Программный комплекс «NARMAK»

Назначение документа: материалы для идентификации объекта оценки и сопоставления с затратами / аналогами при оценке нематериального актива.
Нормативный контур: ФСБУ 14/2022 (оценка не является предметом настоящего текста; документ описывает объект).
Правообладатель: [Наименование компании]
Дата формирования свода: март 2026 г.
Актуальность подсчёта объёма кода: 20 марта 2026 г. (методология cloc).

---

1. Термины и сокращения

Термин	Определение
ПК «NARMAK»	Программный комплекс автоматизации управления производственным предприятием «NARMAK»
ОИС	Объект интеллектуальной собственности (программа для ЭВМ и документация)
НМА	Нематериальный актив
API	Программный интерфейс приложения (REST, WebSocket)
Frontend / Backend	Клиентская (веб) и серверная части системы
OSS	Open Source Software — ПО с открытым исходным кодом
LOC / SLOC	Строки кода; в настоящем документе для метрик используется колонка code утилиты cloc (см. п. 4.1)

---

2. Описание объекта интеллектуальной собственности

Полное наименование: Программный комплекс автоматизации управления производственным предприятием «NARMAK»

Краткое наименование: Narmak ERP

Версия на дату оценки: 2.0

Дата первого ввода в эксплуатацию: 2020 год

Дата оценки: 28 февраля 2026 года

Правообладатель: [Наименование компании]

---

2.1. Назначение программного комплекса

Программный комплекс «NARMAK» (далее — ПК «NARMAK» или Система) предназначен для комплексной автоматизации управления производственным предприятием. Система охватывает весь операционный цикл предприятия: от управления производством и складом до контроля финансов, взаимодействия с контрагентами, управления персоналом и интеграции с маркетплейсами.

Основные цели Системы:

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

2.1.2. Границы объекта и ограничения

• Состав объекта оценки в части программного кода — репозитории backend (narmak_v2, включая каталог microservices/) и frontend (narmak-nx-angular-main) на условиях и методологии раздела 4. Сторонние библиотеки и runtime-зависимости (node_modules, виртуальные окружения, СУБД, ОС, облачная инфраструктура заказчика) не входят в объём собственного кода правообладателя.
• Внешние сервисы по API (DaData, маркетплейсы Wildberries и Ozon, банковские API — Модульбанк, Тинькофф Бизнес, Банк Точка и др., Яндекс Карты как картографический сервис и JS API, Telegram как канал доставки уведомлений, Camunda как BPM-платформа и др.) являются контрагентами интеграции: их программный код и лицензионные условия не заявляются как часть исключительного права на ПК «NARMAK»; в состав объекта входит реализованный в ПК код интеграции с указанными сервисами.
• Облачное хранилище (Selectel): размещение файлов и вложений — интеграция с Selectel Cloud Storage через пакет django-selectel (HTTP API, CDN); для отдельных компонент инфраструктуры допускается S3-совместимый доступ к Selectel Object Storage (см. § 2.4). Услуги провайдера и хранимые пользователем данные не входят в объект оценки как программа для ЭВМ; в объект входит код клиента интеграции в ПК.
• Регламентированный бухгалтерский и налоговый учёт: функциональность Системы ориентирована на операционное и управленческое управление предприятием (учётно-логистические и финансово-планировочные процессы). Полнота соответствия всем требованиям законодательства к официальной регламентированной отчётности не заявляется без отдельного подтверждения внедрения и настройки; конкретный правовой статус отчётных форм определяется заказчиком совместно с бухгалтерией и консультантами.
• Конфигурация и данные: учётные политики, справочники, заполненные документы и пользовательские данные заказчика не являются частью программы для ЭВМ как объекта авторского права; они создаются при эксплуатации.

Нормативный перечень требований к функциям — в разделе 3 (ТЗ); настоящий раздел 2 даёт расшифровку для идентификации объекта и оценки сложности.

---

2.2. Состав программного комплекса

ПК «NARMAK» состоит из серверной части, веб-клиентов (несколько приложений под разные роли), PWA для склада и вспомогательных сервисов в составе backend-репозитория — как единого программного комплекса автоматизации (см. также § 4.2.1 по охвату microservices/ при подсчёте cloc).

2.2.1. Серверная часть (Backend API)

Серверная часть реализует бизнес-логику системы, управление данными и предоставляет программный интерфейс (API) для клиентских приложений.

• Язык программирования: Python 3.10+
• Веб-фреймворк: Django 5.1.4
• API: Django REST Framework 3.15.2
• Протоколы: REST API (HTTP/HTTPS), WebSocket (Django Channels / Daphne)
• СУБД: PostgreSQL
• Брокер сообщений / кэш: Redis
• Асинхронные задачи: Celery 5.2.3
• BPM-движок: Camunda (интеграция через Django-Camunda)
• Шина данных: Apache Kafka

