# China Motor CRM — бизнес процес за обмитяване

Дата на актуализация: 05.09.2026
Статус: потвърден бизнес flow за синхронизиране на frontend, backend, мокъпи и процесна документация

## 1. Цел

Процесът управлява обмитяването на автомобили, които вече са физически приети от Тексим в Безмитен склад. Той трябва да свърже в едно проследимо митническо досие:

- избраните автомобили;
- изпратената заявка и Excel файл;
- митническия агент и имейл кореспонденцията;
- калкулацията;
- фактурата и задължението за плащане;
- плащането;
- митническото освобождаване по автомобили;
- една или повече митнически декларации и MRN номера;
- разхода и документите в досието на всеки автомобил.

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

## 2. Граници на процеса

### Начало

Автомобилът е физически приет от Тексим в `Безмитен склад`.

### Край

Автомобилът е митнически освободен и получената декларация/MRN е свързана с него. Допуска се декларацията да пристигне след освобождаването. В този период автомобилът е `Обмитен · чака декларация`.

### Процеси извън обхвата

- Международният транспорт до България е предходен процес.
- Преместването от BG пристанище до Безмитен склад е митнически транзит, изпълняван от Тексим, а не обмитяване.
- Плащането на автомобила от клиент или дилър е паралелна търговска информация и не е част от митническото задължение.
- Счетоводното завеждане в `Централен склад Чайна Мотор` е следващ Back Office/NAV процес.

## 3. Основни понятия

### Митническа заявка

Работният обект, чрез който избрани автомобили се изпращат за обработка към митнически агент. Една заявка съдържа много автомобили.

### Митническо досие

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

### Калкулация

Един набор от митнически стойности и разбивка по автомобили. Калкулацията може да бъде получена по три начина:

1. От отделен документ за калкулация.
2. Чрез директно попълване или корекция на полетата от потребителя.
3. Автоматично от фактурата, когато фактурата съдържа калкулацията.

Независимо от източника в досието има само един актуален блок `Калкулация`.

### Фактура

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

### Митническо задължение

Един запис в общия списък със задължения, създаден от потвърдената фактура. Отделната калкулация не създава второ задължение.

### Митническо освобождаване

Потвърждение, че конкретен автомобил е обмитен и може да продължи логистично. Освобождаването може да бъде потвърдено преди финалната декларация да е получена и качена.

### Митническа декларация

Финалният документ с MRN. Една декларация може да покрива един или много автомобили. Една митническа заявка може да има повече от една декларация.

## 4. Участници и отговорности

| Участник | Бизнес отговорност |
|---|---|
| Логистика | Подготвя и изпраща заявката, качва и валидира получените документи, потвърждава освободените автомобили и декларациите |
| Митнически агент | Получава заявката, връща калкулация и/или фактура, обработва автомобилите и изпраща декларациите |
| Счетоводство / Finance | Извършва плащането и поддържа достоверния платежен статус |
| NAV | Предоставя информация за извършено плащане, референция и платежен документ, когато интеграцията разполага с тях |
| Back Office | Вижда митническата готовност и документите като част от подготовката за NAV завеждане и издаване |
| Система | Генерира Excel, пази досието, разчита документите, попълва формите, сравнява стойности, съпоставя автомобили и поддържа статусите |

Достъпът до действията се управлява чрез отделни permissions и допустим текущ статус, а не чрез hardcoded име на роля.

## 5. Основен бизнес модел

### Ниво заявка/досие

На ниво митническа заявка се пазят:

- номер на заявката;
- дата на създаване и дата на изпращане;
- създател и изпращач;
- митнически агент;
- имейл получатели и копия;
- генериран Excel;
- изпратен имейл и история на повторно изпращане;
- включени автомобили;
- калкулационни данни;
- фактура и платежен статус;
- платежна информация;
- декларации;
- текущ общ статус;
- история на действията.

### Ниво автомобил

На ниво автомобил се пазят:

