Реестр решений¶

В этом документе будут фиксироваться ключевые решения по реализации отчетов и дашбордов.

Текущие решения (на этапе старта)¶

Формат ведения знаний: OKF (Open Knowledge Format).
Уровень детализации дашбордов: До уровня «модель-цвет». Размерная сетка исключается для упрощения аналитики (задачи 1.2, 4.4).
Интерфейс «Что-если» калькулятора (задача 3.6): Должен поддерживать три колонки: «База», «Новый сценарий», «Отклонение (Дельта)».
Отчётность директоров (задача 3.7): Реализация в Excel/Google Таблицах для возможности гибкого моделирования факта продаж.

2026-06-26 | Дмитрий + Claude (Opus 4.8)¶

Декомпозиция блоков: принята версия по зависимостям данных с новым Блоком 0 (единый слой данных). Причина: все отчёты опираются на общие мастер-данные (ключ «модель-цвет», цены/скидки/себес), которые Глеб «размазал» по задачам 2.1/3.1/3.2.
Единый справочник цен/скидок/себестоимости: один источник (DRY), остальные файлы ссылаются. Глеб правит в одном месте.
Формат Excel: отдельные файлы по блокам + общий 00_Справочники.xlsx; цены считаются формулами из РРЦ и параметров каналов (вручную не вводятся).
Старт: Блок 0 (00_Справочники.xlsx) — создан, выложен на Drive.
4-й канал и B2B-скидка: требуют уточнения у Глеба.
Единый файл задач: 04_Блоки_задач объединён в 03_Задачи (статус-таблица + детали) — статусы ведутся в одном месте.
Реестр классификаторов: константы/справочники вынесены в 07_Справочники_классификаторы (единый источник, выгружается в рабочие Excel). Значения в тексте не дублируем — ссылаемся.

2026-06-26 (II) | Итоговый концепт хранения данных¶

Единый источник данных — Google Sheets «AGT — Справочники и классификаторы» (заменяет пункт «Формат Excel» выше). Claude читает/пишет через сервис-аккаунт (gspread); .xlsx оставлен как исходник/резерв.
Доступ к Apps Script настроен через clasp (OAuth) — для будущих скриптов синхронизации.
Дашборды: созданы примеры-прототипы (Локатор, Остатки по складам, План/Факт, Маржа-калькулятор) с формулами и условным форматированием. Данные демо — заменяются выгрузкой из 1С.

2026-06-29 | Встреча: Глеб Яковлев + Антон Мешков + Дмитрий Пожарский¶

📅 Источник: встреча 29.06.2026, файл docs/Copy of 260629-1_29_ijunja_26_Gleb_Anton_fin_otchety.txt

Приоритет на 2 недели (до отпуска Дмитрия)¶

Задачи в работу: 1.2 (Локатор), 1.5 (Себестоимость остатков / Финансовый сток), 2.3 (Планировщик продаж).
Порядок: 1.2 → 1.5 → 2.3.
Формат: прототип в Google Sheets (не финальная реализация) → показ → обратная связь → тюнинг.

Определение «свободного стока» (задачи 1.2, 1.5) — согласовано¶

Сущность	Что берём	Источник
Свободный сток	«Доступно» (наличие за вычетом всех резервов)	1С, только склад Шушары + Кировский
Транзит FBO	Расходные ордера/заказы МП в статусе не отгружен (все МП кроме статуса «Отгружено»)	1С заказы клиента или расходные ордера
FBO (склады МП)	Все статусы остатков МП кроме «Заявки на поставку» (скачиваются по API)	API маркетплейсов
Резерв B2B + Дилеры	Заказы клиента в статусе Резерв по подразделениям B2B и Дилеры	1С заказы клиента
Ремонт	Склад «Ожидание ремонта УТК Шушары» (старый — не используем)	1С
Брак	Склад «Брак Шушары» (возврат от покупателей) + «УТК Шушары» (после УТК). Склады Киевская, Кодняковская, Егорова — удалить	1С

Важно: «Заявки на поставку» МП (товар, который МП ещё не принял как своё) — не берём, они не скачиваются по API. Это наше пожелание поставить, а не факт.

Серая зона (принято): Товар от ворот склада до момента, когда МП начал принимать — нет источника данных, не критично. Лаг 1–2 недели, на общую картину не влияет.

