Сумма: 40000
Количество заявок: 0
18.06.26 (включительно)
Обсуждается
Идея
Задачи ИКТ
Medicine
Другие технологические решения
ПО/ИС
Финансовые процессы в большинстве частных клиник остаются одним из самых уязвимых и слабо автоматизированных участков: Ручной и дублирующий учет: Клиники ведут финансовый учет в Excel, амбарных кассовых книгах или в сторонних программах (например, 1С), которые никак не связаны с медицинским расписанием . Администраторам приходится вручную переносить данные об оказанных услугах из карточки пациента в кассу, что неизбежно приводит к опечаткам, потере позиций в чеке и недополученной прибыли . Слепая зона по задолженностям: Из-за оторванности кассы от календаря координаторы и врачи не видят в момент визита, что за пациентом числится старый долг за предыдущие приемы . В результате клиника кредитует пациентов, теряя значительные средства. Хаос в возвратах и скидках: Оформление возврата часто требует участия бухгалтерии и занимает до нескольких дней . Кассиры бесконтрольно применяют скидки, а при пересменке невозможно отследить, кто именно из операторов допустил недостачу в кассе, так как смена не привязана к цифровому профилю пользователя . Непрозрачность для руководства: Инвесторы и главные врачи не имеют доступа к аналитике в реальном времени. Нет понимания распределения выручки по методам оплаты (сколько пришло через Kaspi, а сколько наличными), что затрудняет финансовое планирование и контроль кэш-флоу .
Запуск биллингового микросервиса радикально трансформирует финансовую дисциплину медицинского учреждения: Нулевой уровень ошибок учета: Благодаря автоматическому подтягиванию услуг из Календаря и ЭМК прямо в POS-терминал, ошибки при ручном переносе и выставлении счетов снизятся до 0% . Кардинальный рост сбора долгов: Вывод баланса пациента в интерфейс кассы и шапку ЭМК позволит администраторам и координаторам видеть задолженности в режиме реального времени, что по прогнозам увеличит собираемость долгов на 30% . Тотальная персональная ответственность: Обязательное открытие смен с фиксацией наличности (opening_balance) и генерация именных Z-отчетов при закрытии (closing_balance) исключат возможности для финансовых манипуляций и недостач среди кассиров . Ускорение операционных процессов: Автоматизация возвратов (в том числе через Kaspi Refund API) сократит время оформления возврата с 3 дней до 15 минут . За счет интеграции с ChatApp выдача чеков будет происходить мгновенно в WhatsApp, повышая лояльность пациентов . Абсолютная прозрачность для бизнеса: Руководство получит доступ к финансовым дашбордам (запросы к которым идут через Read Replica БД, чтобы не нагружать кассы), где в реальном времени будут отображаться KPI по выручке, среднему чеку и разбивка по всем методам оплаты
Амина Агзамова
Цель и описание задачи (проекта)
Создать отказоустойчивое, высокопроизводительное и идемпотентное платежное ядро, которое полностью устранит разрыв между медицинским приемом и финансовым учетом. Касса должна бесшовно интегрироваться с Интерактивным календарем и Электронной медицинской картой (ЭМК), обеспечивая моментальное выставление счетов, прозрачную обработку платежей (включая Kaspi QR и рассрочки) и автоматическое формирование фискальной и аналитической отчетности . Детальное описание функционала и технических решений: Интерфейс POS-терминала: Разработка единого рабочего экрана кассира (двухколоночный layout) на базе Vue.js 2, где весь флоу проведения оплаты умещается без необходимости скролла . Слева отображается состав счета (услуги, цены, скидки), справа — панель оплаты с интерактивным нумпадом 3×4 для быстрого ввода сумм и автоматического расчета сдачи клиентом по формуле Сдача = Принято − Итого . Методы оплаты и Смешанный биллинг: Поддержка множества методов оплаты: Наличные, банковские карты/POS, Kaspi QR и Kaspi Рассрочка . Реализуется сложная механика «Смешанной оплаты», позволяющая разбить один чек на части (например, часть оплатить наличными, а часть — через QR), при этом сервер создает две отдельные транзакции с валидацией совпадения сумм вплоть до тиына . Глубокая интеграция с Kaspi Pay API: При выборе Kaspi QR бэкенд DCH отправляет запрос к Kaspi Pay API, генерируя динамическую ссылку и QR-код . Интерфейс начинает поллинг (каждые 3 секунды в течение 15 минут) для проверки статуса . Дополнительно внедряется прием входящих Webhooks от Kaspi с обязательной верификацией криптографической подписи HMAC-SHA256 для защиты от подмены статуса . Строгое управление кассовыми сменами: Внедрение системы материальной ответственности. Кассир не может провести ни одной операции без открытой смены (наличие shift_id в JWT-токене проверяется Middleware) . При закрытии смены система автоматически подбивает баланс, сравнивает расчетную сумму с фактической наличностью в кассе, генерирует PDF Z-отчет (через pdfkit или puppeteer) и сохраняет его в S3-хранилище . Также доступна функция промежуточной инкассации . Жизненный цикл счета и контроль долгов: Система поддерживает статусы: draft, pending, partial, paid, debt, refunded, cancelled . Если пациент вносит лишь часть суммы, остаток автоматически фиксируется как долг, который сразу же подсвечивается координаторам и врачам в шапке ЭМК пациента . Модуль возвратов и скидок: Оформление возвратов доступно только из статуса paid и требует обязательного заполнения текстовой причины (минимум 10 символов) . Система скидок строго контролируется JWT-токеном: например, координатор может сделать скидку максимум до 10%, в то время как администратор не имеет ограничений . Интеграции и Уведомления: После успешной оплаты система автоматически генерирует фискальный/информационный чек в формате PDF и отправляет его пациенту на WhatsApp (через ChatApp) или Email . Если оплачивается курс лечения, DCH мгновенно отправляет Webhook в Bitrix24, переводя сделку на этап «Оплачено» (UF_PAYMENT_STATUS = 'paid') . Идемпотентность и безопасность БД: Все суммы в PostgreSQL хранятся в строгом финансовом типе NUMERIC(12,2) . Для исключения риска двойных списаний (например, если кассир дважды кликнул на кнопку при плохом интернете), API требует заголовок Idempotency-Key . Все кассовые действия тотально записываются в таблицу audit_log