При работе в современных конфигурациях 1С, таких как «Управление торговлей 11», «Комплексная автоматизация 2» и «ERP Управление предприятием», пользователи часто сталкиваются с неприятной ситуацией. В момент попытки распечатать Счет-фактуру, УПД или ТОРГ-12 система выдает предупреждение: «Печатная форма сформирована по неактуальным данным. Необходимо актуализировать взаиморасчеты вручную и переформировать печатную форму». При этом суммы в печатной форме могут оказаться нулевыми или документ вообще не выводится на печать.
Давайте вместе разберем эту проблему по шагам, выясним причину ее возникновения на программном уровне и рассмотрим подробные варианты решения.
Чтобы понять, как бороться с проблемой, посмотрим на механику работы платформы. Разработчики 1С заложили в систему алгоритм, при котором перед непосредственным выводом печатной формы происходит проверка состояния взаиморасчетов. Система обращается к регистру сведений ЗаданияКРаспределениюРасчетовСКлиентами. Если по данному партнеру есть невыполненные задания, программа пытается распределить расчеты прямо «на лету».
Рассмотрим фрагмент кода из модуля менеджера документа Счет-фактура выданный, который инициирует этот процесс:
Если (ЗаполнятьПлатежноРасчетныеДокументы ИЛИ Не ПараметрыПечати.ПечатьВВалюте)
И МассивАналитикУчетаПоПартнерам.Количество() > 0
И Не ПолучитьФункциональнуюОпцию("НоваяАрхитектураВзаиморасчетов") Тогда
АналитикиРасчета = РаспределениеВзаиморасчетовВызовСервера.АналитикиРасчета;
АналитикиРасчета.АналитикиУчетаПоПартнерам = МассивАналитикУчетаПоПартнерам;
Попытка
РаспределениеВзаиморасчетовВызовСервера.РаспределитьВсеРасчетыСКлиентами(ОкончаниеПериодаРасчета, АналитикиРасчета);
Исключение
ТекстСообщения = НСтр("ru ='Печатная форма сформирована по неактуальным данным.
|Необходимо актуализировать взаиморасчеты вручную и переформировать печатную форму.'");
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения);
КонецПопытки;
КонецЕсли;
Проанализируем этот блок: код обернут в конструкцию Попытка ... Исключение. Это значит, что если при вызове процедуры РаспределитьВсеРасчетыСКлиентами происходит любая ошибка (например, транзакционная блокировка, нехватка прав пользователя, таймаут ожидания освобождения таблиц базы данных), платформа прерывает выполнение фонового распределения и выдает нам то самое сообщение.
Существует несколько основных сценариев, из-за которых процедура распределения взаиморасчетов завершается аварийно:
ВыполнениеОтложенныхДвиженийПоРасчетамСКлиентамиПоставщиками (например, раз в минуту). Одновременно с этим может запускаться задание УстановкаПериодаРассчитанныхИтогов или происходить закрытие месяца. В результате возникают блокировки на уровне СУБД.ЗаданияКРаспределениюРасчетовСКлиентами могут остаться необработанными. Фоновое задание не справляется с объемом и «падает».Давайте по шагам разберем, что можно сделать для устранения данной ошибки, начиная от самых простых пользовательских обходов до системных архитектурных настроек.
Если проблема носит разовый характер, мы можем использовать хитрый трюк. Установите дату запрета редактирования данных в положение «Без запрета». После этого запустите формирование печатной формы документа. Так как запрета нет, система сможет беспрепятственно актуализировать взаиморасчеты и записать нужные данные в регистр. После того как документ успешно выведен на экран, верните настройки даты запрета в исходное состояние.
Примечание: Этот способ помогает, если причиной ошибки является нехватка прав на запись в закрытом периоде при фоновой актуализации.
Откройте консоль регламентных заданий. Проанализируем расписание. Часто ошибка возникает регулярно в определенные дни месяца (например, 5-го числа). В это время может запускаться тяжелое задание по расчету итогов, которое блокирует таблицы, нужные для задания по отложенным расчетам.
Попробуйте разнести эти задания по времени. Например, настройте выполнение ресурсоемких заданий исключительно в ночное время, когда в базе нет пользователей. Если вы видите зависшие сеансы по распределению расчетов, принудительно завершите их и перезапустите службу сервера 1С.
Если ошибка началась после обновления релиза (особенно при прыжках через несколько версий), регистр заданий может содержать «битые» ключи аналитики. В этом случае программисту потребуется написать небольшую внешнюю обработку, которая очищает регистр ЗаданияКРаспределениюРасчетовСКлиентами или принудительно вызывает серверную процедуру по всем проблемным аналитикам.
Важно: Выполнять подобные обработки необходимо строго в монопольном режиме, когда в базе нет пользователей, чтобы избежать нарушения целостности цепочек расчетов.
Это самое надежное и современное решение для пользователей УТ 11.4+, КА 2.4+ и ERP 2.4+. Как мы видели в коде выше, алгоритм проверяет функциональную опцию НоваяАрхитектураВзаиморасчетов.
В старой архитектуре (офлайн) взаиморасчеты формируются отложенно, что и провоцирует зависания при печати. В новой архитектуре онлайн-расчетов распределение сумм по заказам, накладным и договорам происходит непосредственно в момент проведения самого документа. Если вы включите эту функциональную опцию в настройках системы, проблема «неактуальных данных при печати» исчезнет навсегда.
Обратите внимание: переход на новую архитектуру потребует времени на реструктуризацию данных и полного пересчета итогов, поэтому планируйте этот процесс на выходные дни.
Ошибка актуализации данных при печати — это не программный баг, а следствие работы архитектуры отложенных расчетов 1С, сталкивающейся с транзакционными блокировками или ограничениями прав. В зависимости от ситуации, вы можете применить локальное решение (снятие даты запрета) или системное (переход на онлайн-взаиморасчеты). Тщательно проанализируйте расписание регламентных заданий и права пользователей, чтобы обеспечить быструю и стабильную печать первичных документов.