Ақша сомасы: 0
Өтінімдер саны: 2
26.06.26 (қоса алғанда)
Оплата
Идея
Акт міндеттері
Medicine
Басқа технологиялық шешімдер
БҚ/АЖ
Исторически финансовый учет в большинстве частных медицинских центров СНГ — это самая уязвимая операционная зона, полная ручного труда и ошибок, связанных с человеческим фактором. Ручной перенос данных и прямые финансовые потери: Сейчас администраторы клиник ведут учет платежей в таблицах Excel или сторонних кассовых программах (например, 1С), которые физически никак не связаны с медицинским календарем и ЭМК пациентов . Кассиру приходится вручную перепечатывать услуги из бумажного назначения врача в кассу. Это регулярно приводит к забытым позициям в чеке, опечаткам в суммах и недополученной прибыли. Отсутствие цифрового следа и безответственность: В устаревших POS-системах невозможно доподлинно отследить, кто именно из операторов регистратуры принял оплату или сделал несанкционированную скидку, так как учетные записи в программе часто общие на весь филиал . Сетевые сбои и дубликаты (Race Conditions): При нестабильном интернет-соединении (что часто бывает в клиниках, расположенных на цокольных этажах) кассиры могут несколько раз нажать кнопку «Оплатить». В старых системах это приводит к созданию дублирующих счетов и искажению ежедневной выручки. Потеря тиынов из-за архитектуры БД: Использование программистами неправильных типов данных (вроде float или double) для хранения денег в старых базах данных часто приводит к "магическим" ошибкам округления при сведении баланса за большой период
Разработка надежного финансового ядра (Core & Cash) решит фундаментальные проблемы медицинского администрирования и станет прочным плацдармом для внедрения сложных банковских интеграций (Kaspi) и аналитики на следующих этапах: Снижение ошибок учета до 0%: Благодаря автоматическому подтягиванию услуг в POS-терминал из справочника и модуля Календаря, человеческий фактор при выставлении счетов будет полностью ликвидирован . Абсолютная безопасность транзакций: Внедрение архитектуры идемпотентных запросов обеспечит 100% гарантию того, что двойная оплата одного счета физически невозможна даже при сбоях в сети . Кристальная прозрачность и ответственность: Тотальный Audit Log и жесткая привязка каждой транзакции к индивидуальному JWT-токену сотрудника и конкретной активной смене (shift_id) исключат возможности для финансовых махинаций персонала. Сверхбыстрая работа и сервис без очередей: Оптимизированная архитектура микросервиса позволит загружать POS-экран кассира менее чем за 1.5 секунды и проводить оплату наличными со скоростью до 600 миллисекунд (целевой отклик P95), радикально ускоряя обслуживание пациентов в холле клиники.
Амина Агзамова
Тапсырманың (жобаның) мақсаты мен сипаттамасы
Заложить отказоустойчивый, масштабируемый и высокопроизводительный фундамент для всего финансового контура клиники. Главная задача этого блока — спроектировать надежную архитектуру базы данных (счета, транзакции, позиции чеков), внедрить строгую валидацию прав доступа через JWT-токены на уровне API-шлюза и реализовать базовый, но самый критичный процесс оплаты наличными средствами с автоматическим расчетом сдачи клиенту и защитой от двойного проведения платежей. Детальное описание функционала и технических решений: Архитектура БД и финансовые типы данных: Проектирование ключевых таблиц в PostgreSQL: invoices (счета), invoice_items (позиции счета) и transactions (транзакции) . Фундаментальное техническое требование — все суммы (цены, скидки, итоги, сдача) должны храниться в базе данных исключительно в строгом финансовом формате NUMERIC(12,2) (категорический запрет на использование плавающего типа данных float), а все критические вычисления должны происходить на стороне бэкенда для исключения погрешностей на клиенте . Справочник услуг (Services Database): Разработка и интеграция таблицы services (вызов через эндпоинт GET /api/v2/services?search=) для автоматизированного добавления позиций (медицинских услуг или товаров) в счет . Каждая позиция в чеке будет жестко привязана к справочнику, включая ее стоимость по умолчанию и ставку НДС (vat_pct) . RBAC и защита операций (JWT Middleware): Каждая кассовая операция (создание счета, применение скидки, проведение платежа) должна проходить через жесткий фильтр безопасности. Middleware проверяет JWT-токен кассира, валидируя обязательные поля: role (уровень прав), branch_id (ограничение видимости счетов только своим филиалом), sub (ID сотрудника) и max_discount_pct (допустимый предел персональной скидки) . Самое важное: сервер проверяет наличие shift_id — если у пользователя нет открытой кассовой смены, операция блокируется со статусом HTTP 403 NO_ACTIVE_SHIFT . Флоу оплаты наличными (Cash Flow): Разработка алгоритма приема наличности без внешней банковской интеграции . Сервер принимает параметр amount_paid (сколько дал пациент). Если принятая сумма меньше итоговой суммы счета (total), API автоматически отклоняет транзакцию с ошибкой 422 INSUFFICIENT_AMOUNT . Сдача рассчитывается на клиенте реактивно (change = amount_paid - total) . При успешном проведении, статус счета атомарно переводится сервером в статус paid (или partial), после чего клиенту отправляется WebSocket событие payment.completed для мгновенного обновления интерфейса POS-терминала . Идемпотентность и Аудит (Audit Log): Внедрение механизма защиты от сетевых сбоев и двойных кликов. Критический Endpoint POST /api/v2/invoices/:id/pay требует обязательной передачи заголовка Idempotency-Key . При дублированном запросе сервер вернет закешированный оригинальный ответ без создания двойной транзакции . Одновременно с этим, любые действия жестко логируются в глобальную таблицу audit_log, где сохраняется кто сделал операцию, какое было действие и JSON-состояние чека before и after
Whatsapp
