# Карта ответственности: как заполнить

Версия: 31.10.2026. Шаблон для выбора границ изменения системы. Три заполненных варианта — учебные архитектуры, а не подтверждённые подключения Skirbo или другого продукта.

## Файлы

- `m01-responsibility-map.xlsx`: лист «Карта» для заполнения и лист «Три примера» с 18 строками.
- `m01-responsibility-blank.csv`: пустой шаблон на шесть объектов.
- `m01-responsibility-examples.csv`: те же три учебные архитектуры в переносимом формате.

CSV: UTF-8 с BOM, разделитель — запятая, строки заключены в кавычки. При импорте в таблицу выбирайте запятую как разделитель и текстовый тип для ключей. Исходные значения примеров не содержат клиентских данных. Сохранение CSV не сохраняет оформление XLSX.

## Результат заполнения

Для выбранного участка понятно, какая система меняет каждую сущность, что получают другие системы, как отличают повтор от новой операции и как замечают расхождение. Ответ «данные синхронизируются» недостаточен: назовите событие и проверяемое подтверждение.

Паспорт своей карты запишите рядом с таблицей или в отдельном рабочем документе:

- Компания/подразделение: ______
- Процесс и проблема: ______
- Склады, владельцы товара, кабинеты: ______
- Действующие системы, версия и тариф: ______
- Предлагаемый участок изменения: ______
- Ответственный за решение: ______
- Дата проверки: ______
- Результат: оставить текущую схему / настроить имеющуюся / добавить рабочее место / добавить WMS / исследовать дальше.
- Основание результата и незакрытые вопросы: ______

## Поля карты

| Поле | Что написать |
|---|---|
| Архитектура | Свой вариант и область действия. Для другой зоны или владельца создайте отдельную строку. |
| Объект | Товар, остаток, резерв, заказ, операция, документ. Добавляйте строки, если внутри объекта разные владельцы полей. |
| Точная область данных | Например: физическое количество по ячейке; коммерческий статус заказа; факт упаковки. Эти состояния нельзя смешивать. |
| Устойчивый ключ | Набор полей, по которому запись узнаётся повторно. Для заказа обычно нужны площадка, кабинет, заказ и отправление. Для товара — владелец, SKU и вариант. Проверьте реальные идентификаторы своих систем. |
| Система-источник | Где находится подтверждённое состояние этой области. Одна система может владеть товарным вариантом, другая — контентом карточки. |
| Кто меняет | Конкретная роль и штатный механизм изменения. Укажите, кто разбирает исключение. |
| Получатель | Кто читает копию или принимает событие. Если получателей несколько, перечислите подтверждение каждого. |
| Событие передачи | Что запускает обмен: подтверждение приёмки, изменение строки заказа, завершение передачи. Периодическая отправка также должна иметь условие и период. |
| Что передаём | Поля, единицы, состояние, версия и связь с исходной операцией. Опишите смысл количества, а не только название поля. |
| Подтверждение | Что можно проверить у получателя: сохранённую запись, принятый документ, количество, состояние. Отправка запроса сама по себе недостаточна. |
| Правило конфликта | Что делать с повтором, старой версией и одновременным изменением. Если механизм не подтверждён, так и напишите. |
| Сверка | Какие независимые значения сравнить на одном срезе. Сохраняйте владельца, склад, вариант и единицы. |
| При ошибке | Что временно ограничивается и кто выясняет итог. Не отправляйте повторное списание только потому, что не пришёл ответ. |
| Основание | «Наблюдали в тесте» со ссылкой на протокол; «описано поставщиком» со ссылкой; «требует проверки». Для учебного варианта оставьте его учебный статус. |

## Порядок работы

1. Возьмите один обычный заказ и одно исключение: отмена, недостача или повтор события. Работайте с обезличенным примером.
2. Сначала заполните текущую схему, затем скопируйте карту для предлагаемой. Не меняйте текущую карту задним числом.
3. Пройдите по всем шести объектам. На вопрос «где это исправляют?» должен быть один ответ для каждого конкретного поля и области.
4. Отдельно назовите отправителя остатков в каждый канал. Две системы могут читать один запас, но не должны независимо публиковать конкурирующие значения без согласованного порядка.
5. Проверьте термин «Доступно». В примерах используется запас, свободный для немедленной отгрузки по новым заказам: физическое наличие минус карантин, открытые резервы и согласованный буфер. Будущие поступления в него не входят. Резерв и карантин не пересекаются. Это договорённость примера, не универсальное правило площадок.
6. Пройдите цепочку повторно с тем же ID операции. В проектируемой схеме повтор должен возвращать прежний результат либо быть распознан. Реальное поведение нужно показать на тесте.
7. Зафиксируйте решение и доказательства. Пустая ячейка «Подтверждение» или неизвестный владелец резерва означает незакрытый вопрос для выбранного участка.

При сверке резерва сравнивайте подтверждённые выделения по строкам заказа. Не приравнивайте к ним все открытые обязательства: при дефиците часть количества может оставаться без обеспечения. Запишите отдельно заказано, выделено и не обеспечено, а также политику полного или частичного выделения. Один бизнес-резерв может включать несколько адресных выделений; запрет второго резерва означает отсутствие независимого повторного вычитания в другой системе, а не обязательную единственную техническую запись.

## Как читать примеры

**A. Учёт и сборка.** Учёт сохраняет каталог, физическое наличие, резервы и документы. Сервис сборки владеет проверкой товара и упаковкой. Внешнее состояние заказа задаёт площадка. Подходит для проверки отдельного рабочего места при устойчивом основном учёте.

**B. Учёт и WMS.** Учёт сохраняет каталог и документы. WMS подтверждает физические операции и распределяет годный запас. Учётная копия резерва не вычитает его второй раз. Это пример разделения ответственности, а не готовый регламент внедрения.

**C. Платформа и склад.** Платформа сохраняет торговый каталог и работу с каналами, WMS ведёт физический склад и единый резерв, существующий внешний учёт оформляет документы. Наличие API у платформы не подтверждает обмен с выбранной WMS. Возможность такого разделения, повторы и подтверждения проверяются отдельно.

## Учебная проверка количества

Пусть физически есть 10 единиц, из них 2 в карантине, 3 зарезервированы из годного запаса, ещё 5 ожидаются. Буфер равен 0. Для немедленной отгрузки по новым заказам в этой модели свободно `10 − 2 − 3 − 0 = 5` единиц. Ещё три годные единицы выделены прежним заказам. Показатель с включённым ожиданием может дать другое число: `10 + 5 − 3 = 12`. Подставлять 12 вместо 5 без определения полей нельзя.

Ни один файл этого набора не выполняет синхронизацию, не меняет складские данные и не подтверждает готовность конкретного программного продукта.