Статус «Отгружено» в 1С: должен ставиться в последний момент, когда товар физически покинул ворота склада (а не при создании заказа). Нужно уточнить/подкрутить регламент.

Заявки на поставку МП — не скачиваются по API, ручная вставка не нужна (раз в месяц достаточно, можно описать Недашковской).

Логика сущностей в 1С: заказ клиента vs расходный ордер — согласовано¶

Для МП (FBO/FBS): заказ клиента сразу создаётся в статусе «Отгрузить» (резерв не ставится). Используем заказ клиента в статусе «Отгрузить».
Для B2B и Дилеров: товар ставится в статус «Резерв» на заказ клиента. Используем заказ клиента в статусе «Резерв».
Итог: одна сущность — заказ клиента, разбиваем по каналам через подразделение/статус.

Дашборд финансового менеджера (задача 1.5) — уточнён состав¶

Добавить к задаче 1.2: - Резерв B2B и Дилеры — отдельные столбцы (в задаче 1.2 оставить только свободный сток без резервов). - Разбивка брак/ремонт по конкретным складам (см. таблицу выше). - Исторические данные: не делаем сейчас (сложно по МП и резервам; договорились начинать накапливать только после утверждения отчёта).

Планировщик продаж (задача 2.3) — упрощённый вариант для первого этапа¶

Основная идея: статистика продаж за прошлые 12 мес × мультипликатор = прогноз на 12 мес вперёд.
Детализация: модель-цвет (без размеров), по каждому каналу отдельная таблица (Беляев, Галягин, и др.), сводная таблица суммирует все каналы.
Мультипликатор: один коэффициент на каждый месяц (12 коэффициентов на 12 месяцев вперёд, проставляются вручную). Коэффициент умножает продажи аналогичного месяца прошлого года.
Ценовая часть (информативно): РРЦ текущая + коэффициент скидки канала — только для контроля «бьём ли план в деньгах». Вся цена — информативное поле, штуки — рабочее.
Итог: сумма штуков за 12 мес + ориентировочная сумма в рублях за год (без помесячной суммы — только штуки по месяцам).
Совместная работа: каждый директор канала работает в своей таблице, Глеб видит сводник. Механизм: доступы Google Sheets по вкладкам.
ABC-сортировка: по выручке за последний год, по убыванию. Группировка по категориям — второй волной (нужна классификация от Глеба/Алексея).
После первого этапа (после отпуска): добавить РРЦ с возможностью изменения + влияние на маржу.

Маржинальный калькулятор (задачи 3.6 / 3.7) — концепт уточнён¶

Единая сущность РРЦ: отдельная таблица-справочник (Баталов/Глеб вносят РРЦ по позициям на каждый месяц). Эта таблица тянется во все отчёты.
Себестоимость плановая: фиксируется на период (6–12 мес) Баталовым. Отдельная таблица аналогичной структуры (артикул × месяц). Стартово заливается текущая расчётная себестоимость.
Что меняют директора канала: только РРЦ (в своей таблице канала). Штуки — зафиксированы после планирования (задача 2.3).
Что видят директора: как изменение РРЦ влияет на выручку и маржу их канала. Дельта (абсолютная) прибыли — основной показатель.
Сводник: только у Глеба и Баталова. Отражает суммарный эффект по компании.
Мотивация продаж: привязывать директоров к марже с фиксированной себестоимостью (они не влияют на неё). Сейчас — только для понимания, мотивация — следующий шаг.

Формат прототипирования — принято¶

Прототипы в Google Sheets, без автоматических расчётов на первом этапе.
Показ → обратная связь → итерация. Визуал — критически важен (удобство работы первично).
Горизонтальное расположение данных (скрываемые группы столбцов) — предпочтительнее переключения вкладок.

2026-07-03 | Дмитрий + Claude (Sonnet 5) — старт реализации задачи 2.3 (Планировщик продаж)¶

