Добрый день, коллеги!
Столкнулся с проблемой расчета поля EKPO-EFFWR (Фактическая стоимость позиции) при создании контракта при помощи BAPI_CONTRACT_CREATE.
При следующих значениях NETPR KTMNG PEINH, например:
NETPR (Цена нетто) = 837,16
KTMNG (Договорное количество) = 36
PEINH (Единица цены) = 36
которые подавались в BAPI, создался контракт, у которого поле EKPO-EFFWR уже имеет значение EFFWR = 837,00.

Аналогичные исходные данные при создании через ME31K приводят к правильному расчету (EFFWR = 837,16.).
Очевидно, что проблема связана с последовательным округлением результатов умножения NETPR на KTMNG, затем деления на PEINH.

Вопрос: Кто-либо сталкивался с такой проблемой? Подскажите, плз, в каком направлении стоит копать решение?

Заранее спасибо за помощь

я бы тупо подебажил ME31K и посмотрел какие параметры и методы используются там

Подебажил bapi, проблему решил замещением, реализованным в расширении ФМ ME_CREATE_DOCUMENT, но все же осталось неясным, почему так коряво расчитывает сама бапишка.

При дебаге во что "уперлись"? Видно по коду где и как рассчитывается EFFWR? Пересчитали значение по своей логике в энхансменте ФМ-а ME_CREATE_DOCUMENT?

Вот что раскопал:
1. Инклуд LMEKOU45 проги SAPLMEKO
2. PERFORM call_condition_copy TABLES lt_ckomv
USING ls_komg
CHANGING ls_komk ls_komp ls_vake.

2.1 CALL FUNCTION 'RV_CONDITION_COPY'
2.2 call dialog 'RV_CONDITION_MAINTENANCE' возвращает структуру e_komp
e_komp-NETPR = 837.16
e_komp-KPEIN = 36
e_komp-BRTWR = 23.25 (837.16/36 = 23,25444444444444)
e_komp-NETWR = 23.25 (23,25444444444444)
e_komp-EFFWR = 23.25 (23,25444444444444)

3. PERFORM transfer_price_to_oa_item USING ls_komp ls_vake
ls_vake_src im_ekko
CHANGING ex_ekpo.
3.1 в ней вызывается PERFORM determine_oa_values USING im_komp
CHANGING ch_ekpo.
3.2 И фрагмент интересующего кода:
f1 = ch_ekpo-netpr * ch_ekpo-ktmng / ch_ekpo-peinh / 1000
* ch_ekpo-bpumz / ch_ekpo-bpumn.
IF f1 LE cl_mmpur_constants=>max_value.
ch_ekpo-zwert = f1.
ENDIF.
f1 = im_komp-brtwr * ch_ekpo-ktmng / im_komp-mglme.
IF f1 LE cl_mmpur_constants=>max_value.
ch_ekpo-brtwr = f1.
ENDIF.
f1 = im_komp-effwr * ch_ekpo-ktmng / im_komp-mglme.
IF f1 LE cl_mmpur_constants=>max_value.
ch_ekpo-effwr = f1.
ENDIF.

Собственно, вот здесь и получаются значения полей ekpo-effwr, ekpo-brtwr, ekpo-zwert. Только в случае с ekpo-zwert расчет ведется исходя из значения ekpo-netpr (и в итоге получается правильное значение 837.16), а в случае с ekpo-effwr, ekpo-brtwr пляшут от komp-effwr(23.25) и komp-brtwr(23.25) соответственно, которые уже были округлены в ФМ 'RV_CONDITION_MAINTENANCE' и в результате имеем 837.00.

Вот в это я "уперся" в дебаге.

Так что прямой подлом в ME_CREATE_DOCUMENT врядли корректен, а вот как решить вопрос с таким расчетом в 'RV_CONDITION_MAINTENANCE' - хотелось бы выслушать мнения форумчан

Попробуйте использовать BAdI SD_COND_SAVE_A.

Не вышло. К сожалению, не нашел там необходимых полей для замены. В параметре CT_KONPDB_NEW присутствует только KBETR..

Расковыряв bapi_contact_create, выяснил, что позиций BAPI необходимо заполнить:
it_item_bapi-relord_qty(Стандартный объем отзыва) = it_item-peinh (Единица цены)
Без указания - стандартный объем отзыва тянется из инфо-записи материала и расчет идет некорректно.

И тогда настало счастье
Спасибо за помощь