CMChina Motor CRM
Пълни бизнес storiesБез редакционни статуси и audit оценки
Flow-овеCRM начало
Бизнес преглед · 05.09.2026

Пълният списък от бизнес stories

Всички stories са изписани изцяло: участник, permission, обхват, бизнес описание, предусловия, процес, полета, взаимовръзки, правила, Acceptance Criteria и corner cases.

8 епика40 stories273 Acceptance Criteria
22 контекстуално изпълнени16 частично изпълнени2 без надеждно съвпадение

Оценката е семантична сверка със съдържанието на завършените Sprint 2 задачи и наличните модули. Тя не е резултат от изпълнена QA проверка и не променя ClickUp статус.

01

EP-01

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

6 stories
US-F00-01

Достъп до много компании и роли

F00
Основен участникАдминистратор на системата
Необходимо правоУправление на потребители и достъп
Организационен обхватВсички разрешени компании
User story

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

Бизнес описание

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

Предусловия

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

Как протича

  1. Администраторът отваря съществуващия екран за добавяне или редакция на потребител.
  2. Добавя една или повече комбинации Компания, Роля и Представителство.
  3. Системата валидира допустимостта и дублирането на комбинациите.
  4. След запис назначенията се появяват в контекстния превключвател на потребителя.

Бизнес правила

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

Изключения и corner cases

  • Идентична комбинация не се записва повторно.
  • Деактивирано назначение изчезва от превключвателя, но остава в историята.

Полета

Поле Значение Източник Задължителност / редакция
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 и статус

F00
Основен участникСобственик на процес или администратор
Необходимо правоУправление на роли и permissions
Организационен обхватСистемен
User story

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

Бизнес описание

Възможността за действие се определя от конкретно permission, организационния обхват и текущия статус на обекта. Името на ролята само по себе си не е бизнес условие.

Предусловия

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

Как протича

  1. Системата определя активния company/role context.
  2. Проверява permission, scope и допустим статус.
  3. Показва приложимото действие и валидира повторно при изпълнение.
  4. При разрешен override записва предупреждението, основанието и автора.

Бизнес правила

  • UI скриването не заменя server-side проверката.
  • Hard gate съществува само при изрично потвърдено бизнес правило.
  • Soft warning не блокира потребител с необходимото override право.

Изключения и corner cases

  • Директен URL не заобикаля permission проверката.
  • При масова селекция се изпълняват само допустимите редове и се показват точните откази.

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

Поле/обект Значение Правило
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

Контекстно меню и обхват на данните

F00
Основен участникПотребител с повече от едно назначение
Необходимо правоАктивно назначение в избрания контекст
Организационен обхватКомпания, роля и представителство от назначението
User story

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

Бизнес описание

Единният портал променя менюто, dashboard-а, данните и действията според активната комбинация от компания и роля.

Предусловия

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

Как протича

  1. Потребителят отваря превключвателя от профила.
  2. Избира компания и роля измежду активните назначения.
  3. Системата обновява навигацията, dashboard-а и обхвата на данните.
  4. Избраният контекст се използва при следващите действия.

Бизнес правила

  • Не се смесват данни от различни компании.
  • Дилърският контекст е ограничен до дилъра и разрешените представителства.
  • Вносителският контекст използва определения за ролята обхват.

Изключения и corner cases

  • Отворен запис извън новия контекст става недостъпен.
  • Деактивирано назначение не може да остане активно след нова сесия.

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

Поле Значение Правило
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

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

F00
Основен участникОперативен потребител
Необходимо правоПреглед и приложимо масово действие
Организационен обхватСпоред активния организационен контекст
User story

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

Бизнес описание

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

Предусловия

  • Потребителят има достъп до съответния регистър.
  • Регистърът съдържа поне един видимо достъпен ред.

Как протича

  1. Потребителят филтрира чрез отделните бизнес колони.
  2. Избира отделни редове, текущата страница или всички филтрирани резултати.
  3. Една контекстна лента показва броя и допустимите действия.
  4. Системата изпълнява действието и връща резултат по всеки ред.

Бизнес правила

  • Свързаните обекти имат отделни филтруеми колони, а не обща колона Връзки.
  • Контролите за избор не се дублират в action bar-а.
  • Selection set-ът се запазва точно при пагинация и филтри.

Изключения и corner cases

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

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

Обект Значение Правило
Колонни филтри Филтър върху конкретно поле/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-05

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

F00
Основен участникПотребител, който обработва входящ документ
Необходимо правоКачване и потвърждение за съответния тип документ
Организационен обхватБизнес обектът, към който се прикачва документът
User story

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

Бизнес описание

Документите не създават отделен AI екран. Разчетените данни се попълват директно в крайната работна форма и се записват едва след човешка проверка.

Предусловия

  • Има бизнес обект или процес, към който документът принадлежи.
  • Форматът на файла е разрешен за съответния документ.

