Похоже мы все таки перешли к оккультизму...
Там строчка такая есть в инклюде, CHECK sy-tfill > 999, естественно этот кусок кода за границами энхансмента. Ее как обходить предлагаете?

Очень мне сомнительно, что конкретно между МИГО и RW такое есть, учитывая чувствительность места и древность его возникновения. Желающих подкрутить напильником за прошедшие десятилетия, уверен, было немало, а в свете того, что интеграция движения материалов и финансов это то немногое, что в сапе работает из коробки само, думаю, что все варианты давно обрезаны, даже если они когда-то существовали. TRM это немного другая история все же, там многое зависит от того, мы продаем или покупаем

Неявный энхансмент в начале подпрограммы LFACIFSP(FORM DOCUMENT_SPLIT_GOODS_MOVEMENT): реализовали нужную логику и вышли из подпрограммы.

Вот тут как раз прикол в том, что sap умеет сам дробить такие документы. Представь себе ситуацию: в закупке (ММ) проходит приобретение по сложной номенклатуре (более 499 позиций заказа) и приход на склад. Каждая позиция сопровождается парой позиций (минимум) - BSX и WRX. Удивительная фишка сапа в том, что он сам умеет дробить документ на несколько. Например, при количестве позиций заказа > 499 он сделает в RW сам 2 бухгалтерских документа. Таким образом, сап сам умеет дробить документ по уплотненке - достаточно изучить этот механизм и реализовать его в своем решении, если нужно или если не нужно. Соответственно, как выше написал дедушка Мороз, абсолютный контроль над позициями можно увести на свое решение. При этом я не отрицаю, что это выглядит сурово... но задача прикладная и очень интересная (в настоящий момент, здесь и сейчас). Я бы рад проверить, но в настоящий момент я взламываю XML провайдер книги продаж в России в отсутствие нот для учета прослеживаемости товаров. Хотя нет, я его уже взломал и все работает В сбыте не могу проверить что-либо, потому что я тупорылый и не могу обойти миллион красных ошибок при фактурировании. И вообще в моей системе поставок нет, все идет по плану фактурирования из FPLT.

Всем привет.

Два наблюдения:
1. Кажется на форуме стало больше советчиков, готовых потратить в том числе время на эксперименты, чем собственно авторов вопросов.
Глядя на такие темы, сомневаюсь кто больше заинтересован в результате - автор или толпа набежавших советчиков )

2. Чем дальше, тем больше расстраиваюсь когда все вокруг готовы с энтузиазмом обсуждать технические тонкости реализации хитро выдуманного технического же требования, но мало кому интересно отследить путь от реальной бизнес-потребности до технического требования (сплитить FI-документы, в нашем случае).
Что изменится в физическом мире, если при ОМ к поставке по-прежнему будет один бух. документ, а не два?
Кто из бизнеса расстроится? Почему? Какую свою задачу они надеются решить при помощи двух документов?

Ну точно, оккультизм Ок, я сдаюсь - так действительно можно сделать, хоть это и переламывание сапа через колено. Но впрочем, не в первый раз... Единственное, что - я бы все таки уточнил а. как такая реализация будет работать, если позиций таки набежит 500 и больше, и прожка попытается занырнуть в стандарт; б. как оно работает в интеграции с EWM или любым дрегим внешним складским софтом (если он используется), ибо там наверняка БАПИ, и оно вполнге могло все эти формочки вертеть против часовой; в. эта тара покупается или продается? Потому что от этого зависит сочетание awtyp и glvor, которое по-хорошему тоже надо учитывать.

Так дед его и юзает! Я глянул - он и правда не очень сложный, на ифайской стороне там даже контролить ничего не надо особо, поскольку расшивка происходит на уровне позиции accit простым переклюком "делим/не делим", а дальше все само стандартом.

Мы ищем истину. Нужна ли она автору, уже особенного значения не имеет.

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

Рискну предоположить, что тара оборотная, и учет ведется вот прям как при отцах и дедах - накладные катаются вместе с палетами(или что там), и экспедитор должен вернуть накладную вместе с тарой, тара закреплена за МОЛами на складе и выдается под мат.ответственность экспедитора. Соот-но, для ведения стоимостного и количественного учета подотчетных ценностей требуются отдельные документы. Контрольную функцию бух. учета еще какбэ не отменили.

Какое уж тут переламывание через колено.
Если система УЖЕ умеет делить FI-документы при достижении 999 позиций, то вполне можно заставить ее делить и на меньшие пакеты.
И учесть стандартное разделение тоже можно, это просто более сложная логика.
Никаких интеграций между системами даже обсуждать не стоит.
Был задан вопрос: можно? - Можно.
Нужно ли такое делать? - Думаю, нет.

Ну естественно, если активировано уплотнение позиций, то это работать не будет.
Это все видно в стандартном коде, указанной выше подпрограммы.

а сделать по заказу 2 отдельные поставки - отдельно по товару, и отдельно по таре - не вариант? наверное автоматическое разделение поставок будет проще настроить.

имхо есть ситуации, когда хотелки пользователей нужно ограничивать фразой типа "это ядро САП" со священной дрожью в голосе