Теоретический вопрос:

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

всего порядка десятка статусов.

Сейчас журнал документов (ибо динамический список) все эти статусы считает на лету диким запросом.. но этот запрос не просто дик но и тормознут.

Вопрос: какова будет оптимальная схема хранения множества статусов в готовом виде для облегчения работы журнала документов?


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

есть идеи?

(393) У нас с тобой спор в другом: нужен ли регистратор всегда или ИНОГДА это будет абсолютно искусственная сущность, которая не нужна.

(394) Ты то говоришь о полном хранении историй, то говоришь что документы не нужны :)
Одно из двух - либо у тебя полная анархия с ручными изменениями статуса, либо у тебя всё делается документами.
В анархии история не нужна.

Твои 10 одновременно разных статусов это 100 записей одного справочника в различных вариациях - и тогда да - это можно "вкарячить" в исходный документ.
Но собственно и мысль об РС с ключом "документ+статус" не плоха.

Сори.
Далее тему не читал. По видимому - все не так однозначно :)

А хранение истории движений в самих движениях - даже не знаю как назвать...
Утопия например. Наверно такой эпитет подходит. Как я уже говорил - приведенная тобой выше схема абсолютно нерабочая.

А решение красивое четкое было предложено давно. РС с регистратором (ну или РН с пустым ресурсом), все движения спец. документами, и ведение истории изменения документов.

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

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

Все не читал. Вариант простой рс периодический подчинен регистратору. Измерение документ вид статуса (справочник виды статусов) и ресурс - значение статуса. Все.

(395) Блин, забавно. Ты добавляешь к моим словам свои домыслы, а потом говоришь, что фигня получается. Это как добавить в манку вкуснейшего ядреного хрена и сказать, что фигня твоя манка с хреном :)

(402) Вроде как наоборот - ты добавляешь к моим словам свои домыслы :)
Например чего стоит пост (391)

Кхм ... Не ссортесь

(402) Хорошо. Давай иначе - в каком случае к движению (изменению) статуса не нужен регистратор?

Ребята, начнём с того, вы путаете оперативную работу и бухгалтерский учёт.
С точки зрения бухгалтерского учёта действительно не должно быть непроведённых документов и каких-то следов от них в базе.
А вот когда мы ведём оперативный учёт, то как раз у непроведённых документов и будут статусы, так как проведённые документы чаще всего будут считаться завершёнными.
Что касается установки статуса отдельным документом, то, это, наверное, лишнее, так как получается, что кроме самого статуса ещё и ведутся записи в таблицу документа.
С другой стороны, статусы может ставить как пользователь (тогда нужно запомнить момент установки), так и сама система, когда выполняет какой-то алгоритм по изменению статусов.
Кстати, если кто-то боится, что статусы могут тормозить и мешать, то можно сделать отдельное регламентное задание, которое меняет статусы по заранее заложенному алгоритму.
Тогда ошибка "тёти Маши" будет выглядеть как корректировка документа выписка с причиной "Ошибка ввода" после чего система проведёт анализ и расставит статусы документов, а также может сделать сразу вывод о потерянном из-за ошибки времени и затраты на устранение ошибки - товар-то могли и отгрузить.

(406) конечно же у непроведенных документов есть статусы, которые им присваиваются другими, проведенными документами.

мы похоже по кругу идем. Обсуждается уже в который раз очевидное и необсуждаемое.

(406) Кхм , кхм .

В оперативном учете не волнует непроведенный документ (если данный тип ДОЛЖЕН формировать движения)

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

(406) насчет установки статусов отдельным документом.
Еще раз рассказываю - берется пачка из сотни документов, забивается в ОТДЕЛЬНЫЙ документ сканером штрихкодов, в шапке проставляются новые стутусы, и документ, отдельный документ который ты считаешь лишним - проводится.

(410) в день у нас таким способом получают статусы тысячи документов :)
как я уже говорил штрихкодировано практически все, включая входящие документы и чеки.

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

Ладно, про вопрос "больших данных" можно и не вспоминать.
Анализ того, что было, можно вести отдельно от основной базы.

На самом деле, в 1С плохо то, что всё вообще идёт "от документа".
На самом деле, все действия должны идти "от события", то есть в вашем случае, когда сканируется документ, то система должна понимать, что с таким документом что-то произошло - например - вернулся подписанным от поставщика и т.п.

Но 1С событийную модель пыталась воплотить только в бизнес-процессах и не до конца понятно, так как для событийной модели нужны совершенно другие подходы - там вообще нет понятия "распроведён" или "отменён" - объекты под действием событий переходят из одного состояния в другое.

