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