Цепочка документов

На отдельные позиции заказ-наряда 1С создаёт заказы на производство (по одному на изделие/работу), они уходят в профильный цех. Изготовление фиксируется Сборкой запасов, между складами/цехами — Перемещением запасов. Отгрузка и монтаж — через состояния заказа и поля строк, оплата работ — через Сдельный наряд.

Как документы связаны

Пример реального заказа

Заказ Зп0049 (сумма 405 144 ₽). Строка работы «Фундамент» = Фундамент (стандартный) 2.4*3.0*0.2, 32 400 ₽. Её материалы (через КлючСвязи): цемент 12 мешков, арматура д.8 пластик 109, сетка сварная 2. Так материалы «приклеиваются» к работам.

Структура заказ-наряда

Document_ЗаказПокупателя — главный документ. Три табличные части:

Товар vs работа

Надёжный признак — из какой табличной части строка: «Работы» → услуга, «Запасы» → товар. Поле ТипНоменклатуры обманчиво (например «Тротуарная плитка с монтажом» — по типу «Запас», но это работа).

Так же считает и «Аналитика»: ось строки берётся из табличной части документа (items.kind: service = «Работы», goods = «Запасы», см. classify.axis_for), а название — только источник категории. Поэтому «Тротуарная плитка с монтажом» — услуга (категория «Монтаж»), а «Тротуарная плитка на стяжку» — товар.

Категория «Монтаж» — это работы, включая комплекты «материал + монтаж» (плитка, бордюр): в 1С такие строки лежат в «Работах», поэтому их сумма входит в выручку услуг.

Размеры изделия

Размер площадки/камня — в текстовом поле Содержание: «длина*ширина*высота» в метрах. Вводится вручную и неструктурированно (запятые/точки/скобки вперемешку).

Состояния заказа

Catalog_СостоянияЗаказНарядов: Создан → … → Отгружен → На монтаже → Завершен. Плюс доп. реквизиты «Статус для бригадира» и «Статус для менеджера».

Три параллельных статуса: (1) формальный СостояниеЗаказа (в практике 6 значений), (2) статус для менеджера (73e5fb1b) — Передан/Принят/Жду уточнения, (3) статус для бригадира (60c23586) — Принят/На монтаже/Готов к выдаче. «Заказы на монтаже» считаются по (3), не по (1).

Проверка сходимости (правило сверки)

СуммаДокумента = Σ(Работы.Сумма) + Σ(Запасы.Сумма) — по строкам где Сумма>0. Проверено на живом заказе 00НФ-Б00571: работы 111 025 ₽ + запасы 62 000 ₽ = 173 025 ₽ = сумме документа, бьётся до рубля. Любое расхождение = потеряна вкладка или двойной счёт.

Выручка «Аналитики» — только по строкам, где «Вариант завершения» ≠ «Отменен» и заказ не «Удалён». Разбивка по состояниям — диагностическая: в неё входят и отменённые, и заказы с нулевой суммой, поэтому её итог больше выручки — страница показывает разницу отдельной строкой.

Ответ /api/data по умолчанию без разреза «Товары и услуги» (это половина ответа, страница берёт его из /api/compare); полный ответ — /api/data?full=1. Себестоимости в источнике нет, поэтому cost/margin/margin_pct приходят как null, а не нулями.

Начисления ЗП менеджерам — регистр, а не отчёт по продажам

Раздел «Начисления» читает регистр AccumulationRegister_ДомП_СуммыКНачислениюЗППоМенеджерам («(ДомП) Суммы к начислению ЗП по менеджерам»). Он пишется документами «Заказ покупателя» и по каждой записи держит вид: Receipt — текущая сумма заказа, Expense — уже начисленная сумма. Итог начисления = Receipt − Expense, то есть «сколько осталось начислить».

Проверено на живых данных: Receipt-часть за август 2026 совпала с выручкой «Аналитики» до рубля по каждому менеджеру (49 829 454 ₽), Expense-часть за сезон — с отчётом бухгалтера «кассы общие» (421 625 908 ₽), а за сентябрь 2026 — по каждому менеджеру (27 757 175 ₽). Поэтому выручку сверяют с отчётом «Заказ покупателя → Основные данные», а начисления — с этим регистром; путать их нельзя: регистр «застывает» на моменте начисления и не пересчитывается после правок заказов.