Как протича

  1. Потребителят качва документа.
  2. Кратък status bar показва обработката.
  3. Системата попълва разпознатите стойности в крайната форма и маркира липсите.
  4. Потребителят коригира, добавя или премахва стойности и потвърждава.

Бизнес правила

  • Неразчетена стойност остава празна; системата не измисля данни.
  • Бизнес статусът не се променя преди човешко потвърждение.
  • Един и същ принцип се използва за Excel, фактури, BL, CMR, декларации и други използвани документи.

Изключения и corner cases

  • Нечетим файл остава задача за ръчно допълване.
  • Повторно качване не създава скрит дублиран бизнес документ.

Полета

Поле Значение Правило
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

История на бизнес действията

F00
Основен участникПотребител с контролен достъп
Необходимо правоПреглед на история
Организационен обхватДостъпните бизнес обекти
User story

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

Бизнес описание

Историята проследява бизнес решенията и промените, без да въвежда излишно версиониране на целия процес.

Предусловия

  • Съществува бизнес обект.
  • По него е извършено проследимо действие.

Как протича

  1. Действието се изпълнява в съответния процес.
  2. Системата записва тип, автор, момент и промяната преди/след.
  3. Историята се показва хронологично в досието на обекта.
  4. Контролният потребител може да проследи източника на текущото състояние.

Бизнес правила

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

Изключения и corner cases

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

Полета

Поле Значение Задължителност
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 Добавянето на нови позиции към активна заводска поръчка се логва, без да изисква версия на цялата поръчка.
02

EP-02

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

6 stories
US-F19-01

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

F19
Основен участникDealer Sales
Необходимо правоСъздаване на клиентска поръчка и заявка към вносител
Организационен обхватСобствени клиенти и разрешено представителство
User story

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

Бизнес описание

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

Предусловия

  • Офертата е приета от клиента.
  • Клиентът, конфигурацията, цената и представителството са определени.

Как протича

  1. Sales отваря приетата оферта и търси автомобил по марка и модел.
  2. Системата показва наличностите на дилъра и China Motor с локация и логистичен статус.
  3. При липса на подходящ автомобил Sales избира модификация, екстериор и интериор в конфигуратора.
  4. Създава клиентска поръчка, записва капаро при наличие и създава дилърска заявка само когато автомобилът не е от свободния собствен склад.

Бизнес правила

  • Клиентската конфигурация и цена се пазят като snapshot.
  • Клиентската и дилърската цена са независими.
  • Soft delete на дилърската заявка не променя клиентската поръчка, офертата или капарото.

Изключения и corner cases

  • Липсващ VIN при неналична конфигурация не блокира.
  • От една оферта не се допуска втора активна клиентска поръчка.

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

Поле Значение Източник Задължителност / редакция
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

F20
Основен участникПотребител с право за Sales Manager одобрение
Необходимо правоОдобрение като Sales Manager
Организационен обхватРазрешен екип и представителства
User story

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

Бизнес описание

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

Предусловия

  • Има активна заявка със статус Чака Sales Manager.
  • Заявката е в организационния обхват на потребителя.

Как протича

  1. Потребителят отваря заявката от своята опашка.
  2. Вижда клиента, офертата, конфигурацията, цената и заявеното количество.
  3. Формата предлага заявеното количество и позволява намаляване.
  4. При одобрение заявката преминава към Dealer Manager; при отказ решението остава в историята.

Бизнес правила

  • Потвърденото количество не може да надвишава заявеното.
  • Решението се управлява от permission и статус.
  • Одобрението не създава нова заявка.

Изключения и corner cases

  • Нула не е частично одобрение и се обработва като отказ.
  • Потребител извън scope не може да отвори заявката чрез директен URL.

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

Поле Значение Правило
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

Поръчка за дилърски склад

F20
Основен участникПотребител с право да създава дилърска складова заявка
Необходимо правоСъздаване на поръчка за дилърски склад
Организационен обхватРазрешена дилърска компания и представителство
User story

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

Бизнес описание

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

Предусловия

  • Избрани са представителство и автомобилна конфигурация.
  • Потребителят има право за складова заявка.

Как протича

  1. Потребителят стартира нова поръчка за склад.
  2. Избира модел, модификация, цветове, количество и получаващо представителство.
  3. Системата записва предназначение Дилърски склад.
  4. Заявката започва от Dealer Manager и след одобрение следва China Motor approval процеса.

Бизнес правила

  • Не се изискват клиент, оферта или капаро.
  • Заявката за склад използва същите количествени решения като клиентската заявка след дилърското ниво.
  • Предназначението остава видимо по цялата верига.

Изключения и corner cases

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

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

Поле Значение Правило
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

Финално дилърско одобрение

F21
Основен участникПотребител с право за Dealer Manager одобрение
Необходимо правоОдобрение като Dealer Manager
Организационен обхватЦялата разрешена дилърска компания
User story

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

