Доброго времени суток коллеги.

Имеем документ "Заказ".
У документа есть признак статус. Статус у документа меняется со временем.
Собственно статусы:
- открытый;
- подготовка;
- в работе;
- закрыт.

Смена статуса хранится в регистре сведений в записи типа:
Заказ
СтатусБыл
СтатусСтал

Вот теперь задача:
Как отследить заказы у которых в заданный период 1-й раз сменился статус скажем с открытый на подготовка.

Хотелось бы сделать все одним запросом, но что-то потерялась я....

Заранее спасибо.

Выбираем по этому регистру все записи у которых период между начальной датой и конечной датой - это полностью всё за определенный период. И говорим, чтобы выбирал только те записи, у которых СтатусБыл такой-то, а СтатусСтал такой-то. И делаем группировку по Заказу, СтатусБыл и СтатусСтал и накладываем на период МИНИМУМ. Как-то так:

Запрос = Новый Запрос;
Запрос.Текст = "
|ВЫБРАТЬ
|   МИНИМУМ(МойРегистр.Период),
|  МойРегистр.Заказ
|ИЗ
|   МойРегистр КАК МойРегистр
|ГДЕ
|   СтатусБыл = &СтатусБыл
|   И СтатусСтал = &СтатусСтал
|СГРУППИРОВАТЬ ПО
|   МойРегистр.Заказ,
|   МойРегистр.СтатусБыл,
|   МойРегистр.СтатусСтал
|";

Навскидочку.

регистр сведений уже хранит информацию или только предполагается такая структура? Просто Статус в регистре недостаточно?

я почему спрашиваю, , что могут быть ошибки, кот нужно предусматривать

01.01.2012 открытый подготовка
02.01.2012 открытый подготовка
03.01.2012 открытый подготовка
04.01.2012 в работе закрыт.

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

к тому же тут определенные правила: после "в работе" не ставится "открыт", "подготовка"..... бизнес-процессы, что ли?

Уточню, не совсем правильно объяснил.

Берем период: с [Дата] по [Дата]
Статус менялся может быть и до этого периода, но надо выбрать заказ если статус сменился по заданной схеме именно в этот период.
То есть:

01.01.2012 открытый подготовка (первый раз).
02.01.2012 подготовка открытый
03.01.2012 открытый подготовка (второй раз).

Надо отобрать если период скажем с 01.01.2012 по 02.01.2012
а если период с 02.01.2012 по 03.01.2012, тогда не отбирать

я бы сделал так. в 1 подзапрос поместил бы различные заказы из регистра за период. Во втором подзапросе подсчитал бы по эти заказам количество записей за период и отобрал бы записи с нужным количеством... Если нужны дополнительные условия - накладывал бы их в следующем запросе пакета.

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



вложенными запросами?

Изменения структуры регистра возможно?

в запросе сформировать по СтатусПосле

сформировать строки "1Открыт1Подготовка1закрыт1Подготовка1Открыт1В работе1" , отбирать по числу вхожедений например подстрокистроки "Открыт1Подготовка" равно 1.
1- разделитель в примере.

Но я как в том анекдоте, про стать зайчикам ёжиками - стратег)) . пока не владею знаниями , как в запросе преобразить данные в строку за период в разрезе заказа.

Да там простейшая структура:
Заказ
СтатусБыл
СтатусСтал

ну и плюс период как стандартный реквизит.

То есть по регистру мы можем смотреть полную историю смены статусов.

а возможные ошибки при этом - пример же приведен

Не понял.

Статусбыл всегда можно прочитать из предыдущих строк в регистре. достаточно только статусПосле в регистре.

Это исключает ошибки. Когда вы перепроводите документ другим числом, который устанавливает статусы в регистр. Это нужны проверки тогда при проведении. А так устанавливаете новый статус на новое число и все.

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

В догонку:
сложность в том, что как-то не въезжаю как запросом выделить 1-ю запись отвечающую требованиям.

Точнее, так:
1-я проверка, выделить 1-ю запись в регистре отвечающую требованиям перехода между статусами.
в моем случае это, (к примеру) открытый - подготовка.
2-я проверка, уже после выделения этой самой записи, на вхождение в заданный интервал.

Я имел ввиду, возможно ли давать советы по модификации структуры регистра?

Та не вопрос.

Ну тогда если добавить в регистр реквизит булевого типа и устанавливать его при первом изменении?

Ну я вообщем думал уже об этом.
Просто думаю все-таки существует решение на уровне запроса сделать это, а не потом, как я на данный момент сделал, сравнивать вхождение на заданный период...

единичка меня сбила. значит первое изменение статуса, а не заказы с одним-единственным изменением статуса.

А сначала сделать отбор строк по условию СтатусДо= и статусПосле= , а потом упорядочить по Период. группировки Заказ, за ним группировка период. И снимать только первые записи при обходе выборки...

Как я делал:

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

Правда не работает как надо...

А вот вариант, как надо делать :

|ВЫБРАТЬ
|    СтатусыСрезПервых.Период,
|    СтатусыСрезПервых.Заказ
|ПОМЕСТИТЬ СрезПервых
|ИЗ
|    РегистрСведений.Статусы.СрезПервых КАК СтатусыСрезПервых
|ГДЕ
|    СтатусыСрезПервых.СтатусБыл = &СтатусБыл
|    И СтатусыСрезПервых.СтатусСтал = &СтатусСтал
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
|    Статусы.Период,
|    Статусы.Заказ,
|    Статусы.СтатусБыл,
|    Статусы.СтатусСтал
|ИЗ
|    РегистрСведений.Статусы КАК Статусы
|ГДЕ
|    Статусы.Период МЕЖДУ &НачПериод И &КонПериод
|    И (Статусы.Период, Статусы.Заказ) В
|            (ВЫБРАТЬ
|                СрезПервых.Период,
|                СрезПервых.Заказ
|            ИЗ
|                СрезПервых КАК СрезПервых)