2.2.2. Веб-приложение (Frontend Web)

Веб-интерфейс системы реализован как Nx Monorepo и включает шесть самостоятельных приложений для разных ролей пользователей:

Приложение	Назначение
main-office	Основное рабочее место сотрудника офиса: все модули управления
warehouse-worker	Мобильный интерфейс для складских работников
counterparty-office	Личный кабинет для контрагентов (клиентов и поставщиков)
wow-x-office	Специализированное рабочее место WOW-X
positive-brands	Управление брендом Positive Brands
narmak-web-site	Публичный сайт компании

• Фреймворк: Angular 18.0.0
• Архитектура: Nx Monorepo, Feature-Based Architecture
• Управление состоянием: Akita 8.0.1
• UI-библиотеки: PrimeNG 17, Taiga UI 3, Bootstrap 5
• Визуализация: Chart.js 4, ApexCharts 3, D3.js 7
• Работа с документами: jsPDF, XLSX, Docx

Матрица «функциональный контур × клиентское приложение» (для идентификации поверхностей доступа; конкретный набор экранов задаётся ролями и конфигурацией внедрения):

Функциональный контур	main-office	warehouse-worker	counterparty-office	wow-x-office	positive-brands	narmak-web-site
Базовая платформа (п. 2.3.0)	●	●	●	●	●	—
Производство	●	○	—	●	○	—
Склад	●	●	—	●	○	—
Документооборот	●	○	○	●	○	—
Продажи	●	—	○	●	●	—
Закупки	●	—	○	●	○	—
Финансы	●	—	—	●	○	—
Контрагенты	●	—	●	●	○	—
Договоры	●	—	○	●	○	—
Маркетплейсы	●	—	—	●	●	—
HR	●	○	—	●	—	—
ATS	●	—	—	●	—	—
LMS	●	○	—	●	—	—
TMS	●	○	—	●	○	—
ТОиР	●	○	—	●	—	—
Контроль качества	●	○	—	●	—	—
Коммуникации и уведомления	●	○	○	●	○	—
Аналитика и отчётность	●	○	○	●	○	—

Условные обозначения: ● — основной контур приложения для данного модуля; ○ — вспомогательный или ограниченный набор функций; — функциональность ERP в данном приложении не предусмотрена. Приложение narmak-web-site — публичный сайт (маркетинговый контур), не рабочее место ERP.

2.2.3. Мобильное приложение

Мобильное приложение для складских работников и сотрудников производства обеспечивает доступ к основным функциям системы с мобильных устройств (смартфоны, планшеты). Реализовано на базе Progressive Web Application (PWA) на основе приложения warehouse-worker.

2.2.4. Вспомогательные сервисы (microservices/)

В состав исходного кода ПК на стороне backend включён каталог microservices/: самостоятельные программные сервисы (в т.ч. Telegram-бот, AI-ассистент с внешними сценариями автоматизации, обработка PDF-накладных и др.). Они входят в описываемый объект как компоненты комплекса, обеспечивающие специализированные интеграции и фоновую обработку; их объём учитывается совместно с основным backend при методологии § 4.2.1. Развёртывание может осуществляться контейнерами или отдельными процессами — без изменения правовой квалификации единого комплекса.

---

2.3. Функциональные модули

ПК «NARMAK» включает 17 предметных функциональных модулей (п. 2.3.1–2.3.17), реализованных на уровне серверной части (44 Django-приложения в доменной структуре backend) и клиентских приложений. Сквозной основой является базовый контур платформы (п. 2.3.0): идентификация пользователей, справочники, номенклатура и остатки как связка с логистикой и производством. Детальный перечень требований к функциям — в § 3.2.1.

2.3.0. Базовые функции платформы (users, vocabulary, product, stock и API)

Элемент	Содержание
Назначение	Единая точка входа в Систему: безопасность, справочная база, номенклатура и учётные остатки как фундамент для торговли, производства, склада и финансовых разрезов.
Ключевые объекты данных	Учётные записи и профили, роли и разрешения; нормативно-справочная информация (vocabulary); карточки номенклатуры и взаимосвязи (product); складские остатки и движения на уровне учёта (stock, в связке с модулем склада п. 2.3.2).
Основные операции	Аутентификация и сессии; RBAC; ведение справочников и классификаторов; ведение номенклатуры; учёт остатков и движений (в т.ч. для согласования с операциями склада и производства); базовый аудит действий (см. § 3.2.4).
Типовые роли	Администраторы и супервайзеры данных; офисные пользователи; склад; руководители (чтение сводов).
Входы / выходы	REST API основной линии /api/v2/; отдельный контрагентский API /c-api/v1/ для приложения личного кабинета контрагента; WebSocket для оперативных обновлений; импорт/обмен данными через интеграции доменных модулей.
Связь с модулями	Используется всеми предметными модулями п. 2.3.1–2.3.17 как общая основа данных и доступа.