Бизнес описание

Dealer Manager взема финалното решение от страна на дилъра и изпраща съществуващата заявка към China Motor.

Предусловия

  • Клиентската заявка е одобрена от Sales Manager или заявката е за дилърски склад.
  • Заявката е активна и принадлежи на дилъра.

Как протича

  1. Dealer Manager вижда клиентските и складовите заявки.
  2. Преглежда предназначение, представителство, цена и предходни количества.
  3. Потвърждава същото или по-малко количество.
  4. При одобрение заявката преминава към Мениджър търговска мрежа в China Motor.

Бизнес правила

  • Не се създава дублирана входяща заявка.
  • Потвърденото количество не надвишава Sales решението.
  • Ценово изключение не прескача approval нивата.

Изключения и corner cases

  • Оттеглянето на дилърската заявка е отделно soft-delete действие и не изтрива клиентската поръчка или капарото.
  • Повторно изпращане на вече изпратена заявка не създава дубликат.

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

Поле Значение Правило
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

Последователно количествено решение

F02
Основен участникУчастник с permission за съответното approval ниво
Необходимо правоОдобрение като Sales, Dealer, Network, Product или Brand Manager
Организационен обхватСпоред нивото и активната компания
User story

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

Бизнес описание

Количеството се решава последователно на пет нива. Всяко ниво вижда цялата история и може да потвърди максимум количеството от предходното ниво.

Предусловия

  • Има активна дилърска заявка на съответното approval ниво.
  • Предходното ниво е записало решение.

Как протича

  1. Sales Manager взема първото количествено решение.
  2. Dealer Manager потвърждава дилърския ангажимент.
  3. Мениджър търговска мрежа взема първото решение от China Motor.
  4. Product Manager предлага изпълнимо количество, а Brand Manager взема финалното решение.

Бизнес правила

  • Всяко ниво може да запази или намали, но не и да увеличи предходното количество.
  • Заявката се движи напред и няма общ неясен статус Върната.
  • Неодобрената разлика се отказва; одобреното количество остава активно до изпълнение.

Изключения и corner cases

  • Заявки без движение над 90 и 120 дни се показват като ескалации.
  • Намаляването на количество не променя snapshot-а на клиентската оферта.

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

Поле Значение Правило
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 и обратна връзка

F22
Основен участникChina Motor Network, Product и Brand нива
Необходимо правоСъответното количествено approval право
Организационен обхватВносител и разрешени марки/дилъри
User story

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

Бизнес описание

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

Предусловия

  • Dealer Manager е изпратил заявката към China Motor.
  • Заявката пази дилър, представителство, конфигурация и дилърско количество.

Как протича

  1. Мениджър търговска мрежа преглежда и потвърждава количество.
  2. Product Manager вижда заявки, наличности и таргети и предлага количество.
  3. Brand Manager взема финалното количествено решение.
  4. Дилърът получава потвърдените бройки, а Product Manager получава задача за включването им в поръчка към доставчик.

Бизнес правила

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

Изключения и corner cases

  • Частичното изпълнение не приключва оставащото одобрено количество.
  • Известие към дилъра не се изпраща преди финалното 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 решение, не по-рано.
03

EP-03

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

7 stories
US-F01-01

Управление и проследяване на цели

F01
Основен участникПотребител с право за планиране и преглед на таргети
Необходимо правоУправление или преглед на таргети
Организационен обхватДилър, представителство, доставчик, марка и модел
User story

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

Бизнес описание

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

Предусловия

  • Има дефинирана година и вид таргет.
  • Приложимите дилъри, доставчици, марки или модели съществуват.

Как протича

  1. Оторизиран потребител задава годишен таргет и неговите измерения.
  2. Системата изчислява одобрено търсене, поръчани и доставени количества.
  3. Dashboard-ът показва процент и надвишаване.
  4. Потребителят използва резултата само като контекст за решение.

Бизнес правила

  • Таргетът не блокира бизнес процес.
  • Няма автоматично предложение или преразпределяне по таргет.
  • Редакцията се записва в audit историята без отделен version workflow.

Изключения и corner cases

  • Над 100 процента се показва като изпълнение над таргета.
  • Месечни и тримесечни таргети могат да се добавят в бъдеща версия, без да се изискват сега.

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

Поле Значение Правило
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

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

F03
Основен участникПотребител с право за заводски поръчки
Необходимо правоСъздаване и редакция на поръчка към доставчик
Организационен обхватРазрешени доставчици, марки и модели
User story

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

Бизнес описание

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

Предусловия

  • Има одобрено търсене или собствено планирано количество.
  • За избраните модели има допустим доставчик.

Как протича

  1. Потребителят избира редове от търсенето и/или собствен stock.
  2. Смесената селекция се разделя по доставчик.
  3. За всеки доставчик се отваря или създава поръчка и се добавят редовете.
  4. Добавените бройки създават отделни автомобилни записи и запазват връзката с източника.

