Archive Structure and Document Identification
The table below shows the T H R E E main archival storage units found in the UnForm archival system.
|
Library
|
A folder/directory path to the location where archived documents are stored.
There can be one or many libraries to store documents. Access and security is controlled by library, so the process of designing a single or multiple library structure, and determining which documents will be stored in which library, needs to take into account the access rights of groups and users. Beneath a library path UnForm uses a file storage algorithm with a theoretical capacity for over 4 billion distinct documents.
|
|
Document
|
One or more related files which share a unique document Type and Document ID combination, different from any other document in the archive. Because the document's "source" data itself is stored in what UnForm recognizes as an "image" file, the document unit in UnForm can be seen as an "envelope" or "wrapper" which surrounds one or more associated files.
|
| |
Image
|
A single document file with a distinct format or type which distinguishes it from other files associated with the same document which are of a different format or type.
Think of a "text image" of an invoice, versus a "PDF image" of the same invoice, versus a signed delivery slip "image file" pertaining to the invoice, versus a Word document "image" of the order quotation preceding the invoice, all associated with the same document ID.
|
Document-level Identification
The table below briefly describes the EIGHT main data elements which UnForm uses to identify documents at the document level. With the exception of the date/time stamp, and some character-separator rules enforced by UnForm on some of the fields, the data format for each of these text elements is user-configurable. A significant part of the administrator's implementation process is to design a document identification structure for the archive which will meet the enterprise's needs over a meaningful period of time.
|
Document Type
|
- First segment of the primary document identifier-key.
- Maximum 20 characters
- Null value allowed
Example document types from our sample libraries:
|
/ demo_sales
|
/ demo_accounting
|
/ demo_purchasing
|
"ArStatement" "OpInvoice" "OrderPickQuote" |
"ApAging" "ApCheck" "ArAging" "GLDailyDetail" "OpSalesRegister"
|
"PurchaseOrder"
|
|
|
Document ID
|
- Second segment of the primary document identifier-key.
- Maximum 20 characters
- Null value NOT allowed. However, the null is trapped by UnForm and replaced with a 10-digit unique serial sequence number. Note that the number sequence is global within a library, but not within a document type.
The combination of Document Type and Document ID form a unique identifier-key to a document within a library.
Note that libraries are distinct units to each other so document identifier-keys are only unique to a library, in other words, identical document identifier-keys can exist in two distinct libraries without over-writing.
|
|
Categories
|
Secondary sorting values known in some software applications as sort-keys.
Example Categories from our /demo_sales library include:
OpInvoice and OrderPickQuote Doc Types
|
ArStatement Doc Type
|
"Customer" | {CustName}
"Salesperson" | {SlspName}
"CustPO" | {CustName} | {POnumber}
"OrderId" | {CustName} | {OrderId}
|
"Customer" | {CustName}
|
In the above samples, the text between quotes is literal, and the text between curly braces { } indicates a variable data field where the values for the document being archived are supplied by the application. The pipe symbol  |  is used to delineate segments in a category, which allows UnForm to structure a drill-down presentation when browsing for documents. A category can contain up to three pipe-delimited segments. The first segment should normally be a literal text category name, as shown in the example, to facilitate the category-type browse method when looking up documents.
Note from the first column header above that the "OpInvoice" and "OrderPickQuote" document types are configured with the same list of categories. This is because in our sample database they are related documents in a relationship where an "invoice" is always preceded by an "order". As an example from our samples of some of the considerations in choosing document identification strategies, by structuring a category on the invoice to reference the source order ID number, the following sample document browse list was enabled where an invoice and its related order document appear together in a list.
The next example shows a browse list which has been started using a category browse method and drilling down from customer to customer name "Taylor". Notice the three different types of documents which were located for Taylor, because the different document types were configured with at least one identical category.
|
|
Document Title
|
A broad general description of the document, sometimes composed of several major data values that help distinguish the document from other similar documents.
|
|
Keywords
|
Additional document identifiers that can help narrow and limit searches to locate documents and groups of documents, improving search efficiency.
|
|
Entity ID
|
A security data element which can be included with a document and/or user account to filter access to specific documents or groups of documents to login user accounts which carry access authorization referencing the same entity ID.
The concept of the Entity ID is one of ownership, designed for situations where external web access to documents in a shared library needs to be restricted to the entity specified. For example, where customer XYZ can login and browse, list and view invoices for customer XYZ without ever seeing documents for other entities listed.
If documents are written to the archive with an empty entity ID field, then any user account with an empty entity ID will pass the entity test for access to a record. In an environment with empty entity ID field on documents in the archive, simply assigning a user any non-blank entity ID value can be used to restrict access to all documents in the archive.
At the current release level the entity ID field is treated, both for document properties and user properties, as a simple string of text. There are NOT provisions in the software for assigning multiple entity ID's to either a user or a document, nor any provision for entity ID sub-string referencing.
|
|
Date / Time
|
The date/time stamp of a document is used as a secondary sort-key in the library to allow a by-date browse-method drill-down to locate documents. The document date and time can be modified in the document properties box of a located document.
|
|
Notes
|
Free-form text notes can be stored with a document and can be edited in the document properties box of a located document.
|
Image-level Identification
The elements discussed above apply to a document at a document "envelope" level, and serve to identify, group, and sort documents, and store additional useful information about a document, including free-form notes.
Because there can be multiple "images" associated with a document, each separate image file is assigned a unique identifier-key known as a Sub-ID. When text-based documents are stored in the archive by an UnForm ruleset command, UnForm will default the Sub-ID value to @text for the text version of a document, and @unform for the pdf version of a document. Documents stored in the archive via UnForm's command-line syntax will NOT have a default sub-ID assigned, so the user or the application must create a Sub-Id.
|