Есть требование большие поставки разбивать, чтобы в одной поставке было не больше 500 ящиков. Потом для каждой поставки должна быть создана своя фактура (billing document), т.к. больше 500 ящиков в грузовик не влезает, но у каждого водителя должна быть строго своя бумажка только на то, что у него в грузовике.

Функциональщики развели руками, так что свалили на абаперов. Консультантша написала программу с использованием BAPI_OUTB_DELIVERY_SPLIT_DEC. Звучит хорошо, но вот что этот гадский BAPI делает. Например, есть один заказ на 250 ящиков и один на 250 ящиков + 2 ящика. Все для одного клиента, так что изначально создается одна поставка с тремя позициями: 250, 250, 2. Запускаем BAPI, которому говорим, что 2 ящика должны быть перенесены на новую поставку. На выходе получаем: исходную поставку в том же виде, но 2 ящика помечены вместо статуса А (Not picked) статусом "пробел" и можно сделать post goods issue без них. OK. Вторая поставка создается с 2 ящиками, там все нормально, их можно pick и post goods issue.

Далее запускаем фактурирование. Создаются два инвойса, но позиция с 2 ящиками фигурирует в обоих, причем по полной цене. Вот-те раз...

Сталкивался ли кто-то с подобной задачей и как бы тут вывернуться с минимальным программированием? Ни в нотах, ни на SDN ничего полезного не нашла. Консультантша пыталась сделать что-то вроде user exit, чтобы удалить позиции, переброшенные на новую поставку, со старой. Кончилось это плачевно полным нарушением статусов и связей в VBFA/VBUP и невозможностью отфактурировать исходную поставку.

транзакции VL10* для разделения поставок. для автоматического создания при помощи абапа смотрите VL10BATCH
Но если ящики это единицы обработки то не знаю как оно будет работать, на уровне заказа упаковку не использовал.

Для того-что чтобы было правило одна поставка --> одна фактура используйте поле VBRK-ZUKRI. Последнее можно решить транзакцией VOFM

И с наступающем Вас

А функциональщики, прежде чем развести руками, посмотрели стандартную транзакцию разделения поставок - VLSP?

Ну а чтобы не релевантная для комплектования позиция не попадала в фактуру, нужно подправить условие копирования из поставки в фактуру. А скорее всего, даже стандарное поможет. Попробуйте, например, 4 - Deliv-related item

VL10* создают поставки, а нам надо разбивать уже существующие. VLSP работает замечательно, все как надо, но там должен кто-то сидеть и тыкать пальцами в позиции, которые должны быть разбиты. А нам задали задачу, чтобы программа по всем поставкам искала те, что больше 500 ящиков (ящики у нас просто единица продажи) и их сама разбивала как в VLSP.



Предложила как вариант, функциональщики не одобрили. Продебажила VLSP, нашла ФМ, который собственно все делает (LE_DSP_ALL_STEPS), но ему нужно передать столько данных, что придется ту же VLSP и копировать. Пока дело кончилось тем, что добавила WS_DELIVERY_UPDATE после BAPI, чтобы удалить позиции, перенесенные на другую поставку. Вроде работает.

С BAPI все было бы нормально, если бы он хотя бы выставлял статус "not relevant for billing" для перенесенных позиций. Не понимаю кому нужет такой split, который потом невозможно отфактурировать правильно без лишних телодвижений? Пошлю пожалуй сообщеньице в SAP, пускай подумают над этим, хотя наверняка придумают какую-нибудь отмазку, как обычно.

Всем спасибо и с наступающим!

Ну, я бы все-таки покопался в стандарте. В том направлении, чтобы завести упаковку - транспортное средство, емкостью 500 ящиков. Затем настроить автоматическую кпаковку в поставке и попробовать добиться от VLSP, чтобы она разбивала поставки по упаковке (единицам обработки). Вовсе не уверен, что это можно заставить работать, но вдруг?

Ну а если через абап, то вам конечно виднее, как это делать.

В общем, с наступающим НГ, всех благ!!!