Перенос данных из устаревших конфигураций (например, 1С:Торговля и склад 7.7 или 1С:Управление торговлей 10.3) в современную редакцию 1С:Управление торговлей 11 — это комплексный процесс, в ходе которого технические специалисты часто сталкиваются с логическими несоответствиями в структуре данных. Типичным примером такой проблемы является ситуация, когда перенесенные документы поступления (Приобретение товаров и услуг) и реализации (Реализация товаров и услуг) отказываются проводиться, выдавая системное сообщение: «Необходимо заполнить этапы графика оплаты». Чтобы избежать подобных сложностей при миграции, можно использовать готовое решение для переноса документов и остатков из УТ 10.3 в УТ 11.5.
В этой статье мы подробно разберем причины возникновения этой ошибки, выясним, почему стандартные средства группового изменения реквизитов оказываются неэффективными, и рассмотрим несколько практических способов массового решения проблемы — от простых манипуляций в пользовательском режиме до автоматизации через правила конвертации данных и встроенный API конфигурации.
Для того чтобы понять суть проблемы, проанализируем разницу в архитектуре хранения данных между старыми и новыми версиями 1С. В конфигурации 1С:ТиС 7.7 плановые даты оплат и лимиты контролировались достаточно просто — часто за счет реквизитов шапки документа или простейших параметров договора. В современных редакциях 1С:УТ 11 (а также в 1С:ERP и 1С:КА) механизм планирования оплат полностью переработан.
В новой архитектуре информация о графиках платежей хранится в специализированной табличной части документа, которая называется ЭтапыГрафикаОплаты. Когда вы открываете проблемный документ интерактивно в интерфейсе программы и пытаетесь его сохранить или провести, система автоматически обращается к бизнес-логике формы. Если табличная часть пуста, встроенные алгоритмы формы генерируют одну строку по умолчанию со 100% оплатой на основе текущей даты или условий соглашения/договора. Именно поэтому при ручном перепроведении «прямо из документа» всё проходит успешно.
Однако при попытке выполнить массовое проведение документов или использовать стандартную обработку «Групповое изменение реквизитов», мы сталкиваемся со следующими препятствиями:
ДатаПлатежа, который мы видим в шапке или в списке реквизитов для изменения, в современных версиях часто является вычисляемым (он считывает значение из первой строки табличной части) либо жестко завязан на существование строки в табличной части ЭтапыГрафикаОплаты.ДатаПлатежа игнорируется платформой, либо вызывает конфликт валидации при проведении, так как сумма этапов оплаты остается равной нулю, что не соответствует общей сумме документа.Рассмотрим подробные варианты обхода этой проблемы, которые помогут вам сэкономить время и массово провести перенесенные документы.
Это один из наиболее быстрых и эффективных способов исправления данных непосредственно в работающей базе без изменения конфигурации. Для этого нам понадобится мощный сторонний инструмент — внешняя обработка «Инструменты разработчика» (автор tormozit).
Разберем по шагам, как настроить групповую обработку для заполнения табличной части:
Реализация товаров и услуг за период переноса, которые не проведены).ЭтапыГрафикаОплаты.ВариантОплаты (например, «Кредит (после отгрузки)») и ПроцентПлатежа (укажите значение 100), можно заполнить фиксированными константами для всех документов.СуммаПлатежа, которая уникальна для каждого документа, используйте возможность выполнения «Произвольного алгоритма».В контексте редактирования строки табличной части ЭтапыГрафикаОплаты напишем следующий короткий и эффективный код:
// В контексте строки табличной части ЭтапыГрафикаОплаты
// Приравниваем сумму платежа к общей сумме документа-владельца
Объект.СуммаПлатежа = ОбъектБД.СуммаДокумента;
Этот простой алгоритм динамически считает сумму из шапки каждого обрабатываемого документа и подставит её в создаваемую строку оплаты. После выполнения обработки все документы получат корректно заполненную табличную часть и без проблем проведутся в системе.
Предыдущий способ хорош, но прямое заполнение полей «в лоб» может упустить некоторые внутренние зависимости системы (например, расчет валютных сумм, заполнение дат с учетом календаря предприятия, заполнение аналитики контроля оплат). Чтобы сделать всё максимально корректно с точки зрения внутренней логики 1С:УТ 11, правильно использовать встроенные функции конфигурации.
Напишем небольшую внешнюю обработку, которая будет выбирать проблемные документы и вызывать стандартный метод заполнения этапов оплат, заложенный разработчиками фирмы «1С» в общих модулях конфигурации. Нам понадобится следующий программный код:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РеализацияТоваровУслуг.Ссылка КАК Ссылка
|ИЗ
| Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
|ГДЕ
| РеализацияТоваровУслуг.Проведен = ЛОЖЬ
| И РеализацияТоваровУслуг.Дата МЕЖДУ &НачалоПериода И &КонецПериода";
Запрос.УстановитьПараметр("НачалоПериода", НачалоДня(Объект.ПериодНачала));
Запрос.УстановитьПараметр("КонецПериода", КонецДня(Объект.ПериодОкончания));
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
ДокументОбъект = Выборка.Ссылка.ПолучитьОбъект();
// Вызываем стандартный метод заполнения этапов оплаты по умолчанию.
// В зависимости от релиза конфигурации УТ 11 вызов может немного отличаться.
// Обычно используется вызов из модуля менеджера или специализированного общего модуля:
// Очищаем старые пустые или некорректные строки, если они есть
ДокументОбъект.ЭтапыГрафикаОплаты.Очистить();
// Заполняем этапы оплаты на основе соглашения, договора или правил по умолчанию
ОбработкаТабличныхЧастейУТ.ЗаполнитьЭтапыГрафикаОплаты(ДокументОбъект);
// Если автоматическое заполнение не вернуло строк (например, не задано соглашение),
// то заполняем вручную одну строку по умолчанию на 100% оплаты
Если ДокументОбъект.ЭтапыГрафикаОплаты.Количество() = 0 Тогда
НоваяСтрока = ДокументОбъект.ЭтапыГрафикаОплаты.Добавить();
НоваяСтрока.ВариантОплаты = Перечисления.ВариантыКонтроляОплаты.КредитПослеОтгрузки;
НоваяСтрока.ПроцентПлатежа = 100;
НоваяСтрока.СуммаПлатежа = ДокументОбъект.СуммаДокумента;
НоваяСтрока.ДатаПлатежа = ?(ЗначениеЗаполнено(ДокументОбъект.ЖелаемаяДатаОтгрузки), ДокументОбъект.ЖелаемаяДатаОтгрузки, ДокументОбъект.Дата);
КонецЕсли;
Попытка
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
ЗаписьЖурналаРегистрации("ОшибкиПереносаДанных", УровеньЖурналаРегистрации.Ошибка, , ,
"Не удалось провести документ: " + ДокументОбъект.Ссылка + " Описание ошибки: " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
Этот способ является наиболее безопасным и «чистым», так как он задействует стандартные механизмы проведения платформы и гарантирует, что в будущем у вас не «поплывут» отчеты по задолженности клиентов и платежному календарю. А для более комфортного контроля расчетов после миграции можно использовать ведомость по покупателям и поставщикам как в 1С 7.7.
Если вы находитесь на этапе тестирования переноса и планируете запускать перенос данных из 1С:ТиС 7.7 повторно, правильнее всего устранить первопричину ошибки в самих правилах конвертации объектов (ПКО). Для этого можно использовать готовые решения для переноса данных из 1С 7.7, где уже учтены требования современных конфигураций-приемников.
Для этого откройте ваши правила конвертации в программе «Конвертация данных 2.0», найдите ПКО для документов реализации и поступления и перейдите в обработчик события ПослеЗагрузки. Напишите там следующий скрипт:
// Код выполняется в контексте созданного объекта при загрузке в приемник (УТ 11)
Если Объект.ЭтапыГрафикаОплаты.Количество() = 0 Тогда
СтрокаОплаты = Объект.ЭтапыГрафикаОплаты.Добавить();
СтрокаОплаты.ВариантОплаты = Перечисления.ВариантыКонтроляОплаты.КредитПослеОтгрузки;
СтрокаОплаты.ПроцентПлатежа = 100;
СтрокаОплаты.СуммаПлатежа = Объект.СуммаДокумента;
// В качестве даты платежа можно использовать дату документа или плановую дату из источника
СтрокаОплаты.ДатаПлатежа = Объект.Дата;
КонецЕсли;
Данный подход полностью решает проблему «на лету». При загрузке документов в базу УТ 11 они сразу будут иметь заполненную табличную часть графика оплат, и последующее групповое проведение документов пройдет гладко без дополнительных обработок.
Если вам нужно провести документы «здесь и сейчас», а времени на написание кода или установку внешних обработок разработчика нет, можно попробовать ослабить контроль заполнения графиков платежей в настройках конфигурации. Обратите внимание, что доступность этой настройки зависит от релиза вашей 1С:УТ 11.
Выполним следующие действия:
Если база находится на замке (на поддержке) и вы не хотите вносить изменения в основную конфигурацию, но при этом проведение документов блокируется жестким кодом проверки, можно воспользоваться механизмом расширений (.cfe).
Создадим простое расширение, в котором перехватим процедуру проверки заполнения документов перед записью. В модуле объекта расширяемого документа (например, РеализацияТоваровУслуг) можно переопределить обработчик события ОбработкаПроверкиЗаполнение:
&Вместо("ОбработкаПроверкиЗаполнения")
Процедура Расш1_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
// Вызываем стандартный обработчик проверки
ПродолжитьВызов(Отказ, ПроверяемыеРеквизиты);
// Если проверка выявила ошибки, но мы проводим исторические данные,
// мы можем принудительно удалить из списка проверяемых реквизитов "ЭтапыГрафикаОплаты"
Индекс = ПроверяемыеРеквизиты.Найти("ЭтапыГрафикаОплаты");
Если Индекс <> Неопределено Тогда
ПроверяемыеРеквизиты.Удалить(Индекс);
КонецЕсли;
// Если отказ был вызван только отсутствием графика, сбрасываем его в Ложь
// (Потребуется детальный анализ причин Отказа в коде)
// Отказ = Ложь;
КонецПроцедуры
Использование расширений позволяет гибко управлять логикой проведения исторических документов без необходимости ручной модификации метаданных конфигурации-приемника.
Мы подробно проанализировали проблему отсутствия этапов графика оплаты при переносе документов из ТиС 7.7 в УТ 11. Подводя итог, дадим несколько практических рекомендаций:
ЭтапыГрафикаОплаты суммами документов.