Чому PUESC відхиляє RMPD і що виправити за кодом RMPD500

Код RMPD500 це відмова реєстру PUESC: заявку не зареєстровано, номера немає, а у відповіді перелік рядків із кодом правила, наприклад R01.CodeLatin, і полем, якого він стосується. Виправляти треба всі рядки разом і надсилати нове RMPD100, а не RMPD101. За нашими даними, з 242 заявок відмову отримала кожна четверта.

Коротко: RMPD500 повертає код правила у форматі R01.CodeLatin, і саме код каже, що виправляти · кирилицю в назві або місті відправника (R01) реєстр відхиляє, бо приймає лише латиницю з польськими літерами · польська адреса без поштового індексу у форматі 00-000 (R02) відхиляється, а слово BRAK в індексі не рятує · дата початку в минулому або дата закінчення далі ніж 9 днів від подання (R06, R15, R26) відхиляється в момент подання, зміни чи анулювання · локатор, не активований для SENT (R30), реєстр не приймає навіть з правильною контрольною сумою · перехід кордону і номер дороги мусять збігатися зі словником PUESC · закриття RMPD103 реєстр зараз не приймає взагалі (R16), і це не помилка даних.

Диспетчер натискає «Надіслати» о 23:40, бо фура виїжджає о шостій. Замість номера повертається RMPD500: «R01.CodeLatin: Pole: [GoodsSenderName] zawiera znaki, które są niedozwolone w kodowaniu Latin1+PL». Він виправляє назву, надсилає знову, і тепер приходить «R02.PostalCodePl: niewłaściwy kod pocztowy PL: [nadawca, BRAK]». Третя спроба проходить о 00:15. Кожен такий рядок це правило реєстру, і кожне можна пройти з першого разу, якщо знати, що воно перевіряє.

Ця стаття розбирає ті коди, які реєстр повертає перевізникам насправді, за даними нашої платформи: 136 відмов на 242 заявки, надіслані через Sigil з 24 червня по 15 вересня 2026 року. Це не статистика ринку, а те, що бачить одна платформа з кількома десятками перевізників.

Що таке RMPD500 і як його читати

RMPD500 це технічне повідомлення реєстру з відмовою. Його описує Specyfikacja Techniczna Komunikatów Systemu RMPD від 20 листопада 2024 року: кожна заявка проходить перелік правил R01, R14 із специфікації і ще кілька, які реєстр додав пізніше, а кожне порушене правило дає окремий рядок у списку повідомлень. Один RMPD500 може містити кілька рядків, і тоді виправляти треба все разом, а не по одному.

Рядок має сталу будову: код правила, назва правила, пояснення польською, у квадратних дужках поле або значення, яке не пройшло, і час перевірки. Наприклад: «R02.PostalCodePl: niewłaściwy kod pocztowy PL: [nadawca, BRAK]» означає правило R02 про польський поштовий індекс, поле відправника, значення BRAK.

Чи означає RMPD500, що заявку частково прийнято? Ні. Заявка не зареєстрована, і номера немає. Після виправлення надсилають нове RMPD100, а не RMPD101: змінювати можна лише те, що реєстр уже прийняв. Що робить кожен документ родини, описано в статті RMPD100, 101, 103, 104 і який документ коли подавати.

Які коди повертає реєстр насправді

За даними нашої платформи, з 24 червня по 15 вересня 2026 року через Sigil надіслано 242 заявки RMPD100. Реєстр відповів відмовою RMPD500 136 разів; відмову отримали 60 заявок, тобто кожна четверта, а 38 із них після виправлення реєстр прийняв. У 136 відповідях було 137 рядків із такими правилами.

Три застереження до цієї таблиці. Перше: 31 рядок про перехід кордону припадає на перші тижні роботи інтеграції, коли назва переходу в нашому словнику відрізнялася від назви в PUESC на одну літеру; реєстр порівнює рядки дослівно. Друге: рядки рахуються за повідомленнями, а не за перевізниками, і одна вперта помилка може дати десять рядків від однієї заявки, як R01 у таблиці. Так само 25 рядків R16 це лише 15 відмов: реєстр доставляв їх повторно, і одна копія потрапила до заявки, для якої закриття не надсилали. Третє: таблиця охоплює обидва середовища PUESC, тестове і продукційне, і більшість заявок та відмов припадає на тестове. У продукційному з 31 липня до 15 вересня 2026 року відмову отримали 6 заявок зі 110.

R01 кирилиця в полі, де реєстр чекає латиницю

