При масштабировании бизнеса владельцы магазинов часто сталкиваются с ситуацией, когда торговые точки работают в разных информационных базах 1С:Розница (базовая версия), но при этом имеют один общий ИНН. Основная сложность возникает при настройке электронного документооборота (ЭДО), когда поставщик настаивает на отправке всех документов на один идентификатор (ID). Разберем подробно, почему схема «один ID на три базы» является проблемной, к каким техническим последствиям она приводит и как правильно настроить работу в такой ситуации.
Для начала проанализируем, как происходит процесс получения документов в сервисе 1С-ЭДО. Когда пользователь в программе нажимает кнопку «Отправить и получить», 1С отправляет запрос на сервер оператора (например, «Калуга Астрал»). Сервер ищет новые пакеты документов, привязанные к конкретному идентификатору ЭДО, и передает их в базу 1С.
Важно понимать критическую особенность: как только сервер оператора передал документ в информационную базу, он помечает этот пакет как «Доставленный». Рассмотрим, что произойдет в случае с тремя независимыми базами:
Таким образом, возникает жесткая конкуренция между базами. Документы будут распределяться случайным образом — в зависимости от того, кто первый нажал кнопку получения. Поскольку базы 1С:Розница (базовая) не связаны между собой и не имеют механизмов синхронизации (РИБ), документы, попавшие в одну базу, никогда не появятся в другой автоматически.
Электронный документооборот — это не просто пересылка PDF-файла. Это сложная цепочка обмена служебными сообщениями. Когда вы получаете УПД, ваша программа должна автоматически отправить поставщику ИзвещениеОПолучении, а после проверки — ТитулПокупателя (подпись).
Если Магазин №1 загрузил документ, предназначенный Магазину №2, цепочка обмена инициируется в первой базе. Даже если вы физически передадите файл XML во вторую базу, вы не сможете корректно завершить документооборот, так как идентификаторы сессий и квитанции будут принадлежать разным информационным системам. Это создаст юридические риски: документ будет считаться неподписанным или подписанным с нарушением регламента, что критично при налоговых проверках. Для контроля регламентных цепочек и выявления незавершенных обменов подойдет отчет для отслеживания состояния документов ЭДО.
Часто поставщики заявляют, что могут работать только с одним ID на один ИНН. Выясним причину такой позиции. Чаще всего это связано с ограничениями в их собственной учетной системе или нежеланием сотрудников заводить новые карточки контрагентов для каждого филиала.
С точки зрения законодательства и технических стандартов ЭДО: организация (один ИНН) имеет право регистрировать неограниченное количество идентификаторов. Каждый магазин может иметь свой уникальный ID, даже если у них общий КПП. Если же у магазинов разные КПП (обособленные подразделения), то разделение по разным ID является стандартной практикой.
Рассмотрим несколько сценариев выхода из ситуации, от наиболее правильных до компромиссных.
Это самый надежный способ. Вам необходимо зарегистрировать в сервисе 1С-ЭДО три отдельных учетных записи (три разных ID) на один и тот же ИНН.
Преимущество: Полная автоматизация, отсутствие путаницы, юридическая чистота подписей.
Если поставщик категорически отказывается слать на разные ID, можно применить схему с центральным узлом. Создается одна дополнительная информационная база 1С (например, 1С:Бухгалтерия или даже еще одна 1С:Розница), которая будет служить «шлюзом».
Важно: Подписывать документы в таком случае придется в той же центральной базе, где они были получены, чтобы не разорвать цепочку электронных подписей. Для загрузки переданных файлов XML в базы магазинов можно использовать обработку загрузки документов ЭДО в поступления 1С:Розница.
Некоторые операторы ЭДО (включая тех, что работают через 1С-ЭДО) позволяют настроить распределение входящих документов внутри одного личного кабинета. Это может работать по признаку КПП или по АдресуДоставки, указанному в тегах XML-файла. Однако это требует сложной настройки со стороны техподдержки оператора и часто недоступно в стандартном функционале базовых версий 1С.
Проанализируем ситуацию с точки зрения программного продукта. В 1С:Розница (базовая) отключена возможность использования распределенных информационных баз (РИБ). Если бы вы использовали версию ПРОФ, проблема решалась бы проще: все документы ЭДО загружались бы в главный узел и автоматически разлетались по магазинам через стандартный обмен данными.
Поскольку в базовой версии базы изолированы, использование одного ID неизбежно приведет к хаосу. Вы не сможете гарантировать, что документ попадет именно в ту базу, где числится остаток этого товара.
Разберем по шагам, что нужно сделать прямо сейчас:
Итог: Не пытайтесь использовать один идентификатор в трех независимых базовых версиях 1С. Это приведет к потере документов, невозможности корректного подтверждения приемки и проблемам с сопоставлением номенклатуры. Единственный стабильный путь — разделение идентификаторов или переход на версию ПРОФ с организацией единого центра загрузки документов.