The TransLution General Posting Service is the service that manages all our background functions - Unattended Function Areas, General Posting and Buffered Posting.

 

This Service runs in the background and monitors data in various tables depending on the functionality that is required. All that is required is to install and set up the service and put the required data into the correct database table/s. All of the necessary steps are described below.

 

 

Database Settings

 

The details of which TransLution database and which Syspro company to communicate with are defined in the TransLution Utility Control Database. This is also where the General Posting Service support for multiple TransLution databases posting to multiple Syspro companies is defined.

 

The first step is to define which TransLution databases the service should monitor. These values are set in the DATABASE_NAME_SETUP  table as shown below. There is one row for each database to be monitored. The key columns are shown below. Any of the Syspro users can be specified here.

 

 

 

The next step is to define which of the elements of the service to run and these settings are done in the TRANSLUTION_SERVICE_SETTING table as shown below. All of the threads supported by the General Posting can run with their own timer and timeout interval. In order for a service to be used, it must be marked active here and also in the Config.exe file as shown below. Please note that the service does not execute immediately on start up. There is a 120 second delay before the initial service execution will begin.

 

 

 

 

 

General Posting - This is the original way of doing unattended posting before buffered posting was introduced. The aim is to replace all instances where this is used with buffered posting but there are still a few scenarios where buffered posting cannot be used. The first is the creation of documents with header and line portions and the second is when data in a table will need to be grouped and summed before posting.

 

Buffer Posting - This is intended to replace General Posting. It is easier to use and troubleshoot and also is what allows users to continue scanning if a live post fails - they can buffer the post and then continue scanning. This offers a compromise where you would prefer live posting but need a way to deal with cases where the network is down. This was the original aim of general posting and buffered posting is a much better alternative sicne General Posting never offers the live posting option.

 

Check Service - This is a utility that checks if the TransLution services are running

 

Unattended - This thread manages unattended function areas. if there are no unattended function areas, this is not required.

 

Stock Transit - this is no longer used. The first version of the General Posting Service managed GIT transfers only.

 

 

Configuration File Settings

 

Browse to the folder where the General Posting Service is installed (default is C:\Program Files (x86)\TransLution\TransLution General Posting Service) and edit the file TransLutionGeneralPostingService.exe.config as shown below.

 

GeneralPostingService exe config file

 

The server name tells the system where to find the Utility control database which contains the settings described above

The lines with Run.... allow you to specify which of the elements supported by the service must be executed. While nothing with break if you select to enable a feature that is not used, there is overhead used each time and also, the event log will log that nothing is happening. If you are trying to find problems by using the even log then it makes sense not to log rows that are meaningless.

 

The service can run in a pre-defined time window which is what the last two highlighted lines show.

 

Table Setup required for General Posting to create documents

 

Database Table Structure

While any table name can be used, we recommend a naming structure as follows: tbl_GeneralPost_BOName_BODescription. Some examples would be:

tbl_GeneralPost_INVTBF_InventoryBackflush

tbl_GeneralPost_INVTMA_InventoryAdjust

tbl_GeneralPost_WIPTMI_ WIPSpecfic Issues

 

A table per business object must be exist in the database before the TransLution configuration described below can be completed.

 

Any columns can be mapped to business object tags but every general posting transaction table MUST contain at least the following fields:

ID - a unique ID field

ProcessStatus - any rows that are in status 5 will be processed - all process statuses are covered in detail in the Technical Troubleshooting guide

Response - this is where the response from Syspro is stored

AUDIT_TIME - Audit time

AUDIT_APP_USER - user

BUSINESS_OBJECT_EVENT_ID - the details of what data was posted to Syspro are stored in the Business Object Event table. This gives us a link to see what was posted. The XML files posted are stored in this table as well.

ReferenceTableName - this is to allow conditional posting as described below

ReferenceTableNameID - also for conditional posting

 

 

The service looks for all rows in a process status of 5 (unprocessed) and when the call is complete, updates the status either to 20 for a successful post to Syspro or to 15 to indicate an error. If the row is in status 15, there will also be the Syspro Error message in the Response field.

 

Both standard XML values and parameter values can be stored in this table and mapped to scanned data before posting to Syspro.

 

Generally, if there is no Transaction Date element specified when a transaction is posted to Syspro, the current date is used which is exactly what we would require.

 

Business Object Maintenance

The business object XML files are set up as before with one change:

The "Allow Multiple Items" MUST be checked, as follows:

 

The "multiple items will cause the "<Item></Item>" XML structure to repeat once for each row in the relevant table used for posting.

When creating a document, the Post as Document tag MUST be checked. You also need to tell TransLution which XML tags are used in the SYspro setup to define the document header and details

 

Function Area Maintenance

The General Posting service requires a function area per business object that will be posted. There are some very specific requirements on the function area so it is important to follow the steps below.

 

For the service to work, the function area must be defined as an ERP calling function area with the INVTBF business object defined. The changes to the Function Area Maintenance are described in the following diagram.  The Function Area name or description, in this case Backflush, can be anything but the important item is to select the option Make ERP Call from this function area.

 

There are more configuration items on the second tab as shown below

 

 

The highlighted information above must be set up as shown.

The "Run as Service" must be checked otherwise, it will not be found by the service.

The Business Object Name must be the Syspro business object name.

The General Grid/Service tables must be defined as the table from which the service will read the source data. The Line and document table will always have the same table name.

Once the tables have been selected, then the Business Object tags can be mapped to the Line Table columns. This is done in a similar way to the mapping of the columns in a TransLution Selector view. The required structure for this table is described above and the table must exist before this configuration can be done.

 

The mapping process is shown below:

 

 

 

 

Conditional Posting

 There are occasions when it is required to post one transaction only after another has posted successfully. This can be hard to manage when there is a service running on a timer basis. It is possible that the timer can tick between the two events thereby getting the posting out of sync. An example of where this matters is with job issues and receipts. You may want to be sure that a specific issue to a job has posted successfully before the job receipt is posted. This can be achieved by using the ReferenceTableName and ReferenceTableID columns on the table for the first transaction.

Say for example you want a Job Receipt to happen after a specific issue (or a group of specific issues). In the Job Receipt table you would specify the name of the specific issues table and also the ID of the last specific issue. The job receipt would not post until that line in the issue table had a status of 20 (successfully processed) 

 

Summing Posted Data

If there are multiple transaction rows in the table in status 5 when the service is due to run, each row will be posted individually. They will be part of a single Syspro business object call but will result in 20 transactions in Syspro. If the last column on the mapping table above is checked next to the quantity field then all rows that can be grouped and summed will be grouped to form a single row. This does not mean that 20 transactions will automatically be reduced to 1 transaction. If there are 10 transaction to a job receipt of a single item at a time for job 1 and another 10 rows for job two then there will be two rows posted each with a summed quantity of 10. This is an important way to reduce both transaction numbers and journal numbers in Syspro. It does of course mean a loss of detail. it will not be possible when grouping and summing to pass for example a unique reference or notation per individual transaction. The requirement whether to group or sum or not is generally driven by transaction volumes.