China Motor CRM — процесни flow-ове по роли

Дата: 13.08.2026 · актуализирано на 05.09.2026
Обхват: организация и дилърска мрежа, снабдяване, заводски поръчки, автомобили, плащания, международна логистика, Тексим, обмитяване, хомологация и доставка към дилър. Мокъпи: crm-full-mock.html, texim-operational-portal.html, dealer-process-mock.html и serbia-importer-portal.html

1. Роли и отговорности

Външни участници

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

Организационен модел

Вносител → Дилър (юридическо лице) → Представителство

Ролите в документа са начални профили. Всеки екран и бизнес action се разрешава от конкретно permission плюс допустимия текущ статус, а не чрез hardcoded проверка за име на роля. Един потребител може да има повече от една комбинация Компания + Роля + Представителство.

• China Motor Bulgaria и China Motor Serbia са два равнопоставени вносителя.
• Представителството принадлежи точно на един дилър и един вносител.
• Сръбска заявка през България се вижда и от двете страни като заявка, но винаги пази: вносител, тип заявител, за собствен склад / за дилър, дилър, представителство и крайна дестинация.
• China Motor Bulgaria може да бъде доставчик на China Motor Serbia; алтернативата е директен доставчик/завод от Китай.
• Детайлната матрица на права не се моделира на този етап. Двата вносителя са с еднакви принципни права.
• Сръбският портал е на английски по подразбиране и е подготвен за двуезичност.

2. Как е показан процесът

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

Общ принцип за входящи документи

Когато данни от фактура, товарителница, CMR, митнически или хомологационен документ се използват в CRM, документът е първият вход. Единният flow е качване → структурно четене/OCR → AI съпоставяне → директно попълнена форма → човешка проверка → потвърждение. Потребителят не преписва документа поле по поле. Ръчна корекция се допуска само за липсваща или неправилно разчетена стойност, а бизнес статусът се променя едва след потвърждението.

Основната навигация по жизнения цикъл в автомобилния регистър е:

Производство → Произведени → Към BG → BG порт → Безмитен склад → Дилър

Тя групира точните оперативни състояния. Производство включва подстатусите Поръчана и В производство; Произведени включва произведена, за плащане и платена/готова бройка; Към BG включва заявен и активен международен транспорт и показва доставката с нейното ETA като основна колона; Безмитен склад включва пътуване и приемане в склада; Дилър включва заявка, изпращане и приемане от дилъра. Налични, Резервирани, Капарирани и Продадени са отделни търговски гледки, а не логистични стъпки.

Филтриране, навигация и масови действия

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

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

Работен плот — KPI и оперативни задачи

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

Видимостта следва активната компания, представителство и permissions на потребителя. Одобрени дилърски заявки с неизпълнен остатък се маркират при 90 дни без движение и се ескалират при 120 дни. Всеки оперативен уиджет води към съответния филтриран списък.

3. Flow 1 — цели и планиране

Начало: договорени годишни цели и очаквано дилърско търсене. Край: видима база за заводски поръчки и контрол на изпълнението.

Екран в мокъпа: Цели → Заводски цели · Продуктов мениджър

Важно: заводските и дилърските цели са отделни входове и имат различни права за редакция. Дилърът не редактира заводския контракт.

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

4. Flow 2 — дилърска заявка до одобрено търсене

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

Екран в мокъпа: Дилърски портал → Оферти → Създай поръчка от офертата, след това Дилърски заявки · Dealer Sales / Sales Manager / Dealer Manager / Мениджър търговска мрежа / Продуктов мениджър / Бранд мениджър

Контрол: всяко ниво получава като предварително попълнена стойност решението на предходното и може само да го запази или намали. Процесът се движи само напред; не се използва връщане към предходна стъпка. Неодобрената разлика се счита за отказана, а финално одобреното количество се проследява до пълното му включване в заводски поръчки. Смяната на дилър на конкретен неплатен автомобил не преизчислява дилърската заявка. След плащане разпределението на автомобила се заключва. Заявки с одобрен неизпълнен остатък без движение се маркират на 90 дни и се ескалират на 120 дни.

Прекратяване: създателят на дилърската заявка или потребител с permission за прекратяване от името на Dealer Manager може да я soft-delete-не. Клиентската оферта, клиентската поръчка, капарото и продажбата остават непроменени. Прекратяването се пази в историята и изключва заявката от бъдещо включване в заводска поръчка.

Flow 2A — Sales Manager поръчва за дилърски склад

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

