# China Motor CRM - User Stories, Acceptance Criteria и QA Test Cases

- Версия: 05.09.2026
- Статус: QA спецификация; бизнес изискванията се управляват по епици и stories
- Бизнес изисквания: [Epic и user story структура](./requirements/README.md)
- Бизнес източник: [Интерактивни процесни flow-ове](./process-flows.html)
- Основен мокъп: [CRM мокъп](./mock/crm-full-mock.html)
- Дилърски мокъп: [Дилърски портал](./mock/dealer-process-mock.html)
- Тексим мокъп: [Оперативен портал](./mock/texim-operational-portal.html)

## 1. Цел и начин на използване

Документът пази подробните QA сценарии и досегашните стабилни `US`/`AC`/`QA` идентификатори. Каноничното бизнес описание, полетата и взаимовръзките са в [requirements](./requirements/README.md); този файл не трябва самостоятелно да въвежда ново бизнес правило.

Идентификаторите се използват последователно:

- `US-Fxx-yy` - user story за Flow `xx`;
- `AC-Fxx-yy` - acceptance criterion;
- `QA-Fxx-yy` - QA test case;
- `AC-GEN-yy` и `QA-GEN-yy` - общо правило за всички flow-ове.

Flow 2 е общият процес от дилърска заявка до финално одобрено търсене. Flow 19-22 описват същия процес на ниво конкретни екрани и роли в дилърския портал. При противоречие се прилагат по-конкретните критерии от Flow 19-22.

## 2. Общи бизнес принципи

### 2.1 Достъп и организационен scope

- Действие се разрешава от конкретно permission и допустимия текущ статус, а не от hardcoded име на роля.
- Един потребител може да има няколко комбинации `Компания + Роля + Представителство`.
- Данните се ограничават според активната компания и разрешения организационен scope.
- Ролевите наименования в този документ са начални профили. Реалното право за действие остава permission-based.

### 2.2 Входящи документи и AI

Единният входящ документен процес е:

`Качване -> структурно четене/OCR -> AI съпоставяне -> попълнена форма -> човешка проверка -> потвърждение`

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

### 2.3 Валидации и soft warnings

- Липсващ VIN, двигател, индивидуална фактура или документ не е глобален hard gate.
- Когато бизнес рискът трябва да бъде видим, системата показва конкретно предупреждение по автомобил или документ.
- Override е допустим само при съответното permission и се записва в историята.
- Hard gate се прилага само когато е изрично описан в acceptance criterion.

### 2.4 Таблици и масови действия

- Таблиците поддържат колонни филтри, комбинирани с `AND` логика.
- По подразбиране автомобилите са без групиране; групирането е опционално.
- Поддържат се единична селекция, Shift селекция, текуща страница и всички филтрирани резултати.
- Контекстната лента с масови действия се показва само при избрани редове.
- Действията в лентата се изчисляват от permission и допустимите статуси на избраните записи.

### 2.5 История и свързани обекти

- Всяко потвърждение, отказ, override, изпращане, плащане и промяна на статус пази автор и момент.
- Заводска поръчка, транспортна поръчка, доставка, фактура, митническа заявка и хомологация са отделни свързани обекти.
- Физическа локация, NAV склад и крайна дестинация са отделни стойности.
- `NAV ID` е постоянен идентификатор за обмен с Navision и е различен от VIN и инвентарния номер.

## 3. Общи Acceptance Criteria

- **AC-GEN-01** Потребител без необходимото permission не вижда активно действие и не може да го изпълни чрез директен URL или заявка.
- **AC-GEN-02** Потребител с permission не може да изпълни действие, ако текущият статус не го допуска.
- **AC-GEN-03** Смяната на активна компания или роля обновява менюто, данните и действията според новия scope.
- **AC-GEN-04** Всички потвърждения, откази, overrides и статусни промени записват автор, дата и час.
- **AC-GEN-05** При документен import разчетените данни се попълват в редактируема форма преди запис.
- **AC-GEN-06** Липсващите или несигурните AI стойности са маркирани и никога не се попълват с измислена стойност.
- **AC-GEN-07** Soft warning показва точната причина и засегнатите записи, но позволява продължаване на потребител с override permission.
- **AC-GEN-08** Масовото действие обработва само допустимите избрани записи и показва причината за пропуснатите.
- **AC-GEN-09** Повторно потвърждение или изпращане не създава дублиран бизнес обект.
- **AC-GEN-10** Платежен статус `Платена` се задава след потвърждение на форма, попълнена от разчетен платежен документ или ръчно; бъдещ NAV/import използва същия модел.
- **AC-GEN-11** Всички таблици запазват отделни филтруеми колони за свързаните бизнес обекти.
- **AC-GEN-12** Основните flow-ове са използваеми без хоризонтално припокриване на desktop, tablet и mobile.
- **AC-GEN-13** При поне 200 резултата филтрите, пагинацията и изборът на всички филтрирани запазват точния набор между страниците.

## 4. Общи QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-GEN-01 | Permission отказ | Отвори действие с потребител без permission; повтори чрез директен URL/API | Действието не е достъпно и няма промяна на данни |
| QA-GEN-02 | Недопустим статус | Отвори запис в приключен или предходен статус и опитай действие | Системата отказва действието и показва актуалния статус |
| QA-GEN-03 | Потребител с няколко роли | Смени компания, роля и представителство | Менюто, данните и действията се обновяват без смесване на scope |
| QA-GEN-04 | AI import | Качи валиден документ с познати и непознати стойности | Познатите стойности са попълнени; непознатите са празни и маркирани |
| QA-GEN-05 | Човешка корекция | Коригирай разчетено поле и потвърди | Записва се коригираната стойност и източникът остава проследим |
| QA-GEN-06 | Soft warning | Стартирай действие с липсващ незадължителен документ | Показва се конкретно предупреждение; разрешен override продължава и се логва |
| QA-GEN-07 | Масова селекция | Филтрирай таблица, избери всички филтрирани и изпълни действие | Обработват се всички допустими филтрирани редове, не само текущата страница |
| QA-GEN-08 | Смесени статуси | Избери допустими и недопустими записи | Допустимите могат да продължат; останалите са изброени с причина |
| QA-GEN-09 | Идемпотентност | Потвърди или изпрати два пъти едно и също действие | Има един бизнес резултат и проследима история, без дубликат |
| QA-GEN-10 | Audit history | Изпълни одобрение, override и статусна промяна | В историята присъстват правилните автор, дата, час и действие |
| QA-GEN-11 | Свързани колони | Филтрирай автомобилите по заводска поръчка, доставка и фактура поотделно | Всеки филтър работи независимо и комбинирано |
| QA-GEN-12 | Responsive | Повтори основен flow на 1440 px, 1024 px, 768 px и 390 px | Няма застъпване, недостъпни действия или нечетим текст |
| QA-GEN-13 | Голям набор | Зареди поне 200 автомобила, филтрирай, смени страница и избери всички филтрирани | Броячът и селекцията съвпадат с целия филтриран набор |

---

## Flow 1 - Цели и планиране

### US-F01-01 - Управление и проследяване на цели

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

#### Acceptance Criteria

