Переход с конфигурации «1С:Комплексная автоматизация» редакции 1.1 на версию 2.4 (и выше) — это не просто техническое обновление, а масштабный проект по полноценному внедрению новой системы. Радикальные различия в архитектуре этих решений часто приводят к тому, что после выполнения типового переноса пользователи обнаруживают «пустые» документы. Рассмотрим подробнее, почему заказы поставщикам и покупателям могут переноситься без табличных частей и как правильно подойти к решению этой задачи.
Проанализируем логику типового механизма переноса данных, разработанного фирмой «1С». Основная цель стандартных правил — перенос остатков на определенную дату, а не всей истории хозяйственных операций за предыдущие годы. В контексте заказов это означает следующее:
ЗаказПокупателя или ЗаказПоставщику создаются лишь для того, чтобы в регистрах накопления (например, «Расчеты с клиентами») было заполнено поле ОбъектРасчетов.Если специфика вашего бизнеса требует наличия номенклатурного состава в заказах (например, для доотгрузки по старым заказам уже в новой базе), стандартных средств будет недостаточно. Разберем основные пути решения задачи.
Способ 1: Использование «1С:Конвертация данных 2.1»
Для того чтобы принудительно перенести строки заказов, нам потребуется корректировка правил обмена (xml-файла). Проанализируем последовательность действий:
ЗаказПокупателя.ПередВыгрузкой, которое срабатывает только при определенных параметрах.Статус и ВариантОбеспечения, так как без них документ в КА 2.4 не проведется.Пример кода, который может потребоваться в обработчике ПриЗагрузке для установки значений по умолчанию, чтобы документы стали «рабочими»:
Объект.Статус = Перечисления.СтатусыЗаказовКлиентов.КВыполнению;
Для Каждого СтрокаТЧ Из Объект.Товары Цикл
СтрокаТЧ.ВариантОбеспечения = Перечисления.ВариантыОбеспечения.Отгрузить;
КонецЦикла;
Способ 2: Разработка дополнительной обработки
Если перенос уже выполнен и в базе присутствуют тысячи «пустых» заказов, проще написать обработку, которая через COM-соединение или XML-файл дозаполнит табличные части в новой базе, опираясь на уникальные идентификаторы (GUID) документов в старой базе. Выясним причину, почему это может быть эффективнее: вы не рискуете нарушить логику типового переноса остатков по регистрам, а лишь дополняете справочную информацию в документах.
Выясним, с какими еще сложностями мы столкнемся при попытке «оживить» перенесенные заказы. Перенос табличной части — это лишь верхушка айсберга.
В КА 1.1 справочник Контрагенты был единым. В КА 2.4 введена структура: Партнер (управленческая сущность) и Контрагент (юридическое лицо). При заполнении заказов важно правильно связать эти сущности. Если в заказе будет указан контрагент, не входящий в иерархию выбранного партнера, документ будет некорректным.
В новой архитектуре счета учета (60, 62, 41, 10) не выбираются в документах вручную. Проанализируем механизм: счета подтягиваются из ГФУ. Если при переносе номенклатуры или контрагентов эти группы не были заполнены или настроены, вы не сможете провести перенесенный заказ, даже если заполните в нем товары.
В КА 2.4 Вид номенклатуры определяет всё: является ли позиция товаром, услугой или работой, ведется ли по ней учет по характеристикам или сериям. При переносе данных из КА 1.1 часто происходит «сваливание» всей номенклатуры в один вид, что блокирует возможность корректного заполнения табличных частей заказов, если в оригинале использовались разные типы данных.
Чтобы минимизировать количество ошибок и «пустых» данных, выполним следующие шаги:
ЗаказыПокупателей и РасчетыСКонтрагентами.Подводя итог, отметим: если вы видите пустые табличные части в заказах — это сигнал о том, что система восприняла их как объекты расчетов по остаткам. Для полноценного переноса оперативных данных требуется либо кастомизация правил в Конвертации данных, либо использование дополнительных обработок для постобработки данных. Помните, что КА 2.4 требует гораздо более строгой настройки нормативно-справочной информации (НСИ) для проведения документов, чем ее предшественница.