Некорректный рассчёт стоимости ПМ при частичной поставке

[SCoTo]

Суть: позиция Знп количество 37,125 стоимость 20169,49 расчётная стоимость позиции с учётом окргуления 748792,32
Частичный приход 30,364, расчёт прямой 30,364 * 20169,49 = 612426,39(с коруглением от 612426,394), но приход лепит
с суммой 612426,40(пропорционально стоимости позиции, то есть фактически используя обратный счёт).
В позиции из условий только цена брутто и всё.Откуда рога растут и где рыть не могу понять. В бадишке MIGO подсунуть сумму нормальную не получилось, лепит где-то после. Буду благодарен, если ткнёте носом в матчасть.

[Uukrul]

Ну на самом деле не все так просто, система не считает так сумму, я в свое время разбирался с кодом, там не работает такой вот прямой метод расчета суммы с прямым округлением. Система отталкивается от общего запаса и  его стоимости, т.е например есть две штуки стоимость 1 копейка. При прямом округлении при списании одной шутки должна быть проводка на одну копейку, на самом деле при этом списании вообще не будет финансового документа, а копейка уйдет при списании второй единицы.  В общем сейчас у меня к сожалению нет под рукой с этого компьютера доступной системы, но потом постараюсь найти в качестве примера кусок кода, который считает суммы, если вам очень нужно. Но  сразу говорю, система не считает путем простых округлений сумм.

[SCoTo]

До сих пор актуально.

[Uukrul]

До сих пор актуально.

Я не забыл... разребусь с текущими задачами докопаю эту тему.

[Uukrul]

Значит так, для начала просто как факт что система считает стоимость правильно и у нее есть свой алгоритм расчета цены, при этом вы может как говорил некто Форд, заказать машину с любым цветом, при условии, что этот цвет черный, так и тут, вы можете с калькулятором доказывать, что математически система считает цену не правильно, но она ее так считает и повлиять на это вы не можете. Объясняю на простом примере.

Есть материал и есть его стоимость в периоде. Транзакция CKM3 (Так сказать активен регистр, но сути то это не меняет), рисунок ckm3.png, как видим из рисунка, тут все просто, есть 9 штук, стоят они 100 грв/штука, сумма запаса 900 грв. Теперь усложняем задачу и делаем уценку запаса на 899 грв, т.е. сумма запаса 9 штук будет 1 грв. Уценку делаем через регистр, MR22, пример на рисунке ниже. а еще ниже попробуйте используя математическое округление сказать мне цену одной штуки запаса, ну математически я так понимаю 1 грв = 100 коп / 9 = 11.111111 ~ 11.00, т.е. прблизительно 11 копеек, однако обратите внимание что сумма запаса не стала 99 копеек, а осталась 1 грв, пример на рисунке MR22.png и ниже CKM3-1.png новая цена и сумма запаса.

К чему я все это вел? А к тому, что теперь, если позволить вам даже через BAPI списывать материал + стоимость в ручном режиме используя правила математического округления, это все приведет к тому, что списав последнюю единицу материала по 11 копеек, на складе у вас будет 0 штук, а вот по данным бухгалтерии на счете запаса будет висеть 1 копейка, поэтому я не могу понять, что вы собираетесь рыть? Переписать правила округления сумм в системе? Т.е. вас интересует тот модуль, в котором можно это поменять? В данном случае это группа функций CKM_PRICECHANGES_2, конкретно для MR22, где-то в этом районе можно начать смотреть под отладкой как идет расчет суммы, если там пройтись по тексту, то видно что математическое округление там не работает в таком виде как вы хотите. Поэтому я немного в непонятках, что вы хотите получить на выходе? Математическое округление при расчетах сумм по вашим правилам? В таком случае это никак... точнее конечно с версии .6.0 имея оружие цивилизации под названием энхансмент, можно сделать все, но боюсь что это приведет к гибели всего племени  ;), и как минимум отказ в поддержке со стороны SAP.

В общем уточните что вам актуально, настроить расчет на "правильно", как вы это понимаете? Или объяснить бухгалтерии почему так есть и почему так будет и дальше?

[Uukrul]

Да вот сам текст расчета цены за единицу запаса:

Код Виділити Розширити

