Коротко по сути: подписки на события для одинаковых источников и действия выполняются в порядке размещения подписок в конфигураторе сверху вниз. Т.е. если для документа Реализация товаров в конфигурации есть две подписки на событие ПриЗаписи, то в начале выполнится та, которая расположена выше. При этом если в типовой конфигурации есть добавленные свои подписки, то при обновлении конфигурации на новый релиз поставщика, может измениться порядок размещения объектов и добавленные подписки могут "съехать" выше типовых. Если в конфигурации есть типовая подписка на это же событие с этим же источником, то может измениться и порядок вызова типовой и добавленной подписки, что может привести к изменению логики работы.
Собственно сабж, обновил доработанную базу Бухгалтерия 3.0, всё проверил, пересмотрел, всё правильно. Порадовался и спать. Добавленные модули и подписки даже не посмотрел, что там может случиться? :)
А случиться, оказывается, может, слетела доработанная нумерация счетов-фактур и реализаций. (Префиксы должны формироваться по дате, что б была сквозная нумерация за каждый день: 161011-0001, 161011-0002 и тд,)
Начал разбираться, оказалось, что добавленная подписка на событие ПриУстановкеНовогоНомера съехала вверх и оказалась выше типовой подписки ПриУстановкеНовогоНомера, которая формирует префикс по узлу обмена и организации. В итоге в начале запускалась доработанная подписка, а потом типовая добавляла стандартный префикс, получался номер типа ОРИБ-161011, дальше не хватает символов, ошибка не уникального номера и тд.
Вывод: Если в конфигурации есть добавленные подписки на события, то надо после обновления проверять порядок следования подписок и возвращать добавленные подписки на своё место, что б порядок их выполнения не повлиял на алгоритм работы.
В данной статье рассмотрена ошибка, с которой мы столкнулись после обновления «1С:ERP Управление предприятием» с релиза 2.5.7 на релиз 2.5.22. Для модификации операций закрытия месяца у клиента было отдельное расширение, в котором были модифицированные копии типовых методов.
Рассматривается, при каких условиях и как отключить повторный запуск обработчиков обновления в центральном узле распределенной информационной базе после обмена сообщением с обновленным узлом.
В одном из наших проектов сложного обновления с «1С:ERP 2.5« присутствовал интегрированный модуль «1С:Птицеводство» с неопределенным релизом и накопленными дефектами предыдущих слияний. Прямое обновление было нецелесообразно из-за рисков некорректной реструктуризации. В статье описан метод идентификации версии через анализ метаданных и алгоритм удаления неактуальных объектов перед финальным переходом.
В ходе тестового обновления нетиповой конфигурации «1С:ERP» с версии 2.5.7.201 на 2.5.22.129 после завершения всех регламентных процедур были зафиксированы массовые отрицательные остатки по складам.
Проект обновления «1С:ERP Управление холдингом» с 3.2.1 на 3.2.8 принёс задачку: логика проверки заполнения обязательных реквизитов «переехала» с момента проведения на этап первичной записи документа.
Если в расширение скопирована форма из расширяемой конфигурации, в которой форма была изменена в обновляемом релизе, то в расширении эту форму нужно обновить. Для поиска таких форм предназначена предлагаемая обработка.
Однажды к нам на проект сложного обновления пришла конфигурация «1С: Документооборот КОРП», которую требовалось обновить в технологическое окно 1 час. И мы обновили базу так, как это делают в подобных случаях с ERP — используя механизм «Обновление через копию».
Рассматриваем типичные проблемы обновления 1С: ручную рутину, ошибки при релизах и перегрузку команды. Учимся автоматизировать обновления, работу с доработанными конфигурациями и процессы групповой разработки с помощью инструмента «Обновлятор». Разбираемся, как выстроить безопасный и управляемый процесс доставки изменений – от проверки релизов до автоматического обновления рабочих баз. В результате команда освобождается от рутинных задач и может сосредоточиться на развитии системы.
(1) qwinter, на практике выполняются сверху вниз, я не встречал ситуации, чтобы было иначе. Но разработчики однозначно говорят, что ориентироваться на этот порядок нельзя и что "Подписки могут выполняться в любом порядке".
(1) qwinter, где-то для 8.2 видел видел информацию, что по порядку, сейчас говорят, что в любом порядке, но на деле ни разу не сталкивался, что б не в порядке в конфигурации вызывались. Видимо не хотят отвечать, в случае изменений в алгоритмах платформы. :)) Описанная ошибка в частности это подтверждает, изменение порядка в конфигураторе, приводит к изменению порядка вызова. (платформа 8.3.8.2054)
Еще момент, что подписки с источником общего типа ДокументОбъект, СправочникОбъект выполняются позже, чем с источником конкретного типа, даже если он составной.
Еще момент, что подписки с источником общего типа ДокументОбъект, СправочникОбъект выполняются позже, чем с источником конкретного типа, даже если он составной.
(1) qwinter, раньше, может, выполнялись в произвольном порядке. Проблему, решенную автором, подтверждаю - месяц назад подобную исправил. Решил точно переносом своей подписки в конец всех подписок.
А случиться, оказывается, может, слетела доработанная нумерация счетов-фактур и реализаций. (Префиксы должны формироваться по дате, что б была сквозная нумерация за каждый день: 161011-0001, 161011-0002 и тд,)
И как налоговая относится к такой нумерации? Бухи какую только ерунду не придумывают :)
(5) Armando, ну для разработок с "нуля" - однозначно, а при доработке типовых конфигураций, не всегда целесообразно ради небольших доработок вносить изменения в типовой функционал, особенно в Бухгалтерии, которая требует регулярного обновления.
А не проще ли не нужные подписки просто отключать?. Ну и естественно при обновлении прослеживать "новинки".
И если честно такая нумерация меня тоже удивила: вроде как она должна быть сквозной в пределах года.
(8) lvictor58, А как их отключать без внесения изменений в типовой функционал? Если типовой документ вызывает типовую подписку? И в данной конкретной задаче типовая тоже нужна, только для всех остальных документов кроме реализации и СФ. Если отключить эти два документа из составного типа, то ОЧЕНЬ не удобно будет обновлять..
Про нумерацию точно не скажу, не юрист, но уже не первый раз сталкиваюсь с такой. Очень удобно когда заносятся документы и текущим и задним числом. Что налоговая про это говорит, не знаю, но по моей информации это допустимо, нужно оформить только соответствующий приказ и возможно в учетной политике внести изменения.
