Документация/Склад и снабжение
РУКОВОДСТВО VYRAB

Склад и снабжение

Движение запасов, расчёт потребности и покрытие дефицита.

Назначение

Группа меню Склад отвечает за весь материальный контур: сколько чего есть на складе и где именно (партии, ячейки хранения), движение материала внутрь/наружу/между местами хранения (приход, расход, перемещение, инвентаризация, списание отхода), закупку у поставщиков (заявка → заказ → поступление) и расчётные экраны, которые говорят, чего не хватает и сколько нужно докупить/изготовить (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 там, где она вообще есть (вкладка «Обороты», экран «Обеспеченность»).

Складской журнал

Что видно

Единая таблица всех складских движений: Дата / Номенклатура / Тип / Изменение / Цена за ед. / Сумма / Основание, с фильтром по столбцам. У строк расхода моложе срока возврата — кнопка «Вернуть». Внизу — форма быстрого добавления движения: номенклатура, тип (Приход / Расход / «Корректировка (админ)» — последний вариант виден только администратору), количество, цена за ед. (только для приходов), основание.

Типовые сценарии

  1. Кладовщик быстро фиксирует приход или расход без оформления полноценной накладной — например, канцелярские мелочи или разовую операцию.
  2. Возврат ошибочно списанного расхода: кнопка «Вернуть» показывается только на движениях расхода не старше срока возврата (по умолчанию 3 дня, настраивается на вкладке «Расход»); вводимое количество не может превышать ещё не возвращённый остаток по этому движению.
  3. Администратор корректирует расхождение вручную с обязательным основанием — единственный путь для прямой корректировки без документа-основания.

Особенности и ограничения

  • Прямая корректировка (reason=adjustment) требует operator.is_admin и непустого основания — сервер отклонит запрос иначе (403/422).
  • Цена прихода, если не введена вручную, автоматически подставляется из текущей действующей цены номенклатуры (PriceRecord — тот же прайс-лист, который поддерживается в Прайс-калькуляторе, Себестоимость и цены).
  • Возврат наследует ячейку/партию/цену исходного расходного движения — переопределить их нельзя.
  • Список показывает последние 200 движений без постраничной навигации; для сводки за период — вкладка «Обороты».

Приход

Что видно

Слева — список приходных накладных (Накладная / Поставщик / Дата / Статус). Справа — строки выбранной накладной: Номенклатура / Кол-во / Ед. / Кол-во (баз. ед.) / Цена за ед. / Ячейка / Партия, с удалением строки, пока накладная в черновике. Форма создания накладной: Поставщик, № накладной, Дата. Форма добавления строки (только в черновике): номенклатура, кол-во, единица измерения (пусто = базовая единица номенклатуры), цена за ед., ячейка, номер партии, сертификат. Кнопка «Провести» — только для черновика с хотя бы одной строкой.

Типовые сценарии

  1. Кладовщик заводит накладную на поступившую от поставщика партию, построчно вводит позиции с ценой, сертификатом и номером партии, проводит — на каждую строку создаются партия (Batch) и приходное складское движение.
  2. Ошибочную строку можно удалить, пока накладная в черновике; после проведения накладная и её строки неизменны.

Особенности и ограничения

  • Проведение необратимо в интерфейсе — кнопки отмены/сторно проведённой накладной нет.
  • Если строка указывает единицу измерения, отличную от базовой, а коэффициент пересчёта (Справочники → Коэффициенты, Справочники и доступ) для этой пары единиц не заведён — проведение падает с ошибкой; строку нужно поправить.
  • Номер партии, если не указан, генерируется автоматически (первые 8 символов id строки).

Расход

Что видно

В шапке — две настройки, общие для всего склада (не только этой вкладки): метод списания (FIFO / LIFO / «Партия вручную (SELECT)») и срок возврата в днях. Ниже — список расходных накладных (Основание / Подразделение / Статус) и строки выбранной: Номенклатура / Заявлено / Ед. / К выдаче (баз. ед.) / К выдаче (редактируемое поле, пока накладная в черновике) / Ячейка / Партия. Форма новой накладной: Основание (заявка/наряд), Подразделение. Форма строки: номенклатура, количество, единица, ячейка, партия (поле обязательно и появляется, только если метод списания — SELECT).

Типовые сценарии

  1. Кладовщик заводит расходную накладную по заявке цеха или наряду, вводит запрошенное количество, при необходимости правит «К выдаче» на фактически выдаваемое (частичная выдача — это правка поля до проведения, а не серия отдельных частичных проводок), проводит.
  2. При методе SELECT оператор явно выбирает партию для каждой строки; при FIFO/LIFO система сама разносит списание по открытым партиям, при необходимости — сразу по нескольким.

Особенности и ограничения

  • «К выдаче» по умолчанию равно «Заявлено», редактируется только в черновике.
  • Метод списания и срок возврата, изменённые здесь, действуют сразу и на «Складском журнале», и на диалоге быстрого расхода («Адресация»), и на «Перемещении».

Перемещение

Что видно

Список перемещений (Откуда / Куда / Статус; для статуса «В пути» — кнопка «Принять»). Строки: Номенклатура / Кол-во / Ед. / Кол-во (баз. ед.) / Партия. Форма создания: выбор ячейки «Откуда» и «Куда», комментарий. Форма строки — как на «Расходе» (плюс партия при методе SELECT). Две кнопки проведения: «Передать» и «Выдать».

Типовые сценарии

  1. Перемещение в пределах одного контролируемого кладовщиком участка — «Передать» проводит сразу обе стороны (draft → completed).
  2. Передача между подразделениями/складами с разными ответственными — «Выдать» проводит только расходную часть (draft → pending); принимающая сторона позже жмёт «Принять» в общем списке (pending → accepted).

Особенности и ограничения

Отдельной сущности «Склад-получатель»/«Склад-отправитель» на этом экране нет — «откуда»/«куда» всегда ячейки хранения, а не склады целиком.

Обороты

Что видно

Период «С» / «По» (по умолчанию — с начала месяца по сегодня), кнопка «Показать», кнопка «Выгрузить в Excel» (активна после построения отчёта). Таблица по номенклатуре: Остаток на начало / Приход / Расход / Возврат / Перемещение / Корректировка / Остаток на конец / Сумма на конец.

Типовые сценарии

Сверка на конец периода: кладовщик или экономист строит отчёт за месяц, проверяет остатки на начало/конец, выгружает в Excel для архива или бухгалтерии.

Особенности и ограничения

Отчёт считается «на лету» по журналу движений при каждом «Показать» — отдельной хранимой таблицы оборотов нет; скорость зависит от объёма всего журнала движений за всё время (журнал читается целиком, затем фильтруется по датам).

Адресация

Что видно

Слева — дерево ячеек хранения (Код / Наименование / Родитель) и форма добавления ячейки (Код, Наименование, Родитель). Справа, после выбора ячейки, — остатки в ней: чекбоксы + Номенклатура / Кол-во, кнопка «Расход (N)» по отмеченным строкам и форма быстрого перемещения (номенклатура + количество со знаком «+приход / −расход», кнопка «Переместить»).

Типовые сценарии

  1. Кладовщик заводит иерархию мест хранения: склад → стеллаж → полка → ячейка.
  2. Быстрый расход прямо с полки: отмечает несколько позиций галочками, «Расход (N)» открывает диалог быстрого расхода (см. ниже).
  3. Ручное «+приход / −расход» на конкретной ячейке — обычное складское движение с этим cell_id.

Особенности и ограничения

  • Остатки ячейки — не отдельный регистр, а разбивка журнала движений по cell_id; «что лежит на полке» всегда пересчитывается заново, а не читается из готовой таблицы.
  • На уровне API есть отдельная сущность «Склад» (Warehouse) с деревом ячеек, привязанных к ней специальной связью (не через обычную вложенность ячеек друг в друга) — но форма создания ячейки на этой вкладке не даёт выбрать/создать Warehouse. Все ячейки, заведённые отсюда, остаются без привязки к какому-либо складу-контейнеру; это переходное состояние миграции.

Диалог быстрого расхода

Появляется по кнопке «Расход (N)»: таблица отмеченных позиций (количество — не больше остатка на ячейке; партия — только при методе SELECT), поля Получатель (подразделение), Работник, Тип связи, Комментарий, кнопка «Выдать». При FIFO/LIFO партия для проведения выбирается автоматически; диалог создаёт и сразу проводит расходную накладную одним вызовом — без промежуточного черновика.

Заказы поставщику

Что видно

Таблица заказов: Номенклатура (1-я строка) / Кол-во (1-я строка) / Поставщик / Ожидается / Статус, кнопка «Строки» (открывает модальное окно с полным списком строк заказа) и кнопки перехода статуса («→ Получен», «→ Отменён»). Форма создания: номенклатура, количество, ожидаемая дата, поставщик (выбор из справочника или «+ новый поставщик…» с полем названия прямо в форме).

Типовые сценарии

  1. Кладовщик или снабженец заводит заказ напрямую поставщику для рутинной закупки, минуя согласование через заявку.
  2. При фактическом получении товара — переводит статус в «Получен»: на каждую строку заказа система проводит настоящую приходную накладную (со своими партиями), а не просто одно складское движение.

Особенности и ограничения

Колонки «Номенклатура/Кол-во (1-я строка)» показывают только первую строку заказа — заголовок дублирует данные первой строки по историческим причинам (заказ раньше был всегда однострочным). У многострочного заказа (например, конвертированного из заявки с несколькими позициями) остальные строки видны только через «Строки».

Заявки на закупку

Что видно

Список заявок (Основание / Статус, кнопки перехода «→ Утверждена», «→ Отклонена», «→ Отменена»; для утверждённых — «Создать заказ…»). Строки выбранной заявки: Номенклатура / Кол-во / Нужно к. Форма создания заявки (Основание) и форма добавления строки (номенклатура, количество, срок «Нужно к»).

Типовые сценарии

  1. Заявка создаётся в черновике, наполняется строками, утверждается.
  2. Утверждённая заявка конвертируется в заказ поставщику диалогом «Создать заказ…» (выбор существующего поставщика или ввод нового) — заявка переходит в статус «Заказана», создаётся реальный заказ поставщику со всеми строками заявки.

Особенности и ограничения

Прямой переход заявки в статус «Заказана» заблокирован на уровне API — только через действие «Создать заказ…» (/convert), чтобы нельзя было пометить заявку заказанной, не создав фактический заказ поставщику.

Инвентаризация

Что видно

Список инвентаризаций (Комментарий / Создана / Статус; для черновика — кнопки «Провести» и «Отменить»). Строки: Номенклатура / Ячейка / Учтено факт. / По журналу / Отклонение. Форма строки: номенклатура, партия (или «Не найдена (новая партия)»), ячейка, учтено фактически.

Типовые сценарии

Кладовщик пересчитывает фактический остаток и вводит по каждой позиции фактическое количество — «По журналу» и «Отклонение» считаются и показываются сразу, ещё до проведения (превью, ничего не сохраняется). «Провести» пишет по каждой строке компенсирующее складское движение, которое подгоняет системный остаток под факт.

Особенности и ограничения

После проведения «Отклонение» у строки закономерно показывает величину, близкую к нулю — коррекция уже применена и системный остаток сравнялся с учтённым; это ожидаемое поведение, а не ошибка.

Деловой отход и списание

Что видно

Таблица (Номенклатура отхода / Вид / Источник / Кол-во / Причина / Статус; для проведённых — кнопка «Отменить»). Форма: тип источника («Операция заказа» / «Заказ на доработку») с текстовым полем ID источника, номенклатура и партия-источник, номенклатура отхода, вид («Оприходовать (деловой отход)» / «Списать безвозвратно»), количество, причина.

Типовые сценарии

  1. Оприходовать деловой отход (например, обрезки материала) — создаётся и сразу проводится приходная накладная на номенклатуру отхода (новая партия), остаток исходной партии не меняется.
  2. Списать безвозвратно брак/потери — создаётся и сразу проводится расходная накладная с исходной партии-источника.

Особенности и ограничения

  • Единственный экран приложения, открытый по любому из двух прав (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», таблица: Номенклатура / Ед. / Заявлено / Выдано / Остаток / Мин.резерв / Коэф.потерь / В производстве / Заказано / Баланс (цветной: красный — дефицит, синий — профицит). Действия по строке: значок «глаз» — детали (ссылки на связанные производственные заказы и заказы поставщику), при дефиците — кнопка «Заказ на производство» (для изготавливаемых позиций) или «Заявка на закупку» (для покупных), значок «книга» — открыть номенклатуру в справочнике.

Типовые сценарии

  1. Режим «Весь план» рассчитывается автоматически сразу при открытии экрана — общая картина по всем активным производственным заказам.
  2. Диспетчер проверяет обеспеченность конкретного заказа перед запуском в производство (режим «По заказу»).
  3. По дефицитной покупной позиции — «Заявка на закупку»: диалог с количеством (по умолчанию равно дефициту) и сроком, создаёт черновик заявки на закупку с одной строкой; согласование и превращение в реальный заказ поставщику происходит отдельно, на вкладке «Заявки на закупку» раздела «Склад».
  4. По дефицитной изготавливаемой позиции — «Заказ на производство»: диалог с номером заказа (генерируется автоматически), количеством и сроком — создаёт реальный производственный заказ напрямую, без промежуточного согласования.

Особенности и ограничения

  • Баланс = (Остаток + В производстве + Заказано) − Заявлено×Коэф.потерь − Мин.резерв. Минимальный резерв и коэффициент потерь редактируются на карточке номенклатуры (Номенклатура и заказы), не на этом экране.
  • Путь «Заявка на закупку» из дефицита создаёт 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/Обеспеченности.