2.3.1. Управление производством (manufacture)

Элемент	Содержание
Назначение	Планирование и исполнение производства, учёт норм и выпуска, загрузка мощностей, сопряжение с потребностью в материалах и BPM-регламентами.
Ключевые объекты данных	Производственные задания и этапы; нормы расхода; маршруты и загрузка ресурсов; потребности (в т.ч. MRP-подобная логика); учёт брака и несоответствий (согласованно с качеством).
Основные операции	Планирование и сдвиги графика (в т.ч. Ганта); выпуск и отчётность по выпуску; управление производственными нуждами; запуск/контроль регламентов через Camunda.
Типовые роли	Плановики производства; мастера смен; руководители производства; офис снабжения (косвенно через потребности).
Входы / выходы	Заказы и складские остатки на входе; производственные отчёты, движения материалов/ГП, задания интеграций на выходе.
Связь с модулями	Склад и номенклатура (материалы и выпуск); закупки (покрытие дефицита); финансы (себестоимость и управленческие разрезы — по настройке); качество; документооборот.

2.3.2. Управление складом (warehouse_zones, storage, stock)

Элемент	Содержание
Назначение	Физическая и адресная логистика на складе, операционные движения ТМЦ, инвентаризация, сопряжение с отгрузкой/приёмкой и производством.
Ключевые объекты данных	Зоны, ряды, ячейки; остатки в разрезе SKU, партий, сроков годности; складские операции и история перемещений.
Основные операции	Приёмка, отгрузка, перемещение, списание, инвентаризация; сканирование штрих-/QR-кодов (в т.ч. с PWA).
Типовые роли	Кладовщики; старшие смены; логисты; офис (контроль и отчёты).
Входы / выходы	Заказы, производственные задания, закупки; складские документы и остатки для продаж, финансов и аналитики.
Связь с модулями	Продажи и закупки (исполнение); производство (материалы и ГП); документооборот; маркетплейсы (отгрузочные контуры).

2.3.3. Документооборот (document)

Элемент	Содержание
Назначение	Единый электронный контур первичных и сопроводительных документов: создание, согласование, хранение, связность и печатные формы.
Ключевые объекты данных	Экземпляры документов, шаблоны, маршруты согласования, версии, связи между документами, архив.
Основные операции	Создание по шаблонам; маршрутизация согласований (в т.ч. через Camunda); генерация PDF и Word; связанные документы и автоматизированное порождение производных записей.
Типовые роли	Офис продаж/закупок/бухгалтерии; юристы; руководители (утверждение); контрагенты (ограниченный контур в ЛК).
Входы / выходы	Бизнес-объекты модулей продаж/закупок/склада/финансов; выход — подписанные/утверждённые файлы и записи в архиве.
Связь с модулями	Почти все операционные модули; договоры; контрагенты; уведомления.

2.3.4. Управление продажами (sale, order, cart)

Элемент	Содержание
Назначение	Управление коммерческим циклом от интереса до отгрузки: заказы, цены, отгрузки и контроль дебиторки.
Ключевые объекты данных	Клиентские сделки, корзины и заказы; коммерческие предложения; ценовые условия; отгрузки; дебиторская задолженность.
Основные операции	Воронка лид → КП → заказ → отгрузка; резервирование/отбор под отгрузку (в связке со складом); контроль оплат (со финансами).
Типовые роли	Менеджеры продаж; руководители отдела; финансовый контролёр; логист.
Входы / выходы	Номенклатура и остатки; контрагенты и договоры; маркетплейс-заказы; счета и акты через документооборот.
Связь с модулями	Склад; финансы; контрагенты; маркетплейсы; аналитика.

2.3.5. Управление закупками (purchase)

Элемент	Содержание
Назначение	Обеспечение предприятия материалами и услугами: от потребности до заказа поставщику и приёмки.
Ключевые объекты данных	Заявки на закупку; запросы и сравнение предложений; заказы поставщикам; статусы исполнения.
Основные операции	Планирование закупок от производства и минимальных остатков; согласование; размещение заказа; контроль поставки.
Типовые роли	Снабженцы; закупщики; финансовый контроль; склад (приёмка).
Входы / выходы	Потребности и остатки; реестр поставщиков; платёжный календарь; приходные документы.
Связь с модулями	Склад; производство; финансы; контрагенты; документооборот.

