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

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

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

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

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


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

есть идеи?

(0) Под "полностью пересчитывается каждым документом который влияет хотя бы на один статус" ты имеешь в виду подписку на событие, которая обсчитает статус вовлеченных документов?

на ум тока периодический рс приходит.

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

(3) Плохой вариант.

(0) Все обычно делают эти статусы через РС.

(3) каждый раз документ перезаписывать? А в нем может куча табличных частей.

(1) да
причем полностью ВСЕ статусы.. и в периодический регистр датой вовлеченного документа..

(3) неее.. что то на уровне подкорки мне подсказывает что писать в документ эти статусы не очень хорошо..

(5) вопрос в том что статусов 10 :)
разных
разными событиями ИБ статусы меняются..

(8) зато журнал будет быстро работать ))

(10) ну фиг знает..

хотя вот смотрю шедевры типовых -  корячат статусы прямо в документы..

правда например в БП3 при попытке разнести оплату при открытом счете вываливается ошибка блокировки...

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

(11) Так там статусы меняются только пользователями вручную - вот и корячат. А если твои статусы будет менять сама система - регистр сведений. Главное в запросах дин. списков правильно расставить конструкции компоновки, чтобы "шибко вумный" пользователь не смог поставить систему раком.

(11) ты же при смене статуса документ не перепроводишь, только записываешь и поэтому проще всего хранить статус в самом документе

(4) А чем плох вариант хранить статус непосредственно в документе?

Например состояния документа "Проведен" или "Помечен на удаление" фактически тоже являются статусами, но они же не выведены в отдельную таблицу.

(15) Дублированием.

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

а например статус "готовая продукция передана на склад" меняесят контролером ОТК после проведения двух других документов и причем у сотрудника контролера ОТК не прав лазить в заказ..

(0) чем плох регистр сведений?

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

(17) У документа может быть одновременно несколько статусов или только один на текущий момент?

(19) Одновременно регистр сведений для истории изменений и в самом документе.

(20)  у документа 10 разных статусов одновременно.. и со временем некоторые из этих статусов меняются из других документов другими пользователями

(21) мсье знает толк.

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

(22) регистр с 10 ресурсами

(23) Чтобы не заморачиваться запросами по статусу документа.

(0)
Регистр со статусами не айс с точки зрения блокировок
не зря в типовых статусы в самих документах

(26) а чем блокировка документа лучше чем блокировка регистра ?

(27)
тем что о них нужно будет задуматься в случае РС

(28) а о блокировке документа думать не надо ?

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

не ?

(23) Чем плохо двоить информацию?

(26) В типовых и так и этак, типовые разные.

(0)
Может в доп. свойствах или доп. реквизитах?

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

(33) Сорри за очепятки.

+(33) собственно интересует в какой стадии в каком количестве что находится.

(33) периодический регистр сведений ?

вопрос:

есть измерение: заказ
есть реквизиты:

"статус1"
"статус2"
"статус3"

у тебя документ от 01.01 меняет статус1
затем через месяц другой документ меняет статус2
еще через месяц третий документ меняетт статус1
и тд..

то есть статусы меняются в разное время разными документами.


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

(36) Добавь в измерение НомерСтатуса и не надо переписывать

(32)
Доп.свойства - это РС
Доп.Реквизит - это ТЧ документа
Так что это как раз и обсуждаем где хранить в РС или в документе

(37) а что это даст ?
статусы  - независимы по смыслу..

то есть сначала поменялся статус1
а в другом заказе статус1 поменяется последним..

(36) Храни независимые статусы в разных регистрах: Оплачен, отгружен - независымые статусы

(39) Ты можешь менять статусы независимо и паралельно

(36) Может сделать как в раузе учет затрат? Вынести комбинацию состояний в отдельный справочник... Это так, что в голову пришло.

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

а документ может находиться одновременно в нескольких статусах?

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

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

опишите критерии оптимальности.

(44) может, см (22)

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

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

менеджер же в журнале видит все статусы сразу..

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

(49) Когда была такая задача я к (42) склонялся. Ресурс - элемент справочника со всеми десятью статусами в полях.

(50) а почему не 10 ресурсов?
в чем выигрыш

Ну напрашивается периодический РС с измерением Заказ, ресурсами - все 10 статусов, и регистратором - документом, который меняет статус. Можно менять и вручную, если в конфе есть документ наподобие Корректировки регистров.
А возможно получится использовать доп. свойства документа, если они поддерживают периодичность.

(51)
Размер базы будет меньше видимо.

(53)+
И при добавлении нового статуса структуру РС не придется менять, только справочника, правда заполнять тот справочник будет муторно.

Говорят в 8.3 срез последних в отдельной таблице хранится? Так ли это?

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

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

*остатотпо > остаток по

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

Все же статус в измерение, сотояние в ресурс. Разные статусы - разные процессы и они должны отслеживаться независимо друг от друга.

а почему не сделать регистр с измерениями "документ" и "вид статуса" и с ресурсом "Значение статуса"?

(60) в журнале нужно в одну строку вывести 10 статусов.

10 левых соединений делать ?

(61) почему. Один запрос - срез последних по измерению "Документ". ты получишь таблицу значений: вид статуса - значение статуса

(58) Все статусы булевы. Он или есть (оплачен), или нет (не отгружен)

(63) Совсем не обязательно. Партия зарезервирована, отгружена, доставлена.

+(64) Документы на оформлении, отправлены, подписаны.

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

Но такая система не гибкая

(65) А не факт что это один статус, а не 3 разных

(66) зато надо получать объект. А объект может быть мама не горюй каких размеров

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

(67) СМК в помощь.

(66) А если хранить в ТЧ документа (аля Дополнительные реквизиты), тогда и объект получать не надо

(67) СМК это что?

(72) Управление качеством. Состовляющая ее описание и стандартизация процессов на предприятии.

конечно-же (59) и (60)

(61) а что мешает?

