Каждый практикующий специалист по «1С:Управление торговлей 11» (а также 1С:ERP и 1С:Комплексная автоматизация) рано или поздно сталкивается с ситуацией, когда менеджеры бьют тревогу: в отчете по дебиторской задолженности по срокам долга висит приличная сумма, хотя сам Заказ клиента полностью оплачен, а внутри документа состояние оплаты горит зеленым цветом («Оплачено»).
Давайте подробно разберем, почему возникает эта проблема, как устроен механизм отложенных расчетов в 1С, и что делать, если регламентные задания «пропускают» часть документов, требуя ручного перепроведения документов оплаты.
Проанализируем архитектуру взаиморасчетов, выясним причины блокировки фонового задания ПроведениеПоРасчетамСПартнерами и найдем системные пути решения этой проблемы.
Для того чтобы понять корень проблемы, нам необходимо разобраться, как программа распределяет оплаты. В 1С:УТ 11 существует два ключевых регистра накопления, которые отвечают за состояние расчетов с покупателями:
РасчетыСКлиентами — хранит общую сумму долга по объекту расчетов (например, договору или заказу в целом). Именно на этот регистр опирается сам документ заказа, когда показывает статус «Оплачено» во внутренних формах.РасчетыСКлиентамиПоДокументам — более детальный регистр, который хранит информацию в разрезе конкретных расчетных документов (накладных, платежных поручений, приходных кассовых ордеров) и дат возникновения задолженности. Именно по этому регистру строятся отчеты по дебиторской задолженности по срокам долга и интервалам.Если в первом регистре движения сформировались корректно, а во второй регистр запись по оплате не попала, мы получаем классический разрыв: в заказе долг равен нулю, а в дебиторских отчетах висит просроченный долг.
Такой разрыв возникает из-за использования отложенного (офлайн) режима расчета взаиморасчетов. При проведении платежного документа (например, ПриходныйКассовыйОрдер или ПоступлениеБезналичныхДенежныхСредств) система не пытается сразу распределить деньги по накладным в реальном времени, чтобы не заставлять пользователя ждать. Вместо этого программа делает две вещи:
ЗаданияКРаспределениюРасчетовСКлиентами. This запись сообщает системе: «Внимание! По этому клиенту изменились платежи, нужно пересчитать распределение».Далее в фоновом режиме запускается регламентное задание «Выполнение отложенных движений по расчетам с клиентами» (которое вызывает процедуру ПроведениеПоРасчетамСПартнерами). Оно считывает задания из очереди, берет неоплаченные накладные и распределяет по ним поступившие платежи, делая итоговые записи в регистр РасчетыСКлиентамиПоДокументам.
Если дебиторка «зависает» и лечится только ручным изменением или перепроведением документов, это означает, что цепочка отложенного проведения ломается. Фоновое задание по какой-то причине либо пропускает этот документ, либо аварийно завершается.
Выясним основные технические причины, почему фоновое задание не справляется со своей задачей с первого раза.
---
Это самая распространенная причина в активно работающих многопользовательских базах данных. Когда фоновое задание пытается рассчитать цепочку долгов по конкретному партнеру, оно накладывает управляемую блокировку на записи регистров по данному контрагенту.
Если в этот же самый микросекундный интервал менеджер пытается записать новый заказ, провести реализацию или выписать счет по этому же контрагенту, возникает конфликт блокировок. База данных понимает, что фоновое задание мешает оперативной работе пользователя. В зависимости от настроек СУБД, регламентное задание либо завершается с ошибкой таймаута блокировки, либо просто откладывает обработку этого конкретного задания «на потом», переходя к следующему партнеру. В результате документ оплаты зависает нераспределенным.
Иногда из-за некорректных обменов данными, аварийного завершения работы сервера или программных сбоев при обновлении конфигурации в регистре сведений ЗаданияКРаспределениюРасчетовСКлиентами появляются поврежденные записи. Например, запись может содержать пустую ссылку в поле АналитикаУчетаПоПартнерам, незаполненную организацию или невалидную дату.
Когда регламентное задание доходит до этой строки, оно пытается обработать ее по стандартному алгоритму, натыкается на системную ошибку (например, «Поле объекта не обнаружено» или «Попытка деления на ноль») и аварийно прекращает работу. Вся очередь заданий, которая стояла за этой поврежденной записью, остается необработанной.
Рассмотрим ситуацию: бухгалтер закрыл прошлый месяц и установил дату запрета изменения данных. Однако платеж от клиента пришел в текущем месяце, а сама отгрузка (накладная), которую этот платеж должен закрыть, была создана в прошлом (уже закрытом) периоде.
Регламентное задание пытается распределить оплату текущего месяца на документ прошлого периода. Платформа анализирует дату запрета редактирования и запрещает делать новые записи в регистры накопления задним числом. Регламентное задание блокируется и не может завершить распределение.
---
Ниже приведен комплекс мер, которые помогут локализовать и устранить зависание дебиторской задолженности в вашей базе 1С:УТ 11.
Если ваша конфигурация находится на актуальном релизе (начиная с версий 11.4.11 / 11.5), самым правильным и надежным решением будет полный отказ от устаревшей офлайн-архитектуры распределения.
Разработчики 1С создали новый производительный механизм — Онлайн-взаиморасчеты. В этом режиме распределение по документам расчетов происходит мгновенно в момент проведения платежа или отгрузки, без использования фоновых заданий и очередей распределения.
Для перехода на новую схему выполним следующие действия:
Важно: Переход на онлайн-режим может потребовать некоторого времени, если база данных имеет большой объем накопленных документов. Рекомендуется выполнять эту операцию в копии базы перед применением на рабочей системе.
Если ваша база сильно кастомизирована (содержит много специфических доработок, как у автора темы), и быстро обновить конфигурацию или сменить режим расчетов на «Онлайн» невозможно, проведем технический аудит текущего механизма.
Проанализируем журнал регистрации:
РегламентноеЗадание.ВыполнениеОтложенныхДвиженийПоРасчетамСКлиентами или общим модулем взаиморасчетов.Если мы обнаружили системную ошибку на конкретном документе, нам нужно вручную очистить очередь «зависших» заданий. Для этого:
ЗаданияКРаспределениюРасчетовСКлиентами.Для примера рассмотрим, как программно можно инициировать принудительный пересчет отложенных движений по конкретному партнеру, используя встроенный язык 1С. Этот код можно использовать в составе внешней обработки:
// Пример программного запуска актуализации взаиморасчетов по партнеру
Процедура ВыполнитьРасчетПоПартнеру(ВыбранныйПартнер) Экспорт
// Проверим, заполнена ли ссылка на партнера
Если НЕ ЗначениеЗаполнено(ВыбранныйПартнер) Тогда
Возврат;
КонецЕсли;
// Вызываем стандартный метод актуализации расчетов из БСП / УТ 11
// В зависимости от версии конфигурации имя метода может незначительно отличаться
Попытка
КлассификацияКонтактовВзаиморасчетовВызовСервера.АктуализироватьРасчетыСКлиентами(ВыбранныйПартнер);
ЗаписьЖурналаРегистрации("Взаиморасчеты", УровеньЖурналаРегистрации.Информация, , ,
"Успешно выполнен принудительный пересчет расчетов по партнеру: " + ВыбранныйПартнер);
Исключение
ЗаписьЖурналаРегистрации("Взаиморасчеты", УровеньЖурналаРегистрации.Ошибка, , ,
"Ошибка принудительного расчета по партнеру: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке()));
КонецПопытки;
КонецПроцедуры
Если в вашей базе данных регламентное задание по расчету расчетов запускается слишком часто (например, каждые 10 секунд), это гарантированно приводит к эскалации блокировок СУБД в рабочее время.
Отрегулируем расписание:
Выполнение отложенных движений по расчетам с клиентами.Применяя данные шаги на практике, вы избавитесь от ситуации, когда оплаченные заказы продолжают отображаться в отчетах как просроченный долг, и обеспечите стабильную и корректную работу блока управленческого учета взаиморасчетов.