2.3.6. Финансовый модуль (finance, payment, invoice, bank, banks, intercompany_settlements)

Элемент	Содержание
Назначение	Управленческий финансовый контур: платежи, счета, банковские операции, межкомпанийные расчёты и управленческая отчётность.
Ключевые объекты данных	Платёжный календарь (план/факт); счета на оплату; банковские выписки и сверки; ЦФО/разрезы управленческого учёта; межкомпанийные проводки/взаиморасчёты.
Основные операции	Учёт к оплате и оплат; загрузка выписок; сверка; отчёты P&L, Cash Flow, баланс в управленческом контуре (см. § 3.2.1.6).
Типовые роли	Финансовый директор; бухгалтерия/казначейство; контроллинг; руководители подразделений (лимиты).
Входы / выходы	Документы продаж/закупок; банк; отчётность для аналитики и руководства.
Связь с модулями	Продажи (дебиторка); закупки (кредиторка); документы; межкомпанийные сущности.

2.3.7. Управление контрагентами (counterparty, legal_dossier)

Элемент	Содержание
Назначение	Единый реестр юридических и физических контрагентов, юридические досье и условия работы.
Ключевые объекты данных	Карточки контрагентов; реквизиты и проверки; досье (документы, история); лимиты и условия отсрочки.
Основные операции	Создание/обогащение (DaData); сегментация; кредитные лимиты; связь с договорами и сделками.
Типовые роли	Менеджеры продаж и закупок; юристы; финансы; безопасность/комплаенс (по регламенту).
Входы / выходы	Внешние реквизиты; внутренние решения по лимитам; обмен с ЛК контрагента.
Связь с модулями	Продажи; закупки; договоры; финансы; документооборот.

2.3.8. Управление договорами (contracts)

Элемент	Содержание
Назначение	Реестр договоров, жизненный цикл согласования и исполнения, контроль сроков.
Ключевые объекты данных	Договор, приложения; статусы и этапы; шаблоны; сроки и пролонгации; сканы.
Основные операции	Согласование; напоминания о сроках; генерация из шаблонов; связь со сделками и документами.
Типовые роли	Юристы; руководители; финансы; менеджеры.
Входы / выходы	Контрагенты; проекты договоров; печатные формы и архив.
Связь с модулями	Контрагенты; продажи/закупки; документооборот; уведомления.

2.3.9. Интеграция с маркетплейсами (marketplace)

Элемент	Содержание
Назначение	Омниканальные продажи через Wildberries, Ozon и др.: остатки, заказы, цены, аналитика канала.
Ключевые объекты данных	Каталоги и сопоставление SKU; очереди заказов; ценовые правила; журналы обмена.
Основные операции	Синхронизация остатков; приём и обработка заказов в единый операционный контур; обновление цен; сводная аналитика по каналам.
Типовые роли	E-commerce менеджеры; склад (исполнение); финансы (выручка/комиссии — по настройке).
Входы / выходы	Внешние API маркетплейсов; внутренние остатки и заказы.
Связь с модулями	Склад; продажи; номенклатура; финансы; уведомления.

2.3.10. Управление персоналом — HR (company_structure, employee_leads, employee_debt, employee_private_office)

Элемент	Содержание
Назначение	Кадрово-организационный контур: структура, сервисы для сотрудника, внутренние HR-процессы и взаиморасчёты с персоналом (в заявленных границах модуля).
Ключевые объекты данных	Оргструктура; должности и подчинённость; ЛК сотрудника; лиды/запросы по персоналу; внутренние задолженности/удержания (по регламенту).
Основные операции	Ведение структуры; самообслуживание сотрудника; учёт обязательств перед работодателем/наоборот в модуле employee_debt; маршрутизация HR-заявок.
Типовые роли	HR; руководители; сотрудники; финансы (ограниченно).
Входы / выходы	Заявки и документы; уведомления; связь с задачами и LMS.
Связь с модулями	ATS; LMS; задачи; коммуникации.

2.3.11. Подбор персонала — ATS (ats)

Элемент	Содержание
Назначение	Поддержка воронки найма от вакансии до выхода на работу.
Ключевые объекты данных	Вакансии; кандидаты; этапы воронки; история контактов; интеграции с источниками.
Основные операции	Публикация/учёт откликов; интервью и статусы; оффер; передача в HR после найма.
Типовые роли	Рекрутеры; HR-бизнес-партнёры; руководители подразделений.
Входы / выходы	Внешние площадки вакансий; внутренние заявки на подбор; уведомления.
Связь с модулями	HR (оргструктура и сотрудники); задачи; коммуникации.

2.3.12. Обучение персонала — LMS (lms)

