WHAT’S NEW

EDI Network (продукт «Е-ТТН»)

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого зробили?

Вплив на роботу по API/FTP?

Заблоковано використання сервісу Е-ТТНv2 для створення, підписання та надсилання транзакцій

Заблоковано використання сервісу Е-ТТНv2 для наступних дій. Вимкнено можливість створення, підписання та надсилання транзакцій:

  • ТТН v2;

  • Коригуючих актів до ТТН v2;

Також заблоковано формування як чернеток, так і будь-яких подальших транзакцій після відправки ВВ (вантажовідправником).

Основна діяльність з оформлення, підписання та обміну ТТН і коригуючими актами здійснюється в EDI Network

Для всіх користувачів сервісу E-ТТНv2

Так

Розширено поля вводу для перегляду назв та адрес контрагентів у чернетках документів

Тепер у чернетках повністю відображаються назви та адреси контрагентів в наступних документах, якщо вони довгі:

  • Товарно-транспортна накладна (ТТН) та попередня ТТН;

  • Коригуючі акти до ТТН;

  • Заявка на транспортування та Підтвердження заявки.

Для зручного перегляду всієї інформації по контрагенту без додаткових дій:

  • Користувач одразу бачить повну назву та адресу контрагента при його виборі у полі.

  • Це особливо важливо, коли в системі є декілька контрагентів із подібними назвами або коли назва включає важливі реквізити (наприклад, філії, склади, підрозділи).

Покращення точності і швидкості роботи:

  • Менше ризику помилково обрати не того контрагента.

  • Підвищення ефективності при заповненні документів та економія часу для користувача.

Для всіх користувачів сервісу EDI Network

Ні

**20.05.2025**

Маркет

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого робили?

Вплив на роботу по API/FTP?

Доопрацювали логіку розрахунку кількості палет при інтегрованій відправці замовлення

Доопрацювали логіку автоматич ного розрахунку кількості палет при інтегрованій відправці замовлення. Якщо в прайс-листі товарна позиція містить дані про кількість одиниць у коробці та кількість коробок на палеті, система тепер самостійно вико нує точний розрахунок кількос ті палет. Навіть якщо покупець не передає інформацію про кількість палет у замовленні, система автоматично розраховує цей показник на основі прайс- листа.

Щоб забезпечити коректну логістику та автоматизацію обліку замовлень, мінімізувати ручне втручання і уникнути неточностей у доставці.

Для всіх користувачів сервісу Маркет

Так

Посилання на XML специфікацію

Доопрацьовано логіку роботи обмеження «Підтип замовлення»

  1. Реалізовано доопрацювання логіки обмеження «Підтип замовлення» для покупця. Якщо таке обмеження встано влено, поле «Підтип замовл ення» у кошику стає обов’я зковим. До його заповнення обмеження по замовленню та товарам не застосовуються. Додатково, у залежності від вибраного значення («Реалізація», «Відправка на відповідальне зберіган ня» чи «Зняття з відповіда льного зберігання»), систе ма застосовує відповідну логіку перевірок.

  2. Реалізували перевірку знач ення <ORDRTYPE> у документ ах ORDERS (family = 8, DOCTYPE = О або R), що над ходять через FTP або API. Якщо для зв’язки Продавець → Покупець встановлено обм еження «allowed _ order _ subtype», документ приймається лише за наявності відповідного значення у обмеженні (1, 2, або 3), інакше — відхиляється.

  3. Для документів ORDERS (family = 8, DOCTYPE = О або R) з ORDRTYPE = 3 (Зняття з відповідального зберігання), реалізовано виняток: система не виконує перевірки на відпо відність обмеженням по замовленню та товарам

  1. Щоб унеможливити створення замовлень із некоректними типами при встановлених бізнес- обмеженнях між продавцем і покупцем.

  2. Для гнучкості роботи з замовленнями, що знімаються з відповідального зберігання: вони не потребують контролю по кількості, обмеженнях або асортименту, оскільки стосуються вже придбаних товарів.

  3. Це знижує ризики дублювань або помилок, покращує інтеграцію з зовнішніми системами та підвищує надійність бізнес-процесів.

Для всіх користувачів сервісу Маркет

Так

Посилання на XML специфікацію

Посилання на API документацію

Переробка сховища та міграція прайс-листів

На нашій стороні оновили логіку зберігання товарів у сервісі «Маркет». Також виконали міграцію товарів у нову структуру без зміни існуючих процесів для користувачів.

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

Важливо! Якщо ви помітили будь-які неточності в даних товарів або прайс- листів – будь ласка, одразу зверніться до нашої технічної підтримки для оперативного аналізу та усунення.

Так

EDI Network (продукт «Е-ТТН»)

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого робили?

Вплив на роботу по API/FTP?

