Номер ваучера при програмном создании журнала

[IKA]

AX2009:
Нужно создать програмно создать строку журнала ledgerJournalTrans.

Использую CreditCardPaymentJournal->createJournal() как пример, но смущает, что для номер ваучера не вызывается used().
Ваучер в данном примере создается в вызове

PHP код:

ledgerJournalEngine.initValue(ledgerJournalTrans) 


Норменая серия у нас для номера ваучера непрерывная. Журнал будет разноситься не сразу после програмного создания, а уже после, пользователем.

Корректно ли использовать приведенный выше пример для создания строк журнала или могут быть потом проблемы с дупликатами строк журналов (т.е ошибка "Номер операции уже использован на дату ..")?

[_scorp_]

Посмотрите класс TutorialJournalCreateExample.

[IKA]

В этом классе тоже не используется used(). Вопрос - почему?

[ashu]

вопрос- у вас же строка создается в каком то журнале? а если в имени журнала настроить присвоение номера операции при разноске-не поможет?

[pitersky]

Цитата:

Сообщение от ashu

а если в имени журнала настроить присвоение номера операции при разноске

только так и надо делать. Ваучер - это идентификатор совершённой финансовой операции. Соответственно, в неразнесённых журналах ваучер не нужен.

[IKA]

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

Нужен used() при этих условиях?

[TasmanianDevil]

Цитата:

Сообщение от pitersky

Ваучер - это идентификатор совершённой финансовой операции.Соответственно, в неразнесённых журналах ваучер не нужен

Журнал из N операций. Каждая операция - сложная.
Риск получить в таком случае откорреспондированную кашу или набор проводок без корреспонденции не пугает ?

[IKA]

Настройка серийных серий - работа консультанта. Моя работа - написать корректный код.
Кто-нибудь знает ответ на поставленный вопрос?

[fed]

В общем - при работе с номерными сериями, есть два режима - простой и сложный
Простой режим работает тогда, когда выделение номера в номерной серии и его использование (то есть - засовывание в поле какой-то записи какой-то таблицы) происходят в рамках одной транзакции. В момент выделения номера, новый номер пишется в таблицу NumberSequenceList, и помечается там статусом Нерешенный (Undecided). Если транзакция успешно завершается, в момент завершения все выделенные номера помечаются как используемые. Если транзакция о откатывается, то в момент отката все нерешенные номера, выделенные в рамках откатываемой транзакции, помечаются как свободные. Штатный аллокатор номеров в номерной серии, перед тем как создать новый номер из счетчика, сначала пытается реюзать свободные номера из NumberSequenceList.

Сложный способ используется тогда, когда выделение и использование номера разделены по времени. В этом случае, при создании класса NumberSeq(),в конструктор передается второй параметр decideLater==true. В этом случае, где-то в своем коде, если ты (или пользователь) решил не использовать уже выделенный номер, ты должен вызвать NumberSeq::Release(), если решил использовать - numberSeq.used(). Если ты ни один из методов не вызвал, то номер будет вечно висеть в статусе Undecided, приводя к распуханию таблицы.
При работе с журналом/заказом/закупкой и тп в интерактивном режиме, возможен сценарий, при котором пользователь создал запись (при этом система снегерирует новый номер в номерной серии и запишет его в поле новой записи), а потом вышел из формы без сохранения, или просто удалил запись до сохранения ее в БД. Для того чтобы отслеживать использование/неиспользование номеров, для таких форм был написан класс NumberSeqFormHandler, который обрабатывает в "сложном" режиме, выделение, пометку как использованных и освобождение номеров в номерной серии.

Поскольку при программном создании строк журнала, вариант "Создали запись, захватили номер ваучера, а потом передумали и не сохранились" невозможен, то никакие used() или Release() не используются, поскольку номера будут корректно помечены как использованные или неиспользованные при успешном или неуспешном завершении транзакции "простым" механизмом.