← На главную

Рассмотрим типовую архитектурную задачу: у компании открываются две розничные торговые точки и есть центральный склад, где работает компьютер управляющего. В наличии имеются конфигурации 1С:Розница 2.2 на точках и 1С:Бухгалтерия предприятия 3.0 на складе. Требуется настроить обмен данными так, чтобы видеть общие остатки, перемещать товары, назначать розничные цены и контролировать динамику продаж при возможных перебоях со связью.

Разберем типичные ошибки в планировании такой архитектуры и выясним, как правильно выстроить схему обмена на базе платформенных механизмов 1С.

Анализ архитектурных ограничений и ошибочных ожиданий

Проанализируем распространенное заблуждение: попытку возложить на конфигурацию 1С:Бухгалтерия предприятия 3.0 функции центра управления торговлей и товародвижением. На практике реализация исходных требований через прямое управление из бухгалтерии сталкивается со следующими ограничениями типовых механизмов:

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

Оптимальная схема: Центральный узел «Розницы» и РИБ

Разберем рекомендуемую и проверенную на практике модель организации учета. Для обеспечения бесперебойной работы касс при проблемах с интернетом используется механизм распределенной информационной базы (РИБ).

1. Создание главного узла «Розницы»: На компьютере управляющего (на центральном складе) разворачивается центральная база 1С:Розница 2.2. Именно она становится мастер-системой оперативного учета. Здесь создаются элементы справочника Номенклатура, регистрируются закупки, вводятся документы перемещения между общим складом и торговыми точками, а также оформляется установка розничных цен.
2. Организация РИБ на торговые точки: От центрального узла создаются подчиненные узлы для каждого магазина. Обмен происходит исключительно по схеме «Главный узел — Магазин 1» и «Главный узел — Магазин 2». При временном отсутствии интернета кассы продолжают стабильно пробивать чеки. Как только связь восстанавливается, происходит пакетная синхронизация.
3. Синхронизация с Бухгалтерией: Обмен данными с 1С:Бухгалтерия предприятия 3.0 настраивается только из центрального узла «Розницы». Периферийные узлы магазинов напрямую с БП 3.0 не взаимодействуют. В бухгалтерию выгружаются свернутые итоги розничных продаж, приходные накладные поставщиков и перемещения для формирования проводок регламентированного учета.

Выбор плана обмена для РИБ и видимость остатков

Рассмотрим, как решить вопрос видимости остатков на удаленных точках. В платформе 1С существует два варианта создания узлов РИБ:

1. План обмена «По магазинам»: Рекомендуемый типовой вариант. В базу конкретного магазина передаются документы и остатки только этой торговой точки. База кассы не перегружается лишними данными. Просмотр остатков на соседнем магазине или центральном складе в типовом функционале выполняется онлайн через специальные веб-сервисы центрального узла при наличии интернет-соединения.
2. План обмена «Полный»: Позволяет задублировать все регистры и документы всей сети на каждый локальный компьютер. В этом случае кассир видит чужие остатки даже при полном отсутствии связи. Однако этот подход имеет серьезные недостатки: резкое увеличение объема баз на кассах, замедление обменов, доступ линейного персонала к данным о чужой выручке и высокий риск возникновения коллизий при одновременном изменении документов.

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

Технические правила настройки обмена

Выясним ключевые технические требования, соблюдение которых предотвратит сбои синхронизации:

1. Префиксы информационных баз: Обязательно задаем уникальные префиксы во всех базах: в центральном узле Розницы (например, ЦБ), на магазинах (например, М1, М2) и в Бухгалтерии (например, БП). Если префиксы не назначены, номера документов и коды элементов справочников начнут дублироваться, что приведет к затиранию данных при синхронизации.
2. Порядок обновлений: При использовании РИБ обновление конфигурации сначала применяется в главном узле. Затем при обмене изменения передаются в периферийные базы. До тех пор пока подчиненный узел не запустится в режиме «Конфигуратор» и не применит принятые изменения структуры, прием оперативных данных в режиме «1С:Предприятие» блокируется.
3. Разграничение прав: Запрещаем создание и редактирование элементов справочника Номенклатура и документов установки цен на периферийных точках. Вся нормативно-справочная информация должна формироваться строго в главном узле.