Claude
e125973962
Modes: pre-project questionnaires, TZ/concept review, gap-analysis (typical/simple/complex customization), architecture selection (KA vs ERP vs UT), migration planning, BSL code/reports. References: KA 2.5 capabilities, ERP 2.5 diff, architecture patterns, TZ review checklist, customization catalog (ERF/EPF/MXL/CFE/BSP/config), migration plan template, questionnaire structure. Based on real project experience (ALREADICOM, MLRZ, Teplowin). Customization catalog adapted from 1C AI Development Kit (Arman Kudaibergenov).
10 KiB
10 KiB
Архитектурные паттерны 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
- По функциям: УТ (торговля) + Бухгалтерия (учёт) + ЗУП (зарплата)
- Гибрид: КА (оперативный учёт) + отдельная БП для РСБУ/МСФО
Плюсы:
- Изоляция: проблемы в одной базе не влияют на другие
- Параллельные регламентные операции
- Проще обновление (можно обновлять по одной)
Минусы:
- Синхронизация НСИ — главная проблема
- Дублирование данных, расхождения
- Сложнее консолидированная отчётность
- Выше стоимость сопровождения
Синхронизация НСИ между базами
Проблема: при многобазовой архитектуре справочники (номенклатура, контрагенты, договоры, подразделения) должны быть согласованы.
Решения:
- Типовой обмен данными (РИБ) — распределённая информационная база. Один мастер, все остальные подчинённые. Ограничения: только между одноимёнными конфигурациями.
- Планы обмена + правила обмена (КД 2) — Конвертация данных 2.0. Настраиваемые правила, работает между разными конфигурациями. Стандарт для связки «УТ ↔ Бухгалтерия».
- EnterpriseData (КД 3) — формат обмена на базе XML/JSON, более гибкий, но требует доработки для нетиповых объектов.
- Внешняя шина (RabbitMQ, Kafka) — для высоконагруженных сценариев с большим объёмом обменов. Избыточна для большинства SMB-проектов.
Рекомендация: если нет жёсткой необходимости в разделении — однобазовая архитектура. Каждая дополнительная база = дополнительные затраты на синхронизацию × всю жизнь системы.
3. Интеграция 1С ↔ Битрикс24
Типовые сценарии
| Процесс | Направление | Механизм |
|---|---|---|
| Лиды, сделки → заказы | Б24 → 1С | Модуль интеграции 1С-Битрикс24 (типовой) |
| Контрагенты | Двусторонний | Синхронизация справочника |
| Счета, оплаты | 1С → Б24 | Передача статусов по API |
| Каталог товаров | 1С → Б24 | Выгрузка номенклатуры |
| Документы (акты, счета) | 1С → Б24 | Присоединённые файлы по API |
Варианты интеграции
- Типовой модуль «1С + Битрикс24» — простейший вариант, ограниченный набор сущностей (контрагенты, заказы, счета, товары). Бесплатный, но негибкий.
- REST API Битрикс24 — полный контроль, любые сущности. Требует разработки обработки/расширения в 1С. Рекомендуется для нетиповых сценариев.
- Промежуточная шина (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
- Специализированные (СКК РЖД, ГИСП и др.) — требуют индивидуальной оценки