Бизнес правила

  • Една заводска поръчка е към един доставчик.
  • Поръчката може да остава активна и да се допълва дълго време без версии.
  • Редовете са част от самата активна поръчка и не са отделен междинен бизнес обект.
  • Редът на позициите следва реда на добавяне от Product Manager.

Изключения и corner cases

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

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

Поле Значение Източник / правило
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

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

F03
Основен участникПотребител с право за управление на продуктовия каталог и снабдяването
Необходимо правоУправление на каталог, допустими доставчици и цени
Организационен обхватРазрешени марки, модели и доставчици
User story

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

Бизнес описание

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

Предусловия

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

Как протича

  1. Потребителят редактира модела или модификацията.
  2. Свързва допустим доставчик и приложими цени.
  3. При нова поръчка системата използва актуалния каталог.
  4. Историческите оферти и поръчки продължават да използват своите snapshots.

Бизнес правила

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

Изключения и corner cases

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

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

Поле Значение Правило
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

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

F04
Основен участникПотребител с право за производство
Необходимо правоИмпорт и потвърждение на производствени данни
Организационен обхватРазрешени заводски поръчки и доставчици
User story

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

Бизнес описание

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

Предусловия

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

Как протича

  1. Потребителят качва Excel към заводската поръчка.
  2. Системата разчита и съпоставя редовете.
  3. Формата показва разпознати, непълни и несъпоставени автомобили.
  4. Потребителят коригира и потвърждава произведените автомобили.

Бизнес правила

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

Изключения и corner cases

  • Несъпоставен ред остава за човешка проверка.
  • Масово действие пропуска автомобили в недопустим статус с точна причина.

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

Поле Значение Източник / редакция
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

Обработка на проформи

F05
Основен участникПотребител с право за заводски документи
Необходимо правоКачване, редакция и потвърждение на проформа
Организационен обхватКонкретна заводска поръчка
User story

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

Бизнес описание

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

Предусловия

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

Как протича

  1. Потребителят качва проформата.
  2. Системата попълва номер, дата, валута, сума и позиции.
  3. Потребителят коригира и потвърждава формата.
  4. Проформата се свързва със заводската поръчка и приложимите позиции.

Бизнес правила

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

Изключения и corner cases

  • Нова проформа не изисква version workflow на поръчката.
  • Нееднозначна позиция остава за ръчно съпоставяне във формата.

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

Поле Значение Правило
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

Индивидуални заводски фактури

F05
Основен участникПотребител с право за заводски фактури
Необходимо правоПакетно качване и потвърждение на индивидуални фактури
Организационен обхватЗаводска поръчка и нейните автомобили
User story

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

Бизнес описание

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

Предусловия

  • Съществуват заводска поръчка и автомобилни записи.
  • Получен е пакет от индивидуални фактури.

Как протича

  1. Потребителят качва един или повече фактурни файлове.
  2. Системата извлича данните и опитва съпоставяне с автомобил.
  3. Формата показва проформа, фактурна цена и разлика.
  4. Оторизираният потребител допълва и потвърждава фактурните стойности.

Бизнес правила

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

Изключения и corner cases

  • Несъпоставена фактура остава във формата за ръчно свързване.
  • Дублиран файл не създава скрито второ задължение.

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

Поле Значение Правило
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

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

F05
Основен участникПотребител с право за разпределение на автомобили
Необходимо правоРазпределение и преразпределение към дилър
Организационен обхватРазрешени дилъри, заявки и произведени автомобили
User story

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

Бизнес описание

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

Предусловия

  • Автомобилът е произведен.
  • Има одобрена дилърска заявка с оставащо количество или разрешено собствено предназначение.

Как протича

  1. Потребителят филтрира произведените и неразпределени автомобили.
  2. Избира заявка и вижда одобрено, разпределено и оставащо количество.
  3. Свързва автомобилите със заявката.
  4. До плащането може масово да смени дилъра; след плащане assignment-ът се заключва.

Бизнес правила

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

Изключения и corner cases

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

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

Поле Значение Правило
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 Новият дилър получава известие, че автомобилът може да се забави по логистични причини.
04

EP-04

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

4 stories
US-F06-01

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

F06
Основен участникЛогистика
Необходимо правоСъздаване на транспортна поръчка и RFQ
Организационен обхватПроизведени автомобили и разрешени превозвачи
User story

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

Бизнес описание

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

Предусловия

  • Автомобилите са произведени и не участват в друга активна международна доставка.
  • Транспортните фирми са налични в номенклатурата.

Как протича

  1. Логистика филтрира и избира произведени автомобили.
  2. Създава транспортна поръчка с точния selection set.
  3. Добавя RFQ с превозвач, очаквана цена и маршрут.
  4. По избор изпраща английски email; създаването на поръчката не зависи от email-а.