Екран в мокъпа: Дилърски портал → Към вносител → + Поръчка за склад · Sales Manager, след това Заявки за одобрение · Dealer Manager

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

5. Flow 3 — заводска поръчка

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

Екран в мокъпа: Поръчки към завода → Импортирай Excel или + Нова поръчка към завода · Продуктов мениджър

Контрол: една заводска поръчка има точно един производител / доставчик, но може да съдържа много модели и модификации на същия доставчик. Смесена селекция се разделя автоматично по доставчик. Редът на позициите следва реда, в който Продуктовият мениджър ги добавя, а не автоматичен FIFO по дата на дилърската заявка. Поръчката остава редактируема и може многократно да получава нови автомобили, проформи и фактури; не се създават версии на поръчката, а стандартният audit log пази кой какво е променил. Дилърските количества са вече одобрени от Бранд мениджър и не минават второ дублиращо одобрение. Допълнителните количества за собствен склад/таргет изискват одобрение преди изпращане.

6. Flow 4 — производство на ниво автомобил

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

Екран в мокъпа: Поръчки към завода → отвори поръчка → Excel от завода · Продуктов мениджър

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

7. Flow 5 — проформи, финални фактури и плащане към завода

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

Екран в мокъпа: Поръчки към завода → отвори поръчка → Проформа на поръчката / Индивидуални фактури · Продуктов мениджър валидира документите; потребител с право за плащане потвърждава платежната форма

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

Flow 5A - разпределение на произведените автомобили към дилъри

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

Екран в мокъпа: Поръчки към завода → отвори поръчка → Разпределение на произведените автомобили · Продуктов мениджър

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

8. Flow 6 — международен транспорт Китай → България

Начало: автомобилите са произведени и могат да бъдат включени в транспортна поръчка; VIN/двигател остават видими като информация, но липсващите данни не блокират доставката. Край: една транспортна поръчка с една или повече самостоятелни международни доставки във В транспорт.

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

Екран в мокъпа: Заявки за транспорт → Поръчки за транспорт → Отвори · Логистика

Транспортна поръчка и оферти

Многократни доставки под поръчката

Принцип на въвеждане: задължителните бизнес данни остават превозвач, BL/коносамент, фактура, маршрут, товарене, ETA и автомобили, но документите попълват формата преди потребителското действие. Потребителят проверява и потвърждава; само изключение, което документът не съдържа или е разчел неправилно, се коригира преди потвърждение.

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

Документи и достъп: Всяка доставка има общо документно досие за целия процес: транспортна поръчка и оферта, имейл кореспонденция, BL/коносамент, фактура от превозвача, манифест, packing list, карго застраховка, експортна декларация, разпределение на транспортния разход, платежен документ, Arrival Notice, известие и протокол от Тексим, CMR, MRN и хомологационни документи. Досието показва и наличните, и очакваните документи, а липсващите могат да се качат от същия екран. Финансовите документи и транспортната себестойност се виждат от Логистика, Продуктов мениджър, Финанси и Admin. Фактурата се подава към общия платежен списък, а видимият й статус е само Платена или Неплатена.

9. Flow 7 — проследяване до BG пристанище

Начало: доставката е във В транспорт. Край: конкретните автомобили са видими като физически налични на BG пристанище.

Екран в мокъпа: Заявки за транспорт → Отвори транспортна поръчка → Доставки · Логистика

10. Flow 8 — BG пристанище → Безмитен склад с частични приемки

Начало: има автомобили на BG пристанище, които още не са включени във вътрешен курс. Край: конкретни автомобили са физически приети в Безмитния склад със складов протокол.

Екрани в мокъпа: На пристанище и За приемане · Тексим

Ключов принцип: не се приема цялата морска доставка наведнъж. Приемането е на ниво отделен автомобил и един вътрешен курс може да има няколко последователни частични приемки. Бързият складов протокол, подписаният CMR, подробният PDI Тексим и бъдещият дилърски протокол са свързани, но различни записи.

Еднакъв вход: качването и автоматичното попълване на подписания CMR се изпълнява при физическото приемане в портала на Тексим. Основният CRM вижда документа, прочетените данни и историята, без да дублира приемането.

11. Flow 9 — хомологация

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

Екран в мокъпа: Хомологация · Логистика + Sales, за потвърждение

12. Flow 10 — обмитяване

Начало: автомобилите са физически приети в Безмитния склад. Край: конкретните автомобили са митнически освободени, а получените декларации/MRN са свързани с тях. Декларацията може да пристигне след освобождаването и дотогава остава отделно видимо документно задължение.

