Модуль 10.2. Системный аналитик 1C/ERP/CRM
Темы: интеграции 1C/1C:ERP, справочники, обмен документами. Артефакты: спецификация обмена 1C↔CRM/ERP, карта справочников и ключей. Практика: описать регламент и контракт «CRM→1C:ERP: заказ→счёт→отгрузка→оплата».
В проектах с 1C (УТ/ERP/Бух/КА и др.) системный аналитик (SA) — ключевой связующий между предметкой (учёт/логистика/финансы) и интеграционным ландшафтом (CRM/e-commerce/BI/шины). Ваша задача — зафиксировать что, когда, в каком формате и с какими гарантиями передаётся; как устроены справочники, документы, «проведение» и проводки, а также как обеспечивается идемпотентность, DQ, аудит и откат.
Картина мира 1C/ERP/CRM (как сотруднику — к исполнению)
Типовая схема ролей
- CRM: лид/контакт/контрагент, сделки/заказы, прайс и акции, статусы продаж.
- 1C:ERP/УТ: номенклатура/единицы, склады/остатки, цены/скидки, заказы покупателей, счета, реализации/отгрузки, возвраты, платежи, бухгалтерские проводки.
- DWH/BI: витрины продаж, маржинальность, ABC/XYZ.
- ESB/шина (опционально): маршрутизация, ретраи/дедупликация.
Базовые объекты 1C
- Справочники: Номенклатура, Контрагенты, Договоры, Склады, Валюты, Единицы, Налоги/ставки, Пользователи.
- Документы: ЗаказПокупателя, СчётНаОплатуПокупателю, РеализацияТоваровУслуг, ПоступлениеОплатыОтПокупателя, ВозвратПокупателя.
- Регистры: Накопления (ОстаткиТоваров), Сведений (ЦеныНоменклатуры).
- Ссылки/Ref: каждый объект имеет GUID; в обменах используем внешний ключ (ExternalId) + маппинг на GUID.
«Проведение» и хронология
- Запись (создать) ≠ Проведение (порождение движений/проводок).
- Порядок: справочники → документы (заказ→счёт→реализация) → проведение → расчёты.
- SA обязан описать порядок и зависимости (какой объект блокирует следующий).
Паттерны интеграций с 1C
|
Паттерн |
Где уместен |
Плюсы |
Риски/заметки |
|---|---|---|---|
|
Планы обмена (встроенный механизм) |
1C↔1C, филиалы |
Инкрементальность, «из коробки» |
Тяготеет к XML, требует настройки правил |
|
HTTP-сервисы 1C (/hs/...) |
REST-подобные обмены |
Гибко, JSON, Basic OAuth proxy |
Нужна идемпотентность и лимиты |
|
OData публикация |
Чтение из 1C |
Быстрый старт |
Производительность/фильтры, без сложной логики |
|
Web-сервисы (SOAP/xDTO) |
Легаси интеграции |
Стабильно, типы |
Версионирование, громоздкость |
|
Файловый обмен (XML/CSV, CommerceML) |
E-com/каталоги, офлайн-каналы |
Простота, дешёвый транспорт |
DQ/контроль версий/повторная загрузка |
|
Шина/MQ (ESB, Rabbit/Kafka) |
Много систем, near-real-time |
Буферизация, ретраи, дедуп |
Нужен событийный контракт и ключи |
Рекомендация SA: для CRM↔1C предпочитайте HTTP-сервисы 1C (JSON) с идемпотентными методами + событийные уведомления (через шину) о статусах. Для каталогов/заказов из e-commerce — CommerceML или собственный JSON-контракт. Для витрин BI — CDC/выгрузки по расписанию.
Справочники: модель, ключи, версии
Единая карта справочников (артефакт)
|
Код |
Объект |
Источник истины (SoT) |
Ключ CRM |
Ключ 1C |
Синхрон |
Верси |
|---|---|---|---|---|---|---|
|
CAT-001 |
Номенклатура |
1C |
product. |
Справочник. |
Δ каждые 5 мин |
validFrom/To, ставка НДС |
|
CAT-002 |
Контрагенты |
CRM (мастер), 1C (учёт) |
account. |
Справочник. |
События + ручная сверка |
KYC-статус |
|
CAT-003 |
Склады |
1C |
— |
Справочник. |
Полная ночная |
— |
|
CAT-004 |
Цены |
1C |
— |
РегистрСведений. |
Δ раз в час |
ТипЦен, валюта |
Практика ключей
- Вводим внешний ключ (ExternalId) — неизменяемый строковый ID, живёт в обеих системах.
- Импорт в 1C: поиск по ExternalId → если нет — создать элемент (пометка «создан извне»).
- Храним маппинг ExternalId ↔ GUID (таблица соответствий).
- Для «слияний» контрагентов — политика мерджа (кто главный, кто алиас).
DQ-правила
- Номенклатура: уникальность по (Артикул, Бренд), обязательные поля НДС/ед.изм.
- Контрагенты: ИНН/КПП, проверки адреса, KYC-флаги.
- Единицы: соответствие ОКЕИ, коэффициенты пересчёта.
Документы и статусы: «заказ-счёт-отгрузка-оплата»
Мини-жизненный цикл
- Заказ в CRM (предварительная корзина/согласование) → ЗаказПокупателя в 1C.
- Сформировать Счёт на оплату (опционально).
- После оплаты/подтверждения — Реализация (отгрузка).
- Денежные документы: Поступление оплаты.
- Возвраты — зеркальные документы.
Обязательные связки
- ЗаказПокупателя ←→ Счёт ←→ Реализация ←→ ПоступлениеОплаты (по ExternalId/Номеру/Дате и ссылкам).
- В CRM возвращаем статусы: Создан в 1C, Счёт выставлен, Отгружен, Оплачен, Закрыт.
Пример статусов (таблица маппинга)
|
CRM |
1C:ERP |
Триггер |
|---|---|---|
|
PendingApproval |
ЗаказПокупателя.Записан (не проведён) |
Создан заказ |
|
Invoiced |
Счёт.Записан |
Создан счёт |
|
Shipped |
Реализация.Проведён |
Движения по складу |
|
Paid |
ПоступлениеОплаты.Проведён |
Движения по расчётам |
|
Closed |
ЗаказЗакрыт |
Кол-во/сумма закрыты |
Контракты обмена: форматы, идемпотентность, ошибки
JSON DTO (пример)
{
"externalId": "ORD-78452",
"customer": {
"externalId": "ACC-10023",
"inn": "7701234567",
"kpp": "770101001",
"name": "ООО «Ромашка»"
},
"lines": [
{"productExternalId":"SKU-001","qty":3,"uom":"шт","price":1200.00,"vatRate":"20"},
{"productExternalId":"SKU-002","qty":1,"uom":"шт","price":5000.00,"vatRate":"20"}
],
"warehouseExternalId":"WH-MS-01",
"currency":"RUB",
"contractExternalId":"CTR-2025-010",
"orderDate":"2025-08-20T10:15:00+03:00"
}
Идемпотентность
- Заголовок Idempotency-Key для создающих методов /hs/orders.
- 1C хранит регистр «Идемпотентные операции» (ключ + результат).
- Повтор с тем же ключом → тот же ответ (без дублей).
Ошибки (единый словарь)
- VALIDATION_ERROR (422): отсутствует номенклатура/ед.изм/ставка НДС.
- DUPLICATE (409): заказ с таким externalId уже есть (и несовпадающие поля).
- CONFLICT (409): заказ проведён/закрыт — изменения запрещены.
- NOT_FOUND (404): неизвестный контрагент/склад/договор.
- TEMPORARY_UNAVAILABLE (503): 1C занята/блокировки — повторить позже.
Пагинация и отбор
Для справочников/остатков — страничная выборка (limit/offset или курсор), фильтры по modifiedSince.
Производительность и надёжность 1C-интеграций
- Блокировки: избегайте массового «проведения» в рабочий день; выносите в регламентные задания/ночь.
- Пакеты: отправляйте пакетами (например, до 500 строк) с подтверждением по частям.
- Очереди/ретраи: при ошибке 1C — повтор с backoff; при «падении» 1C — очереди на шине.
- Аудит: логируйте correlationId, externalId, пользователя/интеграцию.
- DQ-мониторы: расхождения номенклатуры, «без владельца», «без НДС», несуществующие единицы — отдельные отчёты/алерты.
Пример потоков (Sequence, текстом)
CRM → 1C: создать заказ
- POST /hs/orders (Idempotency-Key=K1).
- 1C валидирует справочники, создаёт ЗаказПокупателя (не проводит), пишет в регистр идемпотентности K1→OrderGUID.
- Ответ 201 {orderGuid, number}.
- Событие в шину: order.created.v1.
1C → CRM: статус счёта
- 1C создала Счёт (по заказу) → событие invoice.issued.v1 с externalId, number, amount.
- CRM обновляет статус сделки на Invoiced.
CRM/PSP → 1C: оплата
- POST /hs/payments (линк на счёт/заказ, сумма).
- 1C создаёт ПоступлениеОплаты и проводит.
- Событие payment.posted.v1 + обновление статуса заказа Paid.
Отгрузка
- В 1C оформляют Реализацию (из заказа), проводят.
- Событие shipment.posted.v1 → CRM статус Shipped.
Интеграции с бухгалтерией/BI
- Проводки: на «проведение» документов генерируются проводки (доход/НДС/склад). SA фиксирует правила проводок (таблица: документ → Дт/Кт/сумма/основание).
- BI: выгрузка фактов — fact_sales, fact_payments; измерения — клиенты, товары, склады, договоры; SLA D+1; дедуп по (externalId, docType, docDate, lineNo).
Риски и как их гасить
|
Риск |
Симптом |
Меры |
|---|---|---|
|
Дубликаты документов |
Двойные заказы/платежи |
Idempotency-Key + регистр, уникальные ограничения |
|
Несогласованные справочники |
«Товар не найден» |
Единый SoT, nightly полная сверка, отчёты «битых» ссылок |
|
Разные ставки НДС |
Ошибки учёта |
Справочник ставок с датами действия, валидация при приёме |
|
Блокировки при проведении |
Зависания, таймауты |
Распараллеливание, off-peak окна, пакетная обработка |
|
Потеря связи CRM↔1C |
«Висит» статус |
Очереди/ретраи, дэшборд отставаний, ручной ре-матчинг |
|
Изменение предметки «тихо» |
Поломки в ночных обменах |
CCB для изменений, версионирование контрактов, тестовые выгрузки |
|
Смена GUID 1C |
Потерянные связи |
Всегда работать по ExternalId + таблица маппинга |
|
Очистка пометок удаления |
Потеря ссылок |
Политика удаления: только архив/блокировка, без физ. удаления |
Чек-лист SA для 1C/ERP/CRM
- Определён SoT по каждому справочнику; есть карта ключей и маппинг ExternalId↔GUID.
- Описаны контракты: JSON/CommerceML, заголовки, коды ошибок, идемпотентность.
- Согласован порядок: заказ→счёт→реализация→оплата; статусы/события туда-обратно.
- Есть DQ-правила и отчёты (НДС, ед.изм., валюта, пустые поля).
- Нагрузочный план: пакеты, окна, ретраи/лимиты, очереди.
- Версионирование (semver) и CHANGELOG, CCB на изменения.
- Наблюдаемость: correlationId, бизнес-метрики (доля отгрузок без счёта и т. п.).
- BI: схема витрин, ключи дедупликации, SLA D+1.
- Политика удаления/архивации; запрет «тихих» изменений предметки.
Практика (90–150 мин): контракт «CRM→1C:ERP: заказ→счёт→отгрузка→оплата»
Задание: подготовьте полный пакет артефактов.
-
Спецификация API 1C HTTP-сервисов
- POST /hs/orders (создать/обновить), POST /hs/invoices, POST /hs/payments, POST /hs/shipments.
- Заголовки: Idempotency-Key, Authorization, X-Correlation-Id.
- Коды ошибок: 201/202/409/422/404/503.
- Карта справочников и ключей
- Таблица SoT, ExternalId, GUID, стратегия создания/мерджа, DQ-правила.
- order.created.v1, invoice.issued.v1, shipment.posted.v1, payment.posted.v1 (минимальные поля: externalId, number, date, amount, currency, correlationId).
- Кто и когда «проводит»; окна для пакетных операций; что блокирует что (например, реализация без заказа запрещена).
- Набор «счастливый путь» и 6 негативов: неизвестная номенклатура, неверная единица, конфликт НДС, дубликат заказа, закрытый договор, блокировка.
- Статусные события (через шину)
- Порядок и ограничения
- Тест-наборы
Критерии зачёта:
- Контракты идемпотентны и покрывают ошибки.
- Есть полная карта справочников/ключей и SoT.
- Статусы синхронизируются событиями.
- Описан порядок и окна проведения.
- Тест-кейсы покрывают ключевые негативы.
Вопрос–Ответ
В: Можно ли использовать OData для записи заказов?
О: Технически возможно, но нежелательно: OData слабо контролирует бизнес-валидации/проведение. Лучше HTTP-сервис с явной логикой в модуле 1C и идемпотентностью.
В: Как бороться с расхождениями номенклатуры?
О: Единый SoT (обычно 1C), ExternalId, nightly полная сверка, отчёт «нет в 1C/нет в CRM», правила автосоздания с минимальным набором полей и последующей обогащением.
В: Нужно ли «проводить» заказ сразу при создании?
О: Обычно нет. Заказ — заявка. Проводим при готовности к отгрузке/резерву. Проводимость — бизнес-правило, зафиксируйте его явно.
В: Что делать с крупными прайсами (100k+ позиций)?
О: Инкрементальные выгрузки по modifiedSince, постранично, с контрольными суммами; ночные окна; компрессия; отдельный канал для «тяжёлых» справочников.
В: Можно ли менять GUID в 1C?
О: Внутренний GUID может измениться при переносах/слияниях. Именно поэтому требуйте и используйте внешний ключ и таблицу соответствий.
В: Как учитывать разные ставки НДС для одной номенклатуры?
О: Через виды номенклатуры/категории и «ставка НДС по документу/строке» с датами действия; в контракте обязательно передавать ставку/признак НДС.
Шпаргалка
- Сначала справочники и ключи (SoT, ExternalId↔GUID), потом — документы.
- Контракты идемпотентны, с чёткими ошибками и ретраями.
- Заказ→счёт→реализация→оплата — фиксируем порядок/блокировки.
- DQ-правила и отчёты — must have (НДС, ед.изм., пустые поля).
- Массовые операции — в окна, с пакетированием.
- События статусов — для синхронизации CRM.
- BI — SLA D+1, дедуп, бизнес-ключи.
- Любое изменение предметки/контрактов — через CCB и CHANGELOG.