Бизнес правила

  • Една поръчка може да има много RFQ към различни фирми.
  • Превозвачът е relation към компания, а не свободен текст.
  • Добавянето на първата доставка означава приемане на избраната оферта.

Изключения и corner cases

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

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

Поле Значение Правило
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

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

F06
Основен участникЛогистика
Необходимо правоДобавяне и редакция на международна доставка
Организационен обхватКонкретна транспортна поръчка
User story

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

Бизнес описание

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

Предусловия

  • Съществува транспортна поръчка с налични автомобили.
  • Избрана е оферта или превозвач за конкретната доставка.

Как протича

  1. Логистика избира Добави доставка.
  2. Качва BL и фактура, които попълват същата крайна форма.
  3. Допълва капацитет по модели, превозвач, маршрут, дата на товарене, ETA и конкретни автомобили.
  4. Проверява разпределения транспортен разход по автомобил и създава доставката.

Бизнес правила

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

Изключения и corner cases

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

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

Поле Значение Източник / редакция
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-01

ETA, известяване и пристигане

F07
Основен участникЛогистика
Необходимо правоУправление на ETA, пристигане и известия
Организационен обхватАктивни международни доставки
User story

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

Бизнес описание

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

Предусловия

  • Съществува активна доставка с ETA.
  • Има определени получатели на известията в Тексим.

Как протича

  1. Системата показва ETA в списъка и детайла.
  2. В настройваем момент изпраща еднократно предварително известие.
  3. Логистика маркира реалното Пристигна в BG.
  4. Автомобилите получават локация BG пристанище и Тексим получава отделно известие.

Бизнес правила

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

Изключения и corner cases

  • Неуспешното известие остава видимо и не блокира статуса.
  • Реалното пристигане използва действителен момент, а не презаписва ETA.

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

Поле Значение Правило
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

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

F08
Основен участникПриемчик в Тексим
Необходимо правоПриемане на автомобили в Безмитен склад
Организационен обхватКурсове и автомобили, адресирани към Тексим
User story

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

Бизнес описание

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

Предусловия

  • Автомобилите са на BG пристанище.
  • Създаден е вътрешен курс към Безмитен склад.

Как протича

  1. Тексим отваря очаквания курс.
  2. Качва подписания при получаването CMR.
  3. CMR попълва приемната форма, която може да бъде коригирана.
  4. Тексим приема всички или част от автомобилите и системата обновява физическата им локация.

Бизнес правила

  • CMR се качва при физическото приемане, не при тръгването.
  • Частичното приемане приключва курса само за приетите автомобили.
  • Texim PDI е отделен, опционален и неблокиращ процес.

Изключения и corner cases

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

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

Поле Значение Правило
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 на Тексим е отделен, опционален и неблокиращ процес.
05

EP-05

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

3 stories
US-F09-01

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

F09
Основен участникПотребител с право за хомологация
Необходимо правоПреглед, редакция или потвърждение на хомологация
Организационен обхватРазрешени автомобили и технически документи
User story

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

Бизнес описание

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

Предусловия

  • Има автомобил или група автомобили.
  • Получен е технически документ или е регистрирана липса за обработка.

Как протича

  1. Потребителят качва техническия документ.
  2. Системата разчита данните и предлага покритите автомобили.
  3. Потребителят коригира съпоставянето и потвърждава.
  4. Резултатът става видим по всеки покрит автомобил.

Бизнес правила

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

Изключения и corner cases

  • Нечетим документ остава задача без измислени данни.
  • Back Office и Логистика получават началните права, а permission-ите могат по-късно да се закачат към други роли.

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

Поле Значение Източник / правило
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

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

F10
Основен участникЛогистика или потребител с митнически права
Необходимо правоСъздаване и обработка на митническо досие
Организационен обхватИзбрани автомобили в Безмитния склад
User story

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

Бизнес описание

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

Предусловия

  • Автомобилите са налични за митническа обработка.
  • Избран е митнически агент и получател на заявката.

Как протича

  1. Потребителят избира автомобили и създава редактируема митническа чернова.
  2. Системата генерира Excel и записва изпращането към агента.
  3. При отделна калкулация тя се разчита и досието чака фактура.
  4. Ако фактурата пристигне първа, тя попълва и празния блок Калкулация; при два документа сумите се сравняват.

Бизнес правила

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

Изключения и corner cases

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

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

Поле Значение Източник / редакция
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

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

F10
Основен участникЛогистика или потребител с митнически права
Необходимо правоПлащане, освобождаване и обработка на декларации
Организационен обхватМитническо досие и покритите автомобили
User story

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

Бизнес описание

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

Предусловия

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

