feat: add 1c-analyst skill — 1С business analyst for pre-project, gap-analysis, TZ review, migration planning

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).

1c-analyst/references/architecture-patterns.md

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

1c-analyst/references/customization-catalog.md

@@ -0,0 +1,232 @@
+# Каталог типов доработок 1С
+
+> Маппинг: тип доработки → выходной артефакт → трудозатраты → риск обновления.
+> Использовать при gap-анализе для оценки каждой нетиповой функции,
+> а также при проектировании конкретной доработки.
+>
+> Источник базовой классификации: 1C AI Development Kit (Arman Kudaibergenov), адаптация.
+
+---
+
+## Приоритет выбора подхода
+
+От безопасного к рискованному. Каждый шаг «глубже» = выше стоимость сопровождения
+на весь жизненный цикл системы. Всегда выбирать минимально инвазивный подход.
+
+```
+1. Типовая настройка (параметры, справочники, доп. реквизиты через УФ)
+   ↓ если невозможно
+2. Внешний отчёт (ERF) / внешняя обработка (EPF) по существующим регистрам
+   ↓ если невозможно
+3. Расширение конфигурации (CFE) — перехват событий, доп. формы, модификация
+   ↓ если невозможно
+4. Дополнительная обработка через механизмы БСП (подключаемые команды, доп. отчёты)
+   ↓ если невозможно
+5. Изменение конфигурации (снятие с поддержки) — крайний случай
+```
+
+---
+
+## Шкала сложности доработки
+
+| Уровень | Объём | Ориентир трудозатрат | Типичные артефакты |
+|---------|-------|---------------------|--------------------|
+| **S** | Точечное изменение, 1-2 объекта | 4–16 ч | Внешний отчёт, печатная форма, доп. реквизит |
+| **M** | Несколько связанных объектов | 16–80 ч | Расширение CFE, новый документ + формы + права |
+| **L** | Новая подсистема или интеграция | 80–240 ч | Комплект: документы + регистры + отчёты + роли + тесты |
+| **XL** | Архитектурные изменения ядра | 240+ ч | Изменение типовых регистров, переделка логики проведения |
+
+---
+
+## Типы доработок: детальный каталог
+
+### 1. Внешний отчёт (ERF)
+
+**Артефакт:** файл `.erf` — отчёт на базе СКД или произвольный
+**Когда:** нужен отчёт, данные для которого уже есть в регистрах, но типового отчёта нет
+**Риск обновления:** нулевой — внешний файл, не затрагивает конфигурацию
+**Уровень:** обычно S (8–16 ч)
+
+**Примеры:**
+- Aging дебиторской задолженности (по регистру взаиморасчётов)
+- EBITDA (по регистру доходов и расходов)
+- P&L по проектам с рентабельностью (по НД)
+- Сводка план/факт в нетиповом разрезе
+
+**Структура артефакта:**
+```
+ВнешнийОтчёт
+├── Макет СКД (схема компоновки данных)
+│   ├── Набор данных — запрос к регистрам
+│   ├── Вычисляемые поля
+│   ├── Ресурсы (итоги)
+│   └── Настройки (группировки, отборы, оформление)
+└── Форма отчёта (опционально — для доп. параметров)
+```
+
+### 2. Внешняя обработка (EPF)
+
+**Артефакт:** файл `.epf` — обработка для массовых операций, загрузок, сервисных задач
+**Когда:** нужна автоматизация рутины, не покрытая типовым функционалом
+**Риск обновления:** нулевой (внешний файл)
+**Уровень:** S–M (8–40 ч)
+
+**Примеры:**
+- Массовое заполнение доп. реквизитов
+- Загрузка данных из Excel
+- Формирование пакета документов по шаблону
+- Сверка данных между базами
+
+### 3. Печатная форма (MXL)
+
+**Артефакт:** макет `.mxl` — табличный документ для печати
+**Когда:** нужна нестандартная печатная форма для существующего документа
+**Риск обновления:** нулевой при подключении через БСП «Дополнительные печатные формы»
+**Уровень:** S (4–12 ч)
+
+**Примеры:**
+- Нестандартный формат счёта на оплату
+- Внутренний акт с доп. реквизитами
+- Этикетка / стикер для складского учёта
+
+### 4. Расширение конфигурации (CFE)
+
+**Артефакт:** файл `.cfe` — расширение, подключаемое без снятия с поддержки
+**Когда:** нужно изменить поведение типовых объектов, добавить реквизиты, перехватить события
+**Риск обновления:** средний — может «отвалиться» при обновлении, если изменены те же модули
+**Уровень:** M–L (20–120 ч)
+
+**Что можно:**
+- Добавлять реквизиты к типовым документам/справочникам
+- Перехватывать события (&Перед / &После)
+- Заимствовать и модифицировать типовые формы
+- Добавлять новые объекты (документы, справочники, регистры)
+- Добавлять подсистемы и команды
+
+**Ограничения:**
+- Нельзя удалять типовые объекты или реквизиты
+- Конфликты при обновлении, если фирма «1С» изменила тот же модуль
+- Перехватчики добавляют накладные расходы на производительность
+
+**Примеры:**
+- Добавление поля «Проект» к документу, где его нет
+- Автозаполнение реквизитов по бизнес-правилам
+- Доп. проверки при проведении документов
+
+### 5. Доп. обработка через БСП
+
+**Артефакт:** EPF, подключаемая через механизмы Библиотеки стандартных подсистем
+**Когда:** нужно интегрировать обработку в интерфейс типовой конфигурации без расширения
+**Риск обновления:** низкий — БСП-механизмы стабильны между версиями
+**Уровень:** S–M (8–40 ч)
+
+**Механизмы БСП для подключения:**
+- Дополнительные отчёты и обработки (регистрация через справочник)
+- Подключаемые команды (кнопки на формах типовых документов)
+- Дополнительные печатные формы
+- Обработки заполнения документов
+
+### 6. Новый объект метаданных (в конфигурации)
+
+**Артефакт:** объекты конфигурации — документы, справочники, регистры, роли
+**Когда:** задачу нельзя решить расширением/обработкой
+**Риск обновления:** высокий — конфигурация снята с поддержки, обновления через сравнение/объединение
+**Уровень:** L–XL (80–300+ ч)
+
+**Типичный комплект для нового бизнес-процесса:**
+```
+Новая подсистема
+├── Справочник(и) — классификаторы
+├── Документ(ы) — бизнес-операции
+│   ├── Табличные части
+│   ├── Формы (документа, списка, выбора)
+│   └── Модуль объекта (проведение, проверки)
+├── Регистр(ы) накопления / сведений — хранение движений
+├── Отчёт(ы) — аналитика по регистрам
+├── Роль(и) — разграничение доступа (RLS при необходимости)
+└── Подписки на события — интеграция с типовыми объектами
+```
+
+**Примеры:**
+- Подсистема таймшитов (учёт трудозатрат по проектам)
+- Подсистема трансфертного ценообразования между ЦФО
+- Нетиповая интеграция с внешней системой
+
+### 7. Изменение типового объекта
+
+**Артефакт:** модификация существующих модулей, форм, макетов типовой конфигурации
+**Когда:** задачу нельзя решить **ни одним** из способов выше
+**Риск обновления:** критический — каждое обновление = ручное сравнение/объединение
+**Уровень:** M–XL
+
+**Правило:** крайний случай. Перед тем как изменять типовой объект, дважды убедиться,
+что задачу нельзя решить расширением. Документировать каждое изменение:
+что именно изменено, зачем, какой код затронут, кто автор, дата.
+
+---
+
+## Сводная таблица для gap-анализа
+
+| Тип | Артефакт | Риск обновления | Обычный уровень | Стоимость сопровождения |
+|-----|----------|-----------------|-----------------|-------------------------|
+| Внешний отчёт | .erf | Нулевой | S | Низкая |
+| Внешняя обработка | .epf | Нулевой | S–M | Низкая |
+| Печатная форма | .mxl через БСП | Нулевой | S | Низкая |
+| Через БСП | .epf (подключаемая) | Низкий | S–M | Низкая |
+| Расширение | .cfe | Средний | M–L | Средняя |
+| Новый объект | Конфигурация | Высокий | L–XL | Высокая |
+| Изменение типового | Конфигурация | Критический | M–XL | Очень высокая |
+
+---
+
+## Оценка совокупной стоимости доработки (TCO)
+
+При оценке трудозатрат учитывать не только разработку, но и весь жизненный цикл:
+
+| Компонент | % от общей стоимости (ориентир) |
+|-----------|-------------------------------|
+| Аналитика и проектирование | 15–25% |
+| Разработка | 30–40% |
+| Тестирование | 15–20% |
+| Документирование | 5–10% |
+| Внедрение (обучение, настройка) | 10–15% |
+| Сопровождение при обновлениях (в год) | 10–30% от стоимости разработки |
+
+Для доработок с высоким/критическим риском обновления — стоимость сопровождения
+превысит стоимость начальной разработки уже через 2–3 года эксплуатации.
+
+---
+
+## Workflow разработки доработки (режим «Код/Отчёт»)
+
+Адаптация 9-фазного pipeline (1C AI Dev Kit → 6 фаз для Claude.ai):
+
+### Фаза 0: Оценка и классификация
+- Определить тип доработки по каталогу выше
+- Определить уровень сложности (S / M / L / XL)
+- Выбрать подход (ERF → EPF → CFE → конфигурация)
+
+### Фаза 1: Требования и уточнения
+- Формализовать требования: что должно делать, входы/выходы, ограничения
+- Выявить неоднозначности, граничные случаи, зависимости от типовых объектов
+- Все вопросы пользователю — ДО начала проектирования
+
+### Фаза 2: Проектирование
+- Определить затрагиваемые объекты конфигурации (регистры, справочники)
+- Спроектировать структуру данных (реквизиты, табличные части, регистры)
+- Спроектировать запросы (для отчётов — текст запроса СКД)
+- Спроектировать UI (формы, команды, расположение в интерфейсе)
+- Описать права доступа (роли, RLS)
+
+### Фаза 3: Ревью плана → Одобрение пользователем
+- Представить план пользователю
+- **Не начинать реализацию без одобрения**
+
+### Фаза 4: Реализация
+- Писать код BSL с комментариями
+- Для СКД — описать схему компоновки (наборы данных, ресурсы, настройки)
+- Для форм — описать элементы и обработчики
+
+### Фаза 5: Ревью и документирование
+- Проверить код на соответствие стандартам 1С и плану
+- Создать описание доработки (для передачи клиенту / другому разработчику)

