When adding or updating a document, certain fields have a limit as to how long they can be. When incoming data has exceeded their limit, an error is thrown, and the data is truncated. Now that we accept documents from external sources, it is not possible to “return an error” so we now just truncate the data and there is no error message.
This change affects these fields:
File Name of the document (excluding any path information) (128 character limit)
Document description (64 characters).
Document notes (256 characters).
Document Message format: This is the JSON format vendor connect vendors need to send to us (all fields are of type string and optional fields can just be omitted when they are not needed.):
{
"DocumentName":"Name of document with file extension (128 char max, required). Must be unique at the order number level and must include the file extension)",
"Description":"description of a document (64 char max, required)",
"Notes":"Notes about the document(256 char max, optional",
"OrderNumber":"Order number (23 char max, required)",
"DocumentType":"Document Type code (32 char max, optional)",
"DocumentID":"A unique identifier for the document on an order level. (nvarchar 64 max, optional)",
"DocumentSize":"Size (in bytes) of the content of the document (10 digits max (integer), optional Note that documents are limited to ~50 MB in size)",
"ConnectorIdentifier":"The vendor connect identifier that identifies the MoversSuite system to receive the notification (64 char max, required)",
"DocumentContentUrl":"https://… The complete url needed to download the content of the document (1000 nvarchar max, required)",
"DocumentContentHttpMethod":"GET The HTTP method needed for the DocumentContentUrl to retrieve the document content (7 char max, optional (GET is assumed when not specified))"
}
We optionally support Bearer token authentication that never expires. An OAUTH token that expires and needs to be renewed periodically would involve EWS custom development to support.
Using a POST method would involve EWS custom development if a POST payload object is needed. GET method is preferred.
Created by/Modified by Personnel. As with all document providers, it is possible to create a specifically named user in Personnel and have that user be placed on any documents that comes from a particular document source (such as TransDocs, PSI-Gen, Atlas, Arrivy, or other vendor connect partner). That way, when you look at the properties of the document, the modified by user can indicate where the document came from. This can be useful if there is more than one document provider.
If this is not implemented for a specific document source, then documents from that source will say they came form the “External Application” user, which is not very specific at all.
To setup such a Personnel User to match a document source:
Make sure the name of the Xml System Data Type Map name user for a source has not more than 26 characters in that name. To be clear, this would be the Xml System Data Type Map name linked to the Arrivy, TransDocs, PSI-Gen, Atlas or other document source.
Copy that Xml System Data Type Map name value to your clipboard.
Create an employee in Personnel using the Admin tool and use the Xml System Data Type Map name as the Last Name for that employee. (Technically, we search for an employee whose first or last name matches the Xml System Data Type Map name but the last name field is longer (26) than the first name (16)).
If a Vendor Connect vendor sends a document notification that has a document name that matches an existing document on that order, this is what now happens (previously, this would have resulted in an error within the Third Party error log):
If a user manually adds a new document and that document name is already on file, the user is presented with a dialog and he/she can overwrite it, change the name of the new document or cancel the operation. (This is not a change.)
If the document came from a non-vendor connect source, meaning a TransDocs or PSI-Gen document), it would just update the existing document.
If the document came from a vendor connect source (Atlas, Arrivy or other vendor connect vendor). then:
If the original document came from the very same vendor connect vendor, then the document will be updated (meta data and content, even if the content was previously downloaded).
If the original document came from a different vendor connect vendor or another source, then this new item will be treated as a new document and the name will be altered by injecting (2) or (3) into the document name, altering it as necessary to get a unique name, such as “BillOfLading(2).pdf” or “BillOfLading(3).pdf”, etc.
Known Facts:
TransDocs, PSI-Gen and Atlas do not send their documents down more than once. Atlas treats a new version of an existing document as a new and separate document.
Any Atlas documents added before this change is installed are not identified as being from “Atlas” and will be treated as if they came from TransDocs or PSI-Gen. And documents added once this change is installed will be marked as being from Atlas and would follow the rules for vendor connect vendors. Since Atlas never sends a duplicated document name, this should not present any changes to how we handle their documents.
Arrivy says it prefers to keep just the last version of a document so when a document changes (signatures added, items on the document are changed, etc.), that document name is sent again and the document content will be updated. Any attempts to view the document after that happens will result in always viewing the latest version of the document.
If a user deletes a document (via the Document Viewer), and then that very document name comes down again, then TransDocs, PSI-Gen will update the document while vendor connect documents will store a new document.