CMChina Motor CRM
Бизнес изискванияЕпици, stories, Acceptance Criteria и cross-check
Flow-овеМокъп
Работна спецификация · 07.09.2026

China Motor CRM: епици, user stories и проверка на покритието

Един четим документ за бизнес преглед преди финализиране на задачите. Съдържа пълните описания, полетата, взаимовръзките, Acceptance Criteria и сверка с решенията, flow-овете, мокъпа и незавършения Sprint 2 backlog.

8епика
40user stories
273Acceptance Criteria
2противоречия за корекция
00

Обхват, източници и начин на работа

Канонична бизнес спецификация

Статус: Работна структура преди превръщане в задачи Актуализирано: 05.09.2026

1. Предназначение

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

За бизнес преглед story по story се използва пълният HTML списък. В него няма редакционни статуси или audit оценки. Тази страница пази историческата сверка с решенията, flow-овете, мокъпа и незавършения Sprint 2 backlog.

  • Flow-овете показват последователността на бизнеса.
  • Epic документите дефинират бизнес обхвата.
  • User stories дефинират конкретната потребителска стойност и Acceptance Criteria.
  • data-model.md дефинира общите бизнес обекти, полета и взаимовръзки.
  • process-flows-dev-qa.md остава тестовата спецификация с подробните QA сценарии.
  • ClickUp задачите се създават само от story със статус Ready for task.

2. Йерархия на източниците

При противоречие се използва следният ред:

  1. изрично решение от China Motor, записано в decision log;
  2. одобрена user story и нейните Acceptance Criteria;
  3. процесният flow;
  4. текущият production frontend за вече реализирано поведение;
  5. мокъпът като визуална спецификация на новото поведение;
  6. QA test case;
  7. ClickUp задачата.

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

3. Статуси на story

Статус Значение
Draft Структурата е описана, но има липсващи решения или полета
For business validation Story е достатъчно ясна за преглед от process owner
Ready for task Бизнесът, полетата, връзките и AC са потвърдени
In delivery Има активна задача за разработка
Implemented Разработката е приключила, но може да чака QA
Accepted QA и business owner са потвърдили резултата

4. Epic структура

Epic Обхват Stories Основни flow-ове Документ
EP-01 Организация, достъп и общи UI правила 6 Глобални принципи EP-01
EP-02 Дилърски продажби, търсене и одобрение 6 F02, F19-F22 EP-02
EP-03 Таргети, заводски поръчки, производство и заводски фактури 7 F01, F03-F05 EP-03
EP-04 Международен транспорт, ETA, пристанище и приемане от Тексим 4 F06-F08 EP-04
EP-05 Хомологация и обмитяване 3 F09-F10 EP-05
EP-06 Back Office, складово състояние, NAV, еко такси и документи 4 F16-F18 EP-06
EP-07 Вътрешна доставка, дилърска приемка, PDI и щети 6 F11-F14, F24 EP-07
EP-08 Финансови списъци, известия, dashboard и управленски контрол 4 F15, F23 EP-08

Общо: 40 user stories - 30 пренесени от текущата QA спецификация и 10 добавени за липсващите общи или потвърдени процеси.

5. Задължителна структура на всяка story

Всяка story използва story template и съдържа:

  1. стабилен идентификатор и статус;
  2. actor, permission и organizational scope;
  3. бизнес цел и описание;
  4. предусловия и trigger;
  5. основен flow и резултат;
  6. полета с източник, задължителност и право за редакция;
  7. взаимовръзки и cardinality;
  8. бизнес правила и статусни преходи;
  9. Acceptance Criteria;
  10. изключения и отворени решения;
  11. връзки към flow, mock и QA cases.

6. Правила за Acceptance Criteria

  • AC описва наблюдаем бизнес резултат, а не конкретен frontend компонент или backend имплементация.
  • Всяко AC има уникален и стабилен идентификатор.
  • Permission отказът, недопустимият статус и organizational scope се покриват задължително.
  • При масови действия се описват частичен успех, невалидни редове и повторно изпълнение.
  • При AI документи се описват валиден, частично разчетен, нечетим и дублиран документ.
  • Предупреждение не се описва като hard gate, освен ако бизнесът изрично го е потвърдил.
  • Не се добавят автоматични решения, толеранси, FIFO или блокировки без потвърдено правило.

7. Граница между story и задача

Story описва какво трябва да може бизнесът и как се приема резултатът. Задачата след това добавя:

  • конкретен repository/module;
  • технически подход;
  • migration/API/background jobs;
  • frontend компоненти;
  • технически тестове и rollout plan;
  • estimate, assignee и sprint.

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

8. Съпътстващи документи

CHECK

Сверка: решения, flow, mock и Sprint 2

40 stories

Как да се чете резултатът

Потвърдените решения и новите канонични stories са бизнес истина. Старите конфликтни Sprint 2 задачи се използват само за миграционна сверка и се премахват след създаването на пълния нов набор; не трябва да определят новата реализация. „Съгласувано“ означава, че артефактите не си противоречат; не означава, че функционалността е реализирана или приета от QA.

Съгласувано 26Частично 10Конфликт 2Отворено 2
Важно

Старите Sprint 2 задачи трябва да бъдат премахнати след миграцията

Новите канонични stories и задачите, създадени от тях, остават. Старите припокриващи се или конфликтни задачи се изтриват изцяло след като за всяко story има нова водеща задача.

Организация

Notification matrix чака бизнес одобрение

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