- **AC-F01-01** Целта пази година, доставчик, марка/модел и неотрицателно количество.
- **AC-F01-02** Екранът показва цел, поръчани бройки, одобрено дилърско търсене, доставени бройки и изпълнение.
- **AC-F01-03** Надвишаването на целта е видимо, но не блокира заявка или заводска поръчка.
- **AC-F01-04** Системата не предлага и не променя автоматично количества на база таргета.
- **AC-F01-05** Редакцията на цел изисква permission и се записва в историята.
- **AC-F01-06** Текущата версия поддържа годишни таргети; месечни и тримесечни таргети са бъдещо разширение.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F01-01 | Създаване на цел | Въведи валидна година, доставчик, модел и количество | Целта се записва и се вижда в съответните обобщения |
| QA-F01-02 | Невалидно количество | Въведи отрицателна стойност | Записът е отказан с конкретна грешка |
| QA-F01-03 | Надвишен таргет | Създай поръчка над оставащата цел | Показва се надвишаване, но поръчката не е блокирана |
| QA-F01-04 | Permission | Опитай редакция без право | Полетата и действието за запис не са достъпни |

## Flow 2 - Дилърска заявка до одобрено търсене

### US-F02-01 - Последователно количествено одобрение

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

#### Acceptance Criteria

- **AC-F02-01** Клиентска заявка следва `Dealer Sales -> Sales Manager -> Dealer Manager -> Мениджър търговска мрежа -> Продуктов мениджър -> Бранд мениджър`.
- **AC-F02-02** Всяко ниво вижда първоначалното и всички предходни потвърдени количества.
- **AC-F02-03** Всяко ниво може да потвърди максимум количеството от непосредствено предходното ниво.
- **AC-F02-04** Само решението на Бранд мениджъра потвърждава количеството към дилъра.
- **AC-F02-05** Разликата между заявеното и финално одобреното количество е отказана; одобреното количество остава активно до изпълнение.
- **AC-F02-06** Заявката се движи само напред и не използва общ неясен статус `Върната`.
- **AC-F02-07** Неактивни заявки над 90 и 120 дни са видими като отделни ескалации, без автоматична промяна на количество или статус.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F02-01 | Пълно одобрение | Потвърди едно и също количество на всички нива | Дилърът получава финалното количество след Бранд мениджъра |
| QA-F02-02 | Последователно намаляване | Заяви 20; потвърди 18, 15 и 12 на следващите нива | Всяко ниво вижда историята; финално се потвърждават 12 |
| QA-F02-03 | Опит за увеличение | При предходно количество 15 въведи 16 | Потвърждението е отказано с максимално допустимо 15 |
| QA-F02-04 | Прескачане на ниво | Опитай действие на Продуктов мениджър преди Мениджър търговска мрежа | Действието не е достъпно |
| QA-F02-05 | Частично решение | Заяви 100 и одобри финално 60 | 60 остават активни до изпълнение; 40 са видими като отказани |
| QA-F02-06 | Ескалация | Подготви заявки на 89, 90, 119 и 120 дни | Ескалации се показват само на правилните прагове и не променят статуса |

## Flow 3 - Заводска поръчка

### US-F03-01 - Консолидиране на количества към доставчик

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

#### Acceptance Criteria

- **AC-F03-01** Една заводска поръчка съдържа позиции само за един доставчик.
- **AC-F03-02** Смесена селекция се разделя в отделна поръчка за всеки доставчик.
- **AC-F03-03** Одобреният, включеният и оставащият брой по дилърска заявка се показват отделно.
- **AC-F03-04** Поръчката и редовете й остават активни и могат да се редактират от потребители с permission; редовете не са отделен междинен бизнес обект.
- **AC-F03-05** След първо изпращане поръчката може да остане активна и да получава допълнителни автомобили и документи без version workflow.
- **AC-F03-06** Всеки добавен автомобил се създава като отделен запис в автомобилния регистър.
- **AC-F03-07** Редът на позициите следва реда на добавяне от Продуктовия мениджър.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F03-01 | Един доставчик | Избери количества за един доставчик и създай поръчка | Създава се една поръчка с индивидуални автомобилни записи |
| QA-F03-02 | Смесени доставчици | Избери модели от два доставчика | Създават се две отделни поръчки без загубени позиции |
| QA-F03-03 | Частично използване | Включи 6 от 10 одобрени бройки | Остатъкът 4 остава видим за следваща поръчка |
| QA-F03-04 | Постоянна поръчка | Изпрати поръчка, после добави нови автомобили | Новите позиции се добавят към същата поръчка с audit history |
| QA-F03-05 | Ред на добавяне | Добави в ред B, A, C | Позициите се показват B, A, C |

## Flow 4 - Производство на ниво автомобил

### US-F04-01 - Актуализация на производството от документ

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

#### Acceptance Criteria

- **AC-F04-01** Каченият Excel попълва редактируема форма с разпознатите автомобили и производствени данни.
- **AC-F04-02** Потребителят може да коригира, добави или премахне ред преди потвърждение.
- **AC-F04-03** Статусите се движат `Поръчана -> В производство -> Произведена` по конкретни автомобили.
- **AC-F04-04** Неразпознат автомобил остава за човешка проверка и не се създава автоматично с измислени данни.
- **AC-F04-05** Липсващ VIN, двигател или индивидуална фактура е видим, но не блокира записването на производствения резултат.
- **AC-F04-06** Масовата промяна обработва само автомобилите в допустим предходен статус.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F04-01 | Валиден производствен Excel | Качи файл с поръчани и произведени автомобили | Формата е попълнена и след потвърждение статусите се обновяват |
| QA-F04-02 | Корекция | Промени разчетена дата или модел преди запис | Записва се коригираната стойност |
| QA-F04-03 | Липсващ VIN | Качи произведен автомобил без VIN | Редът е маркиран, но може да бъде потвърден |
| QA-F04-04 | Смесен статус | Избери поръчани и вече произведени автомобили за масово действие | Обработват се само допустимите; останалите имат причина |

## Flow 5 - Проформи, индивидуални фактури и плащане към завода

### US-F05-01 - Обработка на проформа

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

### US-F05-02 - Валидация на индивидуални фактури

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

#### Acceptance Criteria

- **AC-F05-01** Една заводска поръчка може да има множество проформи; потребител с permission може да добавя и премахва проформи.
- **AC-F05-02** Качената проформа попълва редактируема форма с позиции, количества и цени.
- **AC-F05-03** Индивидуалните фактури могат да бъдат качени пакетно и се свързват с конкретни автомобили, когато съпоставянето е възможно.
- **AC-F05-04** Системата сравнява проформа и фактура и показва всяка ценова разлика.
- **AC-F05-05** Няма автоматичен толеранс или блокировка при ценова разлика; потребителят вижда и потвърждава стойността.
- **AC-F05-06** Фактура без VIN остава във формата за допълване и може да бъде потвърдена без измислен VIN.
- **AC-F05-07** Плащането се потвърждава чрез една форма, попълнена от платежен документ или ръчно; бъдещ NAV/import подава данни към същия модел.
- **AC-F05-08** Неплатен автомобил може да бъде преразпределян; след плащане разпределението към дилър се заключва.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F05-01 | Нова проформа | Качи проформа и потвърди разчетените позиции | Проформата е свързана с поръчката и позициите са видими |
| QA-F05-02 | Множество проформи | Добави втора проформа към същата поръчка | И двата документа са достъпни; няма автоматично version ограничение |
| QA-F05-03 | Пакет фактури | Качи няколко индивидуални фактури | Разпознатите фактури се свързват с правилните автомобили |
| QA-F05-04 | Ценова разлика | Качи фактура с цена, различна от проформата | Разликата се показва; потребителят може да коригира или потвърди |
| QA-F05-05 | Фактура без VIN | Качи фактура без еднозначен VIN | Формата остава редактируема и не генерира VIN |
| QA-F05-06 | Преразпределение | Смени дилър преди и след потвърдено плащане | Преди плащане е позволено; след плащане е отказано |

