Порядок выполнения подписок на события и опасности с ними при обновлении
Коротко по сути: подписки на события для одинаковых источников и действия выполняются в порядке размещения подписок в конфигураторе сверху вниз. Т.е. если для документа Реализация товаров в конфигурации есть две подписки на событие ПриЗаписи, то в начале выполнится та, которая расположена выше. При этом если в типовой конфигурации есть добавленные свои подписки, то при обновлении конфигурации на новый релиз поставщика, может измениться порядок размещения объектов и добавленные подписки могут «съехать» выше типовых. Если в конфигурации есть типовая подписка на это же событие с этим же источником, то может измениться и порядок вызова типовой и добавленной подписки, что может привести к изменению логики работы.
- Описание
- Подробнее
Описание
Собственно сабж, обновил доработанную базу Бухгалтерия 3.0, всё проверил, пересмотрел, всё правильно. Порадовался и спать. Добавленные модули и подписки даже не посмотрел, что там может случиться? 🙂
А случиться, оказывается, может, слетела доработанная нумерация счетов-фактур и реализаций. (Префиксы должны формироваться по дате, что б была сквозная нумерация за каждый день: 161011-0001, 161011-0002 и тд,)
Начал разбираться, оказалось, что добавленная подписка на событие ПриУстановкеНовогоНомера съехала вверх и оказалась выше типовой подписки ПриУстановкеНовогоНомера, которая формирует префикс по узлу обмена и организации. В итоге в начале запускалась доработанная подписка, а потом типовая добавляла стандартный префикс, получался номер типа ОРИБ-161011, дальше не хватает символов, ошибка не уникального номера и тд.
Вывод: Если в конфигурации есть добавленные подписки на события, то надо после обновления проверять порядок следования подписок и возвращать добавленные подписки на своё место, что б порядок их выполнения не повлиял на алгоритм работы.