Элемент	Содержание
Назначение	Управление обучением: каталог, назначения, тесты и треки компетенций.
Ключевые объекты данных	Курсы и модули; треки; назначения; результаты тестов; статистика прохождения.
Основные операции	Назначение курсов; прохождение; контроль дедлайнов; отчёты по базе знаний.
Типовые роли	HR-развитие; руководители; наставники; сотрудники.
Входы / выходы	Сотрудники из HR; уведомления; экспорт в отчёты аналитики.
Связь с модулями	HR; качество (инструктажи — по регламенту); задачи.

2.3.13. Управление транспортом — TMS (tms)

Элемент	Содержание
Назначение	Планирование и учёт логистики собственного или привлечённого транспорта.
Ключевые объекты данных	Транспортные средства; маршруты и рейсы; назначения водителей; расходы на логистику.
Основные операции	Планирование доставок; учёт рейсов; контроль затрат; связка с отгрузками со склада.
Типовые роли	Логисты; экспедиторы; руководители цепочки поставок; склад (отгрузка).
Входы / выходы	Заказы и адреса доставки; транспортные документы; аналитика затрат.
Связь с модулями	Продажи; склад; финансы (расходы); аналитика.

2.3.14. Техническое обслуживание (plantmaintenance)

Элемент	Содержание
Назначение	ТОиР оборудования: планы, заявки, история простоев и работ.
Ключевые объекты данных	Единицы оборудования; графики ППР; заявки на ремонт; журналы выполнения работ.
Основные операции	Планирование ТО; регистрация поломок; закрытие работ; отчётность по надёжности.
Типовые роли	Инженеры ТОиР; механики; производственные руководители.
Входы / выходы	Производственный календарь; наряды; учёт запчастей (со складом, по процессу).
Связь с модулями	Производство; склад; качество; задачи.

2.3.15. Контроль качества (qcheck, haccp_journals)

Элемент	Содержание
Назначение	Контроль качества продукции и производственной дисциплины; для пищевого производства — HACCP-журналы.
Ключевые объекты данных	Чеклисты проверок; журналы критических точек; акты несоответствий; претензионная работа.
Основные операции	Плановые и внеплановые инспекции; фиксация отклонений; отчёты по браку; уведомления ответственным.
Типовые роли	Специалисты ОТК; технологи; руководители производства.
Входы / выходы	Партии и выпуск; входной контроль от закупок; корректировки в производство и склад.
Связь с модулями	Производство; закупки; LMS; документооборот.

2.3.16. Коммуникации и уведомления (discussion, telegram, notifications)

Элемент	Содержание
Назначение	Коллаборация пользователей и проактивные уведомления о событиях в Системе.
Ключевые объекты данных	Темы обсуждений, привязанные к сущностям; подписки на события; каналы доставки.
Основные операции	Комментирование и обсуждения; push в браузере (WebSocket); Telegram-бот для уведомлений; email (см. ТЗ).
Типовые роли	Все категории пользователей выборочно по правам.
Входы / выходы	События доменных модулей; исходящие сообщения во внешние каналы.
Связь с модулями	Документы; задачи; согласования; интеграции (в т.ч. Kafka для асинхронности).

2.3.17. Аналитика и отчётность (reports, gantt, tasks)

Элемент	Содержание
Назначение	Управленческая картина по данным Системы: отчёты, дашборды, проектные сроки и операционные задачи.
Ключевые объекты данных	Настраиваемые отчёты; показатели дашбордов; диаграммы Ганта; проекты и задачи.
Основные операции	Выгрузки в Excel/PDF; визуализация KPI; планирование проектов; постановка и контроль задач.
Типовые роли	Руководители; аналитики; PMO; функциональные менеджеры.
Входы / выходы	Витрины данных операционных модулей; файлы отчётов; уведомления о дедлайнах.
Связь с модулями	Производство (Ганта); финансы; продажи; склад; интеграции с BPM.

2.3.18. Сквозные бизнес-процессы (интеграция модулей)

Для целей идентификации сложности и связности ПК ниже приведены типовые сквозные цепочки (без претензии на исчерпание отраслевых регламентов):