Как протича

  1. Плащането се потвърждава и досието чака освобождаване.
  2. Оторизиран потребител маркира освободените автомобили, включително частично.
  3. Получените декларации се качват и AI попълва MRN и автомобилите.
  4. Декларациите се свързват с конкретните автомобили и остават в досието.

Бизнес правила

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

Изключения и corner cases

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

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

Поле Значение Правило
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 при счетоводно завеждане.
06

EP-06

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

4 stories
US-F16-01

Единна Back Office опашка

F16
Основен участникBack Office
Необходимо правоПреглед и изпълнение на приложимите back-office действия
Организационен обхватАвтомобили в Back Office обработка
User story

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

Бизнес описание

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

Предусловия

  • Автомобилът е достигнал приложим етап за back-office обработка.
  • Потребителят има поне едно от необходимите permissions.

Как протича

  1. Back Office филтрира автомобилите по отделните readiness показатели.
  2. Отваря досието и вижда налични, очаквани и липсващи документи.
  3. Стартира независимо необходимото действие или масова операция.
  4. При завеждане или предаване системата показва конкретните липси като soft warnings.

Бизнес правила

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

Изключения и corner cases

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

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

Поле Значение Правило
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-02

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

F16
Основен участникBack Office
Необходимо правоNAV import, NAV export и управление на складово състояние
Организационен обхватАвтомобилният регистър и Централен склад Чайна Мотор
User story

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

Бизнес описание

CRM комуникира с NAV чрез предоставения stock формат. NAV ID, инвентарният номер и VIN са отделни идентификатори, а счетоводният склад е отделен от физическата локация.

Предусловия

  • Наличен е NAV stock файл със съгласувания формат.
  • Автомобилите имат или могат да получат отделен NAV ID.

Как протича

  1. Back Office импортира NAV файла от екрана Автомобили.
  2. Системата съпоставя първо по NAV ID и предлага актуализациите във форма.
  3. Потребителят потвърждава обновяването или обработва несъпоставените редове.
  4. Заведените в Централен склад автомобили могат да се експортират в същия 69-колонен формат.

Бизнес правила

  • NAV import и export не променят физическата локация.
  • NAV склад, физическа локация и крайна дестинация са отделни полета.
  • Счетоводното завеждане в Централен склад не означава физическо движение.

Изключения и corner cases

  • Съществуващ NAV ID обновява автомобила вместо да създава дубликат.
  • Физически към Централен склад се движат само демо автомобили и свободен собствен stock.

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

Поле Значение Правило
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

Партида за еко такса

F17
Основен участникBack Office
Необходимо правоСъздаване и обработка на еко такса
Организационен обхватИзбрани автомобили с приложими хомологационни документи
User story

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

Бизнес описание

Еко таксата може да стартира от автомобилния регистър или специализирания Back Office изглед със същия selection set. Процесът пази партида, фактура, плащане и индивидуални декларации.

Предусловия

  • Автомобилът има CoC или Удостоверение за индивидуално одобряване.
  • Автомобилът не участва в друга активна еко партида и няма отчетена еко такса.

Как протича

  1. Back Office избира автомобилите и вижда наличните хомологационни документи и липси.
  2. Създава и изпраща партида с точния списък автомобили.
  3. Получената фактура попълва форма със стойност и покрити автомобили.
  4. След реално плащане индивидуалните декларации се прикачват към автомобилите.

Бизнес правила

  • Статус Платена се задава само след потвърдено плащане.
  • Един автомобил не се включва повторно в активна партида.
  • Специализираният екран и автомобилният регистър използват еднакъв flow.

Изключения и corner cases

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

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

Поле Значение Правило
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

Документен комплект към дилър

F18
Основен участникBack Office
Необходимо правоГенериране, изпращане и архивиране на дилърски документи
Организационен обхватЕдин дилър, едно представителство и избрани автомобили
User story

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

Бизнес описание

За конкретно предаване се създава документен комплект. Системата следи генерираните, изпратените, върнатите и все още липсващите документи.

Предусловия

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

Как протича

  1. Back Office избира автомобилите и генерира комплекта.
  2. Преглежда файловете и изпраща комплекта.
  3. При получаване на подписани документи ги качва към същия комплект.
  4. Системата приключва само върнатите позиции и оставя липсващите отворени.

Бизнес правила

  • Различни дилъри или представителства не се смесват.
  • Генериране, изпращане и връщане са отделни audit събития.
  • Заменен файл пази предходната история.

Изключения и corner cases

  • Частично върнат комплект остава отворен само за липсите.
  • Повторното изпращане не създава нов несвързан комплект.

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

Поле Значение Правило
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 Повторно изпращане или заменен файл пази предходната история.
07

EP-07

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

6 stories
US-F11-01

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

F11
Основен участникЛогистика
Необходимо правоСъздаване на заявка за вътрешен транспорт
Организационен обхватАвтомобили в Тексим и разрешени крайни локации
User story

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

Бизнес описание

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

