Переход с устаревшей конфигурации «1С:Торговля и склад 7.7» (ред. 9.2) на современную систему «1С:Управление торговлей 11» (начиная с версий 11.4.5 и выше) — это классическая задача, с которой регулярно сталкиваются специалисты по внедрению. Однако в процессе миграции данных пользователи часто натыкаются на серьезное препятствие: документы ввода начальных остатков взаиморасчетов (покупателей, поставщиков, авансов) отказываются проводиться, требуя заполнения таинственного поля «Объект расчетов» или конкретного расчетного документа.
В этой статье мы подробно разберем, почему возникает данная проблема, как устроена современная архитектура взаиморасчетов в «1С:Управление торговлей 11», и проанализируем практические способы автоматизации заполнения этих реквизитов, чтобы вам не пришлось вручную переносить сотни документов.
Для того чтобы понять корень проблемы, давайте обратимся к внутренним механизмам работы программы УТ 11. В ранних релизах конфигурации распределение оплат по накладным происходило в так называемом «офлайн»-режиме при помощи фонового выполнения регламентных заданий. Это позволяло системе безболезненно проводить документы ввода остатков, в которых задолженность указывалась укрупненно — например, просто общей суммой в разрезе договора или соглашения.
Начиная с версии УТ 11.4.6, разработчики фирмы «1С» внедрили и сделали основным механизмом новую архитектуру взаиморасчетов (режим «Онлайн»). В современных версиях программы (включая ветку УТ 11.5) этот режим является единственным и безальтернативным. При включенном режиме «Онлайн» действуют следующие правила:
ВводНачальныхОстатковУзловРасчетов или документов ввода остатков по задолженности клиентов и поставщиков, если в табличной части не заполнены реквизиты ОбъектРасчетов и ДокументРасчетов.Поскольку стандартный Помощник перехода на 1С:Управление торговлей 11 разрабатывался под старые стандарты обмена, правила конвертации данных переносят только конечные сальдовые остатки по договорам. Помощник просто не знает, к каким историческим накладным или платежкам из базы 7.7 относятся эти остатки долга, и оставляет данные поля незаполненными. В результате мы получаем непроводящиеся документы в новой базе.
Разумеется, разработчики «1С» предусмотрели, что переносить всю историю отгрузок и документов оплаты за предыдущие 5-10 лет из базы 7.7 нецелесообразно ради одной лишь фиксации остатка. Для этого в систему был добавлен специальный облегченный объект — Документ.ПервичныйДокумент.
Этот документ не делает движений по складскому учету и не является полноценной накладной. Он выступает в роли «заглушки-регистратора», которая содержит минимальный набор реквизитов:
Именно этот Первичный документ и должен выступать в качестве Объекта расчетов в табличных частях ввода начальных остатков.
Рассмотрим подробнее три основных способа решения этой проблемы в зависимости от масштаба базы данных и ваших технических навыков.
Если у вашего клиента или на вашем предприятии количество контрагентов с остатками взаиморасчетов не превышает 10-20 позиций, наиболее простым путем будет ручное исправление данных после переноса. Разберем этот процесс по шагам:
Ввод начальных остатков задолженности клиентов (или поставщиков).Если у вас сотни или тысячи клиентов с долгами и авансами, ручной ввод превратится в адскую рутину. В этом случае правильным решением будет написание и запуск внешней обработки, которая выполнит рутинную работу за нас. Давайте проанализируем логику работы такой обработки:
Наша обработка должна пройтись по непроведенным документам ввода остатков, проанализировать строки табличной части, программно создать под каждую строку Первичный документ, подставить его в реквизиты и провести документ остатков.
Посмотрим на пример программного кода на языке 1С, реализующего эту логику для документа ввода остатков задолженности клиентов:
// Выбираем непроведенные документы ввода остатков задолженности клиентов
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ВводОстатков.Ссылка КАК Ссылка
|ИЗ
| Документ.ВводНачальныхОстатков КАК ВводОстатков
|ГДЕ
| ВводОстатков.Проведен = ЛОЖЬ
| И ВводОстатков.ХозяйственнаяОперация = ЗНАЧЕНИЕ(Перечисление.ХозяйственныеОперации.ВводОстатковВзаиморасчетовКлиентов)";
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
ДокументОбъект = ВыборкаДетальныеЗаписи.Ссылка.ПолучитьОбъект();
Модифицирован = Ложь;
Для Каждого СтрокаТЧ Из ДокументОбъект.ДанныеПОРасчетам Цикл
// Если объект расчетов еще не заполнен
Если Не ЗначениеЗаполнено(СтрокаТЧ.ОбъектРасчетов) Тогда
// Создаем новый Первичный документ в качестве заглушки
НовыйПервичный = Документы.ПервичныйДокумент.СоздатьДокумент();
НовыйПервичный.Дата = ДокументОбъект.Дата;
НовыйПервичный.Организация = ДокументОбъект.Организация;
НовыйПервичный.Партнер = СтрокаТЧ.Партнер;
НовыйПервичный.Контрагент = СтрокаТЧ.Контрагент;
НовыйПервичный.Договор = СтрокаТЧ.Договор;
НовыйПервичный.СуммаДокумента = СтрокаТЧ.Сумма;
НовыйПервичный.Валюта = СтрокаТЧ.ВалютаВзаиморасчетов;
НовыйПервичный.ПорядокРасчетов = Перечисления.ПорядокРасчетов.ПоДоговорамКонтрагентов;
Попытка
НовыйПервичный.Записать(РежимЗаписиДокумента.Проведение);
// Подставляем созданный объект в строку табличной части
СтрокаТЧ.ОбъектРасчетов = НовыйПервичный.Ссылка;
Модифицирован = Истина;
Исключение
Сообщить("Не удалось записать первичный документ для контрагента: " + СтрокаТЧ.Контрагент);
КонецПопытки;
КонецЕсли;
КонецЦикла;
Если Модифицирован Тогда
Попытка
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
Сообщить("Документ " + ДокументОбъект.Ссылка + " успешно заполнен и проведен.");
Исключение
ДокументОбъект.Записать(РежимЗаписиДокумента.Записать);
Сообщить("Не удалось провести документ: " + ДокументОбъект.Ссылка + ". Записан без проведения.");
КонецПопытки;
КонецЕсли;
КонецЦикла;
Использование подобной обработки позволяет полностью автоматизировать рутинный процесс. Обратите внимание, что мы устанавливаем реквизиту ПорядокРасчетов значение ПоДоговорамКонтрагентов или ПоЗаказам в зависимости от настроек конкретного договора из старой базы, чтобы система корректно распределяла последующие оплаты.
Для программистов и специалистов по внедрению, которые хотят получить чистый результат сразу в процессе переноса, наиболее изящным решением будет модификация файла правил обмена ConvertionRules_Tr9_2_Tr11.xml.
Мы можем настроить правила конвертации объектов (ПКО) таким образом, чтобы при выгрузке остатков взаиморасчетов из «1С:Торговля и склад 7.7» алгоритм анализировал остатки по регистру Покупатели или Взаиморасчеты. Если остаток сформирован конкретным документом-регистратором (например, расходной накладной), мы можем передавать параметры этого документа в УТ 11 и на стороне приемника в обработчике события ПослеЗагрузки программно генерировать ПервичныйДокумент с реальной датой и номером из 7.7, связывая его с табличной частью ввода остатков.
Этот подход требует хорошего понимания работы конфигурации «1С:Конвертация данных 2», однако он гарантирует, что база приемник сразу после завершения работы стандартного помощника будет содержать корректные и проведенные документы ввода остатков.
Мы выяснили, что невозможность проведения документов ввода остатков без указания объектов расчетов в УТ 11 — это не ошибка настройки базы, а следствие работы современной онлайн-архитектуры взаиморасчетов конфигураций на платформе 1С:Предприятие 8.3.
Для успешного перехода с «1С:Торговля и склад 7.7» на новые релизы УТ 11.4/11.5 мы рекомендуем заранее подготовиться к этой особенности алгоритмов 1С. Для небольших баз используйте ручное создание технических первичных документов, а для крупных внедрений — воспользуйтесь приведенным нами шаблоном программного кода для создания автоматической сервисной обработки.