Правило R01 із специфікації дозволяє в текстових полях лише знаки Latin1 плюс польські літери: a-zA-Z0-9, розділові знаки і ąćęłńóśźżĄĆĘŁŃÓŚŹŻ. Кирилична назва відправника з CMR «ТОВ Агротрейд» не проходить, як і апостроф у «Карп'юк» у вигляді знака ' з української розкладки, який не входить у Latin1.

Реєстр називає поле в дужках: GoodsSenderName це назва відправника, GoodsSenderAddressCity місто відправника, journeyStartCity місто початку. У наших даних усі 19 рядків R01 стосувалися саме відправника і міста початку в Україні: перевізник переписав графу 1 CMR так, як вона надрукована, кирилицею.

Що робити: транслітерувати за правилами, якими виписано закордонний паспорт або міжнародну накладну, і так само в усіх полях цієї заявки. ТОВ стає TOV, Карп'юк стає Karpiuk. Це не суперечить правилу переписувати CMR дослівно: реєстр фізично не приймає кирилиці, і транслітерація це та сама назва в іншій абетці, а не інша назва.

R02 польська адреса без поштового індексу

Правило R02: якщо в адресі сторони країна PL, поштовий індекс мусить бути у форматі 00-000. Правило застосовується лише до польських адрес; для України і Німеччини формат не перевіряється.

У наших даних це 12 рядків для 7 заявок, і майже всі з тим самим значенням: [nadawca, BRAK] або [odbiorca, BRAK]. Диспетчер знав, що порожню вулицю або номер будинку треба заповнювати словом BRAK, і застосував те саме до поштового індексу. Для індексу це не працює: BRAK дозволений лише в полях Street і HouseNumber (правило R04).

Що робити: знайти поштовий індекс польської сторони в інвойсі, на печатці або за адресою в довіднику Poczta Polska і вписати як п'ять цифр із дефісом. Якщо на CMR його немає, це саме той випадок, коли дані просять у відправника, а не вигадують.

R06, R15, R26 дати, які реєстр рахує від сьогодні

Три правила про одне: дата початку перевезення не може бути в минулому, а дата закінчення не може бути далі ніж на 9 днів від дня подання. R06 діє при реєстрації, R15 при зміні через RMPD101, R26 при анулюванні через RMPD104.

Найчастіша ситуація в наших даних, 8 заявок із 9 рядків R06: диспетчер подає заявку ввечері на рейс, який планується на 10 днів, і ставить дату закінчення на десятий день. Реєстр рахує 9 днів від дати подання, не від дати початку: «Data zakończenia transportu (2026-09-18) jest późniejsza niż maksymalna dozwolona data (2026-09-17)». Друга ситуація: заявка підготовлена вчора, надіслана після півночі, і дата початку вже «wcześniejsza niż dzisiejsza data».

R26 з'являється тоді, коли перевізник хоче анулювати рейс, який за датами вже почався: «Data rozpoczęcia przewozu towaru: [2026-09-03] nie może być wcześniejsza od bieżącej w chwili anulowania». Після дати початку анулювання неможливе, лишається закриття.

Що робити: подавати не раніше ніж за 9 днів до кінця рейсу, а якщо рейс довший, ставити дату закінчення в межах 9 днів і подовжувати через RMPD101 у дорозі. Заявку, підготовлену ввечері, надсилати до півночі за польським часом або перевірити дату початку після півночі.

R30 локатор є, але не для SENT

Правило R30 перевіряє не формат номера локатора, а те, чи пристрій активований для передачі позиції в рамках заявок SENT: «podany numer nie jest aktywowany do rejestracji położenia w ramach zgłoszeń SENT». Контрольна сума правильна, пристрій існує, але в реєстрі SENT-GEO він не позначений як активний для цього перевізника.

У наших даних це 17 рядків для 8 заявок, і той самий номер повторювався кілька разів: диспетчер бачив, що номер правильний, і надсилав ще раз. Бракувало не цифри, а активації.

Що робити: зайти на PUESC у сервіс локаторів і перевірити статус пристрою; активувати його для перевізника або вписати інший, який уже активний. Запасний локатор перевіряється так само.

Перехід кордону і номер дороги поза словником

Ця відмова приходить без коду правила: «No borderCross for routePlace: Dorohusk - Jagodzin, routeNumber: DK12». Реєстр має словник дорожніх переходів, у якому кожен запис це пара з назви переходу і номера дороги, і порівнює обидва значення дослівно. «Dorohusk - Jagodzin» з дорогою DK12 у словнику не було; був інший запис для того самого переходу.

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

