Здравствуйте. Буду краток.
Дано:
1. ТиС дооопииисаааанннааааяяяя
2. К объекту типа "Документ" (не проведенный), "Справочник" и т.д., не важно, могут устанавливаться статусы (например типа "перечисление" -со значениями "новый", "в обработке", "готов" и т.д.)
3. При решении задачи про регистр забыть, т.к. на мысль о новом документе (двигателе регистра) - отказано.

Найти:
1. Для объекта хранить историю изменения статусов в разрезе Объект/Дата/Время/Статус
2. Иметь возможность сделать срез по текущему состоянию объектов по статусу
3. Играться с отчетами вида: а) сколько времени объект находился в каком-либо статусе; б) был ли объект в определенном статусе; в) был ли переход из статуса1 в статус2 в) на какой статус был переход с определенного статуса; г) с какого статуса был переход на определенный статус; д) еще какой-нить ох...ный отчет
Примечания:
Прошу воспринимать не школярной/рабочей задачей, а личным интересом.
Заинтересовал именно вопрос организации хранения и выборки из истории. Регистр сведений из 8 - это, наверное, здорово, однако, тут 7.7 и без регистров.
)
Спасибо.

перейди на 8ку, блеат!

буть мужиком

1. Храни во внешней таблицы
2. Документ статус, Вводиться на основании документа и хранит в ТЧ историю статусов. Т.е. каждый раз когда статус изменяется - новая строка
3. Эмулировать РС на Справочнике. Колонка Объект (отбор, сортировка) и статусы твои, тоже с индексами поиграться надо для скорости

В принципи можно и 2 справочника замутить. Объект и подчинены статусы (если не будешь прямыми запросами данные таскать, то проще выборку организовывать (использоватьВладельца, ВыбратьЭлементы()))

Ну можно и регистр прикрутить. И не обязательно документ двигатель делать. Добавить в уже существующие документы частичное проведение по этому регистру при смене статуса. Только геморно, очень уж много менять всего.
А так в (3)(4) всё верно.

(3)(4) эти варианты я прикидывал, спасибо.
(5) а это необычно. Думал все перебрал, но вот проводить "левым" документом регистру, прикольно )
(1) Дело не в 8, но без "срача в каментах" и пост не пост )
Спасибо всем.

(1), (2) сгореть в аду за такие советы не предлагале?

замутить справочник состояний объекта с периодическим реквизитом еще не предлагали?

как организовать история страусов? ... зачем страусам история?

(8) плохая мысль.

(8) а как потом запросом "рыться" в периодических реквизитах без прямых запросов или тупо не перебирая?

в 8-ке у меня такое сделано на регистре сведений. логично предположить, что точно такое же в 7-ке можно сделать с помощью любого хранилища, аналогичного восьмерошному регистру сведений...

как правило статусы - \то оперативная деятельность.. спустя неделю - эти статусы ИХ ИСТОРИЯ никого интересовать не будут. важен будет только текущий статус. ну и пройдутся перебором...

(13) не скажи, история статусов позволяет оценивать эффективность подразделений обрабатывающих документы и обнаруживать узкие места этой обработки...

(13): итого.
0. Статус закодировать строкой фикс.длины (1, например), расшифровку по объектам - при необходимости(!) в отдельный справочник.
1. реквизит "АктуальныйСтатус", ясночо.
2. реквизит "СтатусыИстория" - строка длинная такая. В формате со спец.разделителями - хранила чтобы что надо в формате "дата+статус" (количество изменений статусов утвердается приказом, ответственные лица тоже). Доступ - только программый, куда надо прописать что надо для того чтобы показывало как надо и/или позволяло кому надо менять как надо.

(15) Строки достаточно сложно анализировать, особенно, если захочется делать выборку по дате.
Очень просится справочник - если в наименование запихать дату-время, то останется два реквизита - чей статус и сам статус.
При желании, можно сделать справочник, в котором перечислены статусы, а хранилище статусов сделать подчинённым ему - тогда можно будет делать отбор по двум значениям сразу (определённый статус как отбор, и определённые дату-время как сортировку).

(16): строки заранее отстроенного формата - очень легко анализировать. вне зависимости от построения выборки.
справочник и документ - разнотипные сущности, скрещивать их - плохая идея.

Историю проще в mlg писать

