# China Motor CRM - въпроси за валидиране от Борда на директорите

Дата: 05.09.2026
Статус: Работен документ за управленско обсъждане

## Цел на срещата

Бордът не трябва да валидира екрани, полета и техническа реализация. Целта е да потвърди:

1. правилно ли е моделиран бизнесът на вносителя и дилърската мрежа;
2. правилни ли са отговорностите и точките на управленско решение;
3. приемливи ли са правилата за количество, плащане, документи и изключения;
4. правилно ли е разделена отговорността между China Motor, дилърите, Тексим, After Sales, Finance и Navision;
5. има ли бизнес риск, който системата не трябва да позволява дори с предупреждение.

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

---

## A. Концепции за потвърждение

Това са вече моделираните принципи. Не са отворени предложения за нови функции, а основата, върху която са направени flow-овете и мокъпите.

### A1. Един портал и организационна структура

**Текуща концепция**

- Един потребител може да има няколко комбинации `Компания + Роля + Представителство` и да сменя активния си контекст.
- Структурата е `Вносител -> Дилърско дружество -> Представителство`.
- Представителството принадлежи на точно един дилър и един вносител.
- China Motor Bulgaria и China Motor Serbia са равнопоставени вносители.
- Сърбия може да поръчва директно от Китай или през China Motor Bulgaria, като системата пази отделно вносител, заявител, дилър, предназначение и крайна дестинация.

**Въпрос към борда:** Потвърждавате ли този организационен модел и равнопоставеността на двата вносителя?

### A2. Права и отговорности

**Текуща концепция**

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

**Въпрос към борда:** Потвърждавате ли това разделение между управленски, бизнес и административен достъп?

### A3. Два входа за дилърска поръчка

**Текуща концепция**

- Клиентска поръчка започва от контакт, оферта, приемане от клиента, резервация/поръчка и капаро.
- Поръчка за свободна наличност в дилърски склад се създава от Sales Manager без клиент, оферта и капаро.
- Складовата поръчка не може да се представя като клиентска резервация.

**Въпрос към борда:** Потвърждавате ли двата отделни входа и изискването за капаро при клиентската поръчка?

### A4. Последователно одобрение и решение по количества

**Текуща концепция**

`Sales Manager -> Dealer Manager -> Мениджър търговска мрежа -> Продуктов мениджър -> Бранд мениджър`

- Всяко ниво вижда количеството от предходното и може да потвърди същото или по-малко количество.
- Бранд мениджърът взема финалното решение.
- Процесът върви само напред и не се връща към предходно ниво.
- Неодобрената разлика се счита за отказана.
- Финално одобреното количество остава активно до пълното му включване в заводски поръчки.

**Въпрос към борда:** Потвърждавате ли веригата, правото на всяко ниво да намалява количеството и финалното решение на Бранд мениджъра?

### A5. Заводски поръчки и остатък по дилърското търсене

**Текуща концепция**

- Една заводска поръчка е към точно един доставчик, но може да съдържа много модели и дилърски източници.
- Смесената селекция се разделя автоматично по доставчик.
- Всяка бройка пази връзката с дилърската заявка, дилъра, представителството и предназначението.
- Системата пази отделно заявено, финално одобрено, включено в заводски поръчки, разпределено и доставено количество.
- Заводската поръчка може да остане активна и многократно да получава автомобили, проформи и фактури. Промените се пазят в audit log, без отделни версии на поръчката.

**Въпрос към борда:** Потвърждавате ли този модел на дълго живееща заводска поръчка и проследяване на неизпълнения остатък?

### A6. Разпределение на произведените автомобили

**Текуща концепция**

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

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

### A7. Документът е първият източник на данни

**Текуща концепция**

За входящи Excel файлове, фактури, проформи, BL, CMR, митнически и хомологационни документи се използва един процес:

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

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

**Въпрос към борда:** Потвърждавате ли document-first принципа и човешката валидация като задължителна контролна точка?

### A8. Липсващи данни и бизнес изключения

**Текуща концепция**

- Липсващи VIN, номер на двигател, индивидуална фактура, декларация, документ, плащане или друга готовност са видими предупреждения.
- Те не са универсален hard gate.
- Потребител с конкретно право може да продължи след потвърждение на предупреждението.
- Системата записва липсите, потребителя, момента и решението в audit историята.

**Въпрос към борда:** Приемате ли контрол чрез предупреждение и проследим override, или има събития, които трябва да бъдат абсолютно забранени без конкретен документ/плащане?

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

**Текуща концепция**