Файл: новый Google Sheets «Калькулятор маржинальности Brodeks» (бывш. «AGT планирование продаж V1») (1yTZW_8iWFMMsk3JzgIK2CzvawHS2kr-Wov_vxMCrIqs), отдельно от справочной таблицы «AGT — Справочники и классификаторы».
Источники данных — через pgapi напрямую (SQL/файлы), без ручного экспорта:
История продаж: SQL к таблице prodazhi_po_kanalam_only_1c_mt (обновляется ежедневно по cron на офисном сервере) — предпочтительнее ручных xlsx-выгрузок, где это возможно.
Прайс-лист и себестоимость: файлы Прайс-лист XLSX.xlsx и Себестоимость товаров организаций по брендам - июль 25-дек 25 (XLSX).xlsx — та же логика скачивания, что и в проекте «Отчёт по сравнению остатков склада и организации» (pgapiDownloadFile_).
Остатки — сознательно исключены из этого файла: остатки относятся к отдельной задаче (1.2/1.5, Локатор), а не к планировщику продаж.
Каналы этого этапа: В2В, Дилеры Brodeks, Розница+Интернет-магазин (объединены в один лист). Ozon и Wildberries — не включены (решение пользователя 03.07.2026, отложено на отдельный этап/проект).
Себестоимость — расчёт с НДС: добавлен отдельный столбец «с НДС 22%» (ставка фиксированная, копейки отбрасываются — floor, не округление). Причина: обеим версиям (без/с НДС) нужно быть под рукой для разных расчётов маржи.
Архитектура обновления данных (важное решение, определяет всю дальнейшую разработку):
Коэффициент прогноза — один на месяц (в строке шапки листа), не персональный на артикул. Это ключевое архитектурное решение: оно делает список товаров (строки) независимым от плана — можно менять/пересортировывать состав строк, не теряя введённые коэффициенты.
Обновление продаж — только upsert (не полная перезапись листа), чтобы не терять коэффициенты и не ломать формулы плана.
Пересортировка по ABC и «фиксация плана» — сознательно не автоматические, отдельные явные действия по команде.
«Фиксация плана» = дублирование листа + перевод формул блока ПЛАН в статические значения (просто дублирование не защищает от изменения формул, ссылающихся на другой лист — прайс-лист).
Пересчёт плана при правке коэффициента — не требует отдельной кнопки, обычный механизм пересчёта формул Google Sheets.
Google Sheets: подтверждён лимит 10 млн ячеек на файл (не на лист) — при текущем объёме (~4,6 млн ячеек: продажи 208К×13, три листа каналов по ~6000×100) запас достаточный.
Следующий шаг (согласовано): Apps Script + лист «Панель» (по аналогии с проектами «FBO Маркетплейсы» / «Отчёт по сравнению остатков») — кнопки для обновления тех. листов, ABC-пересортировки, фиксации плана.

2026-07-03 (II) | Дмитрий + Антон — согласование логики текущих остатков (задачи 1.2/1.5)¶

📅 Источник: Согласование_остатки_03-07-2026_Антон

Ограничение точности: точный остаток («склад минус отгружается минус резерв») снимается только на текущий момент — статусы резерв/отгружается не восстанавливаются на произвольную историческую дату.
Формула остатка 1С: Остаток на складе − товар отгружается − товар в резерве = доступный остаток. По списку складов (см. ниже).
Лого-подрядчики: товары на логотипировании у переработчиков — данные сейчас не собираются, требуется отдельная проработка сбора (новый открытый вопрос).
МП (Ozon + WB, 4 кабинета): остаток на МП без учёта товара в заявках — товар в пути до МП уже учтён в отчёте МП, столбец «Товары в пути». Подтверждает решение 29.06 (заявки на поставку не берём).
Расходные ордера до статуса «Отгружено»: отдельно не анализируем — дублировало бы то, что уже учтено в отчёте МП. Упрощает архитектуру транзита FBO по сравнению с планом от 29.06 (там предполагался отдельный расчёт по заказам клиента в статусе «Отгрузить»).
Список складов «текущих остатков» (Антон подтвердил): Рекламация (Шушары), Ожидание ремонта / Поступление товара / Сборка-проведение ОТК / Сборка-проведение ремонта / Брак (все — склад ОТК Шушары), Центральный склад СПб Шушары (О) — плюс склад магазина Егорова, шоурум Мск, товародвижение Егорова, будущий склад «Bro Егорова» (уточняется).
⚠️ Не устранённое расхождение с решением 29.06.2026: тогда склады Егорова договорились удалить из брака; сегодня Антон добавляет склады Егорова обратно — уже в контур «текущих остатков» (не «брак»), возможно, это разные вещи (разные склады с похожим названием) — требует уточнения, не разрешал самостоятельно. Также склад «Кировский» из 29.06 в новом списке не упомянут — уточнить, входит ли он в «Центральный склад СПб Шушары» или это отдельная позиция, которая выпала.