1. Продажа со склада (B2B / дистрибуция): заказ клиента → резерв/отбор → отгрузка и складские движения → печатные формы (документооборот) → счёт и оплата (финансы) → контроль дебиторки и отчёт аналитики.
2. Обеспечение производства закупкой: потребность производства / минимальный остаток → заявка и заказ закупок → приёмка на склад → оприходование и оплата поставщику (финансы).
3. Производственный цикл: запуск производственного задания → списание материалов со склада → выпуск готовой продукции → возврат на склад ГП → учёт качества при отклонениях.
4. Маркетплейс-канал: загрузка заказа WB/Ozon → обработка в продажах / очереди → списание остатков маркетплейт ↔ склад → документы и выручка (управленческий контур финансов).
5. Согласование договора и сделки: карточка контрагента → проект договора и маршрут Camunda → подписание и архив (документооборот) → исполнение заказов с лимитами.
6. Сервисное обслуживание оборудования: план ТОиР → заявка простоя → выполнение работ и запчасти со склада → влияние на производственный график.
7. Подбор и развитие персонала: вакансия ATS → найм → карточка в HR → назначение LMS-курса по должности.
8. Контроль качества партии: входной контроль закупок / межоперационный контроль производства → акт несоответствия → корректирующие действия и учёт в качестве и документах.

---

2.4. Технологические интеграции

Внешняя система	Тип интеграции	Назначение
Camunda BPM	REST API	Автоматизация бизнес-процессов
Apache Kafka	Message Queue	Асинхронная передача событий
Telegram	Bot API	Уведомления пользователей
DaData	REST API	Автозаполнение реквизитов контрагентов
Wildberries	REST API	Маркетплейс-интеграция
Ozon	REST API	Маркетплейс-интеграция
Яндекс Карты	Виджет JavaScript API (обёртка Angular для картографии Яндекса), веб-ссылки на сервис карт; обмен с серверной частью по REST в контуре TMS	Отображение карт и маршрутов в main-office и warehouse-worker; разбор маршрута по публичной ссылке Яндекс.Карт и подготовка данных для отображения на стороне backend
Модульбанк	REST API (api.modulbank.ru)	Банковские операции и выписки (синхронизация с модулем bank / реестрами платежей)
Тинькофф Бизнес	Open API (business.tinkoff.ru/openapi)	Загрузка операций по счёту, синхронизация движений
Банк Точка (Enter)	Open Banking API / OAuth (enter.tochka.com)	Выписки, остатки по счетам (в репозитории реализован клиент API; фактическое включение — по настройке внедрения)
Файловый импорт выписок	Загрузка файла (обмен с банком / разбор в коде через импорт, совместимый с контуром 1С)	Альтернатива API: импорт банковской выписки из файла в учётный контур
Selectel (облачное хранилище)	HTTP API пакета (аутентификация auth.selcdn.ru, выдача через CDN *.selcdn.ru)	Хранение файлов и вложений документооборота (и связанные контуры), публичные ссылки на объекты
Selectel Object Storage (S3-совместимый)	Протокол S3 (endpoint региона вида *.storage.selcloud.ru, ключ/секрет)	Объектное хранилище в инфраструктуре развёртывания: в репозитории — примеры конфигурации для микросервисов с совместимым с Amazon S3 клиентом

Реализованный набор банковских интеграций и режимов (API против файла) зависит от настройки внедрения и включённых учётных записей; перечень отражает наличие соответствующего кода в серверной части (app/bank, app/banks).

Selectel: основной Django-backend использует нативный API Selectel Cloud Storage через django-selectel; отдельно в проекте может подключаться S3-совместимый слой того же провайдера (Object Storage) для иных компонентов стека — см. настройки окружения и docker-compose микросервисов (в репозитории встречается endpoint вида *.storage.selcloud.ru).

Яндекс Карты: сервис и карта — продукт Яндекса; использование виджета и тайлов регулируется условиями Яндекса (ключ API при настройке внедрения). В объект оценки как программа для ЭВМ входит код интеграции в frontend/backend, а не сервис картографии.

---

2.5. Характеристика объёма программного комплекса (метрика для оценки)

Актуальные показатели объёма собственного исходного кода приведены в разделе 4 настоящего документа (методология cloc, колонка code, политика исключений CSV/JSON, отдельный учёт сгенерированного API-клиента). Ранние оценки объёма без фиксированной методологии не используются как эталонные.

2.7. Срок использования

• Фактический срок использования: с 2020 года по дату оценки (28.02.2026) — 5 лет 2 месяца
• Характер использования: внутреннее использование в операционной деятельности предприятия; планируется коммерческое лицензирование сторонним организациям

3. Объём исходного кода, языки программирования и методология подсчёта

Дата подсчёта: 20 марта 2026 года
Инструмент: cloc 2.08
Фиксация исходников (коммиты Git):

• Backend narmak_v2: 934ef92e73e85120d4f27c34f949d9206f385813
• Frontend narmak-nx-angular-main: bd1550101995a5bf034b77149c10d7a376bf38e6

---

3.1. Методология

Подсчёт выполнялся по файлам из индекса Git (cloc --vcs=git): учитываются только отслеживаемые версией репозитории файлы; каталоги вроде node_modules, .venv, dist в Git не входят и в анализ не попадают.