ИМХО, есть только 3 различных корректных подхода:

1) РС документ/вид_статуса/значение_статуса либо 10 разных РС (что с т.з. блокировок проще)

2) вариант с РН, причем РН остатков так или иначе будет разбухать, а для оборотного - придется делать запрос за большой период времени

3) полу-оффлайновая непериодическая комбинация: РС с комбинарованным состоянием из справочника, где _каждый_ документ, который может повлиять на состояние переводит в состояние "изменен/нерассчитан", а регл. задание меняет состояние таких документов в верное.

Все остальные варианты приводят или к потенциальным конфликтам блокировок, или к некорректной картине при изменении задним числом.

(68) Почти всегда выборка статусов делается за ограниченный период , так что особо не страшно

о каких блокировках речь? десять записей в регистр в момент проведения - это блокировки?

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

(78) А чем регистр накопления с пустым ресурсом отличается от регистра сведений?

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

Хотя, конечно, вариант  периодического РС со структурой документ/вид_статуса/значение_статуса самый напрашивающийся - а значит, скорее всего и самый   подходящий.

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

(30) да. А еще круче - троить. Попробуй.

Имхо тема интересная. Сделайте голосовалку. Сам всегда делал через реквизит многим клиентам. Плюсы - не надо переписывать множество отчетов, можно быстро делать отборы с списках документов, в динамических списках, быстро получить текущий статус для всяких проверок. Минус - это блокировки. Но при нормальном построении запросов, индексации измерений регистров блокировки либо пропадают совсем, либо возникают очень редко. Но и железо в этом случае должно быть норм. базы в которых работает через реквизит 15-50 человек одновременно +  в некоторых базах активные обмены РИБ.

+(82) еще минус в этом подходе что статус может сменится когда открыт непосредственно сам документ со статусом, тогда косяк при записи возникает. В итоге взвесив все плюсы и минусы я прихожу к выводу что пока у меня реквизит это более плюсово чем РС.

+ (82) я в принципе даже не знаю были бы эти блокировки когда организовано через РС, не разпирался, просто оптимизировал расччеты статусов, помоему было бы тоже самое и с РС. тогда остается проблема только с (83) -  смена статуса когда док кем то открыт.

(74) чем комбинация  "заказ/вид статуса/значение статуса" будет луче чем "заказ/статус1/статус2/статус3/статус4/..../статус10" ?

ведь для построения журнала с текущими статусами (это по сути единственное ради чего вся эта возня) у меня при 10 ресурсах будет 1 левое соединение, а при комбинации "заказ/вид статуса/значние статуса"  будет 10 левых соединений..

(85) Ты же сам сказал, что обновлять эту портянку будет сложнее

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

(85) могу предложить изврат. Добавь системный справочник. Реквизиты - все твои статусы. Элементы - все возможные варианты статусов. В регистре будет измерение док, а ресурс - ссылка на этот справочник. Обновление будет хитрым, но не ресурсоемким, а вывол в ДС двумя няшными левыми соединениеями. Или даже внутренними :-)

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

(88) Зачем нужен изврат, если всё делается четко и правильно, и средств в языке для этого достаточно?

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

имхо, РС + регл.задание тут лучший вариант

(54) ага.Такой справочник на сочетание 10 признаков под 30 млн элементов легко потянет)).

(90) Задача-таки не в том, как правильно организовать хранение статусов, а как организовать быстрый вывод их в ДС.

(92) если состояния бинарные, то 1024. А если есть определенные условия (не может быть отгружен неоплаченный товар, к примеру), то пару сотен :-)

(0) а вообще, внедри бизнес-процесс.

(86) ну почему сложнее?
сейчас я пихнул  в общий модуль процедуру которая рассчитывает  все статусы одним запросом (то что раньше журнал делал) и результаты кладет в регистр.

то есть при проведении каждого документа потенциально влияющего на статус - обновляется состояние ВСЕХ статусов на момент проведения документа


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

(96) а потом у тебя изменился старый документ, который менял один из статусов.

(97) ну так если периодический регистр сведений со статусами то что так что эдак - период в регистре это дата документа изменяющего статус..

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

то есть пофиг - что так что эдак..

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

(98) в смысле пофик?

док0 - заявка.
док1 - оплачен
док2 - отгружен.

у тебя удаляется док1, то есть снимается оплата (например ошибочно заведено не на того контрагента)
а док2 в твоем случае делает неправильное движение.

(100) убедил.
ты прав..

так действительно будет корректнее.

спасибо..

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

(81) Глупость пишешь, двоить информацию нормально, например в 1С она задвоена.
Важнопонимать принесет ли задвоение доп плюсы.

(22)  >>  у документа 10 разных статусов одновременно.. и со временем некоторые из этих статусов меняются из других документов другими пользователями

использую для этого 2 справочника (v7)
- логСменыСтатуса - история изменения статуса с документами
- логСменыСтатусаФинал - финальные статусы документа
соответственно ссылка на единственный на документ экземпляр логСменыСтатусаФинал торчит в документе и определение статуса самого документа не представляет сложности.
Единственный гемор - процедура многотомная процедура переключения статуса.

переделываю на схему "заказ/видстатуса/значениестатуса" посмотрим что получится..
щас базу в 10 000 заказов конвертну гляну..

(102) От блин удивил так удивил ...

(105) Хотел как раз этот вариант предложить.... самый универсальный

У меня логистические статусы последовательные :

1 Распечатан складом
2 Набран
3 Погружен
4 Доставлен
5 Подтверждены документы
6 Документы в архиве

Следующий статус нельзя присвоить если не было предыдущего . Таки через реквизит документа  числовым значением и дата -время смены статуса . Алгоритмы присвоения-отмены упростились (+-1)

(100) м, а зачем здесь делать привязку к регистратору?

(109)  не нужно.

(110) (109) ты меня путаешь :) изменение производится только документами.

