Рассмотрим распространенную практическую задачу: в компании функционируют две торговые точки на конфигурации «1С:Розница». Долгое время они работали абсолютно автономно, учет велся в двух независимых информационных базах. Теперь бизнес вырос, и возникла необходимость объединить их в единую сеть с общей базой и настроить синхронизацию данных (РИБ).
В этой статье мы подробно разберем, как решить эту задачу с минимальными трудозатратами, избежав критических ошибок, лавины дублирующихся товаров и рассинхронизации остатков.
Прежде чем приступать к техническим манипуляциям, проанализируем, почему простое объединение данных «в лоб» приведет к катастрофе в учете. Дело в уникальных идентификаторах объектов (GUID).
В системе «1С:Предприятие» каждый элемент любого справочника (будь то товар «Молоко» или контрагент «Поставщик») обладает скрытым 128-битным идентификатором — GUID. Поскольку базы на торговых точках работали независимо, один и тот же товар в базе А и базе Б имеет разные GUID, даже если их наименования, артикулы и штрихкоды абсолютно идентичны.
Если мы попытаемся настроить стандартный обмен РИБ или перенесем документы стандартной обработкой «Выгрузка и загрузка данных XML», платформа создаст дублирующие карточки товаров и контрагентов. Для системы это будут разные объекты. В результате мы получим задвоение справочников, пересортицу и неверный расчет себестоимости.
Выясним, какие существуют стратегии решения этой проблемы, и разберем по шагам каждую из них.
Если накопленная история продаж и движений документов на второй точке за прошлые периоды не критична для оперативного учета, этот способ сэкономит недели кропотливой работы по очистке данных.
Рассмотрим пошаговый алгоритм внедрения этого сценария:
РегистрацияЗемельныхУчастков или специализированные документы ВводНачальныхОстатковУзла по результатам инвентаризации.Этот подход гарантирует 100% отсутствие дублей и легкий старт, однако у него есть недостаток — потеря истории движений по точке Б в новой системе.
Если бизнес-требования обязывают сохранить все документы движения за прошлые периоды из обеих баз, нам придется выполнить слияние данных. Разберем этот сложный процесс по этапам.
Перед переносом документов необходимо исключить конфликты номеров и кодов. В противном случае документ «Реализация товаров №1» из базы Б при загрузке затрет документ «Реализация товаров №1» в базе А.
В настройках обеих баз задаем уникальные префиксы (например, «А» и «Б»). После этого необходимо запустить обработку «Изменение номеров документов и кодов справочников» (или написать групповое изменение реквизитов), чтобы добавить префиксы ко всем уже существующим историческим документам и кодам справочников.
Забудьте про стандартный перенос по GUID. Нам потребуется использовать инструмент «Конвертация данных» (КД 2.0 или КД 3.0) или специализированные универсальные обработки обмена данными с поиском по реквизитам.
При настройке правил обмена для ключевых справочников мы должны отключить стандартный поиск по идентификатору и задать четкие правила сопоставления:
Штрихкод, Артикул или по точному совпадению Наименование.ИНН + КПП.Даже при самом качественном сопоставлении часть элементов задвоится из-за человеческого фактора (например, в одной базе завели «Молоко 3.2%», а во второй — «Молоко 3,2%» через запятую).
После слияния всех данных в базу А запускаем стандартный инструмент ПоискИУдалениеДублей (раздел Администрирование — Обслуживание). Эта обработка не просто физически удаляет дубли, но и выполняет важнейшую операцию: находит все ссылки на дублирующий элемент во всех проведенных документах и регистрах и корректно перенаправляет их на оригинальный элемент.
Если база А после слияния весит десятки гигабайт, стандартная процедура генерации начального образа РИБ через конфигуратор может зависнуть или выполняться несколько суток. В этом случае применим недокументированный, но крайне эффективный метод создания узла из копии информационной базы.
Рассмотрим по шагам, как реализовать этот метод:
// Указываем системе, что данная база является подчиненным узлом РИБ
ПланыОбмена.УстановитьГлавныйУзел(ПланыОбмена.ПоМагазинам.НайтиПоКоду("Код_Главного_Узла_Базы_А"));
Проанализируем технические альтернативы классическому РИБ, которые могут существенно упростить администрирование системы в будущем.
Вариант с тонким клиентом (веб-сервер): Если на торговых точках присутствует стабильный проводной интернет, самым надежным решением будет отказ от РИБ в пользу работы в единой базе. База разворачивается на сервере (или в облаке), а кассиры подключаются через тонкий клиент или веб-браузер.
Плюсы очевидны: актуальные остатки видны в режиме реального времени, нет задержек обмена, а обновление конфигурации выполняется всего один раз на сервере.
Синхронизация через формат EnterpriseData: Вместо жесткого РИБ-обмена можно настроить синхронизацию через универсальный формат данных.
При таком подходе базы остаются независимыми, но обмениваются данными по расписанию. Главное преимущество — интерактивный помощник сопоставления данных, который при первой синхронизации позволяет вручную увязать сомнительные позиции справочников, предотвращая появление дублей. Кроме того, базы могут обновляться асинхронно, обмен не заблокируется, если на одной из точек конфигурация обновилась раньше.
Если вы выбрали вариант работы через РИБ, но кассирам на точках критически важно знать актуальные остатки товаров у коллег, используйте встроенный механизм Информативных остатков.
В настройках РИБ «По магазинам» можно отключить передачу тяжелых документов продаж между узлами (они будут уходить только в центральный офис), но настроить ежечасную выгрузку легкого регистра сведений ИнформативныеОстатки. В этом случае кассир прямо в рабочем месте кассира (РМК) при подборе товара сможет увидеть актуальный остаток этой позиции в соседнем магазине, не перегружая каналы связи тяжелым документооборотом.