Перейти к содержанию
STAR GROUPAS IS + TO BE + смета + SFA • v2.2
Редакция аудита 317 стр.
Нажмите на текст и внесите изменения. При первом сохранении выберите в окне браузера именно этот HTML-файл и подтвердите его замену.
Режим просмотра • изменений нет
24.09.2026 • Аудит ред. 3 → архитектура v1.4 → смета v1.0 → SFA v1.0
Ограниченный доступ

Код доступа к панели управления

Панель редактирования, сохранения и печати открывается по коду доступа. Код приходит только владельцу документа на 3368606@gmail.com. Просмотр документа кода не требует.

письмо уйдёт только на адрес владельца
Данные аудита
—
STAR GROUP
TO BE • V1.4 RU
4 СЕНТЯБРЯ 2026
Архитектура корпоративных программных систем

Единая операционная архитектура с 1С:УТ в центре

1С:УТ становится центральной System of Control, а WMS и 1С:Бухгалтерия — постоянными доменными системами. На этапе 1 ProTarget работает как переходный SFA/TMS-контур для обеспечения непрерывности операций. После стабилизации core-контура на этапе 2 выбирается Linko, Doctor Sales или собственная SFA-система, ProTarget заменяется, а PRBC подключается через Integration Platform.

1С:УТоперационный мастер • контрольная точка • официальный источник данных о товарах, заказах и статусах операционных платежей
Основание32 процесса и 302 узла аудита
Этап 1ProTarget — переходный контур • 1С:УТ • WMS • Бухгалтерия
ПлатформаIntegration Platform • Gateway • DWH
Этап 2Целевая SFA + PRBC • отдельные решения Go/No-Go
STAR GROUP • TO BE ARCHITECTUREПРЕДЛОЖЕНИЕ • НА СОГЛАСОВАНИЕ
01 / Executive view

Архитектурные решения, требующие утверждения руководства

0220 страниц
ФАКТ АУДИТАРЕШЕНИЕ TO BEТРЕБУЕТ СОГЛАСОВАНИЯ
01
1С:УТ — System of ControlЕдиная НСИ, официальный заказ, резерв, реализация, статус операционного платежа и контрольная точка.
02
ProTarget — переходная SFA/TMS этапа 1Временно сохраняется для непрерывности операций; реализуются только необходимые core-интеграции, неограниченный backlog поставщика не финансируется.
03
WMS — warehouse executionЯчейка, задание ТСД, план/факт, комплектация, погрузка и физический факт возврата относятся к WMS.
04
Единая Integration PlatformAPI Gateway, services, RabbitMQ, canonical model, mapping, Outbox/Inbox, журналирование, retry и DLQ — основа замены SFA.
05
PRBC — System of Engagement этапа 2Финансовый workflow, платёжные запросы, контроль баланса, внутренний чат, задачи и документооборот подключаются после стабилизации core-контура.
06
PRBC не является финансовым masterPRBC управляет запросами и согласованиями; официальный баланс, лимит, факт оплаты и проводки поступают из 1С:УТ/1С:Бухгалтерии.
07
Payment/Fiscal Gateway — модуль платформыSplit tender, маршрутизация провайдера, подписанный callback, фискальный статус и сверка; внешние поставщики находятся за адаптерами.
08
1С:Бухгалтерия — финансовый и налоговый контурНе является операционным master; получает подтверждённые документы из УТ и возвращает результаты банка, налогов и проводок.
09
DWH → Power BI — аналитическая истинаАналитика опирается не на production DB или Excel, а на исторические витрины данных с контролем lineage и DQ.
10
DMS — источник миграции и read-only архивПосле ETL, репетиций и сверки приём новых операций прекращается; история хранится согласно политике retention.
11
Прямая запись в БД и vendor lock-in запрещеныCore-интеграции используют независимый от поставщика API/event-контракт SFA; Excel/Telegram не являются официальной транзакцией.
12
ProTarget заменяется на этапе 2Linko, Doctor Sales и собственная SFA оцениваются по fit-gap, трёхлетнему TCO, API, переносимости данных и PoC; выбирается только вариант, прошедший gate.
Главный принцип: 1С:УТ — не монолит, поглощающий все функции. Она является единой System of Control, а WMS отвечает за исполнение складских операций. ProTarget используется только как переходная System of Entry на этапе 1. На этапе 2 выбранная или разработанная SFA бесшовно принимает эту роль, а PRBC подключается как System of Engagement. Ни одна из этих систем не становится финансовым мастером.
Ожидаемый бизнес-результат

Один заказ — один номер — один статус

Продажи, склад, экспедитор, касса и бухгалтерия работают по единому идентификатору документа.

Результат контроля

Деньги видны в течение дня

Раздельно отражаются ожидаемые, принятые, фискализированные, переданные в кассу суммы и расхождения.

Технический результат

Ошибки не теряются

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

Факты аудита + проектные решения TO BE02 / 20
02 / Evidence base

На чём основано предложение

03Редакция аудита 3
32процесса охвачено аудитом5а–5г — отдельные потоки
302узла уровня Miro280 AS IS + 22 узла плана
37рисков и проблем4 критических • 8 высоких
11системных и бизнес-контуровв разрезе 11 подразделений
24/32процесса с участием DMSтекущая центральная зависимость
Уровень автоматизации операций AS IS
Вручную
215
Автоматически
45
Не определено
20

Расчёт: 280 узлов AS IS; плановые узлы исключены.

Приоритет рисков
Критические
4
Высокие
8
Средние
8
Не оценены
17
Деньги и фрод

Кассовый контроль запаздывает

Смешанный платёж отражается как 100% наличный; деньги у экспедитора не видны онлайн; расхождение может скрываться до 30 дней.

Риски аудита 2, 9, 13, 23, 25
Данные и учёт

Системы видят разную картину

DMS и 1С:Бухгалтерия не полностью синхронизируют изменения; статусы WMS не возвращаются; причина расхождений остатков не установлена.

Риски 12, 19, 22, 26, 37
Процессы и управление

Excel стал операционным слоем

Excel используется минимум в 12 из 32 процессов; задания, согласования, сверки и отчёты связываются вручную.

Процессы 1, 2, 4, 5б, 5в, 11, 13–16, 20, 25
Граница доказательности: сроки в аудите противоречивы, поэтому roadmap опирается не на даты, а на gates. Модули PRBC и функционально-стоимостная проблема ProTarget — новые управленческие исходные данные; они подтверждаются через TCO, fit-gap и PoC.
Источник: аудит процессов Star Group, редакция 303 / 20
03 / AS IS diagnosis

Ключевые разрывы текущей архитектуры

04Карта проблем
Текущий системный поток — упрощённая схема, подтверждённая аудитом
01ProTarget • переходный контурSFA/TMS работает, однако остаются открытые функции, backlog поставщика и давление на TCO
02DMS24/32 процесса • ручное проведение и перепроведение
03WMS + ТСДскладской документ поступает; статусы возвращаются не полностью

Разрыв с 1С:Бухгалтерией

Она получает исходный заказ, но дальнейшие изменения и возвраты отражаются не полностью.

Разрыв платежей

Наличные, карта, QR и Click объединяются в одну запись как наличный платёж.

Разрыв аналитики

DMS → Excel → Power BI; локальный файл и децентрализованное резервное копирование.

Критическая причина: между системами не определены единый идентификатор документа, модель статусов, интеграционный журнал и владелец данных.
Критический

Нет онлайн-контроля денег

Кассир не видит ожидаемую сумму; план/факт и типы оплаты по экспедитору не разделены.

Высокий

Ручное перепроведение

Реализация, смена экспедитора и статус отчёта зависят от повторных действий оператора.

Высокий

План/факт в Excel

WMS не рассчитывает расхождение автоматически; DMS не видит полные статусы приёмки.

Системный

Операторские функции внутри IT

Ручное ведение точек, акций, планов и маршрутов занимает ресурс IT.

1
Double entryОдин факт вручную вводится в несколько систем.
2
Hidden failuresДетали ошибок PostPoint и WMS не возвращаются пользователю.
3
Shadow processExcel, Telegram и бумага выполняют роль официального потока.
4
Риск поставщика и владенияBacklog и стоимость ProTarget, а также владение процессами, системами и НСИ не управляются как единый риск.
AS IS: факты • предположения и открытые вопросы не смешаны04 / 20
04 / Target architecture

Целевая архитектура с 1С:УТ в центре, готовая к замене SFA

