[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2fgi7dqjhlnnn":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":9,"previewImage":11,"headMarkup":12,"projectUrl":9,"bodyMd":13,"bodyHtml":14},"ratinovclinic","Автоматизация 14 медцентров: план лечения, схема тела и платёжная система FINIK",true,"21.07.2026 18:09:10","2026-07-21T18:09:10.266Z",null,"Как мы оцифровали 14 медцентров в России, Казахстане и Кыргызстане: от бумажного плана лечения до интерактивной сетки с 43 зонами тела и интеграции местной платёжной системы FINIK.","\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F5bcd60ccf1f9.webp",[],"# Кейс: Автоматизация сети клиник лечения позвоночника — план лечения, схема тела и платёжная система в Битрикс24\n\n## О клиенте\n\nКлиника Ратинова — сеть из 14 медицинских центров в России, Казахстане и Кыргызстане, специализирующаяся на безоперационном лечении межпозвоночной грыжи методом модулируемой резорбции. Основатель — Андрей Сергеевич Ратинов, невролог-вертебролог с многолетней практикой. Клиника принимает более 175 пациентов в день, за всё время помогла более 90 000 человек. С 2025 года — официальный медицинский партнёр национального олимпийского комитета Киргизии.\n\nОсобенность бизнес-процессов: пациент проходит курс из 10–14 процедур, каждая услуга привязана к конкретной зоне тела и дню лечения. Услуги продаются пакетами — 5, 7 или 10 сеансов. Оплата принимается в Кыргызстане через местную платёжную систему FINIK (AversPay), встроенные решения Битрикс24 для этого региона не работают.\n\n## С чем пришли: 5 болевых точек\n\n**1. Ручное планирование лечения.** Врач на приёме записывал план на бумаге: список процедур, дни, зоны воздействия. Медсестра потом вручную сверяла график. При изменении плана (замена услуги, перенос дня) бумажка переписывалась, старая версия терялась.\n\n**2. Разрозненный учёт оплат и выполненных процедур.** Оплата фиксировалась в счетах, выполнение — в отдельной таблице. Не было связи «оплатил 7 сеансов — посетил 3 — осталось 4». Медсестра не видела, какие услуги оплачены, а какие нет. При возврате одного сеанса из пакета ломалась вся арифметика.\n\n**3. Отсутствие привязки процедуры к зоне тела.** Врач указывал зоны воздействия текстом в комментарии. Медсестра могла перепутать «плечевой сустав левый» с «плечевой сустав правый». Не было визуального контроля: ни врач при назначении, ни медсестра при выполнении не видели схему тела с отмеченными зонами.\n\n**4. Платёжная система не работает в Кыргызстане.** Встроенные платёжные решения Битрикс24 не поддерживают кыргызстанские эквайринги. Клиника не могла отправлять пациентам ссылки на оплату через FINIK — местную систему QR-платежей. Приходилось выставлять счета вручную и ждать подтверждения из банка.\n\n**5. Высокие требования к скорости.** В карточке сделки нужно показывать десятки сущностей одновременно: счета, коммерческие предложения, строки товаров, планы лечения. Без продуманной архитектуры загрузка такого объёма данных заняла бы около минуты — недопустимо для врача, который ведёт приём в реальном времени. При открытии вкладки «План лечения» в карточке сделки загрузка данных занимала 53 секунды. Причины: последовательные REST-запросы к Битрикс24 API (каждый счёт, каждое КП, каждая строка товара запрашивались отдельно), отсутствие кэширования справочников.\n\n## Решение 1. Редактор плана лечения: от бумажки к интерактивной сетке\n\nВ карточку сделки воронки «Приём врача» добавлена вкладка «Лечение». Врач выбирает услуги из каталога товаров, указывает дни выполнения в 14-дневной сетке и настраивает зоны воздействия.\n\nМеханика: услуги подгружаются из каталога товаров Битрикс24 — всегда актуальный список, деактивированные позиции скрыты. Для каждой услуги врач проставляет дни: нажатие «+» в ячейке добавляет сеанс, «−» убирает. План сохраняется единым JSON-объектом в пользовательское поле сделки. При сохранении автоматически синхронизируются товары сделки — вкладка «Товары» заполняется по стандартной схеме Битрикс24 (номенклатура + количество).\n\nРезультат: врач формирует план лечения за 2–3 минуты вместо заполнения бумажного бланка и отдельного внесения товаров в сделку. Все версии плана хранятся в истории поля сделки\n\n![План лечения в карточке сделки](\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F5bcd60ccf1f9.webp)\n\n![Редактор плана лечения](\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F905be2558386.webp)\n\n, а не на глаз — погрешность позиционирования менее 3% от размера схемы. При выборе зоны врачом на схеме загорается кружок с номером зоны. Список из 43 чекбоксов дублируется слева от схемы — можно выбрать как кликом по телу, так и отметкой в списке.\n\nПри сохранении плана список зон записывается в тот же JSON вместе с днями. На вкладке «Лечение» медсестра видит общую схему тела: все зоны из всех услуг плана наложены на одно изображение. Одинаковые зоны разных услуг показываются одним кружком. При наведении на кружок — подсказка: название зоны и список услуг, которые на неё назначены. Под названием услуги в таблице выводятся компактные бейджи с номерами зон.\n\nРезультат: врач видит зоны воздействия в момент назначения, медсестра — перед выполнением. Исключена путаница «левое\u002Fправое», «латеральная\u002Fмедиальная».\n\n![Схема тела с 43 зонами](\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F27f29cdb1824.webp)\n\n. Ячейки окрашены по статусу:\n\n- Синий — «Оплачен» (услуга куплена, ожидает выполнения)\n- Зелёный — «Выдан» (процедура выполнена, отмечена медсестрой)\n- Оранжевый — «Возврат» (оплата отменена, процедура не оказывается)\n- Серый — «Не оплачен» (услуга в плане, но не куплена)\n\nМедсестра нажимает на синюю ячейку оплаченного дня — открывается попап «Отметить выдачу». В нём уже подставлен врач из основной сделки (поле UF_CRM_1730267788), указана текущая дата. Если нужно — дату можно изменить: процедуру, выполненную вчера, медсестра отмечает задним числом (актуально при сбоях интернета или портала). При подтверждении создаётся смарт-процесс (entityTypeId=1122), в который записываются:\n\n- Услуга\n- Врач (из основной сделки)\n- Медсестра (текущий пользователь, нажавший кнопку)\n- Счёт, с которого списана оплата\n- Медцентр, оказавший услугу\n- Медцентр, продавший услугу\n- Дата плановая и дата фактическая\n\nПовторное нажатие на уже выданную ячейку невозможно — она заблокирована. Неоплаченные и возвратные ячейки также неактивны.\n\nРезультат: медсестра видит полную картину по пациенту за 2–3 секунды после открытия вкладки. Никаких отдельных таблиц и сверок.\n\n![План\u002Fфакт процедур](\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F7c1f9a565fd2.webp)\n\n![Отметка выдачи процедуры](\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F0af4e5a0afa9.webp)\n\nранее возникала ошибка: возврат обнулял все оплаченные услуги до статуса «Не оплачен». Например: куплено 5 сеансов, 1 выполнен, сделан возврат 1 сеанса — система показывала 0 оплаченных вместо 4.\n\nИсправленная логика: возврат гасит оплаченные единицы с конца списка. Выданные (уже оказанные) процедуры возврат не трогает. Если возврат больше остатка оплаченных — излишек идёт на неоплаченные с конца. В интерфейсе возвратные дни отмечены оранжевым цветом и заблокированы для выдачи.\n\nРезультат: арифметика всегда сходится. Куплено 5, возврат 1, выполнено 2 → 2 оплаченных ждут выдачи, 1 возврат.\n\n## Решение 5. Платёжная система FINIK через AversPay\n\nДля приёма оплат в Кыргызстане разработан модуль интеграции с AversPay — местным эквайрингом, поддерживающим QR-платежи через систему FINIK.\n\nСхема работы: при выставлении счёта в Битрикс24 формируется запрос к API AversPay. Платёж подписывается RSA-ключом (приватный ключ хранится на сервере). В запросе передаются: сумма, ID сделки, название медицинского центра, ФИО пациента, список услуг. После оплаты AversPay отправляет вебхук на endpoint приложения — оплата автоматически проводится в Битрикс24.\n\nРезультат: клиника получила ссылки на оплату, которые можно отправлять пациентам по SMS. Оплата проводится за 2–3 минуты вместо ручного подтверждения из банка.\n\n## Решение 6. SMS-уведомления\n\nНастроена отправка SMS со ссылками на оплату. Пациент получает сообщение, переходит по ссылке, оплачивает QR-кодом через FINIK. После оплаты статус счёта в Битрикс24 обновляется автоматически.\n\n## Решение 7. Производительность: архитектура быстрой загрузки с первого дня\n\nС самого начала мы заложили архитектуру, исключающую долгую загрузку. В карточке сделки одновременно отображаются счета, коммерческие предложения, строки товаров и план лечения — при 5 КП и 10 счетах это десятки сущностей, которые нужно показать мгновенно.\n\nКлючевые решения, заложенные в архитектуру:\n- Пакетная загрузка данных — до 20 одновременных запросов к API Битрикс24\n- Кэширование справочников и фильтров — повторные обращения не тратят время\n- Переиспользование загруженных данных между разными этапами обработки\n- Исключение дублирующих вызовов — строки счетов загружаются один раз для всей карточки\n- Параллельная загрузка товарных позиций по разным коммерческим предложениям\n\nРезультат: frontend получает все данные одним контекстным запросом. Вкладка открывается быстро даже при большом количестве сущностей в сделке — врач не ждёт, а сразу работает.\n\n## Итоги проекта\n\n| Показатель | До | После |\n|---|---|---|\n| Формирование плана лечения | 10–15 минут (бумажный бланк + ручной ввод товаров) | 2–3 минуты (интерактивная сетка) |\n| Сверка оплат и выполненных процедур | Медсестра вручную сверяла таблицы | Один экран с цветовой индикацией |\n| Ошибки зон воздействия | Текстовое описание, риск перепутать сторону | Визуальная схема тела с 43 зонами |\n| Приём оплат в Кыргызстане | Ручное подтверждение из банка | Автоматический вебхук за 2–3 минуты |\n| Открытие вкладки «План лечения» | Была бы около минуты при последовательных запросах | Оптимизировано (батчинг + кэширование) |\n| Возвраты | Ломали арифметику оплат | Корректный учёт с цветовой индикацией |\n| История изменений плана | Терялась (бумажка переписывалась) | Полная история в JSON-поле сделки |\n\n## Типичные ошибки в похожих проектах\n\n**1. План лечения = просто таблица в Excel.** Самая частая ошибка — сделать красивую таблицу без связи с реальными сущностями CRM. Врач заполняет план, а товары в сделку не попадают. Медсестра отмечает выполнение, а смарт-процесс не создаётся. Каждый блок должен быть связан двусторонней синхронизацией: план → товары сделки, отметка факта → смарт-процесс с полным набором полей.\n\n**2. Возвраты без проверки уже выполненных процедур.** Если система не различает «оплачено, но не сделано» и «оплачено и сделано», возврат сломает учёт. Нельзя просто уменьшать счётчик оплаченных услуг — надо знать, какие из них уже оказаны и не подлежат возврату.\n\n**3. Игнорирование региональных платёжных систем.** Встроенные решения хороши для РФ, но как только клиника выходит за пределы России — нужна интеграция с местным эквайрингом. Причём не просто приём платежа, а полный цикл: ссылка на оплату → вебхук → проведение в CRM. Без этого клиника возвращается к ручному учёту.\n\n**4. Одинаковое визуальное отображение всех статусов.** Когда «оплачено», «выдано», «возврат» и «план» выглядят одинаково, медсестра тратит время на чтение текста вместо мгновенного считывания цвета. Цветовое кодирование критично для медицины: оранжевый = не трогать, зелёный = сделано, синий = можно отмечать.\n\n**5. Последовательные REST-запросы без батчинга.** Когда в карточке сделки нужно показать 5 КП, 10 счетов и 50 строк товаров, нельзя делать 65 последовательных запросов к Битрикс24 API. Батчевые запросы и кэширование — не «оптимизация на будущее», а обязательный этап проектирования.\n\n## Заключение\n\nПроект для клиники Ратинова показал, что даже глубоко заточенное под медицину решение не требует разработки с нуля. Битрикс24 дал каркас: сделки, товары, счета, смарт-процессы, роботов. Поверх каркаса построен предметный слой: план лечения с сеткой дней, схема тела с 43 зонами, платёжная интеграция FINIK, SMS-уведомления.\n\nРешающим обстоятельством стал не объём автоматизации, а точность стыковки блоков. План лечения синхронизирован с товарами сделки. Отметка медсестры создаёт смарт-процесс с полным набором полей. Возврат корректно гасит оплаченные единицы. Зоны тела выбраны врачом — и тут же видны медсестре. Каждый блок знает о соседнем, и ни один не живёт сам по себе.\n\nКлиника получила систему, в которой врач, медсестра и администратор работают в единой среде. Пациент — от первого приёма до последней процедуры — проходит по цепочке, которую видно целиком.","\u003Ch1>Кейс: Автоматизация сети клиник лечения позвоночника — план лечения, схема тела и платёжная система в Битрикс24\u003C\u002Fh1>\n\u003Ch2>О клиенте\u003C\u002Fh2>\n\u003Cp>Клиника Ратинова — сеть из 14 медицинских центров в России, Казахстане и Кыргызстане, специализирующаяся на безоперационном лечении межпозвоночной грыжи методом модулируемой резорбции. Основатель — Андрей Сергеевич Ратинов, невролог-вертебролог с многолетней практикой. Клиника принимает более 175 пациентов в день, за всё время помогла более 90 000 человек. С 2025 года — официальный медицинский партнёр национального олимпийского комитета Киргизии.\u003C\u002Fp>\n\u003Cp>Особенность бизнес-процессов: пациент проходит курс из 10–14 процедур, каждая услуга привязана к конкретной зоне тела и дню лечения. Услуги продаются пакетами — 5, 7 или 10 сеансов. Оплата принимается в Кыргызстане через местную платёжную систему FINIK (AversPay), встроенные решения Битрикс24 для этого региона не работают.\u003C\u002Fp>\n\u003Ch2>С чем пришли: 5 болевых точек\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>1. Ручное планирование лечения.\u003C\u002Fstrong> Врач на приёме записывал план на бумаге: список процедур, дни, зоны воздействия. Медсестра потом вручную сверяла график. При изменении плана (замена услуги, перенос дня) бумажка переписывалась, старая версия терялась.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2. Разрозненный учёт оплат и выполненных процедур.\u003C\u002Fstrong> Оплата фиксировалась в счетах, выполнение — в отдельной таблице. Не было связи «оплатил 7 сеансов — посетил 3 — осталось 4». Медсестра не видела, какие услуги оплачены, а какие нет. При возврате одного сеанса из пакета ломалась вся арифметика.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3. Отсутствие привязки процедуры к зоне тела.\u003C\u002Fstrong> Врач указывал зоны воздействия текстом в комментарии. Медсестра могла перепутать «плечевой сустав левый» с «плечевой сустав правый». Не было визуального контроля: ни врач при назначении, ни медсестра при выполнении не видели схему тела с отмеченными зонами.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>4. Платёжная система не работает в Кыргызстане.\u003C\u002Fstrong> Встроенные платёжные решения Битрикс24 не поддерживают кыргызстанские эквайринги. Клиника не могла отправлять пациентам ссылки на оплату через FINIK — местную систему QR-платежей. Приходилось выставлять счета вручную и ждать подтверждения из банка.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>5. Высокие требования к скорости.\u003C\u002Fstrong> В карточке сделки нужно показывать десятки сущностей одновременно: счета, коммерческие предложения, строки товаров, планы лечения. Без продуманной архитектуры загрузка такого объёма данных заняла бы около минуты — недопустимо для врача, который ведёт приём в реальном времени. При открытии вкладки «План лечения» в карточке сделки загрузка данных занимала 53 секунды. Причины: последовательные REST-запросы к Битрикс24 API (каждый счёт, каждое КП, каждая строка товара запрашивались отдельно), отсутствие кэширования справочников.\u003C\u002Fp>\n\u003Ch2>Решение 1. Редактор плана лечения: от бумажки к интерактивной сетке\u003C\u002Fh2>\n\u003Cp>В карточку сделки воронки «Приём врача» добавлена вкладка «Лечение». Врач выбирает услуги из каталога товаров, указывает дни выполнения в 14-дневной сетке и настраивает зоны воздействия.\u003C\u002Fp>\n\u003Cp>Механика: услуги подгружаются из каталога товаров Битрикс24 — всегда актуальный список, деактивированные позиции скрыты. Для каждой услуги врач проставляет дни: нажатие «+» в ячейке добавляет сеанс, «−» убирает. План сохраняется единым JSON-объектом в пользовательское поле сделки. При сохранении автоматически синхронизируются товары сделки — вкладка «Товары» заполняется по стандартной схеме Битрикс24 (номенклатура + количество).\u003C\u002Fp>\n\u003Cp>Результат: врач формирует план лечения за 2–3 минуты вместо заполнения бумажного бланка и отдельного внесения товаров в сделку. Все версии плана хранятся в истории поля сделки\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F5bcd60ccf1f9.webp\" alt=\"План лечения в карточке сделки\">\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F905be2558386.webp\" alt=\"Редактор плана лечения\">\u003C\u002Fp>\n\u003Cp>, а не на глаз — погрешность позиционирования менее 3% от размера схемы. При выборе зоны врачом на схеме загорается кружок с номером зоны. Список из 43 чекбоксов дублируется слева от схемы — можно выбрать как кликом по телу, так и отметкой в списке.\u003C\u002Fp>\n\u003Cp>При сохранении плана список зон записывается в тот же JSON вместе с днями. На вкладке «Лечение» медсестра видит общую схему тела: все зоны из всех услуг плана наложены на одно изображение. Одинаковые зоны разных услуг показываются одним кружком. При наведении на кружок — подсказка: название зоны и список услуг, которые на неё назначены. Под названием услуги в таблице выводятся компактные бейджи с номерами зон.\u003C\u002Fp>\n\u003Cp>Результат: врач видит зоны воздействия в момент назначения, медсестра — перед выполнением. Исключена путаница «левое\u002Fправое», «латеральная\u002Fмедиальная».\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F27f29cdb1824.webp\" alt=\"Схема тела с 43 зонами\">\u003C\u002Fp>\n\u003Cp>. Ячейки окрашены по статусу:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Синий — «Оплачен» (услуга куплена, ожидает выполнения)\u003C\u002Fli>\n\u003Cli>Зелёный — «Выдан» (процедура выполнена, отмечена медсестрой)\u003C\u002Fli>\n\u003Cli>Оранжевый — «Возврат» (оплата отменена, процедура не оказывается)\u003C\u002Fli>\n\u003Cli>Серый — «Не оплачен» (услуга в плане, но не куплена)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Медсестра нажимает на синюю ячейку оплаченного дня — открывается попап «Отметить выдачу». В нём уже подставлен врач из основной сделки (поле UF_CRM_1730267788), указана текущая дата. Если нужно — дату можно изменить: процедуру, выполненную вчера, медсестра отмечает задним числом (актуально при сбоях интернета или портала). При подтверждении создаётся смарт-процесс (entityTypeId=1122), в который записываются:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Услуга\u003C\u002Fli>\n\u003Cli>Врач (из основной сделки)\u003C\u002Fli>\n\u003Cli>Медсестра (текущий пользователь, нажавший кнопку)\u003C\u002Fli>\n\u003Cli>Счёт, с которого списана оплата\u003C\u002Fli>\n\u003Cli>Медцентр, оказавший услугу\u003C\u002Fli>\n\u003Cli>Медцентр, продавший услугу\u003C\u002Fli>\n\u003Cli>Дата плановая и дата фактическая\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Повторное нажатие на уже выданную ячейку невозможно — она заблокирована. Неоплаченные и возвратные ячейки также неактивны.\u003C\u002Fp>\n\u003Cp>Результат: медсестра видит полную картину по пациенту за 2–3 секунды после открытия вкладки. Никаких отдельных таблиц и сверок.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F7c1f9a565fd2.webp\" alt=\"План\u002Fфакт процедур\">\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Fcases\u002Fratinovclinic\u002Fassets\u002F0af4e5a0afa9.webp\" alt=\"Отметка выдачи процедуры\">\u003C\u002Fp>\n\u003Cp>ранее возникала ошибка: возврат обнулял все оплаченные услуги до статуса «Не оплачен». Например: куплено 5 сеансов, 1 выполнен, сделан возврат 1 сеанса — система показывала 0 оплаченных вместо 4.\u003C\u002Fp>\n\u003Cp>Исправленная логика: возврат гасит оплаченные единицы с конца списка. Выданные (уже оказанные) процедуры возврат не трогает. Если возврат больше остатка оплаченных — излишек идёт на неоплаченные с конца. В интерфейсе возвратные дни отмечены оранжевым цветом и заблокированы для выдачи.\u003C\u002Fp>\n\u003Cp>Результат: арифметика всегда сходится. Куплено 5, возврат 1, выполнено 2 → 2 оплаченных ждут выдачи, 1 возврат.\u003C\u002Fp>\n\u003Ch2>Решение 5. Платёжная система FINIK через AversPay\u003C\u002Fh2>\n\u003Cp>Для приёма оплат в Кыргызстане разработан модуль интеграции с AversPay — местным эквайрингом, поддерживающим QR-платежи через систему FINIK.\u003C\u002Fp>\n\u003Cp>Схема работы: при выставлении счёта в Битрикс24 формируется запрос к API AversPay. Платёж подписывается RSA-ключом (приватный ключ хранится на сервере). В запросе передаются: сумма, ID сделки, название медицинского центра, ФИО пациента, список услуг. После оплаты AversPay отправляет вебхук на endpoint приложения — оплата автоматически проводится в Битрикс24.\u003C\u002Fp>\n\u003Cp>Результат: клиника получила ссылки на оплату, которые можно отправлять пациентам по SMS. Оплата проводится за 2–3 минуты вместо ручного подтверждения из банка.\u003C\u002Fp>\n\u003Ch2>Решение 6. SMS-уведомления\u003C\u002Fh2>\n\u003Cp>Настроена отправка SMS со ссылками на оплату. Пациент получает сообщение, переходит по ссылке, оплачивает QR-кодом через FINIK. После оплаты статус счёта в Битрикс24 обновляется автоматически.\u003C\u002Fp>\n\u003Ch2>Решение 7. Производительность: архитектура быстрой загрузки с первого дня\u003C\u002Fh2>\n\u003Cp>С самого начала мы заложили архитектуру, исключающую долгую загрузку. В карточке сделки одновременно отображаются счета, коммерческие предложения, строки товаров и план лечения — при 5 КП и 10 счетах это десятки сущностей, которые нужно показать мгновенно.\u003C\u002Fp>\n\u003Cp>Ключевые решения, заложенные в архитектуру:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Пакетная загрузка данных — до 20 одновременных запросов к API Битрикс24\u003C\u002Fli>\n\u003Cli>Кэширование справочников и фильтров — повторные обращения не тратят время\u003C\u002Fli>\n\u003Cli>Переиспользование загруженных данных между разными этапами обработки\u003C\u002Fli>\n\u003Cli>Исключение дублирующих вызовов — строки счетов загружаются один раз для всей карточки\u003C\u002Fli>\n\u003Cli>Параллельная загрузка товарных позиций по разным коммерческим предложениям\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Результат: frontend получает все данные одним контекстным запросом. Вкладка открывается быстро даже при большом количестве сущностей в сделке — врач не ждёт, а сразу работает.\u003C\u002Fp>\n\u003Ch2>Итоги проекта\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Показатель\u003C\u002Fth>\n\u003Cth>До\u003C\u002Fth>\n\u003Cth>После\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Формирование плана лечения\u003C\u002Ftd>\n\u003Ctd>10–15 минут (бумажный бланк + ручной ввод товаров)\u003C\u002Ftd>\n\u003Ctd>2–3 минуты (интерактивная сетка)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Сверка оплат и выполненных процедур\u003C\u002Ftd>\n\u003Ctd>Медсестра вручную сверяла таблицы\u003C\u002Ftd>\n\u003Ctd>Один экран с цветовой индикацией\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Ошибки зон воздействия\u003C\u002Ftd>\n\u003Ctd>Текстовое описание, риск перепутать сторону\u003C\u002Ftd>\n\u003Ctd>Визуальная схема тела с 43 зонами\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Приём оплат в Кыргызстане\u003C\u002Ftd>\n\u003Ctd>Ручное подтверждение из банка\u003C\u002Ftd>\n\u003Ctd>Автоматический вебхук за 2–3 минуты\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Открытие вкладки «План лечения»\u003C\u002Ftd>\n\u003Ctd>Была бы около минуты при последовательных запросах\u003C\u002Ftd>\n\u003Ctd>Оптимизировано (батчинг + кэширование)\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Возвраты\u003C\u002Ftd>\n\u003Ctd>Ломали арифметику оплат\u003C\u002Ftd>\n\u003Ctd>Корректный учёт с цветовой индикацией\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>История изменений плана\u003C\u002Ftd>\n\u003Ctd>Терялась (бумажка переписывалась)\u003C\u002Ftd>\n\u003Ctd>Полная история в JSON-поле сделки\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch2>Типичные ошибки в похожих проектах\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>1. План лечения = просто таблица в Excel.\u003C\u002Fstrong> Самая частая ошибка — сделать красивую таблицу без связи с реальными сущностями CRM. Врач заполняет план, а товары в сделку не попадают. Медсестра отмечает выполнение, а смарт-процесс не создаётся. Каждый блок должен быть связан двусторонней синхронизацией: план → товары сделки, отметка факта → смарт-процесс с полным набором полей.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2. Возвраты без проверки уже выполненных процедур.\u003C\u002Fstrong> Если система не различает «оплачено, но не сделано» и «оплачено и сделано», возврат сломает учёт. Нельзя просто уменьшать счётчик оплаченных услуг — надо знать, какие из них уже оказаны и не подлежат возврату.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3. Игнорирование региональных платёжных систем.\u003C\u002Fstrong> Встроенные решения хороши для РФ, но как только клиника выходит за пределы России — нужна интеграция с местным эквайрингом. Причём не просто приём платежа, а полный цикл: ссылка на оплату → вебхук → проведение в CRM. Без этого клиника возвращается к ручному учёту.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>4. Одинаковое визуальное отображение всех статусов.\u003C\u002Fstrong> Когда «оплачено», «выдано», «возврат» и «план» выглядят одинаково, медсестра тратит время на чтение текста вместо мгновенного считывания цвета. Цветовое кодирование критично для медицины: оранжевый = не трогать, зелёный = сделано, синий = можно отмечать.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>5. Последовательные REST-запросы без батчинга.\u003C\u002Fstrong> Когда в карточке сделки нужно показать 5 КП, 10 счетов и 50 строк товаров, нельзя делать 65 последовательных запросов к Битрикс24 API. Батчевые запросы и кэширование — не «оптимизация на будущее», а обязательный этап проектирования.\u003C\u002Fp>\n\u003Ch2>Заключение\u003C\u002Fh2>\n\u003Cp>Проект для клиники Ратинова показал, что даже глубоко заточенное под медицину решение не требует разработки с нуля. Битрикс24 дал каркас: сделки, товары, счета, смарт-процессы, роботов. Поверх каркаса построен предметный слой: план лечения с сеткой дней, схема тела с 43 зонами, платёжная интеграция FINIK, SMS-уведомления.\u003C\u002Fp>\n\u003Cp>Решающим обстоятельством стал не объём автоматизации, а точность стыковки блоков. План лечения синхронизирован с товарами сделки. Отметка медсестры создаёт смарт-процесс с полным набором полей. Возврат корректно гасит оплаченные единицы. Зоны тела выбраны врачом — и тут же видны медсестре. Каждый блок знает о соседнем, и ни один не живёт сам по себе.\u003C\u002Fp>\n\u003Cp>Клиника получила систему, в которой врач, медсестра и администратор работают в единой среде. Пациент — от первого приёма до последней процедуры — проходит по цепочке, которую видно целиком.\u003C\u002Fp>\n"]