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