05Модель V1.4
Архитектура с 1С:УТ в центре, включающая PRBC и план замены SFA на этапе 2 STAR GROUP • ЦЕЛЕВАЯ КОРПОРАТИВНАЯ IT-АРХИТЕКТУРАЦЕЛЕВАЯ АРХИТЕКТУРА СИСТЕМ С 1С:УТ В ЦЕНТРЕЕдиная НСИ • оплата/фискализация в TMS • PRBC и целевая SFA на этапе 2TO BE • V1.4ЦЕЛЕВАЯ МОДЕЛЬЦветовая модель на основе утверждённого wireframeВерсия 1.4 RU • 04.09.2026ПРАВИЛА УПРАВЛЕНИЯ И АРХИТЕКТУРЫ01 • SYSTEM OF ENTRY • ProTarget → целевая SFA02 • SYSTEM OF CONTROL • 1С:УТ03 • DATA / NSI COUNCIL • owner + steward04 • DESIGN AUTHORITY • стандарты API / событий05 • SYSTEM OF ENGAGEMENT • PRBC / этап 206 • SCRUM + GATE • 2 недели / конец месяца07 • ПРАВИЛО • Прямая запись в БД запрещенаS01 • ПРОДАЖИ И ДОСТАВКАProTarget • SFA + TMSПЕРЕХОДНЫЙ КОНТУРSFACONTRACTSTMS / ЭКСПЕДИТОРPAY + FISCALSYSTEM OF ENTRYЧерновик клиента / торговой точки и договораЗаказ, маршрут, экспедитор, факты доставки и возвратаПриём оплаты при доставке и фискальный чекДОСТАВКА → PAY/FISCAL REQUEST → ИНТЕГРАЦИОННЫЙ МОДУЛЬ → TMS / УТ / БУХ↔ЕДИНЫЙ СЛОЙ ОБМЕНАИнтеграционная платформа100% ТРАССИРУЕМОСТЬAPI GatewayAuth • version • limitsIntegration ServicesЗаказы • WMS • Платежи • PRBCRabbitMQОчередь • событие • retryCanonical ModelЗаказ • платёж • задача • документMapping RegistryКорпоративный ID ↔ локальный IDOutbox / InboxИдемпотентность • без дублейRETRY • DLQ • REPLAYSYNC LOG • ADMINCORRELATION_ID • VERSIONНЕТ ПРЯМОЙ ЗАПИСИ В БД • API / EVENT / WEBHOOKПРИНЯТО / ОТКЛОНЕНО • CANONICAL ID • СТАТУСW02 • СКЛАДСКОЕ ИСПОЛНЕНИЕ1С WMS + ТСДПОЛНЫЙ ЦИКЛ СКЛАДСКОГО ИСПОЛНЕНИЯ01 Приёмка и план/фактпричина расхождения + акт02 Ячейка / put-awayфакт через ТСД03 Комплектация и контрольстатус по позициям04 Погрузка / возвратфакты отгрузки и возврата1С WMS создаёт задания и фиксирует фактПрямая интеграция с 1С:УТ средствами 1С — без записи в БД1С ↔ 1С DIRECT • СТАТУС • ПЛАН/ФАКТP04 • КОРПОРАТИВНЫЙ КОНТУРPRBC • платформа управленияЭТАП 2Финансовый блокбюджет • лимитУправление платежамизапрос • согласованиеКонтроль балансаостаток • фактВнутренний чатканал • сообщение • файлУправление задачамиSLA • Kanban • контрольКонтроль документооборотасогласование • версия • аудитSYSTEM OF ENGAGEMENT • контроль и взаимодействие • не финансовый masterЭТАП 2 • PRBC ↔ ИНТЕГРАЦИОННАЯ ПЛАТФОРМА ↔ 1С:УТ / БУХ / DWHLПЕРЕХОДНЫЙ КОНТУРDMS • Legacy / источник миграцииНовые операции не создаютсяETL + mapping + 2 репетиции + сверка10 рабочих дней + закрытие месяца + sign-off → READ ONLYОстатки и документы сверяются с 1С:УТУСЛОВНЫЙ EXIT • НЕ КАЛЕНДАРЬ, А КРИТЕРИИ ПРИЁМКИ1С03 • ЦЕНТРАЛЬНОЕ ОПЕРАЦИОННОЕ ЯДРО1С:УТSYSTEM OF CONTROLЕДИНАЯ НСИ ДЛЯ ВСЕХ ПЛАТФОРМSKU / IKPU / barcodeноменклатура • единицаКлиент / торговая точкачерновик фронта → canonical IDДоговор / лимитусловия оплаты • статусЦена / акция / валютаверсия и срок действияСклад / регионостаток • размещениеКонтрагент / рольвладелец • статус доступаОфициальный lifecycle:VALIDATION→RESERVE→REALIZATION→RETURN→CLOSEФронт инициирует объект; 1С:УТ принимает/отклоняет и присваивает canonical IDЗдесь хранятся заказ, резерв, остаток и статусы TMS delivery/payment/fiscalMASTER-ПРАВИЛО • внешние системы через платформу; WMS и Бух — контролируемый 1С-directDАНАЛИТИЧЕСКИЙ СЛОЙDWH / Data Mart → Power BIEvent / ETL pipeline • историческая модель • контроль DQExcel не master • нет прямого подключения к production DBЕДИНАЯ АНАЛИТИЧЕСКАЯ ИСТИНАBФИНАНСЫ И НАЛОГИ1С:БухгалтерияУТ ↔ Бух: документ, распределение платежа и фискальный чекБанк → банковский перевод: выписка • matching • статус1С ↔ 1С DIRECT INTEGRATION↔МОДУЛЬ ИНТЕГРАЦИОННОЙ ПЛАТФОРМЫPayment + Fiscal GatewayЗапрос TMS → адаптер → payment / fiscal providerWebhook/callback → статус TMS + УТ → БухSFA-ФРОНТ НЕ ПОДКЛЮЧАЕТСЯ К ПРОВАЙДЕРАМ НАПРЯМУЮPВНЕШНИЕ ПРОВАЙДЕРЫПлатёжные и фискальные сервисыPaymentКарта • Click • Payme • Rahmat • QRFiscalPostPoint • SmartPOS • ePOSНалогифискальный результат • статус чекаWebhook / callbackподпись • retry • полный код ошибкиПРИ СМЕНЕ ПРОВАЙДЕРА МЕНЯЕТСЯ ТОЛЬКО АДАПТЕР МОДУЛЯПРИЁМ / СТАТУСПЛАТФОРМА • БЕЗОПАСНОСТЬ • ОПЕРАЦИОННАЯ УСТОЙЧИВОСТЬDEV / TEST / PRODHA • BACKUP • DRAD / SSO • RBACFIREWALL • EDR • VAULTGIT • CI/CDPROMETHEUS • GRAFANA • LOG / ALERTL2/L3 + DEVOPS + SLAСЛЕДУЮЩИЙ ПЛАН1С:ЗУП + UZGPS — отдельный проектPRBC, этап 2 — через API/event после стабилизации core-контураSFA, этап 2 — Linko / Doctor Sales / собственная система • TCO + PoCОбозначения: → поток API/event ↔ контролируемая direct-интеграция - - → миграция - · - → план этапа 2TO BE • FINAL • 16:9 • 4K
TO BE: ProTarget — переходный контур • целевая SFA и PRBC — этап 2 • 1С:УТ — control • WMS/Бух — контролируемый 1С-direct05 / 20
05 / Application portfolio

Роль и целевая судьба каждой системы

06Сохранить / изменить / вывести
СистемаРоль TO BEРешениеГраница / результат
1С:УТЦентральная System of ControlBUILD / COREЕдиная НСИ, официальный заказ, резерв, реализация, статус платежа и возврат
ProTargetТекущая SFA/TMS System of EntrySTAGE 1 TRANSITIONНепрерывность + необходимые API; ограничение backlog/TCO; вывод после cutover целевой SFA
Целевая SFAБудущая System of Entry для продаж/TMSSTAGE 2 SELECT / BUILDLinko, Doctor Sales или собственная SFA; fit-gap + 3Y TCO + PoC + миграция
WMS + ТСДИсполнение складских операцийKEEP + 1C INTEGRATEПлан/факт, ячейки, комплектация/погрузка, расхождения и факт возврата
PRBCКорпоративная System of EngagementSTAGE 2 / INTEGRATEФинансы, платёжные запросы, просмотр баланса, чат, задачи и внутренний документооборот
1С:БухгалтерияФинансовый и налоговый учётKEEP + RE-SCOPEДокументы УТ; банк, налоги, проводки и статус исполнения платежа
Integration PlatformУправляемый обменNEW / CORE ENABLERAPI Gateway, services, RabbitMQ, canonical model, mapping, Outbox/Inbox
Payment/Fiscal GatewayМодуль платежей/фискализации платформыNEWSplit tender, адаптеры, подписанный callback, статус чека и сверка
DWH / Data MartСлой исторической аналитикиNEWНеизменяемая история, lineage, DQ; события SFA/PRBC на этапе 2
Power BIУправленческая аналитикаKEEP + REWIREТолько DWH/data mart; production DB и Excel не являются master
DMSLegacy / источник миграцииMIGRATE → RETIREРепетиции + сверка → закрытие записи → read-only архив
Excel/Telegram/бумагаТеневые операцииREMOVE FROM COREЭкспорт, уведомления и аварийные доказательства; не официальные транзакции или согласования
1С:ЗУП / UZGPSБудущий отдельный контурOUT OF CORE SCOPEОтдельный charter/fit-gap; не блокирует cutover core, SFA или PRBC
Постоянное ядро: 1С:УТ, WMS, 1С:Бухгалтерия, Integration Platform, Gateway и DWH. ProTarget остаётся только на этапе 1 как контур непрерывности операций.
SFA этапа 2: Linko, Doctor Sales и собственная разработка оцениваются по единой scorecard: fit-gap, трёхлетний TCO, API, SLA и пилотный PoC; победивший вариант заменяет ProTarget.
Выводятся: После сверки DMS переводится в режим read-only/архив, а ProTarget — после cutover целевой SFA. Excel и Telegram не являются официальными транзакционными каналами.
Принцип портфеля: один домен — одна ответственная система06 / 20
06 / Data ownership

Где данные создаются и где считаются официальными