2026-07-03 (III) | Дмитрий + Claude — план архитектуры загрузки данных (не реализовано, план на будущее)¶

Проблема: сырой лист prodazhi_po_kanalam_only_1c_mt (208К строк, 2,7 млн ячеек, 65% файла) никем не используется вживую — данные агрегируются один раз внешним скриптом и заливаются как статичные значения в рабочие листы. Хранить сырой дамп внутри основного файла — лишний вес без пользы.
Решение (план, не реализовано):
При обновлении данных агрегация делается на стороне SQL/Python при выгрузке через pgapi (GROUP BY артикул+месяц+канал в самом запросе) — в основной файл сразу пишется готовый агрегат по месяцам, без сырого построчного дампа.
Отдельно заводится дополнительный Google-файл — приёмник для сырых данных (полная история продаж построчно), не для повседневной работы, а на случай, если нужно свериться с первоисточником.
В основном файле — лист «Панель» (тот же, что уже согласован 26.06 как следующий шаг для Apps Script с кнопками обновления/ABC-пересортировки/фиксации плана) получает:
- Ссылку на этот дополнительный Google-файл с сырыми данными.
- Кнопку «Обновить» — скрипт скачивает свежую сырую выгрузку в тот отдельный файл (не в основной).
Работа с сырыми данными — по требованию: обычно они не нужны, но если нужно посмотреть на первоисточник — переход по ссылке с «Панели» в отдельный файл.
Причина такой схемы: пользователь не хочет разводить активно поддерживаемые параллельные файлы («сложнее обслуживание»), но и полностью терять доступ к сырым данным тоже не хочет — раздельный файл-приёмник, обновляемый по кнопке и не требующий отдельного внимания, закрывает оба требования.
Статус: согласовано как план, реализация отложена — делается вместе с остальной частью задачи «Apps Script + лист Панель» (см. 03_Задачи.md, задача 2.3).
Приоритет — низкий, не срочно. На момент решения занято 4,18 млн из 10 млн ячеек лимита (41,8%) — места достаточно, отказ от сырого технического листа не является блокером и делается не ради экономии места сейчас, а как более чистая архитектура на будущее.

Дополнение к плану — выгрузка в Excel для архива/бэкапа (тоже план, не реализовано)¶

На той же «Панели» — кнопки экспорта в Excel-файл (для архива/бэкапа, не для повседневной работы):
«Выгрузить лист» — экспорт текущего/конкретного листа.
«Выгрузить всё» — экспорт всей книги (все листы) одним файлом.
Реализация — вместе с остальными кнопками «Панели» (обновление данных, ABC-пересортировка, фиксация плана, ссылка на файл сырых данных).

2026-07-06 (II) | Глеб + РОПы (Константин, Женя, Алексей Баталов) — обратная связь по первой версии калькулятора маржинальности¶

📅 Источник: сырой транскрипт, саммари — Саммари_встречи_06-07-2026. Закрывает задачу 3.9.

Ключевое архитектурное решение (важно для всей дальнейшей работы): калькулятор маржинальности — это инструмент моделирования сценариев («игра в маржинальность», творческая песочница), а НЕ источник данных для плана производства. Ручные корректировки (РРЦ вручную, Шт вручную) в этом инструменте никогда не должны напрямую передаваться в план производства — если кто-то смоделировал 2000 штук вместо 200, это не должно «утечь» дальше. Утверждение планов — отдельная, независимая сущность/отчёт (следующий шаг после калькулятора), с отдельной проверкой перед выгрузкой в ПП. Автоматическая выгрузка утверждённых (проверенных) штук в план производства — задумана как будущий шаг, не сейчас.
Подтверждена корректность уже реализованной логики (без изменений от нас, только фидбек «работает верно»):
Приоритет ручного ввода: «Шт вручную» на конкретной позиции важнее общего коэффициента месяца.
Галочки периода — учёт/исключение месяцев в «Итого» работает как задумано.
«Дельта прибыли» от ручной РРЦ — работает; дополнительно попросили добавить рядом «Дельту выручки» (сейчас есть только дельта прибыли).
Методология «Итого выручка»: план строится на основе средней исторической скидки/цены фактической реализации, не текущей РРЦ на момент планирования — соответствует уже реализованной формуле (План = Факт того же месяца прошлого года × коэффициент).
Категории по линейкам (не по размерам) — подход подтверждён верным; классификация — по-прежнему задача Алексея Баталова.
Разбивка МП на Ozon/Wildberries — обсуждали как желаемую независимо, до того как это было реализовано технически в тот же день 06.07.2026 — направление совпало.
Статус проекта в общей картине: калькулятор — это «отчёт №1» из будущей системы Пожарского на 9 взаимосвязанных отчётов (план производства, платежи, факт, каналы продаж). Не отдельный проект, а быстрый рабочий прототип, сделанный параллельно, пока официальная система Пожарского готовится (обещаны прототипы не раньше сентября).
Скоуп сейчас — только бренд Brodeks. Остальные бренды можно добавить быстро при необходимости, не сейчас.
Ближайшие шаги: сегодня вечером — обратная связь от РОПов (что добавить/поменять) → повторная встреча впятером, финализация → передача Пожарскому на доработку дилерского канала как эталона → выкатка на остальные каналы.