Екран в мокъпа: Обмитяване · Логистика

Подробна бизнес спецификация: Обмитяване — пълен бизнес процес · Уеб flow за преглед

Ключови правила: митническата заявка/досие е основният работен обект. Една заявка съдържа много автомобили и може да има много декларации; една декларация може да покрива един или много автомобила. Във входящия отговор винаги има един блок Калкулация и един блок Фактура. Калкулацията може да бъде попълнена от отделен документ, директно във формата или автоматично от фактурата. Отделната калкулация може да се запази преди фактурата и досието остава Чака фактура. Фактурата е задължителният финансов документ и създава точно едно задължение. Ако има отделна калкулация, тя не създава второ задължение, а служи за сравнение и разбивка.

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

Контрол с предупреждение: транзитът от пристанището до Безмитния склад е отделен от обмитяването. Клиентското/дилърското плащане също не е митнически gate. При липсващо освобождаване, декларация/MRN, документен комплект, приложима хомологация или плащане системата показва конкретните липси по автомобил. Потребител с право може да потвърди продължаването; решението, липсите, потребителят и моментът се записват в историята.

Подготовка и проверка в Безмитен склад

Екран в мокъпа: Автомобили → Безмитен склад · Логистика

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

Ключов UX принцип: един автомобил с липси не спира останалите и не изчезва от селекцията. Системата показва причината по ред, позволява изключване на конкретни бройки или permission-based продължаване и записва override-а в audit log.

Документно досие: доставна фактура, packing list, коносамент/BL, COC, CMR до Безмитен склад и складов протокол за приемане.

13. Flow 11 — заявка към Тексим за дилър

Начало: автомобилите са физически приети от Тексим и са заведени счетоводно в Централен склад Чайна Мотор. Документите, хомологацията, еко таксата, обмитяването и плащането се показват като готовност или предупреждение. Край: Тексим има видима заявка за конкретни автомобили и конкретна крайна дестинация.

Екран в мокъпа: Автомобили → Безмитен склад → Заяви транспорт или Back Office → Складова наличност, след това Заявки за транспорт → Към дилър · Логистика

Бизнес правило: действието се управлява от permission и допустим статус, а не от hardcoded име на роля. За неплатен автомобил няма отделен approval flow; показва се предупреждение и потребителят с право може да продължи.

14. Flow 12 — Тексим издава и изпраща към дилър

Начало: Тексим има одобрена заявка с конкретни автомобили. Край: избраните автомобили са физически напуснали Безмитния склад, но още не се считат за доставени.

Екрани в мокъпа: За издаване и Изпратени · Тексим

Ключов принцип: Издадена от Тексим означава Изпратена към дилър, а не Доставена.

15. Flow 13 — приемане от дилъра с приемо-предавателен протокол

Начало: автомобилите са със статус Изпратена към дилър. Край: конкретните автомобили са огледани и приети в представителството с отделен системен протокол.

Екран в мокъпа: Заявки за транспорт → Към дилър → Преглед: дилърски профил → Приеми с протокол · Дилър

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

16. Flow 14 — щета или несъответствие

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

Екран в мокъпа: Щети · регистриране от приемащия; оценка/оферта от Тексим; решение в China Motor

Права: преглед, редакция, решение и приключване на щета са отделни permissions. Началното разпределение е към приложимите Back Office, Логистика и After Sales роли, но всяко право може да бъде закачено към друга роля без промяна на flow-а.

17. Flow 15 — известия и комуникационна история

Известия се използват при решения по дилърска заявка, отказано производство, транспорт и пристигане, митнически събития, готовност за издаване, плащане, PDI/щети, преразпределение и 90/120-дневни ескалации. Пълната предложена матрица от trigger, получатели, канал, език, съдържание и документи е част от US-F15-01 и се одобрява като едно бизнес решение.

Екран в мокъпа: Известия / Плащания · потребител с приложимо permission и organizational scope

Контрол: автоматичното известие е еднократно за trigger. Ръчното повторение създава нов запис. Неуспешен или опционално пропуснат email не връща и не блокира бизнес действието.

18. Flow 16 — подготовка за издаване и складово състояние

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

Екрани в мокъпа: Back Office → Подготовка за издаване, Back Office → Складова наличност и Автомобили → досие → Път на автомобила

Правило за Централния склад: всички автомобили могат да бъдат заведени счетоводно в Централен склад Чайна Мотор. Физически там се транспортират само демонстрационни автомобили и свободен собствен сток. Автомобилите за конкретен дилър се вземат директно от Тексим.