Що робити: у секціях 3.7 і 3.8 обирати перехід зі словника, а не з пам'яті; якщо пункт в'їзду не з переліку, використовувати поле «Miejsce spoza listy» з координатами, а не вписувати назву в поле переходу.

R16 закриття, яке реєстр не приймає

«R16.RMPD103Rejected: Przesłany komunikat nie jest aktualnie obsługiwany» приходить у відповідь на RMPD103, бо правило R16 у специфікації звучить «Nie jest możliwe przesłanie komunikatu RMPD_103»: закриття реєстр зараз не приймає взагалі. Це не помилка даних, нічого виправляти не треба, і повторна відправка не допоможе.

У наших даних це 25 рядків для 16 заявок, але відмов лише 15: з 2.07 до 4.08.2026 платформа надіслала 50 закриттів, 49 у тестове середовище PUESC і одне в продукційне, і реєстр не прийняв жодного. Статус 5, тобто закриття самим реєстром, мали лише 3 з 7 039 завершених заявок у продукційному середовищі, тож не розраховуйте й на нього. Що означає кожен статус, розібрано в довідці Перевірка статусів RMPD.

Відмова з кодом це відповідь реєстру; коли реєстр не відповідає взагалі, діє інша процедура, з документом-заміною до GITD, розібрана в статті Що робити з RMPD і SENT, коли PUESC не працює.

Якщо акаунта в PUESC ще немає, кожен екран форми реєстрації з підписами розібрано в статті Реєстрація в PUESC для перевізника, покроково зі скрінами.

Який ідентифікатор сторони вписати, щоб не отримати R03, і чому українська фірма не вписує в заявку EORI, пояснює стаття про номери в PUESC.

Що робити

1. 1Читайте код правила, не лише текст. R01 це знаки, R02 поштовий індекс, R06 дати, R30 локатор. Код каже, яке поле відкривати.
2. 2Виправляйте все з одного RMPD500 разом. Кілька рядків це кілька помилок, і по одній вони заберуть кілька спроб.
3. 3Транслітеруйте назви й міста з України так само, як у закордонному паспорті, в усіх полях однієї заявки. Кирилиця не проходить ніколи.
4. 4Для польської сторони знайдіть поштовий індекс у форматі 00-000. BRAK працює лише для вулиці й номера будинку.
5. 5Ставте дату закінчення не далі ніж на 9 днів від дня подання, а не від дня в'їзду. Довший рейс подовжуйте через RMPD101.
6. 6Перед першим рейсом перевірте на PUESC, що локатор активований для SENT-GEO. Правильний номер без активації це R30.
7. 7Перехід кордону обирайте зі словника, а після планової дати закінчення спершу перевірте статус, перш ніж закривати: закриту реєстром заявку закривати не треба.

Чого не робити

• ✗Не надсилайте ту саму заявку вдруге без змін. RMPD500 повторюється дослівно, а кожна спроба залишає слід у реєстрі.
• ✗Не вписуйте BRAK у поштовий індекс. Правило R04 дозволяє його лише у вулиці й номері будинку.
• ✗Не переписуйте кириличну назву з CMR у заявку. Реєстр приймає лише Latin1 з польськими літерами; транслітерація це та сама назва.
• ✗Не рахуйте 9 днів від дати в'їзду. Реєстр рахує від дня подання, і десятиденний рейс потребує RMPD101 у дорозі.
• ✗Не анулюйте рейс після дати початку. R26 відмовить; після старту заявку тільки закривають.

Де тут Sigil

Sigil читає RMPD500 за перевізника: код правила і назва поля з дужок перекладаються на назву того самого поля у формі, і диспетчер бачить, що саме виправити, українською, без польського тексту реєстру. Частину правил система перевіряє ще до відправки: формат номерних знаків, слово BRAK, польський поштовий індекс, межі дат, контрольну суму локатора, тому ці відмови до реєстру не доходять. Активацію локатора на PUESC і транслітерацію назв підтверджує людина: система не змінює даних із CMR сама.

Відмова коштує хвилин, а не годин: за нашими даними PUESC відповідає на заявку за 4 секунди, а весь цикл від фото CMR до номера триває в медіані 6 хвилин; що насправді затягує оформлення, у статті Скільки насправді триває оформлення RMPD.

Sigil обслуговує заявки RMPD. Заявку SENT про товар подає відправник або отримувач.