07Создание ≠ master
Сбалансированное правило: На этапе 1 коммерческие черновики создаёт ProTarget, а на этапе 2 — выбранная целевая SFA. PRBC ведёт внутренние запросы, согласования, задачи, чат и документооборот. 1С:УТ и 1С:Бухгалтерия остаются официальными источниками операционных и финансовых фактов; PRBC показывает баланс, но не пересчитывает его и не создаёт второй master.
ДанныеСоздание/инициацияAuthoritative masterПотребительКонтроль
Единая НСИ, SKU, штрихкод, ИКПУ, единица, цена1С:УТ / утверждённый workflow владельца1С:УТДействующая SFA, WMS, Бухгалтерия, Gateway, просмотр PRBCВерсия, срок действия и независимый от поставщика mapping
Кандидат клиента и торговая точкаДействующая SFA: ProTarget → целевая1С:УТ (после валидации)SFA, WMS, Бухгалтерия, просмотр PRBCЧерновик/принят/отклонён + canonical ID
Договор, кредит и условия оплатыЧерновик в действующей SFA; внутреннее согласование PRBC1С:УТSFA, Бухгалтерия, PRBC0/30/50/70%, лимит, срок и версия
Черновик заказаДействующая SFA: ProTarget → целевая1С:УТ (после приёмки)WMS, Бухгалтерия, DWH, просмотр PRBCЛокальный ID SFA + canonical order ID
Резерв, реализация и операционное закрытие1С:УТ1С:УТSFA, WMS, БухгалтерияLifecycle не меняется при замене SFA
Ячейка, задание ТСД, план/факт, физический возвратWMSWMS1С:УТ, действующая SFAСобытие с actor/device/time
Маршрут, экспедитор и факт доставкиДействующая SFA/TMSДействующая SFA1С:УТ, WMS, DWHВерсия назначения и код причины
Платёжная транзакция и технический фискальный статусPayment/Fiscal GatewayGateway1С:УТ, действующая SFA, БухгалтерияКаждый способ оплаты отдельно; подписанный callback
Официальный статус оплаты, задолженность и баланс1С:УТ; результат банка/проводки из Бухгалтерии1С:УТ / 1С:Бухгалтерия по доменамSFA, PRBC, DWHФронты только читают; актуальность/сверка
Проводки, банк, налоги и исполнение платежа1С:Бухгалтерия1С:Бухгалтерия1С:УТ, статус PRBC, DWHMatched/unmatched/rejected reference
Внутренние запросы, согласования, чат, задачи, документооборотPRBCPRBCIntegration Platform, DWH; разрешённые события в coreRBAC/SoD, retention, аудит; не финансовый факт
Исторический аналитический фактIntegration/DWH pipelineDWHPower BISource lineage, source_version SFA и DQ
Golden record

1С:УТ

Единая НСИ, официальный заказ, резерв, реализация и статус операционного платежа.

System of Entry • переходный контур

ProTarget → целевая SFA

Единый канонический контракт: черновик клиента/договора, заказ, TMS, факт доставки и возврата.

Physical truth

WMS

Ячейка, задание ТСД, план/факт, комплектация, погрузка и физический возврат.

System of Engagement

PRBC • этап 2

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

Data governance: кандидат → валидация → golden record → downstream sync07 / 20
07 / Integration catalogue

Интеграционные потоки — основной операционный контур

08INT-01 … INT-08
IDПотокPayloadPatternОшибка / приёмка
INT-011С:УТ → SFA/WMSНСИ и ценыEvent + delta APIНезависимый от поставщика payload; ошибка mapping → DLQ
INT-02SFA-фронт → 1С:УТЧерновик клиента/договораSync APIПринят/отклонён + причина + canonical ID
INT-03SFA-фронт → 1С:УТЗаказSync APIИдемпотентное создание; возвращается официальный order ID
INT-041С:УТ → SFA-фронтВалидация, резерв, причина блокировкиEvent/webhookПользователю возвращаются статус и business reason
INT-051С:УТ ↔ WMSЗадания и факты inbound/outbound/returnКонтролируемая интеграция 1СКанонические документ/строки; без прямой записи в БД
INT-06WMS → 1С:УТ/SFAПлан/факт и статусEventКод статуса, время, actor/device, расхождение
INT-07SFA TMS → УТ/WMSМаршрут/экспедиторEventВерсия назначения; без перепроведения
INT-08SFA-фронт → 1С:УТФакт доставкиSync + eventDelivered/partial/failed + факты по строкам
ID

correlation_id

Заказ и все его дочерние документы отслеживаются в одной цепочке.

Защита от дублей

idempotency_key

Повторный webhook не создаёт новый платёж или реализацию.

Надёжность

retry + DLQ

Временная ошибка обрабатывается повторно; неисправленное сообщение остаётся в очереди исключений.

Аудируемость

business + tech log

Кто, когда и что отправил, что принято и почему отклонено.

Контракт привязан не к поставщику, а к домену SFA: schema • version • owner • SLA • failure policy08 / 20
07 / Integration catalogue

Интеграционные потоки — финансы, PRBC и миграция SFA

09INT-09 … INT-19
IDПотокPayloadPatternОшибка / приёмка
INT-09SFA-фронт → Payment/Fiscal GatewayПлатёж/фискальный запрос при доставкеSync APIorder/lines/tenders; signed + idempotent
INT-10Gateway → УТ/SFA/БухгалтерияРезультат оплаты/фискализацииWebhook/eventtxn ID, cheque ID, статус, детали ошибки
INT-111С:УТ ↔ 1С:БухгалтерияРеализация, возврат, платёж, банковский/налоговый статусКонтролируемая интеграция 1СCanonical ID, matching и сверка
INT-12WMS/SFA → УТ → БухгалтерияВозвратSaga/eventОтслеживаются физический и финансовый этапы
INT-13Платформа → DWHСобытия core-бизнесаStreaming/batchНеизменяемая история, lineage и DQ
INT-14DWH → Power BIУтверждённая витрина данныхSemantic model/refreshНет прямого чтения production DB
INT-15PRBC → Платформа → 1С:УТ/1С:БухгалтерияПлатёжный/бюджетный/лимитный запрос, согласование, ссылка на документAPI + event • этап 2Gate стабильности core, SoD, идемпотентность, аудит
INT-161С:УТ/1С:Бухгалтерия → Платформа → PRBCБаланс, лимит, платёж и статус документаQuery API + event • этап 2Официальный источник, актуальность, masking, сверка
INT-17PRBC → Платформа → DWHМетаданные запросов/согласований/задач/документов/чатаEvent/batch • этап 2Retention, область доступа и lineage
INT-18DMS → Migration staging → 1С:УТМиграция legacyETL + сверкаИсточник read-only; checksum и отчёт об исключениях
INT-19ProTarget → SFA staging → целевая SFA/УТКлиенты, маршруты, черновики/open orders и необходимая историяETL/API + сверка • этап 2Экспорт данных, checksum, пилот, rollback и freeze источника
Синхронный API: цена, кредитный лимит, валидация заказа, инициация платежа и разрешённый запрос баланса/статуса из PRBC — операции, где пользователь ожидает немедленный ответ.
Асинхронное событие: складские и фискальные статусы, события BI, согласований, задач и документов PRBC, а также состояния, допускающие задержку обработки.
Запрещается: общая таблица БД, прямая SQL-запись и корректировка статуса без журналирования. Жёсткая привязка контракта SFA к внутренним ID и модели ProTarget также запрещена: при замене целевой SFA core-системы не должны переписываться.
Технические SLA — предложение TO BE; утверждаются после нагрузочного теста09 / 20
08 / End-to-end process

От заказа до финансового закрытия

10Order-to-Cash
01SFA-фронтProTarget → целевая SFA; агент создаёт черновик заказа
021С:УТпроверяет клиента, договор, кредит, цену и остаток
03WMSвыполняет комплектацию, контроль и погрузку
04SFA/TMSфиксирует маршрут, доставку и факт возврата
05Gatewayпроводит оплату и формирует фискальный чек
061С:УТ → Бухгалтерияоперационное и финансовое закрытие
Автоматические контроли 1С:УТ
  • действительность клиента и договора
  • правило предоплаты 0/30/50/70%
  • кредитный лимит и просроченная задолженность
  • цена, акция и право на скидку
  • остаток и резерв
  • статус блокировки/стоп-листа
  • единый штрихкод/ИКПУ
  • дубликат заказа и правило даты
Exception handling

Отклонение — не потеря

Бизнес-отказ не смешивается с технической ошибкой. Заказ остаётся в статусе «blocked» с кодом причины, ответственной ролью и маршрутом повторного рассмотрения.

  • превышен кредитный лимит
  • договор недействителен
  • нет маппинга SKU
  • недостаточно резерва
Сквозная цепочка документов
Черновик заказа SFAзаказ УТрезерв УТзадание WMSотгрузкафакт доставкиоплата/фискализацияфинансовое закрытие

На каждом этапе сохраняются source_id + canonical_id + correlation_id. На этапе 1 фронтом SFA в этой цепочке O2C является ProTarget; на этапе 2 тот же канонический API/event-контракт принимает целевая SFA. PRBC не входит в критический синхронный путь O2C и работает только через Платформу с разрешёнными workflow и статусами.

Процессы аудита: 3–11, 13–14, 2710 / 20
09 / Warehouse execution

Целевой поток приёмки, комплектации, погрузки и возвратов

11WMS + ТСД
Inbound / приёмка
ОжидаетсяПринимаетсяРасхождениеПринято/ОтклоненоРазмещено
  • 1С:УТ отправляет в WMS подтверждённый плановый документ
  • ТСД фиксирует факт по SKU/серии/сроку годности
  • WMS автоматически рассчитывает план/факт
  • при расхождении создаются электронный акт и workflow
  • УТ принимает только подтверждённый складской факт
Outbound / комплектация и погрузка
ОчередьКомплектацияКонтрольСтейджингПогружено
  • WMS выдаёт задание по ячейке и загрузке
  • изменение приоритета возвращается как событие
  • «out of stock» выделяется отдельным кодом причины
  • этап доставки не открывается без факта погрузки
  • 1С:УТ и действующий SFA-фронт видят статус почти в реальном времени