Метрика «строки кода»: в таблицах раздела 4.2 указано значение колонки code утилиты cloc — строки, классифицированные как исполняемый/содержательный код языка (без пустых строк и без строк, отнесённых cloc к комментариям). Это сопоставимо с распространённой практикой SLOC/NCLOC и отличается от «физических» строк файла (wc -l), где учитываются пустые строки и комментарии.

Политика включения и исключения (для сопоставимости с «собственным кодом» ПК):

Политика	Решение
Файлы CSV в backend (справочные и прочие данные, не логика)	Исключены из метрик подраздела 4.2 (--exclude-ext=csv)
Файлы JSON во frontend (в т.ч. крупные датасеты в assets, конфигурация Nx)	Исключены из метрик подраздела 4.2 (--exclude-ext=json)
Каталоги libs/sdk, libs/sdk-counterparty (клиент API, формируется из Swagger/OpenAPI)	Учтены отдельной строкой «Сгенерированный API-клиент»
Автотесты (*.spec.ts)	Включены в основные цифры; объём несущественен при данной гранулярности; при необходимости отдельный подсчёт: cloc ... --not-match-f='\\.spec\\.ts$'
Прочие языки в репозиториях (Markdown, vendored JS/CSS в assets, и т.д.)	Не входят в сводный столбец раздела 4.2.6; кратко указаны для backend в п. 1.5

Воспроизведение подсчёта (выполнять из корня соответствующего репозитория):

# Backend — каталоги приложения; CSV не учитываются
cloc --vcs=git --exclude-ext=csv app narmak microservices config

# Frontend — приложения (apps), без JSON
cloc --vcs=git --exclude-ext=json apps

# Frontend — библиотеки без JSON и без сгенерированных SDK
cloc --vcs=git --exclude-ext=json --exclude-dir=sdk,sdk-counterparty libs

# Сгенерированный API-клиент
cloc --vcs=git --exclude-ext=json libs/sdk libs/sdk-counterparty

При наличии локальных нечитаемых путей (Git LFS, права) cloc может выводить Unable to read ... — перед фиксацией отчёта для ОИС рекомендуется восстановить файлы (git lfs pull и т.п.) и повторить запуск.

---

3.2. Собственный код правообладателя

3.2.1. Серверная часть (Backend)

Охват: каталоги app/, narmak/, microservices/, config/. Файлы .csv исключены (см. методологию).

Язык / тип файлов	Кол-во файлов	Строк кода (cloc, code)
Python (.py)	1 618	140 650
Итого по п. 4.2.1	1 618	140 650

3.2.2. Веб-приложения (Frontend — директория apps/)

Файлы .json исключены.

Язык / тип файлов	Кол-во файлов	Строк кода (cloc, code)
TypeScript (.ts)	853	170 030
HTML-шаблоны (.html)	565	109 939
Стили SCSS (.scss)	316	59 606
Итого Frontend Apps	1 734	339 575

3.2.3. Библиотеки (Frontend — директория libs/)

Без каталогов sdk/ и sdk-counterparty и без файлов .json.

Язык / тип файлов	Кол-во файлов	Строк кода (cloc, code)
TypeScript (.ts)	898	108 973
HTML-шаблоны (.html)	53	15 290
Стили SCSS (.scss)	84	8 810
Итого Frontend Libs (ручной код)	1 035	133 073

3.2.4. Сгенерированный API-клиент (Frontend)

Формируется из контракта REST API; исходники в libs/sdk, libs/sdk-counterparty. Файлы .json исключены.

Компонент	Кол-во файлов	Строк кода (cloc, code)
TypeScript (.ts)	434	91 489
Итого API-клиент	434	91 489

3.2.5. Прочие артефакты в backend-репозитории (справочно)

Те же каталоги, что в п. 1.1, без CSV. Дополнительно к Python в индексе Git присутствуют, в частности: Markdown (документация), JSON, HTML, подключаемый JS/CSS, YAML, Dockerfile и др. — их объём не суммируется с показателями раздела 4.2.1–4.2.4, чтобы не смешивать прикладной код ПК с документацией и статикой админки/прототипов.

3.2.6. Сводная таблица

Компонент	Языки	Файлов	Строк кода (cloc, code)
Backend (серверная часть)	Python	1 618	140 650
Frontend Apps	TypeScript, HTML, SCSS	1 734	339 575
Frontend Libs (ручной код)	TypeScript, HTML, SCSS	1 035	133 073
Frontend API-клиент (ген.)	TypeScript	434	91 489
ИТОГО (подраздел 4.2, собственный код)		4 821	704 787

---

4.3. Используемые языки программирования