А в вашем регистре сведений не болтается ссылка на документ, сделавший движения?

Исче как болтается.

Тогда вариант Vofka должен помочь. Единственное я б наверное наложил ограничение на виртуальную таблицу СрезПервых на дату &НачПериод

Вот в статусБыл и статусСтал - вот здесь грабельки поставлены. Для всех.
По-моему, Регистр надо сделать периодическим - фиксировать изменение статуса.

ЗЫ. Сам щас инет-магазин автоматизирую(
ЗЗЫ. Полегче со "срезами" - это оч специфичная вещь, закидоны с ними в ЗУПе уже претендуют на притчи.

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

Так регистр и есть периодический. (Сорри забыл упомянуть).

Собственно записи и хранятся в порядке возникновения события смены статуса.
Типа:
01/01/2012 - ...... - открытый (создание документа заказ)
02/01/2012 - открытый - подготовка
.....
PROFIT



ЗЫ: Появилась мысль насчет срез первых с условием, может прокатит.....

- Доктор, мне кажется меня все игнорируют.
- Кто здесь?

DartRomanius, а откоментить мой запрос нельзя? Или я его для себя выложил?

Чуть подкину по поводу срезов.
Срез дает все возможные комбинации измерений.
Горбуха из ЗУПа:
Сотр поработал, уволился, затем снова вернулся.
Для рассчета больничных/отпусков нам нужен стаж - срез первых? Хрен Вам, дорогие товарищи! Нужен срез первых по Сотру с игнорированием ФизЛица.
Всем советую: научитесь расписывать Срез, писать Срез в конструкторе, не упоминая это страшное слово. Тогда Вы легко сможете отключить одно или несколько измерений - и Ваш Срез воссияет, и решит все Ваши проблемы




ППЦ! Тогда нахера, простите за фигуру речи, "был"? Предыдущей записи недостаточно?

Уппс, проморгал.



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

Было сказано:

Что здесь не проходит?

Перечитайте мой пост. Стандартный Срез - зло. Не ленитесь.

хорошо - вместо удалить, если прочтут:
влож запрос -- отобрать по условию. внешн запрос поля Период, Заказ. Упорядочить по Период. Группировка ЗАказ, Период. В выборке обход заходить только по первым записям.

Не поверите, я читаю все посты. А теперь перечитайте мой запрос и скажите какое отношение его текст имеет к вашему посту?

|ВЫБРАТЬ
|    СтатусыСрезПервых.Период,
|    СтатусыСрезПервых.Заказ
|ПОМЕСТИТЬ СрезПервых
|ИЗ
|    РегистрСведений.Статусы.СрезПервых КАК СтатусыСрезПервых
|ГДЕ
|    СтатусыСрезПервых.СтатусБыл = &СтатусБыл
|    И СтатусыСрезПервых.СтатусСтал = &СтатусСтал

Как я написал выше, сначала берет срез первых.
Если мы уберем условие, значения есть.

как только использовать условие и запись не является 1-й, она не попадает в временную таблицу

Так вы ж сами говорили, что надо как раз выбирать запись, если ОНА ПОПАЛА В ЭТОТ ПЕРИОД и она ПЕРВАЯ. Не?


ЗЫ. Домовик, а почему вы сначала пишете, а потом удаляете? Не в первый раз за вами такое замечаю? Права на редактирование постов мешают? Так можно убать

Я так понимаю, что безадресные посты адресуются ТС.
Если запостил в ответ на Ваш пост - это ошибка, я стараюсь отвечать только на посты ТС

ЗЫ. Но СрезП.... по регистру, где больше одного Измерения - грабли для лентяев! И ... это... непарит, вобщем

Просто ваш пост оказался под моим, поэтому решил, что это мне.


Грабли - если в ВЫБРАТЬ выбирать несколько измерений. И опять таки, автор не указал что измерения, а что нет. Я специально создал конфу с 1 регистром, чтоб проверить запрос. В моем регистре "Заказ" - это измерение, остальное ресурсы.

Уточняю:

Регистр ИсторияСтатусов
Измерения:
Заказ
Ресурсы:
СтатусБыл
СтатусСтал
Реквезиты:
Нет

Регистр периодический. Режим записи - подчинен регистратору. Периодичность - по позиции регистратора.

Можно на пальцах, для тех кто в танке, почему не правильно отработает мой запрос?

срез первых выбирает только первые записи, не зависимо - какие они. таблица изначально усечена.

а нужно сразу найти искомые записи, потом "срезать".

Ещё раз, прошу ВНИМАТЕЛЬНО прочитать это:



И я просил объяснить на пальцах (на примерах каких-то данных).

Vofka, ваш запрос рабочий, но постановка, думаю, другая.
объяснение было по конкретному тому примеру.

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

задача эта,думаю, выглядит так:

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


в зеленых рамках - записи-рещения.

синим фоном - показан срез первых.

правильно ли понята задача - неизвестно. можно ли применить "выбрать первые " с учетом группировки(заказ) мне тоже неизвестно.

Я, честно говоря, потерял интерес к задаче, поэтому не хочу уже разбираться. А вам жму палец за то, что не поленились изобразить (в отличии от ТС)