Не знаю: не так силён в функционале. Я бы поискал.

Если это так и все изменения vbrk на момент open fi уже лежат в update-модулях, то всё равно нужно в open fi возвращать номер созданного документа исключительно для проверки на ошибки, а ZZBELNR_D заполнять уже асинхронно, подождав пока отработает стандартный update-процесс.

Ключевое слово - асинхронный FM, такой же как у Вас
CALL FUNCTION 'ZSD_ACC_DOC_POST_BILLING_DOC'
STARTING NEW TASK 'ACC_POST', только он должен проверять в лупе, не снялась ли блокирока с VBRK и если снялась, делать UPDATE vbrk. Он будет жить и после отработки Open-FI.

Лучше всё-таки ждать окончания update-процесса, поскольку блокировку может успеть раньше нас кто-то другой поставить.


Но если на момент выполнения open fi вся vbrk лежит в update-модуле, почему бы не добавить в open fi свой update-модуль с обновлением z-поля? Они же по-порядку выполняются.

Мужчины, спасибо!!! Все заработало!! ))
Сделал так, как предлагал SIBRIN.
ОГРОМНОЕ СПАСИБО за помощь!!!

Думал об этом, а если выскочит какой-то промежуточный commit, но того, как главная программа обновит vbrk. Может же такое случиться, кто-то добавит свою обработку в промежуточном user-exit или событии open_fi.

Можно утверждать, что commit'а не должно быть по той причине, что изменение фактуры и финансового документа должны проходить в одном LUW согласно Принципу SAP.

Если кто-то в юзер-экзите поломает этот механизм, то проблемы будут более глобальные, чем простое необновление Z-поля. Более того, необновление z-поля будет как раз индикатором того, что что-то не так.

Тогда все, что делалось в этом топике - нарушает принцип SAP. Независимые асинхронные update выходят за рамки одного LUW.
Об чем тогда речь, это надо было написать во втором сообщении и прикрыть тему.

Под "принцип SAP" я имел в виду только то, что деблокирование фактуры и создание финансового документа проходит в рамках одного LUW и на это можно надеяться в будущем. Т.е. можно рассчитывать, что не "выскочит какой-то промежуточный commit".

Конечно, в SAPе есть Post Processing Framework, RWIN, Workflow и очень много чего происходит асинхронно.

Более того, SAP очень часто нарушает принцип транзакционности в силу кривости реализации своих LUW и групп функций. С переходом на рельсы ООП эти проблемы снимаются.


Да, конечно, это ненадёжно по очень простой причине.
Между тем, как закончится первый процесс и начнётся второй всегда может вклинится любой другой процесс и прочитать/изменить неконсистентное состояние. Если не ставить в цикле задержки wait up to 1 seconds, то в однопроцессорном приближении наш цикл ожидания не будет давать возможности выполняться родительскому процессу. Процессоров на сервере, конечно, много, но в продуктиве они тоже не скучают. А сделать задержку меньше 1 секунды проблематично.

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

Событие 00001025 тут ни при чём. Второй фин. документ должен создаваться в том же самом LUW, что и первый. Причём не важно в каком событии или экзите.

Но это, видимо, не получается, т.к. идёт конфликт по глобальной памяти используемых ф.м. Поэтому приходится второй документ создавать в параллельном процессе как можно ближе к концу родительского LUW. 1030 - уже процесс обновления, так что там поздно. Так что 1025 выбрано грамотно, после всех проверок.

Т.е. для автора топика, видимо, важнее, чтобы перый документ не создался, если не создастся первый.

Абсолютно с этим согласен.


А вот из-за таких допущений как-раз и возникают трудно отлавливаемые ошибки, появление непонятных документов и тд.



Вот именно, что 1025 - это процесс проверки. Во первых обработчиков события 1025 может быть несколько и в каждом из-них проверка может закончиться неудачно, будет выведено предупреждающее сообщение с предложением исправить данные.

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

Поэтому более разумно использовать события 1030, 1050 или иные, срабатывающе уже после создания документа.

сорри, чет намудрил с сообщениями Предудущее должно быть выше на одно.

Это final check, т.е. после всех проверок.

Универсальной защиты от дураков нет.


1030 ещё до сохранения, in update task. Но, боюсь, что из него нельзя вызвать асинхронный процесс и дождаться завершения. Но если даже можно, то не убивать же update-процесс по причине не создания второго документа — базис этого не поймёт.

Хоть у саперов принято использовать 1025 для модифкаций bseg, bkpf, вообще-то sap задумывал его как final user check после всех проверок sap, хотя и для внутреннего использования. Подтверждение этому, что с версии 4.7 практически закрыл лазейку для модификации через import/export.


Причем здесь защита от дурака? Это вполне законный метод, выдать сообщение о ошибке, если проверка каких либо данных, введенных пользователем, в расширении не прошла. Пользователь мог просто ошибиться, не обязательно он дурак