Как исправить потерю данных в регистрах «Расчеты с клиентами по документам» и «Расчеты с поставщиками по документам» после обновления?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Управленческий учет Торговля и дистрибуция
← На главную

При переходе с устаревших версий 1С:Управление торговлей 11.1 на новые редакции 11.2 и 11.3 (а также аналогичные версии 1С:ERP и 1С:КА), многие технические специалисты сталкиваются с критической проблемой: регистры РасчетыСКлиентамиПоДокументам (РСКПД) и РасчетыСПоставщикамиПоДокументам (РСППД) начинают вести себя непредсказуемо. Фоновое задание «Выполнение отложенных движений по расчетам» может внезапно удалять корректные записи у существующих документов, из-за чего «разваливается» Управленческий баланс и отчеты по дебиторской и кредиторской задолженности.

В этой статье мы подробно разберем причины возникновения такой ситуации, проанализируем программные ошибки в модулях распределения и рассмотрим алгоритм восстановления данных через механизмы заданий к распределению.

Причины возникновения проблемы и архитектурные изменения

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

  1. При проведении накладной или платежа система записывает краткую информацию в регистр сведений ЗаданияКРаспределениюРасчетовСКлиентами (или поставщиками).
  2. Фоновое задание считывает эти задания и запускает сложный алгоритм распределения платежей по накладным.
  3. Результат этого распределения записывается в регистры накопления РасчетыСКлиентамиПоДокументам и РасчетыСПоставщикамиПоДокументам.

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

Решение 1: Обновление конфигурации и патчинг модулей

Если ваша база находится на релизах диапазона 11.2.2.x — 11.2.3.x, наиболее правильным шагом будет обновление до версии не ниже 11.2.3.84. Однако, если оперативное обновление невозможно, рассмотрим рекомендации службы поддержки по ручному переносу исправлений из более стабильных версий.

Необходимо внести изменения в несколько ключевых серверных модулей:

  1. В модуле РаспределениеВзаиморасчетов следует обновить основной алгоритм, исключив вызовы методов, специфичных для других подсистем, которые могут вызывать блокировки:
    
    // Пример исключаемых вызовов в старых версиях
    УчетУСНСервер.ОбновитьЗаданияКЗакрытиюМесяцаПриВыполненииРеглОперации(...);
    СформироватьЗаданияКРаспределениюНДС(...);
    
  2. В общем модуле ВзаиморасчетыСервер нужно заменить текст методов РассчитатьДатыПлатежаКлиента и РассчитатьДатыПлатежаПоставщика на актуальные версии из стабильных релизов (например, из 2.1.3 для ERP).
  3. В модулях объектов отчетов КредиторскаяЗадолженность и ПлатежнаяДисциплинаКлиентов следует обновить функцию ПолучитьТаблицуПлатежей.

Решение 2: Восстановление движений через «Задания к распределению»

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

Выясним алгоритм работы вспомогательной обработки, которую можно написать для решения задачи:

  1. Подбор документов: Проанализируем период, за который «поплыли» взаиморасчеты. Выберем все документы продажи (РТиУ, Акт) и закупки (ПТиУ).
  2. Создание эталонного задания: Выполним перепроведение одного любого документа вручную. Проверим регистр сведений ЗаданияКРаспределениюРасчетовСКлиентами. Нам нужно зафиксировать номер задания, который сформировала система.
  3. Массовое заполнение заданий: С помощью обработки программно добавим записи в регистр сведений заданий для всех проблемных документов. Основные поля для заполнения:
    • Задание — ссылка на документ или уникальный ключ.
    • Организация — должна быть заполнена обязательно.
    • ОбъектРасчетов — договор, заказ или сама накладная (в зависимости от настроек учета).
  4. Запуск фонового процесса: После заполнения регистра заданий необходимо дождаться запуска регламентного задания «Выполнение отложенных движений по расчетам с клиентами» или запустить его принудительно через консоль регламентных заданий.

Пример кода для программного создания записи в регистре заданий:


МенеджерЗаписи = РегистрыСведений.ЗаданияКРаспределениюРасчетовСКлиентами.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Организация = ВыбраннаяОрганизация;
МенеджерЗаписи.ОбъектРасчетов = СсылкаНаДокумент;
МенеджерЗаписи.Запись();

Решение 3: Проверка аналитики учета

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

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

← На главную