gifts2017

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

Опубликовал Александр Венгер (venger) в раздел Обработки - Обработка документов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наименование Файл Версия Размер Кол. Скачив.
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) 20.04.11 11:35
Поделись опытом - почему не на справочниках?
Ведь при использовании подчиненных документов мы попадаем в самое узкое горлышко 7.7 - табличку жорнал?
2. Александр Венгер (venger) 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) 29.05.12 14:56
(1) Noy,
У 1с 7.7 много узких горлышек.
Документы узки по-своему, Справочники по-своему.
Скорость записи документов упирается в доступность журнала документов, зато вылетов нет.
У справочников другое "узкое место" - блокировки таблицы справочника некорректно обрабатываются. Если в справочник выполняется много записей от разных пользователей получается много вылетов 1с.
Есть решение этой проблеммы:
http://infostart.ru/public/137108/
, но решаема она толко только для SQL баз (Хотя на dbf эта проблемма вроде не такая острая).
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа