Как в 1С изменить способ зачета авансов по умолчанию на «Не зачитывать» при создании и вводе на основании?

← На главную

Рады приветствовать вас! Сегодня мы разберем одну из весьма востребованных задач по кастомизации типовой логики в решениях на платформе «1С:Предприятие 8.3» (таких как «1С:Бухгалтерия предприятия 3.0», «1С:ERP» или «1С:Комплексная автоматизация»). Речь пойдет об автоматическом зачете авансов в документах отгрузки, а именно в документе РеализацияТоваровУслуг (Реализация товаров и услуг).

Наверняка многие из вас сталкивались с ситуацией, когда по требованиям управленческого или бухгалтерского учета необходимо, чтобы по умолчанию при создании новой реализации способ зачета авансов устанавливался не в значение «Автоматически», а в «Не зачитывать». В рамках этой статьи мы подробно рассмотрим причины стандартного поведения системы, проанализируем, почему простые решения могут давать сбой при определенных сценариях работы (например, при вводе на основании счета или заказа), и разработаем надежные механизмы решения этой задачи с помощью механизма расширений конфигурации.

Анализ стандартного поведения системы и его ограничения

По умолчанию в типовых конфигурациях 1С логика заполнения реквизита СпособЗачетаАвансов жестко зашита на уровне программного кода модулей. Давайте выясним причину, почему разработчики приняли такое решение. Дело в том, что автоматический зачет авансов по методу ФИФО является наиболее распространенной и методологически верной практикой для большинства коммерческих предприятий. Тем не менее, существуют специфические ситуации (например, сложные схемы взаиморасчетов по договорам, особенности валютного контроля или поэтапная оплата), когда зачетом авансов необходимо управлять вручную.

Стандартное поведение системы предполагает автоматическое переключение способа зачета в положение «Не зачитывать» только в двух строго определенных случаях:

Если в документе выбран вид операции, подразумевающий отгрузку без перехода права собственности.
Если в договоре с контрагентом выбран вид договора «С комиссионером».

Во всех остальных случаях система принудительно устанавливает значение «Автоматически». К сожалению, изменить это поведение глобально стандартными пользовательскими настройками в интерфейсе невозможно. Для решения этой проблемы нам потребуется прибегнуть к механизму расширений.

Почему поверхностные решения не работают при вводе на основании?

Разберем по шагам типичную ошибку. Часто разработчики предлагают использовать расширение формы или общий модуль формы и перехватывать процедуру ДоговорКонтрагентаОбработатьИзменение, добавляя в расширение директиву &После:


Форма.Объект.СпособЗачетаАвансов = Перечисления.СпособыЗачетаАвансов.НеЗачитывать;

Казалось бы, решение логичное: при выборе или изменении договора в документе срабатывает код, который переопределяет способ зачета авансов. И действительно, если пользователь создает документ вручную с нуля, заходит в форму, выбирает контрагента и договор — код отрабатывает штатно, и способ зачета меняется на «Не зачитывать».

Однако проанализируем ситуацию, когда документ «Реализация товаров и услуг» создается на основании другого документа, например, «Счета на оплату покупателю» или «Заказа клиента». В этом случае нас ждет разочарование — в созданном документе способ зачета авансов снова окажется в положении «Автоматически». Почему так происходит? Процесс создания документа на основании состоит из нескольких этапов:

Вызывается событие ОбработкаЗаполнения в модуле объекта нового документа. Здесь происходит перенос всех реквизитов (включая договор) из документа-основания.
Инициализируется и открывается форма документа. Так как реквизит ДоговорКонтрагента уже заполнен на этапе обработки заполнения, интерактивного изменения договора на форме не происходит.
Соответственно, событие ПриИзменении для договора не генерируется, и наш обработчик ДоговорКонтрагентаОбработатьИзменение попросту игнорируется. Платформа при инициализации формы отрабатывает стандартные алгоритмы заполнения по умолчанию, устанавливая зачет авансов в «Автоматически».

Чтобы решить эту проблему раз и навсегда, рассмотрим два надежных и правильных способа реализации.

Вариант А. Перехват события формы «ПриСозданииНаСервере» (для интерактивной работы)

Рассмотрим подробнее первое решение. Если ваша цель — гарантировать правильное заполнение реквизита при работе пользователя через интерактивный интерфейс (независимо от того, создается ли документ вручную или вводится на основании), лучшим решением будет использование расширения формы документа.

Мы добавим в расширение форму документа РеализацияТоваровУслуг (основную форму документа) и перехватим процедуру ПриСозданииНаСервере с помощью директивы &После. Это гарантирует, что наш код выполнится в самом конце создания формы на сервере, когда все стандартные заполнения уже завершились.

Посмотрим на пример реализации данного метода:


&После("ПриСозданииНаСервере")
Процедура Расш_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Проверяем, что документ является новым и еще не записан в информационную базу
    Если Не ЗначениеЗаполнено(Объект.Ссылка) Тогда
        
        // Устанавливаем требуемый способ зачета авансов по умолчанию
        Объект.СпособЗачетаАвансов = Перечисления.СпособыЗачетаАвансов.НеЗачитывать;
        
    КонецЕсли;
    