- митническата заявка;
- включване в изпратения Excel;
- сума/разход от калкулацията;
- митническо освобождаване и дата;
- декларация и MRN;
- предупреждение за липсваща декларация;
- връзки към всички документи в митническото досие.

### Ниво декларация

На ниво декларация се пазят:

- файл;
- MRN;
- дата;
- митническо учреждение, когато присъства в документа;
- автомобилите, покрити от декларацията;
- прочетени и потвърдени данни;
- потребител и момент на потвърждение.

## 6. Предварителни условия

За добавяне в митническа заявка автомобилът трябва да бъде видим като физически приет в Безмитен склад.

Системата показва наличността на следните документи, без да скрива автомобила при липса:

- индивидуална заводска фактура;
- packing list;
- коносамент/BL;
- VIN списък;
- CMR до Безмитен склад;
- складов протокол за приемане;
- други налични документи от доставката.

Липсващ документ е видимо предупреждение. Дали конкретна липса блокира изпращането се управлява чрез permission и потвърждение, а действието се записва в историята.

## 7. Flow A — подготовка и изпращане на заявка

1. Логистиката отваря `Обмитяване`.
2. Основният екран показва списък с митнически заявки и текущата дневна чернова.
3. Потребителят отваря черновата и избира `Добави автомобили`.
4. Системата показва само автомобили, физически приети в Безмитен склад и без приключило обмитяване.
5. Таблицата поддържа филтри в колоните, комбинирани филтри, избор на показаните редове и избор на всички филтрирани резултати.
6. Избраните автомобили се добавят в текущата дневна чернова.
7. Черновата може да бъде затваряна и отваряна многократно. Автомобили могат да се добавят и премахват до изпращането.
8. Потребителят избира митнически агент от номенклатура и преглежда имейла.
9. Системата генерира Excel по активния шаблон за избрания агент.
10. Потребителят изпраща заявката.
11. Системата създава митническо досие със статус `Чака отговор`.
12. Изпратената чернова се затваря и автоматично се създава нова празна дневна чернова.

## 8. Flow B — получаване на калкулация и фактура

В досието има два постоянни блока:

1. `Калкулация` — документът е опционален, полетата са постоянни.
2. `Фактура` — документът е задължителен за създаване на задължението.

Не се използва избор на режим. Поведението се определя от реда на получените документи.

![AI форма — калкулация](flow-screens/flow-10-customs-response.png)

![AI форма — фактура](flow-screens/flow-10-customs-invoice.png)

### Сценарий B1 — първо пристига отделна калкулация

1. Потребителят качва документа в блока `Калкулация`.
2. Системата го разчита и попълва калкулационните полета и редовете по автомобили.
3. Потребителят проверява и може да коригира всяка стойност.
4. Потребителят запазва калкулацията самостоятелно. Досието остава със статус `Чака фактура` и не създава финансово задължение.
5. По-късно потребителят отваря същото досие и качва фактурата в блока `Фактура`.
6. Системата попълва фактурните полета, без да презаписва вече въведената отделна калкулация.
7. Системата сравнява калкулацията и фактурата.
8. При съвпадение показва потвърждение.
9. При разлика показва размера и посоката на разликата. Потребителят проверява и коригира данните.
10. Разликата не създава второ задължение и не налага автоматичен толеранс или блокаж.

### Сценарий B2 — първо пристига фактурата

1. Потребителят качва фактурата в блока `Фактура`.
2. Системата разчита документа.
3. Попълва фактурните полета.
4. Ако блокът `Калкулация` е празен, системата попълва и него от фактурата.
5. Калкулацията се маркира с източник `Попълнена от фактурата`.
6. Не се изисква отделен документ за калкулация.
7. Потребителят проверява полетата и разбивката по автомобили и потвърждава.

### Сценарий B3 — калкулация е въведена чрез полета

1. Потребителят може да попълни или коригира калкулационните полета без отделен документ.
2. Калкулацията може да се запази преди фактурата и досието остава `Чака фактура`.
3. При качване на фактурата системата запазва въведената калкулация и сравнява двете стойности.
4. Източникът на калкулацията се пази като `Въведена във формата`.