- Една транспортна поръчка може да има няколко заявки за оферта и много отделни доставки.
- Всяка доставка може да има различен превозвач, маршрут, дати, BL, фактура и автомобили.
- Капацитетът се задава по модел; контейнерът не е задължителен бизнес обект.
- Финалният транспортен разход се разпределя пропорционално според капацитета на моделите и може да бъде коригиран от Логистика преди потвърждение.
- Тексим получава автоматично предварително известие и отделно известие при пристигане в България; и двете могат да бъдат изпратени повторно.

**Въпрос към борда:** Потвърждавате ли структурата `поръчка -> оферти -> много доставки` и начина за разпределяне на транспортния разход?

### A10. Транзит, обмитяване и митническа декларация

**Текуща концепция**

- Преместването от BG пристанище до Безмитен склад е митнически транзит, изпълняван от Тексим, а не обмитяване.
- Физическото приемане в Безмитния склад приключва транзита.
- Митническата калкулация и фактурата са два отделни блока; ако първо се качи фактурата, тя попълва и калкулацията.
- Фактурата създава едно задължение за плащане.
- Митническото освобождаване и получаването на финалната декларация/MRN са отделни събития.
- Автомобил може да бъде отбелязан като освободен, докато декларацията все още се очаква и остава видимо задължение.

**Въпрос към борда:** Потвърждавате ли разделението между транзит, плащане, освобождаване и получаване на декларацията?

### A11. Складове, физическа локация и Navision

**Текуща концепция**

- Всеки автомобил има отделни `Физическа локация`, `NAV склад` и `Крайна дестинация`.
- Всички готови автомобили могат да бъдат заведени счетоводно в `Централен склад Чайна Мотор`.
- Само демонстрационните автомобили и свободният собствен сток се местят физически до Централния склад.
- Автомобилите за конкретен дилър могат да тръгнат директно от Тексим към дилъра.
- Всеки автомобил има постоянен `NAV ID`, различен от инвентарен номер и VIN.
- CRM импортира и експортира договорения Navision stock формат; експортът не променя физическата локация.

**Въпрос към борда:** Потвърждавате ли разделението между счетоводен склад и физическа локация и този обмен с Navision?

### A12. Двата PDI процеса

**Текуща концепция**

- `PDI Тексим` е допълнителен оглед след физическото приемане. Той може да бъде изпълнен по-късно и не блокира останалите процеси.
- `Дилърски PDI` се заявява от дилъра, изпълнява се от After Sales и дилърът фактурира разхода към China Motor.
- PDI фактурата се изпраща към Finance без допълнително бизнес одобрение.
- Оперативният дилърски PDI вече е реализиран в отделната система за щети. Каква част от процеса се вижда или управлява в CRM остава отворено решение.

**Въпрос към борда:** Потвърждавате ли бизнес модела и коя система трябва да бъде водеща за дилърския PDI? Трябва да се определи как CRM получава заявката, статуса, резултата, документите и фактурата от системата за щети и как се обработват разминавания или липсваща връзка.

### A13. Управленски dashboard

**Текуща концепция**

- Dashboard-ът има четири основни категории: `Приходи`, `Разходи`, `Таргети дилъри` и `Таргети доставчици`.
- Периодът по подразбиране е от началото на годината до днес, с месечни графики.
- Детайлите се разглеждат по дилър, представителство, търговец, доставчик, марка и модел според активния достъп.
- Оперативните задачи и ескалациите са отделен блок.

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

### A14. Цени, оферти и финансова видимост на дилъра

**Текуща концепция**

- Клиентската оферта пази договорената клиентска конфигурация и цена и не се преизчислява автоматично при последваща промяна на доставна или каталогова цена.
- Стандартната оферта се управлява в дилърския екип; продажба под дилърската цена изисква право за по-високо ниво на одобрение.
- Дилърът вижда собствените си фактури в отделни състояния `За плащане`, `Просрочени` и `Платени` и може да сваля документите според организационния си обхват.
- Проформа, фактура и платежен документ са отделни обекти; реалното плащане се потвърждава от Finance/Navision.

**Въпрос към борда:** Потвърждавате ли независимостта на клиентската цена, контрола при продажба под дилърската цена и финансовата видимост по дилърски роли?

---

## B. Истински отворени управленски решения

Тези въпроси нямат окончателен отговор и могат да променят процесите или permission модела.

### B1. Има ли задължително FIFO към дилърите?

**Текущо предложение:** Хронологията показва кой е поръчал първи, но е само ориентир. Редът в заводската поръчка и разпределението следват ръчния избор на Продуктовия мениджър. Няма автоматично правило `първи поръчал -> първи получил`.

