# China Motor CRM — регистър за валидация на срещата от 27.08.2026

- **Статус:** работен документ преди финален mock freeze
- **Източници:** [ClickUp среща](https://app.clickup.com/9004021877/docs/8cawy3n-38915), текущи CRM мокъпи и потвърдени решения след срещата

**Важно:** „Покрито“ означава видимо в мокъпа или документацията, а не реализирано и тествано в production.

## Цел

Първо валидираме всяко твърдение. След това актуализираме окончателно мокъпите и process flow-овете. Едва след одобрение превръщаме потвърдените точки в самостоятелни ClickUp user stories, бъгове и технически задачи.

## Обобщение

| Показател | Брой |
|---|---:|
| Общо отделни точки | 101 |
| Директно от срещата | 83 |
| Вече потвърдени решения | 17 |
| Покрити в mock/docs | 51 |
| Частично покрити | 20 |
| Само UI симулация | 4 |
| Липсващи | 10 |
| Отворени дефекти | 4 |
| Само в локален draft | 4 |

## Метод

- **Среща:** директно извлечено от видеото. Timestamp-ът е ориентир за проверка, не дословен цитат.
- **След срещата:** изрично потвърдено от Product Owner след прегледа.
- **Предишно решение:** установен по-рано процес, който е релевантен към темата.
- **Код:** техническа находка от текущия source code; не е бизнес решение.
- Всяка точка запазва отделно текущото покритие, предложеното действие и решението след преглед.
- Решенията са „Да“, „Не“ и „За обсъждане с клиента“. Само „Да“ потвърждава задача; точките за клиента се пазят и експортират отделно, без да се броят за задачи.

## Блокери преди финално задание

- [TX-02](#TX-02) — заявка за митнически транзит от BG пристанище към безмитен склад липсва.
- [TX-03](#TX-03) — транзитът и обмитяването все още не са ясно разделени.
- [CON-07](#CON-07) — автоматично FIFO разпределение не е реализирано.
- [TR-07](#TR-07) — неразпознат превозвач не спира потвърждението.
- [BUG-03](#BUG-03) — AI може да предложи несвързани автомобили от грешен документ.
- [BUG-07](#BUG-07) — основният мокъп има 33 дублирани имена на функции.
- [TX-09](#TX-09) — бързата физическа приемка е само в локален Texim draft.

## Контекст и роли

<a id="CTX-01"></a>
### CTX-01 · Прототипът да работи с реалистичен текущ набор автомобили

- **Тип:** Бизнес правило
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 02:25–04:21

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

**Текущо състояние:** Мокъпът има богат тестов набор, но той остава синтетичен и на места не следва една и съща реална поръчка през целия lifecycle.

**Предложено следващо действие:** Преди финалната валидация да се подготви един проследим end-to-end сценарий с реални модели и консистентни документи.

**Връзки:** [Основен мокъп](../mock/crm-full-mock.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CTX-02"></a>
### CTX-02 · Липсващи бизнес данни да не се измислят

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 05:28–06:01

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

**Текущо състояние:** AI екраните показват увереност, но няма общо правило за блокиране и работна опашка при липсващи master data.

**Предложено следващо действие:** Да се дефинира общ exception state: липсващо поле, собственик за уточнение и източник на корекцията.

**Връзки:** [Основен мокъп](../mock/crm-full-mock.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CTX-03"></a>
### CTX-03 · Ролите от страна на China Motor са разделени

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 36:38–44:58; потвърдено след срещата

Мениджър търговска мрежа управлява входа от дилърите; Продуктовият мениджър (вътрешен ключ buyer) работи с продуктите, доставчиците и количествата; Бранд мениджърът е ръководителят, който одобрява или връща предложението.

**Текущо състояние:** Ролите, имената и отделните dashboard/approval състояния са налични в мокъпа и документацията.

**Предложено следващо действие:** Да се запази като базово решение; да се валидират само конкретните права по екрани.

**Връзки:** [Дилърски flow](../dealer-flows.html) · [Основен мокъп](../mock/crm-full-mock.html#dealer-demand) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CTX-04"></a>
### CTX-04 · Оперативен директор / Admin има обзор и override

- **Тип:** Отворен въпрос
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 43:00–44:28

Ръководната роля трябва да вижда данните на продуктовия екип и дилърската мрежа и при необходимост да може да се намеси, без да се превръща в задължителна стъпка на всеки flow.

**Текущо състояние:** Admin вижда много от модулите, но матрицата на конкретните override действия не е формализирана.

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

**Връзки:** [Основен мокъп](../mock/crm-full-mock.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CTX-05"></a>
### CTX-05 · Dashboard работните опашки показват само следващите действия на ролята

- **Тип:** UX
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 15:15–17:17

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

**Текущо състояние:** Текущият мокъп има role-aware dashboard и работни опашки, но съдържанието трябва да се регресира спрямо всяка роля.

**Предложено следващо действие:** При финалната QA матрица да се провери всяка роля с поне едно чакащо и едно нечакано действие.

**Връзки:** [Dashboard](../mock/crm-full-mock.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CTX-06"></a>
### CTX-06 · Статусът на поръчката да е компактен и информативен

- **Тип:** UX
- **Приоритет:** Нисък
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 15:31–16:12

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

**Текущо състояние:** В текущия мокъп има компактни статуси, но различните детайли използват различни визуални схеми.

**Предложено следващо действие:** Да се избере един компактен Untitled UI pattern за status summary в детайлните екрани.

**Връзки:** [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CTX-07"></a>
### CTX-07 · Дилърът е основното поле, вносителят е отделен контекст

- **Тип:** Промяна
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 19:36–20:31

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

**Текущо състояние:** Данните за дилър, представителство, предназначение и вносител са разделени в текущите заявки.

**Предложено следващо действие:** Да се запази; да се провери същото разделяне във всички export-и и автомобилни колони.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Дилърско търсене

<a id="DLR-01"></a>
### DLR-01 · Търговецът започва от контакт и клиентска оферта

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 09:32–10:08; потвърдено след срещата

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

**Текущо състояние:** Flow-ът е наличен в дилърския мокъп и в двата process документа.

**Предложено следващо действие:** Без нова задача; да се регресира, че директна клиентска поръчка без оферта е невъзможна.

**Връзки:** [Оферти](../mock/dealer-process-mock.html#offers) · [Дилърски flow](../dealer-flows.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-02"></a>
### DLR-02 · Капарото предхожда изпращането към вносителя

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 10:09–10:18; потвърдено след срещата

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

**Текущо състояние:** Дилърският flow наследява офертата и включва капаро в EUR.

**Предложено следващо действие:** Да се потвърди дали има допустими изключения и кой може да ги разреши.

**Връзки:** [Поръчки](../mock/dealer-process-mock.html#orders) · [Дилърски flow](../dealer-flows.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-03"></a>
### DLR-03 · Заявката наследява данните без повторно въвеждане

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 10:44–11:00

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

**Текущо състояние:** Описано и демонстрирано в дилърския flow; връзките между обектите са UI симулация.

**Предложено следващо действие:** Да се превърне в общо правило за traceability и да се тества срещу редакция на изходната оферта.

**Връзки:** [Дилърски flow](../dealer-flows.html) · [Оферти](../mock/dealer-process-mock.html#offers) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-04"></a>
### DLR-04 · Последователна approval верига по организации

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 12:33–14:34, 43:38–46:43; окончателно уточнено след срещата

Клиентска заявка: Sales Manager → Dealer Manager → Мениджър търговска мрежа → Продуктов мениджър предлага количество → Бранд мениджър одобрява или връща. Дилърът получава потвърждение едва след последната стъпка.

**Текущо състояние:** Веригата е видима в основния и дилърския мокъп и в актуалните flow-ове.

**Предложено следващо действие:** Да се запази като source of truth; да се валидират отказ, връщане и повторно подаване на всяка стъпка.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Дилърски портал](../mock/dealer-process-mock.html#orders) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-05"></a>
### DLR-05 · Sales Manager може да поръчва за дилърски склад

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** Решение след срещата

Поръчката за свободна наличност в дилърски склад се създава от Sales Manager без клиент, оферта и капаро; започва директно при Dealer Manager и после следва China Motor approval веригата.

**Текущо състояние:** Добавена е в дилърския мокъп, дилърските flow-ове и основната документация.

**Предложено следващо действие:** Да се провери, че не може да се представи като клиентска резервация и че Sales Manager не одобрява собствената си заявка.

**Връзки:** [Към вносител](../mock/dealer-process-mock.html#orders) · [Дилърски flow](../dealer-flows.html)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-06"></a>
### DLR-06 · Продуктовият мениджър предлага пълно или частично количество

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 44:51–46:43; уточнено след срещата

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

**Текущо състояние:** Полетата заявени, предложени и одобрени бройки и Brand Manager action са налични.

**Предложено следващо действие:** Да се тества частично потвърждение и връщане с причина.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-07"></a>
### DLR-07 · Дилърът вижда обещанието към него, не вътрешната комуникация с доставчика

- **Тип:** UX
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 64:40–74:15

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

**Текущо състояние:** Дилърският портал показва lifecycle, но разграничението между потвърдено от China Motor и произведено трябва да се провери на всички изгледи.

**Предложено следващо действие:** Да се утвърди дилърският status model и точните видими количества.

**Връзки:** [Дилърски поръчки](../mock/dealer-process-mock.html#orders) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-08"></a>
### DLR-08 · Одобрените заявки се добавят масово към поръчка към доставчик

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 17:36–18:30, 30:40–35:18

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

**Текущо състояние:** Factory builder показва неизпълненото търсене и позволява добавяне на много заявки и частични количества.

**Предложено следващо действие:** Да се тества комбиниране на поне три дилъра и два доставчика в една селекция.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-09"></a>
### DLR-09 · Заявки без движение се ескалират

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 75:14–75:40, 79:10–79:42

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

**Текущо състояние:** Документацията използва 90/120 дни и примерните заявки имат age indicators.

**Предложено следващо действие:** Да се потвърди дали периодите са фиксирани или конфигурируеми по марка/доставчик.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="DLR-10"></a>
### DLR-10 · Отказът от одобрено търсене е изключение с причина

- **Тип:** Промяна
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 78:20–78:43

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

**Текущо състояние:** Има общи откази в approval flow, но няма отделен post-approval cancellation flow за остатъка.

**Предложено следващо действие:** Да се реши дали е нужна отделна операция и как влияе на клиентските поръчки и капарото.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Заводски поръчки

<a id="FAC-01"></a>
### FAC-01 · Доставчикът идва по подразбиране от модела, но може да се смени

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 22:15–25:01

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

**Текущо състояние:** Factory builder зарежда доставчик по модел и позволява редакция.

**Предложено следващо действие:** Да се добави контрол кои доставчици са допустими за конкретния модел и от коя дата.

**Връзки:** [Заводски поръчки](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-02"></a>
### FAC-02 · Връзката модел–доставчик трябва да пази бизнес валидност

- **Тип:** Промяна
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 23:03–24:49

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

**Текущо състояние:** Има текущ supplier mapping, но няма effective dates и история на промяната.

**Предложено следващо действие:** Да се потвърди дали времевата валидност влиза в първата production версия.

**Връзки:** [Каталог / заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-03"></a>
### FAC-03 · Една заводска поръчка е към точно един доставчик

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 25:15–25:38

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

**Текущо състояние:** Правилото е описано и factory builder създава отделен запис за всеки доставчик.

**Предложено следващо действие:** Да се покрие с backend constraint и тест за смесена селекция.

**Връзки:** [Заводски поръчки](../mock/crm-full-mock.html#factory) · [Process flow](../process-flows.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-04"></a>
### FAC-04 · Смесената селекция се разделя автоматично по доставчик

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 25:42–26:18

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

**Текущо състояние:** Текущият builder групира позициите по supplier и генерира отделни уникални FO записи.

**Предложено следващо действие:** Да се тества с поне четири модела и повече от един дилърски източник.

**Връзки:** [Нова заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-05"></a>
### FAC-05 · Една поръчка комбинира търсене от много дилъри

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 33:02–35:18

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

**Текущо състояние:** Builder-ът показва източника и allocations по дилърска заявка.

**Предложено следващо действие:** Да се провери export-ът към доставчика да не изнася вътрешна дилърска информация, ако не е нужна.

**Връзки:** [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-06"></a>
### FAC-06 · Поръчката може да се натрупва преди изпращане

- **Тип:** UX
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 34:38–35:18

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

**Текущо състояние:** В един builder session могат да се добавят много заявки, но няма ясно запазена дългоживееща чернова за допълване в различни дни.

**Предложено следващо действие:** Да се потвърди нуждата от persistent draft и кой може да я редактира.

**Връзки:** [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-07"></a>
### FAC-07 · В поръчката влизат само одобрените количества

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 31:22–35:18, 77:37–80:14; потвърдено след срещата

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

**Текущо състояние:** Количеството в builder-а е ограничено до остатъка, а заявката пази активни allocations.

**Предложено следващо действие:** Да се добавят транзакционни backend проверки срещу двойно включване при паралелна работа.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-08"></a>
### FAC-08 · Таргетите са едновременно по доставчик и по модел

- **Тип:** Промяна
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 26:18–27:05

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

**Текущо състояние:** Модулът за цели има заводски цели по доставчик и модел; точната сума и период трябва да се валидират.

**Предложено следващо действие:** Да се потвърдят период, валута и поведение при различни договорни версии.

**Връзки:** [Цели](../mock/crm-full-mock.html#targets) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-09"></a>
### FAC-09 · Остатъкът по таргета се вижда при решение и поръчване

- **Тип:** UX
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 29:06–31:10

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

**Текущо състояние:** Целите съществуват, но контекстният target summary не е еднакво видим във всички decision screens.

**Предложено следващо действие:** Да се добави общ target context component към заявката и factory builder-а.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Цели](../mock/crm-full-mock.html#targets) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FAC-10"></a>
### FAC-10 · Надвишаването на таргет се предупреждава преди поръчка

- **Тип:** Бизнес правило
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 29:30–29:50

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

**Текущо състояние:** Има target визуализации, но няма универсален warning/override audit при създаване на поръчката.

**Предложено следващо действие:** Да се реши дали предупреждението е soft warning или изисква одобрение от Бранд мениджър.

**Връзки:** [Цели](../mock/crm-full-mock.html#targets) · [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Проформи и разпределение

<a id="CON-01"></a>
### CON-01 · Проформата е доказателството за потвърждение от доставчика

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 53:19–53:49, 59:42–61:41

Изпратената заводска поръчка не е потвърдена сама по себе си. Потвърдени стават количествата, които доставчикът включи в получена проформа.

**Текущо състояние:** Отделният proforma flow е наличен и променя confirmed quantities.

**Предложено следващо действие:** Да се покрие с автоматична връзка документ → позиции → количества → очаквана цена.

**Връзки:** [Проформи](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-02"></a>
### CON-02 · Само включените позиции стават потвърдени

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 60:26–61:05

Ако поръчката е за 100 автомобила, а проформата е за 50, само тези 50 стават потвърдени. Останалите не се маркират като отказани.

**Текущо състояние:** Проформа формата ограничава бройките по оставащото количество и пази чакащ остатък.

**Предложено следващо действие:** Да се провери поведение при частично включена позиция с еднакъв модел и различни цветове.

**Връзки:** [Проформи](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-03"></a>
### CON-03 · Една заводска поръчка приема много проформи

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 60:40–64:26

Доставчикът може да потвърждава поръчката на части по месеци, производствен капацитет или финансов лимит; всяка нова проформа допълва потвърденото количество.

**Текущо състояние:** Списъкът и upload действието поддържат много проформи.

**Предложено следващо действие:** Да се валидират повторена позиция, дублиран документ и анулирана проформа.

**Връзки:** [Проформи](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-04"></a>
### CON-04 · Поръчани, потвърдени и чакащи бройки са видими отделно

- **Тип:** UX
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 61:11–61:41

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

**Текущо състояние:** Проформа card-ът показва потвърдени / общо и чакащи проформа.

**Предложено следващо действие:** Да се провери същата разбивка в списъка, export-а и dealer-facing view.

**Връзки:** [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-05"></a>
### CON-05 · AI прочита проформата, потребителят валидира

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** UI симулация
- **Начално решение:** За обсъждане
- **Основание:** 47:32–49:08, 61:58–62:12

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

**Текущо състояние:** Flow-ът е интерактивно симулиран; реалното document extraction и confidence handling не са production функционалност.

**Предложено следващо действие:** Да се специфицират schema, confidence threshold, audit на оригинална/редактирана стойност и unsupported documents.

**Връзки:** [Проформа upload](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-06"></a>
### CON-06 · Всяка проформа създава отделно финансово задължение

- **Тип:** Промяна
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 53:34–55:31

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

**Текущо състояние:** Проформата има статус за плащане, но пълният payable lifecycle и email ingestion са частични.

**Предложено следващо действие:** Да се свърже с общия финансов регистър по контрагент и документ.

**Връзки:** [Фактури](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-07"></a>
### CON-07 · Автоматичното разпределение по подразбиране е FIFO

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 64:46–65:15, 71:58–72:07

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

**Текущо състояние:** Мокъпът има данни за allocations и ръчна смяна на дилър, но няма реална FIFO операция върху потвърдените бройки.

**Предложено следващо действие:** Да се дефинира точният sorting key и поведение при еднаква дата, приоритетен клиент и частични цветови комбинации.

**Връзки:** [Разпределение](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-08"></a>
### CON-08 · Алтернативно разпределение спрямо таргет

- **Тип:** Промяна
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 71:42–72:10

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

**Текущо състояние:** Няма отделно действие или preview на target-based allocation.

**Предложено следващо действие:** Да се определи формулата и дали се използва дилърски, представителствен или месечен таргет.

**Връзки:** [Разпределение](../mock/crm-full-mock.html#factory) · [Цели](../mock/crm-full-mock.html#targets) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-09"></a>
### CON-09 · Автоматично предложение с масова ръчна корекция

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Частично
- **Начално решение:** Потвърдено
- **Основание:** 65:16–67:15, 70:44–74:56; потвърдено след срещата

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

**Текущо състояние:** Масовото действие Промени дилър работи за произведени/готови автомобили; автоматичната начална стъпка липсва.

**Предложено следващо действие:** Да се добави allocation preview преди запис и да се гарантира транзакционна промяна на всички остатъци.

**Връзки:** [Разпределение](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-10"></a>
### CON-10 · Дилърската заявка пази постоянен остатък

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 75:01–80:14; потвърдено след срещата

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

**Текущо състояние:** Формулата и остатъкът са налични в mock data, builder-а и документацията.

**Предложено следващо действие:** Да се реализира на ниво домейн и да се покрият конкурентни allocations и rollback.

**Връзки:** [Дилърско търсене](../mock/crm-full-mock.html#dealer-demand) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-11"></a>
### CON-11 · Преразпределената бройка се връща в остатъка

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 76:14–80:14, 87:56–88:27; потвърдено след срещата

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

**Текущо състояние:** Mock data и описанието пазят reallocated allocation и преизчислен остатък.

**Предложено следващо действие:** Да се провери с реален scenario: 50 заявени, 25 разпределени, 10 преместени, остатък 35.

**Връзки:** [Дилърски заявки](../mock/crm-full-mock.html#dealer-demand) · [Заводска поръчка](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-12"></a>
### CON-12 · След плащане разпределението се заключва

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** След срещата
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** 86:46–87:09; потвърдено след срещата

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

**Текущо състояние:** Масовото действие изключва платените автомобили и показва причината.

**Предложено следващо действие:** Да се дефинира отделният exception process след плащане, ако изобщо е нужен.

**Връзки:** [Разпределение](../mock/crm-full-mock.html#factory) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-13"></a>
### CON-13 · Преразпределението трябва да е възможно до късен физически етап

- **Тип:** Промяна
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 80:52–88:27

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

**Текущо състояние:** Текущото действие е ограничено главно до произведени/чакащи плащане/готови автомобили и не покрива всички логистични стадии.

**Предложено следващо действие:** Да се определи точният lock event и ефектът върху транспортни документи, уведомления и дилърски обещания.

**Връзки:** [Автомобили](../mock/crm-full-mock.html#production) · [Безмитен склад](../mock/crm-full-mock.html#central-stock) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="CON-14"></a>
### CON-14 · Всяка промяна на разпределението има история и дилърски ефект

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 76:14–78:18, 87:56–88:27

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

**Текущо състояние:** История и причина са видими в мокъпа; автоматичното дилърско известие е частично.

**Предложено следващо действие:** Да се потвърдят шаблонът и моментът на известяване.

**Връзки:** [Разпределение](../mock/crm-full-mock.html#factory) · [Известия](../mock/crm-full-mock.html#notifications) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Производство и фактури

<a id="PROD-01"></a>
### PROD-01 · Заводският производствен списък обновява конкретните автомобили

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 90:59–92:24, 103:13–103:40

Полученият Excel/списък съдържа поне модел, цветове и когато са налични VIN и номер на двигател; той трябва да се съпостави към съществуващите поръчани бройки.

**Текущо състояние:** В мокъпа има Excel от завода и директно попълване на формата.

**Предложено следващо действие:** Да се фиксира contract-ът на import schema и exception handling за несъпоставени редове.

**Връзки:** [Производство](../mock/crm-full-mock.html#production) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-02"></a>
### PROD-02 · AI попълва същата производствена форма

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** UI симулация
- **Начално решение:** За обсъждане
- **Основание:** 90:59–92:24

Разчетените редове не се показват в отделен декоративен preview. Те попълват редовете във формата, а Продуктовият мениджър проверява и редактира само изключенията.

**Текущо състояние:** UX е симулиран; реалното AI/структурно четене не е имплементирано в HTML прототипа.

**Предложено следващо действие:** Да се опише field-level confidence, original value и validation result.

**Връзки:** [Производство](../mock/crm-full-mock.html#production) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-03"></a>
### PROD-03 · Произведени стават само валидираните бройки

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 89:45–92:24

Операцията Маркирай като произведени трябва да работи върху потвърдените и валидирани редове, а не върху целия първоначално заявен брой.

**Текущо състояние:** Има селекция и потвърждение на произведени автомобили; необходим е regression test срещу requested/confirmed quantity mismatch.

**Предложено следващо действие:** Да се добави автоматичен тест за частично потвърдена поръчка.

**Връзки:** [Производство](../mock/crm-full-mock.html#production) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-04"></a>
### PROD-04 · VIN и номер на двигател са опционални при Произведен

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 91:41–92:17, 99:32–99:56

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

**Текущо състояние:** Блокиращото съобщение е премахнато и липсата се показва като информационно комплектоване.

**Предложено следващо действие:** Да се пази видима работна опашка за допълване, без да се блокира ранният транспорт.

**Връзки:** [Производство](../mock/crm-full-mock.html#production) · [Транспорт](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-05"></a>
### PROD-05 · Крайният gate за VIN и индивидуални документи не е финализиран

- **Тип:** Отворен въпрос
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 92:08–92:17, 99:14–100:08

Идентификаторите и индивидуалните фактури трябва да са налични най-късно при пристигането/митническата обработка в България, но точният блокиращ момент не беше окончателно определен.

**Текущо състояние:** Документацията изрично отбелязва operational gate за потвърждение.

**Предложено следващо действие:** Клиентът да потвърди точния етап: Arrival Notice, транзит, приемане в Безмитен склад или митническо освобождаване.

**Връзки:** [Process flow](../process-flows.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-06"></a>
### PROD-06 · Крайните фактури са индивидуални за всеки автомобил

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 90:09–90:58, 98:10–98:28

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

**Текущо състояние:** Има отделно действие Индивидуални фактури и batch upload UI.

**Предложено следващо действие:** Да се предвиди обработка на частичен пакет, дублиран файл и повторно качване.

**Връзки:** [Индивидуални фактури](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-07"></a>
### PROD-07 · Индивидуалната фактура се мачва по VIN

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 90:20–91:08, 103:40–104:00

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

**Текущо състояние:** Мокъпът показва VIN matching и status на всеки документ.

**Предложено следващо действие:** Да се определи резервен ключ и да се забрани автоматично потвърждение при двусмислено съвпадение.

**Връзки:** [Индивидуални фактури](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-08"></a>
### PROD-08 · Проформа и крайна фактура са отделни типове документи

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 98:54–103:02

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

**Текущо състояние:** Екраните и документните типове са разделени.

**Предложено следващо действие:** Да се запази като домейн ограничение и в API/data model.

**Връзки:** [Фактури](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-09"></a>
### PROD-09 · Крайната цена се валидира спрямо проформата

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 102:26–104:39

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

**Текущо състояние:** UI показва очаквана, фактурна цена, разлика и validation status.

**Предложено следващо действие:** Да се реши допустим tolerance и кой може да приеме реална ценова промяна.

**Връзки:** [Индивидуални фактури](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-10"></a>
### PROD-10 · Продуктовият мениджър валидира документите и цените

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 102:07–102:44

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

**Текущо състояние:** Ролевите действия са при Продуктов мениджър; точните права на Finance и Back Office остават за преглед.

**Предложено следващо действие:** Да се направи permission matrix за upload, edit, approve и read-only достъп.

**Връзки:** [Фактури](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-11"></a>
### PROD-11 · Произведените коли създават Navision карта и поръчка за доставка

- **Тип:** Промяна
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 100:12–101:28

На база индивидуалните документи трябва да се подготвят автомобилна карта и purchase order в Navision с фактура, дата, стойност и шаси.

**Текущо състояние:** Мокъпът има отделен процес за счетоводно завеждане в Централен склад, но не показва ясно ранното създаване на Navision карта при производство.

**Предложено следващо действие:** Да се сверят точният момент, системата source of truth и интеграционните полета с Back Office/Finance.

**Връзки:** [Централен склад](../mock/crm-full-mock.html#central-stock) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="PROD-12"></a>
### PROD-12 · Логистика вижда автомобилното досие и документите

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 95:54–96:39

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

**Текущо състояние:** Документните досиета и свързаните процеси са видими от логистичните екрани.

**Предложено следващо действие:** Да се провери дали финансовите стойности са ограничени според окончателната permission matrix.

**Връзки:** [Транспортно досие](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Международен транспорт

<a id="TR-01"></a>
### TR-01 · Транспортна поръчка се създава от автомобилите или от транспортния модул

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 93:43–95:14

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

**Текущо състояние:** И двата входа са налични в мокъпа.

**Предложено следващо действие:** Да се гарантира, че използват една и съща eligibility логика и не създават дублирано включване.

**Връзки:** [Автомобили](../mock/crm-full-mock.html#production) · [Транспорт](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-02"></a>
### TR-02 · Поръчката започва със заявка за оферта към превозвач

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 95:14–97:23

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

**Текущо състояние:** Create transport order и request for quote са отделени от deliveries.

**Предложено следващо действие:** Да се потвърдят задължителните полета на RFQ и английският email шаблон.

**Връзки:** [Транспортна поръчка](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-03"></a>
### TR-03 · Една транспортна поръчка може да има оферти от различни фирми

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Предишно решение
- **Текущо покритие:** Частично
- **Начално решение:** Потвърдено
- **Основание:** Предходно потвърдено изискване; срещата показва RFQ → оферта

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

**Текущо състояние:** Моделът поддържа requests, но UX за сравняване на много конкурентни оферти е частичен.

**Предложено следващо действие:** Да се добави сравнима таблица и явно действие Приеми оферта.

**Връзки:** [Транспорт](../mock/crm-full-mock.html#international-request)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-04"></a>
### TR-04 · Една транспортна поръчка има много доставки

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Предишно решение
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** Предходно потвърдено изискване; валидирано в текущия mock

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

**Текущо състояние:** Transport order detail съдържа списък Доставки и многократно Добави доставка.

**Предложено следващо действие:** Да се покрият частично изпълнена поръчка и различен carrier на втората доставка.

**Връзки:** [Транспорт](../mock/crm-full-mock.html#international-request)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-05"></a>
### TR-05 · Добави доставка започва с BL и фактурата от превозвача

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** UI симулация
- **Начално решение:** За обсъждане
- **Основание:** 105:55–107:57

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

**Текущо състояние:** Document-first modal и статус на четене са интерактивно симулирани.

**Предложено следващо действие:** Да се специфицира реалното OCR/AI извличане и поведението, когато документите си противоречат.

**Връзки:** [Добави доставка](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-06"></a>
### TR-06 · AI съвпадението на автомобили изисква проверимо доказателство

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 106:37–107:27

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

**Текущо състояние:** Мокъпът предлага първите свободни автомобили по модел и показва confirmation form, но confidence/конфликтите са UI симулация.

**Предложено следващо действие:** Да се забрани тихото създаване на доставка от несвързан документ и да се пази причината за предложението.

**Връзки:** [Добави доставка](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-07"></a>
### TR-07 · Неразпознат превозвач трябва да спира потвърждението

- **Тип:** Бъг
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 107:32–108:11

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

**Текущо състояние:** Текущото demo extraction избира наличен carrier; няма пълен unresolved-company state.

**Предложено следващо действие:** Да се добави entity resolution modal с confidence, exact source text и забрана за confirm без решение.

**Връзки:** [Добави доставка](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-08"></a>
### TR-08 · Маршрутът, товаренето и ETA са данни на конкретната доставка

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 95:14–97:23, 105:55–108:16

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

**Текущо състояние:** Полетата са в delivery form и в shipment list.

**Предложено следващо действие:** Да се добави история при промяна на ETA.

**Връзки:** [Транспорт](../mock/crm-full-mock.html#international-request) · [Проследяване](../mock/crm-full-mock.html#international-tracking) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-09"></a>
### TR-09 · Транспортният разход се разпределя към автомобилите

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Предишно решение
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** Предходно потвърдено изискване

Стойността от фактурата на превозвача се разпределя върху точните автомобили в доставката и влиза в себестойността им; методът трябва да е видим и възпроизводим.

**Текущо състояние:** Мокъпът показва стойност на автомобил и равномерно разпределение по брой.

**Предложено следващо действие:** Да се потвърди дали формулата винаги е равномерна по брой или зависи от модел/капацитет.

**Връзки:** [Транспорт](../mock/crm-full-mock.html#international-request)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-10"></a>
### TR-10 · Фактурата на превозвача има прост статус Платена/Неплатена

- **Тип:** Бизнес правило
- **Приоритет:** Среден
- **Източник:** Предишно решение
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** Предходно потвърдено изискване

Оперативният екран не показва вътрешен NAV статус; потребителят вижда само дали конкретната фактура е платена или неплатена и може да отвори платежния процес.

**Текущо състояние:** Статусите са опростени в транспортния register и dossier.

**Предложено следващо действие:** Да се запази; интеграционният източник може да остане вътрешен.

**Връзки:** [Транспорт](../mock/crm-full-mock.html#international-request)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-11"></a>
### TR-11 · Предварително и пристигнало известие към Тексим са отделни събития

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Предишно решение
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** Предходно потвърдено изискване; срещата уточнява получателите 108:20–111:49

Преди ETA системата изпраща еднократно предварително известие. Логистиката отделно маркира реалното пристигане в България, което изпраща ново известие; и двете имат history и повторно изпращане.

**Текущо състояние:** Международното проследяване пази двата вида известия.

**Предложено следващо действие:** Да се свържат получателите с организационните звена на Тексим.

**Връзки:** [Проследяване](../mock/crm-full-mock.html#international-tracking) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TR-12"></a>
### TR-12 · Документното досие трябва да използва реалните типове и етапи

- **Тип:** Промяна
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 114:19–119:57

В досието трябва да са отделени проформи, индивидуални фактури, BL, packing list/списък автомобили, фактура от превозвача, платежни, CoC/УИО и последващи митнически/хомологационни документи. Неясни или несъществуващи типове не трябва да се показват като задължителни.

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

**Предложено следващо действие:** Да се валидира окончателният checklist по етап с реалните документи от логистиката.

**Връзки:** [Документи по пратката](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Пристанище и Тексим

<a id="TX-01"></a>
### TX-01 · Известието към Тексим е адресирано първо към митническото звено

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 109:39–111:49

При предстояща пратка China Motor изпраща пълната документация към митническото звено на Тексим; транспортното и складовото звено получават информация за количества и подготовка, пряко или чрез вътрешната им комуникация.

**Текущо състояние:** Има общо известие към Тексим, но няма отделни получатели/роля по звено и различен набор приложения.

**Предложено следващо действие:** На среща с Тексим да се потвърдят адресати, шаблон и задължителни приложения.

**Връзки:** [Проследяване](../mock/crm-full-mock.html#international-tracking) · [Тексим](../mock/texim-operational-portal.html#port) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-02"></a>
### TX-02 · BG пристанище → Безмитен склад започва със заявка за транзит

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 111:49–114:13

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

**Текущо състояние:** Текущият flow преминава директно към вътрешен CMR/курс и не показва отделна транзитна заявка и документ.

**Предложено следващо действие:** Да се добави отделен flow, екран и статуси за транзит преди вътрешния транспорт.

**Връзки:** [Тексим · пристанище](../mock/texim-operational-portal.html#port) · [Process flow](../process-flows.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-03"></a>
### TX-03 · Транзитът и обмитяването са различни процеси

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 112:53–123:24

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

**Текущо състояние:** Customs модулът е отделен, но документацията не описва ясно транзитния слой между международната доставка и CMR курса.

**Предложено следващо действие:** Да се разделят обектите, документите и статусите в domain model и UI.

**Връзки:** [Обмитяване](../mock/crm-full-mock.html#customs) · [Тексим](../mock/texim-operational-portal.html#port) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-04"></a>
### TX-04 · Точният документен пакет за транзит трябва да се потвърди

- **Тип:** Отворен въпрос
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 114:19–119:57

Срещата посочва BL, фактури и packing list/списък автомобили като съществени; карго застраховката е опционална, а експортната декларация беше оспорена. Финалният checklist не е потвърден.

**Текущо състояние:** Досието показва примерен по-широк набор, който не трябва да се приема като окончателен.

**Предложено следващо действие:** Да се изискат реалните transit templates и писмен списък от логистиката/Тексим.

**Връзки:** [Документи](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-05"></a>
### TX-05 · Тексим избира конкретни автомобили от наличните на пристанището

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 124:26–125:10

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

**Текущо състояние:** Табът На пристанище има таблица, филтри, bulk selection и CMR action.

**Предложено следващо действие:** Да се регресира с 100 автомобила и няколко паралелни курса.

**Връзки:** [На пристанище](../mock/texim-operational-portal.html#port) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-06"></a>
### TX-06 · CMR прочита VIN и попълва вътрешния курс

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** UI симулация
- **Начално решение:** За обсъждане
- **Основание:** 124:28–125:45

Каченият CMR трябва да извлече номера, маршрута, датата, превозвача/шофьора и VIN-овете и да предложи точните автомобили от пристанищния пул за потвърждение.

**Текущо състояние:** CMR AI flow е наличен в основния и Тексим мокъпа, но разчитането е симулирано.

**Предложено следващо действие:** Да се дефинира поведение при нечетлив CMR, ръкописни VIN и дублиран курс.

**Връзки:** [CMR](../mock/texim-operational-portal.html#port) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-07"></a>
### TX-07 · Шофьорът има минимален mobile capture за CMR при вземане

- **Тип:** UX
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 126:44–131:09

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

**Текущо състояние:** Текущото качване е в портала на Тексим и няма отделен driver link flow.

**Предложено следващо действие:** Да се потвърди дали реално шофьорът или диспечерът ще качва документа и как се удостоверява курсът.

**Връзки:** [Тексим](../mock/texim-operational-portal.html#port) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-08"></a>
### TX-08 · CMR се пази при вземане и при получаване

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 131:13–133:23

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

**Текущо състояние:** Има CMR и отделен складов протокол, но няма ясно повторно качване на подписания CMR след получаването.

**Предложено следващо действие:** Да се добавят CMR departure и CMR received версии към курса.

**Връзки:** [За приемане](../mock/texim-operational-portal.html#warehouse-receipt) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-09"></a>
### TX-09 · Бързата физическа приемка затваря курса

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Само локално
- **Начално решение:** За обсъждане
- **Основание:** 127:35–129:51

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

**Текущо състояние:** Flow-ът е добавен в локалната непубликувана версия на Тексим мокъпа; текущият Git HEAD още смесва приемката с детайлен checklist.

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

**Връзки:** [За приемане](../mock/texim-operational-portal.html#warehouse-receipt) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-10"></a>
### TX-10 · PDI Тексим е отделен подробен оглед след приемката

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Само локално
- **Начално решение:** За обсъждане
- **Основание:** 128:27–135:12

След като физическата приемка приключи транспорта, складовият/PDI екип извършва отделен checklist, снимки, опис на щети и липси и записва инспектора.

**Текущо състояние:** Документацията е обновена, а отделният PDI екран е само в локалната непубликувана промяна на Тексим мокъпа.

**Предложено следващо действие:** Да се валидира името PDI Тексим с клиента и да се публикува след интерактивен тест.

**Връзки:** [Безмитен склад](../mock/texim-operational-portal.html#bonded) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-11"></a>
### TX-11 · Приемащият курса и инспекторът могат да са различни хора

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Само локално
- **Начално решение:** За обсъждане
- **Основание:** 133:33–135:12

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

**Текущо състояние:** Локалният mock пази receiver и inspector в отделни записи.

**Предложено следващо действие:** Да се потвърди дали са нужни отделни роли или само отделни audit полета.

**Връзки:** [Тексим](../mock/texim-operational-portal.html#bonded) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-12"></a>
### TX-12 · CMR курсът и приемката са на ниво автомобил и поддържат X/Y

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 124:26–135:12

Един CMR може да съдържа много коли и да бъде приет на части. Непристигналите остават в За приемане, а курсът показва частично приети X/Y до последната бройка.

**Текущо състояние:** Partial receipt моделът и селекцията на конкретни автомобили са налични.

**Предложено следващо действие:** Да се тества едновременно приемане от два CMR курса и повторно отваряне на остатъка.

**Връзки:** [За приемане](../mock/texim-operational-portal.html#warehouse-receipt) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="TX-13"></a>
### TX-13 · CMR доказва на кой handoff е възникнала щетата

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 131:13–133:23

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

**Текущо състояние:** Централният регистър щети пази CMR и място, но audit връзката към двете версии на документа е частична.

**Предложено следващо действие:** Да се моделират handoff events и доказателства, вместо свободен текст Място.

**Връзки:** [Щети](../mock/crm-full-mock.html#damages) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Безмитен склад и митници

<a id="WH-01"></a>
### WH-01 · Безмитният склад има работна опашка за готовност

- **Тип:** Flow
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 140:24–141:31

За всяка кола трябва ясно да се виждат документи, CoC/УИО и хомологация, еко такса, обмитяване, щети и готовност за следващ транспорт.

**Текущо състояние:** Автомобили → Безмитен склад и Back Office опашките показват отделните gates.

**Предложено следващо действие:** Да се валидира окончателният checklist и собственикът на всяко действие.

**Връзки:** [Безмитен склад](../mock/crm-full-mock.html#central-stock) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-02"></a>
### WH-02 · CoC и индивидуалното одобряване са алтернативни пътища

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 118:58–119:53, 140:31–140:44

При наличен CoC/сертификат за съответствие не се изисква индивидуална хомологация. При липса се стартира процес по Удостоверение за индивидуално одобряване (УИО), а документите се пазят отделно.

**Текущо състояние:** Мокъпът и документацията използват CoC и УИО и разделят хомологационните документи.

**Предложено следващо действие:** Да се потвърдят точните наименования и document types с продуктовия/хомологационния екип.

**Връзки:** [Хомологация](../mock/crm-full-mock.html#homologation) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-03"></a>
### WH-03 · Митническото освобождаване е твърд gate за изпращане към дилър

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 141:13–142:08, 145:25–146:10

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

**Текущо състояние:** Readiness и customs screens отделят release от declaration и блокират необмитените автомобили.

**Предложено следващо действие:** Да се свърже gate-ът с реалния customs release event/API.

**Връзки:** [Обмитяване](../mock/crm-full-mock.html#customs) · [Безмитен склад](../mock/crm-full-mock.html#central-stock) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-04"></a>
### WH-04 · Плащането е видимо, но не е автоматичен логистичен блокер

- **Тип:** Бизнес правило
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 142:08–145:22

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

**Текущо състояние:** Мокъпът третира плащането като warning и позволява ролево изключение.

**Предложено следващо действие:** Да се тества, че всяко изключение пази потребител, дата и причина.

**Връзки:** [Безмитен склад](../mock/crm-full-mock.html#central-stock) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-05"></a>
### WH-05 · Продуктов мениджър и Admin могат да разрешат неплатен транспорт

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Предишно решение
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** Потвърдено
- **Основание:** Предходно потвърдено изискване

Ролевата възможност се запазва, без в този етап да се проектира отделен сложен approval flow.

**Текущо състояние:** Ролевият override е описан и демонстриран.

**Предложено следващо действие:** Да се запази минимален audit и да не се разширява без ново решение.

**Връзки:** [Безмитен склад](../mock/crm-full-mock.html#central-stock)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-06"></a>
### WH-06 · Customs екранът от демонстрацията не следваше реалния процес

- **Тип:** Бъг
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 120:59–123:24

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

**Текущо състояние:** След срещата customs UI е преработен в кошница → калкулация → плащане → освобождаване → декларация, но още не е повторно валидиран с клиента.

**Предложено следващо действие:** Да се демонстрира новият екран с реален customs case и документите на логистиката.

**Връзки:** [Обмитяване](../mock/crm-full-mock.html#customs) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-07"></a>
### WH-07 · Статус Обмитен · чака декларация е задължителен

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 145:38–146:10, 148:17–148:29

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

**Текущо състояние:** Статусът и отделното качване на декларация са налични.

**Предложено следващо действие:** Да се добави aging/напомняне за липсваща декларация.

**Връзки:** [Обмитяване](../mock/crm-full-mock.html#customs) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-08"></a>
### WH-08 · Тексим/митническият агент може да подаде декларацията директно

- **Тип:** Flow
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 148:40–149:04

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

**Текущо състояние:** Основният CRM приема документа; Тексим порталът няма завършен customs document upload flow.

**Предложено следващо действие:** Да се потвърди договорният и ролевият модел за външен upload.

**Връзки:** [Обмитяване](../mock/crm-full-mock.html#customs) · [Тексим](../mock/texim-operational-portal.html#bonded) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-09"></a>
### WH-09 · Готовите автомобили създават вътрешен транспорт към дилър

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 141:13–145:03

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

**Текущо състояние:** Трите отделни стъпки са налични в CRM, Тексим и дилърския портал.

**Предложено следващо действие:** Да се тества частично издаване и частично дилърско приемане по една заявка.

**Връзки:** [Заявка към Тексим](../mock/crm-full-mock.html#dealer-transfer-request) · [Издаване](../mock/texim-operational-portal.html#dealer-issue) · [Приемане](../mock/crm-full-mock.html#dealer-receipt) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-10"></a>
### WH-10 · Тексим дава калкулация/оферта за установена щета

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 136:48–138:43

След подробния оглед Тексим вижда щетата и може да добави оценка или оферта за отстраняване, която China Motor разглежда.

**Текущо състояние:** Централният damage register има калкулация, оферта, claim и решение.

**Предложено следващо действие:** Да се свърже автоматично с PDI Тексим и да се определи SLA.

**Връзки:** [Щети](../mock/crm-full-mock.html#damages) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="WH-11"></a>
### WH-11 · Ролята, която одобрява решение по щета, не е потвърдена

- **Тип:** Отворен въпрос
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 137:35–138:43

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

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

**Предложено следващо действие:** Да се реши собственикът преди production permission matrix.

**Връзки:** [Щети](../mock/crm-full-mock.html#damages) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Финанси и документи

<a id="FIN-01"></a>
### FIN-01 · Задълженията се следят в един общ финансов модел по контрагент

- **Тип:** Архитектура
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 152:56–154:06

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

**Текущо състояние:** Има общи списъци и dashboard данни, но прототипът още съдържа отделни локални структури по модули.

**Предложено следващо действие:** Преди задачите да се направи data/domain review със съществуващия finance модул.

**Връзки:** [Фактури](../mock/crm-full-mock.html#factory-invoices) · [Транспорт](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FIN-02"></a>
### FIN-02 · Аванси, крайни плащания и транспортни плащания са отделни задължения

- **Тип:** Flow
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Частично
- **Начално решение:** За обсъждане
- **Основание:** 53:34–55:31, 117:38–118:16, 153:15–153:58

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

**Текущо състояние:** Документите и статусите са показани, но общата settlement логика е UI ниво.

**Предложено следващо действие:** Да се дефинират relation-ите document → obligation → payment allocation.

**Връзки:** [Фактури](../mock/crm-full-mock.html#factory-invoices) · [Транспорт](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FIN-03"></a>
### FIN-03 · Платежното от счетоводството може да влиза чрез email reply

- **Тип:** Flow
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 54:22–55:38

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

**Текущо състояние:** Има email preview/history, но няма inbound mailbox ingestion и автоматично document matching.

**Предложено следващо действие:** Да се прецени дали това е MVP, интеграционен етап или остава ръчно качване.

**Връзки:** [Фактури](../mock/crm-full-mock.html#factory-invoices) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FIN-04"></a>
### FIN-04 · Документите са типизирани и свързани с точния бизнес обект

- **Тип:** Бизнес правило
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Покрито в mock/docs
- **Начално решение:** За обсъждане
- **Основание:** 95:54–96:39, 114:19–119:57

Всеки файл трябва да е свързан с поръчка, проформа, VIN, доставка, CMR, customs case или плащане според съдържанието му; общата папка не замества структурните връзки.

**Текущо състояние:** Досиетата са групирани по процес и показват source и status, макар част от типовете още да са примерни.

**Предложено следващо действие:** Да се утвърди document taxonomy и задължителните relation keys.

**Връзки:** [Документи по пратката](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="FIN-05"></a>
### FIN-05 · Да не се дублира работещ финансов модул

- **Тип:** Архитектура
- **Приоритет:** Среден
- **Източник:** Среща
- **Текущо покритие:** Липсва
- **Начално решение:** За обсъждане
- **Основание:** 152:13–154:06

Преди разработка трябва да се провери кои purchase order, invoice, counterparty и payment функции вече съществуват в другите продукти/модули и да се конфигурират за China Motor.

**Текущо състояние:** Това е архитектурна задача, не екран в мокъпа.

**Предложено следващо действие:** Да се направи кратък technical discovery и mapping към съществуващите компоненти.

**Връзки:** [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Бъгове и UX

<a id="BUG-01"></a>
### BUG-01 · Неконсистентните seed данни блокираха реалната демонстрация

- **Тип:** Бъг
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** Отворено
- **Начално решение:** За обсъждане
- **Основание:** 04:53–08:35, 48:40–58:22

Липсващи цветове, неподходящи модели и несвързани тестови записи направиха част от end-to-end проверката невъзможна и доведоха до импровизирани документи.

**Текущо състояние:** Мокъпът още използва различни примерни поръчки и документи в отделни модули.

**Предложено следващо действие:** Да се създаде един canonical demo dataset с поръчка, проформи, VIN, фактури, транспорт и приемки.

**Връзки:** [Основен мокъп](../mock/crm-full-mock.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="BUG-02"></a>
### BUG-02 · Филтрирането/правата не показаха очакваните произведени коли

- **Тип:** Бъг
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 92:43–94:05

По време на демонстрацията търсените произведени автомобили не се появиха и беше сменена роля, което показва възможен дефект във филтъра, данните или permission scope.

**Текущо състояние:** След това е добавен универсален модул за колони, филтри и role-aware actions, но конкретният сценарий не е повторно тестван.

**Предложено следващо действие:** Регресионен тест: Product Manager маркира произведени → Logistics вижда същите VIN и ги добавя в транспорт.

**Връзки:** [Автомобили](../mock/crm-full-mock.html#production) · [Транспорт](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="BUG-03"></a>
### BUG-03 · AI предложи несвързани автомобили от неподходящ документ

- **Тип:** Бъг
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Отворено
- **Начално решение:** За обсъждане
- **Основание:** 106:37–107:27

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

**Текущо състояние:** Новият UI показва confidence и проверка, но генераторът все още симулира съвпадение по модел.

**Предложено следващо действие:** Да се въведе hard unresolved state при document/order mismatch и тестове с негативни документи.

**Връзки:** [Добави доставка](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="BUG-04"></a>
### BUG-04 · Липсващ carrier master record не блокираше процеса

- **Тип:** Бъг
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Отворено
- **Начално решение:** За обсъждане
- **Основание:** 107:32–108:11

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

**Текущо състояние:** Carrier select е задължителен, но entity-resolution exception flow липсва.

**Предложено следващо действие:** Да се създаде отделна задача за company matching и audit.

**Връзки:** [Добави доставка](../mock/crm-full-mock.html#international-request) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="BUG-05"></a>
### BUG-05 · Старият customs wizard беше неразбираем и с нерелевантни полета

- **Тип:** Бъг
- **Приоритет:** Висок
- **Източник:** Среща
- **Текущо покритие:** За проверка
- **Начално решение:** За обсъждане
- **Основание:** 120:59–123:24

Участниците не можаха да обяснят какво се въвежда и защо, което е едновременно UX и domain дефект.

**Текущо състояние:** Екранът е преработен след срещата, но няма нова клиентска валидация.

**Предложено следващо действие:** Да се прегледа с реален митнически документ и да се премахне всичко без бизнес собственик.

**Връзки:** [Обмитяване](../mock/crm-full-mock.html#customs) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="BUG-06"></a>
### BUG-06 · Приемката и подробният оглед бяха слети и забавяха транспорта

- **Тип:** Бъг
- **Приоритет:** Критичен
- **Източник:** Среща
- **Текущо покритие:** Само локално
- **Начално решение:** За обсъждане
- **Основание:** 126:21–135:12

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

**Текущо състояние:** Корекцията е направена само локално в Тексим мокъпа и не е публикувана в Git HEAD.

**Предложено следващо действие:** Да се валидира локалният вариант и да се публикува като отделна промяна.

**Връзки:** [За приемане](../mock/texim-operational-portal.html#warehouse-receipt) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

<a id="BUG-07"></a>
### BUG-07 · Основният мокъп съдържа дублирани функции и dead override код

- **Тип:** Бъг
- **Приоритет:** Критичен
- **Източник:** Код
- **Текущо покритие:** Отворено
- **Начално решение:** За обсъждане
- **Основание:** Техническо наблюдение след коментара 152:13–152:56

Статичната проверка намира 33 имена на функции, дефинирани повече от веднъж, включително transport, customs, final invoice и warehouse функции. По-късната дефиниция тихо заменя по-ранната и прави поведението трудно за доказване.

**Текущо състояние:** Проблемът е потвърден в текущия crm-full-mock.html; това не означава автоматично 33 потребителски бъга, но е реален риск и пречи на финалната валидация.

**Предложено следващо действие:** Преди финалния mock freeze да се премахнат override блоковете и да остане една дефиниция на функция с regression checks.

**Връзки:** [Основен мокъп](../mock/crm-full-mock.html) · [Запис](https://app.clickup.com/9004021877/docs/8cawy3n-38915)

- **Да стане реална задача:** ☐ Да ☐ Не ☐ За обсъждане с клиента


---

## Техническо приложение

Статичната проверка на `crm-full-mock.html` намира 832 function declarations и 33 имена, дефинирани повече от веднъж. Това не означава автоматично 33 потребителски дефекта, но означава, че по-късна дефиниция тихо заменя по-ранна.

Дублираните имена са: `carSelectionActions`, `carsReqTransport`, `confirmFactoryFinalInvoices`, `customsRequestSelected`, `dashOpenTransport`, `factoryExpectedUnitPrice`, `factoryFinalInvoicesCard`, `factoryReadFinalInvoiceBatch`, `openCarrierRequestModal`, `openExcelDrop`, `openFactoryFinalInvoiceBatch`, `openTransportDeliveryModal`, `openTransportDossier`, `openWarehouseReadiness`, `openWarehouseTransportForm`, `recSendGo`, `refreshFactoryFinalInvoiceValidation`, `renderCustomsTab`, `renderInlineShipmentComposer`, `renderOrderShipments` (3×), `renderShipments`, `renderTransportOffers`, `renderTransportOrderDetail`, `renderTransportOrderRegister`, `showDealerTransferRegister`, `transportCreateInlineShipment`, `transportInlineSelection`, `transportRefreshInlinePreview` (3×), `transportSaveCarrier` (3×), `transportSaveDelivery`, `warehouseGate`, `warehouseReadinessTable`, `warehouseSummary`.

## Следващ етап

След клиентска и вътрешна валидация само потвърдените точки се превръщат в:

+ актуализация на финалния мокъп;
+ актуализация на процесната документация;
+ самостоятелни ClickUp user stories, bugs и technical debt задачи с пълен текст, зависимости и acceptance criteria.