### Калкулационни данни

Формата показва най-малко:

- номер на калкулация, когато има такъв;
- дата;
- мито;
- ДДС;
- обща стойност;
- разбивка/разход по автомобил;
- източник на данните.

### Фактурни данни

Формата показва най-малко:

- номер на фактура;
- дата;
- доставчик;
- валута;
- стойност;
- файл;
- статус `Неплатена` или `Платена`.

### Потвърждение

След потвърждение на фактурата:

- в общия финансов списък се създава едно задължение;
- митническото досие става `Чака плащане`;
- калкулацията и фактурата остават видими за редакция според правата;
- източникът на всяко поле и направените корекции се пазят в историята.

## 9. Flow C — плащане

1. Митническата фактура се вижда в общия списък със задължения.
2. Счетоводство извършва плащането.
3. Платежният статус може да бъде получен от NAV.
4. Като резервен вариант може да се качи платежен документ.
5. При качен платежен документ системата го разчита и попълва референция, дата и сума.
6. Потребителят проверява и потвърждава.
7. Фактурата става `Платена`.
8. Митническото досие става `Платена · чака освобождаване`.

Платежната информация съдържа:

- източник `NAV` или `Платежен документ`;
- референция;
- дата;
- платена сума;
- документ или NAV връзка;
- потребител, потвърдил статуса.

## 10. Flow D — митническо освобождаване

1. След плащането Логистика отваря действието `Отбележи освобождаване`.
2. Системата показва всички автомобили в заявката, които още не са освободени.
3. Потребителят може да избере всички или само част от тях.
4. Потвърждава дата на освобождаване и опционална бележка.
5. Всеки избран автомобил става `Обмитен · чака декларация`.
6. Неизбраните автомобили остават в предходния статус.
7. Досието показва частичен напредък, например `4 от 7 освободени`.

Освобождаването и декларацията са отделни събития. Не трябва да се използва статус `Деклариран` като заместител на реалното митническо освобождаване.

## 11. Flow E — декларации и MRN

1. Потребителят избира `Добави декларация`.
2. Качва PDF, изображение или структуриран документ.
3. Системата показва кратък статус, че документът се чете.
4. AI попълва MRN, дата, учреждение и разпознатите автомобили.
5. Системата съпоставя VIN номерата с автомобилите от митническата заявка.
6. Потребителят вижда цялата попълнена форма и таблицата с автомобили.
7. Потребителят може да добави или премахне автомобил преди потвърждение.
8. След потвърждение декларацията се свързва с всички избрани автомобили.
9. Автомобилите стават `Обмитен · декларация налична`.
10. Ако автомобилът не е бил предварително маркиран като освободен, потвърдената декларация едновременно го маркира като освободен и комплектован.
11. Останалите автомобили в заявката продължават да чакат освобождаване или декларация.
12. Към същото досие могат да се добавят още декларации.
13. Досието е `Приключено`, когато всички автомобили имат декларация/MRN.

## 12. Статуси

### Статуси на митническата заявка

| Статус | Значение |
|---|---|
| `Чернова` | Редактируема дневна селекция, която още не е изпратена |
| `Чака отговор` | Excel заявката е изпратена, но няма потвърдена фактура |
| `Чака плащане` | Фактурата е потвърдена и има неплатено задължение |
| `Платена · чака освобождаване` | Задължението е платено, но няма освободени автомобили |
| `Частично освободена` | Само част от автомобилите са митнически освободени |
| `Чака декларация` | Има освободени автомобили без декларация/MRN |
| `Частично комплектована` | Част от автомобилите имат декларация, а други още чакат |
| `Приключена` | Всички автомобили имат декларация/MRN |

### Статуси на автомобил