## Flow 6 - Международен транспорт Китай към България

### US-F06-01 - Транспортна поръчка и заявка за оферта

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

### US-F06-02 - Множество доставки по една поръчка

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

#### Acceptance Criteria

- **AC-F06-01** Транспортна поръчка може да съдържа много доставки.
- **AC-F06-02** Всяка доставка пази собствен превозвач, маршрут, дата на товарене, ETA, BL, фактура и автомобили.
- **AC-F06-03** Добавянето на доставка започва с качване на BL и фактура; разчетените стойности се попълват в същата крайна форма.
- **AC-F06-04** Капацитетът се задава по модел и избраните конкретни автомобили са видими преди потвърждение.
- **AC-F06-05** Финалният транспортен разход се разпределя пропорционално по моделен капацитет и сумата на разпределените разходи е равна на фактурата.
- **AC-F06-06** Логистика може да коригира автоматично разпределен разход преди запис.
- **AC-F06-07** Липсващ VIN, двигател или индивидуална фактура не блокира създаването на доставката.
- **AC-F06-08** Имейлът към превозвача е опционален; когато се изпраща, съдържанието е на английски.
- **AC-F06-09** Един автомобил не може да бъде активен в две международни доставки едновременно.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F06-01 | Създаване на поръчка | Филтрирай произведени автомобили, избери всички филтрирани и създай поръчка | Всички допустими автомобили са включени |
| QA-F06-02 | Документен старт | Качи BL и фактура | Формата се попълва с маршрут, дати, превозвач, стойност и автомобили |
| QA-F06-03 | Непълен AI резултат | Качи документ без ETA | ETA остава празно и маркирано за допълване |
| QA-F06-04 | Много доставки | Добави две доставки с различни превозвачи и дати | И двете са в една поръчка с независими статуси и документи |
| QA-F06-05 | Капацитет и разход | Избери няколко модела с различен капацитет | Разходът е разпределен пропорционално и сборът е точен |
| QA-F06-06 | Ръчна корекция | Промени разхода по автомобил преди запис | Корекцията се запазва и общият сбор се валидира |
| QA-F06-07 | Дублиран автомобил | Опитай да добавиш автомобил от активна доставка във втора | Автомобилът е недостъпен или действието е отказано с причина |
| QA-F06-08 | Без имейл | Създай заявка без изпращане на имейл | Поръчката се създава без email събитие |
| QA-F06-09 | Имейл | Изпрати заявката към превозвач | Preview и изпратеният текст са на английски и се пазят в историята |

## Flow 7 - Проследяване до BG пристанище

### US-F07-01 - ETA, известяване и пристигане

Като Логистика искам да виждам актуалното ETA на всяка международна доставка и да отбележа реалното пристигане, за да подготвя Тексим и следващите операции.

#### Acceptance Criteria

- **AC-F07-01** Всяка активна доставка показва потвърдено ETA като основна стойност.
- **AC-F07-02** Промяна на ETA пази предишната и новата стойност в историята.
- **AC-F07-03** Предварителното известие към Тексим се изпраща автоматично еднократно според настройваем период преди ETA.
- **AC-F07-04** При действие `Пристигна в BG` конкретните автомобили получават физическа локация `BG пристанище`.
- **AC-F07-05** При пристигане се изпраща отделно автоматично еднократно известие към Тексим.
- **AC-F07-06** И двете известия показват статус и история и могат да бъдат изпратени повторно ръчно.
- **AC-F07-07** Промяна на ETA след изпратено предварително известие не създава автоматично второ съобщение.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F07-01 | Видимо ETA | Отвори активна доставка | ETA се вижда в списъка и детайла |
| QA-F07-02 | Промяна на ETA | Редактирай ETA и запази | Новата стойност е активна, старата е в историята |
| QA-F07-03 | Предварително известие | Достигни конфигурирания период преди ETA | Изпраща се едно известие и статусът му е видим |
| QA-F07-04 | Повторно известие | Избери ръчно повторение | Създава се нов комуникационен запис без дублиране на бизнес събитието |
| QA-F07-05 | Пристигане | Маркирай доставка като пристигнала | Само автомобилите от доставката са на BG пристанище и Тексим е известен |

## Flow 8 - BG пристанище към Безмитен склад

### US-F08-01 - Вътрешен курс и физическо приемане от Тексим

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

#### Acceptance Criteria

- **AC-F08-01** Във вътрешен курс могат да се включат само автомобили с физическа локация `BG пристанище`, които не са в друг активен курс.
- **AC-F08-02** Курсът пази автомобилите, водача, превозното средство, началната и крайната локация.
- **AC-F08-03** Подписаният CMR се качва при физическото приемане в Безмитния склад, не при тръгването.
- **AC-F08-04** CMR следва общия AI flow и попълва редактируема приемна форма.
- **AC-F08-05** Тексим може да приеме само част от автомобилите; неприетите остават в активния курс.
- **AC-F08-06** Приетият автомобил получава физическа локация `Безмитен склад` и складов протокол.
- **AC-F08-07** Допълнителният PDI на Тексим може да се изпълни по-късно и не блокира приемането или следващата логистика.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F08-01 | Създаване на курс | Избери свободни автомобили на пристанище и създай курс | Автомобилите са `Към Безмитен склад` |
| QA-F08-02 | Дублиран курс | Опитай да включиш автомобил от активен курс | Действието е отказано с посочен активен курс |
| QA-F08-03 | AI CMR | Качи подписан CMR при приемане | Формата се попълва и остава редактируема преди потвърждение |
| QA-F08-04 | Частична приемка | Потвърди 7 от 10 автомобила | 7 са в склада; 3 остават в курса |
| QA-F08-05 | Без PDI Тексим | Приеми автомобил и продължи без изпълнен PDI | Процесът продължава; PDI остава отделна видима задача |

## Flow 9 - Хомологация

### US-F09-01 - Обработка на хомологационни документи

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

#### Acceptance Criteria