(111) Ок. А зачем все равно делать привязку к регистратору? Без нее не будет проблемы с изменениями задним числом и будет максимально эффективно решена задача вывода данных в ДС.

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

(112) хороший вопрос..

На учет статусов через реквизит пошел осознанно (то же рассматривал в свое время варианты со справочником и регистром) .

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

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

Метода не универсальная , но для конкретного применения - наиболее оптимальная

(115) Ну, ты по факту "срез последних" на документ выводишь. Нормально, иногда даже необходимо :-)

(112) то есть как не будет? У нас в день три документа изменяющих статус. Один делается непроведенным. Какой статус в итоге? Проводим/перепроводим документ неким временем в середине дня, какой в итоге статус? Ты не знаешь, есть ли позже документ или нет.
Или ты при каждом проведении будешь перебирать все документы за день?

(112) Для истории. Я тебе больше скажу - некоторые статусы в типовых хранятся в регистрах накопления... У меня для одного из производств статусы на регистрах накопления сделаны...

(116) :)

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

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

Конкретной задаче - конкретное решение :))

Можно поставить вопрос иначе - чем тебе регистратор помешал?
У тебя автоматом при проведении/снятии с проведения в регистре правильные данные. Как ты это организуешь без регистратора?

(117) У вас как статус рассчитывается? По документам что ли? У меня например все статусы на основе регистров сделаны, т.е мне пофигу сколько документов до и сколько после, смотрим остатки регистра и все.

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

Без регистратора можно. Инфа записывается текущей датой в регистр и все. Типа можно отследить реальную историю смены статусов.

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

Тоже возникала проблемма статусов. Программистское нутро поначалу отказывалось писать статусы в док. Но пришлось. Оправдано в случае когда чтение преобладает над записью. А со статусами так всегда.

(122) Скорее даже не так .

Оправданно когда преобладает получение информации Документ-->Статус , против Статус-->Документы (или даты)

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

(121) Рассчитывается? Зачем его рассчитывать? Он хранится в регистре на текущую дату. Документ тоже ничего не рассчитывает. Он делает движения по новому статусу, и всё.

(117) Берешь срез последних по статусу. Получаешь текущие значения, меняешь, допустим флаг "Оплачено" на Истина. Отвязываемся от документа, переходим к событию, которое происходит именно сейчас, а не в дату документа. Уверен на все 100, что рано или поздно понадобится дать права главбуху или другому боссу "ручками" менять статус. Например, дир в сауне хорошо отдохнул с директором контрагента, тот подогнал хороших девочек, и наш решил отгрузить ему партию-другую без оплаты вообще. Девочек по учету не проведешь, деньги из ниоткуда не возьмутся, тупо спишем потом в убыток, а процессы тормозить нельзя.

(120) Ты про вариант, где измерения "Документ, ВидСтатуса" или какой?

(125) ну тут вопрос примерно в следующем:

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

(128) сейчас все просто - регистр накопления.. остатки и если конечный остаток нулевой то типа готов..

для одного-двух статусов - нормуль, работает..

а вот когда этих статусов 10..
возникает вопрос в необходимости оптимизации..

(129) плюс у меня вопрос, с точки зрения нагрузки на сервер и соответственно быстродействия - сделать левое соединение к 10 регистрам накопления будет по быстродействию сильно отличаться от 10 запросов к регистру сведений срезу последних ?

(126) Глупость какая-то. Документ "изменение статуса".

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

(130) Если тебе так нравится регистр накопления - кто мешает сделать в нем вид показателя измерением?

(128) А в чем вопрос?

(132) Ситуации бывают всякие :)

(135) Для разных ситуаций есть БУ, вот пусть там и рисуют все что угодно.

(131) А какая разница? Что с ним, что без него? По факту ты переходишь на то же событие, только заводишь под это новый объект. Есть в этом один плюс: можно порядок в пределах одной секунды сделать. Кое-где использую и такое. Но по факту ты переходишь к моей схеме, где док, меняющий статус, не является регистратором.

+(136) Вообще у меня позиция простая: что на входе - то и на выходе.

(137) В смысле не является? Ты когда делаешь документ непроведенным, его движения убираешь? Или если в документе поменял реквизит, ты старые движения не убираешь?

(136) В БУ, что угодно? И какой закон запрещает продавать без оплаты?

Кроме того есть штатная ситуация: аномальные скидки в заявке должен завизировать начальник отдела. Он не проводит, не сохраняет документ, просто ставит галку. Тут чисто событие.

(139) Тебя там двое? Сам писал в (131) "Документ "изменение статуса"." Как он будет связан с тем документом, что его создал?

(140) Это к тому, что абсурдно грузить товар не формируя ДЗ или хотя бы расходную часть в БДР.

(136) В оперативном учете их не меньше . Ну в конкретном примере "с девочками" док все равно должен быть закрыт по оплате , из собственных средств понятно . если отгружать по нулевой цене потом концов не найти . У нас ситуация "товарный ретробонус покупателю" ситуация штатная :))

(143) Ретробонус должен быть начислен, чтоб его потом закрыть. Это разные процессы и необходимо давать реальную картину по ним.

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

(141) Еще раз повторю вопрос - ты делаешь документ непроведенным, в нем ошибка, либо его нужно исправить и провести с другими данными, как ты без регистратора уберешь его движения? Пусть это даже будет документ "изменение статуса".

(144) Процессы начисления ретробонуса , и отгрузки товара со склада и транспортировки клиенту - независимые . Складу вообще пофигу бонус это или обычная накладная , и ему пофигу оплатят ли  ее безналом или котлетой капусты

(146) в чем проблемма убрать без регистратора?

(147) независимые, о чем сказал в (132)

(148) А как ты узнаешь без регистратора какие движения сделал этот документ?

(146) Делаем новую запись со снятием флага для этого статуса? В чем проблема получить срез последних и сделать новую запись?

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