Return-to-stock / возврат
01SFA-фронтProTarget → целевая SFA; позиция, количество, причина, фото и подтверждение клиента
021С:УТразрешение на возврат и ожидаемая приёмка
03WMS/ТСДфизическая приёмка, решение по качеству и годности
041С:УТкорректировка остатков и баланса клиента
051С:Бухгалтериядокумент финансовой/налоговой корректировки

Бумажная квитанция может быть аварийным подтверждением, но официальный идентификатор возврата и его статус создаются в системе.

Устраняется: план/факт в Excel и уведомление по email.
Устраняется: только статус «проведено/отменено» в DMS.
Проверяется: версия WMS и фактическое покрытие по филиалам.
Процессы аудита: 2, 6–8, 12, 24, 2911 / 20
10 / Money control

Платежи, фискализация и кассовая сверка

12Payment/Fiscal Gateway
01ExpectedУТ рассчитывает ожидаемую сумму по заказу
02CaptureЭкспедитор выбирает способы оплаты в мобильном приложении
03ProcessGateway направляет запрос банку/QR/POS/фискальному провайдеру
04ConfirmВозвращаются статусы транзакции и чека
05CollectКассир принимает деньги в разрезе экспедиторов
06ReconcileУТ/Бухгалтерия закрывает план-факт или создаёт исключение
Split payment

Один заказ — несколько способов оплаты

Наличные, карта, Click, Payme и Rahmat/QR сохраняются как отдельные транзакции; их сумма сверяется с суммой заказа. Это поток денег, принятых от клиента, тогда как «управление платежами» в PRBC — корпоративный workflow платёжных запросов и согласований.

Fiscal control

Состав чека на уровне позиций

SKU, штрихкод, ИКПУ, количество, цена, налог и скидка берутся из официальных данных 1С:УТ.

Provider independence

Провайдер через адаптер

Выбор PostPoint, SmartPOS или ePOS не требует перестройки кода действующей SFA/1С:УТ; тот же принцип адаптеров сохраняется при переходе с ProTarget на новую SFA.

Рабочее место кассира — в разрезе экспедиторов
ПоказательЗначение
ОжидаетсяСумма, которую необходимо сдать по доставленным заказам
ПринятоСумма в реальном времени по наличным/карте/QR/Click
ФискализированоЧасть, подтверждённая ID чека и фискальным статусом
СданоДеньги, фактически переданные экспедитором в кассу
РасхождениеОжидалось − принято/сдано; причина и ответственный
Fail-safe

Фискальная ошибка не закрывает заказ скрыто

  • бизнес-платёж и фискальный статус разделены
  • подпись callback провайдера проверяется
  • повторный callback обрабатывается идемпотентно
  • лимит повторов и dead-letter queue
  • ручная корректировка — только с комментарием и audit log
  • выдача клиенту электронного/печатного чека подтверждается
Риски аудита: 2, 9, 13, 24–26, 33, 35–3612 / 20
11 / Control model

Единая модель статусов и закрытие дня

13State machines
Заказ
ЧерновикВалидацияЗаблокированПодтверждёнРезервWMSПогруженДоставкаЗакрыт
Платежи и фискализация
ОжидаетсяИнициированоАвторизованоОжидает фискализацииФискализированоПринятоСвереноЗакрыто
Платёжный запрос PRBC • этап 2
ЧерновикОтправленСогласование руководителяФинансовый контрольСогласовано / ОтклоненоПередано в УТ/БухгалтериюИсполненоСверено
Исключения
Бизнес-отказТехническая ошибкаОчередь повторовРучная проверкаРешено
Правила закрытия дня
  1. Для всех доставленных заказов рассчитывается ожидаемая сумма.
  2. Платёжные транзакции агрегируются по типам оплаты.
  3. Проверяются статус фискального чека и сумма провайдера.
  4. Баланс экспедитора закрывается актом сдачи в кассу.
  5. При расхождении смена остаётся в статусе «exception».
  6. День закрывается только после подтверждения причины и решения ответственной ролью.
Банковский платёж
  1. Банковская выписка автоматически загружается в 1С:Бухгалтерию.
  2. Сопоставление по контрагенту, договору, сумме и назначению.
  3. Подтверждённое платёжное событие возвращается в 1С:УТ.
  4. Неидентифицированная сумма попадает в очередь исключений.
  5. Оператор только разбирает исключение, не вводя данные повторно.
Отменяется: ежемесячная фотосверка, запись «100% наличные», закрытие предыдущего дня без сравнения с ожидаемой суммой и слепая отметка «оплачено» по Excel-выписке.
Процессы аудита: 5а–5г, 9–11, 14, 25–2713 / 20
12 / Data & engagement

Контур интеграции DWH, Power BI и PRBC

14Read model + workflow
ИСТОЧНИКИ1С:УТ • WMS • SFA-фронт • 1С:Бухгалтерия • PRBC*SFA: ProTarget → целевая система; PRBC — только на этапе 2
ПРИЁМIntegration Platformвалидация схемы • mapping • lineage • журнал ошибок
ХРАНЕНИЕDWH / Data Lakehouseистория • факты/измерения • медленно изменяемая НСИ
ВИТРИНЫData Martпродажи • запасы • деньги • финансы • workflow
ИСПОЛЬЗОВАНИЕPower BIролевые дашборды и управленческие KPI
Правило Power BI

Нет прямого подключения к production DB

Отчётная нагрузка не замедляет операционные системы; показатели берутся из пересчитываемой витрины данных с контролируемыми lineage и DQ.

Правило PRBC

System of Engagement, а не master

PRBC управляет внутренней работой. Официальными источниками финансового факта, баланса, лимита и проводок остаются 1С:УТ и 1С:Бухгалтерия.

Правило NAS

Резервные копии и файлы, но не БД

NAS может хранить документы, файлы и резервные копии; он не является интеграционной БД реального времени или master-источником Power BI.

Рекомендуемые витрины данных
Salesorder, line, price, discount, client, agent
Warehousestock snapshot, movement, pick, discrepancy, return
Доставкаroute, expeditor, stop, delivered/partial/failed
Cashexpected, collected, fiscalized, handed-over, variance
Financereceivable, bank matching, realization, correction
Workflowзапросы PRBC, согласования, SLA, статусы задач и документов
Шесть модулей PRBC и граница интеграции
  • Финансовый блок: просмотр бюджета/лимита и внутренние запросы
  • Управление платежами: платёжный запрос, маршрут и согласование; исполнение в 1С:Бухгалтерии/1С:УТ
  • Контроль баланса: чтение официального баланса через Платформу, контроль актуальности и сверка
  • Внутренний чат: сообщения, файлы и контекст с политиками retention/RBAC
  • Управление задачами: владелец, SLA, Kanban и эскалация
  • Внутренний документооборот: версии, согласование и аудит; без прямой записи в БД
Данные аудита + новое требование TO BE по PRBC14 / 20
13 / Security & reliability

Требования к безопасности, инфраструктуре и качеству сервиса

15Предлагаемые NFR
Identity

AD/SSO + MFA

Централизованный жизненный цикл пользователей, ролей, устройств и администраторских прав. PRBC также подключается к корпоративным SSO/MFA; при увольнении доступ автоматически отзывается.

Access

RBAC + SoD

Права кассира, экспедитора, оператора, бухгалтера, инициатора/согласующего PRBC и администратора разделяются; self-approval и сочетание request + approve + pay в одной роли запрещены.

Trace

Immutable audit log

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

Resilience

Backup + DR test

Критерием приёмки служат не наличие backup, а результат тестового восстановления и runbook.

NFRПредлагаемый targetКомментарий
Availability≥99.9% в операционном окнеподтверждается нагрузкой и SLA вендоров
API latencyp95 ≤3 свалидация и пользовательские запросы
Event delayв норме ≤60 ссобытия статусов WMS/фискализации/PRBC
RPOcore ≤15 мин1С:УТ и состояние интеграции
RTOcore ≤4 часовизмеряется DR-тестом
Message safety0 неотслеживаемых потерьза счёт DLQ и сверки

Эти значения не являются замерами аудита — это целевые TO BE показатели, утверждаемые в ТЗ и нагрузочном тесте.

Инфраструктурные зависимости из аудита
  • отдельная VM и фактический замер ресурсов для 1С:УТ
  • резерв мощности на период параллельной работы с DMS
  • центральный firewall, защита endpoint и сегментация сети
  • топология серверов/сети и реестр активов
  • автозапуск и мониторинг принтеров/VM WMS
  • стратегия хранения Kerio/NAS — отдельный проект
Риски аудита 14, 27–31
Service account: интеграции не работают под личными учётными записями.
Безопасность этапа 2: для целевой SFA обязательны SSO/RBAC, безопасность API, экспорт данных, pentest и DR; для чатов и документов PRBC — retention, шифрование и DLP.
Мониторинг: технический alert отделяется от бизнес-исключения; также контролируются SLA и очереди PRBC.
Целевые NFR утверждаются руководством и владельцами бизнеса15 / 20
14 / Operating model

Роли и ответственность — в разрезе функций

16RACI
Деятельность
Владелец процесса
IT/Архитектура
InfoSec
Операционная роль
Правила и KPI процессов core/SFA/PRBC
A
C
I
R
Выбор SFA, 3Y TCO и PoC
A
R
C
C
НСИ и качество данных
A
R
C
I
ТЗ, независимый от поставщика API и security baseline
C
A R
C
I
Разработка/тест интеграций и миграции
I
A R
C
C
UAT/приёмка core, целевой SFA и PRBC
A R
C
C
R
Релиз, rollback и gate этапа 2
A
R
C
I
Поддержка L1 и пересмотр доступов
A
C
C
R
R

Responsible

Фактически выполняет работу.

A

Accountable

Владелец итогового решения и результата.

C

Consulted

Участвует как эксперт до принятия решения.