| Статус | Значение |
|---|---|
| `За митническа заявка` | Автомобилът е приет в Безмитен склад и не участва в изпратена заявка |
| `Заявка изпратена` | Автомобилът участва в митническо досие, което чака отговор |
| `Чака плащане` | Фактурата е потвърдена, но задължението не е платено |
| `Платена` | Задължението е платено, но освобождаването още не е потвърдено |
| `Обмитен · чака декларация` | Освобождаването е потвърдено, но няма декларация/MRN |
| `Обмитен · декларация налична` | Има потвърдена декларация и MRN |

Статусът на автомобила се извежда от митническото досие. Не се поддържа отделен несвързан flow по автомобил.

## 13. Основен екран `Обмитяване`

Екранът по подразбиране показва митническите заявки, а не всички автомобили.

![Списък с митнически заявки](flow-screens/flow-10-customs.png)

### Горна част

- бутон `Нова / текуща заявка` с броя автомобили в черновата;
- брой заявки, чакащи отговор;
- брой заявки, чакащи плащане;
- брой платени заявки, чакащи освобождаване;
- брой заявки с автомобили, чакащи декларация.

### Филтри

- всички;
- чакат отговор;
- чакат плащане;
- чакат освобождаване;
- чакат декларация;
- приключени.

### Таблица със заявки

Колоните включват:

- заявка и дата;
- митнически агент;
- брой автомобили;
- калкулация и източник;
- фактура и стойност;
- разлика между калкулация и фактура;
- платежен статус;
- освободени автомобили;
- автомобили с декларация;
- брой декларации;
- общ статус;
- действие `Отвори`.

## 14. Екран `Митническо досие`

Досието се показва на един екран и съдържа:

![Митническо досие](flow-screens/flow-10-customs-dossier.png)

1. Заглавие, агент, брой автомобили и текущ статус.
2. Компактен progress по реалните етапи: `Заявка → Документи → Плащане → Освобождаване → Декларация`.
3. Обобщение на задължението, освободените автомобили и декларациите.
4. Документи по заявката.
5. Блок `Калкулация` с източник.
6. Блок `Фактура` и платежен статус.
7. Всички митнически декларации.
8. Таблица с автомобилите, разхода, статуса и MRN.
9. Следващо допустимо действие.
10. История на действията.

Действията върху избрани автомобили използват стандартната долна лента за масови действия от текущия frontend.

## 15. AI обработка на документи

За калкулация, фактура, платежно и декларация се използва един и същ принцип:

`Качване → статус на четене → попълнена форма → съпоставени автомобили → човешка проверка → потвърждение`

Правила:

- AI не променя бизнес статус преди човешко потвърждение.
- Всички прочетени полета могат да се коригират.
- Във формата се вижда източникът на данните.
- Неразпозната стойност остава празна; системата не измисля стойност.
- Неразпознат VIN остава видим като несъпоставен ред.
- Потребителят може да добави или премахне автомобил от предложеното съпоставяне.
- След потвърждение документът и полетата се пазят в досието и автомобилите.

## 16. Разпределение на сумите

Когато документът съдържа разбивка по автомобил, системата използва разчетените редове.

Когато документът съдържа само обща сума:

- системата не дели автоматично сумата поравно;
- редовете по автомобили остават празни или непотвърдени;
- потребителят въвежда или коригира стойностите;
- общата сума и сборът по автомобили могат да бъдат сравнени;
- разлика се показва като предупреждение, без измислен автоматичен толеранс.

## 17. Финансово поведение

- Потвърдената фактура създава едно задължение в общия списък със задължения.
- Отделната калкулация не е финансов документ и не създава задължение.
- Статусът на фактурата е само `Неплатена` или `Платена`.
- Плащането се свързва с митническото досие и засегнатите автомобили.
- В досието на автомобила митническият разход се вижда като отделен тип допълнителен разход.
- Клиентското/дилърското плащане се показва само като паралелна справочна информация и не променя митническия статус.

## 18. Връзка с Back Office и Централен склад

Back Office вижда по автомобил:

- има ли митническа заявка;
- платено ли е митническото задължение;
- освободен ли е автомобилът;
- има ли декларация/MRN;
- кои документи липсват;
- линк към митническото досие.