1c-analyst/references/erp25-capabilities.md

@@ -0,0 +1,96 @@
+# 1С:ERP 2.5 — Отличия от КА 2.5
+
+> Этот файл фокусируется ТОЛЬКО на отличиях. Общие механизмы (торговля, склад, бухгалтерия,
+> казначейство) — практически идентичны КА 2.5, см. `ka25-capabilities.md`.
+> **Всегда верифицировать через web search** — различия меняются между релизами.
+
+---
+
+## 1. Бюджетный процесс (главное отличие)
+
+В ERP 2.5 (в отличие от КА 2.5) есть подсистема **«Бюджетный процесс»**:
+- Маршруты формирования и согласования бюджетов
+- Монитор задач бюджетирования
+- Статусы экземпляров бюджетов (черновик, на согласовании, утверждён)
+- Автоматическое формирование задач ответственным
+
+Это ключевое преимущество ERP для компаний, которым нужен формализованный бюджетный цикл.
+
+---
+
+## 2. Производство (MRP, MES)
+
+### MRP — Планирование потребности в материалах
+
+- Расчёт потребности на основе плана производства и спецификаций
+- Формирование заказов поставщикам и производственных заказов
+- Учёт страхового запаса, минимальных партий
+
+### MES — Управление цеховым уровнем
+
+- Маршрутные карты (последовательность операций)
+- Планирование по рабочим центрам
+- Учёт выработки, нормы времени
+- Попередельное производство
+- Планирование по узким местам (TOC — Theory of Constraints)
+
+### Производственные подсистемы ERP vs КА
+
+| Функция | КА 2.5 | ERP 2.5 |
+|---------|--------|---------|
+| Спецификации | Да | Да (+ ресурсные спецификации) |
+| Заказ на производство | Да | Да (+ этапы, графики) |
+| MRP | Нет | Да |
+| MES / маршрутные карты | Нет | Да |
+| Попередельное производство | Нет | Да |
+| Планирование по рабочим центрам | Нет | Да |
+| Управление ремонтами (ТОИР) | Нет | Да (через доп. модуль) |
+
+---
+
+## 3. Управление данными об изделиях (PDM-элементы)
+
+ERP 2.5 поддерживает:
+- Версионирование спецификаций
+- Конструкторско-технологическая подготовка (КТП)
+- Альтернативные спецификации для одного изделия
+
+---
+
+## 4. Документооборот и согласование
+
+ERP 2.5 имеет расширенные механизмы:
+- Бизнес-процессы (типовые маршруты согласования)
+- Задачи с контролем сроков
+- Интеграция бизнес-процессов с документами учёта
+
+В КА 2.5 согласование ограничено заявками на ДС и некоторыми закупочными документами.
+
+---
+
+## 5. Управленческий учёт — расширения
+
+| Функция | КА 2.5 | ERP 2.5 |
+|---------|--------|---------|
+| Учёт по НД | Да | Да |
+| Директ-костинг | Да | Да |
+| Полный управленческий план счетов | Нет | Да (опционально) |
+| Фин. результат с распределением косвенных | Да | Да (+ расширенные базы) |
+| Управленческий баланс | Через бюджетирование | Через бюджетирование + план счетов |
+
+---
+
+## 6. Когда мигрировать с КА на ERP
+
+Миграция оправдана, если:
+1. Нужен полный MRP/MES (производственное планирование)
+2. Нужен формализованный бюджетный процесс (workflow)
+3. Масштаб перерос 200 пользователей
+4. Нужны бизнес-процессы с маршрутами согласования
+
+Миграция НЕ оправдана, если:
+1. Бюджетный workflow можно реализовать через Битрикс24
+2. Производство простое (сборка, комплектация)
+3. Нет потребности в MRP
+
+**Риск миграции:** стоимость лицензии ERP значительно выше, сложность внедрения выше, более длинный проект. Всегда считать TCO (Total Cost of Ownership) на 5 лет.

