There are various options to give users different ways to managed posts that fail or to manage a process where communication to the ERP software is not reliable. Understanding the Post Types available with TransLution will allow users to make the right decision for their environment.

 

There are a range of Post Types available on the Post Step configuration as shown below. The options apply when either Step Mapping and Table mapping have been selected. The difference between Step mapping and table Mapping are shown here Step vs Table Mapping

 

 

 

Post Step Definition

 

 

 

 

Each Post Type is described below:

Live Post - With this mechanism, the post is attempted as the user reaches the post step in the function. If the post fails, the function ends and there is no opportunity to re-try the post.

 

Live Post with Retry - If this option is selected, the post is attempted as before but this time, if there is an error the user has an option to retry. The error message will tell the user why the post failed and they have the opportunity to fix the problem before re-trying the post. The retry will use exactly the same data as the original attempt but say for example the post failed because a stock code in Syspro was on hold. The user can get the stock code taken off hold and then the retry will result in a successful post. The two live posting options are the recommended options if at all possible. The greatest risk with any kind of integration is managing failures after the event and live posting reduces that risk as far as possible.

 

Live Post with Retry

 

Buffered Post - This option will log the data that would be posted to a posting table and the posts will then be attempted in sequence in this table. If this method is used, the user is not presented with information about a failed post since the posting is not done as part of the scanning process. If the communication to the ERP system is not reliable then this is a useful option.

 

Live Post with Buffer or Retry - The final option tries to offer the advantages of all the other options. A post is attempted as the scanning proceeds. If there is no error then everything continues. If there is a posting error, the user can choose to retry or Buffer the post. If they select retry then the post is re-attempted. If they select buffer then the data is logged for later posting and the user can continue scanning. If there are multiple post steps in a function, or the same post step is reached multiple times, once one row has been buffered, all subsequnt rows are automatically logged for buffered posting. The reason for this is that if for example rows are buffered because the ERP communications is not working, the asking the user on each poast step to buffer is irritating. The steps will all be processed once communication is re-established. Another reason for this is that if posts are dependent on each other for example, a job receupt running after a job issue, you want to be sure the processing will still happen in sequence. Logging all rows for buffering deals with that too.

 

Live Post with Buffer or Retry

 

Technical Data

Data for buffered posting is written to the table BUFFER_POST_DATA

Possible row statuses are:

5 - New row ready for processing

15 - Error row. Processing failed

20 - Processing was successful

50 - Cancelled Row. Will not be processed

 

The following is important:

If one row on a given scanner job fails, that row will be set to status 15. If the current post step is set to be dependent on another post step (including itself) then as long as there is one row in status 15 for a given scanner job, no subsequent rows will be processed. In order to process these rows the initial row must either be cancelled or processed successfully (status 20 or 50).

 

However, if subsequent posts steps are not selected to be dependent on another post step then they will attempt to post regardless of the status of the initial post step. 

 

The option to choose depends on the requirements of your specific implementation