(18) отличная тема - анализировать текстовый файл в несколько сот мегабайт...

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

(19) Ну если анализировать надо не часто, то очень легко делается:

find "OpenSession" 1cv7.mlg >opensession.csv
и получаем файлик в пару мегабайт только с нужными данными.

Эмуляция регистра сведений.
И все это работает...

(13) Бывает нужно для "разбора полетов"

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

(0)
для скуля - своя табличка в скуле
для дбф - своя табличка в sqlite базе или в дбф-файле.

Далее тупо прямым запросом запись  и чтение таблички.
Всё собственно.

(25) Собственно, чем "своя табличка" отличается от "дополнительного справочника"? :-)))

(26) в случае дбф-базы прямым запросом не поапдейтишь справочник :(

927) серёзно?

"Здравствуйте. Буду краток. "
День добрый, Владимир Владимирович.

(27) Можно. Хотя писать туда я предпочитаю штатными методами...

Регистры, какие то отдельные таблицы в СКЛ. Ну насоветовали.
Чем справочник с прямыми запросами то не устраивает?.

(13) вот пример анализа: http://zalil.ru/32007272
и такое за каждый день. Можно делать сводный по дням - и сравнивать динамику обработки.
В принципе, вся эта информация есть "на кончике пальцев" у отдела логистики и у  сопровождения продаж, но тут она наглядна...

(31) люди путают "сущность" и "реализацию"

(28) вполне.
Апдейтить\инсёртить\удалять можешь через фоксовый провайдер, а у него другой индексный файлик будет..

Вообще, интересует штатный метод организации\хранения\выборки.

(32) ох...о ) Сколько времени строится отчет?
(22) а можно чуть подробнее

(35) 1. чуть более двух секунд.
2. справочник.

(36) а выборка прямым или штатным запросом или... ?

(37) Прямыми, ессно. Я штатными не пользуюсь, ибо они "кривые" :-))

(36) пишешь штатными методами, и.. в какой момент ?

у нас статусы есть, но в самом доке слеплены.

В 7.7 в отличии от 8 реквезиты объектов могут быть переодическими, вот и храни в них информацию. можно хранить для каждого измерения свой реквезит, а можно просто в один строчный собирать разделяя из ";" типа: "Объект;Дата;Время;Статус". А в отчетах просто получать данные хоть запросом хоть через объектную модель, хоть всё в таблицу значений грузить и дальше все что угодно можно делать.

как раз и без регистров, и возможности 7.7 задействуешь, которых в 8 нет))))

(41) Уже писали. Периодика хранится в обной таблице, зачем туда всю эту хрень писать. Строку потом замаешься парсить при обработке, плюс отборов не будет.

(39) В момент обработки соответсвующего шага БП.
(при выборе пункта меню, или при сканировании заявки, или при создании подчиненных документов)

(41) Нахрена плодить тормоза?

Делал тоже через справочник. Правда у меня требования попроще были, особого анализа не надо было. В основном для разборок между отделом сбыта и снабжения.

Тьфуты, это 1986....

(42) чего чего нет? Периодических реквизитов? Так это не "возможность", это кривой костыль.

(48) см (47)

(43) Что там сложного парсить, написал функции и она за тебя все делает.
Ну ещё 1 вариант, просто пиши и читай данные в отдельную dbf таблицу. И работает все быстро и парсить ничего не надо.
(47) Толсто

(48) Пользователям все равно им главное чтоб работало.

(50) Написать-то несложно, только вот работать это все медленно будет, плюс в запросе нормально условия не наложишь.

Коллеги, а прямой запрос формально считается штатным?

да работать не очень быстро будет наверное, хотя на sql версии несколько раз писал такие конструкции работало приемлемо и данных прилично
(53) нет

(50) ЗА-ЧЕМ?
Штатно - справочник без всяких периодических реквизитов с индексами несколько десятков тыс элементов потянет даже без прямых запросов...
Нафига эти костыли с переброской периодики в ДБФ и прочим?

(53) да.

+(55) а если делать своевременную очистку старых периодов, то количество этих записей и не будет превышать сотню тыс записей.

