Разделете три вида проблеми

Файлът може да не отговаря на изискванията за пакетиране или структура, стойностите и връзките да нарушават правило за валидация или бизнес информацията да е неточна. Тези проблеми изискват различни отговорници. Преименуването на файл не поправя липсваща връзка към договор. Успешната техническа проверка не установява пълнотата на списъка с доставчици.

EBA публикува отчетни материали, технически проверки и правила за валидация. Използвайте версията за съответната референтна дата и указанията на органа, който приема подаването. Не приемайте, че най-новият номер на отчетна рамка важи за всеки модул. Пазете използваните правила заедно с подадената версия, за да може друг проверяващ да възпроизведе резултата.

За обхвата и връзките между таблиците вижте ръководството за DORA регистъра. Примерът по-долу е малко упражнение за начина на проверка, а не заместител на официалните образци.

Измислен пример с грешна връзка

Нека описът на договорите обозначава договореност като DEMO-014. Отделен ред за услуга сочи към DEMO-041. Упражнението умишлено използва опростени имена на колони и измислени идентификатори. Това не са официални полета, реални LEI кодове или готов за подаване DORA (регламент на ЕС за цифровата оперативна устойчивост на финансовия сектор) файл.

Запис Преди корекция Проверен източник След корекция
Опис на договорите DEMO-014 Прегледан договор DEMO-014
Връзка от услугата DEMO-041 Същият договор DEMO-014
Вътрешен дневник Неразрешена връзка Запис от проверката Поправена и проверена

Изкушаващото решение е да добавите нов договор DEMO-041, за да заработи връзката. Така ще създадете запис без бизнес основание. Правилната проверка установява дали действително има два договора, дали услугата принадлежи другаде или препратката е сгрешена. Само подкрепящият договор може да реши този въпрос.

Проследете корекцията до отговорника

Запишете идентификатора на правилото точно както е получен, засегнатата таблица и ред, референтната дата и версията на пакета. После проследете стойността до нейния източник: покупки, правен отдел, опис на услуги или регистър на юридически лица. Запазете първоначалното съобщение, вместо да го заменяте с Вашето тълкуване.

Съгласувайте поправката с отговорника за източника. Ако идентификаторът е грешен в системата за покупки, поправката само в експорта оставя дефекта готов да се върне следващия месец. Ако източникът е правилен, но преобразуването за експорта е грешно, промяната на бизнес записа ще въведе нов проблем. Разграничението трябва да присъства в дневника на корекциите.

Липсващ идентификатор не дава основание да измислите такъв. Установете допустимия тип и приложимите указания. Когато информацията още липсва, запишете отговорника, искането и последствията за подаването. Не поставяйте правдоподобни стойности само за да мине проверката за непразно поле.

Проверете отново цялата последователност

След поправка на източника или преобразуването генерирайте пакета отново и изпълнете приложимите проверки. Сравнете новия списък с грешки с предишния. Изчезнала грешка може да означава и изтрит ред за услуга, затова съпоставете броя на лицата, договореностите и услугите с очаквания обхват.

Запазете точните подадени файлове, резултата от валидацията, проверяващия и потвърждението за предаване. Различавайте локална проверка, успешно изпращане и приемане от компетентния орган. Това са отделни събития. Когато предупреждение може да бъде прието, запишете основанието и упълномощеното решение, вместо да наричате целия регистър изряден.

Кратък преглед преди повторното подаване

Проверете референтната дата, задължителните връзки, дублиращите се ключове и съответствието между включените договорености и договорения периметър. Поискайте потвърждение на съдържанието от бизнес отговорника след техническия преглед на структурата. В малък екип един човек може да изпълнява и двете роли, но двата въпроса пак изискват отговор.

Изтеглете примера с връзките и дневника на корекциите. Той включва редове преди и след поправката и полета за получената грешка, отговорника, корекцията и статуса на приемане. Опростените данни са за обучение; за подаване използвайте действителния отчетен формат на органа.

Какъв резултат да очаквате от прегледа

Полезният ангажимент установява причината за отхвърлянето, отговорния източник, направената промяна и доказателството за повторна валидация. Той трябва да посочи и какво не е проверено. Прегледът на извадка от договори не доказва пълнотата на всички ИКТ (информационни и комуникационни технологии) договорености в групата.

Диасол може да договори тази работа в самостоятелната услуга за проверка и корекция на регистъра, с предварително определени системи, записи и отговорности за подаване. Страницата за обхват обяснява договарянето на допълнителна работа. Техническото приемане остава само част от точния и поддържан регистър.

В изпълнената лабораторна демонстрация липсващ идентификатор остава неразрешен след повторния тест: липсващ факт не се измисля, за да премине файлът. Демонстрацията е ограничен образователен набор, а не пълна регулаторна валидация.