- **AC-F09-01** Хомологацията може да започне преди физическото пристигане, когато необходимите технически документи са налични.
- **AC-F09-02** Каченият документ се разчита и попълва редактируема форма преди потвърждение.
- **AC-F09-03** Системата показва по автомобил дали има CoC, Удостоверение за индивидуално одобряване или друг приложим резултат.
- **AC-F09-04** Един документ може да бъде свързан с всички покрити автомобили, без да се губи индивидуалната проследимост.
- **AC-F09-05** Липсващ или нечетим документ е видим като задача, без измислени данни.
- **AC-F09-06** Преглед, редакция и потвърждение се управляват от отделни permissions.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F09-01 | Ранно стартиране | Качи технически документ преди пристигане | Процесът се създава и автомобилите остават в текущата логистика |
| QA-F09-02 | Валиден документ | Качи четим документ за няколко автомобила | Формата е попълнена и документът се свързва с всички покрити автомобили |
| QA-F09-03 | Нечетим документ | Качи файл с неразпознати стойности | Полетата остават празни и са маркирани за проверка |
| QA-F09-04 | Permission | Опитай потвърждение с право само за преглед | Потвърждението не е достъпно |

## Flow 10 - Обмитяване

### US-F10-01 - Митническа заявка, калкулация и фактура

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

### US-F10-02 - Освобождаване и декларации

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

#### Acceptance Criteria

- **AC-F10-01** Логистика създава редактируема митническа чернова от избрани автомобили в Безмитния склад.
- **AC-F10-02** При изпращане системата генерира Excel и записва получателя, момента и изпратените автомобили.
- **AC-F10-03** Досието има отделни блокове `Калкулация` и `Фактура`.
- **AC-F10-04** Калкулацията може да бъде попълнена от отделен документ/полета или директно от фактурата, когато тя пристигне първа.
- **AC-F10-05** Когато има отделна калкулация и фактура, системата сравнява сумите и показва разликата.
- **AC-F10-06** Само фактурата създава едно финансово задължение; калкулацията не създава второ задължение.
- **AC-F10-07** Потвърденото плащане променя заявката на `Платена - чака освобождаване`.
- **AC-F10-08** Освобождаването се потвърждава за конкретни автомобили и може да бъде частично.
- **AC-F10-09** Освобождаването и получаването на митническа декларация са отделни събития.
- **AC-F10-10** Една заявка може да има много декларации, а една декларация може да покрива много автомобили.
- **AC-F10-11** Качената декларация попълва MRN и автомобилите в редактируема AI форма.
- **AC-F10-12** Автомобил без финална декларация може да продължи логистично, но липсата остава видима и дава soft warning при счетоводно завеждане.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F10-01 | Изпращане на заявка | Избери автомобили, генерирай и изпрати Excel | Заявката пази точния набор и комуникационната история |
| QA-F10-02 | Първо калкулация | Качи калкулация, после фактура | Има два документа, едно задължение и видимо сравнение |
| QA-F10-03 | Първо фактура | Качи само фактура | Фактурата попълва и блока за калкулация и създава едно задължение |
| QA-F10-04 | Различни суми | Качи калкулация и фактура с различна стойност | Разликата е видима, без автоматично второ задължение |
| QA-F10-05 | Плащане | Потвърди реално плащане | Статусът е `Платена - чака освобождаване` |
| QA-F10-06 | Частично освобождаване | Освободи част от автомобилите | Само избраните са обмитени; заявката остава отворена за останалите |
| QA-F10-07 | Много декларации | Качи две декларации към една заявка | Всяка декларация и покритите автомобили са проследими |
| QA-F10-08 | Декларация за много коли | Качи декларация с няколко VIN | MRN се свързва с всеки потвърден автомобил |
| QA-F10-09 | Липсваща декларация | Продължи с освободен автомобил без декларация | Логистиката продължава; липсата остава видима и предупреждава по-късно |

## Flow 11 - Заявка към Тексим за дилър или Централен склад

### US-F11-01 - Подготовка и изпращане на вътрешен транспорт

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

#### Acceptance Criteria

- **AC-F11-01** Заявката показва по автомобил документи, хомологация, еко такса, обмитяване, плащане, физическа локация, NAV склад и крайна дестинация.
- **AC-F11-02** Липсващ документ, декларация, плащане или друг readiness елемент показва конкретен soft warning.
- **AC-F11-03** Потребител с override permission може да продължи след изрично потвърждение; действието се записва.
- **AC-F11-04** Автомобил може да бъде изпратен директно от Тексим към дилър, когато крайната му дестинация е дилърско представителство.
- **AC-F11-05** Физически към Централен склад се изпращат само демо автомобили и свободен собствен сток.
- **AC-F11-06** Счетоводното завеждане в `Централен склад Чайна Мотор` не означава физическо преместване.
- **AC-F11-07** Заявката съдържа точните автомобили, начална и крайна локация и получател.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F11-01 | Готови автомобили | Избери напълно подготвени коли и създай заявка към дилър | Заявката се създава без предупреждения |
| QA-F11-02 | Липсващо плащане | Избери неплатен автомобил | Показва се точен warning; override е възможен само с право |
| QA-F11-03 | Липсваща декларация | Избери обмитен автомобил без декларация | Показва се липсващият документ, без автоматичен hard block |
| QA-F11-04 | Директно към дилър | Създай маршрут Тексим -> представителство | Физическата крайна дестинация е дилърът, без междинно физическо преместване |
| QA-F11-05 | Централен склад | Опитай физическо изпращане на клиентски автомобил към Централен склад | Действието е отказано; демо или свободен собствен сток е допустим |
| QA-F11-06 | Счетоводно завеждане | Заведи автомобил в NAV Централен склад | NAV складът се сменя, физическата локация остава непроменена |

## Flow 12 - Тексим издава и изпраща към дилър

### US-F12-01 - Частично изпълнение на заявка към дилър

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

#### Acceptance Criteria

- **AC-F12-01** Тексим вижда само заявки и автомобили в разрешения му оперативен scope.
- **AC-F12-02** Преди издаване се показват точните автомобили, дестинацията и документите на заявката.
- **AC-F12-03** Тексим може да издаде част от автомобилите; останалите остават `За издаване`.
- **AC-F12-04** Издадените автомобили получават статус `Изпратена към дилър`, а не `Приета от дилър`.
- **AC-F12-05** Физическата локация се променя на `В транспорт към дилър` и движението се записва в историята.
- **AC-F12-06** Един автомобил не може да бъде издаден повторно по друга активна заявка.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F12-01 | Пълно издаване | Издай всички автомобили по заявката | Всички са `Изпратена към дилър`; заявката е изпълнена |
| QA-F12-02 | Частично издаване | Издай 3 от 5 автомобила | 3 са в транспорт; 2 остават за издаване |
| QA-F12-03 | Грешна локация | Опитай да издадеш автомобил, който не е физически при Тексим | Действието е отказано с актуалната локация |
| QA-F12-04 | Повторно издаване | Опитай второ издаване на вече изпратен автомобил | Не се създава дублирано движение |

## Flow 13 - Приемане от дилъра

### US-F13-01 - Приемо-предавателен протокол по автомобил

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

#### Acceptance Criteria