ClickUp snapshot: разгледани са незавършените задачи в Sprint 2 на 05.09.2026. Старите, новите и дублиращите се задачи са показани заедно; те не са променяни.
Отвори Sprint 2
StoryОценкаРешение и flowМокъпНезавършени задачиНеобходимо действие
EP-01 - Организация, достъп и общи правила
US-F00-01Достъп до много компании и роли Частично РешениеCTX-03 и потвърденият модел Компания + Роля + ПредставителствоFlowОрганизационен модел и матрица на роли Има role/company switcher и екран за назначения; липсва отделна актуална Sprint 2 задача, която да обхваща целия модел. Няма пряка незавършена задача Да се провери реалният frontend за create/edit user и при липса да се създаде една задача за многократни назначения.
US-F00-02Разрешаване на действие по permission и статус Съгласувано РешениеПотвърден принцип permission + допустим статусFlowОбщ принцип за права по действия Проверки по permissions са приложени в консолидирания мокъп. UNI-32135 Да се използва като общо изискване за всички останали задачи.
US-F00-03Контекстно меню и обхват на данните Частично РешениеCTX-03, CTX-04 и последващата меню матрицаFlowРоли, организационен scope и dashboard контекст Switcher-ът и ролевите менюта са показани; frontend parity трябва да се провери отделно. UNI-32137 Да се добави изричен scope към задачата за role switching или отделна задача само ако реалният frontend не го покрива.
US-F00-04Единни таблици и масови действия Съгласувано РешениеПотвърден общ UI принципFlowФилтриране, навигация и масови действия Column filters, selection set и долна bulk action лента са уеднаквени в основните регистри. UNI-32295 Да се използва един и същ frontend компонент във всички автомобилни таблици.
US-F00-05AI обработка на входящ документ Частично РешениеCON-05, TR-05, TX-06 и общото решение document-firstFlowОбщ принцип за входящи документи Еднакъв модел upload -> progress -> попълнена форма -> потвърждение е показан, но AI е демонстрационен. UNI-32208 UNI-32194 UNI-31952 Да се обедини техническият компонент, без отделните business stories да се смесват в една задача.
US-F00-06История на бизнес действията Частично РешениеCON-14 и общите audit решенияFlowИстория и комуникационни събития Има локални истории по процеси, но не е доказан единен audit модел за всички действия. UNI-32162 Да се дефинира общ audit contract; UNI-32162 покрива само преразпределението.
EP-02 - Дилърски продажби, търсене и одобрение
US-F19-01Клиентска поръчка и заявка към вносителя Съгласувано РешениеDLR-03 и потвърденият dealer flowFlowF19 и дилърски flow: оферта -> клиентска поръчка -> заявка Дилърският портал наследява клиент, конфигурация, цена и източник от офертата. UNI-31977 UNI-32138 UNI-32139 UNI-32242 Да се избере UNI-31977 като водеща story задача и да се свържат по-малките задачи като подзадачи или AC.
US-F20-01Одобрение на заявка от Sales Manager Частично РешениеDLR-04 и количественото уточнение след срещатаFlowF20 - Sales Manager решение Стъпката и количествената форма са налични. UNI-32085 UNI-32142 UNI-32141 Задачата трябва да казва, че действието идва от permission и позволява същото или по-малко количество.
US-F20-02Поръчка за дилърски склад Съгласувано РешениеПотвърден допълнителен път за дилърски складFlowFlow 2A и дилърски flow за складова заявка Sales Manager може да създаде заявка без клиент, оферта и капаро. UNI-32140 UNI-32085 Да остане отделен вход към същата approval верига.
US-F21-01Финално дилърско одобрение Частично РешениеDLR-04 и последващото количествено решениеFlowF21 - Dealer Manager решение Dealer Manager потвърждава количество и изпраща към China Motor. UNI-32085 UNI-32142 UNI-32141 Да се премахне hardcoded роля от техническото решение и да се запази permission-based action.
US-F02-01Последователно количествено решение Съгласувано РешениеDLR-04 и изричното решение за пет количествени ниваFlowF02/F20-F22 - пълната последователна верига Пълната верига е показана като количествено решение на всяко ниво до максимума от предходното; няма връщане назад. UNI-32085 UNI-32088 UNI-32142 UNI-32141 Новата story е канонична. Старите конфликтни approval задачи се премахват при миграцията към новия task set.
US-F22-01Решение на China Motor и обратна връзка Съгласувано РешениеDLR-07, DLR-08 и последващото финално решениеFlowF22 - China Motor решение и обратна връзка Network, Product и Brand са отделни количествени нива; финалното Brand решение известява дилъра и прави поръчването достъпно за Product Manager. UNI-32088 UNI-32089 UNI-32143 UNI-32144 Да се пази тази последователност като единствена активна версия във flow, mock и новите задачи.
EP-03 - Таргети, заводски поръчки и производство
US-F01-01Управление и проследяване на цели Съгласувано РешениеFAC-08, FAC-09 и решението таргетът да е само контекстFlowF01 - цели и планиране Таргети по дилъри, доставчици и модели са годишни; месечни и тримесечни периоди са бъдещо разширение. UNI-31955 UNI-32137 Да няма автоматични предложения, ограничения или версии на таргетите.
US-F03-01Консолидиране към доставчик Съгласувано РешениеDLR-08, FAC-06 и FAC-07FlowF03 - консолидиране и заводска поръчка Матрицата по доставчик създава или допълва една активна поръчка към един доставчик; редовете са част от поръчката и няма повторно approval на дилърските количества. UNI-32086 UNI-32088 UNI-32143 UNI-32148 UNI-32149 UNI-32151 Да се запази една дългоживееща поръчка към един доставчик, като редовете са част от самата поръчка.
US-F03-02Каталог, доставчик и ценови контекст Частично РешениеFAC-01 и FAC-02FlowF03 - избор на доставчик Има меню Доставчици/каталог и default доставчик по модел; бизнес валидността на връзката не е напълно показана. UNI-32147 UNI-32214 Да се уточни кой permission управлява допустимите доставчици и от кога промяната важи за нови позиции.
US-F04-01Актуализация на производството от документ Съгласувано РешениеPROD решенията и document-first уточнениетоFlowF04 - производство на ниво автомобил Excel попълва редактируема форма; липсващ VIN/двигател не блокира маркиране като произведен. UNI-31959 UNI-32163 UNI-32164 UNI-32165 UNI-32166 UNI-32170 Да се консолидират припокриващите се задачи под една story и да се запазят идентификаторите отделно.
US-F05-01Обработка на проформи Съгласувано РешениеCON-01, CON-02, CON-03 и CON-05FlowF05 - проформи Много проформи към една поръчка и AI форма за проверка са показани. UNI-32091 UNI-32152 UNI-32153 UNI-32154 UNI-32168 Да се уеднакви терминът Product Manager вместо Buyer и да не се въвежда version workflow.
US-F05-02Индивидуални заводски фактури Конфликт РешениеPROD-06, PROD-07, PROD-08, PROD-09 и последващите уточненияFlowF05 - индивидуални фактури и сравнение Показва пакетно качване и разлика, но трябва да се провери да няма скрит hard gate. UNI-32092 UNI-32167 UNI-32169 UNI-31952 Да се коригира UNI-32092: VIN е опционален, ценовата разлика е видима без tolerance и не блокира потвърждението от оторизиран потребител.
US-F05-03Разпределение на произведени автомобили Конфликт РешениеCON-10, CON-11, CON-12, CON-13 и CON-14FlowFlow 5A - разпределение на произведени автомобили Масова смяна на дилър и payment lock са налични, но част от стария код преизчислява цена/остатъци. UNI-32090 UNI-32157 UNI-32158 UNI-32159 UNI-32160 UNI-32161 UNI-32162 Да се промени само dealer assignment на неплатения автомобил. Фактури, цени, заявки, документи и локация не се преизчисляват.
EP-04 - Международен транспорт и приемане от Тексим
US-F06-01Поръчка за транспорт и оферти Съгласувано РешениеTR-01 и потвърденият transport order процесFlowF06 - поръчка за транспорт и оферти Поръчка се създава от произведени автомобили или от транспортния модул и допуска много оферти. UNI-31958 UNI-32172 UNI-32173 UNI-32174 Да се избере една водеща задача и да се запази email като опционално действие на английски.
US-F06-02Множество доставки по поръчка Съгласувано РешениеTR-04, TR-05, TR-06, TR-08, TR-09 и TR-10FlowF06 - множество доставки под поръчката Добавяне от BL/фактура, много доставки, превозвач, ETA, автомобили и разпределен разход са показани. UNI-32175 UNI-32176 UNI-32177 UNI-32178 UNI-32179 UNI-32180 UNI-32194 Да се запази човешката редакция на AI резултата и точният сбор към фактурата.
US-F07-01ETA, известяване и пристигане Съгласувано РешениеTR-08 и TR-11FlowF07 - ETA, предварително известие и пристигане ETA е на доставка; предварително и arrival известие са отделни, еднократни и могат да се повторят ръчно. UNI-31960 UNI-32178 UNI-32207 Да се потвърди само настройваемият период преди ETA и списъкът получатели.
US-F08-01Вътрешен курс и приемане от Тексим Съгласувано РешениеTX-05, TX-06, TX-08 и последващото решение CMR да се качва при получаванеFlowF08 - пристанище към Безмитен склад Частичното приемане е налично; CMR се качва и архивира при физическото приемане в Тексим. UNI-31962 UNI-32181 UNI-32182 UNI-32184 UNI-32186 Да се пази единствено този вариант в новите stories и задачи; старите CMR варианти се премахват при миграцията.
EP-05 - Хомологация и обмитяване
US-F09-01Обработка на хомологационни документи Съгласувано РешениеПотвърдено разграничение CoC/Удостоверение за индивидуално одобряванеFlowF09 - хомологация Алтернативните пътища и AI документът са показани; начално действията се изпълняват от Back Office и Logistics. UNI-31963 UNI-32183 Правата за преглед и обработка на хомологация са отделни и могат впоследствие да се закачат към всяка роля.
US-F10-01Митническа заявка, калкулация и фактура Съгласувано РешениеWH решенията и финалното уточнение за един блок Калкулация + един блок ФактураFlowF10 - заявка, калкулация и фактура Досието има един блок Калкулация и един блок Фактура и допуска двата потвърдени входа. UNI-31964 UNI-32187 UNI-32194 UNI-31952 Да се пазят двата входа: калкулация -> фактура или директно фактура -> автоматично попълнена калкулация. Само фактурата създава задължение.
US-F10-02Плащане, освобождаване и декларации Частично РешениеWH-04, WH-08 и последващите решения за release и декларацииFlowF10 - плащане, освобождаване и декларации Плащане, частично освобождаване и много декларации са показани; direct submission от агента остава недоказан. UNI-32185 UNI-32188 UNI-32190 UNI-32209 UNI-32293 Да се запази декларацията отделно от освобождаването и soft warning при липса; direct external upload да се потвърди преди реализация.
EP-06 - Back Office, склад, NAV, еко такси и документи
US-F16-01Единна Back Office опашка Съгласувано РешениеWH-01 и решението за паралелна готовностFlowF16 - подготовка за издаване и складово състояние Документи, хомологация, еко такса, обмитяване и плащане са независими показатели и действия; общият gate е предупреждение. UNI-31975 UNI-32293 UNI-32295 Да не се възстановява отделен линеен процес Комплектовай; readiness индикаторите остават независими.
US-F16-02NAV import, export и складова проследимост Съгласувано РешениеПотвърден NAV ID и отделни physical/NAV/destination полетаFlowNAV import/export и складова проследимост NAV ID, inventory no и VIN са отделни; показани са 69-колонен import/export и location history. UNI-31823 UNI-31824 UNI-31984 UNI-31965 UNI-32170 Да се използва предоставеният NAV CSV като contract fixture и да се избегнат три припокриващи се задачи за същия обмен.
US-F17-01Партида за еко такса Съгласувано РешениеBack Office срещата и последващото потвърждениеFlowF17 - еко такси и декларации Партида се създава от автомобилите или специализирания екран; показани са фактура, плащане и декларации. UNI-31978 Да се актуализира задачата по текущия flow и общия AI компонент.
US-F18-01Документен комплект към дилър Съгласувано РешениеBack Office и dealer delivery решениятаFlowF18 - документни комплекти към дилър Комплектите са по дилър/представителство и пазят изпратени, върнати и липсващи позиции. UNI-31979 Да се потвърди финалният checklist, без да се блокира разработката на обекта и връзките.
EP-07 - Вътрешна доставка, приемка, PDI и щети
US-F11-01Подготовка и заявка за вътрешен транспорт Частично РешениеWH-09, WH-04 и решенията за Централен складFlowF11 - заявка към Тексим за дилър/собствен склад Readiness snapshot и двете физически направления са показани; override permissions са още общи. UNI-31966 UNI-32189 UNI-32293 Да се запази soft-warning моделът и да се потвърдят конкретните override permissions.
US-F12-01Частично издаване от Тексим Съгласувано РешениеWH-09 и Texim operational решениятаFlowF12 - частично издаване от Тексим Тексим избира и издава конкретни налични автомобили; остатъкът остава отворен. UNI-31967 UNI-32189 Да се обедини с общата задача за вътрешен транспорт само ако ownership и AC останат ясни.
US-F13-01Приемо-предавателен протокол Съгласувано РешениеDealer receipt и сервизните уточненияFlowF13 - дилърска приемка с протокол Има частична приемка, checklist, снимки и damage case при щета или липса. UNI-31969 UNI-31974 UNI-32189 Да се запази единният приемен процес за нови автомобили без допълнителни полета извън описания checklist.
US-F24-01Оперативна приемка в представителството Съгласувано РешениеDealer operational receipt решениятаFlowF24 - приемане в представителството Доставките, частичната приемка, checklist и снимките са налични. UNI-31974 UNI-32189 Дилърският mock следва AC-F24-03 и не дублира различен приемен процес.
US-F14-01Единно досие на щета Съгласувано РешениеTX-13, WH-10 и последващото permission решениеFlowF14 - щета или несъответствие Единно damage досие, снимки, калкулация и решение са показани с отделни права. UNI-31971 UNI-32191 UNI-30719 Първоначално Back Office, Logistics и After Sales получават нужните права; всяко право може впоследствие да се закачи към друга роля.
US-F14-02Dealer PDI и фактуриране към China Motor Отворено РешениеПотвърден бизнес поток; отворена интеграция със системата за щетиFlowDealer PDI: дилър -> After Sales -> фактура към China Motor Dealer PDI е отделен от Texim PDI, но оперативният процес вече живее в системата за щети; CRM интеграцията не е решена. UNI-31976 UNI-32294 UNI-32192 UNI-32193 Ръководството да определи източника на истина, обменяните статуси и документи, връзката с автомобила и поведението при разминаване; след това да се актуализира обхватът на задачите.
EP-08 - Финанси, известия и управленски dashboard
US-F23-01Финансов списък на дилъра Частично РешениеДилърският финансов flow и dashboard решениятаFlowF23 - фактури за плащане, просрочени и платени Dealer portal показва финансови статуси и документи, но няма една ясно водеща Sprint 2 задача за целия списък. UNI-31972 UNI-32167 UNI-32193 Да се отдели дилърският read-only финансов списък от вътрешната Finance обработка.
US-F23-02Платежно и потвърждение на плащане Съгласувано РешениеFIN-02 и потвърденият общ модел за отразяване на плащанеFlowF23 и общият финансов модел Платежен документ или ръчно въведени полета попълват една редактируема форма; потвърждението задава статуса Платена. UNI-32209 UNI-32193 UNI-31961 Бъдещи NAV, import или други източници попълват същата форма и не създават паралелен платежен модел.
US-F15-01Автоматични и ръчни известия Отворено РешениеTR-11, TX-01 и общите комуникационни решенияFlowF15 - автоматични известия и история Статус, история и повторно изпращане са показани; финалните получатели/канали не са потвърдени за всички събития. UNI-31973 UNI-32207 UNI-32296 UNI-32296 съдържа пълната предложена notification matrix за бизнес одобрение; опционалният email никога не блокира бизнес действието.
US-F15-02Dashboard по активна компания и роля Съгласувано РешениеCTX-05 и потвърдените dashboard решенияFlowРолеви работни опашки и KPI Запазен е одобреният интерактивен dashboard с YTD период, месечни графики, role switch и drill-down. UNI-32137 UNI-32229 UNI-32110 Да не се редизайнира концепцията; да се коригират само дефинициите, данните и доказаните frontend бъгове.
EP-01

Организация, достъп и общи правила

6 user stories

Статус: For business validation Business owner: China Motor Admin / Product owner

Цел

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

Обхват

  • много компании, роли и представителства за един потребител;
  • активен работен контекст и ограничаване на данните;
  • permission + допустим статус за всяко действие;
  • единни таблици, филтри, селекция и масови действия;
  • единен AI процес за входящи документи;
  • audit история и проследимост.

Основни обекти

IMPORTER, DEALER, REPRESENTATION, USER, USER_ACCESS, DOCUMENT, DOCUMENT_EXTRACTION, AUDIT_EVENT.

Общи Acceptance Criteria

Тези критерии се прилагат към всяка story, освен когато конкретна story изрично дефинира по-строго правило.

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

Story register

Story Заглавие Статус
US-F00-01 Достъп до много компании и роли For business validation
US-F00-02 Разрешаване на действие по permission и статус For business validation
US-F00-03 Контекстно меню и обхват на данните For business validation
US-F00-04 Единни таблици и масови действия For business validation
US-F00-05 AI обработка на входящ документ For business validation
US-F00-06 История на бизнес действията For business validation

US-F00-01Достъп до много компании и роли

User story: Като администратор искам да добавям на един потребител няколко назначения Компания + Роля + Представителство, за да работи в разрешените организационни контексти с един профил.

Описание: Назначението е самостоятелен запис. Ролята не определя сама достъпа до данни; company scope и representation scope са част от назначението. Един потребител може да има повече от една роля в една компания.

Полета

Поле Значение Източник Задължителност / редакция
USER_ACCESS.user_id Потребител Съществуващ потребител Да; Admin
USER_ACCESS.company_id Вносител или дилър Номенклатура компании Да; Admin
USER_ACCESS.role_id Начален набор permissions Номенклатура роли Да; Admin
USER_ACCESS.representation_ids Разрешени представителства Според избраната компания Условно; за Sales/Sales Manager
USER_ACCESS.status Активно/неактивно назначение Admin Да

Взаимовръзки

  • USER 1:N USER_ACCESS; деактивиране на назначение не деактивира потребителя.
  • USER_ACCESS N:1 COMPANY; компанията ограничава достъпните данни.
  • USER_ACCESS N:M REPRESENTATION; представителствата трябва да принадлежат на избрания дилър.

