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).
142 lines
10 KiB
Markdown
142 lines
10 KiB
Markdown
# Архитектурные паттерны 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
|
|
- Специализированные (СКК РЖД, ГИСП и др.) — требуют индивидуальной оценки
|