Transflo Synergize Bulk Print
The Synergize Bulk Print process integrates external billing systems with Synergize. Processes deployed on the process server do similar things, and as a group, provide functions called print renditioning or rendition billing.
The main purpose of Synergize Bulk Print is to get invoicing documents called source documents from the external system into a Synergize repository and to distribute supporting source documents from Synergize to the customers to be billed.
The external billing systems that Synergize Bulk Print integrates with are called Synergize Bulk Print providers. In the individual external billing systems, access to the Bulk Print functions is called various things, including Print Rendition.
As of version 2.2.9, the following providers are supported:
-
TruckMate
-
MercuryGate
-
NetSuite
-
Innovative
-
Accellos (SJS)
-
TransPlus (SJS)
-
TMW Suite (added in version 2.2.15)
Synergize Bulk Print supports different ways to pick up batches of source documents for processing. The batches could be files in a directory on the file system, files in an FTP folder, or even Synergize documents in a Synergize repository queue. A Synergize Bulk Print listener is the entity responsible for picking up the batches to be processed by Synergize Bulk Print. Every listener can be scheduled to start and stop processing at specified times. As of version 2.2.9, the following listener types are supported.
An FTP Listener constantly watches a directory on an FTP location and picks up any files that arrive there.
A Directory Listener constantly watches a directory and picks up any files that arrive in that directory.
These files are processed by Synergize Bulk Print, according to the Provider logic.
-
A Directory Listener can be configured to pick only one file at a time or a whole set of files at a time.
-
A Directory Listener provides the option to ensure older files are processed before more recent files.
This option may come with a performance penalty.
If the sequence of files is not relevant to your processing, we recommend keeping this option off.
-
A Directory Listener only returns files that are at least 500 seconds old.
A Queue Listener constantly runs Synergize searches for documents in a predefined queue.
Note for repositories with parallel workflow enabled: as of 2.2.9, this listener does not support a search queue that is inside of a split box.
A Bulk Print scenario is a collection of settings that defines how a particular batch of documents is processed.
-
A scenario can change default behavior, like saving the source document into the Synergize repository or distributing the supporting documents.
-
A series of scenarios can be chained together, by having one scenario save to a directory that a different listener is monitoring. That listener can be associated with the next scenario in the chain.
Synergize Bulk Print Service
Synergize Bulk Print takes its preferences from a Registered Application with the name Synergize Bulk Print Service. Synergize Bulk Print supports the creation of multiple Registered Application names, with different group names. The installation prompts for a group name.
When using a group name, a file is created in the same directory as Synergize Bulk Print Service.exe called Synergize Bulk Print Service.ini which contains the name of the group for the instance of the Synergize Bulk Print Service.
When using a group name, the registered application name is:
Synergize Bulk Print Service - <group name>
If there is a problem querying the registered application, make sure there is no carriage return or line feed in the Synergize Bulk Print Service.ini file. It should have exactly the group name, with no extra characters.
(Optional) Use Local Preferences
Synergize Bulk Print provides the option to use local preferences, instead of the Synergize Bulk Print Service Registered Application preferences. This can be useful in environments where different instances of Synergize Bulk Print need to run with different settings for the same Synergize Deployment.
To enable this feature, you need to copy the BulkPrint_UseLocal.txt file to the Synergize Bulk Print installation folder.
Please ensure this is not a zero-length file.
When using local preferences, on a Windows 7 machine for example, the settings file is by default located in C:\ProgramData\Microdea\Synergize Bulk Print\SynergizeBulkPrintService.settings
Create and Configure Scenarios
When creating a scenario, you are first prompted to select the provider that the scenario will run under. The list of available providers is calculated by Synergize Bulk Print based on the existence of the provider DLL files. Synergize Bulk Print can run multiple scenarios with the same or with different providers at the same time.
Export and Import Scenarios
Feature First Available:
Bulk Print 2.3.2
October 2017
Prerequisites:
Synergize Server
Transflo Velocity+ Command Center, Transflo One Portal Loads, or a Third-Party TMS
Each exported scenario is saved as an XML file. You might export an existing scenario for the following reasons:
-
You can create several similar scenarios quickly, by exporting multiple variations on the basic scenario.
-
You can export a partially created scenario. Normally you cannot save your preferences for Bulk Print, if a scenario is incomplete. Exporting a partial scenario allows you to delete it before saving your preferences, then later import it to continue working on it.
-
If you need a default scenario, you can set it up and then export it. Each time you import, you can use the default scenario as a starting point.
To export a scenario, right-click on the scenario name and select Export Scenario.
Specify the name and location for the exported scenario XML file.
Synergize Bulk Print starts all of its listeners, and they each are constantly checking for input. When files or groups of files are picked up by the listener, they are treated as a package which goes through the following steps:
-
If more than one scenario is configured for the listener, Bulk Print determines the applicable scenario for the package. This also determines the Provider, because the scenario can only belong to one Provider.
-
Parse the batch, according to the Provider Logic, split it into source documents, and save them to the Synergize repository.
-
Determine which document types are used in the search for supporting documents in Synergize repository, to be used for distribution.
-
Perform a look-up into the Provider's look-up database or Web Service, to return the list of bills for each source document.
-
For each source document, run a Synergize search for documents matching the list of bills and the documents types.
-
For each source document, figure out the type of distribution and the value for it.
For example, if the distribution type is Email, we need to get the email address the supporting documents need to be sent to.
-
Optionally, group the supporting documents so that billed customers receive one email for all their source documents instead of one per source document.
Distribution can also be grouped by another field that is assigned to the source document. All source documents sharing the same value for this field get sent in the same email, along with their supporting documents. Some providers may allow the grouping field to be the result of a look-up so it can be different for different customers. Please look at your specific provider documentation to check whether this feature is allowed.
The task code string tells Bulk Print how to distribute the various documents associated with a particular processing run.
Examples:
-
SYNF17F11F12E17E11E12
-
SYNE13E1516
-
SYNEDI
The task code provides the following data for Bulk Print:
-
Contains the list of Synergize Document Type IDs to be used in the search for supporting documents in the Synergize repository.
Example:SYNF17F11F12E17E11E12
Only documents of type 11, 12, and 17 are used for the search.
-
Indicates the distribution type for each document type.
Example: SYNE13E1516
Email supporting documents of types 13 and 15 and print supporting documents with document type 16.
-
Indicates that a document was never generated because all transactions were done using Electronic Data Interchange (EDI).
Example: SYNEDI
The three-letter EDI code indicates that no further distribution needs to be done.
The task code string is usually in a bar code on the source document. If there is no SYN bar code, this string must be retrieved from the customer table, where individual customer distribution preferences are stored.
Two key things to note:
-
For all scenarios, if there is no distribution specified and no EDI flag, then an exception is thrown.
-
Innovative scenarios can return isEDI as a flag from a lookup on a bill.
Bulk Print providers return a letter to indicate the distribution type, for each source document. Not all distribution types are available, for all providers. Although not every provider supports every distribution type, the following table shows the full list:
Distribution Letter |
Distribution Type |
Supported Extensions |
---|---|---|
E |
|
Any |
F |
Fax |
tif and pdf |
X |
Ftp |
Any |
D |
Directory |
Any |
Default |
|
tif and pdf |
Letter |
Print Mode |
---|---|
s |
Simplex |
s2 |
Two Up Simplex |
f |
Duplex |
f2 |
Two Up Duplex |
s2x |
Two Up Simplex Fit To Page |
f2x |
Two Up Duplex Fit To Page |
Default |
Printer Settings in the scenario |
Rebilling happens, when an invoice was issued to the wrong customer using the wrong billToCode and a correction must be made.
-
First, we have to issue a credit memo with the same billNo value, for the incorrectly billed customer.
-
Next, an invoice with the same billNo has to be sent to the correct customer.
Such a situation creates more than one entry in the lookup table for billToCode, for the same billNo value. In order to make sure to send each bill to the correct customer, we need to look up values in another column called DetailLineID. This is an integer column that has two different values for the same billNo. To use rebilling, the batch has the DetailLineID value, instead of the billNo.
X Stops are used to append information to an existing document. X Stops are extra stops that a driver makes on a route. You can configure Bulk Print to read the extra stop number from the freight bill (FB) number to create an instance of the document for distribution.
The Processing tab of most scenario configurations includes three (3) options for X Stops:
-
Disabled:X Stops do not run.
-
Separator: Allows a character to be set as a separator between the original FB number and the extra stop suffix.
For example, setting the separator to an underscore would be able to interpret a FB like: HV123456_ABC
-
Fixed Length: Counts the number of characters at the end of a string.
For example, the last two characters of a FB number could be the extra stop suffix, like: HV123456AB
Bulk Print finds all supporting documents for the original FB and the extra stops and attaches them all to the invoice.
On some Bulk Print configurations, under the Barcodes tab, you will see a group of fields called Direction and Rectangle of Interest.
The idea of limiting where to look for bar codes is to reduce the possibility of false positives: interpreting something as a bar code when it is not one, or — more commonly — interpreting the wrong bar code, if there are multiple.
Direction:
In most cases, a bar code should be read left to right.
Therefore, you would select only East (reading in the Easterly direction, if North is assumed to be the top of the page).
If you select all four directions, you may catch any bar code that can be read in any direction.
However, you also run the risk of misinterpreting some bar codes that do not provide context about their beginning or end -- because you may read them both backwards and forwards.
Rectangle of Interest:
Each number can be entered, to represent inches.
If all the entries are zero, then the bar code could be located anywhere on the page
The top and left coordinates help you find a starting point.
Then you would define a rectangle from that starting point, to the right and down (or width and height in inches).
Example:
To scan the top area of a page for a bar code sticker that reads left to right, you could use the following settings:
-
Direction: East
-
Rectangle of Interest: Top: 0; Left: 0; Width: 0; Height: 3
This would scan a left-to-right bar code in the top three (3.0) inches (7.62 cm) of the page.
By default, Synergize Bulk Print logs its activity to its own logging database tables, inside the Synergize repository. These tables are created using a script provided with the Synergize Bulk Print setup.
The logging database is also used for batch verification. This feature allows you to reprocess a batch that was only partially successful, and it will only reprocess failed steps from the previous run. During configuration, you can disable batch verification by checking Disable Batch Verification; it is enabled by default. See Batch Verification.
Bulk Print provides a comprehensive logging feature. However, you can also have the system write the logs to a database that you specify.
MS SQL databases can be used.
You can set up logging tables in each repository database you access.
You can also use local logging to a CE database.
If you are using local logging, the rest of this section is not relevant to you.
Configure Logging Tables in a Scenario
Feature First Available:
Bulk Print 2.3.2
October 2017
Prerequisites:
Synergize Server
Third-Party TMS
To set up logging within a particular scenario, follow these steps:
-
Configure the scenario to the last tab called Logging.
-
On the Logging tab, you can enter the Hostname, Username, and Password, to get Administrative access to the repository database you've chosen.
First, test the connection.
Once you have successfully connected, click Create Tables.
The tables are either set up now for logging, or the process confirms that they had already been set up previously.
In either case, you get a success message.
An error message comes up, if there is a problem with creating or accessing the tables.
Batch verification is the ability for Bulk Print to "pick up where it left off", when processing Batches. The technical background to this feature is important when troubleshooting. Alternatively, disabling batch verification allows you to "reprocess" a batch from the beginning.
Tables
There are three tables involved in batch verification:
Source Item Processed:
BulkPrint_Document: Document item processed (linked to source item)
BulkPrint_Action: Distribution details (linked to document)
The source item has a unique identifier.
This allows the system to determine if it has encountered the item previously.
Hierarchy and Identification of Items
Batches contain source items. A source item can be either a file or a document to be processed. A source item may also have metadata to be processed.
-
If a source item is a file, its unique identifier is a concatenation of the file CRC (checksum), a dash, and the file length. Although mathematically, there could be duplicate IDs for different files, the chances are infinitesimal.
-
If a source item is a document, it has a unique document identifier (which is the Synergize repository document ID).
Together, file IDs and document IDs are referred to as source item keys.
Batch Verification Process
-
When a batch is being processed, each source item in the batch is picked up and parsed.
-
If the source item has a valid structure and can be parsed, it is registered in the Source Item table.
-
During the distribution phase, the invoices, statements, and any other supporting documents for a file are sent to an Email Server, a Print Queue, or a Fax Machine.
-
Although Bulk Print gets a success notification for delivery to these secondary systems, it does not know the final disposition of these documents. In other words, a document is deemed to be successfully processed, as soon as it is successfully sent to the secondary processing system (SMTP server, print server, etc.).
-
If the intended recipients report that they did not receive the document, an investigation can begin at the secondary processing system.
-
When a batch is resumed with batch verification enabled, the Bulk Print processor first checks to see if a source item appears in the source item table.
-
If it does, then Bulk Print checks to see if a document from that source item was completed.
-
If the document was deemed to have been successfully distributed, it cannot be distributed a second time.
-
To resend a set of supporting documents to a customer at their request, a new source document (invoice) must be generated.
Related documents are Synergize documents returned from a search for a list of bills, regardless of their document type value. In other words, regardless of whether they will be distributed. In addition to updating supporting documents, you can also update related documents.
Each provider that updates a predefined field when saving a source document needs to have the ability to update that same field, for related documents. Please note that when the source doc details tab includes additional fields that come from the look-up, these fields are not meant to be updated for related documents. A check box indicates whether or not related documents should be updated for the scenario. This is a generic scenario setting on all providers.
Provider |
Updated Field |
---|---|
TruckMate |
If the source document is a statement, then the statement field for all related documents is updated If not, no related documents are updated (if not equal to key field) Default Behavior: Do not update related documents |
TMW Suite |
Source documents identified with Order Number, Doc Type, and optionally Workflow Queue Default Behavior:BackupOnly, where the supporting documents are updated with invoiceNumber, pegControlNumber, billTo, and optionally masterBillNumber. Other update options: None, InvoiceOnly, and AllDocuments. |
NetSuite |
The invoice field of all related documents is updated (if not equal to key field). Default Behavior: Do not update related documents |
Accellos and TransPlus |
If Trip scenario, then the TripNoField field of all related documents is updated (if not equal to key field). If not, the invoice field of all related documents is updated (if not equal to key field) Default Behavior: Update related documents |
MercuryGate |
The invoice field of all related documents is updated (if not equal to key field) Default Behavior: Do not update related documents |
Innovative |
Not Applicable |