Как организовать учет алкогольной продукции в нескольких магазинах ИП в 1С:Розница?

При автоматизации розничной торговли алкоголем (пиво, сидр, медовуха и другая слабоалкогольная продукция) для индивидуальных предпринимателей (ИП) часто возникает методологическая и техническая сложность. Если у ИП открыто две или более торговые точки, типовые механизмы конфигурации 1С:Розница при стандартной настройке связывают учетную запись ЕГАИС только с одним магазином. Разберем причины такого поведения системы, проанализируем ограничения ЕГАИС и типовых конфигураций 1С, а также рассмотрим проверенные сценарии решения этой задачи.

Причины проблемы: архитектура ЕГАИС и модель 1С

Для юридических лиц (ООО) каждое обособленное подразделение имеет свой уникальный КПП и отдельный идентификатор FSRAR_ID. В этом случае на каждую точку устанавливается свой универсальный транспортный модуль (УТМ), а в 1С настраивается однозначное соответствие между магазином и организацией ЕГАИС.

Для индивидуальных предпринимателей ситуация иная:

1. Отсутствие КПП: По законодательству ИП имеет единый ИНН и может использовать один сертификат электронной подписи и один УТМ для работы со слабоалкогольной продукцией на всех своих объектах.
2. Общий остаток в ЕГАИС: Сервер ЕГАИС хранит все остатки продукции в разрезе одного кода FSRAR_ID, без автоматического деления по фактическим магазинам.
3. Ограничение типовой конфигурации: В справочнике ОрганизацииЕГАИС и регистре сведений НастройкиОбменаЕГАИС программа требует жестко закрепить за конкретным УТМ только один торговый объект (магазин или склад).

В результате при стандартной настройке все входящие товарно-транспортные накладные (ТТН ЕГАИС) поступают на один назначенный магазин, а обработка корректировки остатков сопоставляет сводный остаток из ЕГАИС только с учетными данными этого одного магазина, создавая искусственные расхождения.

Способ 1. Схема с «Виртуальным магазином» (типовой вариант без доработок)

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

Разберем по шагам порядок настройки и работы:

1. Создание служебного магазина: В справочнике Магазины создаем виртуальный объект, например «Склад ЕГАИС (Центральный)».
2. Привязка УТМ: В настройках обмена с ЕГАИС привязываем единственный УТМ и соответствующий элемент справочника ОрганизацииЕГАИС к созданному виртуальному магазину.
3. Приемка ТТН: Все входящие электронные накладные ЕГАИС загружаются и подтверждаются на «Склад ЕГАИС». На этом этапе алкоголь юридически и фактически числится на основном остатке ИП.
4. Внутреннее перемещение: Распределение продукции по реальным торговым точкам оформляется типовым документом ПеремещениеТоваров между виртуальным складом и нужным магазином. Так как перемещение алкоголя между точками одного ИП не требует фиксации в ЕГАИС, накладная формируется исключительно для управленческого учета в 1С.
5. Списание реализованной продукции: Продажи (или вскрытия кегов/тары) фиксируются на кассах магазинов. Формирование исходящих актов списания в ЕГАИС выполняется централизованно от имени «Склада ЕГАИС» на основании сводных данных отчетов о розничных продажах.

Способ 2. Получение отдельных FSRAR_ID на каждое место деятельности

Если требуется вести полностью независимый учет по каждой точке без перемещений внутри 1С, проанализируем вариант разделения на уровне самого ЕГАИС.

В личном кабинете ФСРАР индивидуальный предприниматель имеет право добавить несколько мест осуществления деятельности по фактическим адресам магазинов. При этом каждому адресу присваивается отдельный FSRAR_ID.

Порядок работы при таком подходе:

1. Регистрируем адреса торговых точек в ЛК ЕГАИС и получаем отдельные коды ФСРАР.
2. Для каждого магазина настраиваем собственный УТМ (на отдельных компьютерах или через разные порты).
3. В 1С:Розница в справочнике ОрганизацииЕГАИС создаем отдельную запись под каждый FSRAR_ID и привязываем ее к соответствующему реальному магазину.
4. Уведомляем поставщиков, чтобы отгрузка на конкретную точку производилась строго на присвоенный ей FSRAR_ID.

Способ 3. Организация работы в распределенной информационной базе (РИБ)

Если учет ведется в распределенной базе данных (РИБ по магазинам), модуль обмена с ЕГАИС целесообразно настраивать только в центральном узле.

1. На узлах магазинов прямой обмен с УТМ отключается.
2. Кассы точек фиксируют продажи и передают документы через штатный обмен РИБ в центральную базу.
3. Центральная база принимает входящие ТТН, аккумулирует отчеты о продажах со всех узлов и отправляет регламентные акты списания в ЕГАИС по единому УТМ.

Особенности сверки и корректировки остатков

Выясним причину сложностей при инвентаризации: если у ИП используется один FSRAR_ID, запрос остатков из ЕГАИС возвращает общую сумму алкоголя по всем точкам вместе взятым. Чтобы корректно выполнить сверку, придерживаемся следующих правил:

1. Проводим инвентаризацию одновременно на всех торговых точках ИП.
2. Суммируем учетные остатки по всем магазинам в 1С.
3. Сравниваем полученную сумму с данными из регистра ЕГАИС.
4. Внутренние расхождения между точками выравниваем типовыми документами ОприходованиеТоваров, СписаниеТоваров или ПеремещениеТоваров внутри 1С без отправки корректирующих запросов в ЕГАИС по каждой отдельной точке.

Программная корректировка маршрутизации ТТН

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

Для этого в расширении или конфигурации создается подписка на событие ПередЗаписью для документа ТТНВходящаяЕГАИС:

// Пример назначения магазина при загрузке ТТН ЕГАИС
Процедура ПриОбработкеТТНПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт

    Если Источник.ЭтоНовый() Тогда
        // Определение нужного магазина по адресу доставки или комментарию
        НужныйМагазин = НайтиМагазинПоРеквизитам(Источник);
        Если ЗначениеЗаполнено(НужныйМагазин) Тогда
            Источник.Магазин = НужныйМагазин;
        КонецЕсли;
    КонецЕсли;

КонецПроцедуры

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