(412) Ну у меня то же . Отчасти , с не очень большой детализацией , но в общем пока хватает .

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

Но собственно статусы это другое , у нас они служат для получения очень быстрой оперативной информации по документу (списку документов)

И да , я знаю , идет дублирование данных :) Но скуль тянет :))

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

(413) >На самом деле, в 1С плохо то, что всё вообще идёт "от документа".<

А по моему хорошо :)
Но спор на эту тему уведет ветку в обсуждение глубоких теоретических эмпирией что станет офф-топом

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

(415) А кто мешает все данные хранить в самом событии ?

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

(417) А кто мешает считать документ изменяющий статусы "событием"?
Причем тут входящая корреспонденция? Тут идет сортировка документов по отделам и статусам. Идет документ (заявка покупателя) в сборку? Отсканировали его в табличную часть документа "Сборка", у которого еще куча параметров в шапке. Попала накладная в машину, есть соответствующий документ, у нас называется "Товарный отчет" (ну можно называть путевым листом, или еще как-нибудь, это неважно), в табличную часть которого сканируются документы. И у него тоже куча параметров в шапке. И т.д.

(418) Как бы, получается, что то на то и выходит, только я бы несколько событий в один документ не стал бы объединять, так как потом проще понять, что было, когда каждое событие описывает только один объект.

(419) То есть накладные которые мы собираем в одну машину - не надо объединять в табличной части одного документа?
Или если водитель привез пачку "правильно" оформленных документов без претензий - их не надо объединять в одном документе "изменение статуса"? Или сборщик физически собирает пачку заявок - их не надо объединять в документе "сборочный лист"? А если мне нужно распечатать  товарный отчет, сборочный лист и т.д. естественно опять-таки с штрих-кодом для легко поиска в дальнейшем? Это тоже не аргумент?
А что ты предлагаешь? Какие ваши предложения? :)

(416) это однозначно плохо. особенно в оперативном учете. в бухгалтерии это канает т.к. бухия только фиксирует что-то - эту схему тупо перетащили на ОУ.
.
например: почему в куче контор сталкиваешься с прямо-таким нечеловечесикм сопротивлением манагеров в части например обработки заявок? они все колотят задним числом в одну и ту же исходную заявку. Потому что для них "заявка" - это процесс обслуживания клиента. а система корректировки заявок (попытка нарисовать такой процесс через оформление документов, на примере ТИС) - выносит им мозг напрочь. Потому что даже тривиально - когда работая по схеме "корректировки заявок" - манагер в одном дне видит несколько заяовк от одного клиента с разными сумамми - он просто теряется. потому что это противоречит его "логике" - и здесья с манагером кардинально согласен. В итоге: пришлось делать дополниетельный нумератор и внедрять его взаявки - то есть сугубо "номер  сделки" - этот номер идет красной нитью в обслуживании заявки клиента. и манагеру показывать только текущее состояние заявок, пряча псевдореализацию процесса некими оторванными от реальности "документами".

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

А не проще ли их, раз этот набор документов имеет большую общую шапку, печатную форму, и по сути является отдельным учетным внутренним документом - не проще ли просто взять, и объединить их в один документ? Один раз забить шапку, и просто отсканировать их скопом в табличную часть?

(421) У нас нельзя править заявку - точнее исправление заявки - это исправление, ЧП, с фиксацией исправления, и записью в историю. Если была предварительная заявка - то такой документ и делается, и дальнейшие изменения вводом на основании.

(420) Зачем объединять накладные в один документ, если в событиях будет сказано, что их поместили в одну машину, причём, не факт, что все три и сразу - а если маршрут и загрузку выбирала сама система, то она просто покажет результат и будет отслеживать, что это выполнили.

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

(420) у мну заявки на отгрузку (реализации) в одну машину - объединяются в "отгрузочные листы" по машинам. Причем в листы отгрузки идут не сами заявки, а уже сгруппированные в путевые листы или в Транспортные накладные. Причем в ТН или ПЛ может быть как одна заявка, так и несколько. У меня так вот.

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

(423) > если в событиях будет сказано, что их поместили в одну машину,
- как конкретно ты это скажешь событием?

(423) В документе расписывается водитель и экспедитор как МОЛ , данный документ не просто "событие" , это документально зафиксированный факт передачи материальных ценностей со склада в транспортный отдел

(426) Таки у меня в модели есть объекты, и связи между ними, а события меняют связи и данные объектов.
Причём, связь не удаляется, а просто делается недействительной.