- **AC-F13-01** За приемане са достъпни само автомобили със статус `Изпратена към дилър` за съответното представителство.
- **AC-F13-02** Приемащият може да избере част или всички автомобили от доставката.
- **AC-F13-03** Приемката записва конкретния автомобил, приемащия потребител и момента на физическото получаване.
- **AC-F13-04** За всеки приет автомобил са задължителни checklist и снимки от огледа.
- **AC-F13-05** При щета или липса описанието е задължително и се създава свързан случай.
- **AC-F13-06** Системата генерира протокол само за потвърдените автомобили.
- **AC-F13-07** Неприетите автомобили остават в доставката за следваща приемка.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F13-01 | Пълна приемка | Попълни checklist и снимки за всички автомобили | Всички са приети и има протокол |
| QA-F13-02 | Частична приемка | Приеми 2 от 4 автомобила | Протоколът съдържа 2; останалите 2 чакат приемане |
| QA-F13-05 | Щета без описание | Избери `Щета` и остави описанието празно | Потвърждението е блокирано за този автомобил |
| QA-F13-06 | Щета с данни | Добави описание и снимки | Автомобилът се приема и се създава свързан damage case |

## Flow 14 - Щета или несъответствие

### US-F14-01 - Единно досие на щета

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

#### Acceptance Criteria

- **AC-F14-01** Щета може да бъде създадена на пристанище, при приемане в Безмитен склад, при издаване или при приемане от дилър.
- **AC-F14-02** Случаят пази автомобил, място и етап на откриване, описание, снимки, автор и момент.
- **AC-F14-03** Правата за преглед, редакция, решение и приключване са отделни permissions.
- **AC-F14-04** Няма hardcoded роля или единствен permission profile за обработка на щетите.
- **AC-F14-05** Случаят поддържа резултати `Без забележки`, `Щета`, `Чака допълнителен оглед`, `За ремонт` и `Приключен` според разрешените действия.
- **AC-F14-06** Няма автоматичен срок, след който системата сама приключва или отказва калкулацията.
- **AC-F14-07** Приет автомобил със щета може да продължи логистично, докато случаят се обработва отделно, освен ако потребител с permission не го спре изрично.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F14-01 | Щета на различни етапи | Създай случаи на пристанище и при дилър | И двата имат правилен етап и общ формат на досието |
| QA-F14-02 | Permission разделение | Влез с права само за преглед | Данните са видими, но решение и редакция не са достъпни |
| QA-F14-03 | Допълнителен оглед | Маркирай случая като чакащ оглед | Случаят остава активен и автомобилът пази връзката |
| QA-F14-04 | Логистично продължаване | Приеми автомобил със създаден damage case | Приемането се записва, а щетата остава отворена |
| QA-F14-05 | Audit | Смени отговорник и приключи случая | Историята съдържа двете действия, авторите и моментите |

## Flow 15 - Известия и комуникационна история

### US-F15-01 - Автоматични и ръчни известия

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

#### Acceptance Criteria

- **AC-F15-01** Автоматично известие се създава еднократно за конкретното бизнес събитие.
- **AC-F15-02** Повторното изпращане създава нов комуникационен запис и не презаписва предходния.
- **AC-F15-03** Историята показва тип, канал, получатели, момент, автор/система и резултат.
- **AC-F15-04** Неуспешното изпращане е видимо и може да бъде повторено.
- **AC-F15-05** Когато имейлът е опционален, бизнес действието може да се запази без изпращане.
- **AC-F15-06** Имейлите към международен превозвач са на английски.
- **AC-F15-07** При смяна на дилър се известява само новият дилър за възможно логистично забавяне.
- **AC-F15-08** Промяна на ETA след предварително известие не изпраща автоматично второ известие.
- **AC-F15-09** Получателите се определят от business relation, company/representation scope и permission, а не от hardcoded име на роля.
- **AC-F15-10** За всяко събитие одобрената notification matrix определя trigger, получатели, канал, автоматично/ръчно изпращане, език, съдържание и приложени документи.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F15-01 | Автоматично известие | Задействай бизнес събитие два пъти | Автоматичното известие е едно; бизнес действието не е дублирано |
| QA-F15-02 | Ръчно повторение | Избери `Изпрати отново` | Има нов запис с нов момент и запазен предходен запис |
| QA-F15-03 | Неуспешен канал | Симулирай email error | Статусът е неуспешен и повторението е достъпно |
| QA-F15-04 | Опционален email | Запази транспортна заявка без изпращане | Заявката е създадена и няма email history запис |
| QA-F15-05 | Международен превозвач | Отвори preview на транспортен email | Съдържанието е на английски |
| QA-F15-06 | Смяна на дилър | Преразпредели неплатен автомобил | Известие получава само новият дилър |
| QA-F15-07 | Organizational scope | Задействай събитие за конкретен дилър и представителство | Получатели са само потребителите с приложим relation, scope и permission |
| QA-F15-08 | Ръчно повторение след автоматично известие | Изпрати повторно от историята | Създава се нов комуникационен запис и автоматичният не се презаписва |

## Flow 16 - Подготовка за издаване, склад и NAV

### US-F16-01 - Единна Back Office опашка

Като Back Office искам да виждам паралелната готовност по документи, хомологация, еко такса, обмитяване и NAV, за да подготвя автомобилите без изкуствен линеен статус `Комплектоване`.

### US-F16-02 - NAV import, export и складова проследимост

Като Back Office искам да импортирам и експортирам реалния NAV stock формат и да пазя NAV склада отделно от физическата локация, за да синхронизирам системите без грешни движения.

#### Acceptance Criteria

- **AC-F16-01** Единната опашка показва отделен резултат по документи, хомологация, еко такса, обмитяване, плащане и NAV завеждане.
- **AC-F16-02** Няма отделен задължителен линейно приключващ статус `Комплектоване`.
- **AC-F16-03** Досието показва наличните файлове, очакваните документи и възможност за преглед, сваляне и качване според permission.
- **AC-F16-04** При завеждане в Централен склад липсите се показват като конкретни soft warnings и могат да бъдат override-нати с право.
- **AC-F16-05** Всеки автомобил има отделни `NAV ID`, инвентарен номер и VIN.
- **AC-F16-06** NAV import съпоставя съществуващ автомобил първо по NAV ID и обновява, вместо да създава дубликат.
- **AC-F16-07** Неразпознат NAV ред остава за човешка проверка.
- **AC-F16-08** NAV склад, физическа локация и крайна дестинация се пазят и филтрират отделно.
- **AC-F16-09** NAV import или export не променя физическата локация.
- **AC-F16-10** Export използва същите 69 колони, ред и разделител като предоставения NAV stock файл.
- **AC-F16-11** От `Складова наличност` се експортират само автомобили, заведени в `Централен склад Чайна Мотор`.
- **AC-F16-12** Физически към Централния склад се придвижват само демо автомобили и свободен собствен сток.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F16-01 | Паралелна готовност | Отвори автомобил с частично изпълнени направления | Всеки резултат и липса са отделно видими |
| QA-F16-02 | Преглед на документи | Отвори наличен документ и качи липсващ с правилно permission | Файловете са достъпни и историята се обновява |
| QA-F16-03 | Soft warning при завеждане | Заведи автомобил с липсваща декларация | Показва се warning; разрешен override продължава и се логва |
| QA-F16-04 | NAV update | Импортирай ред със съществуващ NAV ID и нов NAV склад | Съществуващият автомобил се обновява без дубликат |
| QA-F16-05 | Несъпоставен NAV ред | Импортирай непознат NAV ID с непълни данни | Редът остава за проверка и няма измислен автомобил |
| QA-F16-06 | Разделени локации | Импортирай нов NAV склад | NAV складът се обновява; физическата локация не се променя |
| QA-F16-07 | NAV export | Експортирай филтрирани автомобили от Централен склад | Файлът има 69 колони и само допустимите автомобили |
| QA-F16-08 | Недопустим export | Опитай export на автомобил извън NAV Централен склад | Автомобилът не се включва и причината е видима |
| QA-F16-09 | Физически централен склад | Изпрати демо и клиентски автомобил към Централния склад | Демо е допустим; клиентският е отказан |