(149) Но по оперативному учету бонус так же должен быть закрыт по оплате , "погашен" иначе будет вылезать во все отчеты как неоплаченный и просроченный документ . Так что одним БУ , и "делайте там что хотите " не обойтись

(151)
В смысле?
А тем документам которым не надо снимать статус, ты нафига статус снимешь? Один и тот-же статус может проставляться неоднократно, разными документами. И при снятии документа с проведения не для всех документов нужно снимать статус.

Не для всех объектов надо снимать статус.

(150) Писать в реквизит?
Честно говоря я уже потерял нить, кто что отстаивает. Но в случае, когда изменение РС может производиться не только доком (вручеую или задачей) обычно решается через независимый РС с реквизитом.

(153) Задача БУ не показывать убытки, как, впрочем, и прибыль.

Задача УУ показать реальную картину. Если товар отгружен мы должны сформировать ДЗ и ее погасить. Погашение следует из условий договора: он может быть как бонусным, так и по 100% предоплате. Не вижу ни каких проблем в отражении этих фактов в системе. А вот простановка всяких статусов в зависимости от разных хотелок привет к неадекватным оценкам и решениям.

(156) И чем запись документа в реквизит отличается от регистратора?

(156) Независимостью регистра. И необязательностью регистратора.

+(157) Или к адекватным, но не в пользу компании.

(156) Чего тут ослеживать?
Нормальная схема - каждый документ меняет только свои статусы. Документ - регистратор. При любом изменении документа, проведении, распроведении - соответственно меняются/появляются/удаляются записи.
В итоге мы можем получить статус и на текущий момент, и на любой момент. В самой простой схеме документам не нужны никакие расчеты, тупо запись статуса. Последовательность восстанавливать не надо. Она никогда не портится.

(159) А как ты будешь изменять/удалять движения ошибочно проведенного документа?

Допустим ошибочно провели документ, который присваивает статус "находится в отделе логистики" куче первички.
Его надо удалить, но часть первички действительно в отделе логистики, и был этот статус присвоен другим документом, а часть в других местах.

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

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

(165) Получается, регистратор фиксирует момент ввода данных и оператора и нужен только для этого?

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

Мои посты (163) и (164) видны? Или форум глючит?

(168) Видны.

(169) Я тебе приведу пример - у нас 10000 первички в день, всей первичке присваиваются различные статусы (не только местонахождение) путем сканирования первички (все документы включая входящие штрихкодированы) в документ "изменение статуса", и автоматическое изменение документами которые должны менять статус по смыслу.

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

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

(170) Ты мне так и не сказал, ты какую структуру регистра держишь в уме: измерения "Документ, ВидСтатуса" или только документ?

(171) зачем в регистре документ, если есть регистратор?
Измерения объект, вид статуса
ресурс статус.

(172) Я объект и имел ввиду. Для твоей ситуации с регистратором все ок. Но он решает не задачу оптимально правильной организации процесса движения по статусам, а максимально быстрый вывод в ДС. Ради последнего приходится порой идти на огромные уступки :(

(172) Каким образом регистратор (выписка, реализация) к объекту контроля (заявка покупателя)?

(174) регистратор нужен для отмены проведения, что указано выше, а объект контроля пишется в измерение регистра (объект)

(173) в чем неоптимальность? где мы теряем в скорости?

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

(177) Получить актуальное значение регистра сведений - это и быстро, и красиво.

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

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

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

(180) Можно поподробней?
У нас есть движение.
Объект1, видстатуса1, Да

Что мы делаем при отмене проведения?

(181) А где я сказал, что будет справочник - просто будет два регистра - в одном значение, в другом - история. Справочник, конечно, от обычного регистра сведений мало чем отличается, если про GUID не вспоминать.

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

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

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

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

Просто, если статусы все пишут, а смотрит кто-то один, то их вообще для быстроты можно в ЛОГ-файл писать - явно быстрее регистра будет, а вот как они там будут читаться - это не проблемы пишущего - так что-ли ?

(185) Не совсем понял - при отмене проведения мы пишем зачем было сделано движение? Какое значение мы пишем в ресурс при отмене проведения?
(186) Показ в журнале нет проблем сделать моментальным. А сделать вместо записи 200000 движений в день - 400000 движений, при этом добавить 200000 получений актуальных значений - это конечно круто, но нужно сравнивать количество показов, и количество движений за день, чтоб решить что выгодней.

(187) Нет, не так - я сделаю честное получение атрибутов из регистра, при этом без тормозов. Оно же лежит в таблице, с индексом по объект/видстатуса, отсортированное по позиции документа.

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

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

(190) То есть записать новый статус не надо? Ты предлагаешь пойти дальше, и брать значение на момент проведения, и еще и его крутить? Есть подозрение, что замедлением на порядок тут не обойтись :)

(191) Выбрать последнее значение, причем с последним значением? :)

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

(194) Нет, при проведении мы пишем в ресурс статусы из документа. Без каких либо расчетов либо получения итогов/движений.
Но чтоб отменить проведение, если мы не отменяем движения документа - то естественно надо знать (получить) статус на момент проведения документа.
Только непонятно зачем городить огород, если проще просто убрать движение?

Чтоб вывести в журнал, нам нужно только одно обращение к базе - срезПоследних. А потом тупо разобрать ТЗ, там нечему тормозить.

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

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

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

(198) Это уже отдельная тема, документирование действий пользователей.

+ (199) У него в задании - получить все статусы.

(199) В журнале мы получаем все статусы всех объектов, которые есть в отборе журнала - там получается уже и не так просто, особенно, если отбор журнала не просто по дате.

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

(203) В крайнем случае вообще получаем только по активной строчке. Пользователь без проблем проедет по журналу.

(202) самая хрень когда отбора тупо нет

(204) Лучше сразу по всем, хотя в 1С это не так уж и просто.
Просто на экране более 20 строк, и делать сразу двадцать запросов при пролистывании страницы - как-то не айс.