(423) В каких событиях? Ты каждый раз будешь выбирать машину? Вместо того чтоб один раз выбрать машину, а потом пройтись сканером, ты сделаешь выбор машины при каждом сканировании документа? Боюсь что за это тебя уволят.

Система? Пока AI не дорос до того чтоб лучше человека составлять маршруты и правильно распределять накладные по машинам, и естественно это делается в полу-автоматическом режиме. И почему три? Намного больше накладных влезет в машину.

(425) Водитель. Привез документы. В одно время. Он их привез не в момент сканирования. Есть время прибытия водителя.

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

(427) Так этот бумажный документ может быть и отчётом по базе. В момент передачи мы фиксируем что передали и кому.

Заполнение шапки - 10 секунд. Сканирование 20 документов - 10 секунд. Итого 20 секунд на заполнение документа.

При выборе шапки в каждом событии - 20*10=200 секунд. В 10 раз больше. Потребуется взять на работу в 10 раз больше сотрудников. Извините, но у нас и так огромный отдел логистики.

(430) Ну вот такой контроль у меня и реализован на уровне "логистических статусов"

(429) А кто сказал, что вообще что-то будет выбираться ?
Водитель привёз документы и сдаёт их, при этом идентифицируется как сам водитель, так и тот, кто принимает.
А уж как эти документы будут передаваться - это уже дело десятое. Главное, что никто не заставляет закрывать форму, пока всё не будет введено.
Плюс бонусом будут события - "начат приём документов" и "окончен приём документов".

(431) "отчет по базе" как говорится к делу не пришьешь :)

Хозяйственные операции должны "квантоваться" , документ и есть такой квант

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

(435) угу, только у нас произошла подмена понятий. документ должен рождаться в ИТОГЕ выполнения некой цепочки действий. а не наоборот.

(435) Документ - это отражение бумажной реальности - он, в данном случае, необходим, но никто не говорит, что мы просто будем рассматривать документ "как есть", у нас будет и история его ввода, разбитая на события, причём если потом будет привязка видеонаблюдения, то будет ясно к чему, а что можно привязать к просто документу ?

(434) То есть всё будет забиваться в одну форму, но это не будет один документ?
В журнале он будет идти одной строкой, но это не будет один документ?
Он будет иметь свою, отдельную печатную форму, но это не один отдельный документ?
В отчетах он будет идти отдельной строкой, но это не документ?
Мне не кажется что ты хочешь поставить всё с ног на голову?

(438) У меня привязывается видеонаблюдение и телефонные разговоры. А что? Правда видео пока в тестовом режиме, на одном компе.

(439) В журнале действий будет не одна строка, так как событий было много. А в отражении списка полученных документов, подписанных передающим и принимающим - это будет один документ, точнее таблица, которую они подписали.

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

(437) Есть документы которые ПОРОЖДАЮТ цепочку действий (событий , других документов , фактов обработки который учитываются статусами и т.п.) , есть документы которые ПОДТВЕРЖДАЮТ выполнение некоей хоз операции , или факта

(438) У меня есть история изменений. Документа! Одного, с кучей первички в табличной части. И журналируются критичные ситуации во время ввода.

(439) в самом общем случае - документ состоит или только из шапки или из одной строки.

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

(441) Ты всё ставишь с ног на голову.
В любой учетной системе набор событий объединенных общей записью называемых шапкой - называются документом.

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

У документа есть одна дата - то есть момент подписания, всё, что было до или после - это уже вне документа.

(446) Есть два понятия документа.
1. в (447)
2. Печатная форма.

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

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

(448) Ты хочешь на ходу придумать новое определение документа?

(446) Документ МОЖЕТ иметь печатную форму . Документ это всего лишь квант фиксирующий или инициирующий (что не мешает эту инициацию зафиксировать) некие действия .

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

давайте остановимся на простом постулате.
АВТОМАТИЗАЦИЯ ЕСТЬ ЗЛО.

(454) ВЫДЫХАЙ !!! :)))

(453) Можешь яснее выразить свою мысль.
Конкретный сотрудник может одновременно сканировать первичку в разные документы по разным отделам?
см. (429) и (432)
При этом количество ошибок станет просто зашкаливающим.

(452) Если так подходить, то в базе вообще нет документов - есть только таблицы, в которые что-то пишется, и объектов там вообще нет - только байты.

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

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

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