В регистре встречается служебное значение ответственного «В кассу не считать» — эти суммы в начисление из кассы не попадают. Ещё в 1С бывает разное написание ФИО одного человека (например, «Мухорин Виталий Владимирович» в заказах и «…Викторович» в начислении) — страница помечает такие строки значком «≠». Второй источник значка «≠» — свежий заказ: 1С пишет Receipt-записи при проведении документов, поэтому по заказам последних часов регистр немного отстаёт (обновляется автоматически).

Чтобы не считать вручную, в карточке «Начислено» показано второе число — «как в отчёте бухгалтера»: начислено по регистру плюс текущие суммы заказов по подразделениям, которые бухгалтер считает отдельно (АРТ Бетон и ПроКовка — в 1С по ним нет ни одной Expense-записи). Совпадает с её файлами до рубля: сентябрь 2026 — 28 510 749 ₽, сезон 2025/26 — 427 896 113 ₽.

Вторая вкладка раздела — «Заказы с изменениями»: по выбранному месяцу видно заказы, которые 1С относит к этому месяцу, их суммы в начислении и сейчас, и — построчно — правки сумм из журнала (было → стало, когда заметили). Логика начислений с июня 2025 накопительная, поэтому начисление месяца = заказы месяца + корректировка по прошлым месяцам; корректировка на странице считается как «начислено − заказы месяца». Построчно само начисление не разложить: в 1С записи начисления не привязаны к заказам. Журнал правок ведётся с сентября 2026.

Ещё один вид расхождения — значок «нет начисления»: у менеджера в регистре нет ни одной Expense-записи (начислений нет вовсе). Так по АРТ Бетону (Стрижко) и ПроКовке (Язов) — за все месяцы. В отчёте бухгалтера по этим подразделениям взяты текущие суммы заказов, поэтому её итог больше страницы ровно на них: за сентябрь 2026 — на 630 574 ₽ и 123 000 ₽ соответственно (в её файле 28 510 749 ₽ против 27 757 175 ₽ у нас, всё остальное совпадает по менеджерам).

КлючСвязи связывает товар ↔ работа

Поле КлючСвязи (тип Int64) парует строки вкладок: у каждой позиции «Запасы» есть своя строка «Работы» с тем же КлючСвязи. Пример: памятник (ш120*60*7, КС=1) ↔ «Монтаж памятника» (КС=1); цветник (КС=2) ↔ «Портрет гравировка» (КС=2). Самостоятельные работы (фундамент, плитка, бордюр, переустановки, демонтаж) — без пары в «Запасах». Материалы привязаны к работам тем же ключом.

Кратность — цена за единицу × объём

В строке «Работы» Цена × Кратность = Сумма. Кратность — объём/площадь: Фундамент 30 000 ₽ × 1.188 (м²) = 35 640 ₽; Тротуарная плитка 3 500 ₽ × 11.79 м² = 41 265 ₽; Бордюр 800 ₽ × 14.4 пог.м = 11 520 ₽. Размер площадки — в Содержание («3.3*3.6*0.10»).

Скидка 100% = включено в стоимость (бонус)

Позиции, входящие в комплект, получают ПроцентСкидкиНаценки=100 → Сумма=0. В примере цветники и тумба даны за 0 ₽ (входят в памятник), платят только памятник (58 500 ₽) и вазу (3 500 ₽). Такие строки не добавляют выручки — учитывать при анализе.

Типы фундамента

Спецификация «стандарт»

Базовый состав на 1 фундамент: Цемент (50 кг) + Арматура д.8 пластик + Лягушка + Сетка сварная. Формулы пустые — реальные количества считаются по размеру площадки.

Рецепты по размеру (медианы 2026)

Заказы на производство по цехам

Структура заказа на производство

• Продукция — что производим (Работа/Запас).
• Операции — тех. операции с нормами времени.
• СоставБригады — исполнители.
• СписокНоменклатуры — текстовая сводка.

Сборка и сдельная оплата

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

Кто и как оформляет (исправленные роли)