2026-07-06 (III) | Дмитрий + Claude — найдено, где в 1С КА хранится цена и история скидок (задача 0.6)¶

📅 По прямому запросу Дмитрия: «найти где в 1С КА хранится цена и смена цен», чтобы посчитать, сколько компания недополучает выручки из-за скидок. Подробный разбор — 03_Задачи, задача 0.6; доступ к базе — 07_Справочники_классификаторы, раздел 7.

Отдельного регистра истории цен в реплике 1С (Postgres через pgapi) нет — проверено полным перебором ~400 таблиц.
Решение: история цен и скидок реконструируется из строк документов продаж — таблица RealizatsiyaTovarovUslugTovary_PROD (121К+ строк, с 01.07.2025) уже содержит по каждой строке продажи и цену (TSena), и тип прайс-листа (VidTSeny), и ручную скидку (SummaRuchnoySkidki/ProtsentRuchnoySkidki), и дату (SsylkaData), и канал (SsylkaPodrazdelenie) — отдельный регистр не нужен, эта таблица и есть источник истины.
Важная находка, уточняющая модель каналов: у Дилеров реально минимум 3 разных прайс-листа («Дилер-33», «Дилер-25», «Дилер-15») — наш единый коэффициент 0.67 в «Дилеры Brodeks v2» является упрощением (усреднённой ставкой), а не единственной реальной скидкой. У В2В — в основном полная РРЦ («Цена продажи») + переменная ручная скидка сверху (в наблюдаемых сделках 0–11,6%).
Методология расчёта «недополученной выручки» — уточнена и упрощена (06.07.2026, поправка Дмитрия): первоначальная идея (2 шага: РРЦ минус цена по прайс-листу, плюс отдельно ручная скидка) признана ненадёжной — у пользователей 1С есть право вписать цену вручную (не по прайс-листу), и в этом случае невозможно надёжно разделить «отклонение от прайс-листа» и «скидку от вручную вписанной цены». Решение: сравнивать напрямую факт. выручку (Summa) с БАЗОВОЙ РРЦ на дату документа, без промежуточных шагов через TSena/VidTSeny/поля скидок — единственное сравнение, устойчивое к любому способу формирования итоговой цены (ручной ввод, прайс-лист, скидка, комбинация). Недополучено по строке = РРЦ_на_дату × Kolichestvo − Summa.
Остаётся техническая задача: знать РРЦ («Цена продажи») на конкретную дату — восстанавливается как временной ряд по строкам RealizatsiyaTovarovUslugTovary_PROD/ZakazKlientaTovary_PROD с VidTSeny='Цена продажи' (метод проверен, РРЦ реально меняется и это видно в документах).
Статус: методология определена, сама реализация (скрипт реконструкции временного ряда РРЦ + расчёт по всем продажам) — следующий шаг, не начат.

2026-07-08 | Дмитрий + Claude (Sonnet 5, dp-office-server) — найден готовый регистр истории РРЦ, доступ к БД/Sheets настроен¶

Уточняет и частично отменяет вывод от 06.07.2026 («отдельного регистра истории цен в реплике 1С нет»).