(205) Ну да "сейчас мы запустим запрос и поднимем всю базу в память и посмотрим - хватит ли её нам".

:LOL:

+(206) Пользователь проедет по журналу со скоростью улитки, так как многозадачности в 1С просто нет.

Предлагаю все-таки получать только по активной строчке, и кешировать в что-нибудь индексированное.
То есть если текушая строка не равна последней,
то последняя равна текущей, и значение в соответствие.

(209) Пользователю никто не мешает так-же листать. Либо установить отбор.

(211) У меня, когда я такие поделки смотрю, есть желание выкинуть монитор в окно, так как медленность реакции на пролистывание и создаёт ощущение жутких тормозов.

(212) Не совсем понял - реакция ровно такая-же, как не было бы вообще вывода статуса.

А вот если хочешь посмотреть статус документа - встань на него. И получишь его в табличной части.

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

Сильно сомневаюсь что надо видеть журнал - то есть ОДНОВРЕМЕННО МНОГО ОБЪЕКТОВ со всеми их 10 состояниями.
Всегда бесило желание юзверей из журнала сделать отчет.
попытки юзверей иметь такой мегажурнал - свидетельстует о не до конца оформившихмя хотелках. или непонятности самого процесса обслуживания таких объектов.
.
имхо.

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

А что там в восьмерке с ПриВыводеСтроки()?
Её отменили, или она работает не только с тем что на экране?
Я уже потерялся во всех 1Совских нововведениях.

(217) Да работает она прекрасно - и при перелистывании страницы двадцать раз и отрабатывает, чтоб им пусто было.
(216) Если только они не захотели экран, где все статусы всех документов за текущий день, но и здесь можно его обновлять раз в минуту.

(218) см. (210) Кеширование спасет от тормозов.

(216) +100500

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

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

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

(196) Ты на УФ с ДС работал?

(223) Нет, но суть то от этого не меняется, хранение данных такое-же как всегда.

(222) Товар в журнале - гнать в шею таких клиентов.
P.S. во "взрослых" системах количество объектов в любой выборке обычно ограничивается (например 100), чтобы никто не выбрал всё и сразу.

(223) Когда он поработает, ему сразу 1С разонравится - несколько раз сходить на сервер при перелистывании страницы, да за такое всю 1С можно сразу в топку.

(225) Товар в справочнике, но суть от этого не меняется.

(226) Всегда любые препоны от 1С можно обойти.

Не нравятся динамические списки - ведь никто не заставляет ими пользоваться.

(224) ))))))))))))))))
Ты даде не представляешь, как динамический список обрадуется лишним десяти соединениям. А статусы нудны в дурнале польщователям, чтобы фильтровать по ним.

(230) Он просто хитрый и на сервер пойдёт, когда строка уже будет в списке и выводиться на экран, а не когда нужно что-то фильтровать.

(228) да? Заставь гребаный метод ПроверитьВывод работать корректно и я тебе коньяк поставлю. Высчитывать масштабы вручную по миллиметрам желания нет :-(

(230) Разве ТС говорил что нужно фильтровать по статусам? Тогда как говорил Torquader - писать куда-нибудь актуальный статус при проведении каждого документа влияющего на статусы. По всем объектам на статусы которых документ влияет при проведении. Либо не пользоваться фильтрами по статусам.

(229) Сейчас журнал (т.е. форма списка) это и есть динамичнский список. И больше никак. Вообще никак. Остальное - изврат, нежизнеспособно вообще.

(233) В ДМ для фильтра можно использовать все поля (видемые и нет). Поэтому вывести их - значит уже дать возмодность отбора по ним.

(235) *ДМ = ДС

(234) Ээээ... Даже ТЗ в качестве источника данных запрещено?

(234) Ну, можно вообще таблицу на форме, которая из ТЗ строится, и обновляется, когда пользователь нажмёт "обновить", тогда явно тормозов при выводе не будет, только вот назвать такое "творение" журналом как-то язык не поворачивается.

(238) Не верю что существуют языки в которых невозможно сделать динамическое обновление. Ни разу в жизни не видел.

(238) я про это и писал: "изврат, нежизнеспособно вообще."

(240) Почему?

(239) Оно есть. В Динамическом списке :-)

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

(243) Ничего не понял, говоришь загадками.

(244) В нормальном языке, если запрос ушёл на сервер, то клиент продолжает работать дальше, не ожидая прямого ответа на запрос.

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

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

(245) ну, в СКД так и сделано :-)

(245) как это поможет в листании журнала?

Отсутствие многопоточности конечно иногда добивает, привык даже на любую кнопку вешать thread.
(249) Не будет тормозов в листании на время обновления данных.

(237) тз только во временную можно. А воеменные в ДС юзать нельзя :-)

(250) и данных не будет :-) у 1с в выборку попадает 50 записей всего.

(247) Прикол. У меня в системе десятки миллионов документов, и если я выведу полный журнал - никаких тормозов не будет несмотря на обновляемые колонки.
Даже поиск по реквизиту (например по штрих-коду при сканировании) - отрабатывает моментально. В полном журнале за весь период.

Динамическое обновление данных написать - это как правило совсем немного работы.

Спать уже час как пора. Ушел.

(218) даже за один день - имеет какой-то смысл в размере если порячдка 20-30 запией. в противном случае - задача/потребность пользователя неясны ему самому.. - это сразу всплывает на больших объемах

(255) Да автор вопросов уже десятый сон досматривает, пора бы и нам туда же.

(253) я помню, как было на семерке. Объем данных не так влияет на производительность, как количество пользователей. Сколько у тебя в системе активных одновременно?

(257) До сотни примерно.

Объем данных всегда влияет на производительность, ибо пользователи должны успеть за день провести 10000 новых документов. И подправить какое-то число старых задним числом. Учитывая что никаких управляемых блокировок у меня нет, при проведении блокировки как обычно, то требования к оптимизации достаточно суровые.