Отримання всіх наявних коригуючих актів до ТТН новими учасниками

Доопрацювали логіку автоматичного створення Актів у ТТН. Тепер, при додаванні нового учасника в ТТН через транзакцію, система автоматично створює для нього всі наявні коригуючі Акти, які вже були створені по цій ТТН та мають позитивно завершений життєвий цикл (ЖЦ). Попередня логіка залишилась актуальною — Акти створюються всім поточним учасникам після завершення ЖЦ відповідного Акта.

Щоб забезпечити цілісність документообігу для нових учасників ТТН, гарантувати, що всі сторони мають повний набір необхідних документів для обробки та зберігання

Для всіх користувачів сервісу EDI Network

Ні

Додавання нового поля «Серія, номер водійського посвідчення» при реєстрації та в GLN, заповнення назви водія та перевізника у документах

  1. Реалізували нове поле «Серія, номер водійського посвідчення» при реєстрації та в GLN. Якщо ФОП виступає і перевізником, і водієм, він може одразу внести дані посвідчення під час створення акаунта або редагування GLN.

  2. У подальшому в ТТН та супровідних документах такий GLN можливо використовувати як:

    • Водія — у полі назва буде відображатись ПІБ фізичної особи.

    • Перевізника — назва включатиме форму власності ФІЗИЧНА ОСОБА- ПІДПРИЄМЕЦЬ + ПІБ.

Для зручності та автоматизації роботи з документами в тих випадках, коли одна особа виконує роль і перевізника, і водія. Це усуває потребу створювати окремі GLN

Для всіх користувачів сервісу EDI Network

Ні

**06.05.2025**

EDI Network

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого зробили?

Вплив на роботу по API/FTP?

Доопрацювання запису новихтоварних позицій з замовлення в товарний довідник

Реалізували запис нової товарної позиції, яка присутня в замовленні не лише в Загальний довідник для постачальника, а також створення її в розрізі товарного довідника мережі від якої отримано замовлення з новим товаром

Для автоматизації наповнення товарного довідника, що створений постачальником під певну роздрібну мережу

Для всіх користувачів сервісу EDI Network

Ні

Новий функціонал Розділення Замовлення на декілька накладних

Реалізували функціонал,що дозволяє постачальникам, які працюють на web платформі витрачати менше часу на формування документа Повідомлення про відвантажен ня, а саме заповнення табличної частини за кількісними та номенклатурни ми характеристиками у випадках, коли поставка розбивається на декілька накладних.

Для оптимізації роботи постачальника:

  1. Мінімізується час на формування документів у відповідь, у випадках коли замовлення розподіляється на декілька накладних

  2. Підвищення швидкості обробки замовлень

Для всіх користувачів сервісу EDI Network

Ні

Новий тип документа Дані про продукт

Реалізували новий документ Дані про продукт (PRODAT), його візуальне відображення на web платформі, опрацювання документа на FTP, API

Для можливості організації роботи з електронними документами між 3PL операторами, та їх Контрагентами реалізували новий тип документа Дані про продукт

Для всіх користувачів сервісу EDI Network

XML-специфікація та приклад документа буде опубліковано

Е-Сертифікати

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого робили?

Вплив на роботу по API/FTP?

Новий тип структурова ного документа Декларація виробника/ постачальника

Реалізували новий структурова ний документ Декларація виробника/постачальника (CERTDOC ), автоматизували створення картки декларації та її візуалізація у форматі pdf у сервісі Е-Сертифікати, опрацювання документа на FTP, API

  1. Для розширення функціоналу сервісу

  2. Для оптимізації роботи при створенні сертифікатів типу Декларація виробника/ постачальника. Документи можна імпортувати з облікової системи постачальника без ручного введення — це особливо корисно при великих обсягах оменклатури.

Для всіх користувачів сервісу Е-Сертифікати

XML-специфікація та приклад документа буде опубліковано

EDI Network (продукт «Е-ТТН»)

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого робили?

Вплив на роботу по API/FTP?

Адаптивні версії коригуючих актів до ТТН

Оптимізували функціонал для опрацювання та підписання документів з мобільних пристроїв для ТТН та коригуючих актів до ТТН.

  1. Щоб забезпечити зручну роботу з документами безпосередньо з мобільного телефону

  2. Щоб користувачі могли ефективно опрацьовувати коригуючі акти до ТТН навіть у дорозі

Для всіх користувачів сервісу EDI Network

Ні

Доопрацювання логіки автоматичного розраху нку значень прописом

Доопрацювали логіку автоматич ного розрахунку значення прописом у блоці «Загальні дані» в ТТН.

  1. Щоб підвищити точність і відповідність між числовим і прописним значенням.

  2. Для автоматизації заповнення та зменшення помилок при створенні документів

