Оперативка для MAX

1. Рамки, которые задаёт хакатон

Ниже факты из официальных правил (ред. 21.08.2026) и сайта. Детальное Задание по треку придёт на почту только 15 сентября, поэтому концепция должна оставаться гибкой в деталях, но твёрдой в архитектуре.

2. Как считают баллы, и что из этого следует

На онлайн-этапе техника весит больше продукта. Это редкость для хакатонов и главный аргумент в пользу интеграционной темы: критерий «корректность интеграции и обмена данными» существует буквально под наш проект.

В финале расклад меняется: 40% техника, 60% защита. В защите 25% весит потенциал тиражирования и 15% сценарий запуска и внедрения. Здесь компания как реальный пилотный заказчик даёт то, чего у студенческих команд обычно нет: живого клиента и план внедрения.

3. Идея продукта

Проблема

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

Решение

«Оперативка» ставит между ERP и MAX слой интеграции. Он подписывается на события в учётной системе, превращает их в сообщения с кнопками нужным людям и записывает результат действия обратно. Мини-приложение даёт то, что не помещается в чат: списки, карточки документов, сводку дня, настройку подключения.

Роли и сценарии

4. Что даёт платформа MAX

Собрано из документации dev.max.ru. Проверить на актуальность 15 сентября вместе с Заданием, документация обновляется.

5. Архитектура

Три слоя, каждый заменяем независимо. Ключевая мысль для жюри: MAX и ERP не знают друг о друге, между ними единая модель событий и документов.

Интерфейс адаптера

Это то, что показывает «потенциал масштабирования» в коде, а не на слайде. Любая новая ERP подключается реализацией одного интерфейса.

interface ErpAdapter {
  id: 'moysklad' | '1c-odata' | 'bitrix24' | 'demo';
  connect(credentials): Promise<ConnectionInfo>;      // проверка доступа
  subscribe(events: EventKind[]): Promise<void>;       // вебхук или опрос
  pull(since: Cursor): Promise<ErpEvent[]>;            // резерв, если вебхуков нет
  getDocument(kind, id): Promise<Document>;            // счёт, заказ, накладная
  listDocuments(kind, filter): Promise<Document[]>;
  apply(action: Approve | Reject | SetStatus | Comment): Promise<Result>;
  summary(date): Promise<DailySummary>;                // касса, дебиторка, очередь
}

Сквозной поток на примере счёта

1. Менеджер создаёт счёт в МойСклад. Вебхук прилетает в адаптер, тот нормализует его в событие invoice.created.
2. Маршрутизатор находит правило «счета свыше 100 000 согласует директор» и кладёт задачу в очередь.
3. Bot Gateway отправляет директору сообщение с суммой, контрагентом и кнопками «Согласовать», «Отклонить», «Открыть».
4. Директор жмёт «Согласовать». Callback уходит в маршрутизатор, адаптер меняет статус документа и пишет комментарий с автором и временем.
5. Менеджер получает уведомление и по кнопке «Поделиться» отправляет клиенту ссылку на статус через shareMaxContent.
6. Если ERP недоступна, событие остаётся в очереди, пользователю приходит «не удалось записать, повторим», повтор по экспоненте, всё в журнале синхронизации.

6. Граница между компанией и командой

Что компания даёт легально и полезно:

• Экспертизу: какие события в ERP реально важны, как выглядит согласование у клиентов, где чаще всего ломается обмен.
• Тестовую базу 1С с опубликованным OData и обезличенными данными. Это превращает «адаптер 1С» из заглушки в живую интеграцию.
• Роль пилотного заказчика для раздела «сценарий запуска и внедрения» в финале: письмо о заинтересованности, план пилота на одном клиенте.
• Менторство по архитектуре обмена без участия в написании кода продукта.

Заодно это честный тест гипотезы для самой компании: если студенты за 15 дней собирают рабочий канал «ERP → мессенджер» на открытых API, это продукт, который компания может предлагать клиентам после хакатона, заведя бота от своего юрлица.

7. Объём MVP на 15 дней

8. План: кто и когда

9. Чеклист сдачи

• Репозиторий с лицензией и историей коммитов всех участников, без секретов в коде.
• README: что это, для кого, как запустить за 10 минут через docker-compose, тестовые учётки.
• Схема архитектуры и описание интерфейса адаптера, список поддерживаемых событий.
• Работающий бот в MAX с тестовой компанией и данными, к которым есть доступ у проверяющих.
• Видео 3 минуты: сквозной сценарий от события в ERP до записи обратно.
• Презентация: проблема, решение, архитектура, масштабирование, план внедрения с пилотным заказчиком, команда.
• Чеклист обязательных требований Задания, отмеченный по пунктам.

10. Риски и открытые вопросы

Источники

• Сайт хакатона MAX: треки, даты, призы.
• Официальные правила хакатона 2026 (PDF, ред. 21.08): разделы 4, 5, 8, 9, 10, 11, 12.
• Документация Bot API MAX: вебхуки, лимиты, deep links.
• Подключение мини-приложения и MAX Bridge.
• Новость на Хабре о сезоне 2026 и итоги сезона 2025: победители трека «Эффективность» делали календарь встреч с ИИ-ассистентом.