arm-ka-docs/context/02-glossary.md

02. Глоссарий: бухгалтерский язык → язык системы

Формат: Термин — что это для бухгалтера → как это выглядит в АРМ КА (таблица/поле/правило).

Отчётность и формы

• ББ, Бухгалтерский баланс (форма 0710001, «форма 1») — состояние активов и пассивов на дату. Строки с кодами 1110…1700 (актив 1100–1600, пассив 1300–1700), три колонки-даты (отчётная, конец прошлого года, конец позапрошлого). → document.document_type = BALANCE, шапка financial_statement_meta (statement_type = balance), колонки financial_statement_column (period_date, is_current), строки financial_statement_line.line_code, числа financial_statement_value.amount. Единицы — обычно тыс. руб. (meta.units).
• ОФР, Отчёт о финансовых результатах (0710002, «форма 2») — доходы и расходы за период (обороты, не остатки). Коды 2110…2400 (2110 выручка, 2120 себестоимость, 2200 прибыль от продаж, 2300 до налогообложения, 2400 чистая прибыль). → document_type = INCOME, statement_type = income, те же таблицы.
• ОСВ, Оборотно-сальдовая ведомость по счёту — выгрузка из 1С по одному синтетическому счёту (60, 62, 76…) с детализацией по субсчетам и субконто (контрагенты, договоры, подразделения). Шесть сумм в строке: сальдо на начало Дт/Кт, обороты за период Дт/Кт, сальдо на конец Дт/Кт. Единицы — рубли с копейками. → document_type = OSV, document.osv_account_code, строки osv_entry (opening_*, turnover_*, closing_*).
• Расшифровка — приложение к отчётности в свободной/рекомендуемой форме (кредиты и займы, дебиторы/кредиторы, поручительства, аренда, лизинг, залог; см. Форма расшифровки к отчетности *.xlsx). → document_type = DISCLOSURE; разбор расшифровок вне scope первой очереди (ANL-040).
• Отчётная дата / отчётный период — ББ «на дату» (30.09.2025), ОСВ и ОФР «за период» (9 месяцев 2025 / 3 квартал 2025). В банке период обозначают следующим днём: 01.10.2025 = 9 мес. 2025. Отчётность — нарастающим итогом с начала года. → consolidation.year/quarter/reporting_date, document.period_year/period_quarter/is_cumulative.
• Нарастающий итог (cumulative) — ОСВ за «9 месяцев»: обороты с 1 января. ОСВ «за 3 квартал» из 1С может быть и квартальной (обороты только июль–сентябрь), и нарастающей — определяется по шапке/суммам. → document.is_cumulative; правило приведения квартальных ОСВ к нарастающим — 05-domain-rules.md §2.
• Единица измерения — ББ/ОФР в тыс. руб. (реже руб.), ОСВ в руб. → financial_statement_meta.units; при сопоставлении ОСВ ↔ строки ББ переводить явно.
• Коды строк (ОКУД, Приказ 66н / ФСБУ 4/2023) — четырёхзначные идентификаторы статей (1230, 1520, 2110). → financial_statement_line.line_code, kfo_result_line.line_code, elimination_rule.article_*_line, correction.debit_line_code/credit_line_code. Шаблон порядка строк и разделов — на фронте, не в БД.
• Контрольные соотношения / логические проверки — равенства, которые должны выполняться внутри формы (1600 = 1100 + 1200; 1700 = 1600; 2400 = 2300 − 2410 + 2420) и между формами (Δ1370 = 2400). → считаются на лету по financial_statement_value; результат не хранится; непройденные проверки держат документ в NEEDS_CHECK, аналитик может акцептовать с комментарием (meta.checks_accepted_*).

План счетов и ОСВ

