Synchronizing data to Bitlog API
Supported Data Models
Q: How is data downloaded?
A: Via endpoints (from erp) using last changed date time
Synchronizing transactions via Bitlog API
For every stock transaction that is performed in Bitlog WMS a synchronization (sync) record is created at the background. These sync-records can be retrieved via Bitlog API. Following is the list of most common record types that are created:
In Incoming transaction, such as receive of a purchase order or customer return
Out Outgoing transaction, such as shipment of a sales order
Move Movement of stock between warehouses
Take Positive or negative stock takes
These transactions can be retrieved and updated using transaction/sync endpoints:
The most common way to handle sync transactions is as follows:
Call GET sync to retrieve the next available transaction
Report the result of processing by calling PUT sync
Repeat the sequence until GET sync returns null, meaning that the sync queue is empty
This endpoint will give you the next available not blocked transaction according to the transaction time. Transaction can be blocked by an earlier transaction for the same stock item.
For example, let's consider the following two transactions:
If you get a problem processing transaction Id 10 and you report it as failed, the transaction Id 11 will get blocked because there is a big chance that it will fail as well (we cannot ship something that is not on stock).
The blocking process is performed automatically by the API by examining blocked transactions when looking for the next one that is waiting. This also means that the more transactions get blocked, the bigger a chance that you get a chain reaction of blocking.
Unblocking of transactions can be done only in WMS Manager as of right now. There you can either try this transaction again or mark it as resolved.
GET sync/Id Use this endpoint to retrieve a transaction by its Id.
Use this endpoint to report the result of processing a transaction at the backend. The most common is to send 1 as a result of a successful operation and a negative value and an error message in a case of a faulty one. You may include a message even on successful operation, such as a reference number that can be used to trace transactions at the backend.
Examples for transactions