Научете
Подадохте. Изчакахте. После пристигна файлът с обратна връзка с код на правило, който никога не бяхте виждали, и без обяснение на разбираем език какво означава той. Тази статия свързва кодовете за отхвърляне с причините за тях, като използва това, което ESAs действително са публикували, вместо това, което интернет предполага.
КорекцияПренаписана на 14 юли 2026 г. По-ранна версия на тази статия описваше регистъра като таблици “B00” до “B06”, което не е структурата на регистъра. Реалната структура са 15-те официални образеца, B_01.01 до B_99.01, определени в Регламент за изпълнение (ЕС) 2024/2956 на Комисията. Същата версия твърдеше и наличието на валидационен механизъм от “117 правила на EBA”, таблица с честоти на отхвърляне, измислена конвенция за имена на CSV файлове, твърдение, че CSV файловете трябва да стоят в корена на ZIP архива, и разработен пример с неуспешно подаване на платежна институция. Нищо от това не можа да бъде проследено до източник и всичко беше премахнато. Всяка причина за отхвърляне по-долу вече води до ITS или до публикуван документ на ESA, а за няколко от причините, изброени в по-ранната версия, се оказва, по собствените публикувани доказателства на ESAs, че изобщо не водят до отхвърляне.
⚡ Накратко
ESAs публикуваха най-често срещаните грешки, които наблюдават при отчитането на register of information, заедно с колона, посочваща дали всяка от тях води до отхвърляне. Седем от тях водят: нарушения на външен ключ (807), липсващи първични ключове (805), проблеми с filing indicators (808), файлове извън DORA или с грешна големина на буквите (720), entityID, който не съвпада с името на файла (714), структура на файла на отчета (103) и кодове в заглавния ред, които липсват в таксономията (801). Пет често срещани грешки не водят до отхвърляне, включително липсващи задължителни стойности и грешен LEI. Ако сте заклещени в цикъл от повторни подавания, най-бързият изход е да поправите седемте, които водят до отхвърляне, и да разберете, че един-единствен файл, който не може да бъде разчетен, може да предизвика каскада от грешки за външен ключ, които нямат самостоятелна причина.
Какво всъщност се случва, когато подадете
Вашето подаване е отчетен пакет. EBA определя структурата му в указанията си за подготовка на обикновен CSV отчетен пакет за DORA. ZIP архивът се именува по отчетния субект, а вътре в него има папка reports и папка META-INF. Папката reports съдържа report.json, parameters.csv, FilingIndicators.csv и по един CSV файл за всяка таблица. META-INF съдържа reportPackage.json.
Схемата за именуване на ZIP архива
ReportSubject.CON/.IND_Country_FrameworkCodeModuleVersion_Module_ReferenceDate_CreationTimestamp.zip
Собственият пример на EBA:
DUMMYLEI123456789012.CON_IT_DORA010100_DORA_2024-12-31_20240821141632000.zip
Отчетният субект е вашият LEI. .CON или .IND отбелязва консолидирано или индивидуално подаване. А параметърът entityID вътре в parameters.csv трябва да съвпада с него: когато не съвпада, ESAs повдигат грешка 714, а 714 води до отхвърляне.
След това проверките се изпълняват на слоеве. EBA ги описва в документ, озаглавен изцяло като преглед на техническите проверки, валидационните правила и бизнес проверките, които EBA прилага при отчитането на RoI. Техническите проверки гледат самия пакет: правилно ли е структуриран, верни ли са имената на файловете, UTF-8 ли е кодирането. Правилата на модела на точките от данни гледат таблиците: в таксономията ли са кодовете в заглавния ред, попълнени ли са ключовите колони, разрешават ли се външните ключове. Бизнес правилата гледат съдържанието: реален ли е този LEI, съществува ли този EUID.
⚠️ Една уговорка, която ESAs поставят върху собствения си документ
Публикуваните наблюдения носят изрично предупреждение: материалът отразява устройството на отчетната инфраструктура на ESAs, а “валидационните проверки и съобщенията за обратна връзка, внедрени от компетентните органи в техните отчетни решения, използвани за събиране на регистрите на информацията от финансовите субекти, може да се различават от обяснените на тези слайдове”. Порталът на вашия NCA е мястото, където действително подавате. Четете неговите технически указания заедно с това.
Грешките, които ESAs действително виждат, и кои от тях водят до отхвърляне
През април 2025 г. ESAs публикуваха набор от наблюдения от тестването на отчитането на register of information, актуализиран през май 2025 г., в който изброяват най-често срещаните грешки по код на правило. Съществено е, че списъкът носи колона, посочваща дали всяка грешка води до отхвърляне. Възпроизвеждаме това съответствие по-долу, защото то пренарежда приоритетите, с които започват повечето планове за отстраняване.
Това пренареждане има по-голямо значение, отколкото звучи. Плановете за отстраняване почти винаги започват с данните, защото лошите данни изглеждат като сериозния проблем, а името на файл изглежда дребно. По собственото съответствие на ESAs редът е обратен, а екип, който прекара две седмици в чистене на записи за доставчици, преди да поправи грешка в големината на буквите, ще подаде отново и ще бъде върнат отново по същата причина.
Това пренареждане има по-голямо значение, отколкото звучи. Плановете за отстраняване почти винаги започват с данните, защото лошите данни изглеждат като сериозния проблем, а името на файл изглежда дребно. По собственото съответствие на ESAs редът е обратен, а екип, който прекара две седмици в чистене на записи за доставчици, преди да поправи грешка в големината на буквите, ще подаде отново и ще бъде върнат отново по същата причина.
| Код на правило | Описание | Води до отхвърляне |
|---|---|---|
| 807 | Нарушено ограничение за външен ключ | ДА |
| 805 | Липсващ първичен ключ | ДА |
| 808 | Липсващи filing indicators или грешна големина на буквите | ДА |
| 720 | Отчетени файлове извън DORA или грешна големина на буквите | ДА |
| 714 | Параметърът entityID не съвпада с името на файла | ДА |
| 103 | Структура и съдържание на файла на отчета | ДА |
| 801 | Всички кодове в заглавния ред на таблиците трябва да са в таксономията | ДА |
| v8886_m, v8850_m, v8885_m, v8884_m, v8888_m, v88889_m | Липсващи задължителни стойности | НЕ |
| VR_71, VR_23, VR_12, VR_77 | Отчетен е грешен LEI | НЕ |
| 806 | При отворени таблици не може да отчитате еднакви ключови стойности | НЕ |
| VR_72 | Кодът EUID не беше намерен в BRIS | НЕ |
| v8826_m | Валидност на маската на LEI | НЕ |
Прочетете тази таблица отново. Липсващите задължителни стойности не водят до отхвърляне. Грешен LEI не води до отхвърляне. Невалидна маска на LEI не води до отхвърляне. EUID, който не е намерен в системата за взаимно свързване на търговските регистри, не води до отхвърляне. Дублирани ключове в отворени таблици не водят до отхвърляне. Всичко това са реални проблеми с качеството на данните, всички те ви се връщат обратно, а вашият компетентен орган може да заеме различна позиция в собствения си портал, но по публикуваното съответствие на ESAs те не са това, което връща вашия пакет. Това, което връща пакета ви, е структурата: ключове, препратки, имена на файлове, filing indicators, кодиране и заглавни редове.
807: нарушения на външен ключ и каскадата зад тях
Нарушението на външен ключ е първият ред в таблицата на ESAs и води до отхвърляне. Регистърът е релационен: 15-те образеца, определени в Article 5 от ITS, се препращат един към друг чрез идентификатори, които вие задавате. Най-важният от тях е референтният номер на договореността. Article 5 и указанията в Annex I изрично посочват, че за всяка договореност с пряк ICT доставчик на услуги от трета страна субектът “присвоява уникален ‘референтен номер на договореността’, за да идентифицира недвусмислено самата договореност”.
Собственият разработен пример на ESAs за неуспех 807 е референтен номер на договореност, който се появява в B_07.01, образецът за оценките, и липсва в B_02.01, обща информация за договореностите. Стойността е налице. Тя просто не се разрешава.
Каскадата, за която никой не ви предупреждава
Ето частта, която държи екипите в цикъл от повторни подавания, и тя идва директно от слайдовете на ESAs. Ако една таблица изобщо не може да бъде интегрирана, тогава всяка препратка към тази таблица се проваля. Техните примери за това, което спира интегрирането на таблица, са грешка 801, при която код на колона в заглавния ред липсва в таксономията, и грешка 805, при която ключова колона е празна. Тяхната бележка за последицата: “Тогава много FK потенциално могат да се провалят, а други таблици ще препращат към таблицата, която не е успяла да се зареди. Това е очаквано поведение, една система за бази данни би се провалила по същата причина.”
Правило 809, добавено на 1 май 2025 г., съществува точно по тази причина. Ако един CSV файл не може да бъде разчетен, защото броят на колоните в съдържанието не съвпада със заглавния ред, ESAs отбелязват, че е “много трудно за подаващите да разберат каква е причината за 807, ако не сме успели изобщо да интегрираме файла на целевата таблица”. Затова 809 вече ви казва директно.
Практическата последица: когато получите файл с обратна връзка с петдесет грешки 807, не започвайте да поправяте петдесет препратки. Потърсете първо 801, 805 или 809. Една-единствена таблица, която не може да бъде разчетена или заредена, може да генерира произволен брой последващи грешки за външен ключ, които нямат самостоятелна причина, а поправянето на единия проблем нагоре по веригата ги изчиства всички.
Пакетиране, имена на файлове и filing indicators
Четири от седемте кода, водещи до отхвърляне, се отнасят до пакета, а не до данните. Те са и най-евтините за поправяне, след като научите правилата, и са неинтуитивни.
Това е отчетният режим в най-дразнещия и най-трудно защитим свой вид. Нищо в имената на файлове с малки букви или в filing indicators с главни букви не защитава дори един потребител, а правилата се откриват основно чрез четене на презентация със слайдове. Правилният отговор е да ги кодирате веднъж в това, което изгражда вашия пакет, и след това никога повече да не мислите за тях.
Това е отчетният режим в най-дразнещия и най-трудно защитим свой вид. Нищо в имената на файлове с малки букви или в filing indicators с главни букви не защитава дори един потребител, а правилата се откриват основно чрез четене на презентация със слайдове. Правилният отговор е да ги кодирате веднъж в това, което изгражда вашия пакет, и след това никога повече да не мислите за тях.
720: имена на файлове и големина на буквите
Файловете на таблиците трябва да са именувани с малки букви, например b_01.01.csv. Слайдовете на ESAs показват прието име на файл с малки букви и отхвърлено име с главни букви, както и отхвърлено излишно или грешно име на файл. Липсващите файлове вече се приемат, след разхлабване на правило 720, но файл, който не бива да е в пакета, все още ще го върне.
808: filing indicators
Това правило хваща хората, които разсъждават, съвсем разумно, че ако нямат какво да отчетат в даден образец, трябва да го заявят. Правилото казва друго. Очакват се всички DORA образци. Идентификаторите на образците трябва да се появяват с главни букви във FilingIndicators.csv, тоест B_01.01 вместо b_01.01, дори когато самият CSV файл е именуван с малки букви. Всеки отчетен идентификатор на образец трябва да бъде деклариран като true, като 1 се допуска като стойност за истина. Един образец може да бъде отчетен празен, ако няма какво да се сложи в него. Но, по думите на ESAs, “отчетени идентификатори на образци, декларирани като false или със стойност 0, ще бъдат отхвърлени с грешка 808 за filing indicator”.
714: entityID трябва да съвпада с името на файла
Параметърът entityID в parameters.csv трябва да съвпада с отчетния субект в името на ZIP файла. Заглавният ред на parameters.csv също трябва да е правилен: правило 723, добавено на 1 май 2025 г., изисква заглавният ред да се състои само от name и value, в този ред, защото в стандарта XBRL името се появява преди стойността.
103 и 306: структура и кодиране
103 е проверката на структурата на файла на отчета. 306 е кодирането: всеки файл в пакета трябва да бъде UTF-8. Това беше превърнато в правило с провал на 1 май 2025 г., на основание че файл, който не е коректен UTF-8, води до повредени текстови данни. UTF-8 с byte order mark се приема.
⚠️ Две широко разпространени вярвания, които са неверни
Редът на колоните няма значение. ESAs заявяват направо, че в CSV файл на таблица “имената на колоните могат да идват в произволен ред”, и публикуват валиден пример с две разменени колони. Имената на колоните са чувствителни към големината на буквите и са с малки букви, а заглавният ред не бива да съдържа празна клетка, но редът им е свободен.
CSV файловете не стоят в корена на ZIP архива. Отчетният пакет има папка
CSV файловете не стоят в корена на ZIP архива. Отчетният пакет има папка
reports и папка META-INF. Плосък архив от CSV файлове не е структурата, която порталът очаква.Типове данни: префиксът eba_, който препъва всички
Указанията на EBA за пакетирането определят седем правила за типовете данни на колоните. Те са кратки и си струва да се четат буквално, защото третото е източник на голямо количество болка, която може да бъде избегната.
Ако вашият регистър живее в електронна таблица, само това правило е аргумент експортът да се пише със скрипт вместо да се редактира на ръка. Хората изписват кодовете на държави така, както ги четат, а таксономията иска формата с префикс на собственика. Никой не поддържа тази дисциплина в хиляди клетки през цял отчетен сезон.
Ако вашият регистър живее в електронна таблица, само това правило е аргумент експортът да се пише със скрипт вместо да се редактира на ръка. Хората изписват кодовете на държави така, както ги четат, а таксономията иска формата с префикс на собственика. Никой не поддържа тази дисциплина в хиляди клетки през цял отчетен сезон.
| Тип | Какво изисква таксономията |
|---|---|
| Стринг (буквено-цифров) | Стрингова стойност. Ако съдържа символа разделител, тоест запетая, стойността трябва да бъде оградена с двойни кавички. |
| Дата | Трябва да бъде във формат yyyy-mm-dd. |
| Изброен (затворен набор от опции) | Трябва да бъде стойност от падащия списък в анотирания образец, с префикс на собственика eba_. Примерът на EBA е eba_GA:AT за държава. Това е най-често разбираното погрешно правило в целия пакет: голото AT или думата Austria се различават от изброената стойност, която таксономията очаква. |
| Булев | Трябва да бъде или true, или false, или 1, или 0. |
| Паричен | Трябва да бъде изразен в единици, не в хиляди или милиони. Примерът на EBA е 2540100.23. |
| Цяло число | Трябва да бъде цяло число. |
| Ключови колони | Ако колоната е ключ, тя трябва да бъде попълнена. Празна ключова колона е правило 805, а 805 води до отхвърляне. |
Указанията в Annex I на ITS описват полетата за държава концептуално, като кода по ISO 3166-1 alpha-2, а полетата за валута като буквения код по ISO 4217. Това е, което полето означава. То се различава от това, което въвеждате в CSV файла. В отчетния пакет изброената стойност носи префикса на собственика, поради което разработеният пример на EBA за стойност на държава е eba_GA:AT вместо AT. Базовата валута в parameters.csv се появява в примера на EBA като iso4217:EUR. Ако вашият експорт изписва четимия за човек код, таксономията няма да го разпознае.
LEI и EUID: реални проблеми, които не водят до отхвърляне
Article 3(5) от ITS изисква финансовите субекти да използват “валиден и активен идентификатор на правен субект (LEI) или европейски уникален идентификатор ... (‘EUID’), а когато са налични и двата идентификатора, за да идентифицират всички свои ICT доставчици на услуги от трети страни, които са юридически лица, с изключение на физически лица, действащи в стопанско качество”. Article 3(6) разширява същото изискване, през прекия доставчик, към подизпълнителите, които на практика поддържат услуги в подкрепа на критични или важни функции.
Обърнете внимание на думите “валиден и активен”. Структурно коректен LEI, който е изтекъл, е неактивен. ESAs изпълняват бизнес валидационни правила срещу кеширано копие на базата данни на GLEIF, така че грешен LEI бива хванат. Той се връща обратно под кодове като VR_71, VR_23, VR_12 и VR_77. По публикуваното съответствие на ESAs той не отхвърля подаването, което остава недостатъчна причина да го оставите грешен: регистърът трябва да е точен, а Article 3(3) от ITS ви задължава да го преглеждате редовно и да “коригирате незабавно всички установени грешки или несъответствия”.
Маската на LEI, прецизно
Правилото, което EBA прилага, v8826_m, е регулярен израз: ^[A-Z0-9]{18}[0-9]{2}$. Осемнадесет знака, които са от A до Z или от 0 до 9, следвани от две цифри. Двадесет знака общо. Обърнете внимание, че първите осемнадесет може да са букви или цифри, така че описанията на LEI, които настояват, че началните знаци трябва да са букви, грешат за маската, която валидаторът действително прилага.
EUID е самостоятелен идентификатор, различен от LEI
EUID е европейският уникален идентификатор от системата за взаимно свързване на търговските регистри. VR_72 се задейства, когато отчетен EUID не бъде намерен там. ESAs изброяват причините, които могат да бъдат избегнати: LEI, маркиран като EUID, и отчетен EUID, който не следва шаблона на EUID. Двете им лесни проверки са, че EUID следва да съдържа точка и следва да започва с двубуквения ISO код на държава от ЕИП. В броенията, които публикуваха от тестването, невалидният формат на EUID беше с голяма разлика най-голямата категория резултати за EUID, значително надхвърляйки както намерените, така и ненамерените.
Едно следствие си струва да се изпише, защото произтича от ITS, а не от валидатора: доставчиците, установени в трети държави, се идентифицират само с LEI, тъй като EUID е европейски идентификатор. Поставянето на стойност с форма на EUID срещу доставчик от САЩ или Индия няма да проработи.
Има изкушение, след като научите, че тези кодове не водят до отхвърляне, да ги оставите за догодина. Устоите му. Хигиената на идентификаторите е най-евтината работа по качеството в регистъра: проверка в GLEIF в момента на въвеждане отнема секунди, докато установяването по-късно кой от вашите доставчици носи изтекъл идентификатор е седмица от нечий живот.
Има изкушение, след като научите, че тези кодове не водят до отхвърляне, да ги оставите за догодина. Устоите му. Хигиената на идентификаторите е най-евтината работа по качеството в регистъра: проверка в GLEIF в момента на въвеждане отнема секунди, докато установяването по-късно кой от вашите доставчици носи изтекъл идентификатор е седмица от нечий живот.
Задължителни стойности и дублирани ключове
Правилата за задължителни стойности имат вида v8886_m и подобни и представляват условни твърдения в модела на точките от данни. Разработеният пример на ESAs гласи на практика, че за B_07.01 колона c0080 е задължителна, и те го показват да се проваля по два различни начина: колоната изобщо липсва във файла, или колоната е налице и стойността не е попълнена. И двата дават един и същ код.
Правило 806 е правилото за дублирани ключове: при отворени таблици не може да отчитате еднакви ключови стойности. Ако отчетете един и същ ключ два пъти, той се маркира. Нито едно от двете не води до отхвърляне по съответствието на ESAs. И двете са реални провали в качеството на данните. Article 3(4) от ITS определя шестте принципа, на които трябва да отговарят данните във вашия регистър: точност, пълнота, последователност, цялост, еднородност и валидност. Регистър, който минава през портала, докато нарушава тези принципи, не е постигнал нищо освен разписка.
Структурно правило, което лесно се сгрешава. Article 4(2) от ITS: “Финансовите субекти попълват всеки елемент от данните с една стойност. Когато повече от една стойност е валидна за конкретен елемент от данните, финансовите субекти добавят допълнителен ред в съответния образец за всяка валидна стойност.” Две държави, два реда. Една клетка с две държави в нея е нарушение.
Чеклист преди подаване
Изпълнете това, преди да подадете. То няма да хване всичко и не замества набора от правила, който вашият NCA действително прилага, но покрива седемте кода, които водят до отхвърляне, и структурните правила зад тях.
Преминаването през него отнема един следобед първия път и минути след това, защото повечето от тези неща са свойства на вашия процес по експортиране, а не на данните от тази година. Тази асиметрия е целият аргумент да поправите канала вместо пакета.
Преминаването през него отнема един следобед първия път и минути след това, защото повечето от тези неща са свойства на вашия процес по експортиране, а не на данните от тази година. Тази асиметрия е целият аргумент да поправите канала вместо пакета.
Пакет и имена на файлове
- Името на ZIP архива следва схемата
ReportSubject.CON/.IND_Country_FrameworkCodeModuleVersion_Module_ReferenceDate_CreationTimestamp.zip, с вашия LEI като отчетен субект. entityIDвparameters.csvсъвпада с отчетния субект в името на ZIP файла. Разминаването е правило 714, а 714 води до отхвърляне.- Файловете на таблиците са именувани с малки букви, например
b_01.01.csv. Слайдовете на EBA показват отхвърляне на име на файл с главни букви по правило 720. - Пакетът има папка
reportsи папкаMETA-INFсreportPackage.json. CSV файловете стоят вътре в тях, а не свободно в корена на ZIP архива. - В пакета няма файлове извън DORA. Излишни или грешни имена на файлове се отхвърлят по 720.
- Всеки файл е UTF-8. От 1 май 2025 г. файл, който не е UTF-8, попада под правило 306 и се проваля. UTF-8 с BOM се приема.
Filing indicators
FilingIndicators.csvизброява идентификаторите на образците с главни букви, напримерB_01.01.- Всеки отчетен идентификатор на образец е деклариран като
true(или1). Идентификатор на образец, деклариран катоfalseили0, се отхвърля по правило 808. - Образец, за който няма какво да се отчете, се включва като празна таблица, с декларация за истина и без да се пропуска.
Ключове и препратки
- Всяка ключова колона е попълнена. Празен ключ е правило 805 и води до отхвърляне.
- Всеки външен ключ се разрешава. Разработеният пример на EBA: референтен номер на договореност, наличен в B_07.01, но липсващ в B_02.01, се проваля с 807.
- Заглавните редове не съдържат празни клетки и кодове на колони, които липсват в таксономията. И двете са правило 801, а провал по 801 в една таблица може да предизвика каскада от грешки 807 в таблиците, които сочат към нея.
- Броят на редовете и броят на запетаите съвпадат със заглавния ред във всеки CSV файл. Провалът при разчитане е правило 809 и предизвиква същата последваща каскада.
Типове данни
- Датите са
yyyy-mm-dd. - Всяка изброена стойност носи префикса на собственика
eba_. - Паричните стойности са в единици, не в хиляди.
- Стойностите, съдържащи запетая, са оградени с кавички.
Идентификатори
- Всеки LEI отговаря на маската, която EBA прилага:
^[A-Z0-9]{18}[0-9]{2}$, тоест 18 знака от A до Z или от 0 до 9, следвани от две цифри. - LEI кодовете се проверяват срещу GLEIF, защото ESAs изпълняват бизнес правила срещу кеширано копие на базата данни на GLEIF.
- EUID кодовете са отделен вид идентификатор от LEI. Указанието на EBA е, че EUID съдържа точка и започва с двубуквения ISO код на държава от ЕИП.
Кога отхвърлянето сигнализира за по-дълбок проблем
Ако едни и същи грешки се връщат след като ги коригирате, проблемът обикновено е в друго, извън изпълнението. Той е в това, че регистърът се сглобява в инструмент, който не може да задържи формата му.
Едно-две отхвърляния при първо подаване са нормални и незабележителни и никой не бива да ги чете като провал на екипа. Четвъртото и петото ви казват нещо за процеса. В този момент разумният ход е да спрете да редактирате изхода и да отидете да погледнете къде се съхраняват данните.
Едно-две отхвърляния при първо подаване са нормални и незабележителни и никой не бива да ги чете като провал на екипа. Четвъртото и петото ви казват нещо за процеса. В този момент разумният ход е да спрете да редактирате изхода и да отидете да погледнете къде се съхраняват данните.
Регистърът е релационен набор от данни. Референтният номер на договореността е ключ, към който сочат няколко образеца. Идентификаторът на функцията, съгласно ITS, трябва да бъде уникален за всяка комбинация от LEI на финансов субект, лицензирана дейност и функция, а ITS дава разработен пример точно за това. Всички доставчици в една верига на доставки на ICT услуги трябва да споделят един и същ референтен номер на договореност и един и същ тип ICT услуги. Рангът е естествено число, винаги 1 за прекия доставчик и винаги по-голямо от 1 за подизпълнител. Това са ограничения за цялост. Електронната таблица не налага ограничения за цялост; тя съхранява текст.
| Какво трябва да е изпълнено | В електронна таблица | В система, която моделира регистъра |
|---|---|---|
| Всеки външен ключ се разрешава | Проверява се на ръка, с формули за търсене. Чупи се безшумно, когато идентификатор се редактира в един лист и остане непроменен в останалите. | Препратката е връзка между записи, така че тя не може да сочи към нищо. |
| Ключовите колони никога не са празни | Нищо не спира празна клетка. | Запис без своя ключ не може да бъде записан. |
| Изброените стойности носят префикса eba_ | Падащ списък предлага стойности; свободният текст ги отменя. | Потребителите избират етикета на бизнес език; кодът се прилага при експорт. |
| Грешките се откриват преди подаване | Откриват се от портала, след опита. | Откриват се от валидационно преминаване през модела на данните, преди пакетът да бъде изграден. |
Точно това прави модулът за регистъра на Venvera. Доставчиците, договореностите, субектите, функциите, веригите на доставки и оценките са свързани записи вместо листове. Потребителите работят на бизнес език, а кодовете на ESA се прилагат при генерирането на пакета. Изглед за пълнота извежда валидационните проблеми, всеки маркиран с образеца и полето, към които принадлежи, и отбелязан като грешка или предупреждение, преди да експортирате. Експортът произвежда xBRL-CSV пакета през всички 15 официални образеца, B_01.01 до B_99.01, в структурата на таблиците на ITS (ЕС) 2024/2956. Доставчиците могат да бъдат проверявани срещу GLEIF API направо от формуляра за доставчик, който връща регистрираното юридическо наименование и статуса на регистрация, така че изтекъл LEI е видим в момента, в който го въвеждате, вместо във файл с обратна връзка.
Това, което няма да твърдим, е, че така се гарантира приемане. Наборът от правила е версиониран, ESAs го променят, вашият NCA може да изпълнява собствени проверки, а ESAs сами го казват. Това, което ви дава един модел на данните, е, че класът грешки, които водят до отхвърляне, тоест структурните, до голяма степен са премахнати още в проектирането, вместо да се търсят чрез тестване.
Спрете цикъла от повторни подавания.
Venvera държи Register of Information като релационен модел, извежда валидационните проблеми спрямо образеца и полето преди да експортирате, и изгражда xBRL-CSV пакета през всички 15 официални образеца.
Заявете демо →Често задавани въпроси
Всички ли най-чести грешки в Register of Information водят до отхвърляне?
Не, и това е най-полезното нещо в публикуваните наблюдения на ESAs. От дванадесетте типа грешки, които ESAs изброяват като най-чести, пет са отбелязани като невеждащи до отхвърляне: липсващи задължителни стойности, отчетен грешен LEI, еднакви ключови стойности в отворени таблици, EUID, който не е намерен в BRIS, и валидност на маската на LEI. Седемте, които водят до отхвърляне, са нарушение на външен ключ (807), липсващ първичен ключ (805), проблеми с filing indicator (808), файлове извън DORA или с грешна големина на буквите (720), entityID, който не съвпада с името на файла (714), структура на файла на отчета (103) и кодове в заглавния ред, които липсват в таксономията (801). ESAs предупреждават също, че проверките и съобщенията за обратна връзка, внедрени от националните компетентни органи в собствените им отчетни решения, може да се различават от описаните в този документ.
Какво означават кодовете на правилата във файла с обратна връзка?
Те са идентификаторите на конкретните валидационни правила, които отчетната система е приложила. Числовите кодове в стотиците, седемстотиците и осемстотиците са технически и структурни проверки на пакета. Кодовете от вида v8826_m са правила на модела на точките от данни, изразени като твърдения, така че v8826_m е правилото, че стойността трябва да отговаря на маската на LEI. Кодовете от вида VR_71 са бизнес валидационни правила. EBA публикува набора от правила в своите пакети с валидационни правила, а презентацията ѝ за често срещаните проблеми преминава през честите с разработени примери.
Защо един счупен файл произведе десетки грешки за външен ключ?
Защото таблицата, която той счупи, така и не се зареди. ESAs обясняват, че когато един образец не може да бъде интегриран, например защото код на колона в заглавния ред липсва в таксономията (801) или ключова колона е празна (805), или CSV файлът не може да бъде разчетен (809), тогава всяка друга таблица, която препраща към провалилата се таблица, също ще се провали при проверките си за външен ключ с 807. Тяхната собствена бележка по това е, че това е очаквано поведение и че една система за бази данни би се провалила по същата причина. Затова първо преследвайте грешките 801, 805 и 809: голям блок от грешки 807 често има една-единствена причина нагоре по веригата.
Може ли празен образец да бъде оставен извън пакета?
Не. По правило 808 се очакват всички DORA образци, идентификаторите на образците трябва да се появяват с главни букви във FilingIndicators.csv, а всеки отчетен идентификатор на образец трябва да бъде деклариран като true. Образец, за който няма какво да се отчете, се подава като празна таблица, с декларация за истина и без да се пропуска. Има и долен праг: правило 724, въведено на 1 май 2025 г., съществува, защото пакет, в който всеки файл е празен, не произвежда никакви констатации, а ESAs отбелязват, че като минимум образците B_01 трябва да бъдат отчетени дори от субект без договори с външни доставчици.
Какво става, ако ICT доставчик няма LEI?
ITS изисква валиден и активен LEI или европейски уникален идентификатор (EUID), и двата, когато са налични, за всеки ICT доставчик на услуги от трета страна, който е юридическо лице, с изключение за физически лица, действащи в стопанско качество. Доставчиците, установени в трети държави, се идентифицират само с LEI, защото EUID е европейски идентификатор. Не поставяйте запълваща стойност в поле за LEI и не поставяйте LEI в поле за EUID: ESAs изброяват LEI, маркиран като EUID, като една от причините за грешката VR_72, които могат да бъдат избегнати, а в данните, които публикуваха, невалидният формат на EUID беше далеч най-голямата категория проблеми с EUID.
Първични източници
- Регламент за изпълнение (ЕС) 2024/2956 на Комисията. ITS относно стандартните образци за register of information по Article 28(9) от DORA. Article 1 определя прекия доставчик, веригата на доставки на ICT услуги и ранга. Article 2 задава правилото за ранжиране. Article 3 задава общите изисквания към образците, шестте принципа за качество на данните и изискването за LEI и EUID. Article 4 задава правилата за формата на данните. Article 5 изброява 15-те образеца, B_01.01 до B_99.01.
- ESAs, “Observations from reporting of RoI to the ESAs. Key common issues identified” (първоначално публикувано на 16 април 2025 г., актуализирано на 16 май 2025 г.). Източникът за таблицата с кодовете на грешки, съответствието отхвърля или не отхвърля, каскадата при външните ключове, правилото за filing indicator, маската на LEI, указанията за EUID и правилата, добавени на 1 май 2025 г.
- EBA, “Preparing plain csv reporting package for DORA”. Източникът за схемата за именуване на ZIP архива, структурата от папки на пакета, съдържанието на report.json, parameters.csv и FilingIndicators.csv, и седемте правила за типовете данни, включително префикса на собственика
eba_. - Пакети с валидационни правила на EBA. Публикуваният набор от правила. Той е версиониран, а активните правила зависят от версията на таксономията и на отчетната рамка, която е в сила.
- EBA, “Frequently asked questions on reporting of the registers of information” (актуализирано на 28 март 2025 г.).
- EBA, “Preparations for reporting of DORA registers of information”. Индексната страница, която съдържа техническия пакет, модела на точките от данни, таксономията и документите по-горе.
- Регламент (ЕС) 2022/2554 (DORA), Article 28(3), задължението да се поддържа регистърът, и Article 28(9), мандатът за образците.
- Контекст: нашето ръководство за 15-те официални образеца и придружаващата справка за образците (CSV).
Тази статия е само за информация и не представлява правен или регулаторен съвет. Източниците бяха проверени на 14 юли 2026 г. ESAs отбелязват, че валидационните проверки и съобщенията за обратна връзка, внедрени от националните компетентни органи, може да се различават от публикуваните от тях, а наборът от правила е версиониран. Потвърдете версията на таксономията и правилата в сила с вашия NCA преди всяко подаване.
