Как настроить продажу алкогольной продукции между собственными организациями в одной базе 1С:Бухгалтерия 3.0 через ЕГАИС?

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

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

Суть проблемы: конфликт сопоставления и уникальности FSRAR_ID

Для корректного взаимодействия с системой ЕГАИС в 1С каждая запись в справочнике Классификатор организаций ЕГАИС должна иметь тип сопоставления. Рассмотрим ситуацию, когда Организация А продает товар Организации Б:

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

Поскольку идентификатор FSRAR_ID должен быть уникальным, 1С не позволяет создать две разные записи в классификаторе с одинаковым кодом. В итоге пользователю приходится вручную менять сопоставление (то «С организацией», то «С контрагентом»), что крайне неудобно при регулярных операциях.

Решение №1: Техническое дублирование записи через обход проверки уникальности

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

Шаг 1: Создание временной записи

Создадим новую запись в справочнике Классификатор организаций ЕГАИС. В поле FSRAR_ID введем заведомо неверный код (например, добавим в конец реального кода символ «Х»). Выберем тип сопоставления «С контрагентом» и укажем соответствующего контрагента из нашей базы. Сохраним запись.

Шаг 2: Использование программной обработки или группового изменения

Теперь нам нужно вернуть корректный FSRAR_ID, игнорируя стандартную проверку уникальности формы. Для этого воспользуемся стандартной обработкой Групповое изменение реквизитов (раздел Администрирование — Обслуживание — Корректировка данных).

1. Выберем объект: Классификатор организаций ЕГАИС.
2. Добавим фильтр по нашей временной записи (например, по наименованию или по тому самому временному FSRAR_ID).
3. В колонке «Новое значение» для реквизита FSRAR_ID (Идентификатор ФСРАР) укажем правильный код.
4. Нажмем «Изменить реквизиты».

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

Решение №2: Использование механизма обособленных подразделений

Разберем альтернативный вариант, который подходит организациям с одним ИНН, но разными КПП. В системе ЕГАИС такие подразделения имеют разные FSRAR_ID.

В этом случае проблема уникальности не возникает. Выясним алгоритм настройки:

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

Настройка транспортных модулей (УТМ)

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

Если оба УТМ установлены на одном физическом сервере/компьютере, они должны работать на разных портах. Стандартный порт 8080 используется для первой организации, а для второй можно настроить, например, 8081.

В 1С перейдем в раздел Настройки обмена с ЕГАИС — Параметры подключения к ЕГАИС. Создадим две настройки:

// Настройка для Организации 1
Организация = "Организация А";
АдресУТМ = "127.0.0.1";
ПортУТМ = "8080";

// Настройка для Организации 2
Организация = "Организация Б";
АдресУТМ = "127.0.0.1";
ПортУТМ = "8081";

Такое разделение гарантирует, что при нажатии кнопки «Выполнить обмен» в 1С, запросы будут уходить в нужные транспортные модули, и входящие ТТН от «самого себя» будут загружаться корректно.

Анализ процесса «Интеркампани» в рамках БП 3.0

Посмотрим на процесс оформления самой сделки. Поскольку в 1С:Бухгалтерия 3.0 нет автоматизированного механизма «Интеркампани», как в 1С:УТ 11, последовательность действий будет следующей:

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

Важные замечания по безопасности и обновлениям

Использование метода программного изменения реквизитов (создание дублей FSRAR_ID) является «хаком» и требует осторожности. Проанализируем возможные риски:

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

Таким образом, мы выяснили, что наиболее стабильным и изящным способом решения задачи в рамках одной информационной базы является техническое создание двух записей в классификаторе организаций ЕГАИС с одинаковым FSRAR_ID, но разными типами сопоставления. Это позволяет автоматизировать процесс перепродажи алкоголя между своими фирмами без необходимости ежедневного ручного вмешательства в настройки системы.