В процессе работы с конфигурацией «1С:Комплексная автоматизация 2.4» (КА 2.4) пользователи иногда сталкиваются с неожиданным поведением системы: документ Реализация товаров и услуг, оформленный на определенную сумму (например, на частичную отгрузку), через некоторое время «самопроизвольно» меняет данные, подтягивая полную сумму из Счета на оплату или Заказа клиента. Рассмотрим подробно, почему это происходит, как устроена логика взаимосвязи документов и какими инструментами можно вычислить причину изменений.
Для начала проанализируем базовый механизм работы системы. В «1С:Комплексная автоматизация 2.4» (и аналогично в 1С:ERP 2) реализована жесткая структура распоряжений на отгрузку. Основным документом-распоряжением почти всегда выступает Заказ клиента.
Разберем стандартную цепочку:
Счет на оплату не является распоряжением для отгрузки.Заказа клиента.Если мы попытаемся в штатной базе создать Реализацию напрямую на основании Счета на оплату, система не предложит такого варианта в стандартном меню «Создать на основании». Следовательно, если в вашей базе такая связь прослеживается или документ заполняется данными счета, мы имеем дело либо с доработкой системы, либо с тем, что пользователь путает Счет и Заказ.
Выясним причины, по которым документ Реализация товаров и услуг может быть перезаполнен данными из распоряжения (Заказа), что внешне выглядит как «заполнение по Счету».
1. Использование рабочего места «Оформление накладных»
В КА 2.4 менеджеры часто используют автоматизированное рабочее место (АРМ) для массового создания документов. Если по Заказу клиента была оформлена частичная реализация (например, на 1 000 руб. из 2 000 руб.), то в списке распоряжений этот заказ все еще висит как «недопоставленный». Если другой пользователь (или тот же менеджер случайно) повторно инициирует процесс оформления по этому распоряжению или использует функции группового переоформления, система может перезаписать существующий документ или создать новый на остаток, что приведет к путанице в суммах.
2. Механизм автоматического пересчета цен
Рассмотрим ситуацию, когда в системе включены автоматические регламентные задания. Если в Заказе клиента или связанном Соглашении изменились цены (например, обновился прайс-лист), а документ Реализация товаров и услуг еще не проведен или находится в статусе «К предоплате» / «В резерве», определенные подписки на события или расширения могут инициировать обновление табличной части. Проанализируем настройки автоматического обновления цен в параметрах системы.
3. Влияние расширений и кастомизации
Как было отмечено в ходе обсуждения проблемы, если в базе реализована возможность ввода Реализации на основании Счета, значит, в систему внесены изменения. Проверим наличие расширений:
Если в списке присутствуют модули, корректирующие проведение или заполнение документов продажи, скорее всего, логика автоматического перезаполнения заложена именно в них. Программист мог добавить код в процедуру ОбработкаЗаполнения или в подписку на событие ПередЗаписью.
Если проблема обнаружена на копии базы и Версионирование объектов (история изменений) не было включено заранее, мы не сможем увидеть детальное сравнение версий «до» и «после». Однако у нас остаются другие инструменты анализа.
Журнал регистрации фиксирует факт изменения объекта даже при выключенном версионировании. Посмотрим на алгоритм поиска:
Реализацию).Проанализируем структуру подчиненности документа. Нажмем кнопку «Отчеты — Связанные документы» в карточке реализации.
Если в дереве связей над Реализацией стоит только Заказ клиента, а Счет находится «сбоку» или вообще отсутствует, значит, реализация всегда ориентируется на данные Заказа. Если сумма реализации изменилась и стала равна сумме заказа, проверьте, не менял ли кто-то сам Заказ клиента (например, увеличил количество товара после того, как была сделана частичная отгрузка).
Если вы планируете разобраться, какой именно код отвечает за перезаполнение, рекомендуем обратить внимание на следующие точки в конфигураторе:
В модуле менеджера документа РеализацияТоваровУслуг проверьте процедуру:
Процедура ОбработкаЗаполнения(ДанныеЗаполнения, ТекстЗаполнения, СтандартнаяОбработка)
// Здесь может быть логика подтягивания данных из Счета
КонецПроцедуры
Также стоит проверить наличие подписок на события, которые реагируют на запись документов. В частности, подписки, связанные с ДокументОбъект.РеализацияТоваровУслуг, событие ПриЗаписи или ПередЗаписью. Часто разработчики добавляют туда механизмы синхронизации табличных частей, чтобы данные в цепочке Заказ -> Счет -> Реализация всегда были идентичны.
Подведем итог: самопроизвольное изменение суммы в Реализации в КА 2.4 — это либо следствие работы внешнего расширения, которое принудительно синхронизирует документы со счетами, либо результат работы штатных АРМ по оформлению накладных, которые при перезаполнении ориентируются на остатки в Заказе клиента. Для предотвращения таких ситуаций в будущем рекомендуем включить Версионирование объектов для документов продажи, что позволит точно видеть, в какой момент и какой реквизит был изменен.