Предусловия

  • Автомобилите са физически налични в Тексим.
  • Определени са крайна дестинация и получател.

Как протича

  1. Логистика филтрира и избира автомобилите.
  2. Системата показва документи, хомологация, еко такса, обмитяване, плащане, NAV склад и локация.
  3. Липсите се показват като конкретни предупреждения.
  4. След потвърждение или разрешен override се създава заявка към Тексим.

Бизнес правила

  • Счетоводното завеждане не е физическо движение.
  • Директна доставка от Тексим към дилър е допустима.
  • Всяко override решение изисква permission и история.

Изключения и corner cases

  • Неплатен или необмитен автомобил показва предупреждение, но не е автоматичен hard gate.
  • Към Централен склад физически се насочват само демо и свободен собствен stock.

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

Поле Значение Правило
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

Частично издаване от Тексим

F12
Основен участникТексим
Необходимо правоИздаване на автомобили по вътрешна транспортна заявка
Организационен обхватЗаявки и автомобили в operational scope на Тексим
User story

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

Бизнес описание

Тексим издава физически наличните автомобили по заявката. Издаването може да е частично и не означава приемане от крайния получател.

Предусловия

  • Има активна заявка за вътрешен транспорт.
  • Поне един от заявените автомобили е физически наличен за издаване.

Как протича

  1. Тексим отваря заявката и вижда автомобилите, дестинацията и документите.
  2. Маркира автомобилите, които действително издава.
  3. Системата създава движение към дилър или Централен склад.
  4. Неиздадените автомобили остават За издаване в същата заявка.

Бизнес правила

  • Издаден автомобил е В транспорт, а не Приет от дилър.
  • Частичното издаване не приключва останалите позиции.
  • Един автомобил не може да бъде издаден в две активни заявки.

Изключения и corner cases

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

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

Поле Значение Правило
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

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

F13
Основен участникПриемащ служител
Необходимо правоПриемане на вътрешна доставка
Организационен обхватАвтомобили, изпратени към текущата локация
User story

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

Бизнес описание

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

Предусловия

  • Автомобилите са изпратени към текущата локация.
  • Доставката съдържа неприети автомобили.

Как протича

  1. Служителят избира всички или част от пристигналите автомобили.
  2. За всеки попълва checklist за състояние и комплектност.
  3. Добавя изискваните снимки и описва щета или липса.
  4. Потвърждава приемката и системата създава протокол само за избраните автомобили.

Бизнес правила

  • Checklist-ът и снимките са по автомобил.
  • Щета или липса създава свързано damage case.
  • Неприетите автомобили остават в доставката.

Изключения и corner cases

  • Автомобил със щета може да бъде приет със свързан damage case.
  • Частичната приемка не приключва цялата доставка.

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

Поле Значение Задължителност
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

Оперативна приемка в представителството

F24
Основен участникДилърски приемащ потребител
Необходимо правоПриемане на доставка в представителство
Организационен обхватАктивното дилърско представителство
User story

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

Бизнес описание

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

Предусловия

  • Има активна доставка към представителството.
  • В доставката има поне един неприет автомобил.

Как протича

  1. Потребителят отваря доставката и вижда маршрут, CMR, дата и автомобили.
  2. Избира неприетите автомобили, които са пристигнали.
  3. Попълва checklist, снимки и щети.
  4. Потвърждава приемката; доставката остава отворена или приключва според остатъка.

Бизнес правила

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

Изключения и corner cases

  • Щета или липса изисква описание и damage case.
  • Частично пристигнал курс запазва точния неприет остатък.

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

Поле Значение Задължителност
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

Единно досие на щета

F14
Основен участникПотребител с приложимо право за щети
Необходимо правоОтделни права за преглед, редакция, решение и приключване
Организационен обхватДостъпните автомобили и damage cases
User story

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

Бизнес описание

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

Предусловия

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

Как протича

  1. Потребителят създава случай от приемка, PDI или автомобилното досие.
  2. Добавя място, етап, описание, снимки и отговорник.
  3. Оторизираните потребители допълват оглед, калкулация и решение.
  4. Случаят се приключва след реалното разрешаване.

Бизнес правила

  • Няма hardcoded роля или profile за обработката.
  • Щетата не спира автоматично логистиката.
  • Няма автоматичен срок за отказ или приключване на калкулацията.

Изключения и corner cases

  • Чака допълнителен оглед и За ремонт остават отворени състояния.
  • Началното разпределение следва Back Office/Логистика/After Sales според действието, а всяко право може да се закачи към друга роля.

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

Поле Значение Правило
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-02

Dealer PDI и фактуриране към China Motor

F14
Основен участникДилър и After Sales
Необходимо правоЗаявяване, изпълнение и фактуриране на Dealer PDI
Организационен обхватАвтомобили на дилъра и приложим After Sales екип
User story

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

Бизнес описание

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