Найден периодический регистр цен TSenyNomenklatury25_PROD (та же БД bigquery@10.20.20.81) — колонки Nomenklatura, Period (дата действия цены), VidTSeny (16 типов цен, включая 'Цена продажи' = РРЦ), TSena. 2 992 900 строк. Предыдущий вывод 06.07.2026 («регистра нет, проверено перебором ~400 таблиц») не подтвердился — таблица есть, реконструкция РРЦ по строкам продаж (запланированная 06.07.2026) больше не нужна.
Методология подтверждена на реальном документе: join TSenyNomenklatury25_PROD (последний Period ≤ SsylkaData, VidTSeny='Цена продажи') с RealizatsiyaTovarovUslugTovary_PROD — на примере AGKA-011639 цена по прайсу 11 600 ₽ vs факт 5 800 ₽ = скидка 50%.
Создан переиспользуемый скрипт /!VDS-DP-Office/scripts/discount_report.py — принимает Ssylka документа реализации, выводит построчное сравнение факт/РРЦ + итоги.
Написана методика Методика_расчёта_скидки_от_РРЦ — расчёт % скидки по (артикул×канал×месяц), итоговый столбец за период, агрегат по бренду+каналу (место вывода агрегата — открытый вопрос, см. документ).
Архитектурная рекомендация (согласована с пользователем): РРЦ-на-дату считать один раз на уровне SQL-источника (обогатить prodazhi_po_kanalam_only_1c_mt или завести вспомогательную вкладку API_скидка_от_РРЦ), а не дублировать джойн в каждом из канальных скриптов (20_b2b_v2.py и т.д.).
Настроен доступ к Google Sheets с dp-office-server (пользователь pozharskiy, не root): смонтирован gdrive: (rclone, scope=drive, полный диск), скачан ключ сервис-аккаунта claude-sheets@my-project-93453-01-04-26.iam.gserviceaccount.com в /home/pozharskiy/.config/gspread/service_account.json, gspread установлен в отдельный venv /home/pozharskiy/.venvs/gspread (pip напрямую заблокирован PEP 668). Проверено: открывается «Калькулятор маржинальности Brodeks», доступно 8 таблиц (не весь диск — сервис-аккаунт видит только явно расшаренные файлы).
Наведён порядок в docs/: черновые «видения реализации» от MiniMax/Mimo/DeepSeek-v4/GLM-5.2/Kimi/Qwen (17 файлов) перенесены в docs/Архив_видений_реализации_ИИ/; файлы встреч (саммари/разборы/транскрипты/согласование остатков, 6 файлов) — в docs/Встречи/; относительные ../-ссылки внутри перенесённых файлов исправлены под новую глубину. Один легаси-файл Дашборд. Новая версия...xlsx (лежал в !Архив/ без MD-карточки) — перенесён в docs/, зарегистрирован в HEAVY_FILES.md.
Новое правило в 01_SYSTEM_GUIDE.md (§3, пункт 5): чужие журналы диалогов (5X_<ИИ>.md, История общения/**) не читать без явного запроса пользователя.
Согласован план (не реализовано): лист «Дилеры Brodeks v3» — копия v2 через gspread.duplicate_sheet (v2 не трогается), новая вкладка-источник API_скидка_от_РРЦ (агрегаты SQL по артикул×канал×месяц), итоговый столбец скидки на v3 через SUMIFS. Открыто: куда класть агрегат по бренду/каналу целиком (ячейка шапки рядом с CC2 — предложение Claude, vs строка A001 — предложение Дмитрия), нужна ли помесячная разбивка на самом листе.

2026-07-08 (II) | Дмитрий + Claude (Sonnet 5, VDS USA) — НДС в расчёте прибыли + расшифровка листа-прототипа v3 (задачи 0.6/0.7)¶

📅 Продолжение сессии этого же дня (запись выше — dp-office). Полный ход рассуждений — 03_Задачи, задачи 0.6 и 0.7. Не согласовано с Глебом — это решения Дмитрия как ведущего проект, статус задач остаётся 🟡.

Проблема: для расчёта реальной прибыли нужна выручка без НДС, но считать все продажи по флэт-22% неверно — часть реализаций идёт по 20% (старая ставка, до перехода), 0%/«Без НДС» (дилеры-нерезиденты).
Решение 1 — источник НДС по строке найден, ETL менять не нужно: таблица RealizatsiyaTovarovUslugTovary_PROD (та же, что для скидки от РРЦ) уже содержит StavkaNDS/SummaNDS/SummaSNDS построчно, доступна напрямую через pgapi. Снимает опасение параллельной сессии dp-office о необходимости доработки ETL-выгрузки prodazhi_po_kanalam_only_1c_mt.
Решение 2 — механизм 0%/«Без НДС» подтверждён: это не шум, а конкретные контрагенты-нерезиденты (29 партнёров, дилеры Беларуси/Казахстана — экспорт СНГ), совпадает с находкой «Дилер-СНГ» из задачи 0.6.
Решение 3 — финальная методика расчёта k (эффективная доля НДС для прогноза): вместо усреднения по ограниченному окну — универсальная построчная аппроксимация по всей истории: для строк со стандартной ставкой (20% или 22%) выручка без НДС = Summa / 1.22 (аппроксимация «как если бы уже действовала текущая ставка 22%», валовая цена принимается неизменной); для льготной ставки (0%/«Без НДС») — Summa без изменений (реальное освобождение, не трогаем). Формула по каналу/артикулу: k = 0.1803 × (1 − доля выручки по льготной ставке). Даёт k за всю историю (не только последние месяцы) — решает проблему малой выборки для непопулярных артикулов. Проверено: Дилеры Brodeks k=0.1625, В2В k=0.1797, Розница/Интернет-магазин k=0.1803 (=22/122, льготных продаж почти нет).
Почему именно так: альтернатива (сохранять чистую цену продавца, пересчитывать вверх валовую) даёт другую, менее естественную модель — выбрана аппроксимация с фиксированной валовой ценой как более простое и защитимое допущение для ретроспективной нормализации.
Найден и расшифрован лист-прототип «Обсуждение (копия)» (книга «Калькулятор маржинальности Brodeks», id листа 1115921388) — черновая, более развёрнутая структура для v3 (не текстовое обсуждение, несмотря на название): столбец CB — % скидки от РРЦ (агрегат по каналу в строке 2, по артикулу за всю историю в строках товаров); новый столбец CC (добавлен Дмитрием в процессе обсуждения) — эмпирическая ставка НДС k, тот же принцип (канал в CC2, артикул в остальных строках с откатом на CC2 при малом объёме данных); CD–CI — РРЦ/два сценария цены (коэфф. №1 на базовой РРЦ, коэфф. №2 на ручной новой РРЦ, приоритет — коэфф.№2, если задан, иначе коэфф.№1, сырая РРЦ нигде не используется напрямую)/себестоимость; помесячный план — предложено расширить с 4 до 5 подколонок (Шт/Шт вручную/Сумма выручки с НДС/Выручка без НДС [новая, = Сумма выручки × (1−k)]/Прибыль, пересчитанная на однородных величинах без НДС). Итого-блок (GF–GQ, 12 колонок) уже содержал пустые заголовки-заглушки под «без НДС» — новая логика их заполняет.
План реализации (согласован, не начат): «Дилеры Brodeks v3» = копия v2 (gspread.duplicate_sheet, v2 не трогается), старт с одного канала (Дилеры). Новый вспомогательный лист API_скидка_НДС_от_РРЦ (агрегаты SQL артикул×канал: % скидки → CB, k → CC), считается Python-скриптом через pgapi (не живая формула — источник в Postgres), CB/CC на v3 подтягивают через VLOOKUP. Остальные источники (прайс-лист, себестоимость, история продаж, ABC) уже есть в книге, переиспользуются из v2 без изменений.
Найдена попутная нестыковка на листе-прототипе: колонки рентабельности (GN/GP) заполнены по отдельным артикулам без underlying-прибыли (GM/GO пустые) — считались какой-то старой формулой в обход. Будет исправлено при реализации v3 честной цепочкой формул.
Следующий шаг после реализации v3 (по указанию Дмитрия): переписать пользовательскую инструкцию (лист «Инструкция» в этой же книге) под новую логику.

2026-07-08 (III) | Дмитрий + Claude (Sonnet 5, VDS USA) — пилот CB2/CC2 на канале «Дилеры», join только по артикулу, инфраструктура ускорения¶

Методика НДС финализирована (упрощена от окна к аппроксимации по всей истории): строки со стандартной ставкой (20%/22%, неважно какая исторически) → выручка без НДС = Summa/1.22; льготная ставка (0%/«Без НДС») → Summa без изменений. Свёрнуто в k = 0.1803 × (1 − доля льготной выручки). Подробности и обоснование — 03_Задачи, задача 0.7.
Посчитано и записано на пилотном листе «Обсуждение (копия)»: CB2 = 34,05% (скидка от РРЦ), CC2 = 16,25% (эмпирическая доля НДС) — оба на уровне канала «Дилеры Brodeks» целиком, вся история. Решили НЕ делать артикульный разрез для первой версии — канальный уровень проще и уже провалидирован (см. задача 0.7, «Очерёдность»).
Важная методологическая поправка (Дмитрий): join истории цен с продажами по названию (Nomenklatura) ненадёжен — названия в 1С нестабильны, переименовываются. Проверено на реальных данных: 6,3% несовпадений при джойне по названию через справочник Nomenklatura_PROD, из них 137 строк — настоящие переименованные брендовые товары (не мусор). Решение: join только по артикулу. Дмитрий добавил колонку NomenklaturaArtikul напрямую в реплику TSenyNomenklatury25_PROD и перезалил таблицу целиком.
Инфраструктура ускорения (совместно с Дмитрием): LATERAL JOIN по датам без индекса не укладывался в таймаут pgapi (39К строк канала). Создан scripts/25_rrc_price_history_matview.sql (индекс + материализованное представление mv_rrc_price_history, теперь по артикулу). pgapi-ключ — только SELECT, DDL им не выполнить (проверено), поэтому представление создавал Дмитрий сам напрямую в БД (DBeaver).
Обновление представления — через уже существующий воркфлоу n8n на офисном VDS («Обновление мат. представлений в 4 утра 03.26», id oE68bEtGB9KgddMW, каждые 2 часа), а не отдельным cron-скриптом — Дмитрий дописал REFRESH MATERIALIZED VIEW mv_rrc_price_history; в конец существующего списка REFRESH-команд, тестирует. Отдельный scripts/26_refresh_mv_rrc_price_history.sh удалён как избыточный.
Статус: таблица TSenyNomenklatury25_PROD (перезалив с артикулом) на момент записи ещё догружается — представление создано по новой структуре и подтверждено рабочим, но не отражает полный объём данных. Следующий шаг — дождаться полной загрузки, REFRESH, пересчитать CB2/CC2 через SQL и сверить с текущими цифрами (34,05%/16,25%), затем переходить к копированию v2 → v3.

2026-07-08 (IV) | Дмитрий + Claude (Sonnet 5, VDS USA) — v3 достроен, инструкция переписана, расчёт по всем каналам¶

v3 достроен целиком на канале «Дилеры Brodeks»: два ценовых сценария (коэфф.№1 авто / коэфф.№2 ручной, логика перенесена с прототипа «Обсуждение (копия)», но с исправлением найденных там ошибок — защита от пустого значения, верный индекс VLOOKUP для себестоимости без НДС), помесячный расчёт выручки/прибыли без НДС, 12-колоночный Итого-блок (по образцу прототипа, но с порядком, сгруппированным по сценарию — предложение Claude, принято). Сверка: рентабельность коэфф.№2 (факт) 51,6% совпала с независимой референсной цифрой из пилота 03.07.2026.
Лист «Инструкция» переписан с нуля — старая версия сохранена как отдельная вкладка-архив + PDF-снимок на GDrive, новая инструкция обобщённая (не привязана к конкретному листу-каналу), тоже сохранена в PDF. Оба PDF оформлены по правилам тяжёлых файлов (docs/HEAVY_FILES.md).
Методологическая ошибка найдена и исправлена в расчёте скидки от РРЦ: строки без найденной цены на дату (15–25% строк на разных каналах) исключались только из знаменателя, не из числителя — давало ложную отрицательную скидку почти на всех каналах кроме Дилеров. После исправления: реальная скидка есть только у Дилеров (34,14%), остальные каналы торгуют практически по РРЦ. Подробности и итоговая таблица по всем каналам — Методика_расчёта_скидки_от_РРЦ.
CB2/CC2 в v3 обновлены под пересчитанные цифры (артикульный join точнее названия); к CC2 добавлено примечание (не изменение формулы) с альтернативным представлением ставки НДС «в привычном виде» (19,40% вместо 16,25%) — по явному запросу пользователя, изменение самой формулы обсуждено и отложено (потребовало бы правки везде, где используется $CC$2).
Не сделано: артикульный разрез CB/CC (сейчас только канальный уровень), репликация структуры v3 на остальные каналы (В2В/Розница/МП пока на архитектуре v2), подтверждённый REFRESH mv_rrc_price_history (представление на конец сессии ещё не обновилось, хотя воркфлоу n8n активен).