Когда займ — это мешок монет: как мы уложили инвестиционную платформу в типовую 1С

К нам пришёл финтех-стартап с задачей, которая «в лоб» не решалась: типовые конфигурации не подходили, отраслевые решения для финансовых организаций требовали серьёзной доработки, а разработка с нуля — заведомо неподъёмная для стартапа. Мы уже готовили вежливый отказ, но один разговор внутри команды изменил картину. В этом кейсе — пример того, как одно нестандартное допущение разворачивает «уникальную» задачу в типовую учётную схему. Будет полезно, если у вас «специфический» бизнес и кажется, что без большой кастомной разработки не обойтись.

Компания позиционирует себя как инвестиционная платформа. Выдаёт займы юридическим лицам, но средства — не свои, а собранные у других юрлиц-вкладчиков.

Логика такая. На платформу приходят инвесторы, видят список потенциальных заёмщиков с их финансовыми показателями, целью займа и предлагаемой ставкой — и сами решают, готовы ли вкладывать в каждую конкретную сделку. Платформа здесь посредник: предоставляет интерфейсы, ведёт взаиморасчёты, живёт с комиссии.

Запрос был конкретный: нужно учётное решение, которое концептуально закрывает задачу. Не идеальное, не покрывающее все нюансы, но рабочее. И при этом в бюджете стартапа.

Проанализировали рынок и увидели, что в рамках бюджета и сроков задача не решается ни одним из стандартных путей.

Типовые конфигурации — изначально не про финансовое посредничество. Если моделировать займы напрямую, любую из них (УТ, Бухгалтерию, ERP) пришлось бы серьёзно переделывать под чужую логику.

Отраслевые решения для финансовых организаций — есть, но их логика сильно отличается от того, что нужно клиенту. Объём доработок выходил сопоставимым с разработкой с нуля.

Разработка с нуля — для стартапа на таком этапе слишком долго и слишком дорого.

Мы уже готовили клиенту честный ответ: в нынешних рамках задача нерешаемая.

Перед тем как окончательно отказать, договорились ещё раз посмотреть на задачу под другим углом. Не «как сделать», а «на какую учётную схему ложится эта задача».

Идею предложил один из ведущих разработчиков. Звучит она странно — но именно из этой странности всё и работает:

Если так допустить, задача из «нестандартной финтех-системы» превращается в классическую торговлю «заказ под заказ» с обязательным обособлением товара. Все участники, документы и операции аккуратно ложатся на типовые сущности 1С:Управление торговлей.

Вот как идея раскладывается по типовым объектам 1С: Управление торговлей:

Деньги (1 монета = 1 единица учёта) → Товар с обязательным обособлением
Заёмщик → Покупатель
Инвестор-вкладчик → Поставщик
Заявка на займ → Заказ покупателя (количество = тело займа, сумма = полная сумма к возврату)
Заявка на финансирование → Заказ поставщику (количество = объём вклада, сумма = полная сумма дохода)
Поступление денег от инвестора → Приобретение товаров и услуг
Выдача денег заёмщику → Реализация товаров
Возврат тела займа от заёмщика → Оплата от покупателя
Перечисление дохода инвестору → Оплата поставщику

Удобный побочный эффект этой схемы — в ней не нужно отдельно хранить процентную ставку. Разница между суммой и количеством в каждом заказе и есть проценты.

В заказе покупателя: количество — это сколько монет получает заёмщик, сумма — сколько он за них в итоге заплатит. Разница — стоимость пользования займом, проценты заёмщика.

В заказе поставщика — то же самое с другой стороны: количество — сколько монет инвестор «продал» платформе, сумма — сколько за них получит. Разница — его доход.

Чтобы не оставлять схему абстрактной — приведём пример с живыми числами.

Допустим, ООО «Ромашка» хочет занять 1 млн рублей на год под 15% годовых. К возврату — 1 150 000 ₽.

Двое инвесторов готовы профинансировать сделку, но под разные ставки:

В 1С: УТ это разворачивается в три типовых документа:

Заказ покупателя · ООО «Ромашка» · 1 000 000 монет · 1 150 000 ₽
Заказ поставщику · ООО «Василёк» · 500 000 монет · 560 000 ₽
Заказ поставщику · ООО «Одуванчик» · 500 000 монет · 565 000 ₽

Дальше всё считается само собой типовыми механизмами:

Ни процентных ставок, ни поля «комиссия платформы» в системе нет вообще. Всё это — естественные следствия из обычных заказов.

Стоит увидеть структурную связь — и дальше за вас работают все типовые механизмы 1С: УТ. Вместо месяцев самописного кода — рабочее ядро на типовой конфигурации.

Частичные перечисления и возвраты — из коробки. Стандартная схема «заказ под заказ» поддерживает их без доработок. Постепенный сбор средств от нескольких инвесторов под одну заявку, поэтапный возврат тела займа — всё ложится на типовой документооборот.

Контроль остатков и обособление — встроенный. Механизм гарантирует, что монеты конкретного инвестора пойдут именно тому заёмщику, под которого они размещены. Никаких самописных регистров для отслеживания связи «чьи деньги — кому ушли».

Отчётность и анализ — типовые. Дебиторка-кредиторка, обороты по контрагентам, анализ выполнения заказов — всё это уже есть. Не нужно проектировать с нуля.

То есть учётное ядро, которое иначе пришлось бы строить месяцами, оказалось доступно почти бесплатно — за счёт правильного переосмысления.

По этой схеме мы собрали демонстрационный стенд на типовой 1С: УТ с минимальными изменениями. И встретили предсказуемую сложность: на объяснение сути уходило заметное время. Когда видишь, что в системе торгуют какими-то «монетками», нужно время, чтобы перестроить голову.

Чтобы это снять, прорабатывали интерфейсный слой: убирали из форм лишние реквизиты, заменяли «Покупатель» на «Заёмщик», «Поставщик» на «Инвестор», «Товар» на привычные финансовые термины. Плюс несколько корректировок в расчётных движениях из-за специфики бизнеса клиента.

В итоге получилось работоспособное учётное ядро на типовой конфигурации.

На стенде стало видно главное: задача, которая с виду казалась нерешаемой, разворачивается до уровня типовой схемы — если найти правильный подход.

Учётное ядро для финтех-задачи такого класса — от 600 000 ₽ и примерно месяц работы. В этот объём входит ключевое: структура документов, движения по регистрам, типовая отчётность.

Доработки, специфические расчёты под вашу бизнес-логику и интеграции с банками или другими сервисами увеличат стоимость проекта. Пример такой интеграции — в нашем кейсе про финтех-API.

Если задача «не ложится» на типовое 1С, а отраслевые решения кажутся избыточными — напишите нам. Часто правильно поставленный вопрос экономит месяцы разработки.⬇️