Підсумок змін Fulfillment REST API

1. Рекомендації щодо оновлення інтеграцій (Обов'язкова адаптація)

Оскільки впроваджені зміни оновлюють специфікації контракту API, для забезпечення стабільної роботи клієнтам необхідно актуалізувати власні інтеграційні рішення відповідно до нижчезазначених оновлень.

Зверніть увагу: дані зміни не підтримують зворотну сумісність.

• Реструктуризація ендпоінтів замовлень: Видалено поодиноке створення замовлення /orders. Додано пакетне створення /orders/multiple.
• Стандартизація ідентифікаторів (id / ids): Проведено глобальну уніфікацію. API відмовляється від префіксів (documentId, objectBarcodeId, documentIds, warehouseIds). Тепер використовується уніфіковане id (для поодиноких об'єктів/шляхів) та ids / destWarehouses (для масивів/списків та складів).
• Зміна мапінгу типів доставки (Delivery Type Enums): В усіх ендпоінтах замовлень 1 — Відвантаження НП, 2 — Самовивіз. Код 2 змінив бізнес-сенс (став Самовивозом замість Відвантаження НП), старий код 5 більше не підтримується.
• Виправлення друкарської помилки: Виправлено назву параметра з waybilNumber на waybillNumber (із двома літерами ll).
• Перехід на бізнес-коди складів: Замість warehouseIds впроваджено destWarehouses (приймаються рядкові бізнес-коди складів, наприклад "Boyarka").
• Зміна типу даних поля status у відповіді: В ендпоінті перевірки статусу тип status змінено з рядка (string) на integer (повертає ID статусу).
• Створення ШК товару: Прибрано обов'язкові одиниці виміру під час генерації/створення ШК товару.

2. Зміни у функціональній логіці (Отримання залишків)

• Незалежність від наявності штрихкоду: Інформація про товари повертається незалежно від того, є у товару штрихкод чи ні.
• Диференційована логіка відображення залишків: Без конкретизації номенклатури (без параметрів ids, objectArts, objectTitles) система повертає тільки товари з реальним залишком (>0). З точковими фільтрами товари повертаються завжди, навіть якщо залишки нульові.

3. Оновлення валідації та нормалізації даних

• Автоматична нормалізація (Trimming): Усі вхідні текстові значення (string) очищаються від пробілів на початку та в кінці (Trimming), а порожні рядки конвертуються в null.
• Сувора валідація JSON payload: За наявності зайвих/незадокументованих ключів у Body-запиті система повертає помилку 422 Unprocessable Entity.
• Консистентність даних: Унікальність GUID перевіряється в межах запиту. Впроваджено умовну обов'язковість полів (наприклад, quantity обов'язкове при передачі objectId).

4. Зміна формату JSON-payload та Query-параметрів

• Root-level Array: Масиви даних для пакетних операцій передаються безпосередньо на кореневому рівні root-level array ([...]), без обгортки об'єктом.
• Query-параметри у GET-запитах: Для GET-запитів з масивами скасовано розділення комою. Необхідно дублювати ключ: ?ids[]=val1&ids[]=val2.