function gld_errechnen.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"       IMPORTING
*"             VALUE(LBKUM) LIKE  CKMLPP-LBKUM
*"             VALUE(SALK3) LIKE  CKMLCR-SALK3
*"             VALUE(PEINH) LIKE  CKMLCR-PEINH
*"             VALUE(CURTP) LIKE  CKMLCR-CURTP OPTIONAL
*"       EXPORTING
*"             REFERENCE(PVPRS) LIKE  CKMLCR-PVPRS
*"       EXCEPTIONS
*"              OVERFLOW
*"              PRICE_NEGATIVE
*"              PRICE_ZERO
*"              PRICEUNIT_ZERO
*"----------------------------------------------------------------------
*4.6C
*JAC    401861 090501 MR22 allows negative valuation
*4.5B
*MLKP45K058427 151098 Bei C+725 Wфhrungstyp mitausgeben
*4.5A
*UW ALRK082737 160298 created as substitute for gld_errechen(SAPLCKM1)

  data: verpr_f type f,
        lbkum_f type f,
        salk3_f type f,
        peinh_f type f.
  data h_salk3(18).
  data h_lbkum(18).

  check lbkum ne 0.
  if peinh = 0.
    message e043 raising priceunit_zero.
*   Preiseinheit von 0 ist nicht zulфssig
    exit.
  endif.

  check lbkum ne 0.
  lbkum_f = lbkum.
  salk3_f = salk3.
  peinh_f = peinh.
  verpr_f = salk3_f * peinh_f / lbkum_f.
  catch system-exceptions conversion_errors = 1.
    pvprs =  verpr_f.
  endcatch.
  if sy-subrc = 1.
    h_salk3 = salk3.
    h_lbkum = lbkum.
    message e056 with h_salk3 h_lbkum peinh raising overflow.
*   Feldќberlauf bei der Preisberechnung
  endif.
  if verpr_f < 0.
    message e723 raising price_negative.
*   Periodischer Verrechnungspreis des Materials wird negativ.
  endif.
  if pvprs = 0.
    message e725 with curtp raising price_zero.
*   Periodischer Verrechnungspreis des Materials wird Null.
  endif.



endfunction.

[SCoTo]

За ответ спасибо, кое-чего нового почерпнул. Но речь веду не о существующем запасе, а о приходящем и расчёте стоимости для него. По отпуску и корректировке цен тут всё понятно. Меня интересует аналогичная проблема расчёта стоимости ПМ, которое считается не как количество*цену(именно так и хотелось бы) при частичной поставке, а пропорционально от стоимости позиции ЗнП.

PS Версия 4.7

[Uukrul]

Ок, понял... гляну этот кусок рассчета...

[Uukrul]

Ну в общем-то я бы про не корректный рассчет все таки не говорил бы... так как за теорией как компьютер работает с числами вида FLOAT, это все таки не SAP, а больше к принципам как вообще имея фактически целочисленную двоичную арифметику, процессор получает числа с плавающей точкой.

В общем сделал по вашему методу заказ, рисунок 4500011964.png, в общем если идти по вашему методу и рассчиать все на калькуляторе, то при поступлении 30,364 получаем методом расчета на калькуляторе = 612426,39436, т.е. по правилам округления 39 копеек в хвосте, Однако если сделать операцию проводки, то сумма будет  = 612426,40, т.е. все таки 40 копеек. Смотрим как оно считает и видим что все рассчеты сводятся к преобразованию чисел к формату FLOAT, после чего уже идет рассчет, т.е. результат получается просто более точным, чем считает калькулятор, так как формат FLOAT из справки SAP имеет разрядность F Floating point number 8, что дает нам в рассчетах следущие картинки. Смотрим на 4500011964-LMBGBFES-2.png и видим, что после фактический рассчет идет такой:
( 3.0364000000000000E+04 * 748691.47 ) / 3.7120000000000000E+04 =   6.1242639534159482E+07, т.е. как видим таки по правилам округления это будет 40 копеек, а не 39... короче, все дело в точности, которая у SAP выше чем у стандартного калькулятора или программы калькулятора (под виндой и под дебом (кде), калькулятор тоже показывает 39 копеек, но если накрутить точность представления, то можно выйти на 40 как и у SAP).

Надеюсь вопроса закрыт. Кстати, если вам таки надо 39 копеек, ну тогда можно отфактурировать поставленное количество на 612426,39 и копейка из стоимости уйдет. Хотя как по мне, все и так правильно, кстати, а никто не знает если ли государственные нормы по правилам округления стоимостей при рассчете частичных поставок, т.е. какая точность должна быть при рассчетах и т.д. Как по мне то я о таких правилах не слышал.

[SCoTo]

Огромное спасибо.
Ровно то, что доктор прописал.
Буржуйская логика чё поделаешь. Договорные отношения превыше всего ;D