(258) у нас более 200. Причем база во многих местах редкостный го*нокод. И работает приемлимо. Даже из Китая через веб-интерфейс.

(260) Но у вас данных наверно поменьше. 10000 в день - это только первичка.

(259) это скорее не объем данных, а количество транзакций и блокировок. Разные вещи же.

(261) да. У нас довольно специфическая система.

Блин, точно ушел.

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

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

(266) На порядок больше.

те около 100 тыс строк в день?

(268) Да, примерно 100000.

Может больше. Но строки же не нагружают, в 1SJOURN их нет.
А движения да, плодят.

(270) получается тч доков небольшие. строк по 10

(170) У меня в такого вопроса нет. Все статусы прекрасно работают.

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

(273) У меня другая система. По проекту выполняется множество работ. Эти работы распределяются по видам и в зависимости от вида работы определяются наборы статусов. Для ведения текущего состояния по работам и истории сделал периодический регистр сведений. Работы с прочей аналитикой (проект, организация, сценарий, подразделение) вынесены в измерения, ресурс значение состояния.

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

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

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

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

черт..

(275) Документ может быть аннулирован. Для этого было введено состояние "аннулирован", соответственно движений по базе он не делал. Отзыв не предусматривал в тот же день. Эти статусы нужны были для контроля сроков подписания документов заказчиками. Если произошла ошибка пользователя, то просто ставили нужный статус и дату и все работало нормально.

+(277) Но эта схема мне не нравилась из-за того, что заново делались все движения. По хорошему бы вынести это из документа. Может отдельным документом фиксировать изменение и корректировку статуса.

+(274) Одновременно по работам ведется куча другой информации: потребность в часах, сметная стоимость, сроки, в какой пункт договора входит выполняемая работа. Все это можно двигать, планировать, анализировать.

(274) как решаешь следующие ситуации:

1. работа сделана а статус не изменен (статус влияет на возможность начать следующий этап работ)

2. работа сделана, статус изменен, работа отменена  а статус остался

?

(275) Корректировка ошибки происходит тем же документом. Пока "сторнирование статусов" делать не хочу, смысла не вижу. Обновление статусов происходит новым документом.

(121)  >> Вобщем по моему опыту история изменения статусов без привязки к регистратору никакой полезной информации не несет, а только очень запутывает всю аналитику.  

+1

(282) +100500. Может так убедим Мистовское сообщество :)

(121) Конечно по регистрам.

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

(280)

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

По хорошему нужно еще сетевой график и вехи вести, но не хочу :)

2. Этот момент пока не проработал. В любом случае состояния по работе должны сохранятся, т.к. некоторые телодвижения велись по ней и есть какой-то статус, как и последнее состояние. Заодно нужно вести доп. статусы на работу: приостановлена и до какого срока или бессрочно, отменена. Как это будет реализовано пока не знаю. Может через галочку, может через дополнительный регистр сведений.

(285) Регулировать и регистрировать такие коллизии необходимости нет.

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

+(287) Документ проведен - данные попали в отчет.

В моем же случае расстыковки в данных "вылезут" на уровне отчетов. Ну и куча проверок перед записью.

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

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

Процесс 1, статус 1, 2, 3
Процесс 2, статус 1, 2

И Процесс 2 может перейти в состояние 2, только когда Процесс 1 в состоянии 3.

Если мы должны откатить Процесс 1 назад в состояние 2, то мы должны проверить Процесс 2.

+(290) И откатить или задать (как минимум) вопрос, что делать.

(283)  >> Может так убедим Мистовское сообщество :)

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

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

(290) Кто мешает проверить?
Вообще можно завести шаблоны, где расписать допустимые переходы и необходимые условия, и всё так-же автоматом будет проверяться.

(293) Да, именно это. Привязка движений к документу их сделавшего. С автоматическим удалением и изменением движений.

(295) Как-то абсурдно это обсуждать.

(295) Меня больше волновал вопрос стоит ли вешать статусы на документ, например акт реализации, или вести их отдельным документом.

(296) В смысле? Ведь кто-то с этим не согласен. Только по этому и обсуждается.

(298) Не интересно, кто там с чем не согласен. Есть простая логика: проведен есть движения, нет проведения - нет движения.

+(297) Например, по акту может быть несколько статусов. Разные отделы вешают разные статусы. Так вот потихоньку прихожу к мысли, что регистрировать статусы отдельным документом имеет смысл.

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

(293) Был и второй вопрос - менять все статусы объекта при изменении части статусов, и писать все статусы в один сборный ресурс, или менять документом только те статусы которые должны измениться, и хранить разные виды статусов объекта отдельно. То есть в первом случае измерение объект, и ресурс "сборный статус", во втором два измерения - объект, вид_статуса, и один ресурс статус.
Я утверждаю что второй способ единственно верный, а проблемы с журналом решаемы. И никто не запрещает дублировать куда-нибудь актуальный сводный статус при проведении .

(299) Слава богу. Теперь вроде пришли к консенсусу с регистратором :)

+(299) Другой интересный момент - это построение S-кривой по статусам работ, к статусу цепляется процент и мы высчитываем итоговый процент по проекту с учетом веса работ.

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

(300) "а проблемы с журналом решаемы." Достаточно голословно, если не знаешь текущего инструмента и технологии. Я тебе, вроде, уже описал все проблемы, которые возникают с ДС.

(299) "Есть простая логика: проведен есть движения, нет проведения - нет движения. " Я правильно понимаю, что разобраться, какой же дятел делает кривые документы постоянно нам не интересно? (Склад уже три дня в полном составе собирает заказ с ошибочным доком по оплате) Движения распроведенного дока пропали, значит, и истории не сохранится?

(304) Есть
1. Структура хранения.
2. Механизмы отображения.
Со структурой хранения всё понятно, и понятно что получение данных по одному документу практически моментально (всяко не будет превышать 1 мс даже на относительно слабом сервере)
В любом языке, в том числе и в восьмерке достаточно средств чтоб хоть свой журнал написать. На чем угодно.
Хоть в табличном документе с динамическим обновлением.

