Названия удобны человеку, коды — связи между системами. Эти роли нельзя смешивать. При переименовании подразделения его документы не обязательно должны переходить к новому объекту, а одинаковые названия не делают два объекта одним.
Владелец каждого справочника
В учебной схеме учётная система содержит места хранения, а кабинет партнёра — точки получения заказа. Для части точек есть прямое соответствие складу, для других заказ комплектуется из нескольких мест. Прежде чем писать преобразование, определяют владельца обоих наборов и основание сопоставления.
Владелец справочника отвечает за создание, изменение и закрытие записи в своей системе. Владелец таблицы соответствий отвечает за связь между наборами. Это могут быть разные люди. Если интегратор сам придумывает соответствие неизвестного кода, техническая настройка незаметно превращается в бизнес-решение.
Зафиксируйте смысл полей: идентификатор, отображаемое название, признак активности и допустимый период использования. Уточните, можно ли повторно выдать старый код новому объекту. Даже редкое повторное использование способно изменить смысл давно созданных документов.
Таблица соответствий кодов
Сопоставление должно быть явным и иметь проверяемое основание. Для учебного примера возьмём склад WH-02 и точку получения PICKUP-NORTH. Названия могут различаться; связь действует потому, что её подтвердил владелец процесса. Отсутствие соответствия — отдельное состояние, а не повод выбрать первую похожую строку.
| Источник и код | Получатель и код | Основание | Состояние |
|---|---|---|---|
| Место хранения WH-02 | Точка PICKUP-NORTH | Подтверждённая выдача с этого склада | Активно |
| Место хранения WH-03 | Не установлено | Нет решения владельца процесса | Требует уточнения |
| Подразделение DEP-02 | Не применяется | Это группа сотрудников, а не место выдачи | Исключено из данного обмена |
В рабочую матрицу добавляют дату действия и ссылку на решение. Когда связь неоднозначна, её модель описывают отдельно: например, выбор склада по виду товара. Строка «один код соответствует нескольким» без правила выбора оставляет ошибку будущей реализации.
Такая матрица дополняет подготовку интеграции. Она показывает, какие решения уже существуют, а какие нельзя получить из одного перечня полей API.
Переименование без смены идентичности
В примере склад WH-02 меняет название с «Северный» на «Распределительный». Если физически и организационно это тот же объект, связь с PICKUP-NORTH может сохраниться. Обмен должен обновить отображаемое название, не создавая новую запись только из-за текста.
Однако похожая ситуация может означать закрытие старого объекта и открытие нового. Решение принимают по бизнес-факту, а не по совпадению кода. Для истории нужно понимать, с каким объектом был связан документ на момент создания и какое название показывать сегодня.
Выберите правило отображения: текущее название, название на дату документа или оба. Не обновляйте исторический документ автоматически, если процесс требует сохранить исходное обозначение. При смене связи таблицу соответствий версионируют так, чтобы объяснить уже обработанные записи.
Неизвестный код и ручное решение
В кабинет приходит WH-03, которого нет в согласованной матрице. Безопасное для процесса поведение нужно определить заранее: остановить конкретную запись, поместить её в очередь уточнения или передать без привязки, если это допускается. Ни один из вариантов не подходит всем системам.
Карточка уточнения содержит исходный код, вид объекта, документ, в котором он встретился, и ожидаемое назначение. Ответственный либо добавляет подтверждённую связь, либо объясняет, почему объект исключён. После решения запись можно обработать по новой версии матрицы, сохранив первоначальную причину остановки.
Проверьте четыре случая: переименование известной записи, новый код, закрытый объект и одинаковое название у двух разных объектов. Затем убедитесь, что исправление одного соответствия не меняет несвязанные строки. Итогом становится заполненная матрица и понятный порядок уточнения. Это более определённый предмет передачи подрядчику, чем просьба «синхронизировать справочники»; границы ответственности закрепляют в контракте модуля.
