Склад и снабжение
Движение запасов, расчёт потребности и покрытие дефицита.
Назначение
Группа меню Склад отвечает за весь материальный контур: сколько чего есть на складе и где именно (партии, ячейки хранения), движение материала внутрь/наружу/между местами хранения (приход, расход, перемещение, инвентаризация, списание отхода), закупку у поставщиков (заявка → заказ → поступление) и расчётные экраны, которые говорят, чего не хватает и сколько нужно докупить/изготовить (MRP, Обеспеченность). Отдельно — лимитно-заборные карты (многократный отпуск материала цеху в пределах лимита без отдельной накладной на каждую выдачу).
Пять пунктов меню группы: MRP, Обеспеченность, Склад (сам по себе — 10 вложенных вкладок), Лимитно-заборные карты, Поступления.
Кто использует (роли)
- Кладовщик — основной пользователь всей фазы: MRP, Обеспеченность, Склад (все вкладки), Лимитно-заборные карты, Поступления.
- Снабженец — закупочная часть: Обеспеченность, Поступления, плюс
просмотр Заказов (производственных, не путать с Заказами поставщику —
те живут на вкладке Склада под тем же правом
provision.view, что и Обеспеченность). - Мастер участка и Диспетчер — видят и используют Обеспеченность (просмотр + управление), чтобы проверить, хватит ли материала на свои заказы, и создать из дефицита заявку/заказ.
- Администратор — все права, плюс два места этой фазы, где
недостаточно просто права на раздел:
- Прямая корректировка остатка («Складской журнал», причина
«Корректировка») — доступна только
operator.is_admin(проверка по флагу, не по слагу права) и требует обязательного основания. Кладовщик без прав администратора для той же цели идёт на вкладку «Инвентаризация». - Деловой отход и списание — единственный экран приложения,
открытый по любому из двух прав:
warehouse.viewИЛИqc.write. Мастер участка/кладовщик списывают обычный производственный отход по первому праву, Контролёр ОТК — брак/доработку по второму; ни одна роль по отдельности не покрывает оба случая.
- Прямая корректировка остатка («Складской журнал», причина
«Корректировка») — доступна только
Основные понятия
| Термин | Значение |
|---|---|
| Складское движение (StockMovement) | Неизменяемая запись в журнале: номенклатура, знак и величина изменения (delta), причина (приход/расход/корректировка/возврат/перемещение), дата, основание, опционально ячейка/партия/цена. Источник истины остатка; Part.stock_qty — материализованный кэш поверх него |
| Партия (Batch) | Лот материала, создаётся только при проведении приходной накладной: номер, количество, цена, дата поступления, сертификат, учётная группа. Остаток партии всегда пересчитывается на лету суммой движений с этим batch_id |
| Метод списания (FIFO / LIFO / SELECT) | Общая для склада настройка, как расход выбирает партию: FIFO — сначала самые старые партии, LIFO — сначала самые новые, SELECT («партия вручную») — партию для каждой строки выбирает оператор. Настраивается на вкладке «Расход» |
| Ячейка хранения | Дерево физических мест (склад → стеллаж → полка → ячейка). Не отдельный регистр остатков — просто фильтр/группировка по тому же журналу движений (cell_id) |
| Приходная / расходная накладная | Документ «черновик → строки → Провести»: строки — чистые данные, реальные складские движения (и для прихода — партии) возникают только при проведении |
| Заявка на закупку / Заказ поставщику | Двухступенчатая закупка: заявка (черновик → утверждена → «Создать заказ…») превращается в заказ поставщику; заказ поставщику можно завести и напрямую, минуя заявку — для рутинных закупок без согласования |
| Уведомление о поступлении | Факт «материал физически привезли» отдельно от факта «остаток оприходован»: «Оприходовать» создаёт приходное складское движение |
| Лимитно-заборная карта (ЛЗК) | Документ на многократный отпуск одной номенклатуры одному подразделению в пределах лимита за период; выданное количество — сумма движений с ref = id карты |
| Обеспеченность | Сопоставление чистой потребности (та же BOM-математика, что и MRP) с остатком, производством, заказами, минимальным резервом и коэффициентом потерь; баланс = наличие − потребность×коэф.потерь − мин.резерв |
| Учётная группа (StockOwnershipGroup) | Метка на партии/движении для раздельного учёта одинаковых ТМЦ по разным договорам/проектам в рамках одного склада — реализована на уровне API, экрана в интерфейсе пока нет (см. «Особенности» ниже) |
Склад
Раздел /warehouse, право warehouse.view. Технически — не одна страница,
а вложенный dockview с 10 независимо перетаскиваемыми панелями, которые
открываются сразу все при первом входе: Складской журнал, Заказы
поставщику, Заявки на закупку, Адресация, Приход, Расход,
Перемещение, Обороты, Инвентаризация, Деловой отход. Любую
панель можно перетащить в отдельное окно, закрыть, переоткрыть — как и с
окнами верхнего уровня (см. Начало работы).
В отличие от legacy VOGBIT (support/4158), в этой версии нет печати готовых бланков документов (приходный ордер, расходная накладная и т.п.) — только выгрузка в Excel там, где она вообще есть (вкладка «Обороты», экран «Обеспеченность»).
Складской журнал
Что видно
Единая таблица всех складских движений: Дата / Номенклатура / Тип / Изменение / Цена за ед. / Сумма / Основание, с фильтром по столбцам. У строк расхода моложе срока возврата — кнопка «Вернуть». Внизу — форма быстрого добавления движения: номенклатура, тип (Приход / Расход / «Корректировка (админ)» — последний вариант виден только администратору), количество, цена за ед. (только для приходов), основание.
Типовые сценарии
- Кладовщик быстро фиксирует приход или расход без оформления полноценной накладной — например, канцелярские мелочи или разовую операцию.
- Возврат ошибочно списанного расхода: кнопка «Вернуть» показывается только на движениях расхода не старше срока возврата (по умолчанию 3 дня, настраивается на вкладке «Расход»); вводимое количество не может превышать ещё не возвращённый остаток по этому движению.
- Администратор корректирует расхождение вручную с обязательным основанием — единственный путь для прямой корректировки без документа-основания.
Особенности и ограничения
- Прямая корректировка (
reason=adjustment) требуетoperator.is_adminи непустого основания — сервер отклонит запрос иначе (403/422). - Цена прихода, если не введена вручную, автоматически подставляется из
текущей действующей цены номенклатуры (
PriceRecord— тот же прайс-лист, который поддерживается в Прайс-калькуляторе, Себестоимость и цены). - Возврат наследует ячейку/партию/цену исходного расходного движения — переопределить их нельзя.
- Список показывает последние 200 движений без постраничной навигации; для сводки за период — вкладка «Обороты».
Приход
Что видно
Слева — список приходных накладных (Накладная / Поставщик / Дата / Статус). Справа — строки выбранной накладной: Номенклатура / Кол-во / Ед. / Кол-во (баз. ед.) / Цена за ед. / Ячейка / Партия, с удалением строки, пока накладная в черновике. Форма создания накладной: Поставщик, № накладной, Дата. Форма добавления строки (только в черновике): номенклатура, кол-во, единица измерения (пусто = базовая единица номенклатуры), цена за ед., ячейка, номер партии, сертификат. Кнопка «Провести» — только для черновика с хотя бы одной строкой.
Типовые сценарии
- Кладовщик заводит накладную на поступившую от поставщика партию, построчно вводит позиции с ценой, сертификатом и номером партии, проводит — на каждую строку создаются партия (Batch) и приходное складское движение.
- Ошибочную строку можно удалить, пока накладная в черновике; после проведения накладная и её строки неизменны.
Особенности и ограничения
- Проведение необратимо в интерфейсе — кнопки отмены/сторно проведённой накладной нет.
- Если строка указывает единицу измерения, отличную от базовой, а коэффициент пересчёта (Справочники → Коэффициенты, Справочники и доступ) для этой пары единиц не заведён — проведение падает с ошибкой; строку нужно поправить.
- Номер партии, если не указан, генерируется автоматически (первые 8 символов id строки).
Расход
Что видно
В шапке — две настройки, общие для всего склада (не только этой вкладки): метод списания (FIFO / LIFO / «Партия вручную (SELECT)») и срок возврата в днях. Ниже — список расходных накладных (Основание / Подразделение / Статус) и строки выбранной: Номенклатура / Заявлено / Ед. / К выдаче (баз. ед.) / К выдаче (редактируемое поле, пока накладная в черновике) / Ячейка / Партия. Форма новой накладной: Основание (заявка/наряд), Подразделение. Форма строки: номенклатура, количество, единица, ячейка, партия (поле обязательно и появляется, только если метод списания — SELECT).
Типовые сценарии
- Кладовщик заводит расходную накладную по заявке цеха или наряду, вводит запрошенное количество, при необходимости правит «К выдаче» на фактически выдаваемое (частичная выдача — это правка поля до проведения, а не серия отдельных частичных проводок), проводит.
- При методе SELECT оператор явно выбирает партию для каждой строки; при FIFO/LIFO система сама разносит списание по открытым партиям, при необходимости — сразу по нескольким.
Особенности и ограничения
- «К выдаче» по умолчанию равно «Заявлено», редактируется только в черновике.
- Метод списания и срок возврата, изменённые здесь, действуют сразу и на «Складском журнале», и на диалоге быстрого расхода («Адресация»), и на «Перемещении».
Перемещение
Что видно
Список перемещений (Откуда / Куда / Статус; для статуса «В пути» — кнопка «Принять»). Строки: Номенклатура / Кол-во / Ед. / Кол-во (баз. ед.) / Партия. Форма создания: выбор ячейки «Откуда» и «Куда», комментарий. Форма строки — как на «Расходе» (плюс партия при методе SELECT). Две кнопки проведения: «Передать» и «Выдать».
Типовые сценарии
- Перемещение в пределах одного контролируемого кладовщиком участка —
«Передать» проводит сразу обе стороны (
draft → completed). - Передача между подразделениями/складами с разными ответственными —
«Выдать» проводит только расходную часть (
draft → pending); принимающая сторона позже жмёт «Принять» в общем списке (pending → accepted).
Особенности и ограничения
Отдельной сущности «Склад-получатель»/«Склад-отправитель» на этом экране нет — «откуда»/«куда» всегда ячейки хранения, а не склады целиком.
Обороты
Что видно
Период «С» / «По» (по умолчанию — с начала месяца по сегодня), кнопка «Показать», кнопка «Выгрузить в Excel» (активна после построения отчёта). Таблица по номенклатуре: Остаток на начало / Приход / Расход / Возврат / Перемещение / Корректировка / Остаток на конец / Сумма на конец.
Типовые сценарии
Сверка на конец периода: кладовщик или экономист строит отчёт за месяц, проверяет остатки на начало/конец, выгружает в Excel для архива или бухгалтерии.
Особенности и ограничения
Отчёт считается «на лету» по журналу движений при каждом «Показать» — отдельной хранимой таблицы оборотов нет; скорость зависит от объёма всего журнала движений за всё время (журнал читается целиком, затем фильтруется по датам).
Адресация
Что видно
Слева — дерево ячеек хранения (Код / Наименование / Родитель) и форма добавления ячейки (Код, Наименование, Родитель). Справа, после выбора ячейки, — остатки в ней: чекбоксы + Номенклатура / Кол-во, кнопка «Расход (N)» по отмеченным строкам и форма быстрого перемещения (номенклатура + количество со знаком «+приход / −расход», кнопка «Переместить»).
Типовые сценарии
- Кладовщик заводит иерархию мест хранения: склад → стеллаж → полка → ячейка.
- Быстрый расход прямо с полки: отмечает несколько позиций галочками, «Расход (N)» открывает диалог быстрого расхода (см. ниже).
- Ручное «+приход / −расход» на конкретной ячейке — обычное складское
движение с этим
cell_id.
Особенности и ограничения
- Остатки ячейки — не отдельный регистр, а разбивка журнала движений по
cell_id; «что лежит на полке» всегда пересчитывается заново, а не читается из готовой таблицы. - На уровне API есть отдельная сущность «Склад» (
Warehouse) с деревом ячеек, привязанных к ней специальной связью (не через обычную вложенность ячеек друг в друга) — но форма создания ячейки на этой вкладке не даёт выбрать/создатьWarehouse. Все ячейки, заведённые отсюда, остаются без привязки к какому-либо складу-контейнеру; это переходное состояние миграции.
Диалог быстрого расхода
Появляется по кнопке «Расход (N)»: таблица отмеченных позиций (количество — не больше остатка на ячейке; партия — только при методе SELECT), поля Получатель (подразделение), Работник, Тип связи, Комментарий, кнопка «Выдать». При FIFO/LIFO партия для проведения выбирается автоматически; диалог создаёт и сразу проводит расходную накладную одним вызовом — без промежуточного черновика.
Заказы поставщику
Что видно
Таблица заказов: Номенклатура (1-я строка) / Кол-во (1-я строка) / Поставщик / Ожидается / Статус, кнопка «Строки» (открывает модальное окно с полным списком строк заказа) и кнопки перехода статуса («→ Получен», «→ Отменён»). Форма создания: номенклатура, количество, ожидаемая дата, поставщик (выбор из справочника или «+ новый поставщик…» с полем названия прямо в форме).
Типовые сценарии
- Кладовщик или снабженец заводит заказ напрямую поставщику для рутинной закупки, минуя согласование через заявку.
- При фактическом получении товара — переводит статус в «Получен»: на каждую строку заказа система проводит настоящую приходную накладную (со своими партиями), а не просто одно складское движение.
Особенности и ограничения
Колонки «Номенклатура/Кол-во (1-я строка)» показывают только первую строку заказа — заголовок дублирует данные первой строки по историческим причинам (заказ раньше был всегда однострочным). У многострочного заказа (например, конвертированного из заявки с несколькими позициями) остальные строки видны только через «Строки».
Заявки на закупку
Что видно
Список заявок (Основание / Статус, кнопки перехода «→ Утверждена», «→ Отклонена», «→ Отменена»; для утверждённых — «Создать заказ…»). Строки выбранной заявки: Номенклатура / Кол-во / Нужно к. Форма создания заявки (Основание) и форма добавления строки (номенклатура, количество, срок «Нужно к»).
Типовые сценарии
- Заявка создаётся в черновике, наполняется строками, утверждается.
- Утверждённая заявка конвертируется в заказ поставщику диалогом «Создать заказ…» (выбор существующего поставщика или ввод нового) — заявка переходит в статус «Заказана», создаётся реальный заказ поставщику со всеми строками заявки.
Особенности и ограничения
Прямой переход заявки в статус «Заказана» заблокирован на уровне API —
только через действие «Создать заказ…» (/convert), чтобы нельзя было
пометить заявку заказанной, не создав фактический заказ поставщику.
Инвентаризация
Что видно
Список инвентаризаций (Комментарий / Создана / Статус; для черновика — кнопки «Провести» и «Отменить»). Строки: Номенклатура / Ячейка / Учтено факт. / По журналу / Отклонение. Форма строки: номенклатура, партия (или «Не найдена (новая партия)»), ячейка, учтено фактически.
Типовые сценарии
Кладовщик пересчитывает фактический остаток и вводит по каждой позиции фактическое количество — «По журналу» и «Отклонение» считаются и показываются сразу, ещё до проведения (превью, ничего не сохраняется). «Провести» пишет по каждой строке компенсирующее складское движение, которое подгоняет системный остаток под факт.
Особенности и ограничения
После проведения «Отклонение» у строки закономерно показывает величину, близкую к нулю — коррекция уже применена и системный остаток сравнялся с учтённым; это ожидаемое поведение, а не ошибка.
Деловой отход и списание
Что видно
Таблица (Номенклатура отхода / Вид / Источник / Кол-во / Причина / Статус; для проведённых — кнопка «Отменить»). Форма: тип источника («Операция заказа» / «Заказ на доработку») с текстовым полем ID источника, номенклатура и партия-источник, номенклатура отхода, вид («Оприходовать (деловой отход)» / «Списать безвозвратно»), количество, причина.
Типовые сценарии
- Оприходовать деловой отход (например, обрезки материала) — создаётся и сразу проводится приходная накладная на номенклатуру отхода (новая партия), остаток исходной партии не меняется.
- Списать безвозвратно брак/потери — создаётся и сразу проводится расходная накладная с исходной партии-источника.
Особенности и ограничения
- Единственный экран приложения, открытый по любому из двух прав
(
warehouse.viewИЛИqc.write) — см. «Кто использует» выше. - Поле «ID операции»/«ID заказа на доработку» — обычный текст без выпадающего поиска: готового picker для этих объектов пока нет, id нужно знать заранее (например, скопировать из уже открытой карточки).
- Создание и проведение — один шаг, черновика нет; отменить можно только уже проведённую запись целиком.
Учётные группы (контрактный учёт — пока только API)
В коде полностью реализован механизм раздельного учёта одинаковых ТМЦ по
разным договорам/проектам в рамках одного склада (StockOwnershipGroup —
справочник групп, StockOwnershipTransfer — перевод количества из одной
партии в новую под другой группой, с возможностью отмены): у партии и
складского движения есть поле ownership_group_id, приход при проведении
подставляет группу по умолчанию, если строка её не указала. Но ни на одном
экране Склада нет ни списка учётных групп, ни формы перевода между ними —
это API-функциональность (support/724 в legacy-версии — полноценный
экран с формированием «виртуальной ограды» вокруг части остатка и переводом
между группами) без собственного интерфейса в Vyrab на момент
написания этой фазы.
MRP (Расчёт потребности)
Раздел /mrp, право mrp.view.
Что видно
Выбор номенклатуры и количества, кнопка «Рассчитать». После расчёта — таблица: Номенклатура / Тип / Ед. / OwnerQty / K1 / Потребность / Замена. Колонка «Замена» — выпадающий список доступных аналогов для позиции (если в справочнике заведены замены для этого места в составе изделия); после выбора одной или нескольких замен появляется кнопка «⇄ Пересчитать с заменами».
Типовые сценарии
Технолог или кладовщик проверяет, что и сколько нужно для гипотетического количества изделия ещё до создания реального заказа — чистый BOM-расчёт без учёта остатка на складе, текущего производства или открытых заказов (в отличие от «Обеспеченности» ниже, которая берёт ровно эту же математику и добавляет к ней склад).
Особенности и ограничения
- Обходит состав изделия (BOM) рекурсивно на глубину до 20 уровней.
- K1 берётся из справочника коэффициентов пересчёта (Справочники →
Коэффициенты, Справочники и доступ) для конкретной пары номенклатура/единица, а если
запись не найдена — из
default_k1карточки номенклатуры. - K2 и нормативная трудоёмкость учитываются, только если у тенанта включены
нормы расхода по операциям (настройка
vgb_norm_type_enabled); иначе формула сводится к «OwnerQty × K1» — самый частый случай в VOGBIT. - Управление самими нормами (правила
norm_rule— формула или таблица, К1/К2/К3) — отдельный административный экран в Справочниках (Справочники и доступ), на этой странице их только применяют, не редактируют.
Обеспеченность
Раздел /provision, право provision.view.
Что видно
Три вкладки-режима: Весь план, По заказу, По изделию. Под ними — форма запуска (для «По изделию» — номенклатура и количество, для «По заказу» — выбор производственного заказа из списка), кнопка «Рассчитать». После расчёта — фильтры (Все / Только дефицит / Только профицит; Все виды / Изготавливаемые / Покупные), кнопка «Выгрузить в Excel», таблица: Номенклатура / Ед. / Заявлено / Выдано / Остаток / Мин.резерв / Коэф.потерь / В производстве / Заказано / Баланс (цветной: красный — дефицит, синий — профицит). Действия по строке: значок «глаз» — детали (ссылки на связанные производственные заказы и заказы поставщику), при дефиците — кнопка «Заказ на производство» (для изготавливаемых позиций) или «Заявка на закупку» (для покупных), значок «книга» — открыть номенклатуру в справочнике.
Типовые сценарии
- Режим «Весь план» рассчитывается автоматически сразу при открытии экрана — общая картина по всем активным производственным заказам.
- Диспетчер проверяет обеспеченность конкретного заказа перед запуском в производство (режим «По заказу»).
- По дефицитной покупной позиции — «Заявка на закупку»: диалог с количеством (по умолчанию равно дефициту) и сроком, создаёт черновик заявки на закупку с одной строкой; согласование и превращение в реальный заказ поставщику происходит отдельно, на вкладке «Заявки на закупку» раздела «Склад».
- По дефицитной изготавливаемой позиции — «Заказ на производство»: диалог с номером заказа (генерируется автоматически), количеством и сроком — создаёт реальный производственный заказ напрямую, без промежуточного согласования.
Особенности и ограничения
- Баланс = (Остаток + В производстве + Заказано) − Заявлено×Коэф.потерь − Мин.резерв. Минимальный резерв и коэффициент потерь редактируются на карточке номенклатуры (Номенклатура и заказы), не на этом экране.
- Путь «Заявка на закупку» из дефицита создаёт
PurchaseRequisition(черновик) — это решение пересмотрено 25.08.2026; раньше из дефицита создавался заказ поставщику напрямую. Прямое создание заказа поставщику по-прежнему доступно отдельно на вкладке «Заказы поставщику» раздела «Склад», для рутинных закупок без формального согласования. - «В производстве» — сумма количества по позициям графика (
WorkOrder), ещё не в статусе done/canceled; это не «сколько реально осталось доделать по шагам маршрута», а упрощённая метрика для этого экрана. - «Выдано» — суммарный расход по номенклатуре за весь журнал складских движений, не привязан к конкретной потребности или заказу: в системе нет отдельного документа «заявка на материал», который бы это увязывал.
Лимитно-заборные карты
Раздел /limit-cards, право limit-cards.view.
Что видно
Таблица карт: № карты / Номенклатура / Подразделение / Лимит / Выдано / Остаток лимита / Действует с / По / статус-бейдж («Открыта» / «Закрыта»); для открытых карт — кнопки «Выдать» и «Закрыть». Форма создания: номер карты, номенклатура, подразделение, лимит, дата начала и окончания действия.
Типовые сценарии
Кладовщик заводит карту на подразделение под конкретную номенклатуру с лимитом на период. По мере обращений цеха — жмёт «Выдать», в диалоге видно остаток лимита, вводит выдаваемое количество — так до исчерпания лимита без оформления отдельной накладной на каждую выдачу. По окончании работ карту «Закрывают».
Особенности и ограничения
- Карта заводится полностью вручную — номер, номенклатура, лимит и сроки вводит оператор. Это отличается от legacy VOGBIT (support/395), где ЛЗК формируются автоматически из состава заказа и техпроцесса и автоматически делятся по подразделениям/местам хранения; в Vyrab такой автогенерации нет.
- «Выдано» всегда пересчитывается суммой складских движений с
ref= id карты; выдача сверх остатка лимита отклоняется сервером. - Создание карты дополнительно резервирует весь лимит как мягкую бронь
(
StockReservation) на эту номенклатуру; закрытие карты снимает бронь в том же действии. Частичные выдачи саму бронь не уменьшают — это грубая метка «занято под эту карту», а не точный остаток брони.
Поступления
Раздел /arrivals, право arrivals.view.
Что видно
Таблица уведомлений: Дата / Номенклатура / Кол-во / Примечание / Статус («Ожидает» / «Оприходовано»); для ожидающих — кнопка «Оприходовать». Форма создания: номенклатура, количество, дата, примечание.
Типовые сценарии
Снабженец фиксирует, что материал физически привезли на склад — ещё до того, как кладовщик его оприходовал по документам. Кладовщик по факту проверки жмёт «Оприходовать»: создаётся приходное складское движение, статус меняется на «Оприходовано».
Особенности и ограничения
- На уровне API уведомление можно привязать к конкретному заказу
поставщику (
purchase_order_id), но форма создания на этом экране такого поля не показывает — привязка де-факто не используется через интерфейс. - «Оприходовать» можно только один раз (идемпотентный ключ на основе id уведомления) и необратимо в интерфейсе — кнопки отмены нет.
Связанные разделы
- Начало работы — роли и права, окна и навигация; здесь используются без повторного объяснения.
- Обзор и аналитика — виджеты дашборда «Приход, не оприходовано», «Лимитные карты на исходе» и «Закупки требуют внимания» берут данные отсюда (Поступления, Лимитно-заборные карты, Заявки на закупку/заказы поставщику).
- Производство и планирование — «Управление потоком»: виджет/сводка «Дефицит материалов» использует ту же математику Обеспеченности.
- Номенклатура и заказы — карточка номенклатуры хранит
min_reserve_qty/safety_factor/default_k1, которые использует MRP и Обеспеченность; замены компонентов (has_substitute) заводятся там же. Производственные заказы, на которые ссылается режим «По заказу» Обеспеченности, — тоже оттуда. - Себестоимость и цены — цена прихода по умолчанию подставляется из текущей цены номенклатуры, которую поддерживает Прайс-калькулятор.
- Справочники и доступ — коэффициенты
пересчёта единиц (К1/К2/К3) и правила норм расхода (
norm_rule) администрируются там, здесь только применяются при проведении документов и в расчётах MRP/Обеспеченности.