Acceptance Criteria

  • AC-F00-01-01 Един потребител може да има повече от едно активно назначение, включително повече от една роля в една компания.
  • AC-F00-01-02 Представителство може да се избира само когато принадлежи на избраната дилърска компания.
  • AC-F00-01-03 Дублирана идентична комбинация не се записва втори път.
  • AC-F00-01-04 Промяната на назначенията влиза в сила без промяна на историческите автори на действия.
  • AC-F00-01-05 Всяка промяна пази автор, момент и стойности преди/след.

US-F00-02Разрешаване на действие по permission и статус

User story: Като собственик на процес искам действията да се управляват от конкретни permissions и допустими статуси, за да можем да променяме ролевите профили без hardcoded бизнес логика.

Полета и връзки

Поле/обект Значение Правило
ROLE.permissions Начален набор разрешения Може да се конфигурира
USER_ACCESS Активен company/role scope Проверява се за всяко действие
business_object.status Текущ процесен статус Действието има списък допустими статуси
override_reason Основание при soft warning Условно според действието

Acceptance Criteria

  • AC-F00-02-01 Действие се изпълнява само при едновременно валидни permission, organizational scope и текущ статус.
  • AC-F00-02-02 Името на ролята не участва като самостоятелно hardcoded условие.
  • AC-F00-02-03 Скриването на бутон не замества server-side проверката на правото.
  • AC-F00-02-04 Soft warning позволява продължаване само с необходимото override permission и записва основанието.
  • AC-F00-02-05 Hard gate се прилага само когато е изрично потвърден в конкретна story.

US-F00-03Контекстно меню и обхват на данните

User story: Като потребител с няколко назначения искам от профила да сменям компанията и ролята си, за да виждам само приложимите менюта, данни и действия.

Полета и връзки

Поле Значение Правило
active_access_id Активно назначение Едно в рамките на сесията
company_scope Разрешена компания Derived от назначението
representation_scope Разрешени представителства Derived от назначението
navigation_items Видими модули Derived от permissions, не от статичен role name

Acceptance Criteria

  • AC-F00-03-01 Switcher-ът показва само активните назначения на потребителя.
  • AC-F00-03-02 Смяната на контекст обновява меню, dashboard, данни и действия без смесване между компаниите.
  • AC-F00-03-03 Директен URL не дава достъп до модул или запис извън активния scope.
  • AC-F00-03-04 Вносителските роли виждат вносителския scope, а дилърските роли - само своя дилър и разрешените представителства.

US-F00-04Единни таблици и масови действия

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

Полета и връзки

Обект Значение Правило
Колонни филтри Филтър върху конкретно поле/relation Комбинират се с AND
Selection set Избраните record IDs Отделно от текущата страница
Bulk action Действие върху selection set Derived от permission и статусите
Result summary Успешни/пропуснати/грешни По конкретен запис и причина

Acceptance Criteria

  • AC-F00-04-01 Таблиците поддържат отделни филтруеми колони за свързаните обекти, без общо поле Връзки.
  • AC-F00-04-02 Налични са избор на ред, Shift избор, текуща страница и всички филтрирани резултати.
  • AC-F00-04-03 Контекстната лента е една, показва се при селекция и не дублира контролите за избор.
  • AC-F00-04-04 При смесени статуси системата обработва допустимите редове и показва останалите с точна причина.
  • AC-F00-04-05 При поне 200 записа филтрите, пагинацията и изборът на всички филтрирани пазят точен selection set.

US-F00-05AI обработка на входящ документ

User story: Като потребител искам документът да попълни крайната работна форма, за да валидирам данните вместо да ги преписвам.

Полета

Поле Значение Правило
DOCUMENT.type, file Вид и оригинален файл Файлът се пази без промяна
DOCUMENT.status Качен/разчетен/за проверка/потвърден/неуспешен Не променя бизнес статус самостоятелно
DOCUMENT_EXTRACTION.source_value Разчетен първоизточник Не се губи при корекция
normalized_value Предложена стойност Попълва директно крайната форма
confidence, validation_result Несигурност и сравнение Информация за човешкото решение

Взаимовръзки

  • DOCUMENT N:M BUSINESS_OBJECT чрез DOCUMENT_RELATION; един файл може да е свързан с поръчка, автомобил, доставка, фактура или друг приложим обект.
  • DOCUMENT 1:N DOCUMENT_EXTRACTION; оригинално разчетената стойност се пази отделно от потвърдената стойност във формата.
  • Потвърждението актуализира свързания бизнес обект; самото AI разчитане не променя неговия статус.

Acceptance Criteria

  • AC-F00-05-01 Процесът е Качване -> четене -> попълнена форма -> човешка проверка -> потвърждение.
  • AC-F00-05-02 Потребителят може да коригира, добавя и премахва стойности преди запис.
  • AC-F00-05-03 Неразчетена стойност остава празна и видимо маркирана; системата не измисля данни.
  • AC-F00-05-04 Кратък progress/status компонент показва четене, резултат и нужда от проверка.
  • AC-F00-05-05 Бизнес статус се променя само след човешко потвърждение.
  • AC-F00-05-06 Повторното качване не създава скрит дублиран бизнес документ.

US-F00-06История на бизнес действията

User story: Като контролна роля искам да виждам кой, кога и как е променил бизнес обект, за да проследя решенията без version workflow върху самия процес.

Полета

Поле Значение Задължителност
AUDIT_EVENT.actor_id Извършил действието Да
action, object_type, object_id Какво и върху кой обект Да
timestamp Момент Да
before, after Променени бизнес стойности При редакция
reason Основание При override, отказ, преразпределение

Взаимовръзки

  • BUSINESS_OBJECT 1:N AUDIT_EVENT; всеки проследим обект има хронологична история.
  • USER 1:N AUDIT_EVENT; промяна или деактивиране на потребителя не изменя вече записаните събития.
  • Повторното действие създава ново AUDIT_EVENT, вместо да презаписва предходното.

Acceptance Criteria

  • AC-F00-06-01 Одобрение, отказ, override, изпращане, плащане, разпределение и статусна промяна създават audit event.
  • AC-F00-06-02 Историята се показва хронологично в контекста на бизнес обекта.
  • AC-F00-06-03 Исторически запис не се променя при преименуване или деактивиране на потребител.
  • AC-F00-06-04 Добавянето на нови позиции към активна заводска поръчка се логва, без да изисква версия на цялата поръчка.

Отворени решения за EP-01

  1. Финалната начална permission матрица по роли.
  2. Кои действия изискват специално override permission.
  3. Езиците на българския портал при production старт.

Traceability

EP-02

Дилърски продажби, търсене и одобрение

6 user stories

Статус: For business validation Business owner: Dealer network / Sales

Цел

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

Основни обекти

CONTACT, CLIENT, OFFER, CLIENT_ORDER, DEPOSIT, DEALER_REQUEST, DEALER_REQUEST_LINE, APPROVAL_DECISION.

Story register

Story Заглавие Статус
US-F19-01 Клиентска поръчка и заявка към вносителя For business validation
US-F20-01 Одобрение на заявка от Sales Manager For business validation
US-F20-02 Поръчка за дилърски склад For business validation
US-F21-01 Финално дилърско одобрение For business validation
US-F02-01 Последователно количествено решение For business validation
US-F22-01 Решение на China Motor и обратна връзка For business validation

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

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

Описание: Търговецът първо търси автомобил по марка и модел сред наличностите на дилъра и China Motor. Ако няма подходящ автомобил, използва конфигуратор. Клиентската оферта и цена остават snapshot и са отделни от дилърската цена към вносителя.

Основни полета

Поле Значение Източник Задължителност / редакция
OFFER.client_id Физическо/юридическо лице Избран клиент Да; Sales
OFFER.configuration Марка, модел, модификация, екстериор, интериор Наличност или конфигуратор Да до приемане
OFFER.vehicle_id Конкретен наличен автомобил Наличност Условно
OFFER.price_snapshot Клиентска цена Активна ценова листа + разрешени корекции Да; не се auto-update-ва
CLIENT_ORDER.deposit Капаро и платежни данни Потребител/документ Според търговския процес
DEALER_REQUEST_LINE.requested_qty Заявено количество Клиентска поръчка Да; положително цяло
DEALER_REQUEST.representation_id Представителство Активен scope Да

Взаимовръзки

  • OFFER 1:0..1 CLIENT_ORDER; само приета оферта може да стане клиентска поръчка.
  • CLIENT_ORDER 1:0..N DEALER_REQUEST; soft delete на заявка не променя клиентската поръчка.
  • DEALER_REQUEST 1:N DEALER_REQUEST_LINE; редът пази конфигурацията и количеството.
  • Наличен автомобил може да се резервира; неналична конфигурация създава търсене, не фиктивен автомобил.

Acceptance Criteria

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

US-F20-01Одобрение на заявка от Sales Manager

User story: Като потребител с право Одобрение като Sales Manager искам да потвърдя същото или по-малко количество, за да предам заявката към Dealer Manager.

Основни полета и връзки

Поле Значение Правило
APPROVAL_DECISION.stage sales_manager Едно активно решение на етап
input_qty Количество от заявката Read-only изходна стойност
approved_qty Решение на етапа 0..input_qty
comment Основание за решението По избор; препоръчително при намаление

Acceptance Criteria

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

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

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

Основни полета и връзки

Поле Значение Правило
DEALER_REQUEST.purpose Дилърски склад Не е клиентска заявка
representation_id Получаващо представителство В разрешения scope
configuration Модел, модификация, цветове Да
requested_qty Заявени бройки Положително цяло
created_by Заявител Audit

Acceptance Criteria

  • AC-F20-07 Поръчката за дилърски склад не изисква клиентска оферта, клиентска поръчка или капаро.
  • AC-F20-08 Поръчката за склад съдържа модел/конфигурация, количество, предназначение, представителство и заявител и започва от Чака Dealer Manager.
  • AC-F20-09 След създаване поръчката за склад следва същите China Motor approval и procurement правила като клиентското търсене.

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

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

Основни полета и връзки

Поле Значение Правило
APPROVAL_DECISION.stage Dealer Manager ниво Едно активно решение за етапа
input_qty Количество от Sales Manager Read-only вход
approved_qty Потвърдено дилърско количество Цяло число от нула до input_qty
comment Основание за решението По избор; препоръчително при намаление
decided_by, decided_at Автор и момент Неизменим audit факт
  • DEALER_REQUEST 1:N APPROVAL_DECISION; решението се добавя към съществуващата заявка.
  • Одобрението променя опашката и статуса на същата DEALER_REQUEST, без да създава дубликат при China Motor.
  • DEALER_REQUEST N:1 DEALER и N:1 REPRESENTATION; организационните връзки се запазват при изпращане.

Acceptance Criteria

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

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

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

Основни полета и връзки

Поле Значение Правило
DEALER_REQUEST_LINE.requested_qty Първоначално заявено количество Не се презаписва от решенията
APPROVAL_DECISION.stage Sales, Dealer, Network, Product или Brand Следва фиксираната бизнес последователност
APPROVAL_DECISION.input_qty Количество от предходното ниво Read-only
APPROVAL_DECISION.qty Решение на текущото ниво Положително цяло, максимум входа
final_approved_qty Финално Brand решение Източник за потвърждението към дилъра
  • DEALER_REQUEST_LINE 1:N APPROVAL_DECISION; историята на всички нива остава видима.
  • Всяко решение сочи непосредствено предходното решение, от което получава максималното допустимо количество.
  • Финалното решение не променя snapshot-а на клиентската оферта или клиентската цена.

Статуси и решения

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

Етап Вход Допустим резултат Следващ етап
Sales Manager Заявено Същото или по-малко Dealer Manager
Dealer Manager Sales решение Същото или по-малко Мениджър търговска мрежа
Мениджър търговска мрежа Dealer решение Същото или по-малко Продуктов мениджър
Продуктов мениджър Network решение Същото или по-малко Бранд мениджър
Бранд мениджър Product решение Същото или по-малко Финално решение