1. Менеджер оформляет заказ на производство из заказ-наряда: Ответственный_Key = тот же менеджер, что ведёт заказ; указывает цех (СтруктурнаяЕдиница_Key).
2. Начальник профильного цеха (каменного / малярного / сварочного / плиточного) принимает задачу и назначает исполнителя на операции (Операции.Исполнитель).
3. Бригада (работники + КТУ) назначается в СдельномНаряде → СоставБригады (в самом заказе на производство бригада пустая). Это оплата труда.

Состояния производства

Catalog_СостоянияЗаказовНаПроизводство — свой справочник (не как у заказ-наряда):

Создан → Передан → В производстве → (Сварено → Окрашено → Упаковано) → Готов → Завершен, плюс «Жду уточнений» и «В работе сварщика».

Привязка именно к цеху обязательна: Упаковано и Сварено изредка встречаются и в Каменном цехе, а для него признак готовности другой — подтверждённая приёмка камня.

Структура (вкладки, связка через КлючСвязи)

Продукция (что делаем) ↔ Операции (связь КлючСвязиПродукция → продукт) ↔ Запасы (материалы, ДомП_Продукция_Key). СоставБригады в самом заказе — пустая.

Пример: бордюр 288 шт (Плиточный цех)

Заказ 00НФ-004995: продукция = бордюр чёрный 288 шт (спец 99ab5f39, КС=55); 3 операции (все КлючСвязиПродукция=55); материалы — песок 460.8 + отсев 1152 + цемент 288 + пластификатор 1.44 + пигмент 4.32 + фибра 0.864. Сборка 00НФ-002721, сдельник 00НФ-011334 (8 640 ₽: 25×288=7 200 + 5×288=1 440).

Заказ → несколько производственных заказов (по цехам)

Один клиентский заказ-наряд порождает по одному производственному заказу на каждый задействованный цех, а не «одно изделие = один заказ». Проверено: заказ a6632ce4 → 3 производственных заказа (каменный + сварочный + малярный). Производственный заказ = вся работа одного цеха по данному заказу (все его изделия + операции + материалы).

Кросс-цеховая цепочка: Сварочный → Малярный (болванка → покраска)

Сварочный цех производит «БОЛВАНКИ» (металлические каркасы оградок/ножек/столбиков/флагштоков) → Малярный цех их красит (грунт + чёрная глянец RAL9005 + лак + антик МЕДЬ) → готовое ограждение. Это конвейер через склады.

«Продукция» = изделия + работы (услуги)

«Продукция» производственного заказа — это не только физические изделия, но и РАБОТЫ-услуги цеха. Пример монумента 00НФ-004681: 22 «продукта» = эпитафия-гравировка, выпил форм, портрет на КГ, ниша, макет, фрезеровка, лавка гранитная, металлопролёт — вся работа каменного цеха по объекту. У каждого продукта: Спецификация_Key (BOM), Характеристика_Key (вариант/размер), КлючСвязи, количество, ЗаказПокупателя_Key + КлючПродукцииЗаказ (трасса заказ → производство).

Как материал → изделие и операция → изделие (связки)

Неочевидные решения

• Материалы масштабируются рецептом, формулы скрыты. 540 плиток «Крокодил» → песок 1 382,4 кг + отсев 3 180,6 + цемент 1 922,4 + пластификатор 16,2 + пигмент красный 12,96 + чёрный 14,58 (тонны на партию). Кол-во считает 1С из BOM; через OData формулы не видны.
• Пигмент = цвет. «Красная» плитка = пигмент красный + чёрный (оттенок). Чёрные оградки = краска чёрная + лак + антик МЕДЬ (эффект старения).
• Операция-кол-во ≠ кол-во изделия. Лавка гранитная (1 шт) — а одна операция план=4 (обработка в своих единицах, напр. 4 грани).
• Нормочасы/НормаВремени = почти везде 0. Реальная трудоёмкость — в СдельномНаряде (Расценка × Факт). План — только «что и сколько».
• Промежуточные статусы — особенность цеха. У сварочного/малярного есть «В работе сварщика / Сварено / Окрашено / Упаковано»; у каменного/плиточного их нет.

Факт ↔ план (Сборка + Сдельный наряд)

Пример малярного заказа 00НФ-000003 (оградка №16 + углы):