(0) т.к. в 7ке толку от запросов особо нету я сделал бы рекв. строка у документа неогр. и на форме таблица значений с колонками дата;статус приоткрыттии тз ЗначениеИзСтроки - призаписи -ЗначениеВСтроку. в отчетах скорость конечно просядет. А так если выписать для себя под это дело несколько функций по типу СколькоВиселВСтатусе(док.ссылка,"В ремонте") итд то можно лепить суперпупер  атчоты

(58) Че-то мне имхается, это еще более кривое решение, чем периодика. А по запросам к справочнику присоединюсь к (55), даже штатные вполне себе пойдут до определенного предела по объему, причем объеи этот достаточно приличный.

(56) cпорный вопрос. Вообще, "штатным", наверное, могут считаться только некоторые конфы от 1С. :-) Даже в зике были какие-то заплатки для багофичей...

(59) тут даже трудно сравнивать - "более кривое" или "менее"...

(61) Ну я помягче решил выразиться :).

(54)(56) прям голосование ) по (53)

Короче, история статусов, в общем случае - справочник&прямой запрос.
...вот так вот простенько и без вые..ов )

(63) даже, как говорят, не обязательно прямой - можно и кривым....
Суть в том, что это периодика с отборами. В клюшках штатно она не реализуется. в снеговике это регистр сведений. Собственно, суть одна и та же - таблица. А уж как конкретно ее сделать - дело десятое... Лишь бы работало быстро и без ошибок...

(63) Не, ну можешь туда еще блэк-джек и женщин легкого поведения прикрутить :)).

(63) Для начала можно штатными попробовать, а походу дела определишься по скорости.

(65) Если нормально спроектировать - потребность в них появляется очень быстро...

(67) В ком именно, в блек-джеке или женщинах легкого поведения :))) ?

(68) в обоих... типо, "и какая же [женщина л.п.] обрабатывала этот документ так, что он ..."

(67) Согласен. Тут определиться какую инфу считать, писать в момент записи статуса, какую на этапе обработки. Например, время нахождения в конкрентом статусе можно считать в момент смены статуса, и писать в рекизит, а можно на этапе формирования отчета. Или, например, предыдущий статус тоже хранить в реквизите справочника . Больше места займет хранение и больше время записи, но быстрее и проще обработка и выборка будет.
Это уже ТС определять.

(70) "предыдущий статус тоже хранить в реквизите справочника . Больше места займет хранение" - тебе жалко 9 байт? :-)))
Вообще-то, я храню для контроля прохождения бизнеспроцесса...
Но вообще, зависит от задач...

(71) Мне не жалко :)), я наоборот за такой вариант. Это как пример различной реализации одного и того же.

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

(0) в постановке задачи ты сам фактически дал ответы.
У тебя есть 2 разные задачи:
п.2: отчеты по текущему состоянию и итогам по ведущему объекту.
п.3: отчеты по смене состояний
При этом языку запросов 7.7 очень далеко до 8.*

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

Что хранить в справочниках, а что рассчитывать в запросах - тебе самому решать. Иногда быстрее расчеты делать при записи документа (одна запись на каждый переход), чем каждый раз при формировании отчета. Все зависит от того, что у тебя чаще выполняется и что критичнее.
Периодические реквизиты - имхо здесь зло.

достаточно 1 справочник с реквизитами
-Код
-Объект (только для групп) с отбором
-Статус (для групп и элементов)
-Время/дата в удобном формате
Для удобства построения последующих отчетов по анализу можно добавить реквизиты.
-прошлый статус
-времянахождениявстатусе


На каждый объект делаем группу, внутри группы сама история.

Текущее состояние получаем:

спр.ВыбратьЭлементыПоРеквизиту("объект",объект,0,1)
актЭлемент=спр.ТекущийЭлемент();
актстатус=актЭлемент.статус;


историю получаем:

Спр.Использоватьродителя(актЭлемент);
спр.ПорядокКодов();
спр.ОбратныйПорядок(1); // тут изменяем хронологию
спр.ВыбратьЭлементы();
Пока спр.ПолучитьЭлемент()=1 Цикл
   Сообщить(""+спр.Код+" "+...);
КонецЦикла;

(74) что есть "заранее рассчитанную информацию по переходам между состояниями"?
Текущее состояние - еще понятно (это если не хочется делать общий реквизит)
"При этом языку запросов 7.7 очень далеко до 8.*" - потому и применяем прямые запросы...

(75) Неудобно, если нужно делать отборы по статусу...

