Личный кабинет партнёра с договорными ценами и остатками из 1С
Партнёр видит свои цены и остатки, а менеджеру остаётся то, что действительно требует человека
Проверяется: прогон прав по ролям и ежедневная сверка
Средний бизнесРаботаем по NDA
Партнёрам нужны актуальные цены, остатки и статусы, а получают они их по звонку или в файле. Менеджеры тратят день на перенос заказов и ответы на одни и те же вопросы. Конструктор или модуль сайта не вмещает договорные цены, отсрочки и разные склады, а данные нельзя отдавать чужому облаку.
Что съедает срок и бюджет на самом деле
Интерфейс здесь самая лёгкая часть. Остальное ломается так.
Цены лежат в файле у менеджера
договорные условия никогда не вносились в учёт. Прежде чем показать цену в кабинете, её нужно сначала завести в источник.
Остаток без резерва врёт
кабинет показывает «в наличии», а менеджер уже резервировал позицию под другого. Без вычитания резервов заказ приходится отменять.
Партнёр видит чужое
ошибка в правах открывает цену или заказ соседа. Права проверяет сервер на каждый запрос, и это проверяют прогоном из-под каждой роли.
Данные устаревают
кабинет работает как копия, и если обмен остановился, пользователь видит вчерашнее и не знает об этом. Нужна метка актуальности.
Ограничение, которое определяет решение
Договорные цены и данные клиентов могут быть закрыты договорами или политикой безопасности, поэтому кабинет стоит на ваших серверах или у выбранного вами хостера. Персональные данные граждан России обычно должны храниться на серверах в России. Оферту, соглашение с пользователями и статус оператора персональных данных готовит юрист заказчика.
Как проверить, что работа сделана
Приёмка держится на трёх проверках. Прогон прав: из-под каждой роли пробуют открыть чужие цены, заказы и документы, все попытки должны быть отклонены сервером.
Сверка с учётом: раз в сутки сравниваются число заказов, суммы и выборка остатков, расхождения попадают в журнал.
Поведение при сбое: обмен с 1С останавливается, кабинет показывает метку актуальности, заказ сохраняется в очереди и после восстановления проходит без дубля.
О чём спросить любого подрядчика
- Откуда кабинет берёт цену и остаток и что видит партнёр, если 1С недоступна.
- Как проверяются права: покажите план прогона из-под каждой роли.
- Вычитаются ли резервы из остатков и кто их ведёт.
- Где хранятся данные и кому принадлежит код с первого коммита.
- Что входит в сопровождение и кто отвечает за обмен, если у 1С поменяется конфигурация.
Как мы идём по этапам
На каждом этапе назван результат, который остаётся у заказчика. Остановиться можно после любого.
- Таблица «поле, источник, хозяин»Выясняем, откуда берутся цены, остатки и статусы и есть ли они в учёте. Результат: список того, что можно показывать сейчас, и того, что сначала нужно завести.
- Роли и праваЗаписываем, что видит дилер, поставщик, менеджер и администратор. Результат: матрица ролей в проверяемом виде.
- ПрототипКликабельный на образцах данных, показываем нескольким партнёрам и правим до написания кода.
- Разработка и обменИнтерфейс, права, очередь обмена с 1С, журнал. Раз в две недели показываем рабочую версию на стенде.
- Запуск на двух партнёрахЗаводим одного-двух партнёров, смотрим журнал и обращения, потом подключаем остальных. Передаём исходный код, инструкцию и регламент сопровождения.
Как это обычно устроено внутри
Типовая схема: веб-приложение с ролевой моделью, база PostgreSQL хранит копию цен и остатков, обновляемую по изменению, и профили пользователей. Заказ уходит в очередь и в 1С через HTTP-сервисы, статус возвращается событием. Права проверяются на сервере, действия пишутся в журнал, а метка актуальности данных показывается рядом с остатком.
- PostgreSQL
- REST API
- HTTP-сервисы 1С
- Очередь сообщений
- Ролевая модель
- Docker
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.