I

Informed

Получает информацию о результате/статусе.

Обязательный жизненный цикл изменений
01Владелец процессапроблема, KPI и ожидаемый результат
02Регламентроль, триггер, правило, исключение
03Бизнес-требование / ТЗданные, API, безопасность, тесты
04Разработка + тестинтеграция, UAT, производительность
05Релиздокументы, обучение, поддержка, rollback
Граница ответственности: Владельцы процессов продаж, склада и финансов отвечают за правила core-контура; product owner SFA — за функциональный scope, TCO и миграцию; владельцы модулей PRBC — за workflow, SLA, согласования и сроки хранения контента. IT отвечает за платформу, интеграции, мониторинг, безопасность и поддержку, но не за ежедневные операторские операции.
Процессы аудита: 16–22, 2816 / 20
15 / Transition roadmap

Последовательность перехода core-контура, целевой SFA и PRBC

17Волны 0–11
0

Governance и baseline

Владельцы процессов/данных/PRBC/SFA, модель статусов, core scope и charter этапа 2

G0: утверждён architecture charter
1

Инфраструктура и security foundation

VM 1С:УТ, backup/restore, мониторинг, AD/SSO/RBAC, service account

G1: пройдены тесты восстановления и доступа
2

MDM и очистка данных

SKU, штрихкод, ИКПУ, клиент, договор, цена, mapping и дубликаты

G2: 100% критических master-data сопоставлено
3

Каркас Integration Platform

Независимый API SFA, RabbitMQ, canonical ID, mapping, Outbox/Inbox, DLQ

G3: пройдены тесты failure/retry/replay
4

Переходный MVP ProTarget ↔ УТ ↔ WMS

Только необходимые потоки заказа, резерва, статусов WMS, доставки/возврата и pay/fiscal

G4: UAT core O2C; freeze backlog
5

Payment/Fiscal + 1С:Бухгалтерия

Split payment, fiscal, рабочее место кассира, bank matching, корректировка возврата

G5: закрыта ежедневная сверка
6

DWH / Data Mart → Power BI

События core, DQ/lineage, витрины продаж/запасов/денег/финансов

G6: KPI сверены с источниками
7

Пилот core и fit-gap региона

Выбранный склад/филиал, offline, локальная фискализация/касса и support runbook

G7: Go/No-Go пилота core
8

Вывод DMS + стабилизация core

Parallel run, закрытие расхождений, read-only, архив/retention, контроль SLA

G8: запись в DMS закрыта; core стабилен
9

Этап 2A • выбор SFA / buy-build

Linko, Doctor Sales и собственная SFA: обязательный fit-gap, 3Y TCO, API/export, SLA, security

G9: решение по weighted scorecard
10

Этап 2A • PoC SFA и cutover

Пилот, mobile/offline/TMS/pay-fiscal, миграция данных, parallel run, rollback; freeze ProTarget

G10: сверка целевой SFA + sign-off
11

Этап 2B • интеграция PRBC

6 модулей, просмотр официального баланса/статусов, согласование платежей, события задач/чата/документов

G11: UAT PRBC + SoD + финансовая сверка
Подход к срокам: календарная дата и обязательство go-live не фиксируются, пока для каждой волны не утверждены владелец, результат и gate. Противоречивые сроки из аудита не приняты как план.
Roadmap: последовательность и критерии приёмки • календарный baseline на следующем этапе17 / 20
16 / Acceptance & cutover

Критерии Go / No-Go для core-контура, замены SFA и PRBC

18Stage gates
Обязательный набор сквозных сценариев
1Обычная доставка с оплатой наличными
2Доставка с оплатой картой/QR
3Смешанный платёж
4Сопоставление банковского перевода
5Блокировка по кредитному лимиту
6Частичная доставка
7Полный/частичный возврат
8Расхождение план/факт WMS
9Ошибка фискального провайдера + retry
10Повторный webhook
11Offline/reconnect
12Совместимость API-контракта SFA
13PoC mobile/offline/TMS для SFA
14Экспорт данных ProTarget + checksum
15Параллельные заказы/сверка целевой SFA
16Rollback целевой SFA/freeze ProTarget
17Платёжный запрос PRBC + согласование
18Актуальность баланса PRBC + сверка
19Аудит и доступ к документам/задачам PRBC
Критерии допуска к go-live
1Критических дефектов = 0
2Master mapping утверждён
3Входящие остатки сверены
4Тест дубликатов/rollback
5Тест восстановления backup
6Фискальный чек доставляется клиенту
7Есть L1/L2 runbook и owner
8Monitoring/alert работают
9Security access review
10Business UAT sign-off
11Weighted fit-gap score SFA
12Утверждён 3Y TCO SFA
13PoC API + экспорта данных SFA
14Сверка миграции SFA
15Право выхода/rollback из ProTarget
16Решение по DMS exit/retention
17Стабильность core до PRBC
18UAT PRBC по SoD/RBAC/retention
Parallel run

Сопоставление фактов

Cutover невозможен до сверки остатков, заказов, реализаций, платежей и возвратов.

Rollback

Проверенный путь

Backup/restore и rollback runbook проверяются на практике до релиза.

DMS exit

Только чтение + архив

Новые записи блокируются; история остаётся доступной для чтения согласно политике retention.

Критерии входа в этап 2

SFA и PRBC — отдельные решения Go/No-Go

SFA: scorecard, PoC, экспорт, миграция/rollback. PRBC: версионируемые API/event, SoD, официальный баланс и UAT.

Триггер No-Go: критическое финансовое расхождение, дубликат документа/платежа, непроверенное восстановление backup, неизвестный master mapping, потеря фискального чека или неготовность поддержки L1/L2. Дополнительные No-Go для этапа 2: core-контур нестабилен; SFA не прошла PoC API/экспорта данных или сверку миграции; отсутствует путь выхода/rollback из ProTarget; PRBC ведёт баланс как второй master либо не прошла UAT по SoD/RBAC/retention.
Критерии приёмки должны быть перенесены в ТЗ и план тестирования18 / 20
17 / Risk closure

Как критические и высокие риски аудита закрываются в TO BE

19Control mapping
ID
Приоритет
Проблема аудита
Контроль TO BE
Владелец
R-2
Критический
Смешанный платёж отражается как 100% наличный
Split tender + Gateway + платёжный ledger УТ
Финансы + IT
R-4
Критический
Ручная оплата по Excel-выписке
Импорт/matching банка + очередь исключений
Финансы
R-9
Критический
Фотосверка и фрод до 30 дней
Ежедневная кассовая сверка + закрытие смены
Касса/Контроль
R-13
Критический
Деньги у экспедитора не видны онлайн
Рабочее место кассира + expected/collected/variance
Логистика/Финансы
R-1
Высокий
WMS не считает план/факт автоматически
Факт ТСД + workflow расхождений
Склад
R-7
Высокий
Нет IT-бюджета/тендера/план-факта
Отдельное управление IT-закупками
Руководство/IT
R-12
Высокий
Ручное перепроведение реализации
Событийные статусы + идемпотентное проведение
IT/Операции
R-14
Высокий
Слабый реестр активов и актов
CMDB/lifecycle активов + HR offboarding
IT/HR
R-15
Высокий
Кредит и договор ведутся вручную
Rule engine договоров/кредитов УТ
Финансы/Продажи
R-16
Высокий
Экспедитор/территория устаревают
Независимое от поставщика master-событие SFA + версия
Логистика/Продажи
R-18
Высокий
Функция UZGPS не используется
Отдельный fit-gap вне core scope
Транспорт
R-19
Высокий
Изменения DMS и Бухгалтерии разорваны
Канонические документы УТ→Бух + статус возврата
Финансы/IT
Средние риски: BI/закупки, точки/акции, отзыв доступа и загрузка планов закрываются через data governance.
17 неоценённых рисков: включаются в реестр с severity/owner в ходе discovery и fit-gap по филиалам.
Остаточный риск: возможности поставщиков, покрытие филиалов и capacity не отмечаются как «закрытые» без измерений.
Новый управленческий риск: Функциональный backlog ProTarget, несоответствие затрат результату и vendor lock-in контролируются через TCO/PoC; для PRBC предусмотрены отдельные gates по dual master, SoD и retention.
ID риска соответствует порядковому номеру в реестре аудита19 / 20
18 / Decision log

Вопросы для утверждения до старта

20Approval pack
01
Q-01Кто является владельцем workflow согласования клиента/договора и итоговым data steward?
02
Q-02Каковы покрытие WMS/SFA, локальные процессы и offline-различия по филиалам?
03
Q-03Кто утверждает единый обязательный функциональный fit-gap для Linko, Doctor Sales и собственной SFA?
04
Q-04Каков трёхлетний TCO каждого варианта SFA: лицензии, customization, интеграции, support, инфраструктура и внутренняя команда?
05
Q-05Каковы weighted scorecard и минимальный проходной балл для решения buy versus build по SFA?
06
Q-06Каковы условия exit, notice, экспорта данных, API, истории/архива и интеллектуальной собственности в договоре ProTarget?
07
Q-07В каком филиале/складе, с каким числом агентов/экспедиторов и какой peak load проводится PoC целевой SFA?
08
Q-08Каков план freeze/rollback для open orders, маршрутов, клиентов, договоров и истории при миграции ProTarget → целевая SFA?
09
Q-09Каковы финальный payment/fiscal provider и правила refund: API, SLA, цена и фискальная корректировка?
10
Q-10Кто утверждает business/product owner, MVP, SLA баланса, SoD и retention для шести модулей PRBC?
11
Q-11Каковы capacity, HA/DR и SLA поддержки для 1С:УТ, Платформы, целевой SFA и PRBC?
12
Q-12Какие должности принимают три отдельных решения Go/No-Go по Core Go-Live, cutover SFA и запуску PRBC?
Рекомендуемое решение: Утвердить документ как концептуальную архитектуру; по завершении Wave 0 принять baseline ТЗ по владению данными, каталогу интеграций, security/NFR и scope пилота. Для этапа 2 утвердить два отдельных charter: (A) fit-gap, TCO, PoC и миграция вариантов Linko, Doctor Sales и собственной SFA; (B) MVP PRBC, SoD и gate стабильности core-контура.
Бизнес-спонсор / руководствоУтверждает scope core-контура, решение buy/build по SFA, бюджет TCO и charter этапа 2 для PRBC.
Дата / решение
Владельцы операций, продукта SFA и модулей PRBCУтверждают обязательные функции, приёмку пилота, статусы/сверку, согласования, SoD, SLA и retention.
Дата / решение
IT-архитектура и безопасностьФиксирует baseline независимого от поставщика контракта SFA, экспорта/миграции данных, NFR, безопасности, API/event PRBC и модели поддержки.
Дата / решение
Основной источник

