Как построить отчет по заказам клиентов со статусами и состояниями в 1С:Управление торговлей 11?

При переходе с конфигурации 1С:Управление торговлей 10.3 на редакцию 11 разработчики и аналитики часто сталкиваются с вопросом построения отчета по заказам клиентов. В УТ 10.3 для этих целей традиционно использовался типовой универсальный отчет по регистру накопления ЗаказыПокупателей. В УТ 11 учетная архитектура существенно изменилась: типового сквозного отчета старого образца нет, а попытка собрать данные по аналогичному регистру накопления приводит к потере документов, находящихся на согласовании. Разберем архитектуру заказов в УТ 11, типовые средства анализа, а также методику разработки собственного отчета.

Архитектурные различия: Статусы и Состояния заказов

В конфигурации 1С:Управление торговлей 11 разделены понятия административного этапа обработки заказа и его фактического текущего состояния:

1. Статус заказа — управляющий реквизит самого документа ЗаказКлиента (значения перечисления СтатусыЗаказовКлиентов). Он задается вручную пользователем или бизнес-процессом («Не согласован», «Согласован», «К выполнению», «В резерве», «К отгрузке», «Закрыт») в зависимости от установленных настроек ведения заказов в программе.
2. Состояние заказа — расчетное системное значение (значения перечисления СостоянияЗаказовКлиентов). Оно хранится в независимом непериодическом регистре сведений СостоянияЗаказовКлиентов и пересчитывается программно при проведении документов цепочки («Ожидается согласование», «Ожидается аванс», «Ожидается обеспечение», «Готов к отгрузке» и т. д.).

Таким образом, статус отражает этап бизнес-процесса с точки зрения регламента компании, а состояние показывает фактическую готовность документа к следующему действию на основе графиков оплат, поступления товара и отгрузок.

Почему заказы «На согласовании» не делают движений в регистры

Выясним причину, по которой отчет по регистру накопления ЗаказыКлиентов не может отобразить полную картину. По методологии типовой конфигурации статус «Не согласован» или «На согласовании» отражает лишь черновик или предварительное коммерческое предложение. До момента согласования заказ:

1. Не создает потребностей на закупку или перемещение товаров.
2. Не резервирует товарный запас на складах компании.
3. Не формирует плановую дебиторскую задолженность в графиках оплат.

Движения по регистру накопления ЗаказыКлиентов и регистрам взаиморасчетов формируются только начиная со статусов К выполнению (при использовании обеспечения под заказ) либо В резерве / К отгрузке (при работе только со склада). Следовательно, если строить отчет исключительно по виртуальным таблицам остатков регистра ЗаказыКлиентов, все несогласованные заказы гарантированно выпадут из выборки.

Типовые инструменты контроля заказов в конфигурации

Прежде чем приступать к разработке внешнего отчета, проанализируем типовые возможности УТ 11:

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

Если же руководству требуется единый реестр за период со списком документов, суммами, статусами и состояниями, потребуется настройка СКД или разработка отдельного отчета.

Особенности регистра сведений «СостоянияЗаказовКлиентов»

Расчет текущего состояния выполняется процедурой менеджера регистра сведений: РегистрыСведений.СостоянияЗаказовКлиентов.ОтразитьСостояниеЗаказа(МассивЗаказов, Отказ, УдалениеПроведения).

При анализе алгоритма формирования состояний в модуле менеджера регистра (функция ТекстЗапросаДляРасчетаСостоянийОбеспеченияЗаказа) можно встретить следующий фрагмент:

МАКСИМУМ(ВЫБОР
    КОГДА ЗаказКлиентаТовары.ВариантОбеспечения = ЗНАЧЕНИЕ(Перечисление.ВариантыОбеспечения.ИзЗаказов)
        И ЗаказКлиентаТовары.ДатаОтгрузки > &ТекущаяДата
        ТОГДА ИСТИНА
    ИНАЧЕ ЛОЖЬ
КОНЕЦ) КАК ОбеспечениеИзЗаказовОжидается