• Сборка запасов 00НФ-000181 — списала болванки+краску, оприходовала окрашенные изделия.
• Сдельный наряд 00НФ-000556 (Ефимов, 1 010 ₽): углы — план/факт 4 × 100 ₽ = 400 ₽; оградка — 12,2 м × 50 ₽/м = 610 ₽.

Формула оплаты: Расценка × КоличествоФакт = Стоимость. Исполнитель — на каждой операции (СоставБригады пуст, если 1 сотрудник).

Шапка: к каким справочникам ведут поля

Положения реквизитов (где хранится значение): ПоложениеЗаказаПокупателя=ВТабличнойЧасти, ПоложениеСклада=ВТабличнойЧасти, ПоложениеИсполнителя=ВШапке, ПоложениеСтруктурнойЕдиницыОпераций=ВШапке.

Неочевидные механики (полная трассировка + журнал)

• КлючПродукцииЗаказ = LineNumber строки заказ-наряда. У каждого продукта производства — номер исходной строки клиентского заказа (эпитафия → строка 42, выпил → 30, пролет → 15…). Это трасса «какой продукт из какой строки заказа».
• Запасы.ДомП_Продукция_Key = Номенклатура_Key целевого изделия (в живух: «шнп105*60*3» → продукт «пролет из НП шанси»; «плитка» → «изделие из камня»). Дополнительно ДомП_Характеристика_Key и ДомП_Комментарий («пролет 800*30*3 — 3 шт, 670*30*3»).
• Операция ↔ продукт — через КлючСвязиПродукция (целое число), а материал ↔ продукт — через ДомП_Продукция_Key (guid номенклатуры). Разные механизмы.
• ДополнительныеРеквизиты = производственный журнал. В монументе — код состава («…фр+худспина+худлицо+худпрол3+вазаскант+…») и полная история: «принят 30.07 → в работе → макет → жду фото → 02.07 фото принесут… → 24.02 отпр.нов… → 21.07 принято». Ведёт цех.
• ТипНоменклатуры продукта = Работа или Запас — продукция бывает и услугой (гравировка/эпитафия).
• Исполнитель в шапке = 0000 — исполнители ставятся по операциям (цеховым). РесурсыПредприятия → Catalog_КлючевыеРесурсы (станки/оборудование).
• Нормочасы почти всегда 0 — только у «изделия из камня» Нв=1/Нч=1. Реальный труд — в сдельнике.

Перемещения

ПеремещениеЗапасов — между складами/цехами: База → филиал/цех. ЗаказНаПеремещение не используется. Так болванки/материалы попадают в цеховые склады («Склад <Цех> МАТЕРИАЛЫ»).

Резерв в заказ-наряде

Строка «Запасы»: Резерв (зарезервировано на складе под заказ, = кол-во), РезервОтгрузка (зарезервировано под отгрузку, = Резерв), СтруктурнаяЕдиницаРезерв_Key (склад — «Склад База»/склад филиала).

Отгрузка: флаг + состояние

Маркер отгрузки — Запасы.ДомП_Отгрузка (True = позиция отгружена) + смена СостояниеЗаказа:

Создан → … → Отгружен частично → Отгружен → На монтаже → Завершен

Частичная отгрузка = часть строк ДомП_Отгрузка=True, остальные False (напр. щебень/камень отгрузили, памятник ещё нет).

РасходнаяНакладная (28) — не привязана к заказу (поле Заказ пустое), только опт/розница. Основной поток отгрузки документ не создаёт — только флаг+состояние.

Резерв в производстве

Продукция.Резерв = 0 (изделия ещё не готовы, на складе не резервируются). Запасы.Резерв (материалы) = полному кол-ву на складе — материалы зарезервированы под производство.

Регистры — источник истины по резервам/остаткам

ПотребностьВЗапасах — перекрестие заказ↔производство↔склад: лучшее место для «сколько материала под резервом сейчас».

Склад — раздел «Склад» в дашборде

Раздел показывает остатки по складам, движение, расход, потери и дефицит материалов. Данные кладутся отдельным синком регистров и не смешиваются с заказ-нарядами.