• Счёт, субсчёт, субсубсчёт — 60 → 60.01 → 60.01.1. В 1С пишут «60.1», в нормализованном виде — «60.01». → chart_of_account.code (нормализованный), row_type = account / subaccount / analytic, parent_id. Нормализация кода — в коде, не в справочнике (ARCH-004).
• Активный / пассивный / активно-пассивный счёт (A / P / AP) — на каком плече обычно сальдо. 60 (поставщики) и 62 (покупатели) — AP: 60.01 кредиторка (Кт), 60.02 авансы выданные (Дт); 62.01 дебиторка (Дт), 62.02 авансы полученные (Кт). → chart_of_account.kind; используется шахматкой для выбора дебетовых/кредитовых наборов.
• Забалансовый счёт — 001, 008, 009, 011 (арендованные ОС, обеспечения выданные/полученные). → is_off_balance.
• Дебет / Кредит (Дт/Кт) — две стороны записи. Для нас: Дт сальдо = нам должны (актив), Кт сальдо = мы должны (пассив) на расчётных счетах. Встречная операция у контрагента отражается на противоположной стороне: у А Дт 62 (покупатель должен) ↔ у Б Кт 60 (мы должны поставщику).
• Сальдо — остаток на дату; оборот — сумма движений за период. Тождество строки: opening_debit − opening_credit + turnover_debit − turnover_credit = closing_debit − closing_credit (развёрнутое сальдо хранится по сторонам, свёрнутое — разница). Полезно как контрольная сумма парсера.
• Субконто — аналитический разрез счёта в 1С: Контрагенты, Договоры, Подразделения, Номенклатура и т. п. Шапка ОСВ перечисляет субконто в порядке вложенности. → recognition_job.group_schema ([{type: ACCOUNT}, {type: DEPARTMENT}, {type: COUNTERPARTY, has_inn}, {type: CONTRACT}]), тип строки — osv_entry.group_type, исходное название — group_name.
• Уровень группировки (outline level) — отступ строки в Excel (сворачиваемые группы 1С). Единственный надёжный признак вложенности строк ОСВ. → osv_entry.level; родитель — parent_entry_id (открытый вопрос №2).
• Контрагент — организация/ИП/физлицо в строке ОСВ. В одной ОСВ он — текст; ИНН бывает отдельной колонкой (не всегда). → osv_entry.counterparty_name/inn (сырые, не меняются), counterparty_id (резолв в legal_entity), словарь написаний legal_entity_alias.
• Выводимые данные: БУ / НУ / Вал. / Кол. — ОСВ может содержать строки бухгалтерского учёта, валютные (дублируют сумму в валюте) и количественные. В расчёт берём только БУ (и «сумма» для шапки варианта 2). → osv_entry.data_type ∈ {BU, CURRENCY, QUANTITY, SUM}.
• Типичные счета в консолидации — 01 ОС, 02 амортизация ОС, 03 доходные вложения, 08 вложения во внеоборотные, 58 финвложения (58.01 доли/акции, 58.03 займы выданные), 60 поставщики (60.01 кредиторка, 60.02 авансы выданные), 62 покупатели (62.01 дебиторка, 62.02 авансы полученные), 66/67 краткосрочные/долгосрочные кредиты и займы (…01 кредиты, …02 проценты по кредитам, …03 займы, …04 проценты по займам), 76 прочие дебиторы/кредиторы (76.03/76.05/76.07/76.09… — субсчета, часть из них аренда/лизинг), 80 уставный капитал, 83 добавочный капитал, 90 продажи (90.01 выручка, 90.03 НДС), 91 прочие доходы/расходы.

Группы и организации

• ГК — группа компаний — верхний уровень справочника клиентов, импорт из ЕЦП CRM (crm_id), закреплена за филиалом. → company_group (SCD4: живая таблица + company_group_history).
• ГСК — группа связанных компаний — подмножество ГК, по которому строится КФО. ГСЗ — группа связанных заёмщиков — другое подмножество (регуляторное, 115-И/254-П логика). ЮЛ может быть только в одной ГСК или ГСЗ. → related_group.kind ∈ {gsk, gsz}, состав related_group_member (SCD2, is_current).
• ЮЛ / ИП — юридическое лицо / индивидуальный предприниматель. Натуральный ключ — ИНН (10 знаков ЮЛ, 12 ИП). → legal_entity (inn UNIQUE, entity_type, company_group_id NULL = монозаёмщик).
• Периметр консолидации — зафиксированный список компаний конкретной версии КФО. Изменение состава ГСК в справочнике не меняет существующие версии. → consolidation_member (+ is_head_entity).
• Головная / дочерняя организация (ГО / ДО) — в контексте гудвилла: кто владеет долей в ком. (Не путать с ГО — головной офис банка: в DBML regional_office.is_head_office, статусы CONSOLIDATION_GO.)
• Монозаёмщик — ЮЛ вне ГК; его данные в ЕХ лежат без консолидации.
• Филиал (РФ) / Головной офис (ГО) — определяет видимость данных пользователя и маршрут согласования. → regional_office, app_user.regional_office_id, consolidation_version.initiator_office_id.
• ЗО — зона ответственности — сегмент бизнеса: ДКБ (крупный), ДМСБ (малый и средний), ДМ (микро). → app_user.business_segment.

Консолидация