Acceptance Criteria

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

US-F22-01Решение на China Motor и обратна връзка

User story: Като участник от China Motor искам търсенето да мине през network, product и brand решение и финалът да бъде върнат към дилъра.

Основни полета и връзки

Поле Значение Правило
final_approved_qty Решение на Brand Manager Максимум Product Manager решението
factory_ordered_qty Включено в заводски поръчки Derived от DEMAND_SOURCE
allocated_qty Конкретно разпределени автомобили Derived от active allocations
delivered_qty Приети от дилъра автомобили Derived от receipts
remaining_qty Одобрено, но неизпълнено Не се губи при частично поръчване

Acceptance Criteria

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

Отворени решения за EP-02

  1. Точният текст и канал на 90/120-дневните ескалации.
  2. Нужна ли е причина при количествено намаляване и кой получава известието за нея.

Traceability

EP-03

Таргети, заводски поръчки и производство

7 user stories

Статус: For business validation Business owner: Product management / Brand management

Цел

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

Основни обекти

TARGET_PLAN, SUPPLIER, BRAND, MODEL, MODIFICATION, FACTORY_ORDER, FACTORY_ORDER_LINE, DEMAND_SOURCE, VEHICLE, VEHICLE_ALLOCATION, DOCUMENT, INVOICE, PAYMENT.

Story register

Story Заглавие Статус
US-F01-01 Управление и проследяване на цели For business validation
US-F03-01 Консолидиране към доставчик For business validation
US-F03-02 Каталог, доставчик и ценови контекст For business validation
US-F04-01 Актуализация на производството от документ For business validation
US-F05-01 Обработка на проформи For business validation
US-F05-02 Индивидуални заводски фактури For business validation
US-F05-03 Разпределение на произведени автомобили For business validation

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

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

Полета и връзки

Поле Значение Правило
TARGET_PLAN.type Дилърска или заводска цел Определя приложимите измерения
year Период Годишна цел за текущата версия
supplier_id, brand_id, model_id Заводски scope Условни според типа
dealer_id, representation_id Дилърски scope Условни според типа
target_qty Заявена цел Неотрицателно цяло число
actual_qty Изпълнение Derived от съответните поръчки/приемки

Acceptance Criteria

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

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

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

Основни полета

Поле Значение Източник / правило
FACTORY_ORDER.supplier_id Получател на поръчката Един доставчик за поръчка
FACTORY_ORDER.status Активна/приключена Активната поръчка може да се допълва и редактира
FACTORY_ORDER_LINE.configuration Модел, модификация и цветове Каталог
FACTORY_ORDER_LINE.qty Поръчани бройки Положително цяло
DEMAND_SOURCE.purpose Дилърско търсене/собствен stock/target Да
DEMAND_SOURCE.qty Използвано количество от източника Не надвишава наличния остатък

Взаимовръзки

  • FACTORY_ORDER 1:N FACTORY_ORDER_LINE; всички редове са към същия supplier.
  • FACTORY_ORDER_LINE N:M DEALER_REQUEST_LINE чрез DEMAND_SOURCE.
  • FACTORY_ORDER_LINE 1:N VEHICLE; всяка бройка става отделен автомобилен запис.
  • Една дилърска заявка може да бъде изпълнявана от повече от една заводска поръчка.

Acceptance Criteria

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

US-F03-02Каталог, доставчик и ценови контекст

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

Полета и връзки

Поле Значение Правило
MODEL.brand_id Марка Една марка има много модели
MODIFICATION.model_id Модификация Основа за цени и конфигурация
MODEL_SUPPLIER.supplier_id Допустим доставчик Редактируем с permission
PRICE_SET.channel Клиентска/дилърска/доставна цена Стойностите не се презаписват взаимно
catalog_item.hidden Оперативно скрит запис Историческите relations остават

Acceptance Criteria

  • AC-F03-08 Потребител с permission може да добавя и редактира допустим доставчик за модел.
  • AC-F03-09 Скрит каталогов запис не участва в нов избор, но остава видим чрез Покажи скрити и пази историческите връзки.
  • AC-F03-10 Клиентска, дилърска и доставна цена са отделни стойности.
  • AC-F03-11 Промяна на ценова листа не изменя автоматично snapshot-а на вече издадена оферта или поръчка.

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

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

Основни полета и връзки

Поле Значение Източник / редакция
VEHICLE.factory_order_line_id Поръчаният ред Съпоставяне по поръчка/конфигурация
production_status Поръчана/в производство/произведена Документ + човек
vin, engine_no Заводски идентификатори Може временно да липсват
production_date Реално производство Документ; редактируемо преди потвърждение
configuration Модел, модификация, цветове Сравнява се с поръчания ред

Acceptance Criteria

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

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

User story: Като Продуктов мениджър искам да качвам една или повече проформи към заводска поръчка и да валидирам разчетените позиции.

Полета и връзки

Поле Значение Правило
DOCUMENT.type Factory pro forma Много към една заводска поръчка
number, date, currency, amount Заглавни данни AI + редакция + потвърждение
PROFORMA_LINE.configuration, qty, unit_price Разчетени позиции Съпоставят се със заводски редове
DOCUMENT.status За проверка/потвърдена Не е финансово плащане

Acceptance Criteria

  • AC-F05-01 Една заводска поръчка може да има множество проформи; потребител с permission може да добавя и премахва проформи.
  • AC-F05-02 Качената проформа попълва редактируема форма с позиции, количества и цени.

US-F05-02Индивидуални заводски фактури

User story: Като Продуктов мениджър искам пакетно да кача индивидуални фактури и да сравня фактурната цена с проформата по автомобил.

Основни полета и връзки

Поле Значение Правило
INVOICE.number, date, currency Индивидуална фактура Уникалност за издател + номер
INVOICE_LINE.vehicle_id Конкретен автомобил При еднозначно съпоставяне
INVOICE_LINE.amount Реална фактурна цена Сравнява се с pro forma
validation_result Съвпада/разлика/нееднозначно Индикация без tolerance gate
PAYMENT.document_id, amount, date, reference Потвърдено плащане От разчетен платежен документ или ръчно попълнени полета; NAV/import може да е бъдещ източник

Acceptance Criteria

  • AC-F05-03 Индивидуалните фактури могат да бъдат качени пакетно и се свързват с конкретни автомобили, когато съпоставянето е възможно.
  • AC-F05-04 Системата сравнява проформа и фактура и показва всяка ценова разлика.
  • AC-F05-05 Няма автоматичен толеранс или блокировка при ценова разлика; потребителят вижда и потвърждава стойността.
  • AC-F05-06 Фактура без VIN остава във формата за допълване и може да бъде потвърдена без измислен VIN.
  • AC-F05-07 Плащането се потвърждава чрез една редактируема форма, попълнена от платежен документ или ръчно; потвърждението задава Платена за покритите документи и автомобили.

US-F05-03Разпределение на произведени автомобили

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

Основни полета и връзки

Поле Значение Правило
VEHICLE_ALLOCATION.vehicle_id Конкретен автомобил Един активен allocation
dealer_request_line_id Изпълнявана заявка Пази историята на търсенето
dealer_id, representation_id Получател Редактируеми до плащане
allocated_at, allocated_by Решение Audit
VEHICLE.payment_status Заключване на allocation Платен = не може да се преразпределя

Acceptance Criteria

  • AC-F05-08 Неплатен автомобил може да бъде преразпределян; след плащане разпределението към дилър се заключва.
  • AC-F05-09 Разпределението показва одобрено, вече разпределено и оставащо количество по заявка.
  • AC-F05-10 Само произведени и неразпределени автомобили са налични за ново разпределение.
  • AC-F05-11 Неплатен автомобил може да бъде преразпределен независимо от логистичния статус.
  • AC-F05-12 Преразпределението сменя дилъра, без да променя фактури, документи, цени или физическа локация.
  • AC-F05-13 Новият дилър получава известие, че автомобилът може да се забави по логистични причини.

Отворени решения за EP-03

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

Traceability

EP-04

Международен транспорт и приемане от Тексим

4 user stories

Статус: For business validation Business owner: Logistics

Цел

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

Основни обекти

TRANSPORT_ORDER, TRANSPORT_RFQ, DELIVERY, DELIVERY_VEHICLE, CARRIER, DOCUMENT, INVOICE, LOCATION, VEHICLE_MOVEMENT, TEXIM_RECEIPT, PDI_TEXIM, NOTIFICATION_EVENT.

Story register

Story Заглавие Статус
US-F06-01 Поръчка за транспорт и оферти For business validation
US-F06-02 Множество доставки по поръчка For business validation
US-F07-01 ETA, известяване и пристигане For business validation
US-F08-01 Вътрешен курс и приемане от Тексим For business validation

US-F06-01Поръчка за транспорт и оферти

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

Основни полета и връзки

Поле Значение Правило
TRANSPORT_ORDER.vehicle_ids Обхват автомобили Само произведени и свободни за транспорт
TRANSPORT_RFQ.carrier_id Транспортна фирма Relation към контрагент с контактни данни
route, expected_price, expected_dates Параметри на офертата От/до, очаквана цена и период
email_to, email_body Комуникация Опционална; текстът е на английски
TRANSPORT_RFQ.status Draft/изпратена/предложена/приета/отказана Офертите не се презаписват

Acceptance Criteria

  • AC-F06-10 От списъка с произведени автомобили могат да се изберат текуща страница или всички филтрирани.
  • AC-F06-11 Поръчката пази конкретните автомобили и източниците им.
  • AC-F06-12 Една поръчка може да има много RFQ към различни транспортни фирми.
  • AC-F06-13 Създаването на RFQ и изпращането по email са отделни действия.
  • AC-F06-14 Избраната транспортна фирма е relation, а не свободен текст, когато съществува в номенклатурата.
  • AC-F06-15 Добавянето на първата доставка приема избраната оферта, без отделен задължителен wizard.

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

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

Основни полета

Поле Значение Източник / редакция
DELIVERY.carrier_id Превозвач на доставката BL/фактура или избор
origin_id, destination_id Тръгва от/пристига в BL; редактируемо преди потвърждение
loading_date, eta Дата товарене и ETA Документ/форма
bl_number, bl_document_id Коносамент AI + потвърждение
invoice_id Транспортна фактура AI + потвърждение
model_capacity Бройки/капацитет по модел Избор във формата
DELIVERY_VEHICLE.transport_cost Разход по автомобил Пропорционално изчислен; редактируем

Взаимовръзки

  • TRANSPORT_ORDER 1:N DELIVERY; отделните доставки имат независими статуси.
  • DELIVERY N:M VEHICLE; конкретните автомобили се виждат преди потвърждение.
  • DELIVERY N:1 CARRIER; различни доставки по една поръчка могат да имат различни превозвачи.
  • DELIVERY 1:0..1 INVOICE; фактурата създава финансово задължение.

Acceptance Criteria

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

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

User story: Като Логистика искам да виждам ETA, да известя Тексим предварително и да маркирам реалното пристигане в BG.

Полета и връзки

Поле Значение Правило
DELIVERY.eta Очаквано пристигане Основна стойност в статус Към BG
actual_arrival_at Реално пристигане Задава събитие Пристигна в BG
NOTIFICATION_EVENT.type Pre-arrival/arrived Автоматично еднократно
resend_of_id Повторно изпращане Ръчно действие с история
VEHICLE.physical_location_id BG пристанище Променя се при потвърдено пристигане

Acceptance Criteria

  • AC-F07-01 Активната доставка показва потвърдено ETA в списъка и детайла.
  • AC-F07-02 Промяна на ETA пази старата и новата стойност.
  • AC-F07-03 Предварителното известие към потребителите на Тексим се изпраща автоматично веднъж според настройваем период.
  • AC-F07-04 Пристигна в BG мести конкретните автомобили на BG пристанище и записва реалния момент.
  • AC-F07-05 При пристигане се изпраща отделно еднократно известие към Тексим.
  • AC-F07-06 И двете известия имат статус, история и ръчно повторение.
  • AC-F07-07 Промяна на ETA след предварително известие не изпраща автоматично второ.

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

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