**Решение:** Бордът трябва да потвърди дали това е допустима управленска свобода или се изисква задължително правило за приоритет.

### B2. Има ли изключения от капарото?

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

**Решение:** Ако са допустими изключения, трябва да се определи кой има право да ги разреши.

### B3. Фиксирани ли са ескалациите на 90/120 дни?

**Текущо предложение:** Одобрено, но неизпълнено дилърско търсене се маркира на 90 дни и се ескалира на 120 дни.

**Решение:** Периодите фиксирани ли са за всички марки и доставчици, или се настройват според марка/доставчик?

### B4. Кой е бизнес собственик на хомологацията?

**Текущо предложение:** Прегледът, редакцията и потвърждението са отделни права. CoC/сертификатът за съответствие и УИО са алтернативни пътища според автомобила.

**Решение:** Кой екип носи крайната отговорност и кои начални роли трябва да имат съответните права?

### B5. Кой взема решението при щета?

**Текущо предложение:** Приемащият регистрира случая, Тексим предоставя оглед/калкулация, а China Motor решава ремонт, claim, изчакване или друг резултат. After Sales управлява изпълнението и приключването.

**Решение:** Коя бизнес функция има право да одобри разхода и окончателното решение по щетата?

### B6. Кой може да прави рисков override?

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

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

### B7. Коя система е финансова истина?

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

**Решение:** Бордът трябва да потвърди границата между CRM и Navision и коя система е водеща при разминаване.

### B8. Какви езици поддържат порталите при старт?

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

**Решение:** Кои езици са задължителни за първата production версия?

### B9. Как се задават и отчитат таргетите?

**Текущо предложение:** Заводските цели са годишни с разпределение по Q1-Q4; дилърските цели са отделни по дилър и модел. Месечният изглед е отчетна разбивка. Надвишаването на таргет се показва, но не блокира и не предлага автоматично количество.

**Решение:** Потвърждавате ли периодите, собствениците на двата вида таргети и че таргетът е управленски ориентир, а не ограничение за поръчване?

### B10. Как комуникират CRM и системата за щети за дилърски PDI?

**Потвърден контекст:** Дилърският PDI вече се управлява оперативно в системата за щети. Потвърденият бизнес поток остава `дилър заявява -> After Sales изпълнява -> дилър фактурира China Motor`.

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

---

## C. Важни уточнения, които не са за Борда

Тези теми са необходими преди production, но трябва да бъдат възложени на процесните собственици. Бордът следва да потвърди само кой ги предоставя и до кога.

| Тема | Необходим резултат | Предложен собственик |
|---|---|---|
| Митнически Excel | Реалният шаблон, точните колони и примерен завършен файл | Логистика / митнически агент |
| Документни комплекти | Окончателен checklist по етап: транзит, обмитяване, хомологация, склад, дилър | Логистика + Back Office |
| Транспортен капацитет | Финални капацитети/коефициенти по модел | Логистика + Продуктов екип |
| NAV обмен | Потвърден 69-колонен формат, задължителни полета и обработка на грешки | Finance / Back Office / IT |
| Хомологационни документи | Точни наименования и видове CoC/УИО и примерни документи | Хомологационен собственик |
| Известия | Получатели, канали и текстове за Тексим, дилъри и ескалации | Логистика + Търговска мрежа |
| Permission матрица | Началните права по функции за двата вносителя и дилърските роли | Business owners + системен администратор |
| Реален E2E пример | Една проследима поръчка с реални модели, документи и статуси от оферта до дилър | Всички процесни собственици |

---

## D. Очакван резултат от срещата

Срещата е успешна, ако приключи със:

1. потвърждение или конкретна промяна по A1-A14;
2. еднозначно решение по B1-B10;
3. посочен собственик и срок за всеки ред от секция C;
4. именуван представител от China Motor, който да даде финален business sign-off на обновените flow-ове и мокъпи;
5. решение, че след тази валидация нови процесни промени влизат само чрез изрично change request, а не чрез неформално тълкуване.

## Кратък протокол за попълване

| ID | Потвърждаваме | Променяме | Собственик / бележка |
|---|---|---|---|
| A1-A14 |  |  |  |
| B1 FIFO |  |  |  |
| B2 Капаро |  |  |  |
| B3 90/120 дни |  |  |  |
| B4 Хомологация |  |  |  |
| B5 Щети |  |  |  |
| B6 Override права |  |  |  |
| B7 CRM / Navision |  |  |  |
| B8 Езици |  |  |  |
| B9 Таргети |  |  |  |
| B10 Дилърски PDI / система за щети |  |  |  |