Переход с конфигурации 1С:Розница 2.3 на 1С:Розница 3.0 — это не просто обновление версии, а полноценная миграция на новую архитектуру. Редакция 3.0 построена на базе 1С:Управление нашей фирмой (УНФ), что вносит существенные различия в логику хранения цен, данных о контрагентах и бонусных программах. Рассмотрим подробно, почему возникают ошибки при переносе и как их эффективно устранить.
Часто при стандартном переходе пользователи замечают, что в созданном документе УстановкаЦенНоменклатуры присутствует только розничная цена, а закупочная отсутствует вовсе. Разберем причины этого явления.
Проанализируем работу Помощника перехода. В «Рознице 2.3» при запуске выгрузки существует неочевидный момент в настройках. Если в помощнике не активирована опция «Выгружать все виды цен», программа по умолчанию берет только ту цену, которая помечена как основная для продажи. В результате в XML-файл выгрузки попадают метаданные (названия) типов цен, но сами числовые значения для «Закупочной» игнорируются.
Выясним вторую причину: разница в способах задания цены. В редакции 3.0 (УНФ) закупочная цена часто привязана к прайс-листам поставщиков. Если в старой базе вид цены «Закупочная» не был сопоставлен с конкретным поставщиком или не был помечен как «статический» при выгрузке, алгоритм переноса может «растеряться» и создать пустую строку.
Посмотрим на ситуацию, когда розничная цена в документе есть, но она не фиксируется в программе и не отображается в карточке товара. Это происходит из-за механизма зависимых цен.
В «Рознице 2.3» розничная цена часто рассчитывается как Закупочная + Наценка. При переносе в версию 3.0 этот механизм сохраняется через динамические виды цен. Проанализируем логику: если документ УстановкаЦенНоменклатуры не содержит базовую (закупочную) цену, то расчетная (розничная) цена превращается в ноль или не может быть рассчитана «на лету».
Чтобы исправить это, проделаем следующие шаги в «Рознице 3.0»:
ВидыЦен.ЦеныНоменклатуры их можно будет использовать.Разберем, почему при миграции «теряются» владельцы карт и их штрихкоды. В старой редакции владельцем дисконтной карты являлось Физическое лицо. В новой архитектуре «Розницы 3.0» обязательным является наличие Контрагента (участника программы лояльности).
Рассмотрим алгоритм сбоя: при переносе программа создает физлицо, но не всегда автоматически создает связанного контрагента с ролью «Покупатель». Без этой связки документ ДисконтнаяКарта создается «битым» или обезличенным. Также обратим внимание на штрихкоды. В 2.3 они могли храниться в общем регистре сведений, а в 3.0 они должны быть четко привязаны к реквизиту карты или специализированному справочнику кодов SKU.
Для решения проблемы с картами мы рекомендуем:
ФизЛица -> Контрагенты.Проанализируем ситуацию, когда необходимо перенести несколько видов цен одновременно. Если стандартный обмен не справляется, выполним следующие действия:
Шаг 1. Подготовка в исходной базе (2.3). Проверим, чтобы все цены, которые мы хотим перенести, были актуальны на дату выгрузки. Если цена установлена «вчера», а дата переноса «сегодня», убедимся, что нет пересекающихся документов.
Шаг 2. Настройка соответствия. В «Рознице 3.0» создадим виды цен с идентичными названиями. Важно, чтобы Идентификатор вида цены совпадал. Посмотрим на пример настройки программного поиска (для разработчиков):
// Пример поиска вида цены по наименованию при загрузке
ВидЦеныОбъект = Справочники.ВидыЦен.НайтиПоНаименованию("Закупочная");
Если ВидЦеныОбъект.Пустая() Тогда
Сообщить("Необходимо создать вид цены в целевой базе!");
КонецЕсли;
Шаг 3. Использование внешней обработки. Если штатный помощник игнорирует закупочную цену, попробуем изменить способ задания цены в исходной базе перед выгрузкой. Установим для всех цен способ «Заполнять по данным ИБ при поступлении» на «Задавать вручную». Это заставит выгрузку поместить жесткие значения в XML-файл.
Выясним, почему не переносятся бонусы. В версии 3.0 за остатки бонусов отвечает документ ВводНачальныхОстатков с типом операции «Бонусы». Если при переходе этот документ пуст, проанализируем состояние регистра БонусыЛояльности в старой базе.
Важный момент: если в «Рознице 2.3» остались нерассчитанные бонусные движения (например, не проведены документы начисления бонусов или есть отложенные чеки), остаток может быть перенесен некорректно. Перед миграцией обязательно выполним регламентные операции по закрытию смен и расчету бонусных баллов.
Подводя итог, отметим, что большинство проблем вызвано тем, что «Розница 3.0» ожидает более строгую структуру данных, чем ее предшественница.
Основные рекомендации для успешного завершения перехода:
Контрагенты.Рассмотренные методы помогут вам преодолеть архитектурный барьер между редакциями, сохранить целостность данных и выполнить корректную настройку торгового места на базе РМК.