Основни полета и връзки

Поле Значение Правило
VEHICLE_MOVEMENT.from_location_id BG пристанище Само автомобили на тази локация
to_location_id Безмитен склад Физическа локация
driver, vehicle_registration Вътрешен превоз Данни на курса
TEXIM_RECEIPT.vehicle_ids Реално приети коли Поддържа частична приемка
received_at, received_by Момент и приемащ Затваря транзита по автомобил
cmr_document_id Подписан CMR Качва се при пристигане

Acceptance Criteria

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

Отворени решения за EP-04

  1. Финалните капацитети/коефициенти по модел.
  2. Настройваемият период за предварително известие към Тексим.

Traceability

EP-05

Хомологация и обмитяване

3 user stories

Статус: For business validation Business owner: Back Office / Logistics

Цел

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

Основни обекти

HOMOLOGATION_CASE, CUSTOMS_CASE, CUSTOMS_CALCULATION, CUSTOMS_DECLARATION, DOCUMENT, INVOICE, OBLIGATION, PAYMENT, VEHICLE.

Story register

Story Заглавие Статус
US-F09-01 Обработка на хомологационни документи For business validation
US-F10-01 Митническа заявка, калкулация и фактура For business validation
US-F10-02 Плащане, освобождаване и декларации For business validation

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

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

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

Полета и връзки

Поле Значение Източник / правило
HOMOLOGATION_CASE.vehicle_ids Покрити автомобили Един или много
path CoC / Удостоверение за индивидуално одобряване / друго Според документите
status Нужна/подадена/получена/потвърдена Отделно от логистиката
document_id Финален документ Свързан и с автомобилното досие
owner Отговорна business функция Начално Back Office/Логистика; действията се управляват от отделни permissions

Acceptance Criteria

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

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

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

Основни полета

Поле Значение Източник / редакция
CUSTOMS_CASE.agent_id Митнически агент Номенклатура контрагенти
CUSTOMS_CASE.vehicle_ids Заявени автомобили Редактируема чернова до изпращане
request_document_id Генериран Excel Системен export по договорен шаблон
CUSTOMS_CALCULATION.document_id Отделна калкулация Условно
CUSTOMS_CALCULATION.amount, lines Обща стойност и разбивка Документ или ръчно потвърдени полета
CUSTOMS_CASE.invoice_id Фактура Задължителен финансов документ
INVOICE.amount, currency, due_date Финансови стойности AI + човешко потвърждение
comparison_result Разлики между калкулация и фактура Информация, не автоматична блокировка

Взаимовръзки

  • CUSTOMS_CASE N:M VEHICLE; една заявка съдържа много автомобили.
  • CUSTOMS_CASE 1:0..1 CUSTOMS_CALCULATION; блокът е един, независимо от източника.
  • CUSTOMS_CASE 1:0..1 INVOICE; потвърдената фактура създава едно задължение.
  • Калкулацията не е второ финансово задължение.

Acceptance Criteria

  • AC-F10-01 Логистика създава редактируема митническа чернова от избрани автомобили в Безмитния склад.
  • AC-F10-02 При изпращане системата генерира Excel и записва получателя, момента и изпратените автомобили.
  • AC-F10-03 Досието има отделни блокове Калкулация и Фактура.
  • AC-F10-04 Калкулацията може да бъде попълнена от отделен документ/полета или директно от фактурата, когато тя пристигне първа.
  • AC-F10-05 Когато има отделна калкулация и фактура, системата сравнява сумите и показва разликата.
  • AC-F10-06 Само фактурата създава едно финансово задължение; калкулацията не създава второ задължение.
  • AC-F10-13 Отделна калкулация може да се запази преди фактурата със статус Чака фактура.
  • AC-F10-14 Ако документът съдържа само обща стойност, системата не измисля разбивка по автомобили; потребителят допълва или коригира формата.

US-F10-02Плащане, освобождаване и декларации

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

Основни полета и връзки

Поле Значение Правило
OBLIGATION.status Неплатено/платено/просрочено Derived от фактура и реални плащания
CUSTOMS_CASE.release_status Чака/частично/освободена Отделно от декларациите
released_vehicle_ids Реално освободени коли Частичен резултат
CUSTOMS_DECLARATION.mrn MRN AI + потвърждение
CUSTOMS_DECLARATION.document_id Оригинална декларация Много декларации към едно досие
CUSTOMS_DECLARATION.vehicle_ids Покрити автомобили Един или много

Статусни преходи

Чака отговор -> Чака фактура -> Неплатена -> Платена - чака освобождаване -> Частично освободена/Освободена.

Декларациите са отделен документен статус и могат да пристигнат след освобождаването.

Acceptance Criteria

  • AC-F10-07 Потвърденото плащане променя заявката на Платена - чака освобождаване.
  • AC-F10-08 Освобождаването се потвърждава за конкретни автомобили и може да бъде частично.
  • AC-F10-09 Освобождаването и получаването на митническа декларация са отделни събития.
  • AC-F10-10 Една заявка може да има много декларации, а една декларация може да покрива много автомобили.
  • AC-F10-11 Качената декларация попълва MRN и автомобилите в редактируема AI форма.
  • AC-F10-12 Автомобил без финална декларация може да продължи логистично, но липсата остава видима и дава soft warning при счетоводно завеждане.

Отворени решения за EP-05

  1. Точният Excel шаблон и полета към митническия агент.
  2. Кои permissions позволяват override при липсваща декларация или друг документ.

Traceability

EP-06

Back Office, склад, NAV, еко такси и документи

4 user stories

Статус: For business validation Business owner: Back Office / Finance operations

Цел

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

Основни обекти

VEHICLE, LOCATION, VEHICLE_MOVEMENT, DOCUMENT, DOCUMENT_SET, ECO_BATCH, INVOICE, PAYMENT, NAV_IMPORT, NAV_EXPORT.

Story register

Story Заглавие Статус
US-F16-01 Единна Back Office опашка For business validation
US-F16-02 NAV import, export и складова проследимост For business validation
US-F17-01 Партида за еко такса For business validation
US-F18-01 Документен комплект към дилър For business validation

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

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

Основни полета и връзки

Поле Значение Правило
VEHICLE.document_readiness Налични/липсващи документи Derived от документното досие
homologation_status Приложим път и резултат Relation към case
eco_fee_status Не е започната/в процес/платена/декларация Relation към batch
customs_status Калкулация/фактура/плащане/освобождаване/декларация Relation към customs case
payment_status Платена/неплатена По приложимия финансов контекст
nav_warehouse_id Счетоводен склад Отделно от physical location
final_destination_id Краен получател Дилър/представителство/собствен склад

Acceptance Criteria

  • AC-F16-01 Единната опашка показва отделен резултат по документи, хомологация, еко такса, обмитяване, плащане и NAV завеждане.
  • AC-F16-02 Няма отделен задължителен линейно приключващ статус Комплектоване.
  • AC-F16-03 Досието показва наличните файлове, очакваните документи и възможност за преглед, сваляне и качване според permission.
  • AC-F16-04 При завеждане в Централен склад липсите се показват като конкретни soft warnings и могат да бъдат override-нати с право.
  • AC-F16-13 Операциите могат да се стартират и като масови действия от автомобилния регистър.

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

User story: Като Back Office искам да импортирам и експортирам реалния NAV stock формат и да пазя NAV склада отделно от физическата локация.

Основни полета

Поле Значение Правило
VEHICLE.nav_id Постоянен Navision ID Различен от VIN и inventory number
inventory_no CRM инвентарен номер Отделно филтруемо поле
vin VIN/шаси Не се презаписва като NAV ID
physical_location_id Реално място Само от потвърдено движение/приемка
nav_warehouse_id Счетоводен склад Import/update от NAV или CRM завеждане
final_destination_id Планиран получател Не е текуща локация
NAV_IMPORT.source_file 69-колонен CSV Оригиналът се пази
NAV_EXPORT.filter_snapshot Експортиран набор Само допустимите автомобили

Взаимовръзки

  • Един автомобил има много движения, но една текуща physical location.
  • NAV складът не създава VEHICLE_MOVEMENT.
  • Import редът съпоставя съществуващ автомобил първо по nav_id.

Acceptance Criteria

  • AC-F16-05 Всеки автомобил има отделни NAV ID, инвентарен номер и VIN.
  • AC-F16-06 NAV import съпоставя съществуващ автомобил първо по NAV ID и обновява, вместо да създава дубликат.
  • AC-F16-07 Неразпознат NAV ред остава за човешка проверка.
  • AC-F16-08 NAV склад, физическа локация и крайна дестинация се пазят и филтрират отделно.
  • AC-F16-09 NAV import или export не променя физическата локация.
  • AC-F16-10 Export използва същите 69 колони, ред и разделител като предоставения NAV stock файл.
  • AC-F16-11 От Складова наличност се експортират само автомобили, заведени в Централен склад Чайна Мотор.
  • AC-F16-12 Физически към Централния склад се придвижват само демо автомобили и свободен собствен сток.
  • AC-F16-14 Счетоводното завеждане в Централния склад и физическото преместване остават отделни събития.

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

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

Основни полета и връзки

Поле Значение Правило
ECO_BATCH.provider_id Доставчик на услугата Контрагент
vehicle_ids Автомобили в партидата Един точен selection set
request_document_id Генериран/изпратен списък Пази изпращането
invoice_id Фактура за еко такса AI + потвърждение
payment_id Потвърдено плащане Една редактируема форма, попълнена от платежен документ или ръчно
declaration_documents Индивидуални декларации По една relation към автомобил

Acceptance Criteria

  • AC-F17-01 Еко такса стартира от автомобилите или Back Office екрана със същия selection set.
  • AC-F17-02 Допустимият автомобил има CoC или Удостоверение за индивидуално одобряване.
  • AC-F17-03 Преди изпращане са видими наличният документ и липсите по автомобил.
  • AC-F17-04 Партидата пази точния списък автомобили и изпратената заявка.
  • AC-F17-05 Фактурата попълва редактируема форма със стойност и покрити автомобили.
  • AC-F17-06 Платена се задава след потвърждение на платежната форма; платежният файл е опционален, а бъдещ NAV/import използва същия модел.
  • AC-F17-07 Индивидуалните декларации се свързват с конкретните автомобили.
  • AC-F17-08 Автомобил с отчетена еко такса не влиза повторно в активна партида.

US-F18-01Документен комплект към дилър

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

Основни полета и връзки

Поле Значение Правило
DOCUMENT_SET.dealer_id Получаващ дилър Един за комплект
representation_id Получаващо представителство Един за комплект
vehicle_ids Автомобили Конкретното предаване
DOCUMENT_SET_ITEM.type Вид документ Checklist
status Изискан/генериран/изпратен/върнат/липсва По позиция
document_id Файл Запазва заменените файлове в историята

Acceptance Criteria

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

Отворени решения за EP-06

  1. Приоритетът CRM/Navision при конфликт на NAV склад.
  2. Финалният checklist на документите по вид автомобил и предаване.
  3. Permission-ите за счетоводно завеждане и override на липсите.

Traceability

EP-07

Вътрешна доставка, приемка, PDI и щети

6 user stories

Статус: For business validation Business owner: Logistics / Dealer operations / After Sales

Цел

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

Основни обекти

DEALER_DELIVERY_REQUEST, VEHICLE_MOVEMENT, DEALER_RECEIPT, DOCUMENT_SET, PDI_TEXIM, DEALER_PDI, DAMAGE_CASE, INVOICE.

Story register

Story Заглавие Статус
US-F11-01 Подготовка и заявка за вътрешен транспорт For business validation
US-F12-01 Частично издаване от Тексим For business validation
US-F13-01 Приемо-предавателен протокол For business validation
US-F24-01 Оперативна приемка в представителството For business validation
US-F14-01 Единно досие на щета For business validation
US-F14-02 Dealer PDI и фактуриране към China Motor For business validation

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

User story: Като Логистика искам да избера автомобили, да видя готовността им и да изпратя заявка към Тексим за дилър или Централен склад.

Основни полета и връзки

