Ссылки на предыдущие части:
- Статья 1
- Статья 2
Предыдущую статью я заканчивал мыслью, что описание опять отстаёт от реализации. С тех пор ситуация не стала лучше: пока пишешь текст, в проект прилетает новый issue, закрывается старый, кто-то пробует платформу на своей конфигурации, а из этого внезапно рождается ещё один платформенный механизм.
Поэтому это не совсем “ещё один changelog”. Да, ниже будет много новых возможностей: ИИ-помощник в конфигураторе, нормальная СКД, визуальный конструктор форм, real-time уведомления, история версий конфигурации, автобэкап, свёртка базы, onebase lint, MCP-инструменты и нагрузочный стенд.
Но главный сдвиг не в списке фич. Главный сдвиг в том, что OneBase постепенно перестаёт быть штукой “для пет-проекта на вечер”. Она всё ещё не production-ready, это важная оговорка и я от неё не отказываюсь. Но теперь вокруг неё есть реальные разрабатываемые конфигурации, реальные замечания, реальные баги, реальные правки и очень короткий цикл обратной связи.
Собственно, с этого и начну.
Рис. 1. Главный экран пользовательского режима конфигурации PuT.
1. Уже не только “поиграться вечером”
Когда я писал первую статью, OneBase проще всего было объяснять через понятные примеры: домашняя бухгалтерия, таск-трекер, складская демка, MVP, учебный проект, личная автоматизация. Это всё остаётся хорошим сценарием: платформа маленькая, открытая, понятная 1С-разработчику и не требует лицензий.
Но за последние итерации стало видно другое: проект начинают проверять не абстрактными “а можно ли сделать справочник”, а вполне прикладными вопросами:
- как открыть несколько документов и не потерять контекст списка;
- как дать пользователю поменять структуру отчёта без правки YAML;
- как поймать дубль по ИНН и не обновить случайно не того контрагента;
- как не сломать RLS на чтении формы;
- как показать оператору всплывающее уведомление не через polling;
- как откатить ошибочное изменение конфигурации;
- как посмотреть, что будет при свёртке базы, до того как нажать страшную кнопку;
- как нагрузить базу k6 и увидеть p95/p99, а не “у меня вроде быстро”.
И вот это уже больше похоже на жизнь платформы, а не на демонстрационную поделку.
Сейчас в репозитории есть несколько конфигураций, на которых проверяются разные стороны платформы:
Отдельно развивается более полная конфигурация ПУТ. И это для платформы особенно полезно: маленький пример часто не показывает неприятные углы. Реальная конфигурация быстро вытаскивает наружу то, что в “hello world” не видно: ширину форм, неудобные списки, ошибки импорта, нехватку событий, права, блокировки, отчёты, производительность.
2. Обратная связь как часть разработки
Скажу пару слов про инфраструктуру для получения обратной связи и составления документации.
У меня нет отдела поддержки, отдела по ведению документации и т.п. Но и самому мне этим заниматься времени нет, поэтому пришлось всё автоматизировать.
Документация на сайт попадает сама, просто есть правило для ИИ , он при каждом пуше определяет есть ли новая фича и если есть, добавляет её описание, если что-то изменилось - находит и правит документацию. На статичном сайте появился динамический раздел с документацией и поиском в ней. Документацию не нужно писать отдельно, код сам пишет её
Рис. 1.1 Автообновляемая документация с поиском.
Для тестировщиков на сайте появился раздел тестируем с новыми фичами и описанием как попробовать, но никакой лишней инфраструктуры требующей поддержки, по кнопке сообщить о проблеме пользователь попадет на создание нового ишью на гитхабе по тестируемому вопросу а кнопка обсудить - создаст новое обсуждение в стандартном discussions.
Рис. 1.2 Раздел "Тестируем" на сайте.
Ну и теперь есть динамический автообновляемый роадмап. Карточки фич с прогрессом выполнения, планы в которых можно прочитать и, при желании, обсудить
Рис. 1.2 Раздел "планы" на сайте с обновляемым прогрессом.
Эти простые инструменты позволили снизить до 0 временные затраты на написание и актуализацию инструкций и прогресса по планам и существенно ускорили работу с багами, а значит, и совершенствование системы.
Прошу всех предлагать новые фичи или тестировать уже реализованные. Все это достаточно оперативно рассматривается и как минимум превращается в планы либо сразу идёт в разработку.
После второй статьи от 5 июня 2026 года в GitHub Issues пошёл плотный поток замечаний. Я пересчитал текущий срез через GitHub API перед написанием этого текста: PR исключены, учитываются только issues.
Рис. 2. Срез по GitHub Issues: сколько задач закрыто и с какой скоростью.
На 25 июня 2026 года (да, я долго пишу статью...) картина такая:
Конечно, это не SLA и не обещание “так будет всегда”. Проект по-прежнему развивается в свободное время, и рано или поздно появятся задачи, которые не закрываются за вечер. Но как снимок скорости реакции это хороший индикатор: обратная связь не просто складывается в backlog, а быстро превращается в код.
Самое интересное здесь не само число “55/55”, а характер закрытых задач. Это не только косметика. Среди них были security/critical, UX-блокеры, недостающие платформенные события, проблемы конструктора, отчётов и DSL.
Несколько показательных историй.
Security/RLS: issue #148
В issue #148 была зафиксирована неприятная вещь: серверное событие чтения формы не вызывалось на GET, а значит, прикладной RLS на уровне формы мог не сработать. Для любой системы с пользователями это не “потом посмотрим”, а критичный класс ошибок.
Результат: появился серверный хук ПриЧтенииНаСервере, который получает объект формы уже после загрузки данных — первая точка, где прикладной код видит Объект на сервере до рендера. Через него можно:
- дополнить/вычислить реквизиты перед показом;
- скрыть чувствительные поля;
- вовсе отказать в чтении через ВызватьИсключение (сервер отдаёт 403, данные в HTML не попадают).
Полноценного row-level security на уровне платформы в OneBase нет — движок сам по строкам ничего не фильтрует, а RBAC режет доступ только к объектам целиком. Но ПриЧтенииНаСервере даёт зачаток RLS «своими руками»: логику «имеет ли пользователь доступ к этой конкретной записи» пишет разработчик конфигурации. Важная оговорка — хук закрывает только открытие формы одной записи; списки, отчёты и запросы он не фильтрует. Это заплатка на конкретный дырявый путь чтения, а не сквозной RLS.
Как только вам, друзья, потребуется настоящий RLS, просто создайте ишью )
Время от создания issue до закрытия: около 6,7 часа.
Процедура ПриЧтенииНаСервере()
Если Не ПользовательИмеетДоступКОбъекту(Объект) Тогда
ВызватьИсключение("Нет доступа к объекту");
КонецЕсли;
КонецПроцедуры
Safe-match: issues #177 и #178
При импортах и синхронизациях почти всегда возникает задача “найти объект по реквизиту”. В простом случае хочется написать запрос по ИНН и обновить найденного контрагента. Но в реальной базе есть три исхода:
- ничего не найдено — надо создать;
- найден ровно один — можно обновлять;
- найдено несколько — это конфликт, руками разбирать дубли.
Раньше это каждый раз приходилось аккуратно писать в прикладном коде. После замечаний появился штатный API:
Рез = Справочники.Контрагент.ПроверитьСовпадениеПоРеквизиту("ИНН", ИНН);
Если Рез.Статус = "НеНайдено" Тогда
Контрагент = Справочники.Контрагент.Создать();
ИначеЕсли Рез.Статус = "НайденаОдна" Тогда
Контрагент = Рез.Ссылка.ПолучитьОбъект();
Иначе
ВызватьИсключение("Найдено несколько контрагентов с ИНН " + ИНН);
КонецЕсли;
Это маленькая функция, но очень платформенная по смыслу. Она снимает с конфигураций повторяющийся и потенциально опасный код.
Визуальный конструктор форм: issue #164
Большой пример обратной связи — визуальный конструктор управляемых форм. Сначала была управляемая форма как YAML + предпросмотр. Это уже работало, но всё ещё требовало думать в тексте. Потом появился запрос: перетаскивать реквизиты на форму как в привычном конфигураторе.
В итоге за несколько дней вырос не просто drag-and-drop одного поля, а полноценный визуальный редактор:
- холст формы справа;
- палитра реквизитов и структурных элементов;
- группы, страницы, закладки, табличные части;
- панель свойств выбранного элемента;
- создание обработчиков событий;
- перестановка и удаление элементов;
- синхронизация холста и YAML;
- сохранение ручных комментариев и порядка ключей через round-trip дерева YAML.
Время закрытия issue #164: около 62,8 часа. Для задачи такого размера это очень быстро.
UX по свежим замечаниям: issues #205 и #206
Свежий пример уже из совсем недавних: замечания по конструктору форм и поведению вкладок приложения. Оба issue были закрыты примерно за 4-4,5 часа.
Это важнее, чем кажется. У платформы может быть сколько угодно “больших” возможностей, но если мелкий UX постоянно мешает работать, пользователь до больших возможностей не доберётся. Поэтому такие issue ценны: они двигают OneBase из состояния “фича есть” в состояние “этим можно пользоваться без раздражения”.
3. ИИ-помощник теперь внутри конфигуратора и предприятия
Честно, не помню, писал ли я про ИИ помощника в пользовательском режиме, я его уже очень давно добавил и в зависимости от прав (а в системе уже есть даже RLS) он может анализировать информацию из базы и отвечать на ваши вопросы.
Рис. 2.1 ИИ помощник в предприятии.
Попробовать можно прямо в живой демо базе пользователь Демонов пароль 12345
Во второй статье я писал про CLI-first инструменты для разработки с ИИ: check, describe, ai-guide, procrun. Тогда главный тезис был простой: ассистенту нужна обратная связь. Он должен видеть структуру конфигурации и получать точные ошибки, а не гадать по файлам.
Следующий шаг — встроить эту петлю прямо в конфигуратор.
Теперь в конфигураторе есть ИИ-помощник. Он настраивается через форму: endpoints, модели, профили задач. Можно подключить Gemini, Anthropic, OpenAI или compatible endpoint, в том числе локальные или альтернативные API.
Рис. 2.2 UI настроек ИИ в конфигураторе.
Примерная структура настроек такая:
llm:
enabled: true
endpoints:
- name: z_ai
kind: anthropic
base_url: https://api.z.ai/api/anthropic
api_key: "${env:ZAI_KEY}"
- name: google
kind: gemini
api_key: "${env:GEMINI_KEY}"
models:
- { name: glm-4.6, endpoint: z_ai }
- { name: gemini-2.5-flash, endpoint: google, vision: true }
profiles:
- { task: анализ, models: [glm-4.6] }
- { task: чат, models: [glm-4.6] }
- { task: документы, models: [gemini-2.5-flash] }
default_profile: анализ
Настройки можно задавать через UI, а можно и текстом
Рис. 2.3 Настройки ИИ в конфигураторе в виде JSON.
Ключи можно хранить в _settings базы, а для деплоя задавать через config/app.yaml и переменные окружения. В .obz-бэкап ключи не попадают.
Главное — ИИ-помощник не просто “чат рядом с кодом”. Он умеет работать с конфигурацией как с набором файлов:
- генерировать YAML, .os и формы;
- показывать diff до применения;
- давать выбрать, какие файлы применять;
- запускать проверку перед записью;
- делать self-correction loop после неудачного check;
- показывать tool trace;
- для конфигураций в БД создавать снимки до/после, чтобы был понятный rollback.
Рис. 2.4 Генератор каркаса конфигурации прямо в конфигураторе
Рис. 2.5 ИИ помощник в конфигураторе
Мне кажется, это правильная точка баланса. ИИ не получает бесконтрольную кнопку “перепиши всё”. Он предлагает изменения, показывает diff, прогоняет инструменты платформы, а человек решает, что применять.
4. ИИ можно вызывать из DSL
Отдельная ветка — ИИ-функции прямо во встроенном языке. Это уже не про разработку конфигурации, а про прикладные сценарии.
Доступны функции:
Пример: простая рекомендация к закупке по остаткам.
Процедура Выполнить()
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура,
| КоличествоОстаток
|ИЗ РегистрНакопления.ОстаткиТоваров.Остатки(&НаДату)";
Запрос.УстановитьПараметр("НаДату", ТекущаяДата());
Данные = Запрос.Выполнить().Выгрузить();
Параметры = Новый Структура;
Параметры.Вставить("Задача", "анализ");
Параметры.Вставить("Система", "Ты опытный товаровед. Отвечай кратко.");
Ответ = ЗапросИИ(
"Проанализируй остатки и предложи, что закупить. Данные: " + ЗаписатьJSON(Данные),
Параметры
);
Сообщить(Ответ);
КонецПроцедуры
Другой сценарий — распознавание накладной. Модель вытаскивает поставщика и строки, а конфигурация создаёт черновик документа. Человек потом проверяет и проводит.
Процедура РаспознатьНакладную(ДанныеФайлаBase64)
Промпт =
"Извлеки поставщика и строки накладной. " +
"Верни строго JSON: {""Поставщик"":"""",""Строки"":[{""Наименование"":"""",""Количество"":0,""Цена"":0}]}";
ОтветJSON = РаспознатьИзображение(ДанныеФайлаBase64, "image/jpeg", Промпт);
Данные = ПрочитатьJSON(ОтветJSON);
Док = Документы.ПоступлениеТоваров.Создать();
Док.Поставщик = НайтиКонтрагента(Данные.Поставщик);
Для Каждого Стр Из Данные.Строки Цикл
НоваяСтрока = Док.Товары.Добавить();
НоваяСтрока.Номенклатура = ПодобратьНоменклатуру(Стр.Наименование);
НоваяСтрока.Количество = Стр.Количество;
НоваяСтрока.Цена = Стр.Цена;
КонецЦикла;
Док.Записать();
КонецПроцедуры
Да, это надо использовать аккуратно. Модель не должна без проверки проводить документы и менять остатки. Но как помощник для черновиков, анализа, распознавания и объяснения данных — уже полезно.
5. CLI и MCP: чтобы агент не угадывал структуру
ИИ-помощник в UI — это удобно, но внешние агенты тоже никуда не делись. Поэтому инструменты CLI выросли до более явного контракта.
onebase describe теперь отдаёт машинное описание конфигурации: объекты, формы, отчёты, виджеты, журналы, подсистемы, страницы, HTTP-сервисы, регламентные задания, роли, модули, процедуры, export-флаги, параметры и source location.
Появилась команда onebase examples, которая печатает canonical-фрагменты YAML/DSL. Это важная мелочь: агенту не надо вспоминать, как именно называется поле в метаданных, он может спросить платформу.
onebase describe --project examples/trade
onebase examples --list
onebase examples document
onebase examples query
Плюс набор headless-команд:
И, наконец, onebase mcp: MCP-сервер поверх этих инструментов. По умолчанию он read-only. Mutating-инструменты скрыты, пока явно не включить нужный флаг:
onebase mcp --project /absolute/path/to/config
onebase mcp \
--project /absolute/path/to/config \
--allow-refactor-write
Это ровно тот случай, где “безопасность по умолчанию” важнее удобства. Сначала агент читает describe, смотрит examples, делает impact, запускает check, а уже потом человек решает, давать ли write-инструмент.
6. Отчёты: лёгкая СКД вместо “просто таблицы”
Отчёты — одна из тех областей, где простого “выполнить запрос и показать таблицу” хватает недолго. Пользователь быстро хочет группировки, итоги, варианты, отборы, графики, расшифровки и Excel.
В OneBase появился блок composition — лёгкая СКД в YAML отчёта.
composition:
groupings:
- Номенклатура
measures:
- field: Количество
agg: sum
- field: Сумма
agg: sum
totals: true
chart:
type: bar
category: Номенклатура
value: Сумма
Теперь отчёт может сам собрать:
- группировки;
- итоги;
- вычисляемые показатели;
- условное оформление;
- диаграммы;
- drill-down к деталям;
- экспорт в Excel.
Рис. 3. Конструктор компоновки отчёта в конфигураторе: группировки, показатели, итоги и сортировка.
Рис. 4. Пример сформированного отчёта с группировками, итогами и диаграммой.
Отдельно появился режим кросс-таблицы. Если добавить columns, измерение разворачивается в колонки:
composition:
groupings: [Номенклатура]
columns: [Месяц]
measures:
- { field: Сумма, agg: sum }
Для отчёта по продажам это превращает строки номенклатуры и месяцы в привычную сводную таблицу.
Рис. 4.1 Пример кросс таблицы.
Ещё важнее пользовательские настройки отчёта. На форме можно включать/выключать группировки и показатели, добавлять отборы, менять вид таблицы, сохранять настройки персонально. Конфигурация при этом не меняется.
Рис. 5. Пользовательская настройка отчёта прямо на форме.
variants:
- name: "По складам"
composition:
groupings: [Склад, Номенклатура]
measures:
- { field: Сумма, agg: sum }
- name: "Кросс по месяцам"
composition:
groupings: [Номенклатура]
columns: [Месяц]
measures:
- { field: Сумма, agg: sum }
Для прикладной системы это большой шаг. Отчёт перестаёт быть “одним зашитым представлением” и становится рабочим инструментом пользователя.
7. Визуальный конструктор управляемых форм
Управляемые формы уже были во второй статье. Тогда это был важный шаг от автогенерируемых CRUD-форм к декларативным формам с событиями.
Теперь следующий этап: формы можно собирать визуально.
Рис. 6. Визуальный конструктор управляемой формы в конфигураторе.
Панель редактора стала интерактивным холстом. Реквизит можно перетащить из палитры на форму, выбрать элемент, поменять свойства, добавить группу или вкладку, настроить табличную часть.
Поддержаны:
- поля ввода;
- флажки;
- переключатели;
- списки значений;
- группы;
- страницы и наборы страниц;
- надписи;
- кнопки;
- табличные части;
- колонки табличных частей;
- события элементов;
- события формы.
Важная техническая деталь: холст и YAML синхронизированы двусторонне. Если править форму визуально, меняется YAML. Если править YAML, холст перерисовывается. При этом ручные комментарии и порядок ключей не должны теряться.
- kind: ПолеВвода
name: ПолеНаименование
title: { ru: "Наименование" }
data_path: Объект.Наименование
required: true
events:
ПриИзменении: НаименованиеПриИзменении
Рис. 7. Холст формы и редактирование структуры элементов в визуальном конструкторе, события.
События можно привязывать через UI. У кнопки — Нажатие, у поля — ПриИзменении, у формы — ПриОткрытии, ПриЧтенииНаСервере, ПередЗаписью, ПриЗаписи, ПослеЗаписи.
Если процедуры ещё нет, конструктор может создать пустой обработчик в .form.os.
Процедура ВалютаПриИзменении()
Сообщить("Выбрана валюта: " + Объект.Валюта);
КонецПроцедуры
Отдельно появился элемент “список значений” — аналог СписокВыбора, когда не хочется заводить отдельное перечисление или справочник.
- kind: ПолеСписка
name: ПолеВалюта
data_path: Объект.Валюта
choices:
- value: RUB
title: { ru: "Российский рубль", en: "Russian ruble" }
- value: USD
title: { ru: "Доллар США", en: "US dollar" }
events:
ПриИзменении: ВалютаПриИзменении
Если список зависит от данных, его можно наполнить динамически в событии НачалоВыбора через ДобавитьЗначениеСписка.
8. Интерфейс: вкладки, страницы, плитки и richtext
Много улучшений в интерфейсе небольшие по отдельности, но вместе сильно меняют ощущение от работы.
Появился вкладочный режим: можно открыть список, из него несколько документов, переключаться между ними, продублировать вкладку, не терять список после открытия карточки. При несохранённых изменениях вкладка предупреждает перед закрытием.
Рис. 8. Пользовательский интерфейс PuT со с открытыми вкладками.
Появились произвольные страницы на DSL. Это не отчёт и не форма объекта, а отдельный экран раздела: показатели, таблицы, графики, HTML-блоки, кнопки и серверные действия.
Процедура ПриФормировании(Страница, Параметры) Экспорт
Страница.Заголовок("Панель продаж");
Страница.Показатель("Заказы сегодня", ПолучитьКоличествоЗаказов(), "number");
График = Страница.График("Продажи по дням", "bar");
График.Категории("Пн", "Вт", "Ср");
График.Серия("Продажи", ПолучитьДанныеГрафика());
КонецПроцедуры
Рис. 9. Пример рабочей панели пользовательского режима.
Списки теперь можно показывать не только страницами, но и лентой, плиткой или деревом. Для номенклатуры с фотографиями плитка выглядит естественнее таблицы.
tile_view:
image: Фото
title: Наименование
subtitle: Артикул
fields: [Цена, Остаток]
Рис. 10. Справочник номенклатуры в пользовательском режиме PuT.
Для карточек появились новые типы реквизитов:
- image — поле-картинка, например фото товара или логотип;
- richtext — форматированный текст через Quill, с HTML, картинками и санитайзером.
Рис. 10.1 richtext-поле с форматированием, списком и вставленной картинкой
Для навигации по подсистемам добавились иконки разделов из Lucide. Это мелочь, но на реальных конфигурациях с несколькими подсистемами сильно помогает быстрее считывать интерфейс.
name: Продажи
title: Продажи
icon: shopping-cart
documents:
- ЗаказПокупателя
- РеализацияТоваров
Рис. 10.2 Иконки разделов из Lucide.
И ещё один блок, который раньше быстро начинал мешать: переводы синонимов. Теперь их можно редактировать в конфигураторе единым режимом, а не раскрывать отдельный блок у каждого поля. Переводы enum-значений тоже поддержаны. А когда вам не нужны переводы, они не отображаются и не мешаются
Рис. 10.3 Отображаемые/Скрываемые переводы.
9. Real-time пуши и всплывашки
Real-time сценарии быстро появляются в любой живой конфигурации: задачи, заявки, согласования, интеграции, регламентные операции. Поэтому сам механизм сделан платформенным, без привязки к конкретной предметной области.
В OneBase появился SSE-канал /ui/events, внутрипроцессная шина уведомлений и DSL-функция ОтправитьУведомление.
ОтправитьУведомление("ivan", "уведомление", "Заявка №42 назначена на вас");
ОтправитьУведомление("роль:Оператор", "очередь.переполнена", Новый Структура("Ждут", 7));
ОтправитьУведомление("*", "уведомление", "Сервер будет перезагружен в 18:00");
Первый аргумент — адрес:
- логин пользователя;
- роль:ИмяРоли;
- * для всех онлайн-пользователей.
Если событие называется уведомление и payload — строка, интерфейс показывает готовый toast.
Рис. 11. Real-time toast-уведомление в открытой вкладке интерфейса.
Но можно отправлять и свои события. Тогда страница слушает их на клиенте:
window.addEventListener("onebase:очередь.переполнена", (event) => {
const data = event.detail;
showQueuePopup(data);
});
Это уже основа для живых интерфейсов:
- уведомить исполнителя о новой задаче;
- показать бухгалтеру входящий документ на согласование;
- обновить показатель на дашборде;
- вывести всплывашку по событию внешней системы;
- сообщить группе пользователей о регламентной операции;
- показать администратору предупреждение о сбое интеграции.
Важно: это не замена полноценному распределённому message broker. Сейчас шина внутрипроцессная. Для одного экземпляра приложения этого достаточно, для горизонтального масштабирования нужна отдельная работа. Но для текущего класса инсталляций это уже практичный механизм, который убирает постоянный polling.
10. Печатные формы: от YAML к визуальному макету
Печатные формы в OneBase были с самого начала: можно было описывать YAML или формировать ТабличныйДокумент из DSL. Теперь направление стало удобнее для реальной работы.
Появился визуальный редактор макетов печатных форм:
- строки и колонки;
- ширины и высоты;
- границы по сторонам ячейки;
- привязка данных;
- предпросмотр;
- HTML и PDF;
- кириллические шрифты на серверном PDF;
- картинки в HTML/PDF.
Рис. 11.1 Редактор макетов печатных форм.
Есть и импорт из PDF. Загружаете готовый векторный PDF — например счёт, акт или УПД — платформа пытается распознать сетку, тексты и границы, а дальше даёт доработать макет в редакторе.
Рис. 11.2 Импорт печатных форм из PDF.
Для старых печатных форм есть миграция:
onebase printforms migrate --project ./my-config
Это не магия “любой PDF превратим в идеальный макет”. Со сканами будет честная ошибка. Но для векторных форм это хороший старт, особенно если нужно быстро получить похожий макет и потом руками довести детали.
11. Торговое оборудование и РМК
Ещё один признак взросления платформы — подключаемое оборудование. В пет-проекте это обычно не нужно. В реальной торговой конфигурации без этого быстро упираешься в потолок.
В OneBase появился единый подход к оборудованию:
- чековый принтер;
- дисплей покупателя;
- весы;
- эквайринг;
- сканер штрихкода;
- фискальный регистратор;
- device-agent на кассовом месте;
- эмуляторы для тестов.
Сервер OneBase не обязан иметь прямой доступ к железу кассира. Браузер обращается к локальному onebase device-agent, а URL и token хранятся в localStorage конкретного рабочего места.
Рис. 12. Агент оборудования.
В РМК можно:
- проверить связь с агентом;
- напечатать чек;
- открыть денежный ящик;
- получить вес;
- принять событие сканера;
- пробить фискальный чек через АТОЛ.
Рис. 12. Рабочее место кассира.
Для простых устройств не обязательно писать Go-драйвер. Есть декларативные scripted-драйверы: hex-запрос, regexp ответа, шаблоны строк, кодировка cp866 или utf8.
Это важный принцип для платформы: где можно дать конфигурации расширяемость без пересборки платформы, лучше дать её.
Да, тут пока всё в зачаточной стадии, но задел есть, будут конкретные запросы - буду развивать направление оборудования!
12. Администрирование: версии, автобэкап и свёртка
Напомню, что в onebase конфигурацию можно хранить в файлах и использовать git а можно и в таблицах базы данных (как в 1С)
Когда конфигурация хранится в базе, появляется неприятный вопрос: а что делать, если в конфигураторе ошиблись?
Теперь есть история версий конфигурации. Платформа создаёт снимки в _config_versions при сохранениях, удалениях, batch-операциях и onebase deploy --message.
В UI можно:
- посмотреть список версий;
- сравнить две версии;
- экспортировать снимок в ZIP или config-only .obz;
- выполнить rollback.
Рис. 13. История версий конфигурации, diff двух версий и кнопка rollback
Rollback не стирает историю, а создаёт новую версию. Это правильная модель: даже откат остаётся видимым событием.
Появился автобэкап:
backup:
enabled: true
schedule: "0 2 * * *"
keep_last: 7
directory: ""
Он работает как системное задание AutoBackup, пишет PostgreSQL-дампы как .sql.gz, SQLite — как .db, сначала во временный файл и только после успешного завершения переименовывает в финальный.
Рис. 13.1 Настройки автобэкапа в конфигураторе
И, наконец, платформенная свёртка базы. Это уже совсем не “пет-проектовая” функция.
Свёртка на дату:
- считает остатки балансовых регистров накопления;
- создаёт опорные записи synthetic-регистратором _СвёрткаБазы;
- может удалить движения и документы до даты;
- выставляет дату запрета проведения свёрнутого периода;
- для бухгалтерского регистра использует вспомогательный счёт;
- перед выполнением показывает предпросмотр;
- проверяет, что остатки до и после совпали;
- не даёт оставить повисшие ссылки, если удаляемый документ используется сохраняемой записью.
onebase rollup \
--project ./examples/trade \
--sqlite trade.db \
--date 2026-01-01 \
--dry-run
Рис. 14. Свёртка базы в конфигураторе с предварительной проверкой.
Свёртка необратима. Поэтому сначала бэкап, потом dry-run, потом выполнение. Здесь лучше быть скучным и осторожным.
13. Качество, lint и наблюдаемость
Когда проект начинает проверяться реальными конфигурациями, одного “у меня запустилось” мало.
Появился onebase lint. В отличие от строгого check, lint может выдавать предупреждения:
- неизвестные YAML-ключи;
- неиспользуемые Перем;
- недостижимые процедуры;
- объекты без прав в ролях.
onebase lint --project examples/trade
onebase check --project examples/trade --lint
Это шаг к нормальному CI-gate для поставляемых конфигураций.
Появились Prometheus-метрики на /metrics и структурные slog-логи. Можно задавать формат и уровень:
ONEBASE_LOG_LEVEL=debug ONEBASE_LOG_FORMAT=json onebase run --project ./examples/trade
Секреты, токены, DSN и чувствительные аргументы редактируются в логах, чтобы не утекали в диагностику.
Рис. 15. Лог с секретами.
Для нагрузки появился стенд:
- PostgreSQL;
- onebase;
- Prometheus;
- Grafana;
- k6-сценарии;
- HTML-отчёты.
docker compose -f loadtest/docker-compose.yml up -d --build
go run ./loadtest/seed \
-url http://localhost:8080 \
-counterparties 200 \
-documents 500 \
-out loadtest/seed/counterparties.json
docker compose -f loadtest/docker-compose.yml run --rm --service-ports \
-e K6_WEB_DASHBOARD=true \
-e K6_WEB_DASHBOARD_HOST=0.0.0.0 \
-e K6_WEB_DASHBOARD_EXPORT=/reports/post_document.html \
k6 run /scripts/scenarios/post_document.js
Рис. 16. фрагмент k6 отчёта нагрузочного теста.
Честный текущий вывод по многопользовательской работе такой:
- 10 пользователей на PostgreSQL с умеренной нагрузкой выглядят нормальным сценарием;
- 100 зарегистрированных пользователей сами по себе не проблема;
- 100 одновременно активных пользователей — уже настоящая эксплуатация, нужны PostgreSQL, настройка пула, индексы, лимиты отчётов и нагрузочный прогон;
- SQLite лучше оставить для desktop, демо и разработки;
Это не рекламный ответ “да хоть тысяча”. Это инженерный ответ: вот где уже нормально, вот где надо мерить, вот какие ограничения известны. Главное, что все инструменты теперь есть из коробки
14. Что с REST и HTTP-сервисами
REST API по сущностям был и раньше, но рядом появился более прикладной механизм — HTTP-сервисы на DSL. Это аналог идеи “опубликовать свой endpoint из конфигурации”.
Конфигурация описывает сервис, а обработчик на DSL отдаёт текст или JSON по /hs/<корень>/....
Процедура ПолучитьСтатус(Запрос, Ответ)
Данные = Новый Структура;
Данные.Вставить("status", "ok");
Данные.Вставить("time", ТекущаяДата());
ОтветJSON(Ответ, Данные);
КонецПроцедуры
Рис. 17. RapiDoc/OpenAPI-страница HTTP-сервиса конфигурации
Это удобно для интеграций: webhook от внешней системы, приём заявки, отдача статуса, простая внутренняя API-точка. Но тут тоже есть предохранители: сетевые операции и опасные действия должны включаться осознанно, а секреты не должны лежать в открытом YAML.
Ну и кто не мечтал про Swagger из коробки в 1С? Onebase рисует интерактивную документацию по HTTP-сервисам автоматически (RapiDoc + OpenAPI 3.0, всё внутри бинаря).
15. Итого: куда всё это движется
Если коротко, OneBase стала заметно более платформенной.
В первой статье было важно показать, что вообще можно сделать открытую бизнес-платформу на Go с 1С-подобной моделью: справочники, документы, регистры, DSL, отчёты, формы, лаунчер.
Во второй статье — что платформа быстро догоняет базовую эргономику: управляемые формы, роли, i18n, decimal, CLI-инструменты, REST, рабочий стол.
Сейчас важнее другое:
- конфигурации становятся реальнее;
- обратная связь идёт через issues;
- замечания быстро превращаются в механизмы платформы;
- отчёты стали ближе к СКД;
- формы можно собирать визуально;
- появились пуши и всплывашки;
- есть история версий и rollback;
- есть автобэкап и свёртка;
- есть lint, metrics, логи и нагрузочный стенд;
- ИИ встроен не как игрушка, а как часть dev-loop с diff, check и rollback.
Повторю оговорку: я не называю OneBase production-ready. Там ещё достаточно шероховатостей, технического долга и мест, которые надо добивать перед серьёзной эксплуатацией. REST API v2, полноценный multi-user hardening, RLS-стратегия, горизонтальное масштабирование, лимиты тяжёлых операций — всё это ещё требует доработки.
Но “только для пет-проектов” — уже тоже не совсем честное описание. Пет-проекты остаются хорошей точкой входа. А дальше всё больше видно другой сценарий: быстро собрать прикладную конфигурацию, дать её пользователям, получить обратную связь, закрыть проблемы, улучшить платформу и повторить цикл.
И в этом смысле OneBase становится интереснее всего именно как открытая платформа, которую можно менять под реальные задачи.
Ссылки
- Releases
- Демо база онлайн Демонов 12345
- Документация + в репозитории: README.md, QUICKSTART.md, DEVELOPER.md, docs/features.md
- Примеры конфигураций: examples/
Вступайте в нашу телеграмм-группу Инфостарт