• КФО — консолидированная финансовая отчётность (ГСК) — ББ и ОФР группы «как одной компании»: сумма по компаниям минус внутригрупповые обороты/остатки. → kfo_result (шапка, пороги) + kfo_result_line (по кодам строк: sum_amount → eliminated_auto → eliminated_manual → goodwill_adjust → consolidated_amount) + kfo_result_line_company (разрез по компаниям, доли).
• ВГО — внутригрупповые обороты / обязательства — расчёты между компаниями одного периметра, которые при консолидации надо исключить. Встречное отражение: у А Дт 62.01 контрагент Б = X ↔ у Б Кт 60.01 контрагент А = X. → пары ВГО не хранятся, вычисляются из osv_entry по правилам elimination_rule(_account) (Прил. 3 ТЗ).
• Элиминация — исключение ВГО из строк ББ/ОФР. Авто-элиминация — по правилам (elimination_mode: min — минимум из двух сторон, full — вся сумма (выручка), manual). → kfo_result_line.eliminated_auto.
• Сопоставление ВГО / матчинг — поиск встречной записи у второй компании (1:1, по допустимым парам счетов, сторона противоположная, выбор по минимальному расхождению). → алгоритм 05-domain-rules.md §5.
• Шахматка — матрица «компания × компания» с суммами Дт у А, Кт у Б и расхождением; ячейки > 5 % подсвечены. → вычисляется, не хранится; комментариев к ячейкам нет (v5.22), обязательный комментарий к правке пары — correction.comment.
• Расхождение (deviation) — |Дт − Кт|, процент — к меньшей из сумм (Методика, сноска 14). → correction.deviation_amount/percent, client_kfo_line.deviation_*, kfo_result.total_deviation_*.
• Корректировка — ручное решение аналитика: какую сумму и из каких строк ББ/ОФР исключить по Дт и Кт. Это overlay: первичка не меняется, итог = свод − Σ корректировок. → correction (+ дочерние строки распределения через parent_correction_id, комментарий обязателен, status DRAFT/APPLIED/REVOKED).
• Гудвилл — превышение финансовых вложений ГО в ДО (Дт 58.01) над долей ГО в капитале ДО (стр. 1310 (+1350?) × доля владения). Положительный — отдельная строка в разделе I КФО. → goodwill, kfo_result_line.line_code = 'GOODWILL'.
• Доля владения — % участия ГО в уставном капитале ДО. Источника в первичке нет — ручной ввод. → goodwill.ownership_share.
• ЧА — чистые активы (≈ стр. 1300), ВБ — валюта баланса (стр. 1600/1700), выручка (2110), прибыль от продаж (2200) — базы для порогов расхождений. → kfo_result.net_assets/balance_total/revenue/sales_profit.
• Сводная ОСВ — все строки-контрагенты всех ОСВ периметра одним списком с признаком контрагента (ГСК / ГК / Внешний); суммы не агрегируются. → вычисляется; алгоритм §3.
• Признак контрагента — ГСК (в периметре версии) / ГК (в той же ГК, но не в периметре) / Внешний (иное или не сопоставлен). → функция от osv_entry.counterparty_id и consolidation_member.
• УОБ — уполномоченный орган банка — принимает решение по КФО; его номер и дата заносятся при верификации. → consolidation_version.uob_decision_no/date.
• Подтверждение КФО клиента — клиент принёс свою консолидацию; банк строит свою и сравнивает построчно. → scenario = CONFIRM, client_kfo_line.
• Верификация — финальное подтверждение в ГО; версия становится read-only, пишется срез ЕХ.
• ЕХ / ЕХФД — Единое хранилище финансовых данных — реестр верифицированных срезов: одна ГСК × одна отчётная дата × версия. → ex_snapshot (ACTUAL/ARCHIVE), ex_snapshot_member, ex_snapshot_item (document_id для первички, payload jsonb для всего производного).

Процесс, роли, интеграции

• КА РФ / КА ГО — кредитный аналитик филиала / головного офиса; РКА — руководитель КА; КМ — клиентский менеджер; Куратор (КП ГО) — ведёт ГК и закрепление за филиалами; Эксперт — только чтение; Администратор — пользователи, роли, справочники. → role.code (seed), права — permission × role_permission.
• Маршрут согласования — зависит от инициатора: КА РФ → РКА РФ → КА ГО → Верифицирован; КА ГО → (РКА ГО) → Верифицирован. → consolidation_status + consolidation_status_history.
• Взять в работу / перехват — блокировка версии одним аналитиком. → consolidation_lock.
• РАИСА — банковский SSO; выдаёт JWT с email. → app_user.external_id/email.
• ИС Сканирование (Content AI) — внешняя OCR-система: кладём PDF в «горячую папку», забираем JSON с data_ocr[], table_structure.rows[].cells[] и confidence. → адаптер scan-gateway, recognition_pipeline = image.
• Табличный парсер — наш сервис разбора XLS/XLSX/XLSB ОСВ. → tabular-parser, recognition_pipeline = tabular.
• ЕЦП CRM — источник ГК/ЮЛ. → company_group.crm_id, legal_entity.crm_id; импорт — audit_event(DIRECTORY_IMPORT).
• 276-ОД — форма заключения подразделения анализа (отчёт для кредитного комитета). В ТЗ упомянута, не описана; эталон — листы «ЗАКЛ_*» в Анализ *.xlsx. Вне scope первых срезов.
• Чек-лист документов — матрица «компания × обязательный документ» со статусами. → required_document_rule × consolidation_member − document(status = CONFIRMED).