При работе в конфигурации 1С:Управление производственным предприятием 1.3 (УПП 1.3) часто возникает задача контроля обеспечения потребностей. Рассмотрим ситуацию: у нас есть документ ВнутреннийЗаказ. На его основании планируется закупка, но без жесткого заполнения резервов и размещения. Будет просто создаваться новый ЗаказПоставщику. Возникает закономерный вопрос: каким отчетом можно отследить весь жизненный цикл и исполнение этого заказа? Нам нужно видеть сам заказ поставщику, факт поступления товаров и, при необходимости, складское перемещение.
Разберем по шагам, какие инструменты предлагает типовая конфигурация, в чем их ограничения и как мы можем получить нужную информацию, создав удобную систему аналитики.
Первое, что приходит на ум — использовать стандартный отчет Анализ внутреннего заказа. Давайте посмотрим на его возможности. Данный отчет отлично справляется с задачей показа количественных показателей: сколько товара требовалось, сколько осталось обеспечить, сколько уже зарезервировано на складе.
Однако, если мы проанализируем ситуацию глубже, то выясним причину, по которой этот отчет не полностью решает нашу задачу: в нем присутствуют только сводные цифры. Он не разворачивает детализацию до конкретных документов (заказов поставщику, документов ПоступлениеТоваровУслуг или перемещений). Типового отчета в виде плоской удобной таблицы, который бы показывал статусы обеспечения по внутреннему заказу вплоть до первичных документов "из коробки", к сожалению, нет.
Если документов немного, самый простой и быстрый способ отследить цепочку — использовать стандартный механизм Структура подчиненности (Связанные документы).
Для этого в документе ПоступлениеТоваровУслуг (в табличной части) можно вручную или полуавтоматически заполнять поле Заказ ссылкой на исходный ВнутреннийЗаказ. Если цепочка документов введена корректно (на основании), структура подчиненности покажет всю ветку от потребности до оприходования на склад. Но этот метод подходит лишь для точечного анализа, а не для массового контроля менеджером по закупкам.
Проанализируем ситуацию, когда заказ поставщику создается без заполнения резерва/размещения. Именно отказ от механизма размещения лишает нас автоматической связи ожидаемой поставки с потребностью подразделения в типовых отчетах.
Рассмотрим подробнее, как работает правильное размещение:
ЗаказПоставщику в соответствующей колонке табличной части необходимо указать исходный ВнутреннийЗаказ (он выступает в роли документа партии или потребности).ПоступлениеТоваровУслуг товар автоматически попадет в резерв именно под этот внутренний заказ.Если мы используем этот механизм, мы сможем задействовать отчеты по закупкам:
Вместо того чтобы сразу приступать к программированию с нуля, разберем альтернативный вариант — настройку Универсального отчета. Многие аналитики 1С собирают нужные данные по регистрам накопления, не прибегая к написанию кода.
Для получения детальной картины по документам построим отчет по следующим регистрам:
ПотребностиВНоменклатуре. Он покажет появление потребности по Внутреннему заказу и ее закрытие.ЗаказыПоставщикам. Если вывести в отчет регистраторы (документы движения), мы сможем в одном окне увидеть и сам заказ поставщику, и документы поступления. Сгруппировав данные по измерению, отвечающему за заказ-источник, мы получим связку с внутренним заказом.Как показывает практика и опыт сообщества специалистов по УПП 1.3, самым эффективным решением для полноценного контроля является разработка собственного дашборда. Разберем логику создания такого отчета на Системе компоновки данных (СКД).
Вам потребуется написать запрос, который объединит данные из нескольких регистров. Примерная структура источников для такого отчета:
ПотребностиВНоменклатуре для получения базовой потребности.ЗаказыПоставщикам для получения информации о заказах поставщику и ожидаемых поступлениях.ТоварыВРезервеНаСкладах для контроля фактически поступившего товара, который лежит под заказ.С помощью соединения этих таблиц по номенклатуре и документу потребности, мы можем вывести плоскую таблицу со следующими колонками: Внутренний заказ, Номенклатура, Требуемое количество, Заказ поставщику (документ), Ожидаемое количество, Документ поступления, Поступившее количество.
Таким образом, мы выяснили причину отсутствия готового плоского отчета в типовой УПП 1.3 и разобрали несколько рабочих путей решения: от использования структуры подчиненности и правильного размещения до настройки универсальных отчетов и разработки кастомного решения на СКД. Выбор конкретного метода зависит от требований бизнеса к визуализации данных и глубины аналитики.