1c-analyst/references/ka25-capabilities.md

@@ -0,0 +1,235 @@
+# 1С:Комплексная Автоматизация 2.5 — Типовые возможности
+
+> Справочник для gap-анализа. Для каждой подсистемы указаны типовые механизмы,
+> их ограничения и типичные доработки.
+> **Всегда верифицировать через web search** — механизмы меняются между релизами.
+
+---
+
+## Содержание
+
+1. [Финансовая структура и ЦФО](#1-финансовая-структура-и-цфо)
+2. [Управленческий учёт](#2-управленческий-учёт)
+3. [Казначейство](#3-казначейство)
+4. [Бюджетирование](#4-бюджетирование)
+5. [Управленческая отчётность](#5-управленческая-отчётность)
+6. [Проектный учёт](#6-проектный-учёт)
+7. [Торговля и склад](#7-торговля-и-склад)
+8. [Производство](#8-производство)
+9. [Зарплата и HR](#9-зарплата-и-hr)
+10. [Регламентированный учёт](#10-регламентированный-учёт)
+
+---
+
+## 1. Финансовая структура и ЦФО
+
+### Типовые механизмы
+
+| Объект | Путь в меню | Назначение |
+|--------|-------------|------------|
+| Структура предприятия | НСИ → Структура предприятия | Иерархический классификатор подразделений, не привязан к юрлицу |
+| Организации | НСИ → Организации | Юрлица, между которыми можно вести управленческий учёт |
+| Направления деятельности (НД) | НСИ → Направления деятельности | Сквозная аналитика: проект, вид бизнеса, направление |
+
+### Как настроить ЦФО
+
+В КА 2.5 **нет отдельного справочника ЦФО**. Роль ЦФО выполняет комбинация:
+- **Подразделение** (из «Структуры предприятия») — организационная единица
+- **НД** — вид деятельности / проект / бизнес-линия
+
+Тип ЦФО (центр прибыли, центр затрат, центр инвестиций) — методологическая надстройка. Типовой механизм не хранит тип ЦФО как реквизит.
+
+**Доработка (простая):** добавить доп. реквизит «Тип ЦФО» к элементам справочника «Структура предприятия» через механизм расширений.
+
+### Ограничения
+
+- Иерархия подразделений плоская в плане финансовой аналитики — нет встроенной консолидации «снизу вверх»
+- Один элемент НД = одна аналитика. Если нужно вести учёт одновременно по «проект + вид бизнеса» — нужны два измерения (НД для одного, подразделение для другого)
+
+---
+
+## 2. Управленческий учёт
+
+### Механизм учёта по направлениям деятельности
+
+Регистр накопления `ВыручкаИСебестоимостьПродаж` — основной источник данных. Содержит измерения:
+- Организация, Подразделение, НД
+- Номенклатура, Характеристика, Серия
+- Контрагент, Договор, Заказ
+
+**Что учитывается типовыми средствами:**
+- Выручка по НД (при оформлении реализации с указанием НД)
+- Прямая себестоимость продаж (по НД)
+- Валовая прибыль = Выручка − Себестоимость (по НД)
+- Коммерческие расходы (если привязаны к НД через статьи расходов)
+- Управленческие расходы — распределение через типовую «Базу распределения»
+
+### Директ-костинг
+
+Типовой. Прямые затраты относятся на НД при проведении документов (поступления, производство, зарплата). Косвенные — через документ «Распределение расходов на направления деятельности».
+
+Базы распределения (типовые): выручка, прямые затраты, фиксированные доли. Можно настроить произвольную базу через формулу.
+
+### Трансфертное ценообразование
+
+**НЕТ** в типовом решении. Между подразделениями одного юрлица нет механизма «внутренней продажи». Есть только между организациями (документ «Передача между организациями»).
+
+**Доработка (сложная):** если требуется трансфертное ценообразование между ЦФО одного юрлица — нужен механизм внутренних актов с виртуальными проводками по управленческому плану счетов.
+
+---
+
+## 3. Казначейство
+
+### Типовые механизмы
+
+| Механизм | Описание | Оценка |
+|----------|----------|--------|
+| Заявки на расходование ДС | Документ с маршрутом согласования, статусами, лимитами | Типовое |
+| Платёжный календарь | Визуальное отображение план/факт ДС по дням | Типовое |
+| Реестры платежей | Группировка заявок для массовой оплаты | Типовое |
+| Контроль лимитов | Блокировка заявок при превышении бюджета | Типовое |
+| Согласование заявок | Маршруты согласования (N уровней) | Типовое |
+| Расчётные счета и кассы | Справочники с привязкой к организациям | Типовое |
+| Контроль взаиморасчётов | По контрагентам и договорам | Типовое |
+| Aging дебиторской задолженности | Типового отчёта нет | Простая доработка |
+
+### Ограничения
+
+- Маршруты согласования заявок — без визуального конструктора, настраиваются через «Настройки согласования»
+- Автоматическое формирование платёжных поручений из реестра — типовое, но требует настройки правил заполнения
+- Мультивалютный платёжный календарь — типовой, но курсы нужно актуализировать
+
+---
+
+## 4. Бюджетирование
+
+### Архитектура
+
+Подсистема бюджетирования КА 2.5 — **конструктор**, а не готовое решение. Из коробки нет готовых БДР/БДДС — всё настраивается.
+
+**Ключевые объекты:**
+- **Модель бюджетирования** — верхний уровень (обычно одна на компанию)
+- **Вид бюджета** — конкретный бюджет (БДР, БДДС, бюджет закупок и т.д.)
+- **Статья бюджета** — строка бюджета с аналитиками (до 6 произвольных)
+- **Показатель бюджета** — расчётная величина (ДС на конец периода, ДЗ, и т.д.)
+- **Экземпляр бюджета** — документ ввода плановых данных
+- **Сценарий** — версия плана (оптимистичный, пессимистичный, факт)
+
+### Что типовое
+
+| Функция | Оценка | Комментарий |
+|---------|--------|-------------|
+| БДР | Типовое | Настраивается как вид бюджета со статьями доходов/расходов |
+| БДДС | Типовое | Привязка к хозяйственным операциям казначейства |
+| ББЛ (управленческий баланс) | Типовое | Через показатели бюджетов и связи |
+| Бюджеты по ЦФО | Типовое | Аналитика «Подразделение» в статьях |
+| План-факт анализ | Типовое | 3 источника факта: оперативный, регламентированный, СКД |
+| Контроль перерасхода ДС | Типовое | Лимиты по данным бюджетирования |
+| Контроль не-ДС статей | Сложная доработка | Подписки на события при проведении документов |
+| Бюджетный процесс (workflow) | **Отсутствует** | Есть только в ERP 2.5 |
+
+### Аналитики статей бюджета
+
+Каждая статья поддерживает до 6 аналитик из предустановленного каталога (~30 видов):
+- Подразделение, Направление деятельности, Организация
+- Номенклатура, Контрагент, Договор
+- Статья ДДС, Валюта, Банковский счёт
+- И другие
+
+### Источники фактических данных
+
+Три типа для автоматического сбора факта:
+1. **Оперативный учёт** — данные из регистров накопления (выручка, затраты, ДС)
+2. **Регламентированный учёт** — обороты по счетам бухгалтерского учёта
+3. **Произвольные запросы** — СКД-запросы к любым данным
+
+---
+
+## 5. Управленческая отчётность
+
+### Типовые отчёты
+
+| Отчёт | Раздел | Аналитики |
+|-------|--------|-----------|
+| Доходы и расходы | Финансовый результат | НД, подразделение, организация |
+| Финансовый результат | Финансовый результат | НД, организация |
+| Валовая прибыль | Продажи | Подразделение, клиент, менеджер, сделка, номенклатура |
+| Бюджетные отчёты | Бюджетирование | По настройке вида бюджета |
+| Движение ДС | Казначейство | Статья ДДС, расчётный счёт, организация |
+
+### Что нужно дорабатывать
+
+| Отчёт | Сложность доработки |
+|-------|---------------------|
+| EBITDA | Простая — внешний отчёт по данным регистра «Доходы и расходы» |
+| Aging ДЗ (просроченная задолженность по периодам) | Простая — внешний отчёт по регистру взаиморасчётов |
+| P&L по проектам с менеджерской рентабельностью | Простая — внешний отчёт по НД + поле «Менеджер» |
+| Утилизация инженеров (% времени на проектах) | Сложная — нет таймшитов, нужен новый документ и регистр |
+| Консолидированная отчётность (элиминация ВГО) | Сложная — только при многобазовой архитектуре или нескольких организациях |
+
+---
+
+## 6. Проектный учёт
+
+### Типовой механизм
+
+**Направление деятельности = Проект.** Элемент НД создаётся для каждого проекта. Все доходы и расходы проходят с указанием НД-проекта.
+
+**Что отслеживается типовыми средствами:**
+- Выручка проекта (реализации с НД)
+- Прямые затраты (закупки, субподряд, ФОТ — если привязаны к НД)
+- Себестоимость продаж проекта
+- Рентабельность проекта (валовая прибыль / выручка)
+
+**Что НЕ отслеживается:**
+- Трудозатраты по проекту (таймшиты) — нет механизма
+- Этапы / вехи проекта — нет Gantt, нет WBS
+- Бюджет проекта (план/факт) — только через подсистему бюджетирования с аналитикой НД
+
+### Рекомендация
+
+Для полноценного управления проектами интегрировать с внешней системой (Битрикс24, MS Project, Wrike) и использовать 1С только для финансовой аналитики проекта.
+
+---
+
+## 7. Торговля и склад
+
+Подсистема торговли в КА 2.5 аналогична 1С:УТ 11. Типовые механизмы:
+- Заказы покупателей / поставщикам
+- Ценообразование (виды цен, формулы, скидки)
+- Складской учёт (ордерный и неордерный)
+- Серийный учёт, характеристики, упаковки
+- Партионный учёт (FIFO, LIFO, по средней, по партиям)
+- Резервирование
+
+---
+
+## 8. Производство
+
+Простое производство: сборка, комплектация, разборка. Спецификации, производственные заказы.
+
+**Нет в КА 2.5 (есть в ERP 2.5):**
+- MRP (планирование потребности в материалах)
+- MES (управление цехом, маршрутные карты)
+- Попередельное производство
+- Планирование по узким местам (TOC)
+
+---
+
+## 9. Зарплата и HR
+
+Встроенная подсистема, аналогичная ЗУП 3 (с некоторыми ограничениями). Включает:
+- Кадровый учёт, штатное расписание
+- Начисление зарплаты, НДФЛ, страховые взносы
+- Табельный учёт
+- Отпуска, больничные, командировки
+
+---
+
+## 10. Регламентированный учёт
+
+Полноценный бухгалтерский и налоговый учёт:
+- План счетов РСБУ
+- Регламентированная отчётность (ФНС, ПФР, ФСС)
+- Учёт основных средств, НМА
+- Закрытие месяца (типовой помощник)

1c-analyst/references/migration-plan.md

@@ -0,0 +1,143 @@
+# Шаблон плана миграции между конфигурациями 1С
+
+> Используется при переходе УПП→ERP, КА→ERP, БП→КА и других миграциях.
+> Каждый раздел — обязательный. Пустых разделов быть не должно.
+
+---
+
+## 1. Общие сведения
+
+- Исходная конфигурация: [название, версия, платформа]
+- Целевая конфигурация: [название, версия, платформа]
+- Количество пользователей: [число]
+- Объём базы: [размер файла .dt или SQL]
+- Целевая дата перехода: [дата]
+- Стратегия перехода: [Big Bang / Поэтапная / Параллельная]
+
+---
+
+## 2. Перечень объектов переноса
+
+Для каждого объекта:
+
+| № | Тип объекта | Объект | Кол-во записей | Источник (объект в старой базе) | Приёмник (объект в новой базе) | Правила маппинга | Ответственный | Статус |
+|---|-------------|--------|----------------|-------------------------------|-------------------------------|------------------|---------------|--------|
+
+### Обязательные категории:
+
+**Справочники (НСИ):**
+- Номенклатура (+ характеристики, серии, упаковки, ценовые группы)
+- Контрагенты (+ договоры, банковские реквизиты)
+- Организации (+ учётные политики)
+- Подразделения / Структура предприятия
+- Склады
+- Сотрудники / физические лица
+- Основные средства
+- Статьи расходов / статьи ДДС
+- Направления деятельности (если есть)
+
+**Остатки (на дату отсечки):**
+- Остатки ТМЦ на складах
+- Взаиморасчёты с контрагентами (ДЗ + КЗ)
+- Остатки ДС (банк + касса)
+- Авансы выданные и полученные
+- Основные средства (первоначальная стоимость, амортизация)
+- НМА
+- Остатки незавершённого производства
+- Остатки по расчётам с сотрудниками (задолженность по зарплате, отпускам)
+- Сальдо по налоговым регистрам
+
+**Документы (опционально):**
+- Открытые заказы покупателей / поставщикам
+- Незакрытые договоры
+- Текущие производственные заказы
+
+---
+
+## 3. Нормализация НСИ
+
+### Номенклатура
+- Количество элементов в источнике: [число]
+- Количество дубликатов (оценка): [число]
+- Стратегия нормализации: [автоматическая + ручная ревизия / только ручная]
+- Правила кодификации в новой системе: [описание]
+- Ответственный за ревизию: [ФИО, должность]
+
+### Контрагенты
+- Проверка по ИНН/КПП на дубли
+- Актуализация реквизитов через ФНС API
+- Пометка недействующих контрагентов
+
+### Общие правила
+- Элементы, помеченные на удаление — переносить? [да / нет]
+- Группы (папки) справочников — переносить структуру? [да / нет / пересмотреть]
+- Предопределённые элементы — маппинг один к одному
+- Дополнительные реквизиты и сведения — перечень для переноса
+
+---
+
+## 4. График миграции
+
+| Этап | Описание | Дата начала | Дата окончания | Ответственный |
+|------|----------|-------------|----------------|---------------|
+| Подготовка правил переноса | Настройка КД 2/3, тестовая выгрузка | | | |
+| Нормализация НСИ | Ревизия справочников, удаление дублей | | | |
+| Тестовый прогон №1 | Полный перенос в тестовую базу | | | |
+| Верификация прогона №1 | Сверка остатков, проверка целостности | | | |
+| Исправление ошибок | Доработка правил по результатам прогона | | | |
+| Тестовый прогон №2 | Повторный полный перенос | | | |
+| Верификация прогона №2 | Финальная сверка | | | |
+| Фиксация даты отсечки | Прекращение операций в старой базе | | | |
+| Боевой перенос | Перенос данных на дату отсечки | | | |
+| Верификация боевого переноса | Сверка остатков с бухгалтерией | | | |
+| Начало работы в новой базе | Ввод документов в новой системе | | | |
+
+---
+
+## 5. Переходный период
+
+- Период параллельной эксплуатации: [дней/месяцев]
+- Какие операции ведутся в старой базе во время перехода: [перечень]
+- Какие операции ведутся в новой базе: [перечень]
+- Механизм синхронизации данных в переходный период: [описание или «не предусмотрен»]
+- Порядок закрытия месяца в переходный период: [в какой базе, как]
+
+---
+
+## 6. Критерии качества миграции
+
+| Объект | Критерий | Допустимое отклонение |
+|--------|----------|----------------------|
+| Остатки ТМЦ | Совпадение количества и суммы по каждому складу | 0% |
+| Взаиморасчёты | Совпадение сальдо по каждому контрагенту/договору | 0 руб. |
+| Остатки ДС | Совпадение с банковскими выписками | 0 руб. |
+| ОС | Совпадение первоначальной стоимости и накопленной амортизации | 0% |
+| Справочники | Все активные элементы перенесены, нет потерь данных | 100% |
+| Открытые заказы | Все незакрытые заказы перенесены с корректными статусами | 100% |
+
+---
+
+## 7. План отката
+
+- Точка невозврата: [описание — после какого действия откат невозможен/нецелесообразен]
+- Действия при неуспешной миграции:
+  1. Возврат к работе в старой базе
+  2. Анализ причин сбоя
+  3. Повторная миграция по исправленным правилам
+- Максимальное время на принятие решения об откате: [часов]
+- Ответственный за принятие решения: [ФИО, должность]
+
+---
+
+## 8. Ресурсная модель
+
+| Роль | Количество | Период занятости |
+|------|-----------|------------------|
+| Руководитель проекта (Заказчик) | | |
+| Руководитель проекта (Исполнитель) | | |
+| Консультант-аналитик 1С | | |
+| Разработчик 1С | | |
+| Администратор БД | | |
+| Ключевые пользователи (бухгалтерия) | | |
+| Ключевые пользователи (склад) | | |
+| Ключевые пользователи (производство) | | |

1c-analyst/references/tz-review-checklist.md

@@ -0,0 +1,107 @@
+# Чек-лист экспертизы ТЗ на внедрение / миграцию 1С
+
+> Использовать при рецензировании ТЗ, Концепций проекта, ЧТЗ.
+> Каждый пункт — потенциальное замечание. Если ответ «нет» или «неясно» — фиксировать в отчёте.
+
+---
+
+## 1. Общая структура и полнота
+
+- [ ] Описано текущее состояние (AS-IS) по каждому функциональному блоку?
+- [ ] Описано целевое состояние (TO-BE) с конкретными требованиями, а не намерениями?
+- [ ] Требования детализированы до уровня, достаточного для оценки трудозатрат Исполнителем?
+- [ ] Нет массовых отсылок «будет уточнено в ЧТЗ/на этапе проектирования» без базовых параметров?
+- [ ] Для каждого требования указан приоритет (MoSCoW или аналог)?
+- [ ] Определены границы проекта (что НЕ входит в скоуп)?
+
+## 2. Измеримые критерии успешности
+
+- [ ] Определены KPI проекта (не «повышение эффективности», а конкретные метрики)?
+- [ ] Для каждого KPI указан способ измерения и целевое значение?
+- [ ] Определены критерии приёмки для каждого этапа?
+- [ ] Описана процедура приёмочных испытаний?
+
+## 3. Миграция данных
+
+- [ ] Определён перечень объектов переноса (справочники, остатки, документы)?
+- [ ] Для каждого объекта указан источник, приёмник, правила маппинга?
+- [ ] Определена стратегия нормализации НСИ (дубли, устаревшие элементы, кодификация)?
+- [ ] Указан объём данных (количество элементов справочников, документов)?
+- [ ] Определена дата отсечки для переноса остатков?
+- [ ] Определены ответственные за подготовку данных со стороны Заказчика?
+- [ ] Запланированы тестовые прогоны миграции (минимум 2)?
+- [ ] Определены критерии качества миграции (допустимый % расхождений)?
+- [ ] Описана процедура верификации перенесённых данных?
+- [ ] Есть план отката в случае неуспешной миграции?
+
+## 4. Переходный период
+
+- [ ] Описан режим работы предприятия в переходный период для каждого блока?
+- [ ] Определён период параллельной эксплуатации (старая + новая система)?
+- [ ] Описано, как предприятие будет работать, если блоки 2-й очереди ещё не внедрены?
+- [ ] Определена стратегия перехода: Big Bang / поэтапная / параллельная?
+
+## 5. Нефункциональные требования
+
+- [ ] Требования к производительности (время формирования ключевых отчётов, одновременные пользователи)?
+- [ ] Требования к доступности (RTO, RPO, режим работы)?
+- [ ] Требования к масштабируемости (рост пользователей, объёма данных)?
+- [ ] Требования к информационной безопасности (роли, RLS, журналирование)?
+- [ ] Требования к резервному копированию?
+- [ ] Архитектура серверов (1С:Предприятие, СУБД, веб-сервер, терминальный сервер)?
+
+## 6. Управление изменениями
+
+- [ ] Определена процедура Change Request (оценка влияния на сроки и бюджет)?
+- [ ] Описан процесс согласования изменений в скоупе?
+- [ ] Указано, кто имеет право инициировать и утверждать изменения?
+- [ ] Определён порядок пересмотра стоимости при изменении объёма работ?
+
+## 7. Обучение и оргизменения
+
+- [ ] Определено количество пользователей по ролям и функциональным блокам?
+- [ ] Описана программа обучения с достаточным объёмом часов?
+- [ ] Определены ключевые пользователи (key users) и их роль в проекте?
+- [ ] Описана стратегия организационных изменений (OCM)?
+- [ ] Предусмотрено освобождение key users от основных обязанностей на период проекта?
+- [ ] Определены требования к пользовательской документации?
+
+## 8. Риски
+
+- [ ] Описаны риски ОБЕИХ сторон (не только Заказчика)?
+- [ ] Для каждого риска определена вероятность, влияние, мера реагирования?
+- [ ] Рассмотрены: текучесть команды Исполнителя, ошибки проектирования, недостаточная экспертиза в отрасли?
+- [ ] Рассмотрены: сопротивление персонала, неготовность данных, задержки согласований?
+
+## 9. План-график и ресурсная модель
+
+- [ ] Сроки этапов реалистичны (особенно обучение и опытная эксплуатация)?
+- [ ] Определён состав команды проекта (обе стороны)?
+- [ ] Указаны требования к квалификации участников?
+- [ ] Есть буфер на непредвиденные работы (обычно 15-20%)?
+- [ ] Определено гарантийное сопровождение после приёмки?
+
+## 10. Интеграции
+
+- [ ] Для каждой интеграции определены: протокол, формат, сценарии обмена, обработка конфликтов?
+- [ ] Интеграции не описаны «одной строкой» типа «установка модуля от вендора»?
+- [ ] Определена ответственность за интеграционные модули (кто разрабатывает, тестирует, поддерживает)?
+- [ ] Рассмотрена синхронизация справочников между интегрируемыми системами?
+
+## 11. Разделение на очереди
+
+- [ ] Обоснован порядок очерёдности (почему именно эти блоки в 1-й очереди)?
+- [ ] Для каждой очереди определён самодостаточный набор функций?
+- [ ] Описана работоспособность предприятия на каждом промежуточном этапе?
+- [ ] Зависимости между очередями явно указаны?
+
+---
+
+## Формат замечания в отчёте
+
+Для каждого замечания указывать:
+1. **Раздел/пункт ТЗ** — где обнаружен недостаток
+2. **Суть замечания** — что не так (коротко и конкретно)
+3. **Влияние** — к чему приведёт, если не исправить
+4. **Рекомендация** — что конкретно нужно добавить/изменить
+5. **Критичность** — Критическое / Существенное / Рекомендательное