Потребность к отгрузке берётся так: ДомП_КоличествоКОтрузке, если оно больше нуля, иначе Количество. Так не завышается потребность у частично отгруженных заказов.

Правила формирования

1. Один клиентский заказ = один заказ-наряд (товары + работы + материалы).
2. Материалы привязаны к работе через КлючСвязи.
3. Каждое изделие/работа → свой заказ на производство в профильный цех.
4. Фундамент — монтажная работа, норма материалов зависит от размера.
5. Отгрузка — через состояния заказа и поля строк.

Подводные камни

Источники истины

Кто участвует

Четыре роли: менеджер (создаёт и наполняет заказ-наряд), начальник цеха (принимает задачу по своему цеху и назначает исполнителей на операции), бригадир (монтаж), кладовщик (отгрузка, перемещения, склад). Плюс общий жизненный цикл состояний.

Шапка заказа

👤 Менеджер — что заполняет

1. Товары (Запасы), Работы (со спецификацией/характеристикой/размером), Материалы (из спецификации).
2. Доп. реквизиты: кладбище, ФИО усопшего, контакт, платежи/рассрочка, действия с демонтированным, планируемая дата.
3. Статус для менеджера → «Передан».

👷 Бригадир — монтаж

Смотрит: назначенный бригадир, комментарий/график, примечания, действия с демонтированным.

Заполняет: статус бригадира («Принят» → «На монтаже» → «Готов к выдаче»), дату монтажа, сдельный наряд.

📦 Кладовщик — отгрузка

Сверяет: резерв, резерв-отгрузку, количество к отгрузке. Отгружает: флаг ДомП_Отгрузка в строках «Запасы» (дату ДатаОтгрузки не заполняет — см. «Подводные камни», реальная дата отгрузки = ДатаИзменения заказа). Перемещает между складами. Переводит состояние в «Отгружен».

Закрытие заказа

Создан → Жду уточнения → Передан → На монтаже → Готов к выдаче → Перемещен → Отгружен → Готов и принят бригадиром → Готов и принят заказчиком → Завершен.

Завершен — финал (после отгрузки, монтажа, принятия заказчиком, расчёта). АртБетон — упрощённо: Создан → Отгружен → Завершен.

Шапка заказ-наряда (вкладка «Главное»)

Табличные части (27) — что используется

Оплата (Предоплата)

СуммаПлатежа, СуммаРасчетов, ОплатаБонусами, ОплатаСертификатом. График рассрочки — текстом в доп. реквизите. ПлатежныйКалендарь не используется — так и задумано.

Специалисты: художник, керамист и др.

6 ролей: художник, керамист, монтажник, пильщик, фрезеровщик, сварщик/маляр. У каждой — флаг на номенклатуре (КСА_Художник…) и поле эскиза в шапке (КСА_ЭскизХудожник…).

Доп. реквизиты — полная карта

Анализ камня — что это простыми словами

Раздел «Анализ камней» отвечает на один вопрос: что и сколько докупить, чтобы хватило камня и комплектов (тумб и цветников) под то, что уже продано и зарезервировано. Данные берутся из 1С и обновляются сами — открывать 1С для этого не нужно.

Что означает каждая цифра и откуда она

Комплекты: как подбираются тумбы и цветники

• На каждый камень нужен один комплект: тумба + цветник.
• Кто кому подходит берётся из 1С — регистр «Сопутствующие товары» (в карточке камня список сопутствующих).
• Основная тумба — самая маленькая из подходящих, ширина которой не меньше ширины камня (камень должен встать). Основной цветник — ближайший по длине камня.
• Если в 1С связей нет — позиция подбирается по правилу в том же материале (в таблице помечено «по правилу»).
• Замена — ближайший больший размер того же материала: большую тумбу или цветник можно подрезать, меньшую — нет. Свободный остаток замены сначала закрывает её собственную потребность, а остаток распределяется по дефицитам — поэтому пишем «закроет 12 из 46», а не «есть 60».
• Варианты замены (в том числе из 1С) видны в колонке «Замена» и в раскрытой строке группы.

Можно править «докупить» руками

На вкладке «Заказ» число в колонке «докупить» — редактируемое. Решили закупить больше или меньше — впишите своё значение и нажмите Enter.