Можем забиться. Я давно не писал на восьмерке, но на спор готов написать.

(304) Кто мешает журналировать действия? У меня история изменений сохраняется для практически всех видов документов. Точнее для всех значимых. И всегда можно посмотреть кто что и зачем поменял.

(304) Есть такое понятие - человеческий фактор. Человек не бог, и не может не совершать ошибок. Если у тебя 100 документов в день, то ошибка это ЧП. Если 10000 - то ошибка это нормальная рабочая ситуация.

+ (306) Даже с привязкой документов к телефонным разговорам, если кто-то наговорил эти изменения по телефону, из документа можно их прослушать.

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

(305) И я могу написать. И что? Это так или иначе будут костыли, с которыми потом придется бороться, а реализация будет все равно не сильно лучше, чем штатный ДС.

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

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

(312) Средствами 1С? В 8.2-8.3 на управляемых формах со всем функционалом ДС? Ты искушаешь меня согласиться на твое предложение :)

(311) "писать дополнительно куда тебе нужно сводный статус" Т.е. будут два регистра - Статусы и История статусов?

(313) Средствами 1С, с необходимым пользователю функционалом, а не со всем функционалом ДС.
Можно и весь накрутить, только зачем?

Я честно говоря потерял нить. Ты что пытаешься доказать?
Например в (304)?

(314) Еще раз - основной регистр это РС с регистратором с измерениями <объект> (у ТС это документ) и вид_статуса и с ресурсом Статус.

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

(315) Сам уже запутался. Главная мысль, что удалять движения по статусам при удалении проведения документа - не хорошо.

"Средствами 1С, с необходимым пользователю функционалом, а не со всем функционалом ДС." Ок, достаточно только кнопки "Настроить список..."

РС:
Измерения:
- Заказ
- ТипСтатуса (справочник??)
- Значение статуса (СтатусыДокументов, Родитель - спр. ТипСтатуса)

Документ двигает РС только по изменённому статусу и его типу...
не? )

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

(316) Второй ты подразумеваешь периодический или нет?

(318) Да.
Только обязательно с регистратором / автоматическим удалением движений.

(320) Нет конечно. Зачем периодика на актуальное значение?

(318) "Значение статуса" в измерения. Хитро.

(322) Тогда где ты получишь информацию, что три дня по этому докумету стоял статус "Оплачено" ,а потом пропал?

Значение статуса - ресурс, блин...

У тебя же во всех отборах, в показе журнала - нужно только актуальное значение. Историю движения мы можем взять из основного РС.

Кстати, насчет истории - никто не мешает ошибки сторнировать тем-же документом "ИзменениеСтатуса", и все изменения будут задокументированы. Но ей богу это совершенно неудобно.
(323) Это скорей всего опечатка. Конечно-же ресурс.

(324)  В истории изменений конечно.

(319) Котлеты отдельно, мухи отдельно. Здесь интересна вся история объекта с ошибками, изменения, переделками, погонями, предательствами.

(328) Правильно. Котлеты (регистр по статусу) отдельно, мухи (история исправлений) отдельно.

+ (329) Ровно так-же как и по всем другим регистрам в 1С.

+ (327) У меня история по видам документов делается на точной копии этого документа в метаданных. И итоге любая отчетность по изменениям легко собирается.

(329) Нам нужна не история документа "Платежка" ,а история статуса документа "Заявка". Разные же вещи.

(331) Я уже догадался.

(332) Не получится подколоть :)
У меня документы по которым платеж делает движения собираются в табличной части платежки/строкивыписки :)  И так-же легко собирается в отчете.

(334) Т.е. регистры?

(0)пригласите специалиста
вы там всё равно сами ничего сделать не сможете
два года и опять статусы

(335) Какие регистры? История изменений строки выписки и платежки содержит табличную часть, в которой есть оплаченные документы.

Но если у тебя все изменения статусов делаются документом изменения статуса, и сохраняется история изменения документа "изменение статуса" - то тут уже совсем просто выцепляется полная история изменений статусов.

(337)продолжаю в вашем стиле мыслить:
нужно использовать бизнес-процессы

(337) "Казалось бы, зачем было убивать убийцу убийцы..." Я боюсь представить размеры твоей базы, если для тебя хранить историю истории - это нормально.

(338) Зачем?
Превратили простейшую задачу простейшего регистра в невесть что.

(339) История истории это как? У меня история истории не хранится. У меня хранится только история изменения документов. Причем нагрузку на базу это практически не дает. Да, чуть пухнет 1SJourn, но естественно исправлений документов на порядок меньше чем самих документов.

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

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

(337) Что у тебя с блокировками будет, когда 10 документов (по нескольку тысяч в день каждого) столкнуться в одной таблице документа "Изменение статуса"?

(341) Что странного в желании не городить огород из нового документа, документа, дублирующего его, для хранения изменений, регистра статусов, отчет по истории документа, чтобы вынуть фактическую историю статуса объекта, а сделать это одним регистром?

(342) Расскажи это бухгалтерии, которая например уверена что у любого первичного документа должен быть статус "принят бухгалтерией".
(343) Можно поподробней? Документ "ИзменениеСтатуса" - самый быстропроводимый в системе. Что значит столкнуться в одной таблице? Ничего что в семерке все документы сталкиваются в одной таблице?

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

(344) Опиши схему. Особенно как ты присваиваешь старый статус на позицию документа при отмене проведения.

(347)это вы должны схему описать
если вы поняли что с этого следовало начать это уже хорошо
пока вы (342) не осознали вы будете высмеивать советы
какой смысл вам подсказывать.
а поймете так и сами догадаетесь )))