При `Заведи счетоводно (NAV)` системата показва конкретните липси. Липсваща декларация или друг документ води до предупреждение. Потребител с необходимото право може да потвърди продължаването, а решението се записва в audit историята.

Счетоводното преместване в `Централен склад Чайна Мотор` не променя автоматично физическата локация на автомобила.

## 19. Известия и имейл

- Преди изпращане потребителят вижда получатели, копия, тема, текст и приложения.
- Изпращането създава запис в историята.
- Повторно изпращане е отделно действие и не създава нова митническа заявка.
- Получена фактура създава задача/видимост за Finance.
- Потвърдено плащане създава задача за Логистика да потвърди освобождаването.
- Освободени автомобили без декларация остават във видима работна опашка.

## 20. Permissions

Необходимите бизнес права са отделни действия, които могат да бъдат добавяни към различни роли:

- вижда митнически заявки и документи;
- създава и редактира дневна чернова;
- изпраща митническа заявка;
- качва и разчита калкулация;
- качва и разчита фактура;
- валидира и редактира прочетени стойности;
- вижда финансови стойности;
- отразява плащане;
- потвърждава митническо освобождаване;
- качва и валидира декларация/MRN;
- продължава при предупреждение;
- вижда audit история.

Конкретните начални роли получават permissions според одобрената ролева матрица. Бизнес flow-ът не проверява директно дали потребителят се казва `Логистика`, `Finance` или `Admin`.

## 21. История и проследимост

Историята пази най-малко:

- добавяне и премахване на автомобил от черновата;
- изпращане и повторно изпращане на заявката;
- генериран Excel и използван шаблон;
- качен, заменен или изтрит документ;
- AI разчет и човешка корекция;
- потвърдена калкулация и фактура;
- установена разлика;
- платежен статус и източник;
- освободени автомобили;
- добавена декларация и покрити автомобили;
- permission-based продължаване при предупреждение;
- потребител, дата и час на всяко действие.

Не е необходим отделен versioning flow. Историята пази направените промени.

## 22. Гранични случаи

### Частично освобождаване

Само избраните автомобили стават `Обмитен · чака декларация`. Останалите запазват статуса си.

### Частична декларация

Декларацията се свързва само с разпознатите и потвърдени автомобили. Досието остава активно за останалите.

### Декларация преди ръчно отбелязване на освобождаването

Потвърдената декларация едновременно отбелязва покритите автомобили като освободени и с наличен MRN.

### Разлика между калкулация и фактура

Системата показва разликата. Потребителят коригира стойностите или потвърждава наличните данни. Няма автоматичен процентен толеранс и няма второ задължение.

### Фактура без отделна калкулация

Фактурата попълва двата блока. Калкулацията ясно показва, че източникът е фактурата.

### Калкулация без документ

Потребителят може да попълни калкулационните полета. Фактурата остава задължителният документ за създаване на задължението.

### Документ с неразпознати автомобили

Несъпоставените редове се показват отделно. Потребителят ги свързва или ги оставя извън потвърждението.

### Автомобил без декларация в следващ процес

Системата показва предупреждение `Обмитен · чака декларация`. Продължаването се разрешава само на потребител с право и се записва в историята.

## 23. Отворена конфигурация

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

Това не променя бизнес flow-а. Екранът и досието трябва да поддържат различни шаблони по митнически агент, без промяна на останалия процес.

## 24. Задължителна консистентност с останалия CRM

- Таблиците използват същите колонни филтри като регистъра `Автомобили`.
- Изборът на показаните и всички филтрирани автомобили е в master checkbox контролата.
- Масовите бизнес действия са в долната контекстна лента.
- Документите използват общия AI intake компонент.
- Формата се попълва директно от прочетения документ.
- Ръчната корекция е част от същата форма, а не отделен паралелен flow.
- Финансовото задължение използва общия екран за фактури и плащания.
- Документите се виждат и от митническото досие, и от досието на автомобила.
- Видимостта и действията се управляват чрез permissions и допустим статус.
- Всяко изключение и override се записва в audit историята.