Поле Значение Правило
DEALER_DELIVERY_REQUEST.vehicle_ids Избрани автомобили Точен selection set
destination_id Дилърско представителство или собствен склад Според предназначението
from_location_id Физическа начална локация Обичайно Безмитен склад/Тексим
readiness_snapshot Документи, хомологация, еко, митници, плащане, NAV Пази видимите предупреждения
override_reason Решение при липси Permission + audit

Acceptance Criteria

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

US-F12-01Частично издаване от Тексим

User story: Като Тексим искам да издам само физически наличните автомобили по заявката, за да изпълня транспорта частично или изцяло.

Основни полета и връзки

Поле Значение Правило
DEALER_DELIVERY_REQUEST.status Заявена/частично изпратена/изпратена/приета Derived от автомобилите
issued_vehicle_ids Издадени при действието Подмножество на оставащите
VEHICLE_MOVEMENT.departed_at Реално тръгване По конкретен автомобил
physical_location_id В транспорт към дилър Не е Приета от дилър
transport_document_id Документ за курса Relation към заявката/движението

Acceptance Criteria

  • AC-F12-01 Тексим вижда само заявки и автомобили в разрешения си operational scope.
  • AC-F12-02 Преди издаване са видими автомобилите, дестинацията и документите.
  • AC-F12-03 Частично издаване оставя останалите автомобили За издаване.
  • AC-F12-04 Издаденият автомобил е Изпратена към дилър, не Приета от дилър.
  • AC-F12-05 Physical location става В транспорт към дилър и движението влиза в историята.
  • AC-F12-06 Автомобил не може да бъде издаден повторно в друга активна заявка.

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

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

Основни полета

Поле Значение Задължителност
DEALER_RECEIPT.vehicle_id Приет автомобил Да; неприет от активната доставка
received_at, received_by Момент и приемащ Да
condition_checklist Оглед Да
photos Доказателства Да
damage_description Щета/липса Условно
protocol_document_id Генериран протокол След потвърждение

Взаимовръзки

  • DEALER_DELIVERY_REQUEST 1:N DEALER_RECEIPT; всяка приемка е за конкретен автомобил от доставката.
  • VEHICLE 1:0..1 DEALER_RECEIPT в рамките на активната доставка; един автомобил не се приема повторно.
  • DEALER_RECEIPT 1:0..1 DAMAGE_CASE; щета или липса създава свързан случай.
  • Един приемо-предавателен протокол съдържа само автомобилите от текущото действие.

Acceptance Criteria

  • AC-F13-01 За приемане са достъпни само изпратени автомобили за текущото представителство.
  • AC-F13-02 Могат да се изберат част или всички автомобили от доставката.
  • AC-F13-03 Приемката записва конкретния автомобил, приемащия потребител и момента на физическото получаване.
  • AC-F13-04 Checklist и снимки са задължителни по приет автомобил.
  • AC-F13-05 При щета или липса описанието е задължително и се създава damage case.
  • AC-F13-06 Протоколът съдържа само автомобилите от текущата приемка.
  • AC-F13-07 Неприетите автомобили остават в доставката.

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

User story: Като дилърски потребител искам да виждам изпратените към моето представителство доставки и остатъка им, за да извърша точна частична или пълна приемка.

Основни полета

Поле Значение Задължителност
DEALER_DELIVERY_REQUEST.id Доставка към представителството Да
route, cmr_document_id, dispatched_at Маршрут, CMR и изпращане Да според доставката
vehicle_ids Изпратени автомобили Да
DEALER_RECEIPT.vehicle_id Автомобил от текущата приемка Да; само неприет
condition_checklist, photos Оглед и доказателства Да по автомобил
damage_description Щета или липса Условно

Взаимовръзки и статуси

  • DEALER_DELIVERY_REQUEST 1:N DEALER_RECEIPT; по един индивидуален резултат на автомобил.
  • Доставка е Частично приета, когато има поне един приет и поне един неприет автомобил.
  • Доставка е Приета, само когато всички изпратени автомобили са приети.
  • Physical location става представителството след индивидуалното потвърждение.

Acceptance Criteria

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

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

User story: Като потребител с право за щети искам единно досие независимо къде е открита щетата, за да проследя доказателства, отговорник и решение.

Основни полета и връзки

Поле Значение Правило
DAMAGE_CASE.vehicle_id Засегнат автомобил Един автомобил може да има много случаи
source_stage, location_id Къде е открита Пристанище/Тексим/издаване/дилър
description, photos Доказателства Да
estimate Калкулация Няма автоматичен срок
responsible_party Отговорна страна Relation/потвърден избор
decision, status Оглед/ремонт/claim/приключване Permission-based

Acceptance Criteria

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

US-F14-02Dealer PDI и фактуриране към China Motor

User story: Като дилър искам да заявя PDI, After Sales да го изпълни, а разходът да бъде фактуриран към China Motor.

Описание: Това е различен процес от допълнителния PDI/оглед на Тексим. Dealer PDI се инициира от дилъра, изпълнява се от After Sales и приключва с фактура за разход към China Motor. Оперативното изпълнение вече е реализирано в отделната система за щети; начинът, по който тя комуникира със CRM, остава за решение от ръководството.

Основни полета и връзки

Поле Значение Правило
Автомобил и дилър Връзка към автомобила и заявителя Трябва да е еднозначна между двете системи
requested_at, requested_by Заявка Дилър с permission
status Заявена/в изпълнение/изпълнена/чака фактура/фактурирана Отделно от Texim PDI
result, completed_by, completed_at Изпълнение After Sales
expense_invoice_id Фактура от дилъра към China Motor Финансов документ
Източник на данните Система за щети или CRM Отворено управленско решение

Acceptance Criteria

  • AC-F14-08 Dealer PDI и Texim PDI са отделни обекти, статуси и документи.
  • AC-F14-09 Dealer PDI се създава от дилър с permission за конкретен автомобил.
  • AC-F14-10 After Sales вижда и изпълнява заявката и записва резултат.
  • AC-F14-11 След изпълнение дилърът може да добави фактура за разход към China Motor.
  • AC-F14-12 Фактурата се насочва към Finance без допълнително бизнес одобрение.
  • AC-F14-13 Резултатът и фактурата са видими в автомобилното досие и финансовия контекст.

Решение за обсъждане с ръководството

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

Отворени решения за EP-07

  1. Точният оперативен checklist за приемката и Texim PDI.
  2. Интеграцията между CRM и системата за щети за дилърски PDI.

Traceability

EP-08

Финанси, известия и управленски dashboard

4 user stories

Статус: For business validation Business owner: Finance / Management

Цел

Да показва реалните задължения и плащания, проследима комуникация и role-specific dashboard данни в един портал.

Основни обекти

INVOICE, OBLIGATION, PAYMENT, NOTIFICATION_EVENT, TARGET_PLAN, оперативните business objects и агрегирани KPI read models.

Story register

Story Заглавие Статус
US-F23-01 Финансов списък на дилъра For business validation
US-F23-02 Платежно и потвърждение на плащане For business validation
US-F15-01 Автоматични и ръчни известия For business validation
US-F15-02 Dashboard по активна компания и роля For business validation

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

User story: Като дилърски потребител с финансов достъп искам да виждам и свалям документите към China Motor по платежен статус.

Основни полета и връзки

Поле Значение Правило
INVOICE.number, type, date Документ Филтруеми полета
due_date Падеж Определя просрочието при липса на плащане
order_id, vehicle_ids Бизнес връзки Отделни relation колони
amount, currency Сума Потвърдени данни
OBLIGATION.status За плащане/просрочена/платена Derived от due date и payments
DOCUMENT.file Оригинал Преглед/сваляне с permission

Acceptance Criteria

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

US-F23-02Платежно и потвърждение на плащане

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

Основни полета и връзки

Поле Значение Правило
PAYMENT.document_id Платежен файл Опционален; при качване се разчита в същата форма
amount, date, reference Данни за плащане От документ или ръчно попълване
supplier_id, invoice_id, vehicle_ids Контекст на плащането Според платимия документ и покритите автомобили
source Източник Документ, ръчно, NAV или импорт
confirmed_at, confirmed_by Потвърждение на формата Задава paid state

Acceptance Criteria

  • AC-F23-07 Потребителят може да качи платежно към конкретен платим документ; AI попълва в редактируема форма дата, сума, референция, доставчик и покритите документи/автомобили.
  • AC-F23-08 Потребителят може да попълни същата форма без файл. След потвърждението задължението и покритите документи/автомобили стават Платени.
  • AC-F23-09 Един документ с минал падеж и потвърдено плащане се показва като Платена, не като Просрочена.
  • AC-F23-12 Плащането е видимо в контекста на фактурата, поръчката и засегнатите автомобили.
  • AC-F23-13 NAV, import или друг бъдещ източник може да попълни същия payment запис, без да въвежда различна бизнес логика за статуса.

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

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

Основни полета и връзки

Поле Значение Правило
NOTIFICATION_EVENT.type Бизнес повод Контролирана номенклатура
object_type, object_id Свързан бизнес обект Задължително
recipient_ids, channel Получатели и канал Derived от scope/настройка
sent_at, status Резултат Видим и повторяем при грешка
resend_of_id Повторение Не презаписва оригинала

Предложена матрица за бизнес одобрение

Събитие Предложени получатели Канал и поведение
Нова клиентска дилърска заявка след одобрена оферта Потребители с право за одобрение като Sales Manager в съответното представителство In-app; email подлежи на одобрение
Решение от Sales Manager Потребители с право за одобрение като Dealer Manager в дилърската компания In-app
Решение от Dealer Manager Потребители с право за одобрение като Мениджър търговска мрежа за съответния вносител In-app
Решение от Мениджър търговска мрежа Потребители с право за продуктово решение за засегнатите марки/доставчици In-app
Предложени количества Потребители с право за финално Brand решение за засегнатите марки In-app
Финално Brand решение Създателят/дилърът и потребителите с право за продуктово изпълнение In-app; дилърското съобщение съдържа заявени и одобрени количества
Неизпълнен остатък на 90 дни Product Manager и Мениджър търговска мрежа в приложимия scope In-app escalation; точният текст се одобрява от бизнеса
Неизпълнен остатък на 120 дни Product Manager, Мениджър търговска мрежа и Brand Manager In-app escalation; точният текст се одобрява от бизнеса
Заявка за транспортна оферта Избраната транспортна фирма Опционален email на английски; липсата на изпращане не блокира заявката
Предварително известие преди ETA Определените приемчици в Тексим Автоматично еднократно; видима история и ръчно повторение
Реално пристигане в BG Определените приемчици в Тексим Автоматично след маркиране на пристигането; видима история и ръчно повторение
Нова митническа заявка Избраният митнически агент; Finance в копие, ако е потвърдено Email с генерирания Excel; получателите подлежат на одобрение
Получена фактура или задължение за плащане Потребители с право за плащане в приложимата компания In-app; email подлежи на одобрение
Получена митническа декларация / освобождаване Back Office и Logistics според permission и scope In-app
Готовност и заявен транспорт към дилър Тексим и получаващият дилър/представителство In-app; email подлежи на одобрение
Смяна на дилър на неплатен автомобил Само новият дилър Съобщение за възможно логистично забавяне; старият дилър не се известява
Щета или резултат от Тексим PDI Потребители с право за преглед/решение по щети In-app
Завършен Dealer PDI и фактура за разход Дилърът за резултата; Finance за фактурата In-app; фактурата не минава през допълнително бизнес одобрение
Наближаващ или просрочен дилърски документ Дилърските финансови потребители според company/representation scope In-app; периодичност и email подлежат на одобрение

Acceptance Criteria

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

US-F15-02Dashboard по активна компания и роля

User story: Като потребител с няколко назначения искам dashboard-ът да се променя според активната компания и роля, за да виждам релевантните KPI, задачи и изключения.

Описание: Запазва се текущият одобрен интерактивен dashboard модел. Не се въвежда нов едностраничен редизайн. По подразбиране периодът е от началото на годината до днес; месечните графики показват движението в периода.

KPI scope

