There is more than one way to communicate with Syspro using TransLution and this section of the help files is intended to give you an understanding of the options available so that you can make the best choice for your environment.

 

The two main options available are live posting or buffered posting.

 

Live posting has the benefit of posting the data to Syspro as you scan. Say for example you want to do a stock adjustment in Syspro. The user will be required to scan the warehouse and stock code to adjust and enter the quantity. As soon as he enters the quantity, the data will be posted to Syspro and the adjustment will happen in effectively real time. On step functions there is also a retry function that will post exactly the same data again. Say for example the error received was stock code on hold - if this is a mistake, the problem can be corrected in Syspro and the post retried at which post will succeed.

 

With buffered posting, the XML data to be posted to Syspro is created and then the file is logged to a database table and as the Background Processing Service runs (on a configurable timer basis) all rows that have been logged and not yet posted are posted. There are some extensions to this - if one post in a job fails then you can set up the posting so that no other posts will be attempted (dependent posts) or you can ignore any failures and attempt each post as it stand (independent posts)

 

It seems that Live posting would be a preferable option under most circumstances but this is not always the case. One of the main reasons for selecting to use the service relates to network integrity.

 

If a site is widely distributed and the connectivity is not as good as they would like it to be, buffered posting general handles retries and failures better than live posting. TransLution does have the option to allow for users to select Live posting as the default and then, if for some reason the post fails, then giving the user the option to select to buffer that specific post. This works well if failures are rare and is described here.

 

 

TransLution also offers the option to do a post from table. In this case users scan data, generally multiple rows of data and the scanned data is logged to a database table. Only when the user selects to post or the function goes to a POST step is the data from the table taken and a single post built up from all the rows. As before, this XML file can then be posted directly to Syspro (Live post from table) or it can be saved in the buffered post table to be posted off line (Buffered Post from table).

 

There are some very good examples where table posting makes a lot more sense than step posting. PO Receiving is one such scenario. If you do a post for every line item that a user scans, Syspro will create a GRN per line which is generally not what people want. If you scan and log all the lines for a single receipt and then post at the end, one GRN is created for the whole receipt which makes a lot more sense in most cases.

 

There are also some kinds of posts for document creation that require a post from table such as a SORTDN to create a dispatch note with multiple lines.

 

On the grids - both TL Selector and General Grid there is also the option to choose to do a live post or a buffered post and the same reasoning would apply here.

 

The following section covers both Live and Buffered Posting