«Star Group — аудит процессов», редакция 3: 32 процесса, 11 подразделений, 37 рисков, 17 пунктов roadmap и 10 противоречий.

Основа архитектуры

1С:УТ — System of Control; WMS — warehouse execution. На этапе 1 ProTarget является переходной System of Entry, а на этапе 2 заменяется Linko, Doctor Sales или собственной SFA-системой. PRBC подключается только через Integration Platform.

Статус документа

Концептуальное предложение TO BE. Технические параметры, возможности поставщиков и покрытие филиалов подтверждаются через discovery/test.

STAR GROUP • 1С:УТ + ЦЕЛЕВАЯ SFA + PRBC • V1.4 RU20 / 20
STAR GROUP
SFA • СРАВНИТЕЛЬНЫЙ АНАЛИЗ
24 СЕНТЯБРЯ 2026
Платформы торговых представителей • сравнительный анализ

ProTarget и Smartup: полевая система и полная ERP

Возможности двух платформ по рабочим местам агента, экспедитора, супервайзера, склада и оператора, их фактическое состояние в Star Group и открытые вопросы для решения по целевой SFA.

~1 440дублей торговых точек в ProTarget. Главная проблема — не в системе, а в точке ввода данных: ТТ создаются в 1С вручную. A-1
4 главные проблемы, найденные аудитом, — нажмите, чтобы открыть запись
Охват2 платформы • 8 ролей • 22 требования для Узбекистана
МетодОткрытые источники + веб-панели обеих систем в режиме только чтения
ПозицияНейтральная: рекомендация не даётся — факты и вопросы для решения
Результат15 записей аудита • 7 сверок • 11 вопросов вендорам
STAR GROUP • SFA • PROTARGET VS SMARTUP01 / 15 · SFA · АНАЛИЗ
01 / Overview

Две системы — два разных класса

026 критериев

ProTarget — полевой слой и слой доставки поверх 1С. Smartup — полная ERP, которая ведёт продажи, склад, финансы и кадры в одном облаке.