Предусловия

  • Автомобилът е в дилърския scope.
  • Дилърът има право да заяви Dealer PDI.

Как протича

  1. Дилърът създава PDI заявка за конкретен автомобил.
  2. After Sales вижда заявката и записва изпълнението и резултата.
  3. След изпълнение дилърът добавя разходна фактура към China Motor.
  4. Фактурата се насочва към Finance и остава видима в автомобилното досие.

Бизнес правила

  • Dealer PDI и Texim PDI са отделни процеси и документи.
  • PDI фактурата не преминава през допълнително бизнес одобрение.
  • Изпълнението и финансовият документ са отделни събития.
  • Няма потвърден CRM обхват преди ръководството да определи системата източник и обмена на данни.

Изключения и corner cases

  • Незавършен PDI остава видим за After Sales и дилъра.
  • Фактура не може да се свърже скрито с различен автомобил.
  • За решение от ръководството: източник на истина, синхронизирани статуси и документи, идентификатор на автомобила и поведение при разминаване между системите.

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

Поле Значение Правило
Автомобил и дилър Връзка към автомобила и заявителя Трябва да е еднозначна между двете системи
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.
08

EP-08

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

4 stories
US-F23-01

Финансов списък на дилъра

F23
Основен участникДилърски потребител с финансов достъп
Необходимо правоПреглед и сваляне на финансови документи
Организационен обхватСобствени, екипни или фирмени документи според назначението
User story

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

Бизнес описание

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

Предусловия

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

Как протича

  1. Потребителят отваря финансовия списък.
  2. Филтрира всички, за плащане, просрочени или платени документи.
  3. Отваря връзките към поръчка и автомобили.
  4. Преглежда или сваля оригиналния документ.

Бизнес правила

  • Свалянето не променя платежния статус.
  • Всеки документ има собствен падеж и статус.
  • Sales, Sales Manager и Dealer Manager виждат различен организационен scope.

Изключения и corner cases

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

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

Поле Значение Правило
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

Платежно и потвърждение на плащане

F23
Основен участникПотребител с право за плащане
Необходимо правоПотвърждение на плащане и опционално качване на платежно
Организационен обхватДостъпни фактури и свързани поръчки
User story

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

Бизнес описание

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

Предусловия

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

Как протича

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

Бизнес правила

  • Платежният файл е опционален; потвърдените payment полета са бизнес фактът.
  • NAV, import или друг бъдещ източник попълва същия payment модел.
  • Плащането се проследява в контекста на задължението.

Изключения и corner cases

  • Частична или различна сума остава видима за проверка.
  • Повторно платежно се записва като отделен документ, без автоматично двойно плащане.

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

Поле Значение Правило
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

Автоматични и ръчни известия

F15
Основен участникСистема и оперативен потребител
Необходимо правоПреглед и повторно изпращане на известия
Организационен обхватСъответното бизнес събитие и разрешени получатели
User story

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

Бизнес описание

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

Предусловия

  • Настъпило е събитие с дефинирано известие или потребителят стартира ръчно изпращане.
  • Получателите са определени чрез бизнес relation или конфигурация.

Как протича

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

Бизнес правила

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

Изключения и corner cases

  • Неуспешното изпращане остава видимо и може да се повтори.
  • Промяна на ETA не създава автоматично второ предварително известие.

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

Поле Значение Правило
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, получатели, канал, автоматично/ръчно изпращане, език, съдържание и приложени документи.

За бизнес потвърждение

  • Да се одобри предложената матрица в UNI-32296: trigger, получатели, scope, канал, автоматично/ръчно изпращане, език, съдържание и документи.
US-F15-02

Dashboard по активна компания и роля

F15
Основен участникПотребител с активно company/role назначение
Необходимо правоПреглед на приложимите dashboard KPI и drill-down данни
Организационен обхватАктивната компания, роля, представителства и екипи
User story

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

Бизнес описание

Dashboard-ът използва еднакви KPI дефиниции, но показва различен бизнес обхват за China Motor, дилърски мениджъри и търговци.

Предусловия

  • Потребителят има активно назначение.
  • За контекста са конфигурирани приложимите KPI и задачи.

Как протича

  1. Потребителят избира компания и роля.
  2. Dashboard-ът зарежда KPI, графики, таргети, задачи и изключения за контекста.
  3. Потребителят филтрира периода и отваря drill-down.
  4. Детайлният списък използва същия набор данни като показаната KPI стойност.

Бизнес правила

  • Default периодът е от 1 януари на текущата година до днес.
  • Приходите и разходите се показват по месеци.
  • China Motor различава приходната страна към дилърите от разходната към доставчици и превозвачи.

Изключения и corner cases

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

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 роли.
ОБЩИ AC

Правила, приложими към всички stories

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

  • 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 резултата филтрите, пагинацията и изборът на всички филтрирани запазват точния набор между страниците.
↑