• Правка сохраняется в базе и видна всем, кто открывает дашборд; переживает перезапуск.
• Потребность в тумбах и цветниках пересчитывается сразу: на каждый камень нужен комплект, поэтому формула такая: потребность комплектов = max(расход, докупить + свободный остаток). Купили «в запас» — комплектов тоже нужно больше, и сразу видно, хватит ли их.
• Меньше расхода потребность не опускается: те камни всё равно уйдут клиентам, комплекты под них нужны.
• Правленое число подсвечено синим, рядом ✕ — вернуть расчёт, кнопка «Сбросить правки закупки» — сбросить все.

Когда обновляются данные

Дашборд сам забирает данные из 1С по расписанию (настраивается в «Настройки → Синхронизация», там же кнопка «Запустить сейчас»):

В шапке раздела есть подпись «данные: заказы … · склад … · движения …» — это реальная давность каждой части; если что-то отстало от расписания, оно подсвечивается.

Чего в расчёте нет — чтобы не удивляться

• Камень, ушедший в изделие («изделие из камня»), считается в колонке «В сборке», а не в «Продано»: продано само изделие, а камень — его составляющая. Если посчитать и там и там, будет задвоение.
• «Продано» — по дате продажи, а не по дате заказа: заказ, оформленный в одном месяце, а отгруженный в другом, попадёт в месяц отгрузки.
• У складских движений нет привязки к заказу, поэтому нельзя сказать «эта сборка — под заказ №…»; видно только объём.
• Заказы, у которых состояние удалено в 1С, не считаются активными (в работе, в долгах, в сроке), но их резерв, если он ещё живой, учитывается.
• Отрицательные итоги по заказу (сняли больше, чем ставили — правка) в резерв не берутся: так же считает 1С.

Техническая документация для агента-разработчика

Источники данных и синхронизация

Чтение 1С — только GET по OData: https://1c.dp-cloud.ru/unf/odata/standard.odata, учётка «Чтение» (read-only), AUTH_HEADER = Basic base64(USER:PASS). Загрузка регистров — pull_register_lines(entity): берёт Recorder,RecordSet, листает $top=1000&$skip, пропускает записи Active is False. Документы — page_orders()/_odata(), отбор Posted eq true and DeletionMark eq false.

Расписание описано в SYNC_SECTIONS (интервал по умолчанию, минимум, варианты, «сколько идёт»), метки — в SYNC_META, ручной запуск — SYNC_RUNNERS + /api/sync/run. Циклы (reg_loop, warm_loop, stock_deep_loop, staff_loop, nc_loop) раз в минуту проверяют _sync_due(key); интервалы читаются из таблицы sync_settings (кэш 5 с), поэтому смена интервала действует без перезапуска.

Особенности OData 1С (проверено)

• Фильтры на регистрах не работают: $filter=Номенклатура_Key eq … → HTTP 400. Тянем регистр целиком и фильтруем локально.
• $orderby на регистрах/документах ненадёжен — не полагаться.
• Табличные части читаются навигацией: Document_ЗаказПокупателя(guid'…')/Запасы. В строках ТЧ заказов поле номенклатуры называется Номенклатура, в регистрах — Номенклатура_Key.
• У документов отбор Posted eq true and DeletionMark eq false; учётка read-only, запись в 1С невозможна.

Как считаются цифры в коде

Всё для вкладок «Камни/Тумбы/Цветники» считает build_stones(from_d, to_d, group, pick, plan, only_pick, drop_alts) в app.py:

• Продано — SUM(qty), SUM(amount) FROM stock_sales WHERE d BETWEEN from_d AND to_d (по дате продажи). Если таблица пуста (первый запуск) — запасной путь: закрытые заказы (Завершен/Отгружен) по дате заказа.
• Зарезервировано — «Резерв» строк заказов по живым заказам (см. ниже), иначе запасной путь: строки открытых заказов.
• Остаток по всем складам — SUM(qty) FROM stock (все склады, База + витрины). Отдельно остаток по «Склад База» и по витринам — для расшифровки.
• Потребность производства — stock_prod_need.need (регистр ПотребностьВЗапасах: Receipt − Expense, только положительные).
• В сборке — по stock_move с rec_type='СборкаЗапасов' за период: SUM(exp) − SUM(recv) по всем складам (изделия собирают и в цехах). Расшифровка по документам — таблицы stock_asm_move, stock_asm_doc, stock_asm_prod, stock_asm_line (см. панель «Модалка „В сборке (в изделия)“»): они собираются из тех же строк регистра, поэтому сумма в модалке совпадает с колонкой.
• Обороты склада (расшифровка) — stock_move только по «Склад База»: остаток на начало (d < from), приход, расход.