КритерийProTargetSmartup
РазработчикPRO TARGET TOO, Алматы; отдельная панель для Узбекистана (admin.pro-target.uz)Green White Solutions, Ташкент; с 2009 года
Класс системыSFA + доставка + B2B-приложение (для ТТ)Облачная ERP: продажи, склад, финансы, кадры, производство + SFA
МодулиЗаказы и возвраты, Торговые точки, Портфели, Склады/Остатки, Планы, Задания, Промо, Доставка, СинхронизацияПродажа, Склад, Финансы, Кадры и зарплата, Торговый маркетинг, Оборудование, Задачи, Plugin Marketplace
Кто используетStar Group: базы NonFood и Food; каждый бренд — отдельная «организация» A-15Star Beverages: 6 филиалов, 109 пользователей, с сентября 2026 A-14
Масштаб13,85 млрд сум продаж и 13 146 заказов в неделю (NF + Food)147 заказов, 69 рейсов (этап запуска)
Позиция на рынкеШироко распространён у дистрибьюторов брендов (L'Oréal, Mondelez, BIC…)2 000+ компаний, 16 000+ активных пользователей (данные компании)
Связь с архитектурой. В дорожной карте TO BE по целевой SFA принимается отдельное решение Go/No-Go TO BE · Роли систем TO BE · Открытые решения. Этот анализ — набор фактов для этого решения; «1С» здесь — сейчас DMS (на базе 1С), в дальнейшем 1С:УТ.
Источники: сайты вендоров, Google Play, gazeta.uz; фактические цифры — в разделе аудита02 / 15 · SFA · АНАЛИЗ
02 / Roles

Что есть для каждой роли

038 ролей

В полевых ролях обе системы дают современный набор. Разница — в ролях склада и оператора: Smartup закрывает их сам, в ProTarget эта работа остаётся в 1С.

РольОсновная потребностьProTargetSmartup
Торговый агентМаршрут, визит, заказ, промо, долгТрекинг визитов, заказ, планы продаж, автоматические промо, опросы. Высокая доля заказов без визита A-4Маршрут, GPS, чек-лист (фото/форма), офлайн, долг клиента, срок консигнации
ЭкспедиторРейс, сдача, оплата, возвратМаршруты, Автомобили, Рейсы (~36 800 рейсов); отдельное приложение A-15Логистика: дата, транспорт, экспедитор, точки, загрузка по кг/объёму; вес не заполнен A-11
СупервайзерКонтроль команды, KPI, отклоненияКонтроль визитов, планы, дашборд «Супервайзеры»Местоположение в реальном времени, КПЭ, бонусы, оповещение об отклонении от маршрута
СкладОстатки, приход-расход, инвентаризацияТолько «Остатки» (по партиям); сроки пустые A-2Полный склад: закупки, поступления, инвентаризации, перемещения, маркировка
ОператорЗаказ, база ТТ, прайс-листЕдиная база ТТ, дубли ТТ; документы — в 1С A-1Заказы, заявки, возвраты, взаиморасчёты с контролем сроков задолженности
МерчендайзерВитрина, фотоотчёт, планограммаAI-распознавание витрины, опросыAI Shelf Recognition, планограммы, POS, доля на полке, конкуренты
Торговая точкаЗаказ без агентаB2B-приложение есть, но через него 0% заказов A-8Smartup24 B2B и Telegram-бот (24/7)
РуководствоАналитика в реальном времениДашборд: продажи, скидки, эффективность визитов, разрез по брендамДашборды + финансовые отчёты (PnL, ДДС, баланс)
Главная болевая точка Star Group: новые ТТ создаются в 1С вручную. Корпоративный аудит (ред. 3) называет 50–70 в день, внутреннее наблюдение показало ~200 S-1. В обеих системах нужно отдельно проверить ввод ТТ агентом из приложения с GPS и её попадание в 1С.
Метки A-N и S-N — записи аудита SFA, R-N — проблемы аудита AS IS; нажмите, чтобы открыть запись03 / 15 · SFA · АНАЛИЗ
03 / Integration

Когда 1С остаётся основной системой: кто владеет данными

042 сценария
DMS → 1С:УТНоменклатура, цены, остатки, контрагенты, бухгалтерия
⇄справочники
заказы, новые ТТ,
возвраты, оплаты
SFA-слойProTarget или Smartup
⇄маршрут
визит, заказ
Агент • Экспедитор • МерчМобильные приложения
КритерийProTargetSmartup
Роль в архитектуреПолевой слой поверх 1С — функции не дублируютсяПолная ERP; при работе вместе с 1С склад и финансы ведутся в двух местах A-6
Коннектор 1СРаботает: у каждой ТТ есть код 1С (UZ-000…); журнал «Синхронизация» для этой роли пуст A-10Экспорт: заказ, возврат, поступление, перемещение, инвентаризация, оплаты, касса, банк; «Проверка дубликатов: Нет» A-5
Создание ТТСейчас вручную в 1С; в ProTarget — в планах (после ККМ), без срокаВвод нового клиента в мобильном приложении — нужно подтвердить его возврат в 1С
Маршрут сотрудникаВручную в 1С; «Планы визитов» пусты — нужно выяснить, можно ли перенести в ProTargetСобственное планирование визитов; возврат в 1С может не понадобиться
Стоимость интеграцииВ основном выполненаНовый проект; доработки — 400 000 сум/час (страница SLA)
Вывод: для ProTarget ответ простой — учёт в 1С, ProTarget в поле. При выборе Smartup нужно письменно согласовать с вендором, можно ли использовать только SFA-часть вместе с 1С и сколько это стоит.
Поток упрощён; электронные счета-фактуры и фискализация остаются на стороне 1С/DMS04 / 15 · SFA · АНАЛИЗ
04 / Platform

Технические аспекты, цена и поддержка

0511 критериев

У Smartup SLA, цены и интеграции, специфичные для Узбекистана, опубликованы открыто. По ProTarget их нужно запросить у вендора письменно.

КритерийProTargetSmartup
Мобильная платформаAndroid («Protarget PRO»); iOS — требует подтвержденияAndroid и iOS
Офлайн-режимНЕИЗВЕСТНОЕСТЬ
GPS / геофенсингТрекинг визитов есть; в карточке ТТ нет координат A-3GPS-мониторинг и геоаналитика
AI (распознавание полки)ЕСТЬЕСТЬ
Электронные с/ф, маркировкаОткрытых данных нетFactura.uz, Asl Belgisi
ИнфраструктураВ облаке вендора; расположение серверов неизвестноОблако, ЦОД Tier 3, Oracle MAA
SLA / uptimeНе опубликовано99,5%; Critical — решение за 6 часов; Пн–Сб 08:00–19:00
ЦенаНе опубликована~200 000 сум/мес за пользователя (практика); на сайте 120 000 сум A-14
ДоработкиНе опубликовано400 000 сум/час
ВнедрениеРаботает в Star Group, модули расширяютсяВ среднем 4 недели (данные компании)
Язык интерфейсаУзбекский, русскийУзбекский, русский, английский
Источники: smartup24.com, smartup24.com/uz/sla, greenwhite.uz, protarget.kz, Google Play05 / 15 · SFA · АНАЛИЗ
05 / Market fit

22 требования рынка Узбекистана

0622 требования

Идеальная платформа делает три вещи правильно: собирает корректные данные в точке ввода, автоматически выполняет налоговые требования и требования маркировки, работает без интернета и через Telegram.

ProTarget
8419
Smartup
1327
ЕстьЧастичноНетНеизвестно — спросить вендора
ТребованиеПочему важноProTargetSmartup
Регистрация новой ТТ из приложения агента (ИНН/ПИНФЛ, GPS + фото, подтверждение супервайзера)У точек внутри рынков нет адреса; ТТ создаются вручную A-3НЕТНЕИЗВЕСТНО
Контроль дублей по ИНН и радиусу GPSВ ProTarget ~1 440 дублей A-1ЧАСТИЧНОНЕИЗВЕСТНО
Офлайн-приложение, работающее на недорогих AndroidВ регионах пропадает интернетНЕИЗВЕСТНОЕСТЬ
Защита от подмены GPS, подтверждение визита геофенсингомЗаказы без визита — 41–48% A-4НЕИЗВЕСТНОНЕИЗВЕСТНО
Управление маршрутом и днями недели в системе, оптимизацияМаршрут сотрудника сейчас ведётся в 1С вручнуюЕСТЬЕСТЬ
Продажа в долг (насия) и консигнация: блокировка по долгу и кредитному лимитуБольшая часть продаж — в долгНЕИЗВЕСТНОЕСТЬ
Оплата: наличные, Click, Payme, Uzum; касса экспедитораНаличных много, онлайн-оплата растётНЕИЗВЕСТНОЧАСТИЧНО
Van-selling и чек онлайн-кассы (ОФД)В рознице требуется фискальный чекНЕИЗВЕСТНОНЕИЗВЕСТНО
Электронные счета-фактуры: Didox, Faktura.uzВ B2B электронная счёт-фактура обязательнаНЕИЗВЕСТНОЕСТЬ
Маркировка Asl Belgisi: сканирование при загрузке и сдачеМаркируемых товарных групп становится большеНЕИЗВЕСТНОЕСТЬ
Склад: партии, срок годности, FEFOРиск сроков для Food A-2ЧАСТИЧНОЕСТЬ
Экспедитор: рейс, загрузка по кг/объёму, фото сдачи, возвратДоставка — самое дорогое звено A-11ЕСТЬЕСТЬ
Автоматические промо, контроль бюджета по брендамСкидки — 13–17% продаж A-13ЕСТЬЕСТЬ
Мерчендайзинг: AI-витрина, планограмма, фотоотчётЭтого требуют брендыЕСТЬЕСТЬ
KPI и бонусы: агент, супервайзер, командаМотивация привязана к бонусамЕСТЬЕСТЬ
Канал самостоятельного заказа для ТТ (Telegram / приложение)Владельцы магазинов работают в Telegram A-8ЕСТЬЕСТЬ
Портал бренда: каждый бренд видит свои данныеStar Group — многобрендовый дистрибьюторЕСТЬНЕИЗВЕСТНО
Двусторонняя интеграция с 1С, проверка дублей, REST API1С/DMS остаётся основной системой A-5ЧАСТИЧНОЧАСТИЧНО
Персональные данные на серверах в УзбекистанеТребование локализации данныхНЕИЗВЕСТНОНЕИЗВЕСТНО
Интерфейс: узбекский (латиница/кириллица) и русскийАгенты и владельцы магазинов говорят на разных языкахЕСТЬЕСТЬ
Панель качества данных: дубли, пустые поля, ТТ без GPSГлавная проблема — качество данных A-1ЧАСТИЧНОНЕИЗВЕСТНО
Прозрачная цена в сумах, местная поддержка и SLAБюджет и оперативная поддержка A-14НЕИЗВЕСТНОЕСТЬ
Как читать: «Неизвестно» не означает, что возможности нет. У ProTarget неизвестных больше, потому что его документация закрыта. Это не балл, а список вопросов вендору.
Оценка: открытые источники + наблюдения по веб-панелям на 24.09.202606 / 15 · SFA · АНАЛИЗ
06 / Trade-offs

Преимущества и недостатки

0720 пунктов
ProTargetПолевой и дистрибуционный слой
Преимущества
  • Естественно вписывается в архитектуру, где мастер — 1С: склад и финансы не дублируются
  • Уже работает в Star Group в большом объёме: 13 146 заказов в неделю
  • Вся цепочка: агент → экспедитор → приложение ТТ
  • Промо и организации в разрезе брендов — удобно для отчётности брендам
  • AI-распознавание витрины, опросы
Недостатки
  • Цена, SLA, офлайн-режим и iOS не опубликованы
  • Интеграции с налоговыми сервисами и маркировкой Узбекистана неизвестны
  • Низкое качество данных: дубли, пустые типы ТТ, сроки A-1 A-2
  • Модуль создания ТТ ждёт завершения ККМ, срока нет
  • Планы визитов и Задания не используются A-10
SmartupПолная облачная ERP
Преимущества
  • Лидер рынка Узбекистана, местная команда и офис
  • Работает с Factura.uz и Asl Belgisi
  • Закрывает все роли: склад, задолженность, финансы
  • Открытый SLA 99,5% и интерфейс на узбекском
  • Smartup24 и Telegram-бот — ТТ заказывает без агента
Недостатки
  • Если 1С остаётся, большая часть функций избыточна — риск двух источников A-6
  • Новый проект интеграции с 1С: время и деньги
  • Оплата за пользователя: ~200 000 сум/мес A-14
  • Переход с ProTarget: переобучение и период параллельной работы
  • Доработки зависят от очереди вендора
Рекомендация не даётся — решение принимает руководство на этапе Go/No-Go07 / 15 · SFA · АНАЛИЗ
07 / Decision input

Вопросы, которые нужно закрыть до решения

0811 + 3
Письменные вопросы обоим вендорам
  1. Ввод новой ТТ из приложения агента с GPS, ИНН и фото; попадание в 1С с подтверждением
  2. Выбирается ли в приложении агента сегментация (Тип ТТ, Класс, Канал сбыта, Торговая команда)
  3. Управляется ли маршрут сотрудника в системе с возвратом в 1С
  4. Сколько дней работает офлайн-режим, как разрешаются конфликты синхронизации
  5. Экспедитор: оплата, частичная сдача, возврат, van-selling
  6. Интеграция с Factura.uz / Didox и Asl Belgisi (особенно для ProTarget)
  7. В какой стране серверы с данными; как выгрузить данные при прекращении договора
  8. Открытый REST API и документация
  9. Ежемесячная лицензия по каждой роли, стоимость внедрения и доработок
  10. SLA: uptime, время реакции и решения, команда поддержки в Узбекистане
  11. Smartup: можно ли использовать только SFA-часть вместе с 1С и сколько это стоит
Работы, нужные при любом выборе системы
  1. Процесс регистрации ТТ: агент → проверка → 1С (API + Telegram mini app) A-1 A-3
  2. Очистка ~1 440 дублей и правило объединения кодов 1С
  3. Заполнение сроков годности в партиях (в первую очередь для Food) A-2
Почему это важно: большинство текущих проблем вызвано ручным вводом данных. Переход на другую систему не устранит их сам по себе — он перенесёт их в новую систему.
Следующий шаг: отправить вопросы вендорам и внести ответы в эту таблицу08 / 15 · SFA · АНАЛИЗ
STAR GROUP
SFA • АУДИТ СИСТЕМ
24 СЕНТЯБРЯ 2026
Аудит веб-панелей • режим только чтения

Что видно внутри систем

Наблюдения из админ-панелей ProTarget (базы NonFood и Food) и Smartup (Star Beverages). Ни одна настройка не изменена, ничего не сохранено.

15записей аудита: 2 критичных, 4 высоких, 6 средних и 3 для сведения. Нажмите на число — откроются все записи в плавающем окне.
Критичные и высокие — нажмите, чтобы открыть запись
ОхватProTarget NonFood + Food • Smartup Star Beverages
ПериодДашборд: 17–24.09.2026; списки — на 24.09.2026
ДоступАдминистратор организации (ProTarget), TRADE admin (Smartup)
ОграниченияЧасть разделов вернула 403; мобильные приложения не просматривались
STAR GROUP • SFA • АУДИТ ВЕБ-ПАНЕЛЕЙ09 / 15 · SFA · АУДИТ
08 / Evidence base

Что показал аудит

102 системы • 3 базы
13,85млрд сум продаж за неделюProTarget: NF 9,03 + Food 4,82
13 146заказов за неделюNF 7 061 + Food 6 085
~1 440дублей ТТ«Дубли торговых точек»
44%активных ТТ в базе Food8 130 / 18 598
~36 800рейсов экспедиторов в ProTarget«Доставка → Рейсы»
0%заказов, сделанных самой ТТагент — 100%
39лицензий Smartup«ERP users», за пользователя
~200 тыс.сум в месяц за пользователя5 лицензий = 1 000 000 сум
Приоритет
2463
КритичноВысокийСреднийДля сведения
По системам

ProTarget — 10 записей
Smartup — 5 записей

Тип воздействия

Качество данных — 6
Использование — 3
Интеграция — 2
Затраты — 2
Контроль — 1
Контекст — 1

Общий знаменатель: 6 записей из 15 касаются качества данных. Они вызваны не отсутствием функций системы, а ручным вводом и незаполненными справочниками.
Все числа взяты из веб-панелей; значения, посчитанные как число страниц × 10 строк, помечены «~»10 / 15 · SFA · АУДИТ
09 / ProTarget · dashboard

Базы NonFood и Food, 17–24.09.2026

1114 показателей
ПоказательNonFoodFoodЗапись
Организации (бренды)LOREAL, BIC_CXZ_SILVER, Johnson_Veet…Mondelez; Ritter Sport_Heinz_Vitana
Продажи, сум9 025 931 3704 823 106 890A-15
Скидки, сум1 514 050 783 (~17%)648 886 989 (~13%)A-13
Заказы7 0616 085
Средний чек, сум1 278 279792 622
Визиты с заказом / все визиты3 593 / 15 105 (24%)3 103 / 8 760 (35%)
Заказы без визита2 889 (41%)2 897 (48%)A-4
Уникальные SKU1 398148
Активные ТТ / ТТ в базе4 190 / —8 130 / 18 598 (44%)A-7
Дубли ТТ~1 050~390A-1
Сотрудники~610~470
Инициатор заказа—агент 100% • ТТ 0%A-8
Рабочий день / дорога между точками—06:22 / 02:34A-9
«Годность до» (Остатки)01.01.197001.01.1970A-2
Дашборд NonFood — по скриншоту пользователя; Food — admin.pro-target.uz, Главная11 / 15 · SFA · АУДИТ
10 / ProTarget · admin

Модули есть, справочники не заполнены

1210 разделов
РазделЧто увиделиКомментарий
МенюЗаказы и возвраты, Организации, Торговые точки (+ Дубли), Бренды и товары, Портфели и исключения, Склады/Остатки, Сотрудники, Планы, Задания, Промо, Доставка, Синхронизация, НастройкиБухгалтерии, финансов и кадров нет — чистая SFA/дистрибуция
ОрганизацииКаждый бренд — отдельная организация: «LOREAL - SS NF», «Mondelez - SS F»…Поэтому для каждого бренда отдельный логин
Торговые точкиNF ~14 480; импорт/экспорт, вид на карте; код 1С (UZ-000…)«Типы ТТ» пусты; в карточке нет координат, адрес — текстом A-3
Дубли торговых точекNF 105 страниц, Food 39 страницОдной ТТ присвоены два разных кода 1С A-1
СотрудникиЭкспедитор, Менеджер по логистике, Менеджер команды, Торговый представитель…Возможен импорт из Excel
ДоставкаМаршруты (NF ~210, Food ~180), Автомобили, Рейсы ~36 800Рейсы общие для обеих баз
Промо → Акции«BIC metal 31% Сентябрь-2026», «Oreo 228 gr - Регионы - 15,50%»; тип «На корзину»Food: ~1 880 записей, включая удалённые копии A-13
ОстаткиОстатки по партиям (food/nonfood)«Годность до» 01.01.1970 A-2
Задания, Планы визитов, Оборудование, Типы ТТ«Нет данных» или 403Не используются или закрыты для этой роли A-10
СинхронизацияЖурнал пустОбмен с 1С может идти по другому каналу A-10
admin.pro-target.uz • роль: Администратор организации12 / 15 · SFA · АУДИТ
11 / Smartup · Star Beverages

Smartup используется шире, чем SFA

137 разделов
РазделСостояниеКомментарий
Организации7: Администрирование, BERN, STAR BEVERAGES, Гулистан, Зарафшан, Навои, СамаркандФилиалы — отдельные организации
Лицензии«ERP users», за пользователя: 5 + 33 + 1 = 39 (01–30.09.2026)Август: 5 = 1 000 000 сум; сентябрь: 34 = 6 486 667 сум A-14
Пользователи109: агенты (Андижан, Бухара, Джизак, Фергана, Гулистан…), операторы, экспедиторы, бухгалтер/кассирУ одного пользователя может быть несколько ролей
Заказы147; «В обработке», «Отгружен»С агентом, складом, типом оплаты, датой доставки
Логистика69 рейсов: дата, транспорт, экспедитор, точки, кг/объёмВес 0 кг, загрузка 0% A-11
Настройки интеграцииЭкспорт: заказ, возврат, поступление, перемещение, инвентаризация, оплаты, касса, банкВезде «Проверка дубликатов: Нет» A-5
Шаги визита0 ролейШаги визита не используются A-12
Активные модули в меню: Продажа (визиты, планирование, отслеживание, заказы, возвраты, взаиморасчёты) • Склад (закупки, поступления, инвентаризации, перемещения, логистика) • Финансы (касса, банк, проводки, ОСВ, PnL, ДДС, баланс) • Кадры • Торговый маркетинг • Оборудование. Это показывает, что используется полная ERP A-6.
smartup.online • TRADE / Администрирование и филиал STAR BEVERAGES13 / 15 · SFA · АУДИТ
12 / Register

Реестр аудита: 15 записей

142 • 4 • 6 • 3
IDПриоритетСистемаПроблемаПоследствие
A-1КритичноProTarget~1 440 дублей торговых точекОдной ТТ присвоены два разных кода 1С: история продаж, долг и маршрут делятся надвое
A-2КритичноProTarget«Годность до» во всех партиях — 01.01.1970Товар с истекающим сроком не виден; отгрузка по FEFO не работает. Наиболее опасно для Food
A-3ВысокийProTargetВ карточке ТТ нет GPS, «Тип ТТ» пустНавигатор ищет по текстовому адресу; отчёты по сегментации и таргетирование промо невозможны
A-4ВысокийProTarget41–48% заказов — без визитаАгент может ввести заказ, не приезжая в точку: качество визита и фотоотчёт проверить нельзя
A-5ВысокийSmartupПри выгрузке в 1С проверка дублей отключенаПовторно отправленный документ может попасть в 1С дважды: заказ, оплата, касса
A-6ВысокийSmartupСклад, финансы и логистика тоже в SmartupПри работе вместе с 1С/DMS остатки и оплаты ведутся в двух местах — два «источника истины»
A-7СреднийProTargetВ базе Food активны только 44% ТТБольше половины базы — неактивные точки или дубли: маршруты и планы строятся по неверной базе
A-8СреднийProTargetЗаказы от самих ТТ — 0%Оплаченный B2B-канал не работает; нагрузка на агентов не снижается
A-9СреднийProTargetДорога между точками 02:34 — сомнительное значениеБольшая часть рабочего времени агента выглядит как «в пути»: GPS-трек или расчёт могут быть неверными
A-10СреднийProTargetСинхронизация, Планы визитов и Задания пустыМаршруты и задачи остаются в 1С/Excel; ошибки синхронизации отследить нельзя
A-11СреднийSmartupВ рейсах вес 0 кг, загрузка 0%Планирование вместимости машин и логистические KPI не работают
A-12СреднийSmartup«Шаги визита» не настроеныСтандарт визита (фото, анкета, порядок) не обязателен
A-13Для сведенияProTargetСкидки — 13–17% продажПромо-бюджет нужно контролировать в разрезе брендов
A-14Для сведенияSmartup39 лицензий, ~200 000 сум/мес за пользователяЗатраты напрямую зависят от числа пользователей
A-15Для сведенияProTarget13,85 млрд сум и 13 146 заказов в неделюProTarget — основной канал продаж Star Group: замена несёт большой операционный риск
Нажмите на строку — полная запись откроется в плавающем окне • ID совпадают с метками раздела анализа14 / 15 · SFA · АУДИТ
13 / Data quality

Как разрешены расхождения между источниками

157 сверок
IDРасхождениеКак разрешено
S-1Сколько ТТ создаётся в день
Корпоративный аудит (ред. 3): Иброхим создаёт 50–70 ТТ в день
Внутреннее наблюдение (сентябрь 2026): ~200 в день
Показаны оба значения; нужно замерить в течение 5 рабочих дней
S-2Количество ТТ в базе Food
Дашборд: «Всего в БД» 18 598
Список «Все торговые точки»: ~12 270 (1 227 страниц)
Использовано число с дашборда; разница может объясняться фильтром или ограничением роли
S-3Цена Smartup
Сайт: 120 000 сум/мес за пользователя
Star Beverages: 5 лицензий = 1 000 000 сум
Использована фактическая цена (~200 000 сум)
S-4Вендор ProTarget
protarget.kz — PRO TARGET TOO, Алматы
Панель Star Group: admin.pro-target.uz
Узбекский инстанс; нужно установить сторону договора
S-5ProTarget TMS (экспедиторы)
Корпоративный аудит: «TMS экспедиторов тестируется»
В панели ~36 800 рейсов
Рейсы есть; нужно подтвердить полноценный запуск
S-6Термин «1С»
В исходном тексте — общее «1С»
Корпоративный аудит: DMS (на базе 1С) → 1С:УТ
В документе «1С» = сейчас DMS, в дальнейшем 1С:УТ
S-7Доля скидок
Дашборд: продажи и скидки отдельно
Расчёт: скидки / продажи
До или после скидки считается сумма продаж — запросить у вендора
Приоритет источников
  1. Веб-панель системы (24.09.2026) — на первом месте
  2. Корпоративный аудит Star Group, редакция 3
  3. Открытые страницы вендоров
  4. Журналистские источники
Открытые источники
  • protarget.kz • Protarget PRO — Google Play
  • smartup24.com • Smartup SLA
  • greenwhite.uz — Smartup
  • gazeta.uz, 29.06.2026
Правило: фактическое число в системе приоритетнее заявления вендора15 / 15 · SFA · АУДИТ