Перенос данных из устаревших систем, таких как 1С:Торговля и Склад 7.7, в современные конфигурации на платформе 1С:Предприятие 8.3 (например, Управление торговлей 11), часто сопровождается техническими сложностями. Одной из наиболее распространенных проблем является невозможность проведения документов Приобретение товаров и услуг и Реализация товаров и услуг из-за ошибки: "Необходимо заполнить этапы графика оплаты".
В этой статье мы подробно разберем, почему возникает эта ошибка, как устроена структура хранения данных об оплате в УТ 11 и какими способами можно массово исправить документы, не прибегая к ручному перевыбору каждого из них.
Проанализируем ситуацию: в ТиС 7.7 реквизит ДатаПлатежа часто являлся простым полем в шапке документа. В 1С:УТ 11 логика взаиморасчетов значительно усложнилась. Теперь информация о планируемых платежах хранится не в одном реквизите, а в отдельной табличной части — ЭтапыГрафикаОплаты.
При типовом переносе данных через правила обмена информация из 7.7 может попасть в реквизиты объекта, но не инициализировать создание строк в этой табличной части. В результате мы видим пустые поля в форме документа, хотя при ручном нажатии кнопки "Записать" система сама подтягивает данные из Соглашения и заполняет таблицу. Наша задача — автоматизировать этот процесс для тысяч документов.
Рассмотрим наиболее эффективный метод. Стандартная обработка Групповое изменение реквизитов позволяет не только менять значения полей, но и выполнять произвольный код на языке 1С для каждого выбранного объекта. Это критически важно, так как нам нужно работать с табличной частью.
Выполним следующие шаги:
Реализация товаров и услуг или Приобретение товаров и услуг.В окне алгоритма нам необходимо написать код, который добавит строку в таблицу графика оплаты, если она пуста, и установит сумму, равную сумме документа. Разберем пример кода:
// Проверяем, если таблица этапов оплаты пуста
Если Объект.ЭтапыГрафикаОплаты.Количество() = 0 Тогда
// Добавляем новую строку
НоваяСтрока = Объект.ЭтапыГрафикаОплаты.Добавить();
НоваяСтрока.ВариантОплаты = Перечисления.ВариантыОплатыКлиентом.КредитПослеОтгрузки;
НоваяСтрока.ПроцентПлатежа = 100;
// Сумма платежа берется из суммы документа
НоваяСтрока.СуммаПлатежа = Объект.СуммаДокумента;
// Устанавливаем дату платежа (например, дата документа)
НоваяСтрока.ДатаПлатежа = Объект.Дата;
КонецЕсли;
Важный нюанс: при выполнении этого кода в контексте обработки Объект — это ссылка, доступная для записи. Использование метода Объект.Записать() внутри цикла обработки обычно не требуется, так как обработка сама записывает объект после выполнения алгоритма, если не указано иное.
В конфигурации Управление торговлей 11 заложены мощные механизмы автоматизации. Вместо ручного заполнения полей в коде, мы можем заставить систему "думать", что пользователь нажал кнопку заполнения. Для этого в том же "Произвольном алгоритме" можно вызвать экспортную процедуру модуля объекта.
Проанализируем ситуацию: если у документов заполнено Соглашение или Договор, в которых указаны правила оплаты, можно использовать встроенную функцию конфигурации:
// Вызываем типовой метод заполнения условий оплаты
Объект.ЗаполнитьУсловияОплаты();
// После этого система сама рассчитает этапы на основании настроек НСИ
Этот способ предпочтительнее, так как он соблюдает все бизнес-логики, заложенные разработчиками 1С, включая расчет дат отсрочки и учет праздничных дней, если это настроено в производственном календаре.
Выясним причину, почему документы требуют графики оплаты. Это зависит от функциональных опций в разделе НСИ и Администрирование — Продажи (Закупки) — Условия и порядок оплаты.
Если в системе установлен режим "Произвольное количество этапов оплаты", документы будут требовать заполнения таблицы в любом случае. Чтобы упростить переход, можно рассмотреть следующие действия:
Иногда даже после заполнения дат платежа документ не проводится с ошибкой: "Имеется просроченная задолженность", хотя по факту ее нет. Разберем, как это лечится.
Часто это связано с тем, что в системе числятся незакрытые старые Заказы клиентов. В УТ 11 заказы влияют на расчет взаиморасчетов (особенно в режиме Offline). Если по заказу была отгрузка, но статус заказа не изменен на "Закрыт", система может считать этот заказ "ожидающим оплаты" и выводить его в просрочку.
Рассмотрим решение через закрытие заказов:
Если вы столкнулись с ошибкой в самом коде запроса системы (как обсуждалось в Сообщении 22 форума), когда запросы "сваливают все заказы в кучу", может потребоваться небольшая корректировка в общем модуле ПродажиСервер (или аналогичном для вашей версии), чтобы запрос учитывал разрезы по конкретным заказам в остатках регистра РасчетыСКлиентами.
Подводя итог, при массовых ошибках с этапами графика оплаты после переноса:
ДатаПлатежа в шапке — в УТ 11 это поле часто является лишь отображением первой строки из таблицы этапов.ЭтапыГрафикаОплаты через групповое изменение.Применяя эти методы, мы сможем быстро привести перенесенную базу в рабочее состояние и избежать рутинного ручного исправления документов.