Despite the seemingly obvious assertion “the main component of an application based on EDMS is a document, and what it automates is its“ turn ”, in practice it turns out that a variety of entities may be meant as documents in applications. It depends on the type of the document and the nature of its “turnover”, i.e. life cycle processing. Docsvision provides mechanisms for implementing such objects. This is due to the fact that even for the most typical applications of the EDS (for example, to automate the tasks of classical office work) we needed to simulate a document in the system that is described by a very complex data structure and a complex life cycle. The ability to model such complex entities as a document in paperwork and allowed us to gain sufficient versatility in the implementation of applications for processing documents of various nature. Bearing in mind the considerations expressed in the previous article , we will try to describe the model of the entity, which we call the word “document”.

Information in the document

The document is primarily a carrier of information. What information can be contained in the EDS document?

Unstructured information

- all sorts of files. In this case, the real document in the application of the ERMS may contain:

• one file
• set of versions of a file (keeping its history of changes)
• several files of the same or different formats (for example, contract and applications), each of which may contain version history
• more complex file structures, including hierarchical data ordering, for example, in the tasks of technical document management (description of the product structure)

There are various rights to work with document files (depending on the stage of its life cycle and the role of the user) - the ability to edit, create versions, or other documents in the structure.
')

Structured Information

- a set of attributes of the document. In ECM systems, this data is usually called metadata (data accompanying the document file), which is not entirely correct, since In the EDS application, a document can be processed that does not contain files, but includes only structured information. In the SED annex, it would be more correct to call the metadata information about the structure of the document - the composition of the attributes that make up the structured part of the document, but it is too late to change the terminology.

So, what the structured part of the document consists of.

• set of attributes of standard types (string, number, date, time)
• enumeration attributes (simple reference books) - for different types of documents, attributes can be filled with predefined values ​​of different types (contract type, access level, etc.).
• Attributes filled out from reference books, as opposed to transfers, can be complexly organized reference books (for example, employees, counterparties, nomenclature of cases or headings, etc.). Several document attributes may be associated with one directory entry. For example, for a specific counterparty, such attributes as full name, legal entity may be saved in the document. address, telephone, etc. Depending on the way the document is processed, the reference field can save the static value of the selected item — a reference book or a link that will restore the value each time the document is opened, or perhaps both.
• attributes specific to a particular document handling system. For example, for Docsvision, these are attributes such as a link to a linked document, a document category, a link to the folder in which documents are stored, a document number, a link to a task that was created by the document, etc. To fill in these fields requires a certain processing logic in depending on the type of attribute.

The listed attributes can be organized into tables. For example, if a document contains a list of nomenclature positions or a list of employees participating in the coordination of documents or a list of references to other documents forming a package of documents. Each row of the table can be quite complex in structure and contain all the attribute sets listed above.

Sometimes tables can organize hierarchies of records. Each row in the attribute table may contain not only a flat set of attributes, but, in turn, contain an attribute table. The most typical case is a list of tasks related to this document. In EDMS applications, it is often necessary to decompose tasks, so each row of a table containing references to the back of a document may contain a subordinate table containing child tasks generated from it.

Service information - contains data that is accumulated during the processing of documents and which are needed not for implementing the application logic, but for other tasks, such as auditing, security and performance analysis, etc. These may be logs of fixing facts of access to the document, history of changes, made in the document, etc. This is usually tabular data.

Reliability information is a special type of proprietary information that confirms the authenticity of authorship and the immutability of the document. For this purpose, as a rule, electronic signature mechanisms are used using certificates. Sometimes less costly mechanisms can be used, for example, in Docsvision, a simple signature mechanism is implemented that does not require a PKI infrastructure. Document files and individual attributes of structured data can be subscribed, information on transactions with signed data can also be included in the signature.

System Information - used by the application to perform various service functions and to implement the functions of applications hidden from the user's eyes. Such information in the Docsvision system includes:

• Time of the last change
• Information about access rights to the document
• Presence of blocking of the document or separate files (Check-in / check-out control)
• Stage of the document processing life cycle (document status)

As you can see, the document in the workflow system is a complex information object.

In Docsvision there are several possibilities for constructing the information structure and visual interface of the form of documents. The low-level visual tool Card Manager (CardEditor) allows you to create new document types, describe their information structure and define a constraint on field values. When using this tool, the software component that implements the document interface is developed in any programming language using the API of the Docsvision platform.

Figure 1. Low-level tool CardEditor allows you to describe the information structure of documents.

A higher-level document - a card designer - allows you to create both an information structure and the external interface of a certain type of document * . Contains a set of controls, both general purpose and specialized. Card Designer also allows you to connect various software handlers (scripts) to various operations that the user performs, and events.
*
A type is a low-level object that contains a description of the data structure (schema)
For example, in Docsvision, the document and task types of cards are initially supplied.
A view is a type of card of a certain type. Customized with reference books and constructors.


Figure 2. The high-level tool “Card Designer” allows you to describe the information structure of documents and its interface.

For example, in Docsvision, for the Document type, the types Incoming, Outgoing, etc. are supplied.
For a single document, several interfaces can be designed for processing it by different users at different stages of its life cycle.

Document life cycle

During its life cycle, a document can go through different stages of processing (development, approval, approval, current, archival). At each stage of the document's life cycle, the application must grant different users different rights to process and modify it. For example, at various stages of document processing:

• changes can be made in the main text of the document file, only in the protocol of disagreements or cannot be made,
• certain fields (metadata) of the document may be available for reading and editing;
• available to perform certain operations.

Accordingly, at different stages of the life cycle, a different interface is needed to access the above actions. As a rule, the life cycle of a document is not limited to a simple linear sequence of processing steps. The scheme describing the stages of the life cycle of a document in real life can be complicated, including returns, processing cycles, and even conditional branches (if the processing of a document is developed according to different scenarios).

The Docsvision system has a separate constructor that allows you to describe the life cycle of the document and the operations that are available at each stage of the life cycle.

Figure 3. The State Constructor tool allows you to describe the document life cycle.

Comment! The document life cycle does not describe the process of its processing, but the change of the document during its processing. Typically, ECM / BPM systems implement two subsystems - document lifecycle management (Life Cycle) and business processes for their processing (Workflow).

Document processing business logic, document processing operations

In applications with a document, certain actions may be performed, and their execution may contain various processing logic. The simplest processing logic is associated with the rules for filling in document fields. For example, a field may be mandatory or contain some restrictions (the planned date cannot be earlier than the current date). Rules of this kind are configured in the visual field fill rule designer.
Sometimes it may be necessary to use a specific and more complex logic for processing rules for filling in fields that are specific to applications of the ERMS. For example, the formation of the document number in the paperwork or a unique barcode identifier may be based on complex rules. Another example of complex rules for filling in document fields could be the appointment of the person who performs the document in accordance with the company's organizational structure and temporary substitution structure. To implement such scenarios, special controls are implemented in the Docsvision system, which can also be customized.

However, a large number of scenarios for processing the business logic of a document cannot be foreseen in advance. For their implementation, the Docsvision document supports the possibility of software extensions. To do this, you can use the #C language and a specialized API to access and manage document data. A processing program can be associated with any event occurring with a document — its opening, modification of a field or file.

Figure 4. Card Designer allows you to create various software scenarios for the implementation of advanced document processing logic.

A special group of information processing logic in a document is associated with the synchronization of data from the file's content fields (for example, Excel cells or Word fields) of a document and its attributes. To do this, Docsvision implemented a special tool for marking office documents.

In the next section, we will talk about tools for optimizing the document interface for a specific usage scenario and the Docsvision role model.