История: физическата локация, NAV складът и крайната дестинация са отделни полета. Всяка промяна пази предишна и нова стойност, дата, извършил и източник на събитието.

19. Flow 17 — еко такси и индивидуални декларации

Начало: наличен е CoC или Удостоверение за индивидуално одобряване (УИО). Край: еко таксата е платена и индивидуалните декларации са налични в автомобилните досиета.

Екран в мокъпа: Back Office → Еко такси

20. Flow 18 — документни комплекти към дилър

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

Екран в мокъпа: Back Office → Комплекти към дилър

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

Начало: клиентът е приел офертата и автомобилът не може да бъде изпълнен директно от свободния собствен склад на дилъра. Край: има клиентска поръчка и свързана дилърска заявка със статус Чака Sales Manager.

Екран в мокъпа: Дилърски портал → Оферти → Приета → Създай поръчка

22. Flow 20 — Sales Manager проверява и одобрява

Начало: дилърската заявка е със статус Чака Sales Manager. Край: заявката е отказана или е предадена към Dealer Manager с потвърдено от Sales Manager количество.

Екран в мокъпа: Дилърски портал → Поръчки → Заявки за одобрение

23. Flow 21 — Dealer Manager одобрява и изпраща към вносителя

Начало: заявката е одобрена от Sales Manager или е създадена от Sales Manager за дилърски склад. Край: заявката е отказана или е изпратена към China Motor със статус Чака Мениджър търговска мрежа.

Екран в мокъпа: Дилърски портал → Поръчки → Заявки за одобрение

24. Flow 22 — China Motor приема заявката и потвърждава количество

Начало: Dealer Manager е изпратил заявката към China Motor. Край: дилърът вижда финално потвърденото количество, а Продуктовият мениджър може да продължи с поръчването към доставчик.

Екран в мокъпа: Дилърски портал → Поръчки → Към вносител и Основен CRM → Дилърски заявки

25. Flow 23 — дилърски фактури, падежи и плащания

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

Екран в мокъпа: Дилърски портал → Поръчки → Към вносител → Фактури

26. Flow 24 — дилърът приема изпратените автомобили

Начало: China Motor и Тексим са изпратили конкретни автомобили към представителството. Край: получените автомобили са приети поотделно и имат приемо-предавателен протокол, снимки и резултат от огледа.

Екран в мокъпа: Дилърски портал → Доставки за приемане

27. Оперативен контрол при големи обеми

Това не е отделен lifecycle, а общ механизъм във всички автомобилни flow-ове.

Администратор: има същия достъп до дилърски цени и фактурни стойности като Продуктов мениджър. В текущия UI на щетите действието за затваряне остава достъпно за всички роли за демонстрационни цели, въпреки че бизнес собственикът е After Sales.

NAV импорт и експорт на автомобили

• Всеки автомобил има постоянен NAV ID, който е отделен от VIN и инвентарния номер и се използва за обмена с Navision.
• Импортът започва с качване на реалния NAV файл, показва разпознатите редове във формата и предлага създаване или обновяване.
• При съществуващ автомобил основното съпоставяне и обновяване е по NAV ID. VIN и инвентарният номер остават отделни бизнес полета и не се презаписват като NAV ID.
• Полето NAV склад е счетоводно. NAV импортът може да го обнови, но не променя Физическа локация.
• При физическото приемане от Тексим автомобилът е в NAV склад Пазарджик · необмитени. След подготовката CRM го отбелязва в Централен склад Чайна Мотор, докато физически остава при Тексим.
• От Back Office → Складова наличност се експортират само вече заведените в Централния склад автомобили: избраните или всички в текущия филтриран набор.
• Експортът използва същите 69 колони, имена, ред и CSV разделител като предоставения Stock_14082026.csv. Полето id е NAV ID, а parking_area съдържа NAV склада.
• Неразпознатите и непълните редове остават видими за човешка проверка; системата не измисля стойности.

28. Ролеви работни опашки

Продуктов мениджър

1. Цели за преглед и остатък за поръчване.
2. Нови дилърски заявки за решение.
3. Одобрени заявки, които чакат включване в заводска поръчка.
4. Заводски поръчки, които чакат потвърждение.
5. Поръчани бройки, които трябва да преминат в производство.
6. Бройки в производство, които трябва да бъдат отбелязани като произведени.
7. Отказани производствени позиции и известия към заявителя.
8. Произведени автомобили, които трябва да бъдат заявени за плащане.

