Как избежать задвоения номенклатуры при переносе данных между базами 1С:УНФ?

Пользователь 1С v8.3 (Управляемые формы) 1С:Управление нашей фирмой Управленческий учет Торговля и дистрибуция
← На главную

При работе с несколькими базами 1С:Управление нашей фирмой (УНФ) пользователи часто сталкиваются с ситуацией, когда при переносе документов (например, Отчетов о розничных продажах или Чеков ККМ) справочник Номенклатура начинает «размножаться». Несмотря на то, что коды и наименования товаров в обеих базах абсолютно идентичны, программа создает дубликаты. Разберем подробно, почему это происходит и как решить проблему несколькими способами.

Первопричина проблемы: идентификаторы GUID

Прежде всего, проанализируем техническую сторону вопроса. В системе 1С каждый объект (карточка товара, контрагент, документ) обладает уникальным внутренним номером — GUID (Globally Unique Identifier). Это скрытая строка из 36 символов, которая является «настоящим именем» объекта для базы данных.

Когда мы используем стандартную обработку Выгрузка и загрузка данных XML, программа ищет объект в целевой базе именно по этому идентификатору. Если базы создавались независимо друг от друга, то даже у товара с кодом «00001» и названием «Болт» в разных базах будут разные GUID. При загрузке 1С не находит нужный GUID, считает товар новым и создает дубль. Если же мы отключаем выгрузку сопутствующих данных, программа выдает ошибку Объект не найден, так как документ ссылается на пустоту. Если такие ошибки уже засорили базу, поможет удаление движений с пустой ссылкой во всех регистрах накопления.

Решение 1: Использование типовой обработки «Поиск и удаление дублей»

Если данные за несколько лет уже загружены и справочник «раздут», нам поможет встроенный механизм очистки. Рассмотрим, как правильно им воспользоваться, чтобы не повредить документы.

  1. Перейдем в раздел Администрирование — Обслуживание — Корректировка данных — Поиск и удаление дублей.
  2. В поле «Искать в» выберем справочник Номенклатура.
  3. В правилах отбора укажем «Сравнивать по: Коду» (или Артикулу, если он уникален).
  4. После выполнения поиска система сгруппирует похожие позиции. На этом этапе важно правильно выбрать Образец.
  5. Важный нюанс: выбирайте в качестве оригинала тот элемент, который был создан в основной базе ранее или по которому уже накоплена большая история движений. Программа автоматически перенесет все ссылки из «неправильных» документов на выбранный оригинал и пометит дубли на удаление. Если стандартного функционала недостаточно для массовой чистки, может пригодиться универсальное удаление элементов справочников без пометки на удаление (использовать с осторожностью).

Решение 2: Загрузка данных через Excel с сопоставлением по коду

Этот метод идеально подходит для тех, кто не хочет погружаться в программирование. Вместо выгрузки через XML, мы будем использовать механизм загрузки из таблиц.

Проанализируем алгоритм действий:

  1. В базе-источнике (магазин) сформируем Универсальный отчет или отчет Продажи, содержащий все необходимые поля документов.
  2. Сохраним результат в файл Excel.
  3. В основной базе воспользуемся штатной обработкой или инструментом простая загрузка товаров из Excel, который позволяет перенести не только номенклатуру, но и цены, остатки и картинки.
  4. При настройке загрузки программа предложит выбрать Поле поиска. Установим галочку только напротив поля Код или Артикул.
  5. В этом случае 1С проигнорирует внутренние идентификаторы (GUID) и будет искать товар в справочнике по его коду. Если код найден — товар подставится в документ, если нет — создастся новый. Это исключает появление дублей при условии, что коды в базах синхронизированы.

Решение 3: Настройка правил в «Конвертации данных»

Если перенос данных требуется выполнять регулярно, стоит один раз настроить правила обмена. Для этого используется конфигурация Конвертация данных 2.0. Разберем по шагам, что нужно изменить в логике обмена:

В правилах выгрузки для справочника Номенклатура необходимо зайти в настройки ПКС (Правила конвертации свойств) и ПКО (Правила конвертации объектов).

Найдем параметр «Поиск». Нам нужно:

После этого при каждой загрузке XML-файла система будет сначала «спрашивать» базу: «Есть ли у тебя товар с таким кодом?». И только при отрицательном ответе будет создаваться новая запись.

Решение 4: Синхронизация ГУИДов и онлайн-обмен

Рассмотрим более продвинутый метод, который позволит использовать стандартную выгрузку XML без дублей в будущем. Мы можем программно «подтянуть» идентификаторы из одной базы в другую или настроить прямой обмен.

Для этого существуют внешние обработки (например, «Установка ссылок» или «Смена ГУИД»). Логика работы такова:

  1. Выгружаем из основной базы список номенклатуры с их GUID и Кодами.
  2. В магазинной базе запускаем обработку, которая находит товар по коду и принудительно меняет его внутренний GUID на тот, что в основной базе.
  3. Теперь объекты в обеих базах становятся «близнецами» для системы. Любой обмен через XML будет проходить бесшовно.

Альтернативным вариантом является синхронизация номенклатуры по протоколу HTTP, которая позволяет поддерживать актуальность реквизитов (строк, чисел, перечислений) между двумя базами УНФ в автоматическом режиме.

Переход на версию ПРОФ и использование РИБ

Поскольку планируется переход на версию 1С:УНФ ПРОФ, наиболее правильным стратегическим решением будет настройка РИБ (Распределенной информационной базы). Проанализируем преимущества этого подхода:

Завершающий этап: Восстановление последовательности

После того как мы перенесли данные и устранили дубли, критически важно восстановить правильность учета остатков и себестоимости. При массовой загрузке документов хронология может нарушиться.

Обязательно выполним групповое перепроведение документов:


// В интерфейсе УНФ это делается через:
// Настройки - Обслуживание - Корректировка данных - Перепроведение документов

Рекомендуем проводить документы помесячно, начиная с самой ранней даты загрузки. Это позволит системе корректно рассчитать остатки на складах и финансовый результат за все 3 года, которые не вносились в базу. Если после объединения дублей и перепроведения в остатках появились «минусы», значит, по некоторым позициям в магазинной базе продажи были оформлены на товар, которого фактически не было на остатке в основной базе. В этом случае потребуется универсальная корректировка остатков регистра накопления на дату начала учета.

Помните: всегда делайте резервную копию базы перед любыми манипуляциями со справочниками и массовой загрузкой данных!

← На главную