Здравствуйте!
Нужна помощь: есть задача по автопостингу сч/ф MIRO, при этом необходимо учитывать расхождения, которые могут возникать при приемке.
MIRO позволяет указать расхождения, выбрав вариант просмотра позиций счета - "Сокращение суммы счета".
В табличной части позиций становится доступен "индикатор корректировки", вызывающий в обработке код операции RKA.
Проблема заключается в том, что в BAPI_INCOMINGINVOICE_CREATE нельзя передать параметры для расхождений, в т.ч. KZMEK - индикатор корректировки.
Может быть, есть какой-нибудь способ активировать этот признак (с пом. badi, например)? Или, возможно, какой-то принципиально другой подход к данной реализации?

Вариант с отдельным постингом FI документа по расхождениям с помощью BAPI_ACC_DOCUMENT_POST нежелателен.

А что у вас за расхождения - по количеством или по ценам?
Если по ценам - просто указывается в позиции счета правильную сумму (что в MIRO, что в ФМ BAPI_INCOMINGINVOICE_CREATE), и всё тут.
Главное, чтобы сумма с тоталом сошлась в заголовке.

С использованием кода операции RKA никогда не приходилось сталкиваться за все время работы с SAP, поэтому не знаю, что он такого особенного делает.

По количествам. Если делать вручную, то, вроде как, просто указывают количества и суммы расхождения.
Операция RKA, как я понял, как раз добавляет дополнительные проводки при моделировании в MIRO, например, по счету недостачи, в случае расхождения в сторону уменьшения.
Насколько я понимаю, ее триггерят поля "индикатор корректировки" и соответствующие поля сумм и количеств, доступные при варианте просмотра "сокращение суммы счета" в MIRO. Хочу понять, возможно ли как то заполнить эти поля в случае автопостинга.

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

К сожалению, под рукой нет тех спецификаций, чтобы точнее рассказать.

Но вдруг поможет направление мысли.

А названия бадишки не припомните?

Invoice_update

Думаю, это не подойдет, т.к. там только импортируемые параметры.
В любом случае, спасибо за совет.

Даже в стандартных реализациях делают assign и меняют значения. Думаю, мы делали аналогично.
Это как раз одна из особенностей.

Если Вы имеете ввиду assign глобальной переменной, то это может помочь, я не знал о таком "трюке" в случае с импортируемыми badi. Спасибо.

Привет!
BAPI_INCOMINGINVOICE_CREATE1 не умеет проводить документы с сокращением суммы счета, об этом сказано в ноте:
2196371 - Invoice Reduction not available for BAPI_INCOMINGINVOICE_CREATE

Я бы попробовал сначала поставить точку прерывания в начале ФМ MRM_FINAL_CHECK.
Здесь можно попробовать заполнить недостающие поля таблиц I_RBKPV, T_DRSEG данными сокращения суммы счета.
Предварительно можно посмотреть какие поля заполняются в таблицах I_RBKPV, T_DRSEG при проводке документа с сокращением суммы счета в MIRO.

Если все получится, то тогда:
1) Через EXTENSIONIN передавать в BAPI необходимые поля
2) сделать неявную точку расширения в начале ФМ MRM_FINAL_CHECK и там заполнить нужные поля I_RBKPV, T_DRSEG данными EXTENSIONIN

Да, такую ноту видел:)
Я тоже пошел по пути, аналогичному предложенному вами. ФМ этот ковырял в том числе. Проблема в том, что если добавлять нужные поля DRSEG "в середине" процесса, то в ФМ MR_ACCOUNT_ASSIGNMENT не попадаю на операцию RKA, т.к. поля подводящих к ней условий рассчитываются до попытки принудительного заполнения нужных для сокращения счета полей в том же MRM_FINAL_CHECK. А заполнять только необходимый минимум, в т.ч. нужных для условия операции RKA, полей - страшно, т.к. неизвестно, где они участвуют до этого момента и какие рассчитываемые в логике данные не заполнятся.

В итоге подсунул нужные поля в энхансменте инклуда LMRM_BAPIU01. Там в параметрах одной процедурки наряду с s_rbkpv есть tab_frseg, в которой сидят поля, указанные на входе в bapi, но при этом имеются нужные мне поля.

Документ создался, вроде даже идентичен аналогичному документу, проводимому вручную в MIRO.

Спасибо!