Логистика

1. Произведени автомобили, готови за международна транспортна заявка; payment статусът е видим, но не е автоматичен блокер.
2. Заявки към превозвачи, които чакат избор на оферта.
3. Автомобили в международен транспорт с липсващ VIN, № двигател или индивидуална финална фактура, които изискват внимание, без автоматично да спират процеса.
4. Международни доставки с промяна по ETA, липсващи документи или чакащо известие към Тексим.
5. Автомобили на BG пристанище и вътрешни курсове към Безмитен склад.
6. Дневна митническа чернова и изпратени заявки, които чакат калкулация или фактура.
7. Митнически фактури, които чакат плащане, и платени заявки, които чакат освобождаване.
8. Обмитени автомобили, които чакат декларация/MRN, и заявки с частично покритие.
9. Доставки, които чакат хомологационен сертификат.
10. Обмитени автомобили, които чакат разпределение.
11. Заявки към Тексим, частично изпратени автомобили и дилърски протоколи само за преглед.

Тексим

1. На пристанище — автомобили, които още не са включени във вътрешен курс.
2. За приемане — автомобили във вътрешен курс, които още не са физически приети; подписаният CMR се качва тук.
3. В Безмитен склад — приети автомобили и история на складовите протоколи.
4. За издаване — одобрени заявки към дилър.
5. Изпратени — физически издадени автомобили, които още не са приети от дилъра.
6. Частично приети вътрешни курсове и частично изпълнени заявки към дилър.

Back Office

1. Единна опашка Подготовка за издаване с автомобили, които чакат документи, хомологация, еко такса, обмитяване или NAV завеждане.
2. Документни досиета, за които се очаква файл, физически оригинал или заверка.
3. Автомобили с CoC/УИО, готови за включване в партида за еко такса.
4. Изпратени еко такси, които чакат фактура или плащане.
5. Платени партиди, за които трябва да се генерират индивидуални декларации.
6. Физически приети автомобили в Пазарджик · необмитени, които чакат счетоводно завеждане в Централен склад Чайна Мотор.
7. Предстоящи дилърски предавания, за които трябва да се подготви документен комплект.

Dealer Sales

1. Приети от клиента оферти, от които трябва да се създаде поръчка.
2. Създадени заявки, които чакат решение от Sales Manager или Dealer Manager.
3. Потвърдени от China Motor количества по собствените клиенти.
4. Фактури и падежи по собствените поръчки, когато има permission за финансов преглед.
5. Потвърдени, произведени и пътуващи автомобили.
6. Автомобили, изпратени от Тексим и чакащи физическо приемане.
7. Щети/несъответствия, установени при получаване.

Sales Manager

1. Заявки на назначения екип със статус Чака Sales Manager.
2. Решения и потвърдени количества по търговци и представителства в собствения scope.
3. Поръчки за свободна наличност в дилърски склад, създадени от Sales Manager.
4. Фактури за плащане, просрочени и платени документи в разрешения финансов scope.

Dealer Manager

1. Всички дилърски заявки, които чакат финално вътрешно одобрение и изпращане към China Motor.
2. Изпратени към вносителя заявки и получени потвърдени количества за всички представителства на дилъра.
3. Всички фактури за плащане, просрочени и платени документи на дилърската компания.
4. Предстоящи и частично приети доставки към представителствата.

29. Къде се вижда всеки flow в мокъпите

30. Решаващи статуси и кой ги задава

31. Потвърдени ролеви решения

32. Оставащи отворени решения

1. Прилага ли се реално бизнес правило „първи дилър поръчал, първи получил“, или хронологичният ред е само визуален ориентир за Продуктовия мениджър? До потвърждение няма автоматично FIFO разпределение.
2. Кой изпълнява хомологацията? Достъпът ще бъде permission-based, но началните ролеви профили трябва да се потвърдят.
3. Какви са точните колони и формат на Excel шаблона към митническия агент? Ще се фиксират след получаване на реалните файлове.
4. Какви са окончателните капацитети за всеки модел? В мокъпа има демонстрационни стойности, които трябва да бъдат заменени с бизнес номенклатура.
5. Кои езици ще са налични в българския портал? Сръбският е с английски по подразбиране и подготвено BG превключване само за демонстрация.
6. Каква е детайлната начална матрица на права за двата вносителя? Основният модел permission + допустим статус е потвърден, но конкретното разпределение по профили е отложено.