Контекст Основна информация
China Motor Admin Пълен бизнес и оперативен поглед, настройки и всички разрешени действия
CEO Приходи, разходи, дилъри, доставчици, таргети, одобрения и справки без оперативни менюта
Мениджър търговска мрежа Дилърско търсене, таргети, резервирани/доставени автомобили, 90/120-дневни ескалации
Продуктов мениджър Одобрено търсене, заводски поръчки, производство, проформи, фактури, разпределения
Бранд мениджър Финални решения, цели и контрол по марки/доставчици
Back Office Документни липси, хомологация, еко такси, митници, NAV и готовност за издаване
Finance Задължения към заводи/превозвачи/услуги, вземания от дилъри, падежи и плащания
Dealer Manager Целият дилър по представителства, марки, търговци, фуния, таргети и решения
Sales Manager Собствен екип и представителства: контакти, тест драйвове, оферти, резервации, продажби и задачи
Dealer Sales Лични контакти, тест драйвове, оферти, резервации, поръчки, плащания и издавания
After Sales Dealer PDI, щети, ремонти и фактури за разход

Полета и връзки

Поле Значение Правило
active_access_id Company/role context Определя целия dashboard scope
period_start, period_end Аналитичен период Default YTD; потребителят може да го промени
kpi.source_object/status Източник на метриката Дефиниран, не свободна статична стойност
widget.action Drill-down Отваря филтриран специализиран екран
task_queue Работни изключения Най-долу/отделен подробен изглед според текущия дизайн

Acceptance Criteria

  • AC-F15-09 Смяната на company/role context обновява KPI, меню, задачи и drill-down scope.
  • AC-F15-10 Default периодът е 1 януари на текущата година до днес.
  • AC-F15-11 Приходните и разходните графики показват стойности по месеци за избрания период.
  • AC-F15-12 KPI и drill-down използват една и съща дефиниция и набор данни.
  • AC-F15-13 Мениджърските дилърски изгледи могат да се разделят по представителство, марка и търговец според scope.
  • AC-F15-14 China Motor изгледите разграничават приходната страна към дилърите и разходната страна към доставчици, заводи и превозвачи.
  • AC-F15-15 Дилърските и заводските таргети са отделни секции и поддържат drill-down до приложимите модели/дилъри.
  • AC-F15-16 Надвишаването на таргет е видимо, но не стартира автоматично действие и не блокира процес.
  • AC-F15-17 90/120-дневните дилърски заявки са видими като изключения за приложимите China Motor роли.

Отворени решения за EP-08

  1. Финалният списък получатели и канали за всяко автоматично известие.
  2. Финалната начална permission матрица за dashboard widgets и drill-down данни.

Traceability

DATA

Бизнес data model и взаимовръзки

Общи обекти и cardinality

Статус: Работен contract за user stories Актуализирано: 05.09.2026

1. Правила на модела

  • Това е бизнес речник, а не предложение за конкретни DB таблици.
  • Идентификаторите ENTITY.field се използват във всички epic документи.
  • Екранно поле може да бъде derived от няколко бизнес полета, но не ги заменя в модела.
  • Свързаните обекти се пазят като отделни отношения, за да могат да се филтрират, отчитат и одитират.
  • Soft delete не премахва историческите връзки.
  • Физическа локация, NAV склад и Крайна дестинация са независими.
  • NAV ID, инвентарен номер, VIN и номер на двигател са различни идентификатори.
  • Документ, фактура, задължение и плащане са различни обекти.

2. Организации и достъп

IMPORTER - Вносител

Поле Значение Правило
IMPORTER.id Постоянен идентификатор Не се преизползва
IMPORTER.name Юридическо/оперативно име Видимо в company switcher
IMPORTER.country Държава на вносителя България или Сърбия при текущия обхват
IMPORTER.default_language Език по подразбиране Подлежи на board validation
IMPORTER.active Достъпен за нови операции Деактивирането не трие история

DEALER - Дилърско дружество

Поле Значение Правило
DEALER.id Постоянен идентификатор Използва се във всички дилърски отношения
DEALER.importer_id Вносителят, към който принадлежи Един дилър принадлежи на един вносител
DEALER.name Име на дилъра Отделно от представителството
DEALER.legal_data Данни за договори и фактури Видими според финансово право
DEALER.active Достъпен за нови операции Историческите записи се пазят

REPRESENTATION - Представителство

Поле Значение Правило
REPRESENTATION.id Постоянен идентификатор
REPRESENTATION.dealer_id Собственик дилър Точно един
REPRESENTATION.importer_id Контекст на вносителя Точно един; трябва да съответства на дилъра
REPRESENTATION.name Търговско име/локация Използва се за scope и справки
REPRESENTATION.physical_location_id Физически обект Може да липсва за нефизическо звено
REPRESENTATION.active Достъпно за нови назначения

USER_ACCESS - Назначение на потребител

Поле Значение Правило
USER_ACCESS.user_id Потребител Един потребител има много назначения
USER_ACCESS.company_type Вносител или дилър Определя company context
USER_ACCESS.company_id Конкретна компания Задължително
USER_ACCESS.role_id Пакет от permissions Един от много възможни за потребителя
USER_ACCESS.representation_ids Разрешени представителства Условно за Sales/Sales Manager scope
USER_ACCESS.active Активно назначение Не трие audit история

3. Каталог и цени

SUPPLIER / BRAND / MODEL / MODIFICATION

Поле Значение Правило
SUPPLIER.id, SUPPLIER.name Производител/доставчик Една заводска поръчка има един доставчик
SUPPLIER.active Допустим за нови поръчки Деактивиране без загуба на история
BRAND.id, BRAND.name Търговска марка Може да има различен supplier
MODEL.id, MODEL.name Модел автомобил Свързан с една марка
MODEL.default_supplier_id Предложен доставчик Може да се коригира с право
MODEL_SUPPLIER.model_id, supplier_id Допустима връзка модел-доставчик Много доставчици са възможни; заводската поръчка избира един
MODEL.transport_capacity Капацитет/коефициент за транспорт Финалните стойности се предоставят от бизнеса
MODIFICATION.id, MODIFICATION.name Техническа/ценова модификация Източник на базова клиентска цена
MODIFICATION.hidden Скрито от нови избори Покажи скрити го показва; историческите връзки се пазят

PRICE_SET - Ценови пакет

Поле Значение Правило
PRICE_SET.modification_id Модификация Една активна стойност за период/контекст
PRICE_SET.purchase_price Доставна цена Ограничена финансова видимост
PRICE_SET.list_price Листова цена
PRICE_SET.recommended_price Препоръчителна цена
PRICE_SET.minimum_price Минимална цена Използва се за approval rule
PRICE_SET.partner_price Партньорска цена
PRICE_SET.b2b_price B2B цена
PRICE_SET.currency Валута Не се предполага от документа
PRICE_SET.valid_from Начало на приложимост Не преизчислява историческа оферта

4. Клиент, оферта и дилърско търсене

CONTACT / CLIENT / OFFER / CLIENT_ORDER / DEPOSIT

Поле Значение Правило
CONTACT.id Потенциален клиент/контакт В dealer scope
CLIENT.id, CLIENT.type Физическо или юридическо лице Отделен бизнес обект
OFFER.id Клиентска оферта Snapshot на конфигурация и цена
OFFER.sales_user_id Търговец Определя личен/екипен scope
OFFER.model_id, OFFER.modification_id Избран автомобил
OFFER.exterior_color_id, OFFER.interior_color_id Цветова конфигурация Пазят се отделно
OFFER.price_snapshot Договорена клиентска цена Не се променя автоматично от нов price set
OFFER.status Работна, изпратена, приета, отказана Само приета оферта стартира клиентска поръчка
CLIENT_ORDER.id Поръчка/резервация от клиент Не се изтрива при soft delete на дилърска заявка
CLIENT_ORDER.offer_id, CLIENT_ORDER.client_id Източник и клиент Задължителни за клиентския път
DEPOSIT.amount, DEPOSIT.currency, DEPOSIT.date Капаро Gate според окончателното board решение
DEPOSIT.document_id Документ за капаро Отделен relation към document

DEALER_REQUEST / DEALER_REQUEST_LINE / APPROVAL_DECISION

Поле Значение Правило
DEALER_REQUEST.id Заявка от дилър към вносител Може да е клиентска или за дилърски склад
DEALER_REQUEST.importer_id, DEALER_REQUEST.dealer_id Страни Задължителни
DEALER_REQUEST.representation_id Представителство Задължително в дилърския scope
DEALER_REQUEST.purpose Клиент / дилърски склад Не се променя мълчаливо
DEALER_REQUEST.client_order_id Клиентски източник Задължително само за клиентска заявка
DEALER_REQUEST.status Текущ approval/fulfilment статус Следва разрешените преходи
DEALER_REQUEST_LINE.configuration Модел, модификация и цветове Snapshot на заявеното
DEALER_REQUEST_LINE.requested_qty Първоначално количество Не се презаписва от решенията
DEALER_REQUEST_LINE.final_approved_qty Финално количество Решение на Brand Manager
DEALER_REQUEST_LINE.factory_ordered_qty Включено в заводски поръчки Derived от source allocations
DEALER_REQUEST_LINE.allocated_qty Разпределени конкретни автомобили Derived
DEALER_REQUEST_LINE.delivered_qty Приети от дилъра автомобили Derived от dealer receipts
APPROVAL_DECISION.stage Ниво на решението Sales, Dealer, Network, Product, Brand
APPROVAL_DECISION.qty Потвърдено количество Не надвишава предходното
APPROVAL_DECISION.actor_id, APPROVAL_DECISION.decided_at Кой и кога Неизменим audit факт

5. Заводски поръчки и автомобили

FACTORY_ORDER / FACTORY_ORDER_LINE / DEMAND_SOURCE

Поле Значение Правило
FACTORY_ORDER.id, FACTORY_ORDER.number Заводска поръчка Постоянен идентификатор/номер
FACTORY_ORDER.importer_id Поръчващ вносител Задължително
FACTORY_ORDER.supplier_id Един доставчик Не допуска смесени позиции
FACTORY_ORDER.status Активна, приключена/архивирана Може да остава активна и да се допълва дълго време
FACTORY_ORDER_LINE.configuration Модел, модификация, цветове
FACTORY_ORDER_LINE.qty Количество в реда Сумата на източниците и собствен stock
DEMAND_SOURCE.factory_line_id Заводски ред
DEMAND_SOURCE.dealer_request_line_id Дилърски източник Условно; липсва за собствен stock/target
DEMAND_SOURCE.purpose Дилърско търсене / собствен stock / target Задължително
DEMAND_SOURCE.qty Количество от източника Не надвишава одобрения остатък

VEHICLE / VEHICLE_ALLOCATION

Поле Значение Правило
VEHICLE.id Вътрешен постоянен идентификатор Не е видимият инвентарен номер
VEHICLE.inventory_no CRM инвентарен номер Различен от NAV ID
VEHICLE.nav_id Постоянен идентификатор за Navision Основен ключ при NAV update
VEHICLE.vin VIN/шаси Може временно да липсва; видима липса
VEHICLE.engine_no Номер на двигател Може временно да липсва
VEHICLE.factory_order_line_id Произход от заводската поръчка Задължително за поръчан автомобил
VEHICLE.configuration Модел, модификация, цветове Не се извлича от свободен текст при relation наличност
VEHICLE.production_status Поръчан / производство / произведен Отделно от логистичен статус
VEHICLE.logistics_status Текуща фаза на движение Отделно от търговски статус
VEHICLE.commercial_status Свободен / резервиран / капариран / продаден Не е логистична стъпка
VEHICLE.payment_status Платен/неплатен в приложимия контекст Определя заключване на дилърското разпределение
VEHICLE.physical_location_id Реално физическо място Променя се само от потвърдено движение
VEHICLE.nav_warehouse_id Счетоводен склад Не мести автомобила физически
VEHICLE.final_destination_id Дилър/представителство/склад Може да се различава от текущата локация
VEHICLE_ALLOCATION.vehicle_id Конкретен автомобил Един активен allocation
VEHICLE_ALLOCATION.dealer_request_line_id Заявката, която изпълнява Пази traceability
VEHICLE_ALLOCATION.dealer_id, representation_id Текущ получател Променя се само докато автомобилът е неплатен
VEHICLE_ALLOCATION.allocated_at, allocated_by Кой и кога Audit

