Виталий, информация по генерации преподнесена верно, но вот тема использования вызовов ФМ в собственной АВАР-разработке, мне кажется, раскрыта не полностью.
Внесу пару дополнений, если не возражаете:
1) Сгенерированные ФМ являются модулями обновлений с отложенным запуском (V2-Update). Соответственно, запускаться должны, в идеале, из модуля обновлений ваших данных.
2) Кроме того, можно было бы отметить возможность подготовки таблиц обновления с помощью стандартного ФМ CHANGEDOCUMENT_PREPARE_TABLES. Отдавая на вход таблицы с новыми/старыми данными, получим готовенькие таблицы с установленными индикаторами обновлений.
3) Еще есть нюанс - если запись документа изменений проводится для сложного бизнес-объекта (заголовок + позиции), то модуль, полученный автоматически (как описано в статье), разнесет разные виды изменений позиций (U, I,D) по различным документам изменений, что не всегда удобно и оптимально. В этом случае придется "пилить" собственный модуль записи документов изменений, основываясь, как и стандартный на ФМ CHANGEDOCUMENT_*.

Виталий, информация по генерации преподнесена верно, но вот тема использования вызовов ФМ в собственной АВАР-разработке, мне кажется, раскрыта не полностью.
Внесу пару дополнений, если не возражаете:
1) Сгенерированные ФМ являются модулями обновлений с отложенным запуском (V2-Update). Соответственно, запускаться должны, в идеале, из модуля обновлений ваших данных.
2) Кроме того, можно было бы отметить возможность подготовки таблиц обновления с помощью стандартного ФМ CHANGEDOCUMENT_PREPARE_TABLES. Отдавая на вход таблицы с новыми/старыми данными, получим готовенькие таблицы с установленными индикаторами обновлений.
3) Еще есть нюанс - если запись документа изменений проводится для сложного бизнес-объекта (заголовок + позиции), то модуль, полученный автоматически (как описано в статье), разнесет разные виды изменений позиций (U, I,D) по различным документам изменений, что не всегда удобно и оптимально. В этом случае придется "пилить" собственный модуль записи документов изменений, основываясь, как и стандартный на ФМ CHANGEDOCUMENT_*.

Нехорошо из меппинга куда попало (=недокументировано) соединения устанавливать! Правильно передавать канал как параметр меппинга, а URL через динамическую конфигурацию подсовывать. Да и параметры прокси для интернета, мониторинг общения с ЦБР и поиск ошибок можно будет делать через PIMON.

Добрый день, Марат,
 
Исходный код zip_dbf_to_xml.java не доступен для скачивания.
 
С уважением,
Дмитрий

К Автору: можно ли указать версию системы, уровень ABAP, ОС и тех.параметры сервера на которых производились замеры?
 
если нет - то нет (в принципе они не так важны).
но если меряем точности, хотелось бы знать чем меряем)))
 
Колонка весьма интересная - спасибо!
 
PS. у меня схожий результат.

Автор видимо что-то не то имел в виду. Вероятно стоит переформулировать возникушую проблему (если есть возможность править опубликованный текст), потому что в таком виде, это, мягко говоря, не совсем так )
"К сожалению, в системе SAP ERP нет инструмента, увязывающего сроки производства одного заказа клиента на разных переделах"

Интересный отчет о стандартной ERP.
А есть ли опыт интеграции с MES или PDM  системами. Интересно было бы почитать какие задачи были поставлены и как они решались.