(457) Опят ты все с ног на голову переворачиваешь . Вот что бы ТАК не подходить к учетной системе (на уровне таблиц и байтов) и вводится понятие "документ" - набор событий и данных объединенных общей записью (с)

(406) http://its.1c.ru/db/v8std#content:2149184252:hdoc

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

(459) Да, и этот процесс является по всем признакам отдельным документом, и удобней его хранить именно в документе в базе.

(463) Все критичные документы у нас пишутся построчно.
И даже на наших объемах это ни капли не замедляет.

СТОП !!!

Таки ветка скатилась в теорию рассуждений о том что такое документ , хорошо это или плохо и т.п.

Говорим о статусах документов !

Критичные части, например история взвешивания по конкретному товару пишется во внешнее хранилище.
Так-же построчно.
Насчет сбоев - например какие? Что-то у нас при наших объемах массовых сбоев нет и не было.

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

(465) нафиг писать документы построчно? проще писать документ из однйо строки = событие. "одинаоковые" объединять владелцем, указывающим на документ-шапку.

> содержимое-то бумажки никто не проверяет.
никто не мешает в ШК зашить "подпись" документа. при сканировании ШК - ищем док в базе - сверяем "подпись" дока в базе и подпись из ШК - сошлось зхначит ок., не сошлось - кто-то что-то нахимичил...

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

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

(469) Так я о том и говорю, что зачем что-то писать целиком, когда можно писать по частям.

(472) Ну только если на выходе из принтера поставить сканер, да и то, есть вероятность, что как раз сканер его и зажуёт.

(469) Чтоб в случае критической ситуации все строки сохранились. Восстановить взвешивания например достаточно серьезная проблема. Особенно если товар уже утащили на склад.

(469) Ты уверен что проще? Я вроде написал что нагрузку на базу построчная запись документа не напрягает. А документ один - например Прием продукции, которые взвешивает конкретную накладную.

К сожалению, 1С не умеет записывать документы по частям - она всё равно пишет всё и сразу.

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

(477) И что? Ты сталкивался с тем что простая операция построчной записи вызывает тормоза?

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

+ (478) Заявка будет светится как не попавшая в сборочный лист. А чтоб её отсканировать нужно распечатать. Накладная как не попавшая в товарный отчет, а чтоб её отсканировать нужно распечатать.

(478) Угу ++

По этому  это ставится в момент нажатия кнопки "Печать" или групповой обработки печати пачкой

(480) В нормальной системе не должно быть документов на тысячи строк. Они нечитабельны, и их слишком сложно редактировать.

(483) Ну вот мы к тому и приходим, что нечего держать всё в одном документе. А тысяча строк - это небольшая газелька с товаром по маршруту.

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

(484) Если тысяча строк - то нечего. А если до сотни, а в среднем около 10-20, как у нас сделано - то не просто можно, а даже нужно.
Большие у нас только документы ввода остатков при обрезке - они разбиваются на части.

Ладно - пора спать - всем удачи.

Выписки огромные, но выписка собирается из отдельных документов "строк выписки" в системе. Объединяются действительно только формой. Ну тут еще есть одна причина - у строк выписки есть табличная часть. Необходим список документов погашаемых строкой.

(483) нифгиа себе заява.. у меня заявки от клиентов на 700-800 строк - не редкость. бывают и более 1000 строк.

(93) > Задача-таки не в том, как правильно организовать хранение статусов, а как организовать быстрый вывод их в ДС.
/
при большом колве документов вывод статусов в ДС не имеет смысла. ибо неясно какую КОНКРЕТНО задачу решает такой вывод.

(405) Движение дока по бизнесс-процессу. Сейчас пишем небольшой блок по учету, согласованию и контролю входящей первички с помощью объекта бизнесс-процесс. Нам поставщик присылает документ. Этот документ поступает на согласование к экономисту. Ему создается задача (не документ, а объект бизнесс-процесса у которой два состояния "Выполнено"/не выполнено), после выполнения документ идет финансистам и логистам ,которым генерятся свои задания. После их выполнения документ идет дальше и потом процесс заканчивается. Так вот. Здесь нет документов регистраторов. Здесь даже регистров нет. Но есть жесткая, регламентированная последовательность движения документа по статусам (этапам бизнесс-процесса). Здесь можно сделать документы-регистраторы, но есть вопрос: НАФИГА они здесь?

(489) У него все, что не соответствует учеты в ЕГО компании априори бред и бесогонство :)

(491) Собственно это интересно.
Если нужно отслеживать этапы прохождения некого набора событий насколько удобно использовать бизнес-процесс