6. Документи и AI обработка

DOCUMENT / DOCUMENT_EXTRACTION

Поле Значение Правило
DOCUMENT.id Документно досие Един файл може да има много business relations
DOCUMENT.type Проформа, фактура, BL, CMR, декларация, CoC/УИО и др. Контролирано поле
DOCUMENT.file Оригинален файл Не се замества от разчетените данни
DOCUMENT.issuer_id, counterparty_id Издател/контрагент Relation или изрично неразпознат
DOCUMENT.number, date, currency, amount Общи документни данни Попълват се от AI и се потвърждават
DOCUMENT.status Качен / разчетен / за проверка / потвърден / неуспешен Статусът не променя автоматично бизнес обекта
DOCUMENT_RELATION.object_type, object_id Поръчка, автомобил, доставка, invoice и др. Отделна relation за всеки обект
DOCUMENT_EXTRACTION.source_value Оригинално прочетен текст Пази доказателство
DOCUMENT_EXTRACTION.normalized_value Предложена структурирана стойност Редактируема преди потвърждение
DOCUMENT_EXTRACTION.confidence Увереност Индикация, не автоматично бизнес решение
DOCUMENT_EXTRACTION.validation_result Съвпада/различава се/нееднозначно Видимо за потребителя

7. Финанси

INVOICE / OBLIGATION / PAYMENT

Поле Значение Правило
INVOICE.id, number, date Фактура Отделна от document файла
INVOICE.type Заводска, транспортна, митническа, PDI и др. Определя business relation
INVOICE.counterparty_id Контрагент Задължителен преди потвърждение
INVOICE.amount, currency, due_date Финансови стойности Потвърждават се от потребител
INVOICE_LINE.vehicle_id Конкретен автомобил Условно; поддържа пакетни и индивидуални фактури
INVOICE_LINE.amount Стойност за автомобила/реда Може да се сравнява с проформа
OBLIGATION.invoice_id Финансово задължение Една потвърдена фактура създава едно задължение в контекста
OBLIGATION.status Неплатено / за потвърждение / платено / просрочено Derived от due date и payments
PAYMENT.amount, date, reference Потвърдено плащане Разчетено от документ или попълнено ръчно
PAYMENT.document_id Платежен документ Опционален; попълва редактируемата форма
PAYMENT.source Документ, ръчно, Navision или импорт Една и съща бизнес логика за paid state
PAYMENT.nav_reference Navision референция Опционален бъдещ източник за reconciliation

8. Международен и вътрешен транспорт

TRANSPORT_ORDER / TRANSPORT_RFQ / DELIVERY

Поле Значение Правило
TRANSPORT_ORDER.id, number Поръчка за транспорт Съдържа избрани произведени автомобили
TRANSPORT_ORDER.vehicle_ids Обхват автомобили N:M чрез relation
TRANSPORT_RFQ.carrier_id Запитан превозвач Една поръчка има много RFQ
TRANSPORT_RFQ.route, expected_price, expected_dates Параметри на запитването Email е опционален
TRANSPORT_RFQ.status Draft / изпратена / предложена / приета / отказана Другите оферти не се губят
DELIVERY.id, number Реална доставка/пратка Една поръчка има много доставки
DELIVERY.carrier_id Превозвач за конкретната доставка Може да е различен от друга доставка
DELIVERY.origin_id, destination_id Маршрут Данните от BL имат приоритет за предложение
DELIVERY.loading_date, eta, actual_arrival_at Времена ETA остава видимо в Към BG
DELIVERY.bl_number, bl_document_id Коносамент AI попълва, човек потвърждава
DELIVERY.invoice_id Транспортна фактура Отделен financial relation
DELIVERY_VEHICLE.vehicle_id Автомобил в доставката Един автомобил не участва два пъти в активна доставка за същия етап
DELIVERY_VEHICLE.capacity_factor Коефициент на модела За разпределяне на разхода
DELIVERY_VEHICLE.transport_cost Разпределен разход Изчислен и редактируем преди потвърждение

LOCATION / VEHICLE_MOVEMENT

Поле Значение Правило
LOCATION.id, name, type Пристанище, безмитен склад, централен склад, дилър и др. Физическа или счетоводна според type
VEHICLE_MOVEMENT.vehicle_id Автомобил
VEHICLE_MOVEMENT.from_location_id, to_location_id Физическо движение Не се създава от NAV export
VEHICLE_MOVEMENT.departed_at, arrived_at Реални времена Поддържа частично приемане
VEHICLE_MOVEMENT.source_object Delivery, CMR, dealer request и др. Traceability
VEHICLE_MOVEMENT.confirmed_by Приемащ/издаващ Audit

9. Тексим, митници и хомологация

TEXIM_RECEIPT / PDI_TEXIM

Поле Значение Правило
TEXIM_RECEIPT.delivery_id Вътрешен курс
TEXIM_RECEIPT.vehicle_ids Реално приети автомобили Поддържа X/Y частична приемка
TEXIM_RECEIPT.received_at, received_by Дата и приемащ Затваря транзита за приетите коли
TEXIM_RECEIPT.cmr_document_id Подписан CMR Качва се при пристигане
PDI_TEXIM.vehicle_id Автомобил Опционален и неблокиращ оглед
PDI_TEXIM.result, inspector_id, photos Резултат и доказателства Може да се изпълни по-късно

CUSTOMS_CASE / CUSTOMS_DECLARATION

Поле Значение Правило
CUSTOMS_CASE.id Митническа заявка Съдържа много автомобили
CUSTOMS_CASE.agent_id Митнически агент
CUSTOMS_CASE.vehicle_ids Заявени автомобили Редактируемо преди изпращане
CUSTOMS_CALCULATION.document_id, amount, lines Калкулация Може да се попълни от фактурата
CUSTOMS_CASE.invoice_id Митническа фактура Създава едно задължение
CUSTOMS_CASE.release_status, released_at Митническо освобождаване Отделно от декларацията
CUSTOMS_DECLARATION.id, mrn, document_id Декларация Една заявка има много декларации
CUSTOMS_DECLARATION.vehicle_ids Покрити автомобили Една декларация покрива много автомобили

HOMOLOGATION_CASE

Поле Значение Правило
HOMOLOGATION_CASE.vehicle_ids Автомобили/доставка Групова обработка при приложимост
HOMOLOGATION_CASE.path CoC или УИО Алтернативни пътища
HOMOLOGATION_CASE.status Нужна / подадена / документ получен / потвърдена
HOMOLOGATION_CASE.document_id Финален документ Свързан и с автомобилните досиета
HOMOLOGATION_CASE.owner Бизнес собственик Отворено board решение

10. Back Office, дилърска доставка и After Sales

ECO_BATCH / DOCUMENT_SET

Поле Значение Правило
ECO_BATCH.id, provider_id, vehicle_ids Партида за еко такса Много автомобили
ECO_BATCH.request_document_id Заявка/Excel
ECO_BATCH.invoice_id, payment_id Финансови връзки Отделни обекти
ECO_BATCH.declaration_documents Индивидуални декларации Свързват се по автомобил
DOCUMENT_SET.id, dealer_id, vehicle_ids Комплект към дилър Поддържа частично връщане
DOCUMENT_SET_ITEM.type, document_id, status Изискан/наличен/изпратен/върнат документ Checklist без глобален hard gate

DEALER_DELIVERY_REQUEST / DEALER_RECEIPT

Поле Значение Правило
DEALER_DELIVERY_REQUEST.destination_id Дилър/представителство/централен склад Задължително
DEALER_DELIVERY_REQUEST.vehicle_ids Конкретни автомобили Поддържа частично издаване
DEALER_DELIVERY_REQUEST.status Заявена / частично изпратена / изпратена / приета
DEALER_RECEIPT.vehicle_id Един автомобил Индивидуален резултат в групова приемка
DEALER_RECEIPT.received_at, received_by Реално приемане Определя доставен автомобил
DEALER_RECEIPT.condition, photos, protocol_document_id Състояние и доказателства

DEALER_PDI / DAMAGE_CASE

Поле Значение Правило
DEALER_PDI.vehicle_id, dealer_id Заявен PDI Създава се от дилъра
DEALER_PDI.status, result, completed_by Изпълнение от After Sales
DEALER_PDI.expense_invoice_id Фактура към China Motor Към Finance без допълнително бизнес одобрение
DAMAGE_CASE.vehicle_id Автомобил Един автомобил може да има много случаи във времето
DAMAGE_CASE.source_stage Къде е открита щетата Не се губи при логистично продължаване
DAMAGE_CASE.description, photos Доказателства
DAMAGE_CASE.estimate, responsible_party Калкулация и отговорна страна
DAMAGE_CASE.decision, status Ремонт, claim, изчакване, приключване Отделни permissions за преглед, редакция, решение и приключване

11. Известия, таргети и audit

NOTIFICATION_EVENT / TARGET_PLAN / AUDIT_EVENT

Поле Значение Правило
NOTIFICATION_EVENT.type Предварително Тексим, пристигане, дилърско решение и др. Контролирана номенклатура
NOTIFICATION_EVENT.object_type, object_id Бизнес обект Не се пази само като email текст
NOTIFICATION_EVENT.recipient_ids, channel Получатели и канал Според scope/настройка
NOTIFICATION_EVENT.sent_at, resend_of_id Изпращане/повторение Първото автоматично е еднократно
TARGET_PLAN.type Заводски или дилърски target Отделни типове и права
TARGET_PLAN.year, supplier_id, model_id, dealer_id Обхват на целта Годишен период в текущата версия; измеренията са условни според type
TARGET_PLAN.target_qty Цел Не блокира поръчване
AUDIT_EVENT.actor_id, action, object, timestamp Кой, какво, къде и кога Неизменима история
AUDIT_EVENT.before, after, reason Промяна и основание Задължително при override/преразпределение

12. Основни взаимовръзки

От Към Cardinality Бизнес правило
Вносител Дилър 1:N Дилърът има един вносител
Дилър Представителство 1:N Представителството има един дилър
Потребител Назначение 1:N Позволява много компании и роли
Оферта Клиентска поръчка 1:0..1 Само приета оферта създава поръчка
Клиентска поръчка Дилърска заявка 1:0..N Soft delete на заявката не трие клиентската поръчка
Дилърска заявка Редове 1:N Количествата се пазят по конфигурация
Ред заявка Решения 1:N По едно решение на approval stage
Ред заявка Demand source 1:N Проследява включването в заводски поръчки
Заводска поръчка Редове 1:N Всички редове са към един supplier
Заводски ред Автомобили 1:N Всяка бройка става отделен автомобилен запис
Автомобил Активно дилърско разпределение 1:0..1 Платеният автомобил е заключен
Транспортна поръчка RFQ 1:N Офертите не се презаписват
Транспортна поръчка Доставки 1:N Различни превозвачи са допустими
Доставка Автомобили N:M Чрез Delivery Vehicle
Митническа заявка Декларации 1:N Освобождаването е отделно събитие
Декларация Автомобили N:M Покритието се потвърждава от AI форма
Автомобил Документи N:M Един документ може да покрива много коли
Фактура Задължение 1:1 В конкретния финансов контекст
Задължение Плащания 1:N Позволява частично/повторно reconciliation при нужда
Заявка към дилър Автомобили N:M Поддържа частично издаване и приемане
Автомобил Движения 1:N Формира историята на физическата локация
Автомобил Damage cases 1:N Щетата не променя автоматично локацията

13. Отворени data decisions

  1. Permission-ите за рисков override.
  2. Финалните транспортни капацитети по модел.
  3. Точният митнически Excel contract.
  4. Езиците при production старт.
  5. Приоритетът CRM/Navision при конфликт на складова стойност.
  6. Дали хронологията на дилърските заявки е задължителен allocation приоритет; текущото решение е ръчен избор с видима хронология.
↑