# Архитектурные паттерны 1С: выбор конфигурации и топологии

---

## 1. Выбор конфигурации

### Матрица выбора

| Критерий | КА 2.5 | ERP 2.5 | УТ 11 + Бухгалтерия |
|----------|--------|---------|---------------------|
| **Масштаб** | До 200 пользователей | 200+ пользователей | До 50 пользователей |
| **Производство** | Простое (сборка, комплектация) | Полное (MRP, MES, попередельное, позаказное) | Нет |
| **Бюджетирование** | Конструктор (без workflow) | Конструктор + бюджетный процесс (workflow) | Нет |
| **Казначейство** | Полное | Полное | Нет |
| **Управленческий учёт** | Полный (НД, ЦФО, фин.результат) | Полный + расширенный | Ограниченный |
| **Зарплата** | Встроенная | Встроенная | Нет (отдельно ЗУП) |
| **Стоимость лицензии** | Средняя | Высокая | Низкая |
| **Сложность внедрения** | Средняя | Высокая | Низкая |

### Когда КА 2.5

- Компания 50-200 сотрудников, нужен единый контур: торговля + бухгалтерия + зарплата + бюджетирование
- Производство простое или отсутствует
- Нет потребности в MRP/MES
- Бюджетный workflow не критичен (можно согласовывать через Битрикс24)
- Типичные клиенты: ИТ-интеграторы, торговые компании, сервисные компании

### Когда ERP 2.5

- Производственное предприятие со сложным планированием
- Нужен полный бюджетный процесс с маршрутами согласования внутри 1С
- Масштаб 200+ пользователей
- Требуется MRP (планирование потребности в материалах)
- Типичные клиенты: заводы, крупные производства, холдинги

### Когда УТ 11 + Бухгалтерия

- Торговая компания, бюджетирование и управленческий учёт не нужны
- Малый бизнес, до 50 пользователей
- Минимальная стоимость внедрения
- Зарплата — отдельно (ЗУП или аутсорсинг)

---

## 2. Однобазовая vs многобазовая архитектура

### Однобазовая (одна информационная база)

**Плюсы:**
- Единая точка правды — нет проблем с синхронизацией
- Проще администрирование
- Проще разграничение доступа (RLS внутри одной базы)
- Быстрее внедрение

**Минусы:**
- Риск «тяжёлой» базы при большом объёме данных
- Все пользователи зависят от доступности одной базы
- Регламентные операции (закрытие месяца) блокируют работу

**Когда выбирать:** одно юрлицо или группа компаний с единой учётной политикой, до 200 пользователей.

### Многобазовая (несколько информационных баз)

**Типовые варианты:**
- **По юрлицам:** каждое юрлицо в отдельной базе КА/ERP
- **По функциям:** УТ (торговля) + Бухгалтерия (учёт) + ЗУП (зарплата)
- **Гибрид:** КА (оперативный учёт) + отдельная БП для РСБУ/МСФО

**Плюсы:**
- Изоляция: проблемы в одной базе не влияют на другие
- Параллельные регламентные операции
- Проще обновление (можно обновлять по одной)

**Минусы:**
- Синхронизация НСИ — главная проблема
- Дублирование данных, расхождения
- Сложнее консолидированная отчётность
- Выше стоимость сопровождения

### Синхронизация НСИ между базами

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

**Решения:**
1. **Типовой обмен данными (РИБ)** — распределённая информационная база. Один мастер, все остальные подчинённые. Ограничения: только между одноимёнными конфигурациями.
2. **Планы обмена + правила обмена (КД 2)** — Конвертация данных 2.0. Настраиваемые правила, работает между разными конфигурациями. Стандарт для связки «УТ ↔ Бухгалтерия».
3. **EnterpriseData (КД 3)** — формат обмена на базе XML/JSON, более гибкий, но требует доработки для нетиповых объектов.
4. **Внешняя шина (RabbitMQ, Kafka)** — для высоконагруженных сценариев с большим объёмом обменов. Избыточна для большинства SMB-проектов.

**Рекомендация:** если нет жёсткой необходимости в разделении — однобазовая архитектура. Каждая дополнительная база = дополнительные затраты на синхронизацию × всю жизнь системы.

---

## 3. Интеграция 1С ↔ Битрикс24

### Типовые сценарии

| Процесс | Направление | Механизм |
|---------|-------------|----------|
| Лиды, сделки → заказы | Б24 → 1С | Модуль интеграции 1С-Битрикс24 (типовой) |
| Контрагенты | Двусторонний | Синхронизация справочника |
| Счета, оплаты | 1С → Б24 | Передача статусов по API |
| Каталог товаров | 1С → Б24 | Выгрузка номенклатуры |
| Документы (акты, счета) | 1С → Б24 | Присоединённые файлы по API |

### Варианты интеграции

1. **Типовой модуль «1С + Битрикс24»** — простейший вариант, ограниченный набор сущностей (контрагенты, заказы, счета, товары). Бесплатный, но негибкий.
2. **REST API Битрикс24** — полный контроль, любые сущности. Требует разработки обработки/расширения в 1С. Рекомендуется для нетиповых сценариев.
3. **Промежуточная шина (n8n, Apache Camel)** — для сложных трансформаций и маршрутизации. Оправдана при 5+ системах в ландшафте.

### Разграничение ответственности

**Правило:** «воронка продаж и клиентская работа — в Битрикс24, учёт и финансы — в 1С».

| Область | Где ведётся | Что передаётся |
|---------|-------------|----------------|
| CRM, лиды, сделки | Битрикс24 | Реквизиты контрагента + параметры сделки → 1С |
| Заказы покупателей | 1С | Факт формирования заказа ← из Б24 |
| Выставление счетов | 1С | PDF счёта → в Б24 к сделке |
| Оплата | 1С | Статус оплаты → в Б24 |
| Отгрузка | 1С | Статус отгрузки → в Б24 |
| Воронка, конверсия, LTV | Битрикс24 | — (не дублировать в 1С) |

---

## 4. Интеграция с внешними системами

### ЭДО (СБИС, Диадок, 1С-ЭДО)
- Типовая — через модуль «1С-ЭДО» (DirectBank-подобный протокол)
- СБИС — через внешнюю обработку от вендора, уточнять версию и перечень документов
- При экспертизе ТЗ: «установка модуля СБИС» — недостаточное описание, нужен перечень типов документов, версия модуля, объём настройки

### Банки (DirectBank)
- Типовой — протокол DirectBank, поддерживается большинством банков
- При многобазовой архитектуре: подключать к каждой базе с учётом юрлица

### Государственные системы
- ФНС (электронная отчётность) — через типовые механизмы регламентированной отчётности
- ФГИС (Меркурий, Честный ЗНАК, ЕГАИС) — через типовые подсистемы в КА/ERP
- Специализированные (СКК РЖД, ГИСП и др.) — требуют индивидуальной оценки