mSupply has an interface with the iVEDiX reporting API. The interface allows the automatic sending of batch and transaction information to the iVEDiX reporting platform.
The preferences that define how this interface works are managed on the iVEDiX tab of the File > Preferences menu. The tab looks like this:
NOTE: the fields on this page are disabled if mSupply's synchronisation system is not in use.
;
).
Batches are sent to iVEDiX whenever a stockline is created (e.g. when a supplier invoice or inventory adjustment-add is confirmed) or updated (which means that either the batch or expiry date is changed) in any store with a WHXXXX
code (where XXXX is a 4 digit number) or its corresponding malaria store (which will have a matching GF-MAL-XXXX
code).
The batches are sent using the /batch/createUpdate
endpoint of the API using these fields:
Transactions are all sent to iVEDiX when they are confirmed. Transactions are only sent from stores having a WHXxXX
code or a corresponding GF-MAL-XXXX
code and transactions in any GF-MAL-XxXX
store are sent as if they were in the WHXXXX
store. Stock transfers (or credits) between a WHXXXX
or GF-MAL-XXXX
store are ignored and not sent to iVEDiX.
If a transaction is edited or a line added or removed from it, the whole transaction is sent again, in its new form, to iVEDiX.
The transactions are sent using the /inventoryStockStatus/updateInventory
endpoint of the API using these fields:
There are actually two schedulers running to control sending transactions to iVEDiX: one picks up all new transactions and sends them for the first time. The other picks up all the failed transactions and sends them again until they have reached the maximum number of retries before permanent failure.
If errors are encountered during either of the sending processes then the information to be sent is entered into a queue. All pices of information (batches or transactions) in that queu are attempted to be resent after the number of minutes stored in the Interval between retries field. When a piece of informaiton is successfully sent it is removed from the queue. If a piece of information is not sent successfully after the number of retries in the Number of times to retry sending field then it is removed from the queue, the final failure is logged (see the 25.19. The system log page for details on how to view the log) and an email giving details of the error is sent to the email address stored in the Send errors ro this email address field.
Previous: 23.08. HL7 and Tamanu/Patis Plus integration | | Next: 23.10. Siglofa integration |