Формулы (build_stones):

• res_all = reserved + prod_need — колонка «Зарезервировано»;
• free = stock_all − reserved − prod_need — «Свободно»;
• need_buy = max(0, sold + reserved + prod_need − free) — «К закупке» (объём периода минус свободный остаток);
• total = sold + res_all + in_assembly — «Всего» (считается на клиенте);
• покрытие спроса cov = min(100, round(free / (sold + res_all) · 100)) — процент рядом с «Свободно».

Группы номенклатуры

Группа определяется по папке в дереве номенклатуры: _group_map(c, folder_names) поднимается по parent_key и ищет точное совпадение имени папки. Наборы имён: STELE_FOLDER_NAMES («стелы», «стеллы», «стэлы», «стэлы, нп»…), TUMBA_FOLDER_NAMES («тумба», «тумбы»), CVETNIK_FOLDER_NAMES («цветник», «цветники», «цветники мрамор», «цветники, заглушки»). Метаданные групп — STONE_GROUPS (title, word, search, about). Размеры из названия — _nm_nums(name) (L, W, T), материал и вид — _nomen_kinds(c).

Модалка «В сборке (в изделия)»: документы сборки

В раскрытии камня строка «В сборке (в изделия)» кликабельна: asmOpen(key) → GET /api/stones/asm → asmRender(). По каждому документу видно дату, номер и вид операции, склад, заказ покупателя (номер, дата, статус), заказ на производство (номер, дата, цех) и что собрали (ТЧ «Продукция»).

Особенности: период берётся тот же, что у таблицы (STONES.from/to), поэтому в подвале модалки видно «✓ совпадает» или «⚠ расхождение» с колонкой. Показываются последние 500 документов. У 1 120 документов из 4 950 заказа покупателя нет (массовая сборка) — пишем «без заказа». У изделий-приёмников нетто отрицательное (они не расходуются, а появляются); в группу камней такие позиции не входят.

Синк: sync_assembly() вызывается в разделе registers сразу после sync_stock() (метка last_asm_sync, ~26 с на прогон, 53 тыс. движений). Грабли: фильтр регистра по типу регистратора работает, а по Period — нет («Сегмент пути Period не найден»); $orderby=Ref_Key обязателен, иначе 1С теряет строки при постраничной выгрузке.

План комплектов: /api/plan

1. _related_map(c) — stock_related: камень → сопутствующие (тумбы/цветники) из 1С.
2. _pick_weights(c, pick, from_d, to_d) — «расход» каждого камня = продано (из stock_sales) + резерв + производство.
3. build_stones(..., "stele", pick, plan={"rows":{},"by_kind":{}}) — берём свободный остаток камней (нужен для учёта решений о закупке).
4. _eff_need(weights, free_by, buy_plan) — потребность с учётом правок «докупить»: calc = max(0, расход − свободно), buy = buy_plan или calc, eff = max(расход, buy + свободно).
5. _build_plan(pick, kinds, related, eff) — по каждому камню основная тумба (минимальная подходящая по ширине) и цветник (ближайший по длине); остальные связи — «альтернативы», ближайший больший размер того же материала — «замена»; копится for_qty (разбивка потребности по камням).
6. api_plan — собирает items (роли «нужно»/«альтернатива»/«замена»), распределяет свободный остаток альтернатив по дефицитам (сначала больший дефицит, с уменьшением cap, чтобы один остаток не пообещать дважды) → поля can / covers / why / own_need / own_deficit / own_for; считает totals и fresh.
7. api_stones вызывает build_stones(..., drop_alts=True) — на вкладках тумб и цветников строки-«альтернативы» не показываются, остаются «нужно» и «замена».

Резерв: «В резерв» строк заказов по живым заказам

