Перейти к содержанию

Задачи

Единый файл: вверху — статус по блокам (оркестратор), ниже — детали задач.

Нумерация: Блок.Г# — где Г# = номер задачи из классификации Глеба (Вводные_данные_Глеб). Пример: 1.2 = Блок 1, Задача Глеба №2 (Локатор). Мгновенная трассируемость без доп. колонок. Блок 0 — сервисный фундамент, у Глеба аналога нет → нумерация 0.1–0.5.

Зависимости блоков: 0 → (1, 2) → 3 → 4 → 5. Логика связей — 05_Логика_проекта.

📊 Статус (единственное место ведения)

Меняем статус только здесь. В деталях ниже статусов нет — только содержание.

Блок Задача Г# Статус
0. Единый слой данных (фундамент) 0.1 Справочник «модель-цвет» — 🟡
0.2 История продаж 12 мес × 4 канала — 🟡
0.3 Остатки по складам/статусам — ⬜
0.4 Себестоимость (ср. + замороженная) — 🟡
0.5 Справочник цен/скидок по каналам — 🟡
0.6 История изменения РРЦ по времени — 🟡
0.7 НДС в расчёте выручки/прибыли — 🟡
1. Остатки и оборачиваемость 1.2 Локатор оверсток/андерсток Г2 🟡
1.5 Себестоимость остатков по складам Г5 🟡
2. Планирование продаж 2.3 Планировщик продаж внутри канала Г3 🟡
3. Маржинальность и сценарии 3.6 Маржинальный калькулятор (what-if) Г6 ⬜
3.7 Планирование маржинальной прибыли Г7 ⬜
3.8 Встроенный расчёт прибыли в плане (пилот на «Дилеры») — ✅
3.9 Обратная связь от Глеба по пилоту «Дилеры» — ✅
3.10 Точечные доработки по итогам встречи 06.07 — ⬜
3.11 Отдельная сущность «Подтверждение планов» — ⬜
4. Контроль план/факт 4.4 Аналитика план/факт продаж Г4 ⬜
5. Интеграция платежей (низкий приор.) 5.1 ПП ↔ график платежей Г1 ⬜

Легенда: 🟡 в работе · ⬜ не начато · ✅ готово.

Детали задач

(только содержание; актуальный статус — в таблице выше)

Блок 0: Единый слой данных (фундамент)

Базовые мастер-данные, на которые опираются все отчёты. Реализация — в живой таблице (см. 07_Справочники_классификаторы).

  • 0.1 Справочник «модель-цвет» — канонический ключ (модель, цвет, категория, бренд, РРЦ).
  • 0.2 История продаж 12 мес × 4 канала (шт + деньги).
  • 0.3 Остатки по складам/статусам (Свободный, FBO, Транзит-FBO, Ремонт, Брак).
  • 0.4 Себестоимость: средняя по остаткам + «замороженная» на 6 мес.
  • 0.5 Справочник цен/скидок по каналам — параметры в 07_Справочники_классификаторы.
  • 0.6 История изменения РРЦ по времени (даты смены цены) — новая, без Г#.

📅 Уточнено 03.07.2026 — техническая реализация обнаружена в таблице «Калькулятор маржинальности Brodeks» (бывш. «AGT планирование продаж V1») (1yTZW_8iWFMMsk3JzgIK2CzvawHS2kr-Wov_vxMCrIqs), листы-источники через pgapi: - 0.2 (История продаж): лист prodazhi_po_kanalam_only_1c_mt — 208К+ строк, ежедневное обновление. Только 3 канала из 4 (В2В, Дилеры, Розница+ИМ) — МП (Ozon/Wildberries) не включены, отдельный проект. - 0.4 (Себестоимость): листы _RAW_себестоимость (сырые данные) → API_себестоимость (без НДС + с НДС 22%, floor). - 0.5 (Цены): лист API_прайс_лист — база (Артикул/Наименование/Базовая цена/Цена продажи), без формул скидок по каналам — пока не единый справочник, а плоский прайс. - Дополнительно: лист ABC_анализ — сортировка артикулов по выручке. - Статус скриптов обновления: не найдены, не зафиксированы в scripts/ этого проекта — см. задачу 3.8 (Встроенный расчёт прибыли в планировщике, пилот).

📅 Новая задача 0.6, поднята на встрече 06.07.2026 (см. 02_Решения, раздел «06.07.2026 (II)»): в 1С сейчас не фиксируется история изменения РРЦ (даты, когда менялась цена) — без этого нельзя корректно посчитать среднюю историческую скидку по каналу («быстро никак», непонятно, к какой РРЦ относить старые продажи). Это прямой блокер для задачи В2 (историческая скидка B2B) и для уточнения коэффициента любого канала впредь. Также поднят смежный вопрос: нужны исторические остатки на начало каждого месяца (не только текущие — сейчас есть только отчёт Синютина на дату начала месяца), связано с 0.3/1.2/1.5.