КонецПроцедуры

Этот код лаконичен и крайне эффективен. Проверка Не ЗначениеЗаполнено(Объект.Ссылка) критически важна: она предохраняет нас от перезаписи данных в уже существующих и проведенных документах при их открытии пользователями для просмотра или редактирования.

Вариант Б. Модификация логики в модуле объекта (для программного создания)

Проанализируем альтернативный сценарий. Что делать, если документы в вашей системе создаются не только интерактивно пользователями, но и программно? Например, через внешние обработки, регламентные задания, мобильные приложения или посредством интеграции через Web-сервисы (API). В таких случаях формы документов вообще не создаются и не открываются на сервере, а значит, код из Варианта А не сработает.

Для решения этой задачи нам необходимо перенести логику на уровень модуля объекта. Мы воспользуемся расширением для модуля объекта документа РеализацияТоваровУслуг и перехватим стандартный обработчик ОбработкаЗаполнения.

Разберем по шагам данный подход:


&После("ОбработкаЗаполнения")
Процедура Расш_ОбработкаЗаполнения(ДанныеЗаполнения, СтандартнаяОбработка)
    
    // Данный код сработает после завершения стандартного заполнения документа, в том числе на основании
    ЭтотОбъект.СпособЗачетаАвансов = Перечисления.СпособыЗачетаАвансов.НеЗачитывать;
    
КонецПроцедуры

Использование директивы &После позволяет нам не вмешиваться в сложные типовые механизмы заполнения табличных частей и взаиморасчетов, которые выполняет конфигурация 1С. Мы просто аккуратно корректируем итоговый результат в самом конце процедуры ОбработкаЗаполнения.

Проверка функциональных опций в настройках программы

Обратите внимание на важный нюанс, связанный с настройками самой информационной базы. Чтобы пользователи вообще имели возможность видеть и изменять поле «Зачет авансов» на форме документа реализации, в системе должна быть активирована соответствующая функциональная опция.

Давайте проверим эту настройку в программе «1С:Бухгалтерия предприятия 8» (редакция 3.0):

Перейдите в раздел меню Администрирование.
Выберите пункт Функциональность.
Открываем вкладку Расчеты.
Убеждаемся, что установлен флажок напротив опции Управление зачетом авансов (в некоторых релизах данная опция может называться «Документы расчетов с контрагентами»).

Если данный флажок снят, то поле выбора способа зачета авансов будет скрыто с формы документа, а сама программа будет неявно зачитывать все авансы автоматически по методу ФИФО. Наш программный код в таком случае не приведет к видимым изменениям в интерфейсе, хотя значение реквизита в базе данных все равно будет изменено.

Как массово изменить зачет авансов в существующих документах?

Часто возникает необходимость исправить ситуацию не только для будущих, но и для уже проведенных документов за прошлые периоды. Писать для этого разовую обработку совсем не обязательно — в арсенале администратора 1С есть мощный стандартный инструмент.

Рассмотрим подробнее процесс массового изменения реквизитов:

Перейдите в раздел Администрирование -> Обслуживание -> Корректировка данных.
Откройте ссылку Групповое изменение реквизитов.
В поле «Выбирать элементы» укажите документ «Реализация (акты, накладные, УПД)».
Обязательно настройте правила отбора (например, по конкретному периоду или по определенной организации/контрагенту), чтобы случайно не изменить лишние документы.
В списке доступных реквизитов найдите поле Способ зачета авансов (в базе данных оно соответствует реквизиту СпособЗачетаАвансов).
В колонке «Новое значение» установите вариант Не зачитывать.
Нажмите кнопку Изменить реквизиты в правом нижнем углу.

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

Особенности интеграции и обмена данными

В завершение разберем еще одну важную проблему, которая часто ставит в тупик начинающих специалистов. Бывают ситуации, когда в «1С:Бухгалтерии» способ зачета авансов самопроизвольно меняется на «Не зачитывать» или «По документу» после выполнения синхронизации данных (например, при обмене с «1С:Управление торговлей 10.3» или «1С:Управление нашей фирмой»).

Выясним причину этого явления. Причиной служат правила конвертации данных. Если в системе-источнике (например, в УТ) в параметрах договора или соглашения с клиентом выбран вариант ведения расчетов «По документам расчетов», то при выгрузке XML-пакет содержит указания на конкретные расчетные документы. Правила обмена принудительно затирают стандартное значение «Автоматически» в бухгалтерии.

В таких ситуациях внесение изменений в код формы или модуля объекта БП не принесет желаемого результата, так как обмен данными записывает объекты напрямую, минуя интерактивные формы и стандартные процедуры заполнения. Здесь правильным решением будет корректировка правил конвертации данных (ПКО) перед выгрузкой или настройка ведения взаиморасчетов на стороне управляющей торговой системы.