Для всіх користувачів сервісу EDI Network

Ні

Заблокувати можливість створення ТТН на підставі кількох DESADV для вантажоодержувача АТБ (журнал документів)

Заблоковано можливість створення ТТН на підставі кількох повідомлень DESADV у Журналі документів для вантажоодержувача АТБ.

  1. Щоб гарантувати відповідність вимогам бізнес-процесу мережі АТБ, де 1 DESADV = 1 ТТН

  2. Для забезпечення коректного обліку та контролю постачань у мережі

Для всіх користувачів сервісу EDI Network

Ні

Перевірка на обов’язковість заповнення Адреси компанії в ТТН та Актах для АТБ

Реалізували перевірку обов’язковості заповнення адреси компанії (PostalTradeAddress) у документах ТТН та Актах для мережі АТБ. При створенні чернетки документа через /api/eds/doc/ettn/ttn з параметром full_validate, тепер додатково перевіряється наявність блоку PostalTradeAddress у відповід ному блоці ____TradeParty (відправник, отримувач, перевізник тощо).

Щоб забезпечити відповідність бізнес-вимогам мережі АТБ, де наявність адреси компанії є обов’язковою умовою для подальшої обробки документа

Можливість налаштува ти перевірку - для всіх користувачів сервісу EDI Network. Перевірка працює для всіх Вантажовідправни ків що працюють з АТБ

Так

Посилання на XML специфікацію

Посилання на опис API

Перевірка наявності посади підпису та захищеності носія при підписанні ТТН та Актів до ТТН для мережі АТБ

  1. Додали перевірку типу носія підпису при підписанні ТТН та Актів до ТТН для компаній- учасників мережі АТБ. Дозволені носії: Токен, Хмарний, Гряда, Дія. Файлові ключі заборонено.

  2. Реалізовано перевірку наявності заповненої Посади (subjTitle) у підписі компанії. Виняток: для ролі «Водій» посада не є обов’язковою.

Для забезпечення відповідності політикам безпеки та стандартам документообігу мережі АТБ.

Можливість налаштува ти перевірку - для всіх користувачів сервісу EDI Network. Перевірка працює для всіх Вантажовідправни ків що працюють з АТБ

Так

Посилання на інструкцію

Доопрацьовано реєстра цію транзакції ТТН по завершенню ЖЦ Акта Розвантаження, якщо Перевізник та Склад мають один GLN)

Оптимізували логіку підписання транзакції ТТН у випадках, коли Перевізник і Проміжний склад мають один і той самий GLN. Відтепер, після успішного завершення життєвого циклу Акта Розванта ження на проміжному складі, компанія з таким GLN може підписати транзакцію ТТН від ролі Проміжного складу, без помилок валідації.

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

Для всіх користувачів сервісу EDI Network

Ні

Акт розбіжностей до ТТН: зробити опційним блок кількісних характеристик

«Зробили опційними до заповнення блоки кількісних характеристик у Акті розбіжностей до ТТН, а саме:

  1. DisagreementSubjectSupply ChainConsignmentItem

  2. DisagreementSubjectSupply ChainConsignmentSummary

Це реалізовано шляхом оновлення XSD-схеми, що дозволяє не включати ці блоки у випадках,коли кількісні характеристики не є предметом розбіжностей.

Гнучкість у використанні документа: Не у всіх випадках при створенні Акта розбіжностей фіксуються саме кількісні характеристики. Якщо, наприклад, розбіжність стосується лише температурного режиму чи цілісності упаковки — заповнення кількісних блоків є зайвим.

Важливо! Якщо документ підлягає реєстрації в ЦБД (Централізованій базі даних), то ці блоки залишаються обов’язковими відповідно до вимог їхньої XSD-схеми. У таких випадках відсутність цих блоків призведе до помилки реєстрації документа.

Для всіх користувачів сервісу EDI Network

Так

Посилання на інструкцію

EDIN Driver

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого робили?

Вплив на роботу по API/FTP?

Збільшено термін дії життя сесії у мобільному додатку

Збільшили термін дії сесії в мобільному додатку для водіїв до 120 днів.

Щоб забезпечити стабільну авторизацію без частого повторного входу. Для зручності користування додатком водіями у щоденній роботі.

Для всіх користувачів сервісу EDI Driver

Ні

**22.04.2025**

EDI Network

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого зробили?

Формування Універсального документа на основі Акту виконаних робіт

Реалізували можливість формування Універсального документа (CONDRA) на основі Акту виконаних робіт

  1. Відповідність вимогам процесу співпраці з торгівельною мережею

  2. Спрощення документообігу для постачальників

Для всіх користувачів сервісу EDI

Підключили Універсальний документ до функціоналу погодження