Рассмотрим, к какому поведению это приводит на практике:

1. Проблема просроченных дат: Если дата плановой отгрузки товара наступила или прошла (ДатаОтгрузки <= &ТекущаяДата), а товар от поставщика фактически еще не поступил, условие ожидания перестает выполняться. В результате система считает фазу ожидания завершенной и при отсутствии других блокировок заказ может ошибочно отобразить состояние «Готов к отгрузке», несмотря на нехватку остатка на складе.
2. Фактор отсутствия регламентного пересчета: Расчет состояния опирается на параметр &ТекущаяДата, но сам вызов пересчета происходит только при проведении документов. Если заказ просто лежит в базе, а календарный день сменился, его расчетное состояние в регистре сведений не обновится до тех пор, пока документ или связанная с ним накладная не будут перепроведены.

Для устранения рассинхронизации состояний без изменения движений в закрытых периодах рекомендуется использовать регламентное задание или внешнюю обработку, которая вызывает метод ОтразитьСостояниеЗаказа для массива открытых заказов.

Как правильно построить собственный отчет в СКД

Использовать готовый текст запроса из динамического списка формы документов внутри СКД не рекомендуется. Динамический список оптимизирован платформой для постраничной выборки первых порций данных, тогда как отчет выполняет запрос по всей выборке целиком, что может привести к блокировкам и медленной работе системы.

Разберем по шагам правильную структуру запроса для схемы компоновки данных:

1. Основная таблица: В качестве базового источника используем документную таблицу Документ.ЗаказКлиента с отбором по проведенным документам и интервалу дат. Это позволит увидеть даже те заказы, которые находятся на согласовании.
2. Соединение с состояниями: Выполняем ЛЕВОЕ СОЕДИНЕНИЕ с регистром сведений СостоянияЗаказовКлиентов по полю Ссылка = Заказ для получения актуального вычисленного состояния.
3. Соединение с товарными остатками: Подключаем виртуальную таблицу РегистрНакопления.ЗаказыКлиентов.Остатки для расчета неотгруженного и незарезервированного количества товара.
4. Соединение с взаиморасчетами: Для получения сумм долга и оплаты подключаем регистры взаиморасчетов (РасчетыСКлиентами или РасчетыСКлиентамиПоСрокам).

Посмотрим на пример структуры запроса для СКД:

ВЫБРАТЬ
    ЗаказКлиента.Ссылка КАК Заказ,
    ЗаказКлиента.Номер КАК Номер,
    ЗаказКлиента.Дата КАК Дата,
    ЗаказКлиента.Партнер КАК Партнер,
    ЗаказКлиента.Статус КАК Статус,
    ЕСТЬNULL(Состояния.Состояние, ЗНАЧЕНИЕ(Перечисление.СостоянияЗаказовКлиентов.ПустаяСсылка)) КАК Состояние,
    ЗаказКлиента.СуммаДокумента КАК СуммаДокумента,
    ЕСТЬNULL(ОстаткиЗаказов.КоличествоОстаток, 0) КАК НеОтгружено
ИЗ
    Документ.ЗаказКлиента КАК ЗаказКлиента
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СостоянияЗаказовКлиентов КАК Состояния
        ПО ЗаказКлиента.Ссылка = Состояния.Заказ
    ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ЗаказыКлиентов.Остатки(&Период, ) КАК ОстаткиЗаказов
        ПО ЗаказКлиента.Ссылка = ОстаткиЗаказов.ЗаказКлиента
ГДЕ
    ЗаказКлиента.Проведен = ИСТИНА
    И ЗаказКлиента.Дата МЕЖДУ &ДатаНачала И &ДатаОкончания

Такой подход обеспечивает корректное отображение полного реестра заказов за выбранный период, сохраняет высокую скорость формирования отчета и позволяет одновременно видеть как установленный административный статус, так и расчетное состояние документа.