Sapforum.Biz
Логистика => Управление материальными потоками (MM) => Тема начата: SCoTo от Апрель 02, 2009, 06:15:00 pm
-
Суть: позиция Знп количество 37,125 стоимость 20169,49 расчётная стоимость позиции с учётом окргуления 748792,32
Частичный приход 30,364, расчёт прямой 30,364 * 20169,49 = 612426,39(с коруглением от 612426,394), но приход лепит
с суммой 612426,40(пропорционально стоимости позиции, то есть фактически используя обратный счёт).
В позиции из условий только цена брутто и всё.Откуда рога растут и где рыть не могу понять. В бадишке MIGO подсунуть сумму нормальную не получилось, лепит где-то после. Буду благодарен, если ткнёте носом в матчасть.
-
Ну на самом деле не все так просто, система не считает так сумму, я в свое время разбирался с кодом, там не работает такой вот прямой метод расчета суммы с прямым округлением. Система отталкивается от общего запаса и его стоимости, т.е например есть две штуки стоимость 1 копейка. При прямом округлении при списании одной шутки должна быть проводка на одну копейку, на самом деле при этом списании вообще не будет финансового документа, а копейка уйдет при списании второй единицы. В общем сейчас у меня к сожалению нет под рукой с этого компьютера доступной системы, но потом постараюсь найти в качестве примера кусок кода, который считает суммы, если вам очень нужно. Но сразу говорю, система не считает путем простых округлений сумм.
-
До сих пор актуально.
-
До сих пор актуально.
Я не забыл... разребусь с текущими задачами докопаю эту тему.
-
Значит так, для начала просто как факт что система считает стоимость правильно и у нее есть свой алгоритм расчета цены, при этом вы может как говорил некто Форд, заказать машину с любым цветом, при условии, что этот цвет черный, так и тут, вы можете с калькулятором доказывать, что математически система считает цену не правильно, но она ее так считает и повлиять на это вы не можете. Объясняю на простом примере.
Есть материал и есть его стоимость в периоде. Транзакция 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.
В общем уточните что вам актуально, настроить расчет на "правильно", как вы это понимаете? Или объяснить бухгалтерии почему так есть и почему так будет и дальше?
-
Да вот сам текст расчета цены за единицу запаса:
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.
-
За ответ спасибо, кое-чего нового почерпнул. Но речь веду не о существующем запасе, а о приходящем и расчёте стоимости для него. По отпуску и корректировке цен тут всё понятно. Меня интересует аналогичная проблема расчёта стоимости ПМ, которое считается не как количество*цену(именно так и хотелось бы) при частичной поставке, а пропорционально от стоимости позиции ЗнП.
PS Версия 4.7
-
Ок, понял... гляну этот кусок рассчета...
-
Ну в общем-то я бы про не корректный рассчет все таки не говорил бы... так как за теорией как компьютер работает с числами вида 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 и копейка из стоимости уйдет. Хотя как по мне, все и так правильно, кстати, а никто не знает если ли государственные нормы по правилам округления стоимостей при рассчете частичных поставок, т.е. какая точность должна быть при рассчетах и т.д. Как по мне то я о таких правилах не слышал.
-
Огромное спасибо.
Ровно то, что доктор прописал.
Буржуйская логика чё поделаешь. Договорные отношения превыше всего ;D