Реалізували можливість відправити на погодження Універсальнй документ (CONDRA)

  1. Внутрішнє погодження стало доступним не лише для структурованих документів

  2. Уникається необхідність погоджувати документи через пошту або вручну — весь процес централізовано та доступно в межах однієї платформи

  3. Підвищення прозорості та зручності

Для всіх користувачів сервісу EDI Network

Е-Сертифікати

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого робили?

Збереження пошукових запитів у сервісі Е-Сертифікати

Реалізували можливість зберігати пошукові запити

Це один із кроків до більш інтуїтивного та персоналізованого сервісу.

  1. Підвищення ефективності роботи користувачів. Збереження пошуку дозволяє уникати повторного введення параметрів пошуку - користувач може одним кліком повернутись до потрібного фільтру

  2. Зменшення часу на виконання типових операцій

Для всіх користувачів сервісу Е-Сертифікати

Отримання сповіщень про надання доступу до документів якості

Реалізували:

  1. можливість отримання сповіщень про надання доступу до Сертифікатів

  2. керування сповіщеннями (активація/відключення, канал отримання - e-mail, push-повідомлення)

  1. Підвищення поінформованості користувачів. Користувач миттєво дізнається, що йому надано доступ до нового документа — не потрібно постійно перевіряти вручну.

  2. Прозорість процесів.

  3. Швидке реагування. Сповіщення дозволяють одразу ознайомитися з опублікованими сертифікат ами, що важливо у випадках термінових змін.

Для всіх користувачів сервісу Е-Сертифікати

Маркет

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого зробили?

Можливість пошуку у виборі покупців при Масовому завантаженні прайс-листів

Додано можливість пошуку покупців і груп за назвою при масовому завантаженні прайс- листів.

Щоб прискорити та спростити роботу з великим списком покупців або груп, уникнути помилкового вибору, зберегти вже обрані значення та зробити процес завантаження прайсів зручнішим та інтуїтивно зрозумілим.

Для всіх користувачів сервісу Маркет

Доопрацьовано прайс-лист з ACTION=2,3,4

Доопрацювали можливість по FTP додавати, оновлювати або видаляти товарні позиції з Прайс-листа

Щоб продавці могли автоматично керувати товарними позиціями у прайс-листі через FTP — додавати, оновлювати або видаляти їх без ручного втручання. Це пришвидшує оновлення даних і зменшує кількість помилок.

Для всіх користувачів сервісу Маркет

Збереження дерева категорій окремо для кожного покупця чи групи покупців

Доопрацювали логіку збереження зв’язку між товарними позиціями та деревом категорій: тепер для кожного прайс-листа, навіть із однаковими позиціями, зберігається своє унікальне дерево категорій. Додали додаткові параметри (зокрема,box_qty) до переліку, при зміні яких створюється окремий запис прайс-листа на рівні зв’язки Продавець – Покупець.

Для забезпечення гнучкого налаштування прайсів: кожна група або покупець може отримувати унікальне відображення товарів — як за характеристиками, так і за категоріями. Щоб уникнути неочікуваного перезапису характеристик або структури категорій у прайс-листах інших покупців/груп при оновленні одного з них.

Для всіх користувачів сервісу Маркет

EDI Network (продукт «Е-ТТН»)

Доопрацювання

Що зробили?

Навіщо зробили?

Для кого зробили?

Реєстр документів в xls для Заявки та Підтвердження заявки на транспортування.

Реалізовано можливість вивантаження реєстру документів у форматі XLS на веб-платформі для двох нових типів документів:

  1. Заявка на транспортування

  2. Підтвердження заявки на транспортування.

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

Для всіх користувачів сервісу EDI Network

Вивантаження архіву документів для Заявки та Підтвердження заявки на транспортування.

Реалізовано можливість вивантаження архіву документів через веб-платформу для типів:

  1. Заявка на транспортування

  2. Підтвердження заявки на транспортування.

Архів формується за обраний період (до 1 місяця) та надсилається на електронну пошту користувача у форматах .p7s, .xml або .pdf.

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

Для всіх користувачів сервісу EDI Network

Реалізовано можливість опрацювання Акту перевантаження новим Водієм.

Реалізовано можливість опрацювання Акту перевантаження новим водієм. Якщо під час перевезення змінюється лише водій, акт не переходить автоматично у завершений стан, як це було раніше.

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

Для всіх користувачів сервісу EDI Network

Доопрацьовано транзакцію оновлення ТТН до початку ЖЦ Акта завантаження на проміжному складі.

В транзакції до ТТН на початку ЖЦ Акта завантаження на проміжному складі записуємо в UaSignatureStorage - роль Проміжного складу «WD», замість «WH».

Дозволяє правильно ідентифікувати роль Проміжного складу при підписанні документів.

Для всіх користувачів сервісу EDI Network