Каталог решений - Состояния заказов клиентов

Состояния заказов клиентов

Состояния заказов клиентов

В наличии

Конфигурация «Управление торговлей, редакция 11 (11.4.11.104)». Регистр сведений «Состояния заказов клиентов». Описание и устройство.

Категория:

Описание

Добрый день! В настоящей публикации результат разбора регистра сведений «Состояния заказов клиентов», его устройства, использования и попытка понимания методологии.

Объект включен в подсистему «Объекты УТ11, КА2, УП2». Должны увидеть его в комплексной и ERP. В аналогичном ли виде — не проверял. Непериодический, регистратору не подчинен. Структура изображена на рисунке №1. Светло-красным выделено измерение. Светло-зеленым ресурсы. Светло-синим, соответственно, реквизиты. Измерение «Заказ» и ресурс «Состояние» имеют составной тип.

 

 

Записи в регистр производятся через процедуру «ОтразитьСостояниеЗаказа» модуля менеджера. Сам метод универсален, рассчитывает состояние заказов и/или заявок. Первым параметром передается массив ссылок. Так что сформирован может быть многострочный набор записей. Инициирующим расчет состояния может выступать один из 42 объектов метаданных. Состав на рисунке №2.

 

 

Вызов метода производится в событиях «ОбработкаПроведения» документов и «ПослеЗагрузкиДанных» планов обмена. Механика такова, что в регистрирующих объектах выполняются операции, изменяющие или возможно изменяющие состояние заказов/заявок. Изменение состояния происходит в разрезе заказа/заявки, расчет выполняется на основании источников данных (рисунок №3). Светло-желтым выделены источники данных. Светло-серым вспомогательные виртуальные таблицы с кратким пояснением состава и назначения. Светло-пурпурным — результирующие виртуальные таблицы, которые будут использоваться в конечном собранном запросе через соединение для расчета состояний заказов/заявок.

 

 

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

  • Документ.ЗаказКлиента
  • Документ.ЗаявкаНаВозвратТоваровОтКлиента

В итоге получаем: источники данных + расчет состояний для объекта аналитики (заказа/заявки). Полученный набор в виде таблицы значений пишется в регистр.

Теперь изложу заметки и вопросы, появившиеся у меня «в лоб».

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

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

ПериодЗаказКлиентаКОплатеПриходКОплатеПриход1

КОплатеРасход

08.04.2017Заказ клиента ТД00-000005 от 08.04.2017 17:06:5330 797,8530 797,85102 659,50
15.04.2017Заказ клиента ТД00-000005 от 08.04.2017 17:06:5371 861,6530 797,85102 659,50
15.04.2017Заказ клиента ТД00-000005 от 08.04.2017 17:06:5371 861,6571 861,65102 659,50

 

где «КОплатеПриход1» это поле из таблицы справа, т.е. второго экземпляра «ЭтапыРасчетов». После группировки образуется:

08.04.2017Заказ клиента ТД00-000005 от 08.04.2017 17:06:5330 797,8530 797,85102 659,50
15.04.2017Заказ клиента ТД00-000005 от 08.04.2017 17:06:53143 723,3102 659,5102 659,50

            
Соответственно, на это накладывается условие:

ИМЕЮЩИЕ
    СУММА(ЭтапыРасчетов.КОплатеПриход) — ЕСТЬNULL(Оплачено.КОплатеРасход, 0) > 0

В итоге в таблице «РезультатРасчетов» остается вторая запись:

15.04.2017Заказ клиента ТД00-000005 от 08.04.2017 17:06:53143 723,3102 659,5102 659,50

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

3. Предполагаю, что регистр исключительно аналитический. Предназначен для хранения расчетной сводной информации. Используется ли где-то в конфигурации (в других подсистемах) как источник данных?

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

has been added to your cart:
Оформление заказа