## Flow 17 - Еко такси и индивидуални декларации

### US-F17-01 - Партида за еко такса

Като Back Office искам да избера допустими автомобили, да изпратя заявка, да обработя фактурата и да генерирам индивидуалните декларации, за да завърша еко таксата по автомобил.

#### Acceptance Criteria

- **AC-F17-01** Еко такса може да се стартира от автомобилния регистър или от специализирания Back Office екран.
- **AC-F17-02** Допустимият автомобил има CoC или Удостоверение за индивидуално одобряване.
- **AC-F17-03** Преди изпращане системата показва наличния документ и липсите по всеки автомобил.
- **AC-F17-04** Една партида съдържа точния списък автомобили и изпратената заявка към доставчика на услугата.
- **AC-F17-05** Качената фактура се разчита и попълва редактируема форма със стойност и покрити автомобили.
- **AC-F17-06** Плащането се отразява отделно след реално потвърждение.
- **AC-F17-07** След плащане индивидуалните декларации се генерират и свързват с конкретните автомобили.
- **AC-F17-08** Автомобил с вече отчетена еко такса не се включва повторно в активна партида.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F17-01 | Стартиране от автомобили | Филтрирай и избери допустими коли; стартирай еко такса | Създава се партида със същата селекция |
| QA-F17-02 | Липсващ документ | Избери автомобил без CoC/УИО | Липсата е видима и автомобилът не изчезва от селекцията |
| QA-F17-03 | Фактура AI | Качи фактура | Формата се попълва и може да бъде коригирана преди запис |
| QA-F17-04 | Плащане | Качи платежно или попълни полетата ръчно и потвърди формата | Партидата става `Платена` и пази източника и данните |
| QA-F17-05 | Декларации | Приключи платена партида | Всеки автомобил има своя декларация в досието |
| QA-F17-06 | Повторно включване | Опитай да добавиш автомобил с отчетена еко такса | Действието е отказано с причина |

## Flow 18 - Документни комплекти към дилър

### US-F18-01 - Подготовка, изпращане и връщане на комплект

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

#### Acceptance Criteria

- **AC-F18-01** Комплектът е за един дилър, едно представителство и конкретен набор автомобили.
- **AC-F18-02** Автомобили от различни дилъри или представителства не се смесват в един комплект.
- **AC-F18-03** Системата показва кои документи са генерирани, изпратени, върнати и липсват.
- **AC-F18-04** Генерирането, изпращането и връщането са отделни събития с история.
- **AC-F18-05** Върнатият файл се свързва с правилния комплект и всички покрити автомобили.
- **AC-F18-06** Частично върнатите документи оставят комплекта отворен само за липсващите позиции.
- **AC-F18-07** Повторно изпращане или заменен файл пази предходния запис и момента на промяната.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F18-01 | Валиден комплект | Избери автомобили за един дилър и генерирай | Създава се един комплект с правилните автомобили |
| QA-F18-02 | Смесени представителства | Избери автомобили от две представителства | Селекцията се разделя или действието изисква отделни комплекти |
| QA-F18-03 | Изпращане | Изпрати генерирания комплект | Статусът и комуникационната история се обновяват |
| QA-F18-04 | Частично връщане | Качи част от подписаните документи | Получените са свързани; липсващите остават отворени |
| QA-F18-05 | Заменен файл | Качи коригиран подписан документ | Новият е активен, предходният остава в историята |

## Flow 19 - Dealer Sales създава поръчка след приета оферта

### US-F19-01 - Клиентска поръчка и заявка към вносителя

Като Dealer Sales искам да създам поръчка от приета оферта, като системата наследи вече въведените данни и създаде заявка към China Motor само когато е необходима.

#### Acceptance Criteria

- **AC-F19-01** Действието `Създай поръчка` е достъпно само за оферта със статус `Приета от клиента` и съответното permission.
- **AC-F19-02** Формата наследява клиент, автомобил или конфигурация, цена, търговец, представителство и източник.
- **AC-F19-03** При наличие на капаро се пазят сума, дата, начин на плащане и документ.
- **AC-F19-04** От една оферта не може да се създаде втора активна клиентска поръчка.
- **AC-F19-05** При автомобил от свободния собствен склад на дилъра не се създава заявка към China Motor.
- **AC-F19-06** При автомобил или конфигурация от China Motor се създава свързана дилърска заявка със статус `Чака Sales Manager`.
- **AC-F19-07** Офертата и клиентската поръчка пазят snapshot на клиентската конфигурация и цена.
- **AC-F19-08** Липсващ VIN при неналична конфигурация не блокира поръчката.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F19-01 | Поръчка от приета оферта | Отвори приета оферта и създай поръчка | Данните са наследени и поръчката е създадена |
| QA-F19-02 | Неприета оферта | Опитай създаване от чернова или изпратена оферта | Действието не е достъпно |
| QA-F19-03 | Дублирана поръчка | Повтори действието за същата оферта | Не се създава втори активен запис |
| QA-F19-04 | Собствен дилърски склад | Създай поръчка за свободен собствен автомобил | Има клиентска поръчка, но няма заявка към China Motor |
| QA-F19-05 | Източник China Motor | Създай поръчка за автомобил на вносителя | Създава се свързана заявка `Чака Sales Manager` |
| QA-F19-06 | Неналична конфигурация | Създай поръчка без VIN | Поръчката се създава с пълната конфигурация и празен VIN |
| QA-F19-07 | Snapshot | Промени каталожната цена след създаване | Съществуващата клиентска поръчка пази първоначалната цена |

## Flow 20 - Sales Manager проверява и одобрява

### US-F20-01 - Одобрение на заявка от търговец

Като Sales Manager искам да видя заявката на търговеца и да потвърдя или намаля количеството, за да я предам към Dealer Manager.

### US-F20-02 - Поръчка за дилърски склад

Като Sales Manager искам да създам заявка за свободна дилърска наличност без клиентска оферта, за да я изпратя директно за одобрение от Dealer Manager.

#### Acceptance Criteria

