Добрый день.

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

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

Встречал, например, такую реализацию: статусы для заказов рассчитываются в форме списка документов "Заказ покупателя" при получении данных и тут же пишутся в регистр сведений/реквизит документа. В итоге все ужасно тормозит. Считаю данную реализацию неоптимальной.

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

(0) ут11 в руки.
форма списка документов Заказ клиента.
но там уф+динамический список и "раскраска" генерится в запросе списка.

в регламенте считать кажудю минуту и писать в реквизит.

(2)это было моей идеей №3, но здесь смущает следующее:
- считать только невыполненные заказы покупателей?
- например пользователь распровел то же поступление товаров, а статус поменяется только через, например, полминуты. А ему нужно, чтобы цвет изменился тут же.

(3) За распроведение поступления товаров отрывать руки.

(4)ну кто не ошибается...исправили, потом снова провели, все это одним днем.
Без отмены проведения поступления все понятно, т.к. в остальных документах цепочки заказ покупателя является либо реквизитом шапки, либо реквизитом ТЧ.
Хотелось бы предусмотреть все.

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

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

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

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

(9) Кто мешает анализировать ПередЗаписью()?

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

(11) Сделай подписку перед записью. Тебе нужно отследить те заказы которые уже были затронуты ДО изменения документа, а по результатам проведения проанализировать что было затронуто ПОСЛЕ изменения. Соответственно объединение множеств этих заказов и запихать в регистр, поскольку они все подлежат анализу.