IMHO имеет место непонимание разницы между исходящей поставкой (outbound delivery) и goods movement document (документом, который создается при движении материалов). Это два разных документа и, соответственно, имеются разные статусы позиций заказа (sales order) - VBUP-LFSTA, VBUP-WBSTA. Причем я бы смотрела статусы прежде всего на уровне позиции (VBUP), поскольку статус на уровне заголовка (VBUK) - это всего лишь их производная.

В транзакции VL09N происходит сторнирование (cancellation) не поставки, а goods movement document. Соответственно, это отразится на статусе GM, а не на статусе поставки, который в данном случае не изменился. Строго говоря, поставки вообще не сторнируются (как, например, фактуры), а просто удаляются. Если поставку удалить, то можно создать новую поставку для заказа. Если сторнировать только GM, то можно опять провести отпуск товара (goods issue) по той же поставке.

Кстати, еще заметила интересный прикол со статусами (по крайней мере с billing) - не смотря на то, что статусы хранятся в таблицах VBUP/VBUK, для вывода на экран (в VA03, например) статусы определяются отдельно, в самой транзакции. Если, скажем, были какие-то изменения в конфигурации или user exits, etc., то могут быть расхождения между тем, что на экране, и в БД.

Согласен с Jelena.
Если же говорить о теории, то любые статусы это всегда уступка принципам нормализации базы данных, требующим, чтобы информация в БД хранилась в одном месте.

С одной стороны мы экономим время при запросах к БД, с другой - приходится мириться с тем, что иногда по разным причинам возникает неконсистентность и статус не соотвествует реальному потоку документов.

Уже несколько раз убеждался, что если есть какой-то статус, то порывшись, можно найти ноту с коррекционной программой, которая ищет неправильные статусы и апдейтит их в БД.

Спасибо Jelena и LKU за исчерпывающий ответ. Очень помогли начинающему.


Руслан.

круто! такой шлейф, а проблема прямо под носом. я просто наблюдал за ней с интересом, а причина как нельзя проста...всякие чудеса творятся