От 1.7.2009 всеки търговец трябва да се регистрира в централния регистър на търговците EORI. Същия номер се използва в CWS, премахвайки проблемната корелация между БУЛСТАТ/ЕГН и EORI.
Намирането на клиент (търговец) в CWS по зададен TIN е лесно:
Търси се клиент:
select * from clients C where cnt_approved='Y' and not(cnt_exp_date<=NOW)
and cnt_eori=TIN
Ако липсва се връща грешка DTI_TIN_NOT_REGISTERED.
Връщат се всички намерени клиенти C
(Може да има повече от един клиент, което ще бъде филтрирано допълнително)
4.5Използване на данните за регистрация
DTI използва данните за регистрация в следните случаи:
Логин в DTI Уеб: става с електронен подпис и TIN. Маркирано по-долу като <Уеб>
Автентикация на заявка към DTI B2B. Маркирано по-долу като
Възможните грешки са описани в секция 6 и са посочени в края на всяка проверка по-долу.
Електронният подпис се извлича от заявката за уеб услуга.
<Уеб> Електронният подпис се извлича от браузъра с Java Applet
Подписът се валидира. Възможни грешки: DTI_SIG_MISSING DTI_SIG_INVALID DTI_SIG_REVOKED DTI_SIG_EXPIRED
Ако съдържанието на заявката не съответства на подписа: DTI_SIG_CHECKSUM
Търси се служител (потребител) по подпис и съответното Certification Authority:
select * from clients_empl CE, cert_authorityCA where ca.ca_sid = cnte.ca_sid andCE.cnte_dig_cert_sern=? andCA.ca_cert_auth_name = ?
and not(cer_exp_date<=NOW).
Ако липсва се връща грешка DTI_MISSING_EMPL
Търси се клиент (търговец) по дадения TIN (в <Уеб>) или TIN на изпращача (SenIdeCodQuaMES4 в ) използвайки 4.4
Списъкът клиенти C се филтрира допълнително с условие
C.cnt_sid in (CE.cnt_sid)
Ако не остане нито един се връща грешка DTI_MISSING_CLIENT
Списъкът клиенти C се филтрира допълнително с условие
cnt_is_b2b='Y'
Ако не остане нито един се връща грешка DTI_NOT_REGISTERED_B2B.
Ако остане повече от един клиент, взимаме произволен запис, тъй като няма значение кой ще ползваме. AM ще гарантира процедурно, че данните във всички C и свързаните към тях записи в CWS ще са еднакви (ECS2BCA-369):
еднакъв набор clients_empl с еднакви ЕГН/Имена
еднакъв набор clients_repr.cntr_agent_num
Всичко надолу е за :
Запомняме избрания клиент в променлива sender
ECS2 Core (не DTI) проверява следните условия свързани с изпращача:
RBG018: Sender Identification Code Qualifier и Recipient Identification Code Qualifier идентифицират индивидуалния изпращач и получател съответно. Те се попълват така: ако ECS то <код на МУ>, ако търговец то
RBG018: Sender Identification Code Qualifier и Recipient Identification Code Qualifier идентифицират индивидуалния изпращач и получател съответно. Те се попълват така: ако ECS то <код на МУ> в БГ, ако търговец то на Service Provider.
При връзка от тип b2b Sender Identification Code Qualifier и Recipient Identification Code Qualifier може да се различават от EORI на декларатора
При ползване на DTI Web Sender Identification Code Qualifier и Recipient Identification Code Qualifier съвпадат с EORI на декларатора.
Например за 507 се проверява traderCarrier.tin, за 513 traderDeclarant.tin и пр.
RBG870: IF 613 was sent by trader representative then is Required, and = , and it must be mentioned in the declaration 615 (or last accepted amendment 613)
ELSE (613 was sent by the person lodging the summary declaration): =
Sender и traderDeclarant може да съвпадат но може и да се различават.
Ако се различават, се прави проверка дали в таблица clients_repr, traderDeclarant е посочил sender-a като упълномощен да подава декларации от името на traderDeclarant.
Проверява се, че declarantPersonID съвпада с cnte_egn (на един от намерените служители). Ако не: ERROR_906 с DTI_REGISTRATION_MISMATCH
Ако е посочен traderDeclarant/agentNumber:
Търси се запис за представител:
select * from clients_repr where cntr_eori=sender.cnt_eori)
and not(cntr_exp_date<=NOW)
(Проверено е в CWS, че ако има няколко записа, cntr_agent_num съвпада)
Проверява се дали cntr_agent_num съвпада с traderDeclarant/agentNumber. Ако не: ERROR_906 с DTI_REGISTRATION_MISMATCH за traderDeclarant/agentNumber
4.6Сигурност, упълномощаване
При вход в системата (DTI Web) и при проверка на входящи съобщения (DTI Web и B2B), ECS2 прави проверка за валидността на сертификата по OCSP или по CRL.
4.6.1Проверка по OCSP
OCSP проверка на валидността на сертификати се прави за доставчици, които предоставят тази услуга. Индикатор за поддържането на OCSP e наличието на URL за OCSP в cws в trusted_ca.ocsp_url.
Ако при OCSP проверка се върне грешка за проверявания сертификат, заявената операция (вход в системата – DTI Web, подаване на съобщение – DTI Web и B2B) се отказва.
Ако при OCSP проверка се върне положителен отговор, обработката по заявената операция (вход в системата – DTI Web, подаване на съобщение – DTI Web и B2B) продължава.
Ако при опит за OCSP проверка, самата OCSP услуга предоставена от доставчика на сертификати не е налична:
изчаква се определено време за timeout (15 сек.);
прави се следващ опит. Броят опити се задава в конфигурационен файл.
ако след изчерпване на зададени брой опити, OCSP услугата не може да бъде използвана се преминава към проверка по CRL.
4.6.2Проверка по CRL
Проверка по CRL се извършва за сертификати, за които няма OCSP услуга (trusted_ca.ocsp_url е null) или при недостъпност на OCSP услугата.
CRL-те са предварително свалени от скрипт поддържан от АМ. Скрипта се грижи периодичното им сваляне и поддържане в актуално състояние.
имената на CRL файловете са със следния формат: .crl. Например: 10.crl, 126.crl, 9.crl, ... 1207.crl и т.н.
пътя до директорията със CRL-и се задава в конфигурационен файл.
4.6.3Достъп до данните, сигурност:
Един търговец може да разглежда тези съобщения, на които той е изпращач или получател, и да извлече (5.3) тези съобщения, на които е получател.
Когато движението е в ненулево състояние (напр. TDESND, TCEGPE) и дадена роля на търговец вече е установена (напр. TDE, TCE), само търговецът в тази роля може да изпраща последващи съобщения. Това се проверява в Security\ECS2-Agents-Validation.doc
Секция 4.4 реализира следните изисквания за изпращачи и упълномощаване:
Trader Service Provider:
TSP (подаващият ЕАД) трябва да е записан като Sender в 515 и 513. Може да се различава от TDE, може и да съвпадат.
TSP трябва да е регистриран в DTI с електронен подпис
Ако TSP се различава от TDE, TDE трябва да е упълномощил TSP да подава от негово име в таблица clients_repr
Случаи на получаване на съобщения в зависимост от използването на SP
Trader Service Provider (TSP):
През B2B - трябва да вижда всички съобщения от и към „неговите” търговци
През DTI Web - не ползва DTI Web. Може да вижда и там съобщенията от и към „неговите” търговци
Trader, който използва TSP
През B2B - не вижда съобщенията. Вижда ги чрез своя СП
През DTI Web - не ползва DTI Web. Може и там да вижда съобщенията от и към него, като търговец
Trader, който не използва SP
През B2B - трябва да вижда всички съобщения от и към него
През DTI Web - трябва да вижда всички съобщения от и към него
TDE:
TDE (подаващият ЕАД) трябва да е записан като Trader Declarant в ЕАД
Trader Declarant трябва да е регистриран в DTI с електронен подпис
Agent Number на TDE (ако е митнически агент) трябва да съвпада с този в упълномощаването от първия Trader Exporter споменат в ЕАД
TPL (подаващият ОДН) трябва да е записан като Person Lodging в ОДН.
TPL може да подава корекции за движението.
TRE:
Ако даден TRE е посочен като Trader Representative в ОДН, той може да подава корекции за това движение (виж 3.5.2).
Корекцията трябва да посочва същия Trader Representative
TCE:
Всеки TCE може да Представи стоките (507) за всеки MRN, това става без упълномощаване.
TODO AM: това е потенциален риск за сигурността (MRN hijacking).
Всеки TCE може да Представи манифест (547), виж решение ECS2BCA-341
5DTI B2G Уеб услуги
DTI B2G е интерфейс от тип "система-система", с който информационна система (софтуерен продукт) на търговеца (или митнически агент/представител, който представлява търговеца) може да извършва директна комуникация с ECS2.
Комуникацията се извършва през уеб услуга "B2G". Mетодите на услугата са описани по-долу.
За всеки метод входният параметър (in):
Съдържа ТИН на изпращача в поле SenIdeCodQuaMES4. Това се използва за идентификация на изпращача.
Трябва да е подписан с електронния подпис на изпращача (виж 4.2). Това се използва за автентикация на изпращача.
При грешка се връща fault с код и описание на грешката (виж 6)
При възникване на непредвидена грешка в системата (например недостъпна регистрационна база данни), тя се логва и се връща DTI_INTERNAL_SERVER_ERROR
5.1sendMessage
Изпраща съобщениe към ECS2. Параметри:
in: подписанo XML съобщениe тип BGnnnB (виж 3.3, част "Входящи към АМ"): 507 513 514 515 547 583 613 615 906
При успех: съобщението се предава към АМ и се записва в базата данни на DTI за преглед като форма (XML не се записва, за да се пести място).
ECS2 може да върне BG906B за същото съобщение по-късно, ако то е бизнес-невалидно, напр. грешен MRN или движението е в неподходящо състояние
fault:
Ако типа съобщение не съответства на гореизброените: DTI_BAD_MTYPE
Всички прости грешки: съобщението не се записва и не се предава към АМ.
ERROR_906: съобщението се записва в базата данни на DTI за преглед като форма (XML не се записва, за да се пести място). Записва се BG906B с детайлите на грешката (може да бъде прочетено по-късно с getMessage). Съобщението не се предава към АМ.
5.2getMessageIDs
Получава идентификаторите на ново-изпратени съобщения от ECS2 към този търговец. Параметри:
in: подписан XML съдържащ TIN на изпращача:
BGA39687359ZZZ0
out (при успех): списък идентификатори на съобщения, изпратени от ECS2 към този търговец и още непрочетени (status=UNREAD). Списъкът е във вид:
12345678901234 12345678901234 ...
където идентификаторите са тип an..14. Списъкът може да е празен.
Получава съобщение с даден идентификатор. Параметри:
in: подписан XML съдържащ TIN на изпращача и идентификатор на исканото съобщение във вид:
BGA39687359ZZZ0 12345678901234
Всички съобщения, с които изискваме информация за съобщенията (messages) обграждаме с тагове
out (при успех): XML съобщение тип BGnnnB (виж 3.3, част "Изходящи към АМ"): 504 505 509 521 522 525 528 529 548 549 551 560 561 582 599 604 605 628 906
fault:
Ако липсва съобщение с този идентификатор: DTI_MISSING_MESSAGE
Ако съобщението не е за този TIN: DTI_NOT_OWNER
И други възможни прости грешки.
5.4deleteMessage
Изтрива съобщение с даден идентификатор. Параметри:
in: подписан XML съдържащ TIN на изпращача и идентификатор на съобщението за изтриване във вид:
BGA39687359ZZZ0 12345678901234
При успех: съобщението се маркира като прочетено (status=READ). XML съдържанието му се изтрива, за да се пести място (съобщението остава в базата данни на DTI за преглед като форма)
fault:
Ако липсва съобщение с този идентификатор: DTI_MISSING_MESSAGE
Ако съобщението не е за този TIN: DTI_NOT_OWNER
И други възможни прости грешки.
5.5getMesageIDsByCriteria
Получава идентификаторите на изпратените съобщения от ECS2 към даден търговец на базата на входящи критерии.
in: подписан XML със следния формат:
BGA39687359ZZZ0
20130422
20130426
0
yyCCxxxxxxxxxxxxxZ
YYxxxxxxxxxxxxxRZnnnnn
Полето SenIdeCodQuaMES4 е задължително, останалите са опционални.
Възможните стойности за полето Status са:
0 (непрочетени съобщения);
1 (прочетени);
2 (непрочетени и прочетени).
out (при успех): списък идентификатори на съобщения, изпратени от ECS2 към дадения търговец. Списъкът е във вид:
12345678901234 12345678901234 ...
където идентификаторите са тип an..14. Списъкът може да е празен.
fault
възможни прости грешки
5.6Параметри в ecs2.properties касаещи getMeassage функциите
# Whether to mark message as read on getMessage
dti.b2b.mark.message.read=false
# Number of message ids to be returned by getMessageIds and getMesageIDsByCriteria
Типът подадено съобщение не е измежду разрешените за това действие
2015
DTI_MISSING_MESSAGE
Липсва съобщение с дадения идентификатор
2016
DTI_NOT_OWNER
Съобщението с дадения идентификатор е за друг получател (не DTI клиента, собственик на дадения електронен подпис)
2024
DTI_BAD_STATUS
Невалидна стойност в полето . Възможните стойности са 0, 1 или 2.
2025
DTI_INVALID_FROM_DATE
Грешка в полето . Невалидна дата.
2026
DTI_INVALID_TO_DATE
Грешка в полето <То>. Невалидна дата.
2099
DTI_INTERNAL_SERVER_ERROR
Грешка в приложението. Записана е в системният лог. Моля опитайте по-късно!
5187
DTI_MESSAGE_SENDER_NOT_AUTHORISED
'За всеки в входящите съобщения (513, 515, 547, 613, 615) трябва да има оторизиран , който да подава съобщения вместо него (или Message Declarant да съвпада с Message Sender)
6.2Сложни грешки
BG906B грешките специфични за DTI са описани по-долу. errorXPath указва полетата, които се проверяват
CL_ERROR_DETAIL
Описание
errorXPath
EORI
Подаденият TIN не може да бъде намерен в EORI (връща се специфично съобщение от EORI услугата)
DTI_REGISTRATION_MISMATCH
Данните за Търговец Декларатор и Лице Декларатор се взимат от DTI регистрацията и не могат да се променят
traderDeclarant/agentNumber
declarantPersonID
7Таймер за комуникация между DTI B2G и DTI Web
Комуникацията между DTI B2G/Web и ECS2 Core се извършва през общата база на DTI. За целта в DTI B2G е реализиран Quartz таймер, който :
Проверява на всеки 30 секунди за наличието на съобщения със статус DTI_PENDING,