(77) ну добавить отбор/сортировку на "Статус" и "прошлыйстатус" - тут уж по желанию

(75) это очень хорошо, если надо получить данные по одному объекту. А если надо быстро отчетом по большому числу объектов - то уже не вариант.
(76) при прямых запросах можно вообще сделать полный аналог РС, тогда и тему поднимать не зачем.
"заранее рассчитанная" - зависит от требований отчетов: суммарное время в состоянии "В обработке", признак нарушения регламента по времени, и т.п. - т.е. то, что можно получить перебирая и анализируя историю состояний, но с целью ускорения отчетности вычисляется сразу при смене состояния.

(79) Если отчет по большому числу объектов, то реквизит Объект делать не только для групп, но и для элементов + запросы/выборки для отчетов делать "без групп"

(79) Это во второй писать надо, припереходе состояния...

(80) тут надо определиться - что важнее: сэкономить дисковое место или повысить скорость отчетов
(81) то что длительность одного стояния должна быть во втором, это очевидно. Но в состоянии "В обработке" документ может находиться несколько раз. И для этого часть информации (которая нужна очень часто и получить можно перебором истории состояний) надо дублировать в первом (в котором записей столько, сколько ведущих объектов, а не сколько всего переходов).

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

(32) красиво! ;-)
а какой практический смысл такого анализа статусов...?
у меня в принципе тоже статусы пишутся/регистрируются, но пока что надобности в анализе таком не возникало.. потому как абсолютно по барабану в каком статусе заявка находится и вся предыдущая статстистика тоже - заявка выданная вовремя - должна быть собрана к требуемому времени. А выполнение этого условия никаким образом не зависит ни от истории статусов, ни от длительности этапов БП - все упирается в тупую статистику - а от нее - определение временных норм... так что единственный (вроде как) польза от таких красивых картинок - это определение технологических норм на ту или иную операцию/статус и обеспчение потребного количества людей/исполнителей... как-то так...
.
вот, например, у меня "статистика" нахождения заявки в статусе "отбор с мест хранения"
http://s017.radikal.ru/i412/1110/8d/9808a220197c.jpg
.
сами статусы по каждому объекту - пишу в табличную часть документа-регистратора - в котором фиксируется история "жизни" заявки...

http://s017.radikal.ru/i409/1111/bb/b21ec865a604.jpg

http://s43.radikal.ru/i101/1111/96/b4e775c800ee.jpg
/
в итоге? надо сильно думать для чего нужны статусы, какая в будущем будет обработка этих статусво и прочее...

(84) По этим отчетам и наличию людей зачастую идет заказ дополнительного персонала ("временные работники" типа студенческого отряда)
(86)при "разборе полетов" - "почему затянут вывоз" - видно, в каком месте скапливались заявки - и соответственно, ответсвенное подразделение получает "по шапке"

+(87) слил.ру не работает почему-то, закинуть скрины не могу

радикал тоже не пашет, млин..

заработали, вроде...
У меня есть, допустим, такие отчеты - обновляются каждые 30 секунд:
http://s017.radikal.ru/i427/1111/99/0555b017e1cc.jpg
Именно по ним принимается решение по привлечению дополнительных грузчиков.
Или такие журналы:
http://s017.radikal.ru/i416/1111/74/b2a199233803.jpg
по ним видно, что сейчас в сборке, кто собирает, что собрано, что подготовлено к отгрузке (готов пакет документов) и т.п.

(87) угумс... у планирую сигнализировать о нехватке "ресурсов" не постфактум, а еще на этапе запуска "заявки" в систему - если "не влазит" по ресурсам - то тут даже считать не надо - на графике ПОТОМ будет видно, что возник затык... ;-)
.
(9) у меня мониторчик не такой красивый... ;-) вскорости буду переписывать... на выдачу более развернутой инфы.. но подход немного другой будет... от крупных кнопок к детализации только при необходимости...

(91) У нас сложнее - вывоз заявки могут отменить из-за превышения дебиторки/просрочки. Поэтому заявки прилетают в течение дня, маршрутизируются после закрытия приема, а собираются выборочно (в зависимости от того, может быть "закрыт" клиент, или нет)
"мониторчик" тоже детализирует - окна "динамические". Хотя спорить с тобой по проработке интерфейса - бессмысленно... порвешь как тузик грелку... :-))