Язык	Версия	Применение
Python	3.10+	Серверная бизнес-логика, API, обработка данных, интеграции
TypeScript	5.x	Клиентская логика, компоненты Angular
HTML	5	Шаблоны компонентов Angular
SCSS	—	Стили компонентов и приложений
SQL	PostgreSQL 14+	Хранение и запросы данных (через Django ORM)

---

---

5. Open Source, покупные решения, инфраструктура и DevOps

5.1. Open Source компоненты — Backend

Библиотека	Версия	Лицензия	Назначение
Django	5.1.4	BSD-3-Clause	Веб-фреймворк
djangorestframework	3.15.2	BSD-2-Clause	REST API
celery	5.2.3	BSD	Асинхронные задачи
redis	5.1.0	MIT	Кэш, брокер
psycopg2-binary	2.9.2	LGPL	Драйвер PostgreSQL
channels	4.0.0	BSD	WebSocket
daphne	—	BSD	ASGI-сервер
pandas	2.2.3	BSD	Обработка данных
numpy	2.1.1	BSD	Математика
openpyxl	3.0.10	MIT	Excel
weasyprint	66.0	BSD	PDF
docxtpl	0.16.7	LGPL	Word-шаблоны
django-cors-headers	4.4.0	MIT	CORS
drf-yasg	1.21.4	BSD	Swagger
pytelegrambotapi	4.7.1	GPL-3.0	Telegram Bot
dadata	21.10.1	MIT	DaData API
confluent-kafka	—	Apache 2.0	Kafka
django-camunda	—	MIT	Camunda BPM

Большинство перечисленных зависимостей распространяется под лицензиями MIT, BSD, Apache 2.0, LGPL и может использоваться в коммерческих продуктах при соблюдении текста соответствующей лицензии. Зависимость pytelegrambotapi (GPL-3.0) накладывает требования copyleft: при совмещении с проприетарным кодом и распространении результата необходимо учитывать условия GPL (в том числе раскрытие исходного кода производной работы в предусмотренных лицензией случаях). Окончательную юридическую оценку сценария использования даёт правообладатель совместно с юристом.

---

5.2. Open Source компоненты — Frontend

Библиотека	Версия	Лицензия	Назначение
@angular/core	18.0.0	MIT	Фреймворк
rxjs	7.5.0	Apache 2.0	Реактивность
@datorama/akita	8.0.1	MIT	State Management
primeng	17.18.15	MIT	UI-компоненты
@taiga-ui/core	3.95.2	Apache 2.0	UI-компоненты
bootstrap	5.2.3	MIT	CSS-фреймворк
primeflex	3.3.1	MIT	CSS утилиты
@ngx-formly/core	6.3.1	MIT	Динамические формы
chart.js	4.5.0	MIT	Графики
apexcharts	3.36.3	MIT	Графики
d3	7.9.0	ISC	Визуализация
jspdf	2.5.1	MIT	PDF
xlsx	0.18.5	Apache 2.0	Excel
docx	9.5.1	MIT	Word
quill	1.3.7	BSD	Rich Text
tinymce	8.0.1	MIT	WYSIWYG
moment	2.29.4	MIT	Даты
date-fns	4.1.0	MIT	Даты
lodash	4.17.21	MIT	Утилиты
@zxing/browser	—	Apache 2.0	QR-коды
tesseract.js	5.1.0	Apache 2.0	OCR
bpmn-js	5.5.1	MIT	BPMN-диаграммы
nx	—	MIT	Монорепозиторий

Перечисленные open source компоненты Frontend, как правило, допускают коммерческое использование при соблюдении условий соответствующих лицензий (MIT, Apache 2.0, BSD, ISC).

---

5.3. Покупные решения

Решение	Тип	Условия
Camunda BPM (Community Edition)	Open Source	Apache 2.0, бесплатно
PostgreSQL	Open Source	PostgreSQL License, бесплатно
Redis	Open Source	BSD, бесплатно
Apache Kafka	Open Source	Apache 2.0, бесплатно
TinyMCE (Self-hosted)	Open Source / Коммерческий	MIT для open source версии

Покупных (проприетарных) решений с платными лицензиями в составе ПК «NARMAK» не используется. Сторонние компоненты в основном являются open source; условия конкретной лицензии следует проверять перед включением в поставку (см. п. 5.1 в отношении GPL).

---

5.4. Инфраструктура и DevOps

Компонент	Технология	Лицензия
Контейнеризация	Docker	Apache 2.0
Оркестрация	Docker Compose	Apache 2.0
Веб-сервер	Nginx	BSD-2-Clause
CI/CD	GitHub Actions / GitLab CI	—
Мониторинг	—	—

---