Document Types

The project implementation team will need to create a number of "Document Type" definitions based on documents available across all organizations, as well as organization-specific documents. Examples might be:

• Bill of Lading, a PDF generated automatically by the application at time of Shipment Confirmation.

• Package ID label, a Zebra-printed sticker label generated on-demand by the application.

• Insurance Information, a document to be uploaded and attached to an Order at any time.

The end-user will experience this as a "Documents" tab attached to the transaction. This allows them to download documents that were already generated, and upload new and revised documents.

For example the user might upload an Insurance Information word document, along with Insurance Company Name as a proper text field. (The set of fields available varies by Document Type.)

You can add new document types either through CSV file (using the PLT.DocumentType_IB inbound interface), or by using an Admin UI accessible via the following WebActionRef (designed for a Value Chain Admin or Enterprise Admin).

Document Type Permissions

The project implementation team will also need to identify who can download/upload these documents by matching the user's organization with one or more organizations on the owning transaction.

The model called DocTypePerm is used to govern permissions like upload/download on document types. It involves specifying permission (can download and/or upload), and then granting that permission-based on one or more organizations on the transaction. It tries to match the transaction's orgs against the user's organization (further qualified by the user's role type). Permissions are granted as a union of CanDownload/CanUpload across all matching organizations.

For example, let's say we specify that on an order, the OwningOrg has download permission and the BuyingOrg has download and upload permissions. If my user's organization matches both the Owning and Buying organizations (i.e. they are the same), the user will get the most liberal permissions possible: download+upload.

Users must match any organization AND any RoleType. If the organization not specified, they must just match any RoleType. If RoleType is not specified, they must just match any organization. If neither specified, this is the "default". Rules with organizations and role types will be evaluated first, then rules with organizations only, then rules with role types only, finally rules with no organizations or role types. Any user not matching any DocTypePerm will not be able to access the document type for that parent transaction.

There is a reserved value for the role type column called "DEFAULT". When provided, this row will be used for any role type which doesn't match other rows. If there is no DEFAULT record for that doctype perm, that means the default permissions for all roles = no permissions, i.e. no download or upload. DEFAULT is always LAST in precedence. So if we find ANY other role types, we combine and use those first. Only if no actual matches are found do we fall back on DEFAULT.

You can add a new document type permission either through CSV file (using the PLT.DocTypePerm_IB inbound interface) or by or by using an Admin UI accessible via the following WebActionRef (designed for a Value Chain Admin or Enterprise Admin).

Approve and Reject Documents

The Document Framework also supports the notion of Approving and Rejecting a Document. These are enabled/disabled with similar rules as upload/download, i.e. the organization referenced by the document type may need to match the user's organization in order for them to approve and/or reject.

The Approve and Reject options are available in the "Actions" column of the document panel grid, but only if the user has Approve or Reject permissions. While rejecting, a rejection code is mandatory. Optionally, a rejection comment can also be added.

When approving a document, it will automatically be marked "Final" on the server. When Rejecting a document, it will automatically be marked not "Final" in the server.