Услуги · учётные системы
Строим учётную систему как продукт, а не как стопку доработок: доменные модули на Go, PostgreSQL как источник истины, архитектура зафиксирована в модели C4 и ADR, правила проверяются в CI. Начинаем с платного Этапа 0 — проектирования за 2–4 недели.
Симптомы
Четыре ситуации, после которых разговор обычно и начинается. Слева — как это звучит на планёрке, справа — что за этим стоит инженерно.
Стоимость изменений
Любая доработка стоит как отдельный проект, а после неё отваливается соседний блок
Признак того, что границ между блоками нет: правки лежат поверх типовой конфигурации и знают друг о друге больше, чем следует. В своей системе границы доменных модулей описаны явно, а регрессию ловят тесты в CI на merge request, а не бухгалтер в конце месяца.
Разъезжающиеся данные
Остатки в одной системе, отгрузки в другой, отчёт руководителю — в Excel, и цифры не сходятся
Пять систем — это пять мнений об остатке и ни одного источника истины. Мы делаем PostgreSQL единственным источником истины: остаток считается движениями по регистру, а любую цифру можно раскрутить обратно до документа, который её породил.
Зависимость от подрядчика
Мы не можем сменить исполнителя: код, доступы и знание о системе не у нас
Заложник не в лицензии, а в отсутствии документации. Репозиторий заводится у вас с первого дня, ключевые решения фиксируются в ADR вместе с отвергнутыми вариантами. Передача проекта другой команде — плановая операция, а не катастрофа.
Система как продукт
Хотим продавать свою систему клиентам, но она не переживёт второго арендатора
Мультиарендность нельзя прикрутить сверху: она либо в фундаменте, либо переписывается вся выборка данных. Мы закладываем TenantRegistry и ShardRouter сразу — арендатор определяется на входе в запрос, крупного клиента можно вынести на отдельный шард.
Состав системы
Домены включаются по очереди и в вашем приоритете — стартовать сразу со всем набором не нужно. Ниже то, что мы уже проектировали и доводили до продакшена в этой ERP-платформе.
Номенклатура, контрагенты, организации, склады, единицы измерения. Один справочник на всю систему: у товара один код, а не пять разных в пяти модулях.
Заказы покупателей, резервы, отгрузки, возвраты. Заказ живёт как документ с состоянием, поэтому видно, кто и на каком основании его изменил.
Приёмка, размещение, перемещения между складами, инвентаризация и списания. Остаток — это сумма движений, а не редактируемое поле в карточке товара.
Потребность, заказы поставщикам, поступления и сверка с условиями договора. Заказ поставщику создаётся «на основании» дефицита и сохраняет связь с ним.
Взаиморасчёты, платежи, задолженность по контрагентам и договорам. Денежные суммы храним в целых минимальных единицах — на плавающей точке копейки расходятся.
Типы цен, прайс-листы, скидки и правила подстановки цены в документ. Цена фиксируется в момент проведения, а не подтягивается заново при каждом открытии.
Условия и сроки договоров, маршруты и рейсы доставки, статусы по этапам. Доставка связана с отгрузкой, а не ведётся параллельной таблицей у логиста.
Единая шапка документа и расширения под каждый тип, статусы, помесячная сквозная нумерация и граф связей «на основании» — от заказа до закрывающих документов.
Пользователи, роли и разрешения до уровня операции над типом документа. Проверка прав живёт в доменном слое, иначе её обходят прямым вызовом API.
Архитектура
Четыре механизма, которые отличают учётную систему от набора CRUD-экранов. Каждый решает конкретную проблему, а не добавлен «для современности».
Все типы документов делят общую шапку и расширения под свой тип, а переходы между статусами описаны конечным автоматом: попасть из черновика в проведённый мимо проверок нельзя. Связи «на основании» образуют граф, по которому видно происхождение любой строки — от отгрузки до заказа, который её породил.
шапка + расширения · конечный автомат · граф связей
Событие пишется в ту же транзакцию базы, что и сам документ, а публикует его отдельный воркер. Иначе событие теряется ровно между коммитом и отправкой в брокер, и склад узнаёт об отгрузке, которой уже нет, — или наоборот, не узнаёт о той, которая есть.
outbox → worker → Kafka · at-least-once
Списки, фильтры и поиск читают отдельную модель, которую наполняют те же события. Тяжёлый запрос по большому массиву не встаёт в очередь к транзакциям записи, а новая форма отчёта не требует очередного индекса в PostgreSQL.
запись: PostgreSQL · чтение: Elasticsearch
Арендатор определяется на входе в запрос: TenantRegistry хранит соответствие, ShardRouter выбирает базу. Данные разных клиентов физически не встречаются, а крупного арендатора можно вынести на отдельный шард, не переписывая доменный код.
TenantRegistry · ShardRouter · изоляция данных
Кейс · мультиарендная ERP
Задача. Собрать учётный контур, который развивается как продукт: десяток доменов в одной кодовой базе, несколько арендаторов и внешний API для клиентских приложений.
Решение. Модульный монолит на Go 1.26 и PostgreSQL 16: 10+ доменных модулей, три монолита и GraphQL-шлюз с DataLoader против N+1, единый gRPC-контракт coreerp.v1 почти на два десятка сервисов. Схема живёт в 100+ обратимых миграциях на Goose, архитектура — в модели C4 L1–L4 и корпусе ADR.
Следствие. Новый домен добавляется, не задевая соседние: границы модулей и контракты зафиксированы до кода. Мультиарендность заложена в фундамент, а не прикручена в третий год жизни системы.
Этапы
Первый этап платный и самостоятельный: он заканчивается артефактами, а не обещанием. Дальше объём фиксируется на входе в каждый этап.
Разбираем процессы и текущие системы, размечаем домены и границы модулей, проектируем схему данных и контракты. Ключевые развилки записываем в ADR — вместе с вариантами, которые отвергли, и причинами. На выходе модель C4, схема данных, план миграции и смета на реализацию.
Ставим фундамент: движок документов, НСИ, права доступа, миграции, окружения и CI-гейты. Первые сценарии запускаем на ваших реальных данных — перенос данных ведём как отдельную задачу с проверками, а не как разовый импорт в последний день.
Домены включаем по очереди, приоритет за вами: продажи, склад, закупки, финансы, ценообразование, договоры. Каждый приезжает со своими правами, печатными формами и отчётами и сразу уходит в работу — а не ждёт общего запуска.
Связываем систему с внешним контуром — 1С, CRM, маркетплейсы, кассы, — включаем метрики, трейсинг и алерты, передаём команде документацию и регламент выпуска. Дальше возможны оба сценария: сопровождение с нашей стороны или полностью самостоятельная разработка на вашей.
Вход в проект
Мы не называем цену разработки ERP до проектирования: любая такая сумма была бы выдумана. Поэтому вход в проект отдельный, платный и с понятным результатом.
Этап 0 · проектирование2–4 недели
Фиксированная стоимость, считаем после короткого созвона. На выходе — модель C4 уровней L1–L4, ADR по ключевым решениям, схема данных, план миграции с текущих систем и смета на реализацию с разбивкой по доменам. Этап оплачивается отдельно и ни к чему вас не обязывает: решите строить дальше с другой командой — все артефакты остаются у вас.
Для разработки ERP, интеграций и работ с базами данных фиксированного прайса нет: объём считается после проектирования. Информация на сайте не является публичной офертой.
Результат
Не только работающая система, но и всё, что нужно, чтобы развивать её без нас.
Код заводится в вашем Git сразу, а не выкладывается по факту сдачи. Вы видите каждый коммит, историю решений и реальный темп работы — без демонстраций «по пятницам».
Контекст, контейнеры, компоненты и код описаны на одном языке. По этим диаграммам новый разработчик входит в проект за дни, а не собирает картину системы по чужим коммитам.
Каждое ключевое решение записано: что выбрали, какие альтернативы отвергли и при каком условии решение стоит пересмотреть. Через год это отвечает на вопрос «почему здесь так».
Схема меняется только миграциями, у каждой есть up и down. Откат — штатная операция дежурного инженера, а не ночная реанимация базы из вчерашнего дампа.
Линтеры, тесты с детектором гонок и проверка контрактов на каждом merge request. Архитектурные правила проверяются автоматически, а не держатся на памяти ревьюера.
Описание доменов, схемы данных, регламент выпуска и полный набор доступов к инфраструктуре передаются вам вместе с кодом — по чек-листу, а не «по договорённости».
Сравнение
Честно, включая пункты не в нашу пользу: своя система нужна не всем и не всегда. Если ваш процесс укладывается в типовой — дешевле остаться на типовом.
| Критерий | Доработка 1С | Коробочная ERP | Своя система |
|---|---|---|---|
| Скорость первого результата | Быстро: типовая конфигурация уже содержит учёт | Быстро, если процессы укладываются в шаблон вендора | Дольше: сначала Этап 0, затем MVP-ядро — первые месяцы уходят в фундамент |
| Регламентированный учёт и отчётность в ФНС | Сильная сторона: обновляется вместе с законодательством | По-разному, часто через выгрузку в бухгалтерскую систему | Не делаем: бухгалтерию оставляем в 1С и интегрируемся с ней |
| Стоимость десятого изменения | Растёт: правки ложатся поверх типовой, обновление становится проектом | Упирается в пределы настройки, дальше — доработка силами вендора | Предсказуема: границы модулей и тесты в CI держат регрессию |
| Модель данных под ваш процесс | В рамках типовых объектов и их реквизитов | В рамках справочников и сущностей вендора | Проектируется под ваш домен, PostgreSQL — источник истины |
| Владение кодом и правами | Доработки ваши, платформа — лицензия | Нет: подписка и правила поставщика | Исключительные права по договору, репозиторий на вашей стороне |
| Развитие как продукта: SaaS, арендаторы | Не тот класс задач | Только если это продаёт сам вендор | Мультиарендность и шардирование закладываются в фундамент |
| Зависимость от одного подрядчика | Высокая: знание держится на конкретных людях | Полная: вы внутри чужого релизного цикла | Снижена: C4, ADR и документация позволяют передать проект другой команде |
1С хорошо закрывает регламентированный учёт и отчётность — его мы обычно и оставляем в 1С. Проблема начинается там, где ваш процесс не ложится на типовые объекты: доработки накапливаются поверх конфигурации, обновление превращается в отдельный проект, а правка в одном блоке отзывается в соседнем. Своя система нужна, когда учётный контур — часть продукта и конкурентного преимущества, а не обязанность перед налоговой.
Микросервисы платят за независимость команд сетевыми границами: распределённые транзакции, версионирование десятка API, отдельная эксплуатация каждого сервиса. Для стартующей ERP это плата без выгоды — домены меняются вместе, и бизнес-операция должна укладываться в одну транзакцию. Модульный монолит даёт те же явные границы внутри одной кодовой базы. Отдельный сервис выделяем позже и точечно — например, поиск, у которого свой профиль нагрузки.
Возможны три сценария, и все три обсуждаются до старта: сопровождаем сами; передаём вашей внутренней команде и помогаем на первых спринтах; передаём другому подрядчику. Ради третьего сценария архитектура и решения и фиксируются письменно — модель C4, ADR и регламент выпуска пишутся по ходу работы, а не собираются в последнюю неделю перед актом.
Вам — и код, и база, и инфраструктура. Исключительные права передаются по договору, репозиторий и окружения заводятся на вашей стороне с первого дня. Мы не продаём лицензию на платформу и не держим у себя ключей, без которых система не запускается.
Фиксированного прайса на ERP не существует: объём зависит от числа доменов, состояния текущих систем и качества данных, которые предстоит перенести. Поэтому мы продаём не смету наугад, а платный Этап 0 — проектирование за 2–4 недели с фиксированной стоимостью, которую считаем после короткого созвона. Смета на реализацию появляется на выходе Этапа 0, вместе с архитектурой, на которую она опирается.
Этап 0 — 2–4 недели. MVP-ядро с движком документов, НСИ и правами доступа — ориентировочно 2–3 месяца, точную оценку даём после проектирования. Дальше домены включаются итерациями, приоритет за вами, и каждый уходит в работу сразу, не дожидаясь общего запуска. Срок «под ключ» до Этапа 0 мы не называем: такая цифра была бы выдумана.
Контакты
Разберём, что уже есть, где реально болит и какие домены включать первыми. Если задача решается доработкой существующей системы — скажем об этом прямо. maincode — инженерная студия ИП Диденко М. С.
Дальше
Своя ERP нужна не в каждом случае. Нужно связать уже существующие системы, чтобы данные перестали теряться, — это интеграции. Нужно сначала понять, что не так с текущей системой и где она сломается при росте, — это аудит.
Услуга
Интеграции систем1С, CRM, маркетплейсы и кассы. Гарантия доставки, идемпотентность и журнал обмена, по которому видно, что доехало, а что застряло.
Услуга
Аудит архитектурыНезависимый разбор текущей системы с фиксированной ценой и сроком: карта, реестр рисков и план работ по приоритету.
Услуга
Базы данных и DWHЕсли боль в отчётах и ночном ETL: схемы, индексы, планы запросов и хранилище данных, которое успевает к утру.