(345) да, ты прав, идет тупо добавление записи. Блокировок 0. (347) Я не присваиваю старый статус, я присваиваю новый. По оплате это может быть не бинарное "Оплачено"/"Не оплачено", а "Не оплачено"/"Внесен аванс"/"Оплачено". При отмене проведения  достаточно рассчитать этот флаг (копейки по времени), и записать. И позиция документа тут при чем? У меня будет РС без регистратора.

(349)
Для примера. У нас
Док1 делает статус Объекта1 - Статус3
Док2, который идет за ним делает статус Объекта1 - Статус2.
Сначала док2 сделали непроведенным.
...
А теперь немного усложним. После этого В Док1 изменим статус Объекта1 на Статус3.
...
Что у тебя в регистре? Каким кодом ты этого добился?
Как ты узнал новый статус?

(348) Э. В пьяном виде не надо разгуливать по форумам.
Во первых ТС не я, во вторых свою схему я описал уже давно. Простая удобная и прозрачная схема.

(349) Будет? Я правильно понял? Будет? Не сделано, а будет?

То есть ты даже примерно не представляешь какие подводные камни могут возникнуть, ни разу со статусами не работал?

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

(350) перепиши без опечатки.

(304) В моем случае такая работа останется в системе, т.к. по ней шли телодвижения и были потрачены ресурсы. Но в состояние перейдет "Отменена".

(355) У тебя же пропадают движения сделанные регистратором при отмене проведения? Где фиксится это состояние?

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

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

+(358) Если процесс переходит в другое состояние, то это состояние мы фиксируем и получаем историю изменения состояния процесса.

(358) 0_о Три дня склад пашет, т.к. тетя Глаша выписку криво разнесла, и это не интересно?

(360) Нет.

(353)
Док1 делает статус Объекта1 - Статус3
Док2, который идет за ним делает статус Объекта1 - Статус2.
Сначала док2 сделали непроведенным.
После этого В Док1 изменим статус Объекта1 на Статус1

(361) А если она ошибается раз в неделю и ее стоит уже отправить на пенсию? Удивительные вы люди. Можно к вам устроиться на клиент-банке посидеть? :)

(360) У меня будет начат процесс, потом он перейдет в состояние "отменен" (прекращен и т.д.), но история старта работы процесса и переход его по состояниям будет сохранен.

+(362) Для начала что у тебя будет в регистре, а потом еще объясни какими алгоритмами ты этого добьешься.

(362) -> (354)

(363) Есть владелец процесса. Есть связи между процессами. Если из-за ошибок в процессе 1 стартует процесс 2, то зная владельца первого процесса у руководства будет вся необходимая информация для принятия управленческого решения.

Период ЗначениеСтатуса Основание Комментарий

01.01.01 Статус3 Док1 ""
02.01.01 Статус2 Док2 ""
03.01.01 Статус3 Док2 "Отмена проведения. Оператор да.ун."
04.01.01 Статус1 Док1 "Я этому да.уну больше не дам на проверку".

На третьем шаге возвращаем прошлый статус. На четвертом пишем новый.

(367) Откуда у владельца первого процесса вся информация? Он в блокнотик записывает текущие статусы?

(369) У него должна быть полная информация для выполнения своей функции.

(370) А еще не должно быть войн, все детки должны быть здоровы, а люди счастливы. Твоя система дает ему информацию. Где она?

(371) Слишком абстрактный вопрос. Ты должен определится что ты хочешь от системы и что тебе нужно для этого. Только тогда можно будет ответить на вопрос что мы можем от нее получить.

(372) Мне надо знать, какие изменения статуса были у документа и кто их сделал. Желательно еще как (либо док основание, либо комментарий из обработки).

(373) Ну так в чем проблема? Тут уже полностью этот вопрос со всех сторон обсудили.

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

(375) И что?

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

(376) И где я получу информацию, что этот статус был установлен этим документом?

(368) А теперь набросай алгоритм которым ты этого сможешь добиться.
И на всякий случай третьего числа добавим последним документом Док3, который объекту1 ставит статус4, и был проведен этот документ третьего числа.

На самом деле я уже отлично вижу что рабочей схемы у тебя просто нет.

(379) У тебя нет задания ,а ты хочешь решение. Кто, когда, в какие статусы, при каких условиях может проводить? Аналогично можно и тебе дать порешать такие задачи. Особенно весело будет, когда у непроведенного документа тоже будут статусы :)

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

(380) Задание явно есть. Есть документы которые меняют конкретные статусы конкретных объектов. Реализовать получение актуального статуса. Естественно документы могут изменяться и делаться непроведенными.

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

Это в твоем решении не проведенный документ делает движения по статусам, а в нормальном учете не проведенный документ не должен делать движений.

+(381) не вижу потребности.

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

(383) ИМХО, до первого требования такую информацию предоставить.

не нужно пугаться левого соединения по индексу. Эта операция совсем не сложная.

(384) При чем тут это?
Я говорю что документ изменяющий статус, не должен формировать движения если он не проведен. А не про проведенность "объекта" Статус которого мы отслеживаем.

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

(0) Имха продолжить путь по пути запроса . Его надо упростить  скорее и оптимизировать.

+(388) По сути регистр уже  есть - набор таблиц документов (статусов) где хотя бы одно поле - ссылка на  уитываемый документ.

Городить нормализацию  всегда можно успеть.

(387) Не надо всех под одну гребенку. Это у тебя статус документа движение, а у меня это состояние документа. Проведенного, непроведенного, помеченного на удаление. Бизнесу важна история этого документа. Важны моменты и периоды переходов.

(389) у него нет регистра.

(391) Ты чего-то недопонимаешь. У всех статус - это состояние. И естественно у меня в том числе статус это состояние документа. Проведенного, не проведенного, помеченного.
О чем я уже писал в этой ветке. В последний раз не далее как в том посте на который ты отвечаешь. (387)

(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) Собственно это интересно.
Если нужно отслеживать этапы прохождения некого набора событий насколько удобно использовать бизнес-процесс