Резерв — это поле Резерв строки заказа (колонка «В резерв» в карточке), но только по живым заказам: строка хранит резерв годами и после закрытия заказа, поэтому без фильтра резерв раздувается (по шц50*7*5 — 256 вместо 6). Две таблицы: order_reserve(order_ref, product_key, qty) — резерв строк (пишет синк заказов: инкрементально по изменившимся, полная сверка целиком); order_ordered(order_ref, product_key, qty) — незакрытое заказанное количество из регистра «Заказы покупателей» (пишет sync_order_ordered() в цикле регистров). Резерв по позиции = SUM(MIN(ordered, reserve)) по пересечению — считается на чтении в reports/stones.py, поле orders = число живых заказов.

Проверка: шц50*7*5 → резерв 6 (Г01193 1 + Нк0290 1 + Ж00045 4, заказ Ю00258 без резерва), «Свободно» = 7 − 6 = 1 — совпадает с панелью номенклатуры 1С. Старый способ (сумма заказанного по регистру) давал 11 и «Свободно» −4: он считал необеспеченные заказы резервом.

Продажи: sync_sales()

Регистр Продажи → stock_sales(product_key, d, qty, amount) (агрегация по позиции и дате, ~37,5 тыс. строк, прогон ≈2 мин). Проверка: ш120*60*7 за 01.11.2025–21.09.2026 → 283 шт / 14 631 533 ₽, ровно как в отчёте «Продажи по номенклатуре». По группе «Камни» 3198 шт против 3201 шт фактических отгрузок по движениям склада — задвоения нет.

Правки «докупить»: /api/plan/buy

GET — текущие правки; POST {"key": "…", "qty": 25} — поставить, qty: null — вернуть расчёт, {"items":[…]} — пачкой, {"reset": true} — сбросить все. Хранение — stone_buy_plan(product_key, qty, updated_at, updated_by). На клиенте правка применяется мгновенно (локальный пересчёт), затем сохраняется в базу и обновляет план (stonesLoad()), чтобы пересчитались вердикты замен.

API страницы

Авторизация: @app.before_request требует сессию для всех /api/*, кроме логина; раздел определяется по префиксу пути (API_SECTION): /api/stones, /api/plan* → раздел stones.

Фронтенд: где что лежит

• Состояние: STONES_GROUP (вкладка), STONES_PICK (отмеченные камни, localStorage dsh_pick_stones), PLANN_* (данные, режим группировки, раскрытые строки), PLANN_BUY (текущие правки «докупить»).
• renderStones() — таблица вкладок Камни/Тумбы/Цветники: сортировка (dpTh/dpSortRows), группы по материалам, «+»-кнопки, раскрытие строки с тремя мини-таблицами (Склад База · витрины · итог по камню), колонка «В сборке».
• renderPlanNew() — вкладка «Заказ»: KPI, группы по тумбам/цветникам, «чем заменить», правка «докупить» (attachBuy, applyBuy, saveBuy, refreshZone), локальный пересчёт потребности (EFF, needPos).
• stonesSetAge()/stonesFresh() — подпись «данные: …» с реальной давностью разделов (orders/registers/stock) и подсветкой опоздавших.
• Стили раздела — блок #sec-stones ... в <style> (палитра секции #sec-stones{--an-*}, таблицы table.t-stones и table.stnp-t).

Грабли, на которые уже наступали

Как сверять с 1С (рецепты)

Диагностика в интерфейсе: подсказка к «Зарезервировано» показывает разбивку «по заказам покупателей N + в производство M»; подпись «данные: …» — давность каждой части; если расходится остаток, а не резерв, смотрите время последней выгрузки складского раздела (часовая).

Журнал решений 21–22.09.2026

Что осталось за рамками

• План считает комплекты только под выбранные камни; потребность комплектов под собранные изделия (в сборочных документах вместе с камнем списываются и цветники) не считается — изделие это отдельная позиция номенклатуры.
• У складских движений нет привязки к заказу: объём «в сборку» виден, а «под какой заказ» — нет.
• Расхождения по остатку возможны только из-за давности выгрузки (склад — раз в час). Если нужно чаще — интервал меняется в «Настройках → Синхронизация».