Универсальная подсистема «Статусы документов»

Обработки - Обработка документов

8
Подсистема позволяет включать для разных видов документов возможность установки, снятия и фильтрации документов по произвольным статусам, не меняя, перезаписывая и не перепроводя сам документ, которому мы меняем статус. Что исключает необходимость перепроводки и изменения документов задним числом из-за изменения их статусов. С возможностью просмотра и хранения истории статусов документа.
Например, когда нужно отслеживать прохождение каких-либо «состояний» документа в бизнес-процессе.
Или, как один из вариантов, когда нужно отслеживать, какие документы уже разослали их распечатанные бумажные копии на подпись и простановку мокрой печати второй стороне, какие из них уже вернули подписанными и с печатью, а какие еще нет и т.п.
Подсистема рассчитана на установку и работу в любой конфигурации, с минимальными изменениями самой конфигурации. Используются внешние компоненты: 1С++, FormEx.
Подробное описание настройки, использования и установки читайте в pdf-файле в архиве с демо-конфигурацией.

Установка и использование подсистемы подробно описаны в pdf-файле в архиве с демо конфигурацией и могут быть сделаны и "продвинутым" пользователем слегка знакомым с конфигуратором, но для разработчиков и программистов, как всегда возможностей больше;-)

Поэтому пусть Вас не пугают эти примечания, можете не обращать на них внимания, установить и использовать подсистему практически также легко, как установить модуль или шаблон в CMS Joomla, например;-)

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

Примечания для разработчиков и программистов:

Вкладка "Статусы" документа для вида которого включены статусы генерируется программно, см. скриншоты.

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

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

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

В подсистеме в классе 1С++ «статусов документов» реализовано в качестве внешнего интерфейса различные функции программной установки статуса документа, снятия, просмотра и печати истории, определения текущего статуса и т.п. Что позволяет тем, кто устанавливает подсистему в конфигурацию и знаком с программированием внедрить прямо на формы журналов документов возможность просмотра статуса текущего документа, установку или снятие статуса, без открытия формы самого документа, печати его истории статусов и т.п. прямо из формы журнала. Примеры есть в демо-конфигурации, в общем журнале документов. Точно также, с помощью этого интерфейса можно организовать добавления действий установки/снятия статуса в групповые обработки документов и т.п.

Подсистему «Статусы документов» можно установить и использовать в одной конфигурации совместно с другими моими подсистемами, например, с этими:

Универсальная подсистема «Дополнительные права документов» + «Сканы документов»
//infostart.ru/public/71084/

Универсальная подсистема «Подписи/согласования документов»
//infostart.ru/public/73774/

Как их установить совместно также описано в pdf-файле к этой подсистеме в разделе "Примечание к установке".

8

Скачать файлы

Наименование Файл Версия Размер
DocsStatusesDB.zip
.zip 776,38Kb
18.04.11
89
.zip 776,38Kb 89 Скачать
ManualDocsStatuses.pdf
.pdf 630,04Kb
18.04.11
17
.pdf 630,04Kb 17 Скачать

См. также

Комментарии
Сортировка: Древо
1. Noy 1059 20.04.11 11:35 Сейчас в теме
Поделись опытом - почему не на справочниках?
Ведь при использовании подчиненных документов мы попадаем в самое узкое горлышко 7.7 - табличку жорнал?
2. venger 2067 20.04.11 12:50 Сейчас в теме
(1) Есть подозрения, но не проверял, что выбрать по реквизиту элементы справочника будет медленнее, чем выбрать подчиненные доки. Да и проще было делать в документе, табличная часть (не надо подчиненный справочник лепить), дата/время уже есть и т.п. Еще сыграло роль то, что (это давно было, но тем не менее) известная статья о способе организации нескольких табличных частях у дока:

http://www.mista.ru/articles1c/hare/article.74.html

Комменты (5-7)
http://forum.infostart.ru/forum24/topic21485/

Вот так и "отложилось" в служебных доках делать;-)
3. an_2 18 29.05.12 14:56 Сейчас в теме
(1) Noy,
У 1с 7.7 много узких горлышек.
Документы узки по-своему, Справочники по-своему.
Скорость записи документов упирается в доступность журнала документов, зато вылетов нет.
У справочников другое "узкое место" - блокировки таблицы справочника некорректно обрабатываются. Если в справочник выполняется много записей от разных пользователей получается много вылетов 1с.
Есть решение этой проблеммы:
http://infostart.ru/public/137108/
, но решаема она толко только для SQL баз (Хотя на dbf эта проблемма вроде не такая острая).
Оставьте свое сообщение