- **AC-F20-01** Опашката показва само заявки в разрешения екип и представителства.
- **AC-F20-02** Формата показва оферта, клиент, представителство, автомобил/конфигурация, цена и заявено количество.
- **AC-F20-03** Заявеното количество е предварително попълнено като максимално допустимо.
- **AC-F20-04** Sales Manager може да потвърди същото или по-малко цяло количество, включително нула.
- **AC-F20-05** След одобрение статусът е `Чака Dealer Manager` и историята съдържа решението.
- **AC-F20-06** При решение нула не се изпращат бройки към следващото ниво; няма отделен бутон за отказ или връщане в approval веригата и решението остава видимо.
- **AC-F20-07** Поръчката за дилърски склад не изисква клиентска оферта, клиентска поръчка или капаро.
- **AC-F20-08** Поръчката за склад съдържа модел/конфигурация, количество, предназначение, представителство и заявител и започва от `Чака Dealer Manager`.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F20-01 | Пълно одобрение | Потвърди заявеното количество | Заявката чака Dealer Manager със същото количество |
| QA-F20-02 | Намаляване | Намали 20 на 18 | Следващото ниво получава 18; първоначалните 20 остават видими |
| QA-F20-03 | Увеличение | Опитай да промениш 20 на 21 | Потвърждението е отказано |
| QA-F20-04 | Друг екип | Отвори заявка извън scope | Заявката не е видима или е недостъпна |
| QA-F20-05 | Поръчка за склад | Създай заявка за склад като Sales Manager | Тя започва от Dealer Manager и няма клиент/капаро |
| QA-F20-06 | Нулево решение | Потвърди 0 бройки | Няма движение към следващо ниво; няма отделен отказ или връщане; решението е в историята |

## Flow 21 - Dealer Manager одобрява и изпраща

### US-F21-01 - Финално дилърско одобрение

Като Dealer Manager искам да потвърдя финансовия ангажимент на дилъра и да изпратя заявката към China Motor, за да започне обработката от вносителя.

#### Acceptance Criteria

- **AC-F21-01** Dealer Manager вижда клиентските и складовите заявки на цялата дилърска компания в своя scope.
- **AC-F21-02** Формата показва предназначение, представителство, цена и всички предходни количествени решения.
- **AC-F21-03** Потвърденото количество не може да надвишава количеството от Sales Manager.
- **AC-F21-04** При одобрение се създава точно една заявка при China Motor със статус `Чака Мениджър търговска мрежа`.
- **AC-F21-05** Изпращането записва дилър, представителство, заявител, количество, цена, автор и момент.
- **AC-F21-06** Ценово изключение остава видимо, но не прескача одобрителните нива.
- **AC-F21-07** Оттеглянето на дилърската заявка е отделно soft-delete действие за нейния създател или потребител с permission за деактивиране; то не изтрива клиентската поръчка, офертата или капарото.
- **AC-F21-08** Approval формата няма отделни действия за отказ или връщане; решение нула приключва текущото търсене без потвърдени бройки.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F21-01 | Одобрение и изпращане | Потвърди заявка в допустим статус | China Motor получава една заявка; статусът е актуален и от двете страни |
| QA-F21-02 | Намаляване | Намали количеството и изпрати | China Motor вижда намаленото и пълната история |
| QA-F21-03 | Двойно изпращане | Натисни изпращане повторно | Не се създава дубликат |
| QA-F21-04 | Ценово изключение | Одобри заявка под дилърската цена | Изключението остава видимо и заявката следва нормалния път |
| QA-F21-05 | Оттегляне | Деактивирай дилърската заявка с разрешен потребител | Заявката е soft-deleted; клиентската поръчка и капарото остават |

## Flow 22 - China Motor приема и потвърждава количество

### US-F22-01 - Решение на вносителя и обратна връзка към дилъра

Като участник от China Motor искам заявката да мине през трите количествени решения и финалният резултат да се върне към дилъра, за да започне поръчването само на одобрените бройки.

#### Acceptance Criteria

- **AC-F22-01** Мениджър търговска мрежа е първото ниво на China Motor и може да потвърди максимум дилърското количество.
- **AC-F22-02** Продуктовият мениджър вижда заявката, наличностите, търсенето и таргетите и предлага максимум количеството от предходното ниво.
- **AC-F22-03** Бранд мениджърът потвърждава максимум предложеното от Продуктовия мениджър количество.
- **AC-F22-04** След финалното решение дилърът вижда заявено, потвърдено, включено в заводски поръчки, разпределено и доставено количество.
- **AC-F22-05** Продуктовият мениджър получава задача за включване на одобрените бройки в поръчка към доставчик.
- **AC-F22-06** Неодобрената разлика е отказана; финално одобреното количество остава активно до пълно изпълнение.
- **AC-F22-07** Поръчването по доставчици не губи връзката с дилърската заявка и представителството.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F22-01 | Пълно решение | Потвърди еднакво количество на трите нива | Дилърът и Продуктовият мениджър са известени след Бранд мениджъра |
| QA-F22-02 | Различни количества | Потвърди 20 -> 18 -> 16 | Финалът е 16; всички решения са видими |
| QA-F22-03 | Преждевременно известие | Спри на Продуктов мениджър | Дилърът още няма финално потвърдено количество |
| QA-F22-04 | Частично поръчване | Включи 10 от 16 в заводска поръчка | 10 са включени, остатъкът 6 остава видим |
| QA-F22-05 | Разделяне по доставчик | Одобри модели от различни доставчици | Създават се отделни заводски поръчки с връзка към заявката |

## Flow 23 - Дилърски фактури, падежи и плащания

### US-F23-01 - Финансов списък на дилъра

Като дилърски потребител с финансов достъп искам да виждам и свалям документите към China Motor, разделени по платежен статус, за да управлявам текущите и просрочените задължения.

### US-F23-02 - Отразяване и потвърждение на плащане

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

#### Acceptance Criteria

- **AC-F23-01** Списъкът показва номер, вид документ, дата, падеж, поръчка, автомобили, сума, валута и статус.
- **AC-F23-02** Налични са филтри `Всички`, `За плащане`, `Просрочени` и `Платени`.
- **AC-F23-03** `За плащане` означава неплатен документ преди падеж; `Просрочена` означава неплатен след падеж; `Платена` означава потвърдено плащане.
- **AC-F23-04** Dealer Sales вижда разрешените документи по собствените поръчки; Sales Manager - по своя екип/представителство; Dealer Manager - за дилърската компания.
- **AC-F23-05** Потребител с permission може да отвори и свали оригиналния документ.
- **AC-F23-06** Свалянето не променя платежния статус.
- **AC-F23-07** Платежното се качва към конкретен документ и пази файл, дата, сума и автор.
- **AC-F23-08** Платежният файл е опционален; след потвърждение на редактируемата форма документът и покритите автомобили стават `Платени`.
- **AC-F23-09** Един документ с минал падеж и потвърдено плащане се показва като `Платена`, не като `Просрочена`.
- **AC-F23-10** Една поръчка може да има повече от един финансов документ и всеки пази собствен падеж и статус.
- **AC-F23-11** Дублиран номер за същия издател се маркира за проверка и не създава скрито второ задължение.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F23-01 | За плащане | Създай неплатен документ с бъдещ падеж | Показва се в `За плащане` |
| QA-F23-02 | Просрочена | Премини падежа без потвърдено плащане | Документът автоматично се вижда в `Просрочени` |
| QA-F23-03 | Сваляне | Свали документа | Файлът се отваря/сваля; статусът е непроменен |
| QA-F23-04 | Плащане от документ | Качи платежно, провери разчетените данни и потвърди | Документът е `Платена` с дата, сума, референция и източник |
| QA-F23-05 | Плащане без документ | Попълни същите полета ръчно и потвърди | Документът е `Платена`, без задължителен файл |
| QA-F23-06 | Платено след падеж | Потвърди плащане на просрочен документ | Документът преминава в `Платени` |
| QA-F23-07 | Ролеви scope | Сравни Sales, Sales Manager и Dealer Manager | Всеки вижда само разрешения финансов набор |
| QA-F23-08 | Много документи | Добави две фактури към една поръчка | Всеки документ има независим падеж и статус |
| QA-F23-09 | Дублиран номер | Добави същия номер от същия издател | Показва се предупреждение и няма неволно двойно задължение |