🔎 Найдено 06.07.2026 (по прямому запросу — где в 1С КА хранится цена и смена цен): отдельного периодического регистра цен в реплике 1С (Postgres через pgapi, https://pg.dimavp.ru/query) нет — проверено полным перебором ~400 таблиц базы, ничего похожего на регистр сведений «Цены номенклатуры» не реплицируется. Но задача решается даже лучше, без него: - Таблица RealizatsiyaTovarovUslugTovary_PROD (строки документов «Реализация товаров и услуг», 121 042 строки, период 01.07.2025–07.07.2026) хранит по каждой строке продажи: TSena (цена, по которой фактически продано), VidTSeny (тип цены — «Цена продажи» = базовая РРЦ, «Дилер-33»/«Дилер-25»/«Дилер-15»/«Дилер-СНГ(33)»/«Цена продажи СНГ» = скидочные прайс-листы), SsylkaData (дата документа), SsylkaPodrazdelenie (канал/подразделение), SummaRuchnoySkidki/ProtsentRuchnoySkidki (ручная скидка ПОВЕРХ выбранного прайс-листа), SummaAvtomaticheskoySkidki (автоматическая скидка — в данных всегда 0, похоже не используется). Проверено тождество: Summa = TSena×Kolichestvo − SummaRuchnoySkidki − SummaAvtomaticheskoySkidki (сходится на агрегатах по всем каналам). - Важный нюанс, меняющий модель: «Дилер-33» (33%) — это не единственный дилерский прайс-лист, есть ещё «Дилер-15» и «Дилер-25» (разные скидки для разных дилеров/сделок) — наш текущий коэффициент CC2=0.67 на листе «Дилеры Brodeks v2» это упрощение (усреднённая ставка), реальная картина по факту 1С — минимум 3 разных дилерских ставки одновременно. Аналогично В2В в основном идёт по типу «Цена продажи» (полная РРЦ) + возможная ручная скидка сверху (в примерах — 0%, 5%, 11.6% на разные сделки), что подтверждает: наша черновая оценка 0.96 для В2В — это усреднение множества разных фактических скидок, а не одна ставка. - Как считать «недополученную выручку из-за скидки» (уточнено Дмитрием 06.07.2026 — важная поправка методологии): изначально предполагалось считать в 2 шага — (РРЦ − TSena по прайс-листу) + SummaRuchnoySkidki отдельно. Это ненадёжно, потому что в 1С у пользователей есть право вписать TSena вручную (не по прайс-листу вообще), и если сверху ещё накручена ручная скидка — не восстановить, что из итоговой цены — «отклонение от прайс-листа», а что — «скидка от вписанной вручную цены». Правильный, надёжный способ — сравнивать напрямую факт. выручку с БАЗОВОЙ РРЦ, без промежуточных шагов через TSena/VidTSeny/скидки: Недополучено по строке = РРЦ_на_дату_документа × Kolichestvo − Summa. Это единственное сравнение, которое не зависит от того, СКОЛЬКИМИ способами была получена итоговая цена (ручной ввод, прайс-лист, скидка сверху, комбинация) — оно всегда даёт реальную итоговую скидку от РРЦ по этой конкретной продаже. - Остаётся задача: знать РРЦ («Цена продажи») на конкретную дату документа — прямого регистра нет, реконструируется по той же таблице: TSena из строк с VidTSeny='Цена продажи' как временной ряд (замечено фактическое изменение: 15500 → 15035 у одного и того же артикула в один день, 05.06.2026 — метод рабочий, РРЦ реально меняется и это видно в документах). Ограничение: если по артикулу давно не было ни одной продажи именно по типу «Цена продажи», РРЦ на этот период не наблюдаема напрямую — брать ближайшее по времени наблюдение, либо смотреть ZakazKlientaTovary_PROD (заказы клиента, та же структура полей) как дополнительный источник. - Быстрая проверка на реальных данных (за весь период, без восстановления РРЦ по датам, только через типы цен): сумма по цене выбранного прайс-листа минус факт. сумма (SummaRuchnoySkidki, т.е. только «ручная скидка сверху прайс-листа», без разницы между прайс-листами) — В2В 10,3 млн ₽, Дилеры 5,8 млн ₽, Интернет-магазин 1,2 млн ₽, за весь период 01.07.2025–07.07.2026. Это НЕ полная картина (не включает разницу между «Дилер-33» и базовой РРЦ) — полный расчёт требует реконструкции РРЦ по датам, см. выше. - Следующий шаг: написать скрипт реконструкции временного ряда РРЦ по артикулам (из строк VidTSeny='Цена продажи' таблиц RealizatsiyaTovarovUslugTovary_PROD + ZakazKlientaTovary_PROD), затем джойн к каждой продаже по дате (последнее известное значение РРЦ на момент продажи или раньше) для точного расчёта недополученной выручки по каждой строке/каналу/периоду.

🔎 Уточнение 08.07.2026 — реконструкция не нужна, регистр найден готовым: отдельный периодический регистр цен TSenyNomenklatury25_PROD в той же БД (bigquery@10.20.20.81) всё-таки существует (Nomenklatura, Period, VidTSeny включая 'Цена продажи', TSena; 2 992 900 строк) — перебор ~400 таблиц 06.07.2026 его почему-то не нашёл. Методология (join по последнему Period ≤ SsylkaData) проверена на реальном документе AGKA-011639 — см. 02_Решения, запись 08.07.2026, и Методика_расчёта_скидки_от_РРЦ. Переиспользуемый скрипт: /!VDS-DP-Office/scripts/discount_report.py. - Согласован (не реализован) план для листа «Дилеры Brodeks v3»: копия v2 (gspread.duplicate_sheet, v2 не трогается) + новая вкладка-источник API_скидка_от_РРЦ (SQL-агрегаты артикул×канал×месяц) + итоговый столбец скидки за период через SUMIFS. Открыто: место для агрегата по бренду/каналу целиком (шапка рядом с CC2 vs строка A001), нужна ли помесячная разбивка на листе.

🔎 Найден и расшифрован лист-прототип «Обсуждение (копия)» (08.07.2026) — та же книга «Калькулятор маржинальности Brodeks», id листа 1115921388, 14 артикулов (тестовый масштаб, не полный ассортимент). Название вводит в заблуждение — это не текстовое обсуждение, а черновая структура-прототип, конкретизирующая план v3 выше. Прочитан напрямую через gspread (обходит ограничения экспорта, на которые наткнулась параллельная сессия dp-office). Дмитрий надиктовал точную логику столбцов, сверено с реальными числами листа (совпало): - CB (колонка 80): в строке 2 — итоговый % скидки по каналу за весь период (агрегат: 1 − Σ Summa_факт / Σ(Кол-во × РРЦ_на_дату), методика — Методика_расчёта_скидки_от_РРЦ, шаг 3). В строках товаров (4+) — % скидки по артикулу за всю историю продаж (шаг 2 методики, весь период целиком, без разбивки по месяцам). Явно подчёркнуто: итоговая цифра в CB2 — НЕ среднее и НЕ сумма построчных процентов, а отдельный расчёт от общего вала (поэтому будет отличаться от процентов по отдельным позициям). - CC (81): пустой разделитель между блоком скидки и блоком цены/плана (тот же приём, что уже был для разделителя ФАКТ/ПЛАН на CC/81 в v2). - CD (82): Цена продажи (РРЦ), руб с НДС — источник прежний: Excel-файл через pgapi (прайс-лист), НЕ прямой SQL к TSenyNomenklatury25_PROD (тот регистр используется для расчёта скидки в CB, а не для самой цены РРЦ на листе). - CE (83): Цена со скидкой по коэфф. №1 (авто) = CD × CE2 (коэфф. №1 — та же ячейка, что и раньше, напр. 0,67). - CF (84): Цена, введённая вручную (новый РРЦ) — поле ручного ввода, независимое от CD. - CG (85): Цена со скидкой по коэфф. №2 (ручная) = CF × CG2 — применяется только если задан новый РРЦ вручную. - CH (86): Себестоимость, руб без НДС. - Приоритет цены в расчётах (важно): если CG заполнена (введена ручная РРЦ + коэфф. №2) — используем её; если нет — используем CE (базовый коэфф. №1). CD (сырая РРЦ) нигде в расчётах не используется напрямую — это справочная база для CE. - Помесячный блок ПЛАН (с CI, по 4 подколонки на месяц): Шт (расчёт по коэффициенту месяца, как раньше) → Шт вручную (опциональный оверрайд) → Сумма выручки = Кол-во (Шт вручную, если задано, иначе Шт) × Цена (по приоритету CG→CE выше) → Прибыль = Выручка − Кол-во × Себестоимость (CH). - Значение находки: это фактически готовая, продуманная Дмитрием детальная спецификация листа v3 — конкретнее и проще прежнего плана «через SUMIFS в отдельной вкладке» (расчёт скидки — прямо в колонке CB на самом листе). Реализация всё ещё не начата.

💡 Уточнение помесячного плана (Дмитрий, 08.07.2026) — увязка с задачей 0.7: текущая формула «Прибыль» (и в v2, и в «Обсуждение (копия)») сравнивает разнородные величины — Выручка с НДС минус Кол-во×Себестоимость без НДС. Предложено починить: в блок ПЛАН на каждый месяц, справа от «Сумма выручки», добавить новую колонку «Выручка без НДС» = Сумма выручки (с НДС) × (1 − k), где k — эмпирическая эффективная доля НДС из задачи 0.7 (по каналу либо по артикулу×каналу с порогом объёма). Далее «Прибыль» пересчитывается на однородных величинах: Выручка без НДС − Кол-во × Себестоимость (без НДС). Помесячный блок ПЛАН становится: Шт | Шт вручную | Сумма выручки (с НДС) | Выручка без НДС | Прибыль (5 подколонок вместо 4). - Совпадение с находкой по «Обсуждение (копия)»: это ровно то, что должно закрывать пустые заголовки-заглушки в Итого-блоке того листа («Итого план выручки… без НДС» — col190/192, «Итого план прибыль… без НДС» — col194/196) — новая помесячная колонка суммируется в них через SUMIFS по отмеченным месяцам, тем же принципом, что и остальные Итого-колонки. - Не согласовано, не реализовано — требует: (1) выбора порога для артикульного k (открыто в 0.7), (2) решения, где хранить k на листе (доп. столбец на строку артикула vs фиксированная ячейка на канал — по аналогии с CE2/CG2).

📊 Расчёт скидки от РРЦ и ставки НДС по всем основным каналам (08.07.2026, ночь). Join переведён с названия (Nomenklatura, нестабильно) на артикул (NomenklaturaArtikul, стабильно, добавлен Дмитрием в TSenyNomenklatury25_PROD). Полная методика и найденная методологическая ошибка (строки без цены на дату нельзя исключать только из знаменателя — искажает результат) — Методика_расчёта_скидки_от_РРЦ, раздел «Обновление 08.07.2026 (ночь)». - Результат: Дилеры Brodeks — скидка 34,14% (реальная, соответствует CC2=0,67); В2В/Розница/Интернет-магазин — скидки практически нет (±0–3%, торгуют по РРЦ); Ozon/Wildberries — небольшая отрицательная «скидка» (−1,8…−4,7%, продают чуть выше внутренней РРЦ — не ошибка, площадки сами назначают цену). Ставка НДС везде ≈18,03% (=22/122), кроме Дилеров (16,25%) и В2В (17,97%) — там заметная доля продаж нерезидентам. - Дилеры Brodeks — единственный канал, где артикульный/канальный k и скидка реально нужны для точности; на остальных каналах текущий флэт-подход (без скидки) уже почти не отличается от реальности.

Задача 0.7: НДС в расчёте выручки/прибыли — новая, без Г

  • Постановка (Дмитрий, 08.07.2026): для расчёта реальной прибыли по товару нужна ставка НДС, применённая к каждой конкретной позиции реализации — чтобы восстановить выручку без НДС и сравнить её с себестоимостью без НДС. Считать все суммы реализации по единой ставке 22% неверно — часть продаж идёт по другим ставкам, включая 0%. Закрывает часть открытого вопроса В27.
  • Найдено (Claude, 08.07.2026): отдельный справочник ставок не нужен — НДС уже хранится построчно в той же таблице RealizatsiyaTovarovUslugTovary_PROD, что используется для расчёта скидки от РРЦ (0.6):
  • Поля: StavkaNDS (ставка текстом), SummaNDS (сумма налога), SummaSNDS (сумма с НДС — проверено, равна Summa, т.е. Summa уже содержит НДС).
  • Формула выручки без НДС по строке: Summa − SummaNDS (проверено математически на всех встреченных ставках: SummaNDS = Summa − Summa/(1+ставка)).
  • Фактическое распределение по ставкам (121К+ строк, весь период): 20% — 61 609 строк / 799,7 млн ₽; 22% — 56 753 / 544,8 млн ₽; 0% — 3 520 / 38,0 млн ₽; «Без НДС» — 5 / 1,8 млн ₽.
  • 20% vs 22% — переход ставки НДС во времени, не разные категории: 20% встречается в документах до 23.04.2026, 22% — с 02.01.2026 (переходный период январь–апрель 2026, дальше только 22%), привязано к дате документа, не к каналу.
  • 0% и «Без НДС» распределены неравномерно по каналам: заметная доля у В2В (0% — 81 строка/1,0 млн ₽; «Без НДС» — 5 строк/1,8 млн ₽) и у Дилеров (0% — 3 437 строк/36,9 млн ₽, самая крупная сумма по нулевой ставке) — похоже на экспорт/СНГ, требует подтверждения. У Розницы/МП/Интернет-магазина — почти только 20%/22%, нулевой ставки нет.
  • Размышление Дмитрия 08.07.2026 (открытый вопрос, не решено): в проекте складывается три разных расчёта с разным отношением к НДС:
  • % скидки от РРЦ (0.6): цена реализации (TSena, с НДС) сравнивается с РРЦ (TSenyNomenklatury25_PROD, тоже с НДС) — обе величины «грязные» (gross), НДС не искажает результат, так как сравниваются однородные величины.
  • Факт. выручка без НДС: построчно через Summa − SummaNDS (это задача 0.7 выше) — используется вместе с себестоимостью без НДС для расчёта реальной маржи по факту.
  • Прогноз выручки (планировщики каналов, 2.3 и калькулятор 3.8): предполагается вести целиком без НДС — и выручку, и себестоимость — чтобы прибыль в прогнозе не зависела от НДС вообще.
  • Проблема: нужно уметь связывать/сверять цифру «выручка с НДС» и «выручка без НДС» (например, для сверки прогноза с фактом в 1С/бухгалтерии), но для прогноза заранее не известно, по какой ставке НДС будет продан конкретный товар — микс ставок на уровне позиции плана непредсказуем. Фактическая выручка с НДС при этом всегда смешивает позиции, проданные по разным ставкам (в т.ч. 0%/без НДС) — обратный пересчёт «без НДС» → «с НДС» не тривиален без допущений о будущем миксе ставок.
  • Решения пока нет — зафиксировано как открытый вопрос, требует решения перед реализацией прогноза выручки без НДС в планировщиках каналов.
  • Направление решения для неопределённости ставки в прогнозе (размышление Дмитрия + Claude, 08.07.2026, не согласовано с Глебом): для плановой выручки без НДС наивно вычитать фиксированные 22% из расчётной цены реализации — неточно, если у канала есть заметная доля продаж по 0%/«Без НДС». Предложение: вместо флэт-22% использовать эмпирическую эффективную долю НДС по каналу, k = Σ SummaNDS / Σ Summa за недавний период после перехода на 22% (с 01.05.2026, чтобы не смешивать со старой ставкой 20%) — тот же принцип, что уже используется для коэффициентов скидки канала (CC2). Плановая выручка без НДС = Плановая выручка с НДС × (1 − k).
  • Проверено на реальных данных (01.05–08.07.2026): Розница/МП/Интернет-магазин/прочие — k = 0.1803 = ровно 22/122, т.е. флэт-22% для этих каналов и так корректен (продаж по 0%/без НДС в них почти нет). В2В — k = 0.1794 (близко к 22%, минимальное искажение). Дилеры Brodeks — k = 0.1562, заметно ниже 0.1803 — здесь флэт-22% дал бы систематическое завышение вычитаемого налога (и, соответственно, занижение плановой выручки/прибыли без НДС).
  • Ограничение подхода: это статистическая оценка на уровне канала, не гарантия для каждой конкретной будущей сделки — снимает системную ошибку (флэт-22% там, где есть льготные ставки), но не устраняет неопределённость полностью. Требует периодического пересчёта k (та же частота, что и другие эмпирические коэффициенты канала).
  • Механизм подтверждён (Дмитрий + Claude, 08.07.2026): 0%/«Без НДС» — не случайный разброс, а конкретные контрагенты-нерезиденты. Найдено 29 уникальных партнёров с такой ставкой, все — дилеры из Беларуси (Минск, Гродно, Брест) и Казахстана (Астана, Алматы, Караганда, Актау, Темиртау), плюс один В2В-партнёр (Казахстан). Совпадает с прайс-листами «Дилер-СНГ(33)»/«Цена продажи СНГ» из находки задачи 0.6. Объясняет, почему у «Дилеры Brodeks» k заметно ниже стандартного (0.1562 vs 0.1803) — устойчивая база дилеров-экспортёров, а не шум.
  • Согласовано направление (не окончательное решение, ждёт подтверждения Глеба): т.к. на уровне детализации плана (канал × модель-цвет) состав будущих покупателей не прогнозируется, единственный практичный путь — использовать историческую эффективную долю НДС канала (k) как расчётную для будущих периодов, по тому же принципу, что и коэффициент скидки CC2. Отдельного разреза «резидент/нерезидент» на уровне позиции плана не требуется — канал уже агрегирует этот эффект.
  • Уточнение granularity (Дмитрий, 08.07.2026): канальный k — огрубление. Проверено на топ-артикулах канала «Дилеры Brodeks» (май–июль 2026, 300–400 строк на артикул — выборка не маленькая): разброс k по артикулам 0.095–0.18 (AIR=0.0951, Cyclone=0.11, DragonGR=0.1209 — заметно ниже среднего по каналу 0.1562; KS223YELLOW=0.1803, KS334BLACK=0.174 — на уровне флэт-22%). Это больше, чем разброс между каналами (0.156–0.180) — не шум выборки, а системная разница: одни модели заметно популярнее у дилеров-нерезидентов (Беларусь/Казахстан, см. находку по 29 партнёрам выше), другие почти не идут на экспорт.
  • Мнение Claude (08.07.2026, по прямому запросу — «внеси как твою версию»): да, для точности прогноза правильная цель — восстанавливать k по строкам (артикул × канал), а не только на уровне канала. Предложение по реализации:
  • Считать k в разрезе (артикул × канал) за недавний период (после перехода на 22%).
  • Двухуровневая модель с порогом по объёму: у артикула с достаточным числом строк/суммой за период — берём его собственный k; при малом объёме данных (редкие продажи) — откатываемся на канальный k, чтобы не тащить шум единичной нерезидентской сделки в прогноз. Порог объёма — открытый параметр, нужно подобрать эмпирически (не выбран).
  • Очерёдность: сначала канальный k (уже провалидирован, простая формула — закрывает основную ошибку флэт-22%), артикульный разрез с порогом — следующий шаг поверх него, не одновременно. Тот же паттерн, что уже сработал на пилоте «Дилеры Brodeks» (v1 → v2 → v3).
  • Это личная рекомендация Claude, не согласовано с Дмитрием/Глебом как решение.
  • Статус: находка и механизм задокументированы, двухуровневая формула для плана (канал + артикул с порогом) предложена Claude как рекомендация — реализация (добавление k в листы каналов, подбор порога) не начата, архитектурный вопрос сверки «с НДС» / «без НДС» в целом (В30) остаётся открытым.

🚧 Реализация начата 08.07.2026 (вечер) — пилот на канале «Дилеры Brodeks», уровень канала (не артикул). По итогам обсуждения решили начать с более простого канального уровня (CB2/CC2, единое число на канал, без построчного/артикульного разреза — см. рекомендацию выше, п. «Очерёдность») и с упрощённой финальной методики нормализации НДС (не окно после 01.05, а построчная аппроксимация по всей истории: строки 20%/22% → Summa/1.22, строки 0%/«Без НДС» → Summa без изменений; свёрнуто в k = 0.1803 × (1 − доля льготной выручки) — см. 02_Решения, запись «2026-07-08 (II)»). - Посчитано и записано на листе «Обсуждение (копия)»: CB2 = 34,05% (скидка от РРЦ, канал целиком, вся история), CC2 = 16,25% (эмпирическая доля НДС, вся история, нормализованная методика). Расчёт: join RealizatsiyaTovarovUslugTovary_PROD (39 441 строка канала) с ценами на дату — сделан на стороне Python (bisect по предзагруженной истории цен), не через SQL LATERAL JOIN (тот падал по таймауту, см. ниже). Покрытие — 39 385/39 441 строк нашли цену на дату (99,86%). - Важная поправка методологии от Дмитрия: join цен с продажами по названию (Nomenklatura) ненадёжен — названия в 1С нестабильны (переименования). Проверено: джойн по названию через справочник Nomenklatura_PROD дал 6,3% несовпадений, из них 137 строк — реальные переименованные брендовые товары (Brodeks/Portwest/BASE/Finntrail), не шум. Решение: join только по артикулу. Дмитрий добавил колонку NomenklaturaArtikul напрямую в TSenyNomenklatury25_PROD и перезалил таблицу (в моменте догрузки — было 6 053 027 строк, шло от ~630К до ~1,47 млн в процессе перезаполнения). - Инфраструктура ускорения join — сделана совместно с Дмитрием: - Обнаружено: LATERAL JOIN по (Nomenklatura, Period) без индекса не укладывался в таймаут pgapi (60 сек не хватило на канал в 39К строк). - Создан скрипт scripts/25_rrc_price_history_matview.sql — индекс + материализованное представление mv_rrc_price_history (артикул/дата/цена, только VidTSeny='Цена продажи', теперь по NomenklaturaArtikul, без промежуточного джойна на справочник). Дмитрий создал его сам в БД (у ключа pgapi только SELECT, DDL им не выполнить — проверено). - Обновление представления — не отдельным cron/скриптом, а найденным существующим воркфлоу n8n на офисном VDS (100.108.155.34, контейнер n8n-ngkok0w84c08wcw0kwkwc0sc) — «Обновление мат. представлений в 4 утра 03.26» (id oE68bEtGB9KgddMW, реально каждые 2 часа). Дмитрий сам дописал туда REFRESH MATERIALIZED VIEW mv_rrc_price_history; в конец существующего списка, тестирует. - Убран как ненужный отдельный scripts/26_refresh_mv_rrc_price_history.sh (bash+cron вариант) — избыточен при готовом централизованном механизме. - Текущий статус (на паузе, ждём): таблица TSenyNomenklatury25_PROD ещё догружается (перезалив с добавленным артикулом) — представление mv_rrc_price_history уже пересоздано по новой (артикульной) структуре и подтверждено рабочим, но заполнено частично (снимок на момент создания, не живая ссылка — нужен REFRESH после завершения догрузки). CB2/CC2 посчитаны на полных данных (Python-джойн делался до начала перезаливки) — пересчёт через SQL после REFRESH нужен для проверки инфраструктуры, не блокирует использование текущих цифр.

📐 Финальная схема колонок для v3 (согласована с Дмитрием 08.07.2026, копируем из v2, не из «Обсуждение (копия)» — архитектура v2 проще, только один сценарий цены, без второго коэффициента): - В шапке (перед текущей «Цена продажи»): новая CB — «Скидка от РРЦ за всю историю, %» (только CB2=34,05%, строки товаров пустые); новая CC — «Эмпирическая ставка НДС за всю историю, %» (только CC2=16,25%). - Новая колонка «Себестоимость, руб (без НДС)» рядом с существующей «Себестоимость, руб (с НДС)» — VLOOKUP по артикулу в API_себестоимость (в этом справочнике уже есть готовая колонка D «без НДС», отдельно считать не нужно). - Помесячный блок — 5 подколонок (было 4): Шт | Шт вручную | Сумма выручки (с НДС) [без изменений формулы, только явная пометка в названии] | Выручка без НДС (новая, =Сумма_выручки×(1−$CC$2)) | Прибыль без НДС (переименована из «Прибыль», новая формула =Выручка_без_НДС − Кол-во×Себестоимость_без_НДС; старая формула с НДС не сохраняется параллельно — заменяется). - Все денежные колонки дополнительно получают явную пометку «(с НДС)» / «(без НДС)» в названии, где раньше подразумевалось неявно. - Итого-блок переводится на ту же без-НДС основу (выручка/себестоимость/прибыль/рентабельность), для согласованности с помесячным уровнем. Сравнительная пара «до ручной РРЦ» (GI/GJ-аналоги) — не трогаем, оставляем на текущей (с НДС) основе. - Источник: копия «Дилеры Brodeks v2» (gspread.duplicate_sheet, v2 не трогается) → «Дилеры Brodeks v3». - Реализация в процессе (08.07.2026, вечер) — структурная вставка колонок через Google Sheets API (batchUpdate/insertDimension), формулы генерируются и пишутся Python-скриптом батчами по столбцу (не по ячейке), форматирование — под уже принятую в книге цветовую схему.

🏗️ v3 создан и в основном собран (08.07.2026, ночь). Лист «Дилеры Brodeks v3» создан (gspread.duplicate_sheet, v2 не тронут). Финальная схема отличается от первоначального плана выше — по ходу реализации Дмитрий сверился с логикой прототипа «Обсуждение (копия)» и попросил перенести оттуда механизм двух ценовых сценариев (не упрощать до одного, как в v2): - Итоговая структура шапки (слева направо): CB скидка от РРЦ % (CB2=34,05%) → CC эмпирическая ставка НДС % (CC2=16,25%) → CD разделитель (серый, пустой) → CE Цена продажи (РРЦ), с НДС → CF Цена со скидкой, коэфф.№1 (авто, =CE×$CF$2, CF2=0,67) → CG РРЦ, введённая вручную → CH Цена со скидкой от ручной РРЦ, коэфф.№2 (=IF(CG≠"";CG×$CH$2;""), CH2=0,67 — стартовое значение равно коэфф.№1, Дмитрий поправит позже) → CI Себестоимость, без НДС (единственная себестоимость — «с НДС» удалена как неиспользуемая). - Приоритет цены в «Сумма выручки»: =Кол-во×IF(CH≠"";CH;CF) — если задана ручная РРЦ (и, соответственно, посчитан CH) — берём её; иначе автоматическую CF. Формула пустая в CH, когда CG не заполнена — чтобы приоритет работал корректно (в прототипе-«черновике» этой защиты не было, там CH считался безусловно — учтено как ошибка прототипа, не скопировано). - Помесячный блок — 5 подколонок, как и планировалось: Шт | Шт вручную | Сумма выручки (с НДС) | Выручка без НДС (=Сумма_выручки×(1−$CC$2)) | Прибыль без НДС (=Выручка_без_НДС − Кол-во×$CI). Строка 4 («Итого» по ассортименту) дозаполнена SUM()-формулами для новых колонок по тому же принципу, что и у существующих. - Пойманные и исправленные ошибки в процессе: 1. Подпись «Разделитель» по невнимательности была вписана не в ту ячейку (в CE вместо CD), затёрла заголовок «Цена продажи» — заметил Дмитрий, восстановлено (данные/формулы не пострадали, только текст заголовка). 2. Условное форматирование (зелёный/красный по знаку прибыли, 25 диапазонов на 25 месяцев) при первой пакетной вставке 25 колонок не сдвинулось для месяца №1 (июль) — Google Sheets не продлил именно этот диапазон при вставке на его границе. Из-за этого на глаз казалось, что у июля «нет разделителя» и цвета «не такие», как у остальных месяцев. Починено — добавлен недостающий диапазон правила. 3. После нескольких раундов вставки/удаления колонок осталась одна полностью пустая незамеченная колонка (CI, между коэфф.№2 и себестоимостью) — обнаружена и удалена. 4. Толстая граница, отмечающая конец ценового блока, при вставке новой колонки осталась на старой позиции — перенесена на актуальный край блока (CI). - Названия колонок CE–CI приведены в соответствие с формулировками прототипа «Обсуждение (копия)» (более точные, чем черновые из v2). - Остаётся сделать: переработать Итого-блок (GB–GJ-аналоги, сейчас на позиции HE+ после всех сдвигов) на без-НДС основу — задача 0.6/0.7 из плана выше ещё не выполнена, следующий шаг.

✅ Итого-блок переработан дважды (08.07.2026, ночь) — финал: 12 колонок по образцу прототипа, сгруппированные по сценарию. Первая версия (7 колонок, компактная) была заменена по прямому запросу Дмитрия («должно быть 12 столбцов итогов справа»). Порядок колонок — не как в прототипе (там метрики чередуются по сценариям), а сгруппирован по сценарию целиком (предложение Claude, принято): сначала весь коэфф.№1 как мини-П&Л, потом весь коэфф.№2, дельты — в конце. Итоговая последовательность: разделитель (серый) → Итого план, шт → Себестоимость без НДС → Коэфф.№1 (авто): Выручка с/без НДС, Прибыль без НДС, Рентабельность → Коэфф.№2 (факт/ручная): то же самое → Дельта выручки → Дельта прибыли (обе дельты без НДС). Раскраска по группам: Шт — белый, Себестоимость — коричневый (как в помесячном блоке), коэфф.№1 — синий, коэфф.№2 — золотой, дельты — сиреневый. Суммы — целые рубли, рентабельность — один знак после запятой. - Итоговая проверка на реальных данных: коэфф.№1 (авто, если бы РРЦ никогда не переопределяли вручную) — выручка без НДС 304 906 681 ₽, прибыль 159 891 457 ₽, рентабельность 52,4%. Коэфф.№2 (факт, с учётом редких ручных РРЦ) — выручка без НДС 299 896 051 ₽, прибыль 154 880 827 ₽, рентабельность 51,6% — совпадает с ранее известной референсной цифрой «51%» по этому каналу (пилот 03.07.2026) — независимое подтверждение корректности расчёта. Обе дельты (выручки и прибыли) математически равны между собой (−5 010 630 ₽) — ожидаемо, себестоимость одна и та же в обоих сценариях, поэтому дельта прибыли всегда равна дельте выручки. - Дважды пойманная одна и та же ошибка (важный урок): формулы Итого-строки (row4, «Итого» по всему ассортименту) писались по аналогии с товарными строками (Шт × цена_этой_строки / Шт × себестоимость_этой_строки), но у строки 4 нет «своей» цены/себестоимости на единицу (она разная у каждого артикула) — ячейки-источники на этой строке пустые, произведение уходило в 0. Оба раза исправлено на =SUM(диапазон_по_товарным_строкам). При любом будущем добавлении Итого-показателя, зависящего от цены/себестоимости — сразу использовать SUM, не копировать формулу товарной строки. - Технический урок сессии: при переписывании формул большими партиями (222 строки) вызовы acell() по одной ячейке в цикле упираются в лимит чтений Google Sheets API (429) — нужно читать весь диапазон одним запросом (worksheet.get(range, value_render_option='FORMULA')) и обрабатывать локально, не читать по ячейке в цикле. - Не сделано: артикульный разрез CB/CC (пока только канальный уровень), лист «Инструкция» под новую логику (следующий шаг по плану Дмитрия), проверка после полной догрузки TSenyNomenklatury25_PROD и REFRESH материализованного представления.

🆕 Новое правило для всех v3-листов (Дмитрий, 08.07.2026, ночь): только бренд Brodeks. Остальные бренды на канале (Portwest, BASE, Engel и т.д.) не интересны — строки других брендов удаляются, а CB2/CC2 (скидка/НДС) пересчитываются только по Brodeks, не по всему каналу. Правило действует на все будущие v3-листы, включая «Все каналы_Глеб v3». - Пересчёт по Brodeks дал заметно другие цифры, чем по всему каналу: Дилеры — скидка не изменилась (34,14%, канал и так почти весь Brodeks), НДС не изменился (16,25%). В2В — скидка изменилась с ≈0% (все бренды) на 0,82% (только Brodeks), НДС с 17,97% на 18,01%. - Оказалось, что не-Brodeks строк было заметно больше, чем ожидалось: в В2В из 1234 товаров только 244 — Brodeks (980 других брендов, 80% листа!), в Дилерах — 216 из 221 (уже был почти весь Brodeks).

✅ «В2В v3» построен по образцу Дилеров (08.07.2026, ночь) — та же архитектура, применена без повторения ошибок первого захода. - Структура идентична v2 Дилеров (те же 193 колонки в оригинале, тот же помесячный паттерн) — скрипт вставки колонок переиспользован без адаптации. После вставки — 248 строк (только Brodeks), 225 колонок. - Три новых ошибки поймал и исправил (ни одна не повторяла найденные на Дилерах — новые грабли того же метода): 1. Задвоение чекбокса на «Выручка без НДС» (новая помесячная колонка): при вставке с inheritFromBefore: False новая колонка унаследовала чекбокс от соседа СПРАВА (старая «Прибыль»), а не осталась пустой. На Дилерах этого не было — там та же вставка шла с inheritFromBefore: True (наследование слева, где чекбокса не было). Почищено на всех 25 месяцах. 2. Коэффициент №1/№2 оказался 0,18 вместо заданных 1,0 — после нескольких раундов вставки колонок значение переписалось (источник расхождения не установлен точно). Обнаружено по явно нелогичным цифрам Итого (отрицательная рентабельность −86%) — себестоимость оказалась выше выручки. Исправлено прямой перезаписью. 3. Чекбоксы задублировались и в шапке самого Итого-блока (HE2–HQ2, 13 ячеек) — при вставке 13 новых колонок в конец диапазона (inheritFromBefore: True, вставка на границе листа) новые колонки унаследовали чекбокс-валидацию от последнего месяца. Эти колонки — не помесячные переключатели, чекбоксы там не нужны вообще. Очищено на обоих листах (Дилеры v3 туда же затесалась та же проблема). 4. Забыл дозаполнить строку 4 («Итого») для новой колонки «Выручка без НДС» по всем 25 месяцам сразу (тот же паттерн, что уже фиксировал на Дилерах, но забыл повторить на автомате) — исправлено. - Технический урок: при переписывании формул на большом листе (1234 строки, до фильтра по бренду) один раз поймал лимит записи API (429, не только чтения, как раньше) — увеличил размер чанка (620 строк вместо ~300) и добавил time.sleep(2) между запросами + retry с ожиданием 20 сек при 429. - Финальные цифры (только Brodeks): коэфф.№1 (авто) — рентабельность 66,2%; коэфф.№2 (факт) — 68,0%. Оба выше, чем у Дилеров (51–52%) — ожидаемо для В2В без дилерской скидки. - Следующий шаг (по прямому запросу Дмитрия): «Все каналы_Глеб v3» — сводный лист, тоже с фильтром по Brodeks и пересчитанными CB2/CC2.

✅ «Все каналы_Глеб v3» построен (08.07.2026, ночь) — все три v3-листа канала завершены. Применены все уроки предыдущих двух заходов сразу — прошло почти без новых ошибок: - Порядок операций поменян по итогам опыта: сначала дублирование листа, сразу удаление не-Brodeks строк (2887→284, из них только 280 — Brodeks), и только потом структурная вставка колонок — вместо «вставить структуру на весь лист, потом чистить» (как было на В2В, где 990 из 1234 строк оказались выброшены впустую). Сэкономило кратно на объёме записи. - Вставка месячных колонок — с inheritFromBefore: True (наследование слева) с самого начала — проверил чекбокс сразу после вставки, задвоения не было (в отличие от В2В, где сначала стояло False). - Коэффициенты CF2/CH2 — проверены сразу после записи (value_render_option='FORMULA'), подтверждены верными (1,0/1,0) — повторения загадочной подмены на 0,18 (как на В2В) не было. - Итого-блок собран сразу с превентивной очисткой чекбоксов в шапке (HE2–HQ2) — не ждал, пока станет заметно, почистил сразу после вставки колонок. - Одна новая проблема всё же была: при записи формул 25 месяцев без пауз между запросами (маленький лист, 280 строк — казалось, что лимит не грозит) поймал лимит записи API на 20-м месяце из 25; при доп. диагностике после ретрая обнаружилось, что фактически на сервере применилось больше, чем показывал вывод скрипта (буферизация print), из-за чего пришлось точечно искать и дозаполнять только реально недостающее (4 месяца, колонка «Выручка без НДС») — не переписывать всё заново. - Финальные цифры (только Brodeks, сумма по всем каналам): скидка от РРЦ 15,31%, НДС (доля от валовой) 17,42% (=21,09% в привычном виде). Коэфф.№1 (авто) и коэфф.№2 (факт) — рентабельность одинаковая, 61,6% (дельта всего 2,58 млн ₽ на обороте ~1,1 млрд ₽ — ручные правки цены почти не используются в масштабах всей компании). - Оформление всех трёх листов синхронизировано принудительно — по указанию Дмитрия («цвета у Дилеров самые лучшие») формат Итого-блока (HF–HQ, шапка + данные) скопирован с Дилеров v3 на оба других листа через Sheets API copyPaste (pasteType: PASTE_FORMAT), а не пересобран вручную — гарантирует побитовое совпадение, попутно нашёл и убрал ручные расхождения (размер шрифта заголовков CB3/CC3, отсутствующий numberFormat у CH3 на «Все каналы»).

Итоговая сводная таблица по трём готовым v3-листам (только Brodeks):

Лист Товаров Скидка от РРЦ НДС (доля от валовой) НДС (привычный вид) Рент. коэфф.№1 Рент. коэфф.№2
Дилеры Brodeks v3 216 34,14% 16,25% 19,40% 52,4% 52,7%
В2В v3 244 0,82% 18,01% 21,97% 66,2% 68,0%
Все каналы_Глеб v3 280 15,31% 17,42% 21,09% 61,6% 61,6%

Не сделано / следующие шаги: Розница+ИМ, Ozon, Wildberries — ещё на архитектуре v2, не переведены на v3. Лист «Инструкция» описывает общую логику, но не содержит специфику Brodeks-фильтра (стоит дополнить). Артикульный разрез CB/CC по-прежнему только канальный уровень.

Блок 1: Остатки и оборачиваемость

Задача 1.2: Локатор оверстока и андерстока помодельно (Г2)

  • Суть: Расчет прогноза продаж на основе статистики продаж прошлых 12 месяцев и сравнение со свободным стоком.
  • Функционал:
  • Подсветка по критериям: 0-4 мес — оранжевый, 4-7 мес — зелёный, 7+ мес — красный.
  • Группировка по категориям (зима, лето, обувь, перчатки, аксессуары).
  • Детализация: модель-цвет (размер не нужен).
  • Периодичность обновления: раз в месяц.

📅 Уточнено на встрече 29.06.2026: - Свободный сток = «Доступно» в 1С (только склад Шушары + Кировский). - FBO = все статусы остатков МП кроме «Заявки на поставку» (по API). - Транзит FBO = заказы клиента МП в статусе «Отгрузить» (физически не покинули склад или в пути до приёмки МП). Статус «Отгружено» в 1С ставить ТОЛЬКО при физическом выезде со склада. - Продажи за 12 мес — суммарно по всем каналам (не раздельно). Делим сток на среднемесячные продажи → количество месяцев запаса. - Склады не берём: магазины, брак (склады Киевская, Кодняковская, Егорова — удалить), ремонт-старый. - Заявки на поставку МП — не скачиваются по API, не включаем. - Серая зона (товар «от ворот до приёмки МП») — не критична, принято игнорировать. - ABC-сортировка по выручке за год, по убыванию. Категоризация — второй волной (нужна разбивка от Глеба/Алексея).

📅 Согласовано с Антоном 03.07.2026 (см. Согласование_остатки_03-07-2026_Антон, ⚠️ есть расхождение со строкой выше про склады Егорова — открытый вопрос В22): - Ограничение: точный остаток («склад − отгружается − резерв») снимается только на текущий момент, историю на произвольную дату восстановить нельзя. - МП без заявок: товар в пути до МП уже учтён в отчёте МП («Товары в пути») — заявки не берём (подтверждает решение 29.06). - РО до статуса «Отгружено» — отдельно не анализируем, дублировало бы отчёт МП. - Лого-подрядчики (товар на логотипировании) — не собираются сейчас, нужна проработка сбора (В25). - Точный список складов 1С для «текущих остатков» — см. 07_Справочники_классификаторы раздел 3.

Задача 1.5: Дашборд себестоимости остатков по складам / Финансовый сток (Г5)

  • Суть: Лёгкий дашборд свободных остатков в разбивке по складам (FBO, Транзит на FBO, Ремонт, Брак), бренду и моделям.
  • Дополнительно: Исторические данные, диаграмма распределения товара помодельно.

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

Блок 2: Планирование продаж

Задача 2.3: Планировщик продаж помодельно внутри канала (Г3)

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

📅 Уточнено на встрече 29.06.2026: - Структура прототипа (горизонтально): Наименование | РРЦ | % скидки (один на канал, вверху) | Факт мес1–12 (штуки) | Коэф мес1–12 (вручную) | План мес1–12 (штуки) | Итог штук за год | Ориентир. сумма (руб.). - Помесячная сумма в руб. — не нужна на первом этапе. Только итог за год. - РРЦ и % скидки — информативное поле. Штуки — рабочее. Деньги только для самоконтроля директора («бьюсь ли в план»). - Второй этап (после отпуска): добавить возможность изменять РРЦ и смотреть влияние на маржу. РРЦ вынести в отдельный справочник (единая сущность, тянется везде).

🚧 Реализация начата 03.07.2026 (несмотря на приоритет «после отпуска» по одним задачам — здесь пользователь явно запросил старт). Прогресс: - Файл: Google Sheets «Калькулятор маржинальности Brodeks» (бывш. «AGT планирование продаж V1») (id 1yTZW_8iWFMMsk3JzgIK2CzvawHS2kr-Wov_vxMCrIqs), доступ — тот же сервис-аккаунт claude-sheets@my-project-93453-01-04-26.iam.gserviceaccount.com. - Источники данных обнаружены через pgapi (https://pg.dimavp.ru, ключ в 07_Справочники_классификаторы): - История продаж — таблица prodazhi_po_kanalam_only_1c_mt (обновляется ежедневно), 208 156 строк, июль 2025 – июль 2026. Каналы (podrazdelenie): В2В, Дилеры Brodeks, Розница, Интернет магазин, Маркетплейс Озон, Маркетплейс Wildberries. На этом этапе Ozon/Wildberries не включены (планируются отдельно, через проект «FBO Маркетплейсы»). - Прайс-лист — файл Прайс-лист XLSX.xlsx на офисном сервере (через pgapiDownloadFile_), лист API_прайс_лист (Артикул/Номенклатура/Базовая цена/Цена продажи, 4810 позиций). - Себестоимость — файл Себестоимость товаров организаций по брендам - июль 25-дек 25 (XLSX).xlsx (та же логика, что и в проекте «Отчёт по сравнению остатков склада и организации», скрипт load_sebestoimost.js), лист API_себестоимость (2898 артикулов, колонки без НДС и с НДС 22%, копейки отбрасываются — floor). - Остатки — не входят в этот файл (используются в отдельном отчёте — задаче 1.2/1.5, Локатор). - Структура итоговых листов (по одному на канал — «Дилеры Brodeks», «В2В», «Розница+ИМ»): Бренд | Артикул | Наименование → блок ФАКТ (Шт/Сумма на каждый месяц, июль 2025 – запас на 3 года вперёд, чтобы новые месяцы просто ложились в готовые колонки) → блок ПЛАН (Шт/Сумма на 12 мес вперёд, авг 2026 – июл 2027, с редактируемым коэффициентом в строке над каждым месяцем; План.Шт = Факт(тот же месяц год назад) × коэффициент; План.Сумма = План.Шт × Цена продажи из API_прайс_лист через VLOOKUP) → Итого план, руб/год. Строка «ИТОГО» сразу под шапкой суммирует шт/руб по каждому месяцу (диапазон с запасом на 6000 строк вперёд под будущие товары). Строки отсортированы по убыванию выручки за историю (ABC). - Архитектура обновления (согласовано с пользователем 03.07.2026): 1. Коэффициент — общий на месяц (в строке шапки), не на строку товара → обновление списка артикулов не портит введённые коэффициенты. 2. Догрузка данных — только upsert (обновление ФАКТ-ячеек существующих артикулов + добавление новых строк в конец), без полной перезаписи листа. 3. ABC-пересортировка — отдельное явное действие (не автоматически при каждой догрузке). 4. Фиксация плана — дублирование листа + перевод формул блока ПЛАН в статические значения (иначе цена/коэффициент могут задним числом изменить «утверждённый» план). 5. Пересчёт плана при смене коэффициента — не требует кнопки, формулы Google Sheets пересчитываются автоматически. - Следующий шаг: Apps Script + лист «Панель» (по образцу проектов «FBO Маркетплейсы» и «Отчёт по сравнению остатков») с кнопками: обновить тех. листы (без сырого дампа, агрегация сразу при выгрузке — план от 03.07.2026), ABC-пересортировка, фиксация плана, ссылка на отдельный файл сырых данных (обновляется по кнопке, не хранится в основном файле), выгрузка в Excel (конкретный лист / вся книга — для архива/бэкапа). Пока эти операции выполняются через Python-скрипты по запросу. Приоритет низкий — не блокирует текущую работу. - ABC: список артикулов по убыванию выручки за последний год. Группировка по категориям/линейкам — второй волной (нужна классификация от команды). - Каналов: Беляев, Галягин + ещё каналы. Итого 4–5 таблиц + одна сводная.

Блок 3: Маржинальность и сценарии

Задача 3.6: Помодельный маржинальный калькулятор (Г6)

  • Суть: Расчет прогнозной маржинальной прибыли по бренду/моделям.
  • Вводные: Средняя себестоимость остатков, прогноз продаж (из задачи 2.3).
  • Требования:
  • Учет рентабельности каждого канала (из задачи 2.3).
  • Возможность ручной корректировки «что-если» (прогноз продаж, себестоимость, РРЦ, скидки).
  • Отображение 3-х полей: базовый сценарий, новый сценарий, дельта (отклонение).

Задача 3.7: Планирование маржинальной прибыли продажами (Г7)

  • Суть: Дашборд для планирования прибыли (логическое продолжение задач 2.3 и 4.4).
  • Проблема: Директора по продажам не привязаны к прибыли, маржа «плавает».
  • Решение:
  • Фиксация усреднённой себестоимости на период (например, 6 месяцев) для отчётности продаж.
  • Расчет прогноза прибыли по каналам и моделям.
  • Ежемесячный свод факта продаж и расчётной прибыли.
  • Формат: Excel или Google Таблицы (для ручной игры с цифрами и сценариями увеличения показателей).

Задача 3.8: Встроенный расчёт прибыли в планировщике (пилот) — новая, без Г

  • Суть: Базовый расчёт маржи прямо внутри листов планировщика продаж (задача 2.3), без отдельного what-if калькулятора (3.6).
  • Реализовано на листе «Дилеры Brodeks» (Google Sheets «Калькулятор маржинальности Brodeks» (бывш. «AGT планирование продаж V1»), обнаружено 03.07.2026):
  • Колонки «Категория» и «ABC» (после Наименования).
  • Строка чекбоксов (TRUE/FALSE) для включения конкретного месяца ПЛАН в «Итого».
  • По строке — «Цена продажи, руб (с НДС)» и «Себестоимость, руб (с НДС)».
  • В каждом месяце блока ПЛАН — 3 подколонки: Шт | Сумма выручки | Прибыль.
  • «Итого план, шт» и «Итого план выручки, руб» разделены на отдельные колонки (считаются только по отмеченным чекбоксом месяцам).
  • Не реализовано: Листы «В2В» и «Розница+ИМ» ещё старой структуры (без Категории/ABC/чекбоксов/маржи) — требуют репликации структуры «Дилеров».
  • Открытый вопрос: заменяет ли эта встроенная прибыль полноценный калькулятор «что-если» (3.6, База/Сценарий/Дельта, согласовано 29.06.2026), или это промежуточный шаг, а 3.6 всё равно нужен отдельно.
  • Скрипты обновления: не найдены и не зафиксированы в scripts/ — работа выполнялась другим ИИ-инстансом (предположительно на «Gemini Home VM»), исходники не сохранены. Требуется уточнить у пользователя расположение или пересобрать логику заново.

📅 Прогресс 03.07.2026 (вечер, реализовано этой сессией Claude на листе «Дилеры Brodeks»): - Цена со скидкой канала: колонка «Цена продажи со скидкой» — цена × редактируемый коэффициент (0.67 = скидка дилеров 33%). «Сумма выручки» во всех 24 месяцах плана переключена на неё вместо полной цены (было завышение выручки/прибыли). - Колонка «Рентабельность, %» (EZ) — Прибыль/Выручка×100 по отмеченным чекбоксом месяцам, с итогом по всему ассортименту (сейчас 51%). - Раскраска по смыслу: заголовки по блокам (ID/ФАКТ/Цена/План/Прибыль/KPI), условное форматирование по ABC, категории товара и бренду (Brodeks нейтрально, посторонние бренды Portwest/BASE — ярко), знак прибыли (красный/зелёный) — на весь лист, не только первые строки. «Шт» намеренно оставлены белыми — только суммовые типы данных подсвечены. - Сжатие шапки: месячный коэффициент и чекбокс перенесены в одну строку с названием месяца, старая строка-2 удалена — шапка короче на 1 строку. Формат чисел — пробел вместо запятой (сменена локаль файла на ru_RU). - Полнота данных проверена: 221 артикул на листе = 221 артикул, когда-либо проданный через канал «Дилеры Brodeks» за весь период (июль 2025 – июль 2026) — расхождений нет. - Сделано только на листе «Дилеры Brodeks» — «В2В» и «Розница+ИМ» не трогали. - Подробный технический журнал каждого шага — Техническая_реализация_данных.

✅ Задача 3.8 завершена 03.07.2026 21:31 — первая версия готова. Дополнительно к прогрессу выше: индекс ABC для сортировки (A001…, расчёт на листе ABC_анализ), инцидент с сортировкой и восстановление (буфер формул убран полностью — было 6000 строк, стало 225, новые товары добавляет только Claude), лист «Инструкция» (первая вкладка — структура, цвета, правила безопасной работы), различены цветом Цена/Скидка/Себестоимость, исправлен формат коэффициента CC2.

🚧 Ветка v2 начата 06.07.2026 (до получения обратной связи от Глеба — пользователь явно запросил старт, не дожидаясь встречи). Копия листа — «Дилеры Brodeks v2» (оригинальный пилот не тронут). Добавлено: ручная РРЦ канала (override цены на весь SKU сразу), горизонт плана расширен на месяц назад (с июля 2026 вместо августа), ручное «Шт» на каждый месяц (override количества), блок Итого расширен Себестоимостью/Прибылью, сравнительный блок «выручка/дельта прибыли до ручной РРЦ» для изоляции эффекта ручной правки цены. Подробности — Техническая_реализация_данных, раздел 8. Генератор — scripts/18_dealers_v2_price_override.py. - Попутно пересобрана методология ABC (лист ABC_анализ v2, генератор scripts/17_abc_analysis_v2.py): вместо одного ранга на бренд — 4 канала (Дил/B2B/Роз/МП — Ozon+Wildberries впервые подключены к ABC, хотя в сами планировщики каналов ещё не входят) × 2 разреза (внутри бренда / внутри канала) + общий AGT-ранг. «Дилеры Brodeks v2»: колонка ABC → ранг «в бренде» по каналу Дилеры, колонка Индекс ABC → общий AGT-ранг. - Лист «Все каналы_Глеб» создан 06.07.2026 — полная копия структуры «Дилеры Brodeks v2» (весь ФАКТ/цена/ПЛАН/Итого-блок), но на сумме продаж по ВСЕМ 4 каналам сразу и на всём универсуме 2887 SKU (не только Дилеры). Коэффициент скидки канала переопределён на 1.0 (нет единого дисконта для смеси каналов). Колонка ABC — всегда пусто, Индекс ABC — общий AGT-ранг. Генератор — scripts/19_vse_kanaly_gleb.py, подробности — Техническая_реализация_данных, раздел 8.6. - Лист «В2В» пересобран 06.07.2026 по тому же образцу (старый лист переименован в «В2В (архив, старая структура)», не удалён): 1234 SKU канала В2В, колонка ABC = B2B-ABC (в бренде), коэффициент скидки CC2 = 0.96 (эмпирическая оценка из факт.продаж за весь период — факт.выручка / выручка-по-РРЦ, частично закрывает открытый вопрос В2, не согласовано с Глебом). Буфер строк убран — учтён урок инцидента раздела 6.5 (без буфера сортировка через UI безопасна). Генератор — scripts/20_b2b_v2.py, подробности — Техническая_реализация_данных, раздел 10. - Лист «Розница+ИМ» пересобран 06.07.2026 по тому же образцу (старый — «Розница+ИМ (архив, старая структура)»): 2281 SKU, но ФАКТ-блок только по подразделению «Розница» (без «Интернет магазин», по прямому уточнению пользователя — отличается от логики «Роз» в ABC_анализ v2/Все каналы_Глеб, где Роз = Розница+ИМ суммарно). Коэффициент CC2 = 1.0 (согласовано, скидка 0%). Генератор — scripts/21_roznica_v2.py, подробности — Техническая_реализация_данных, раздел 11. - Лист «Маркетплейсы» создан 06.07.2026 (новый, старой версии не было): 1583 SKU, ФАКТ = Ozon+Wildberries суммарно, коэффициент CC2 = 0.5 (доля выручки компании, не дилерская скидка, см. 07_Справочники_классификаторы). Рентабельность заметно ниже остальных каналов (15,4%) — ожидаемо для модели «50% выручки». Открытый вопрос В3 (баллы Ozon) не решён. Генератор — scripts/22_marketpleisy_v2.py, подробности — Техническая_реализация_данных, раздел 12. - Итог: все 4 канала Глеба (Дилеры/В2В/Розница+ИМ/Маркетплейсы) теперь охвачены структурой v2 как отдельные планировщики. - Маркетплейсы разбиты на «Ozon» и «Wildberries» (06.07.2026) по прямому запросу пользователя, с условием не сломать сортировку/ранги на остальных листах: новые колонки для Ozon/WB добавлены СТРОГО в конец ABC_анализ v2 (R:W, после существующей Q), без вставки в середину диапазона — иначе сдвинулись бы номера колонок, на которые ссылаются VLOOKUP всех остальных листов. Старый «Маркетплейсы» → «Маркетплейсы (не используется, архив Ozon+WB)». Ozon — 1534 SKU (рентаб. 11,4%), Wildberries — 359 SKU (рентаб. 33,7%), коэффициент 0.5 у обоих (не разделён по площадкам). Генераторы — scripts/23_abc_v2_append_ozon_wb.py + scripts/24_ozon_wb_channels.py, подробности — Техническая_реализация_данных, раздел 13.

Задача 3.9: Обратная связь от Глеба по пилоту «Дилеры» — новая, без Г

  • Суть: Показать готовый пилот (лист «Дилеры Brodeks») Глебу, собрать замечания — по формату, логике, набору полей.
  • Далее, по итогам: решение о репликации структуры на «В2В»/«Розница+ИМ» и/или доработке текущего пилота.

✅ Встреча состоялась 06.07.2026 (Глеб + Константин Беляев + Женя + Алексей Баталов). Транскрипт — 260706-1_Встреча Глеба и РОПов по первой версии калькулятора маржинальности_Servis_ZAO, саммари — Саммари_встречи_06-07-2026, решения — 02_Решения, раздел «06.07.2026 (II)». - Подтверждено верным: приоритет ручного ввода (Шт вручную), галочки периода, механика дельты прибыли, методология «план = факт года назад × коэффициент», подход «категории по линейкам, не по размерам», разбивка МП на Ozon/Wildberries (обсуждали независимо в тот же день). - Важнейшее архитектурное решение: калькулятор — инструмент моделирования сценариев, НЕ источник данных для плана производства. Ручные правки никогда не должны напрямую уходить в ПП — нужна отдельная сущность «подтверждение планов» (см. новую задачу 3.11 ниже). - Контекст: калькулятор — «отчёт №1» из будущей системы Пожарского на 9 отчётов (план производства/платежи/факт/каналы продаж), не отдельный проект. - Дальнейшие шаги: обратная связь от РОПов сегодня вечером → повторная встреча впятером, финализация → передача Пожарскому на доработку дилерского канала как эталона → выкатка на остальные каналы. - Статус: обратная связь получена, задача закрыта; конкретные доработки — см. задачи 0.6, 3.10, 3.11 ниже и открытые вопросы В26–В29.

Задача 3.10: Точечные доработки калькулятора по итогам встречи 06.07.2026 — новая, без Г

  • Добавить «Дельту выручки» рядом с «Дельтой прибыли» в сравнительном блоке (сейчас показывается только дельта прибыли при ручной РРЦ).
  • Категория «Новинки» — отдельная классификация для новых товаров (действует первые ~6 мес после запуска). Критерий «когда товар перестаёт быть новинкой» ещё не разработан — нужно от Глеба/Баталова.
  • Проверить корректность себестоимости: что усредняется (курс валют на момент закупки, партийность), несколько артикулов (Алексей отметил «306», «210» и похожие) показались подозрительными по марже при визуальной проверке — перепроверить точечно.
  • Открытый вопрос: что добавить в лист «Все каналы_Глеб» для сравнения канала со средним по компании по каждой позиции (доля выручки? маржинальность? среднее количество штук?) — решения нет, склоняются к среднему количеству. См. В29.
  • Статус: не начато, ждёт приоритизации после финальной встречи впятером.

Задача 3.11: Отдельная сущность «Подтверждение планов» — новая, без Г

  • Суть: независимый от калькулятора маржинальности отчёт/сущность — сюда попадают ТОЛЬКО проверенные, утверждённые директором штуки (не сырые ручные корректировки из калькулятора). Дальше эти цифры автоматически выгружаются в план производства (ПП) Алексею Баталову.
  • Почему отдельно: явное решение встречи 06.07.2026 — калькулятор должен оставаться «безопасной песочницей» для моделирования (даже если кто-то поставит 2000 штук вместо 200 ради эксперимента, это не должно случайно уйти в производство).
  • Статус: не начато, следующий большой шаг после стабилизации калькулятора.

Блок 4: Контроль план/факт продаж

Задача 4.4: Аналитика план/факт продаж (Г4)

  • Суть: Дашборд план/факт по каналам (по отдельности и суммарно).
  • Функционал: Выбор периода, подсветка отклонений цветом в зависимости от % расхождения.
  • Детализация: До моделей (размеры не нужны).

Блок 5: Интеграция платежей

Задача 5.1: Повышение гигиены фин. планирования — связка ПП и графика платежей (Г1)

  • Проблема: Файл плана производства (ПП) напрямую не связан с прогнозом платежей в ДДС. Сейчас платежи (предоплата, фин. оплата, таможня, логистика) разносятся вручную в Google Документах.
  • Решение: Завести ПП в одну сущность с графиком платежей (на базе 1С или дашборда) или настроить синхронизацию Excel ПП с Excel графиком платежей.
  • Требование: Настроить форму/формулу для автоматического расчёта и разнесения платежей по пропорции и датам.