BORNLI / о разработке по делу
Приложение для оптовых поставок лекарств: заказ и партии.
Как согласовать заказ аптечной сети, когда общий остаток есть, но нужное количество не проходит по сроку годности. Показываем собственный модельный интерфейс и границы интеграции.
Кому подходит
Клиентский заказ — поверх работающего отраслевого учёта.
Приложение для фармдистрибьютора имеет смысл, когда закупщику неудобно оформлять и согласовывать B2B-заказ, а менеджер вручную переносит условия между письмами и учётной системой. В первой версии можно связать заказ, проверку подходящей партии и подтверждение резерва. Создавать заново весь отраслевой учёт для этого не требуется.
Начните с проверки своей системы. В официальном описании «1С:Управление аптечной сетью» предусмотрены партионный учёт с серией и сроком годности, а также обмен с МДЛП в рамках поддерживаемой функциональности. Это возможности названного продукта, а не подтверждение совместимости с вашей конфигурацией. Если существующий кабинет уже решает задачу, разумнее настроить его.
Отдельную разработку стоит оценивать для конкретного неудобного участка: покупатель не видит ограничения по партии, частичный объём согласуется в переписке или менеджер не может отличить запрос от подтверждённого резерва. Для более общего процесса повторных оптовых заказов есть отдельный разбор приложения для оптовой компании.
Модельный сценарий · концепция BORNLI
120 упаковок — это ещё не все условия заказа.
Для статьи мы собрали демонстрационный интерфейс заказа. Покупатель, товар, партии и события условные; реальная учётная система и МДЛП не подключены. Это концепция рабочего процесса, не клиентское внедрение и не рекомендация лекарственного препарата.
В заказе PO-204 указано 120 упаковок тестовой позиции F-204. Плановая поставка — 9 ноября 2026 года. Модельный покупатель требует, чтобы на эту дату оставалось не менее 12 месяцев до окончания срока годности. Для примера минимальная дата — 9 ноября 2027 года. Эти 12 месяцев являются условием данного заказа, а не нормой для всех препаратов или покупателей.
Предлагаем хранить рядом с количеством дату поставки, условие по сроку, разрешение на частичный объём и правило замены позиции. Требования привязываются к версии заказа. Если покупатель изменил дату или условия после подбора партии, прежний результат нельзя незаметно оставить подтверждённым.
Проверка доступности
На складе 130 упаковок. Подходят только 90.
В демонстрации есть две серии. B-22 содержит 90 упаковок со сроком годности до 30 апреля 2028 года. A-14 содержит 40 упаковок до 31 декабря 2026 года. Общий остаток равен 130, но вторая серия не проходит по условию покупателя. Для этого заказа подходящий объём — 90; ещё 30 не покрыты.
Интерфейс показывает причину ограничения непосредственно в таблице партий. Менеджеру не нужно вычислять её по отдельному файлу, а закупщик не получает обещания полной поставки только потому, что общий остаток больше заказа. В этом сценарии система предлагает частичное согласование. Другую серию или аналог позиции она автоматически не подставляет.
Подбор в кабинете ещё не создаёт резерв. Перед окончательным подтверждением сервер должен заново проверить доступное количество, актуальность условий и разрешённость операции в системе заказчика. Если данные устарели или часть серии уже занята другим заказом, клиенту нужно показать новое предложение, а не сохранять старую зелёную отметку.
Подтверждение и остаток
Согласовали 90. Оставшиеся 30 не исчезли.
В прототипе менеджер отмечает, что покупатель подтвердил частичный объём. Только после этой отметки доступна кнопка согласования. Модель возвращает резерв R-204: 90 упаковок B-22 по второй версии PO-204. Оставшиеся 30 показаны отдельно как количество без резерва. Отгрузка не выполнена, заказ целиком не закрыт.
Для рабочего приложения предлагаем хранить основание согласования, сотрудника, время, версию условий и ответ учётной системы. Кнопка «Отправить» подтверждает лишь действие пользователя; номер резерва появляется после положительного ответа принимающей системы. Если ответа нет, нужен отдельный статус проверки, а не преждевременное «Готово».
Повторная проверка в нашей демонстрации возвращает тот же R-204 по ключу PO-204-v2. Она не добавляет второй резерв. В реальном проекте сначала нужно проверить, умеет ли учётная система находить результат прежней операции и предотвращать повторную запись. Если такой гарантии нет, неопределённый ответ требует ручного разбора до новой отправки.
Источники и ответственность
У каждой цифры и каждого действия должен быть владелец.
| Данные или решение | Предлагаемый источник | Что проверить до разработки |
|---|---|---|
| Позиция, серия, срок годности | Действующая учётная система | Идентификаторы, качество справочника, права на чтение |
| Условия конкретного заказа | Зафиксированное решение покупателя | Версии, согласование частичного объёма, допустимые изменения |
| Доступный остаток и резерв | Серверная операция в учёте | Конкурирующие заказы, повтор, отмена, поиск результата |
| Отгрузка и связанные документы | Установленный процесс заказчика | Какие подтверждения можно показывать клиенту и когда |
Вопросы маркировки, ограничений оборота, работы с сериями и документов нужно отдельно согласовать с профильными специалистами заказчика. Важно знать установленную конфигурацию и версию, реальные операции, действующие правила и границы доступа. Наличие красивого клиентского интерфейса не доказывает соответствие системы этим требованиям.
Мы здесь не задаём юридические нормы, правила отпуска или медицинские рекомендации. Пример ограничен B2B-заказом и согласованием партии. Если требуется изменить регулируемый процесс, его сначала описывают и проверяют специалисты, а затем он становится частью технического задания.
Первая версия
Проверить исключения до подключения всех покупателей.
Первый объём можно ограничить одним типом покупателя, одним способом заказа и одной учётной системой. Согласуйте, кто оформляет запрос, кто подтверждает частичный объём и где хранится результат. Нативное мобильное приложение стоит выбирать после проверки роли и условий работы; для закупщика, который работает за компьютером, может быть достаточно удобного веб-кабинета.
- Неполный подходящий остаток. Заказ на 120 не должен превратиться в обещание 120, когда подходящих упаковок только 90.
- Изменение условий. Новая дата поставки или правило по сроку требует повторной проверки.
- Конкурирующий резерв. Между просмотром и подтверждением остаток мог измениться; сервер возвращает актуальный исход.
- Потерянный ответ. Повтор не создаёт ещё один резерв, а сначала выясняет результат прежней операции.
- Отзыв согласования. Отмена имеет явный результат; нельзя скрыть незавершённую отмену сменой статуса в кабинете.
Пользу будущего пилота оцениваем по времени согласования, числу исправлений и расхождениям между обещанным и подтверждённым объёмом. В этой концепции эти показатели не измерялись. Стоимость и срок зависят от обмена, правил и исключений, а не от одного количества экранов.
Опишите свой процесс заказа в форме BORNLI: кто покупатель, какая учётная система используется и где сейчас приходится перепроверять данные вручную. Для первого разбора достаточно обезличенного описания процесса; реальные документы и сведения о пациентах не нужны.
От идеи к конкретике
Покажем, как может работать ваш продукт.
Обсудим задачу и материалы, затем подготовим бесплатный кликабельный прототип за 24 часа. До договора.
Обсудить прототип ↗