Как спроектировать веб-приложение для ломбарда: модель залога и процентов, учет договоров, продления и уведомления о выкупе без лишней сложности.
Чаще всего все стартует с Excel, бумажных договоров и переписок в мессенджерах. Пока сделок мало, это работает. Но как только появляется поток, начинаются ошибки: потеряли фото предмета, не сошлась касса, забыли дату выкупа.
Самая болезненная зона - сроки. Каждый день есть договоры, которые подходят к концу, договоры после продления и договоры, где клиент обещал прийти "на днях". Если напоминаний нет, выкупы пропускаются, проценты пересчитывают вручную, а клиенту сложно быстро назвать точную сумму "на сегодня".
Вторая причина постоянной ручной рутины - проценты и условия. Ставки отличаются по типу залога, сумме, сроку и акциям. Плюс штрафы, льготные дни, правила округления. Когда все это хранится "в голове" или в чате, новый сотрудник начинает ошибаться, а опытный выгорает от постоянных проверок.
Обычно в процессе участвуют три роли: кассир оформляет выдачу, принимает платежи и закрывает выкуп; товаровед описывает предмет, оценивает, фиксирует состояние и фото; админ настраивает ставки, права доступа, отчеты и контроль кассы.
Хороший результат автоматизации простой: меньше просрочек и меньше ручных пересчетов. В идеале кассир открывает карточку договора и сразу видит сумму займа, начисленные проценты на текущую дату, ближайший дедлайн, доступность продления и историю действий (выдача, платежи, продления).
Если вы планируете систему учета, начните с фиксации этих болей в требованиях: какие сроки считаем, по каким правилам начисляем, кого и когда уведомляем. Дальше это превращается в понятную конфигурацию и рабочий прототип.
Чтобы система не развалилась на втором месяце, начните с простой, но полной модели данных. Она должна отвечать на три вопроса: кто взял деньги, что оставил в залог и что сейчас происходит с договором.
Базовый набор сущностей обычно такой: клиент (ФИО, телефон, документ, при необходимости адрес), залог (что это, состояние, фото и описание, оценка), договор (сумма займа, ставка, сроки, статусы), платеж (дата, сумма, тип: проценты, тело, штраф), продление (когда, на каких условиях, что было оплачено).
Важно разделять "залог" и "договор". Один и тот же предмет может проходить через несколько договоров (клиент выкупил и позже снова заложил). Если смешать это в одну таблицу, потом сложно строить историю.
Для договора обычно хватает пяти статусов, которые закрывают повседневные случаи: активен, продлен, выкуплен, просрочен, реализован. По залогу часто удобнее держать отдельный признак доступности: "на хранении", "выдан клиенту", "выставлен на продажу".
Критичные даты лучше хранить явно, а не пытаться всегда вычислять на лету:
Из документов и номеров фиксируйте минимум: номер договора, номер кассовой операции (если ведете), реквизиты документа клиента (серия, номер, кем выдан), а для залога - внутренний инвентарный номер или бирка. Скан или фото лучше хранить как файлы, но ключевые поля стоит дублировать текстом, чтобы их можно было искать.
Если вы собираете прототип в TakProsto, удобно сразу описать поля и статусы как справочники. Тогда генерация форм, списков и базовых проверок получается быстрее, а детали можно добавлять без переделки основы.
Если проценты и правила "зашиты" в код, любая правка превращается в задачу для разработчика. Для ломбарда проще держать условия как конфигурацию: менеджер меняет ставку или правило округления, а расчеты начинают работать по новым настройкам без переписывания логики.
Начните с типов залога как справочника. Для каждой категории (золото, смартфоны, инструменты) задайте, что фиксируется при приемке: оценка, состояние, фото, серийные номера или IMEI, а также особые поля (например, проба и вес для украшений). Так система одинаково уверенно ведет и "ювелирку", и технику.
В настройках лучше описывать не одну "ставку", а набор правил. Обычно хватает:
Так проще поддержать разные схемы: начисление по дням, по месяцам или смешанный вариант (часть фиксированно, часть по ставке).
Продление тоже лучше задавать настройками, иначе быстро появятся "исключения для каждого клиента". Достаточно простого набора ограничений: какие категории можно продлевать, сколько раз максимум и с каким шагом по сроку, требуется ли оплата процентов перед продлением, есть ли комиссия и как она считается, что делать, если срок уже истек.
Пример: для смартфонов ставка 1,2% в день, округление в большую сторону до рубля, минимум 50 рублей. Продление разрешено 3 раза, только после оплаты начисленных процентов, плюс комиссия 100 рублей. Когда правила лежат в конфигурации, их проще менять и проверять.
Договор в ломбарде - центр учета, а не просто бумага. Если в нем не хватает пары полей, сотрудники держат детали в голове или в заметках, и ошибки быстро накапливаются.
Для ежедневной работы хватает простого набора, но он должен быть единым для всех точек:
Дальше важна формула суммы к выкупу. Удобно считать ее из частей: тело займа плюс проценты за фактические дни, плюс штрафы при просрочке, минус скидки или акции. При этом расчет и операции нужно разделять: формула дает итог на конкретную дату, а операции показывают, что реально происходило.
Каждое движение денег и изменение сроков лучше фиксировать отдельной записью, с пользователем и временем. Обычно это выдача займа, частичный платеж, продление, выкуп и корректировка (только с причиной и правами).
История изменений спасает в спорных ситуациях: кто поменял тариф, почему сдвинули дату, откуда взялась скидка. Журнал лучше делать неизменяемым: не переписывать прошлое, а добавлять новые события. Так проще и аудит, и разбор жалоб.
В TakProsto такие операции удобно описывать как события и правила расчета. Тогда можно быстро получить базовые экраны, логику операций и отчеты по истории.
Если срок пропущен, начинается лишняя работа: звонки, пересчеты, споры о сумме. Поэтому лучше сразу заложить понятные правила напоминаний и шаблоны, которые не раскрывают лишние данные.
Обычно хватает трех точек: заранее, в день срока и после. Для каждого договора храните дату окончания, часовой пояс отделения и флаг согласия на уведомления.
Практичный набор, который не перегружает ни клиентов, ни сотрудников:
Каналы лучше подключать по очереди, а не все сразу: SMS для коротких сообщений, email для подробностей, мессенджер только при явном согласии. Внутри ломбарда полезно создавать задачу сотруднику, если клиент не отвечает.
Шаблоны держите короткими. Не пишите паспортные данные, полную сумму долга или описание изделия. Достаточно номера договора и даты:
Чтобы не было споров, делайте логирование: время постановки в очередь и время отправки, канал и адрес, статус (отправлено, доставлено, ошибка), текст шаблона и подстановки, кто отменил или отправил вручную.
Чтобы генерация приложения прошла без сюрпризов, нужны не общие пожелания, а четкие правила: что считаем, что запрещаем, где оператор ошибается чаще всего. Удобнее описывать это как "конфигурацию и сценарии", а не как ТЗ на 40 страниц.
Перед началом соберите входные данные в одном месте (документ или таблица), а затем переносите в режим планирования.
Сфокусируйтесь на пяти блоках:
Дальше сформулируйте 3-5 ключевых сценариев с конкретными числами. Например: "залог - телефон, сумма 10 000, срок 30 дней, ставка 0,5% в день. На 15-й день продление на 30 дней при оплате процентов. На 60-й день выкуп". Такие примеры помогают правильно собрать расчеты, статусы и историю.
Роли лучше согласовать отдельно, иначе приложение быстро превращается в "все могут все": оператор (выдача, продление, выкуп, печать документов), старший смены (исправления, отмены, корректировки по регламенту), бухгалтерия (отчеты, сверки, выгрузки), администратор (пользователи, права, справочники, шаблоны).
Когда требования описаны так, TakProsto обычно быстрее собирает базовые экраны, расчеты и напоминания. А если захотите поменять правила, проще откатиться к снимку.
Клиент приносит золотое кольцо. Сотрудник осматривает изделие, фиксирует вес и пробу, делает фото, записывает состояние (царапины, камни, дефекты) и присваивает номер залога. По внутренним правилам оценка получилась 20 000 руб., а займ выдаете на 70% от оценки: 14 000 руб.
Условия займа берутся из конфигурации: ставка 0,8% в день, срок 30 дней, льготный период 3 дня (если он у вас есть). Дата выдачи 10 марта, значит дата окончания 8 апреля (30 дней). Сумма к выкупу на дату окончания: 14 000 + (14 000 * 0,008 * 30) = 17 360 руб. В карточке договора видно тело, начисленные проценты на сегодня и итог к выкупу на выбранную дату.
На 25-й день клиент просит продлить договор на 14 дней. Система создает операцию продления: клиент оплачивает проценты за прошедший период (за 25 дней), а срок сдвигается вперед на 14 дней. Важно, что меняются даты и план начислений, но история остается: было продление, когда, кто провел, какая сумма принята.
По уведомлениям: за 5 дней до окончания и в день окончания уходят напоминания (SMS или мессенджер - как вы настроите). Сотрудник утром открывает список задач и видит договоры, где срок заканчивается сегодня, договоры на ближайшие дни, договоры после продления с подошедшей новой датой и просрочки (если вы их допускаете) с суммой к выкупу на текущую дату.
Самые дорогие ошибки обычно не про дизайн, а про мелкие правила, которые забыли зафиксировать. В результате суммы не сходятся, сотрудники спорят о "как правильно", а клиент получает странные уведомления. Ниже - типовые промахи, которые лучше отловить до того, как система станет "источником правды".
Часто ставку и срок пытаются запихнуть в одно поле вроде "1.5%/день, 30 дней", а дальше начинаются вопросы: когда округлять копейки, что считать "днем", как учитывать неполный период, что делать при досрочном выкупе. Без явных правил один и тот же договор может давать разные суммы у кассира и в системе.
Заранее зафиксируйте:
Вторая боль - когда не хранится история операций. Если в карточке договора лежит только "текущий долг", потом невозможно понять, откуда он взялся: был ли платеж, была ли скидка, кто менял оценку, когда делали продление.
Еще один частый провал - уведомления "по дате" без учета часового пояса, выходных и часов работы точки. В итоге клиенту приходит напоминание ночью или уже после закрытия.
И наконец, не ограничивают изменения ключевых дат. Если любой пользователь может поменять дату выдачи или дату окончания без причины, учет быстро перестает быть надежным. Минимум, который нужен: роли, обязательный комментарий к правке и запись в журнал.
Перед тем как пускать систему в работу, прогоните 2-3 тестовых договора. Это занимает час, но часто экономит недели разборов, почему "сумма к выкупу не сходится" или "клиенту не пришло напоминание".
Проверьте один сквозной сценарий: клиент сдал залог сегодня, через неделю сделал продление, а еще через неделю выкупил. На каждом шаге смотрите, что система сохраняет историю, а не "переписывает прошлое":
Если вы собираете MVP в TakProsto, удобно держать этот чеклист как отдельный сценарий тестирования и прогонять его после каждого изменения настроек.
Хороший учет живет не в таблицах, а на экране кассира. Если сотрудник с утра видит, что горит, а что можно сделать позже, ошибок меньше, а разговоров с клиентами больше по делу.
В начале смены нужен короткий список приоритетов, а не "все договоры". Обычно достаточно нескольких блоков: просроченные договоры с днями просрочки и суммой к выкупу на сегодня, договоры с окончанием в ближайшие 1-3 дня, задачи по продлению, неоформленные операции (черновики, зависшие платежи, несверенные суммы) и короткая сводка дня (выдано, выкуплено, продлено).
Дальше все упирается в поиск. В ломбарде редко помнят "как называется предмет", зато помнят номер договора или телефон.
Поиск должен находить по номеру договора, телефону, ФИО, описанию предмета и статусу. В выдаче важно показывать не только клиента, но и ключевое: дата окончания, остаток к оплате, признак продлений.
В карточке договора лучше держать действия на одном экране: принять оплату процентов, оформить продление, оформить выкуп, добавить комментарий. Чем меньше переходов, тем меньше соблазна "потом внесу".
Отчеты нужны простые и одинаковые каждый день. Обычно хватает 3-4 форм: выдано, выкуплено, продлено, просрочено за период; движение денег по кассе (приходы, расходы, корректировки); список активных договоров с датами и суммами на текущий день; просрочки с группировкой по срокам (1-7, 8-30, 30+ дней).
Экспорт полезен, когда нужно быстро отдать данные бухгалтеру или разобрать спорную ситуацию. Для разборов особенно важен журнал действий: кто и когда менял условия, проводил платеж, отменял операцию, правил дату или процент.
Чтобы приложение реально заработало, начните с малого. Возьмите один тариф (например, 30 дней и 0,5% в день), одну категорию залога (например, ювелирные изделия) и базовые уведомления: за 3 дня до срока и в день окончания.
Дальше переведите правила в конфигурацию: поля тарифа, формулы процентов, льготный период, статусы договора, события, которые запускают уведомления. Удобная структура - тарифы, правила продления, шаблоны уведомлений.
Если вы делаете это на TakProsto (takprosto.ai), можно собрать первый рабочий контур через чат и режим планирования, а потом постепенно уточнять правила без постоянных переделок. На практике это особенно помогает там, где условий много и они меняются по ходу.
Перед запуском тестируйте на копии данных: загрузите 20-50 "учебных" договоров и прогоните типовые ситуации (продление в последний день, частичная оплата, выкуп после просрочки). Чтобы не бояться изменений, сохраняйте snapshots перед правками конфигурации и формул, и откатывайтесь, если суммы в договорах "поехали".
Хостинг и домен подключайте, когда основные операции стабильны и роли настроены. После этого можно организовать перенос исходников через экспорт кода, если нужен внутренний аудит, отдельный репозиторий или доработка своей командой.
Начните с фиксации правил, а не с экранов: какие статусы договора вам нужны, как считаются сроки, как начисляются проценты, что считается просрочкой и кто имеет право править условия. Затем соберите минимальный прототип на реальных сценариях (выдача, платеж, продление, выкуп), чтобы сразу увидеть, где «разъезжаются» суммы и даты.
Разделяйте сущности: «залог» хранит описание, фото, состояние и инвентарный номер, а «договор» — деньги, ставку, сроки и статус. Один предмет может проходить через несколько договоров, и если смешать все в одну запись, вы потеряете историю и начнете путаться при повторных залогах.
Сделайте короткий, понятный набор статусов, который покрывает ежедневные случаи: активен, продлен, выкуплен, просрочен, реализован. Параллельно удобно держать отдельный признак по самому залогу (например, на хранении или выдан), чтобы не путать финансовый статус договора с физическим движением предмета.
Храните критичные даты явно: дата выдачи, плановая дата окончания, конец льготного периода (если он есть) и дата фактического выкупа или реализации. Когда даты «высчитываются где-то по формуле», вы неизбежно получите расхождения при продлениях, округлениях и спорных ситуациях.
Держите проценты и условия как конфигурацию: ставка и период, правило округления, минимум начислений, льготные дни, поведение при просрочке и фиксированные сборы, если они есть. Тогда изменение тарифа становится настройкой, а не задачей на переписывание логики, и вы быстрее вводите новые акции или условия для категорий залога.
Продление лучше описывать отдельными правилами: можно ли продлевать категорию, сколько раз, на какой срок, обязательно ли оплатить проценты перед продлением и есть ли комиссия. Это снижает хаос из «исключений для каждого клиента» и делает поведение системы предсказуемым для всех сотрудников.
Разделите расчет и учет операций: расчет дает сумму к выкупу на выбранную дату, а операции фиксируют фактические действия — выдачу, платеж, продление, выкуп, корректировку. Это позволяет объяснять клиенту сумму «на сегодня» и одновременно сохранять прозрачную историю, почему она получилась именно такой.
Записывайте каждое действие отдельным событием с пользователем, временем и причиной, а прошлые записи не редактируйте. При споре вы сможете показать, кто менял тариф, кто сдвигал дату, откуда взялась скидка, и это сильно снижает внутренние разборы и ошибки «задним числом».
Сделайте понятные точки отправки: заранее, в день окончания и после, плюс подтверждения при продлении и выкупе. В тексте не указывайте лишние данные (паспорт, описание изделия, точный долг), достаточно номера договора и даты, а еще важно логировать факт отправки и статус доставки, чтобы не спорить, «приходило или нет».
Сформулируйте требования как сценарии с числами: конкретный залог, сумма, ставка, срок, когда продление, сколько платится, когда выкуп. В TakProsto удобно сначала описать справочники (категории, тарифы, статусы, роли), а затем прогнать 2–3 тестовых договора и зафиксировать, где нужны дополнительные поля, проверки и права доступа.
