ERP показує замовлення як виконане, WMS — як відвантажене, а TMS — як доставлене частково. Це може бути коректним описом різних об’єктів, поки інтерфейс не зводить їх до одного слова. Архітектору та операційному керівнику потрібно вирішити, хто володіє кожним фактом і як із цих фактів утворюється зрозумілий клієнтський стан. Пропонуємо модель, у якій події мають власників, а загальний статус є пояснюваним результатом правил.
Розділіть об’єкти перед розподілом відповідальності
Умовне замовлення O-41 містить десять палет і виконується двома відправленнями: S-1 на шість палет та S-2 на чотири. WMS відвантажила обидва, але одержувач прийняв лише S-1. TMS має показати часткову доставку замовлення, навіть якщо перший рейс завершений. ERP може вже мати документ відвантаження, проте це не підтверджує отримання другої частини вантажу.
Зробіть карту об’єктів: замовлення клієнта, рядок, складське відправлення, транспортне завдання, зупинка, доказ приймання та розрахунок. Для кожного визначте стабільний ключ і зв’язки. Один рейс може містити кілька замовлень, а одне замовлення — кілька рейсів. Тому номер рейсу не підходить як універсальний ключ усіх інтеграцій і не повинен заміняти ідентифікатор вихідного замовлення.
GS1 EPCIS визначає модель подій видимості та контекст бізнесового кроку. Для нашої архітектури корисний сам принцип опису того, що відбулося з конкретним об’єктом. Пропоновані нижче правила володіння статусами є редакційною методикою: стандарт не призначає ERP, WMS або TMS власником усіх можливих станів вашого підприємства.
Джерела: [1]
Призначте джерело факту та спосіб його виправлення
Власник WMS підтверджує факт відвантаження й кількість, транспортна операція через TMS — доставку на конкретній зупинці, фінанси через ERP — проведений розрахунок. Клієнтська обіцянка належить визначеному комерційному процесу. Якщо її ведуть в ERP, зміна надходить звідти; TMS не повинна переписувати погоджене вікно лише через новий прогноз прибуття.
Для кожної події задайте ідентифікатор, тип, об’єкт, версію, час факту, час запису та джерело. Виправлення передає посилання на попередній факт і причину. Не видаляйте історію помилкового підтвердження: інакше незрозуміло, чому бухгалтерія або клієнт уже отримали повідомлення. Право виправляти факт відрізняється від права читати його чи змінювати візуальне представлення.
Розрахунок загального стану виконує визначений сервіс або система за опублікованим правилом. У прикладі доставка O-41 завершена лише тоді, коли обидва відправлення мають прийняті результати щодо всіх належних палет. Якщо другу частину повертають, правило показує окремий результат виконання з поверненням. Воно не повинно підміняти повернення успішною доставкою заради закриття замовлення.
Опишіть контракт обміну та реакцію на повтор
OpenAPI дає формат опису HTTP API. У контракті вашого обміну потрібно також узгодити значення статусів, допустимі версії та відповідь на бізнесову помилку. Технічне підтвердження прийняття повідомлення не є доказом завершення операції. Якщо подію прийнято в чергу, інтерфейс має відрізняти це від застосування до замовлення та від результату перевірки даних.
Повтор із тим самим ідентифікатором не створює нового відвантаження. Подія старішої версії не стирає новішу, а невідомий об’єкт потрапляє до черги розбору з відповідальним. Повторні спроби доставки повідомлень мають обмеження, спостережуваний стан і процедуру відновлення. Тривала помилка потребує рішення оператора інтеграції; нескінченне мовчазне повторення приховує розрив між системами.
Виберіть допустиму затримку відображення для кожного сценарію, а не одну норму для всього обміну. Диспетчеру потрібен свіжий факт готовності перед виїздом, фінансова звірка може мати інший цикл. Коли дані старіші за погоджену межу, показуйте час останнього підтвердження та застереження щодо рішення. Не маскуйте відсутність свіжого факту зеленим загальним статусом.
↔ Прокрутіть таблицю горизонтально
| Факт | Власник у моделі | Що ще не підтверджено |
|---|---|---|
| Готовність вантажу | WMS і склад | Виїзд автомобіля |
| Відвантаження | WMS і склад | Приймання одержувачем |
| Результат доставки | TMS і транспортна операція | Фінансове закриття |
| Проведений розрахунок | ERP і фінанси | Відсутність відкритої претензії |
Джерела: [2]
Прийміть модель через суперечності та відновлення
Періодична звірка порівнює не тільки кількість повідомлень, а й очікувані бізнесові об’єкти. Для O-41 повинні існувати два відправлення із сумою десять палет та результати їх доставки. Якщо S-2 відсутнє в TMS, інтеграційна команда отримує конкретний пропуск. Якщо запис є, але кількість інша, розбіжність передається власнику вихідного факту, а не виправляється довільно в усіх базах.
У приймальному тесті доставте події не за порядком, повторіть одну з них і затримайте підтвердження S-2. Потім виправте кількість через дозволену процедуру. Перевірте загальний стан, повідомлення клієнту та фінансовий контур після кожного кроку. Збережіть версію правила агрегації, вхідні події, результат обчислення й рішення щодо суперечності. Це дає можливість пояснити статус у конкретний момент часу.
Для контролю щогодини рахуйте частку подій, отриманих за попередні 24 години й досі не застосованих, серед усіх отриманих за цей період; при нульовому знаменнику показуйте відсутність даних. Вік найстарішого пропуску — поточний час мінус час першого виявлення у звірці; перераховуйте його щохвилини. Ручні виправлення групуйте за причиною за завершену добу. Джерела — журнал інтеграції та реєстр звірок, власник — керівник підтримки обміну. Це запропонований режим, який узгоджують з операцією. Поріг дії залежить від наслідку пропуску. Почніть із одного спірного статусу та перевірте, хто може підтвердити його вихідні факти.
Контрольний список
- Побудуйте карту замовлення, відправлень, рейсів, зупинок і доказів приймання.
- Закріпіть власника кожного факту та процедуру виправлення його версії.
- Опишіть повтори, затримки, невідомі об’єкти й чергу ручного розбору.
- Звірте бізнесові об’єкти та відтворіть загальний стан із збережених подій.
Запитання та відповіді
Чи потрібна одна головна система для всіх статусів?
Потрібне одне узгоджене правило представлення, але факти можуть належати різним системам. Оберіть власника розрахунку загального стану та залиште походження складових доступним.
Чи можна дозволити ручне виправлення статусу?
Так, якщо це окрема керована дія з причиною, повноваженням і журналом. Вона має або виправляти вихідний факт, або явно позначати виняток, а не створювати приховану другу правду.