## Flow 24 - Дилърът приема изпратените автомобили

### US-F24-01 - Оперативна приемка в представителството

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

#### Acceptance Criteria

- **AC-F24-01** Екранът показва доставка, маршрут, CMR, дата на изпращане, автомобили и текуща приемка.
- **AC-F24-02** За приемане могат да бъдат избрани само неприети автомобили за активното представителство.
- **AC-F24-03** Checklist и снимките са задължителни за всеки избран автомобил.
- **AC-F24-04** При щета или липса се изисква описание и се създава свързан случай.
- **AC-F24-05** Протоколът съдържа само приетите при текущото действие автомобили.
- **AC-F24-06** Частичната приемка оставя доставката отворена за останалите автомобили.
- **AC-F24-07** След пълна приемка доставката е приключена, а автомобилите са `Приета от дилъра` с правилна физическа локация.

#### QA Test Cases

| ID | Сценарий | Стъпки | Очакван резултат |
|---|---|---|---|
| QA-F24-01 | Приемка на един автомобил | Попълни задължителните данни и потвърди | Има индивидуален резултат и протокол |
| QA-F24-02 | Частична доставка | Приеми част от автомобилите | Доставката е частично приета; остатъкът е точен |
| QA-F24-03 | Пълна доставка | Приеми последните автомобили | Доставката е приключена и всички са физически при дилъра |
| QA-F24-04 | Повторна приемка | Опитай да избереш вече приет автомобил | Автомобилът не е достъпен за повторно приемане |
| QA-F24-05 | Грешно представителство | Отвори доставка за друго представителство без scope | Приемането не е достъпно |
| QA-F24-06 | Щета | Регистрирай щета със снимки и описание | Автомобилът е приет и damage case е свързан |

---

## 5. Traceability матрица

| Flow | User stories | Основен интерфейс |
|---|---|---|
| 1. Цели | US-F01-01 | CRM -> Цели по модели / Dashboard |
| 2. Дилърско търсене | US-F02-01 | CRM -> Дилърски заявки |
| 3. Заводска поръчка | US-F03-01 | CRM -> Поръчки към завода |
| 4. Производство | US-F04-01 | CRM -> Автомобили / Производство |
| 5. Проформи и фактури | US-F05-01, US-F05-02 | CRM -> Поръчка към завода -> Фактури |
| 6. Международен транспорт | US-F06-01, US-F06-02 | CRM -> Поръчки за транспорт |
| 7. ETA и пристигане | US-F07-01 | CRM -> Международни доставки |
| 8. Безмитен склад | US-F08-01 | Тексим -> Пристанище / За приемане |
| 9. Хомологация | US-F09-01 | CRM -> Хомологация |
| 10. Обмитяване | US-F10-01, US-F10-02 | CRM -> Обмитяване |
| 11. Заявка към Тексим | US-F11-01 | CRM -> Към дилър |
| 12. Издаване от Тексим | US-F12-01 | Тексим -> За издаване |
| 13. Приемане от дилър | US-F13-01 | Дилър -> Доставки за приемане |
| 14. Щети | US-F14-01 | CRM / Тексим / Дилър -> Щети |
| 15. Известия | US-F15-01 | CRM -> Известия / комуникационна история |
| 16. Back Office и NAV | US-F16-01, US-F16-02 | CRM -> Подготовка за издаване / Складова наличност |
| 17. Еко такси | US-F17-01 | CRM -> Еко такси |
| 18. Комплекти към дилър | US-F18-01 | CRM -> Комплекти към дилър |
| 19. Dealer Sales поръчва | US-F19-01 | Дилър -> Оферти -> Създай поръчка |
| 20. Sales Manager | US-F20-01, US-F20-02 | Дилър -> Заявки за одобрение |
| 21. Dealer Manager | US-F21-01 | Дилър -> Заявки за одобрение |
| 22. China Motor решение | US-F22-01 | CRM -> Дилърски заявки / Дилър -> Към вносител |
| 23. Дилърски фактури | US-F23-01, US-F23-02 | Дилър -> Към вносител -> Фактури |
| 24. Дилърска приемка | US-F24-01 | Дилър -> Доставки за приемане |

## 6. Решения, които не трябва да се превръщат в AC преди потвърждение

Следните теми остават конфигурационни или отворени. До решение QA не трябва да приема конкретна стойност като дефект:

1. Дали `първи дилър поръчал, първи получил` е задължително разпределително правило. Засега хронологията е визуален ориентир, а редът в заводската поръчка следва реда на добавяне от Продуктовия мениджър.
2. Точният Excel шаблон и колони към митническия агент.
3. Финалните капацитети по модел за разпределение на транспортния разход.
4. Езиците в българския портал.
5. Детайлната начална permission матрица за двата вносителя.
6. Финалните получатели и канали в notification matrix.

## 7. Definition of Done за разработка

- Всички приложими `AC-GEN-*` и `AC-Fxx-*` са реализирани или изрично маркирани извън обхват.
- Интерфейсът използва текущите frontend компоненти за таблици, филтри, selection dock, форми, модали, statuses и alerts.
- Няма паралелен алтернативен UI за същото действие.
- Няма hardcoded проверки по име на роля.
- Всички статусни промени и overrides имат audit history.
- Всички входящи документи следват единния AI flow.
- Няма необяснено дублиране на поръчка, автомобил, задължение, доставка или известие.
- Desktop, tablet и mobile изгледите са проверени.
- Липсват browser console errors в основните happy paths.

## 8. QA Exit Criteria

- Всички тестове с висок бизнес риск са изпълнени поне за happy path, permission отказ, недопустим статус и описания corner case.
- Ролевият scope е проверен с поне два дилъра, две представителства и потребител с няколко роли.
- Масовите действия са проверени с повече от една страница резултати и с комбинирани колонни филтри.
- Документните flow-ове са проверени с валиден, частично разчетен, нечетим и дублиран документ.
- Финансовите flow-ове са проверени преди падеж, след падеж, с качено платежно и с потвърдено плащане.
- Локациите са проверени с различни физическа локация, NAV склад и крайна дестинация.
- Няма нерегистрирана загуба на връзка между дилърска заявка, заводска поръчка, автомобил, доставка, фактура и документно досие.