Skip to content

VISION Integration

Jump to bottom Edit New page
fungbo edited this page Jan 3, 2016 · 7 revisions

VISION Integration

The VISION integration feature is used instead of VISION import. The VISION integration allows for the capability to pull down Consignee, Programme, Sales Order, Purchase Order and Release Order data automatically through the particular endpoints provided by Unicef WebService, then save those data into Eums database.

How to work

The VISION integration function needs a start date to work at the first time. The start date can be set on the Admin/Settings page, once a start date is set, the sync will be triggered immediately. It may takes a long time, depends on the start date just set. Note that currently the start date can only be changed to an earlier date. e.g. The start date is set initially to 10-Dec-2015, the start date can be changed to 1-Dec-2015, but can not be changed to 20-Dec-2015. After the first time sync, the sync task will be run at midnight daily.

Sales Orders

Below are the required fields:

  • SALES_ORDER_NO
  • MATERIAL_CODE
  • SO_ITEM_DESC
  • NET_VALUE
  • WBS_REFERENCE
  • SO_ITEM_NO
  • CREATE_DATE
  • UPDATE_DATE

NOTE: All other sales order fields pulled down from the WebService will be ignored. The WBS code got from the WebService is usually like 4140A004118007001, EUMS removes the last 6 digits and add slash before importing to the system. So the WBS code is like 4140/A0/04/118 in EUMS.

Current functionality for the sales order import goes as follows for each sales order object:

  1. Look to see if a sales order exists in system matching the SALES_ORDER_NO. If no sales order exists a new one is created, else the matching value is used to import the sales order item.
  2. Find if a sales order item already exits in system matching the SO_ITEM_NO as well as the MATERIAL_CODE and SO_ITEM_DESC If no sales order item exists in the system a new one is created else it is ignored.

Purchase Orders

Below are the required fields:

  • PO_NUMBER
  • PO_ITEM
  • PO_TYPE
  • MATERIAL_CODE
  • MATERIAL_DESC
  • AMOUNT_USD
  • PO_ITEM_QTY
  • SO_NUMBER
  • PREQ_ITEM
  • CREATE_DATE
  • UPDATE_DATE

NOTE: All other purchase order fields pulled down from the WebService will be ignored. Only purchase order types NB, ZLC, ZUB, ZOC are supported in EUMS, any other purchase order types will be ignored.

The purchase order import requires sales orders to exist in the system in order to tie purchase orders to a relevant sales order.These must exist in order for purchase orders to be imported.

NOTE: The creating of the purchase order item no longer tie the existing of the sales order item.

Current functionality for the purchase order import goes as follows for each purchase order object:

  1. Look to see if a purchase order exists in the system matching the PO_NUMBER If a matching value is found it is used to import the purchase order item. If no matching purchase order is found, the import first looks to see if a matching SO_NUMBER exists in the system. If no sales order exists, this purchase order is ignored and the import moves onto the next one, else if found a new purchase order is created.
  2. If a purchase order is imported in step 1, all purchase order items related to this purchase order will be imported into system unless it has some invalid field value, such as zero amount.

Release Orders

Below are the required fields:

  • RELEASE_ORDER_NUMBER
  • RELEASE_ORDER_ITEM
  • SHIPMENT_END_DATE
  • MATERIAL_NUMBER
  • DELIVERY_QUANTITY
  • VALUE
  • CONSIGNEE
  • SO_NUMBER
  • PO_NUMBER
  • WAYBILL_NUMBER
  • PO_ITEM

NOTE: All other release order fields pulled down from the WebService will be ignored. Any release order item that has nill for quantity, value, waybill, consignee details or shipment end date will NOT be imported.

The release order import requires sales orders and purchase orders to exist in the system in order to tie release orders to a relevant purchase order and the corresponding purchase order items. These must exist in order for release orders to be imported.

Current functionality for the release order import goes as follows for each release order object:

  1. Look to see if a release order exists in the system matching the RELEASE_ORDER_NUMBER If a matching value is found it is used to import the release order item. If no matching release order is found, the import first looks to see if a matching SO_NUMBER and matching PO_NUMBER exist in the system. If any of these are not found, this release order is ignored and the import moves onto the next one, else if both are found a new release order is created.
  2. Find if a purchase order item already exits in system matching the PO_NUMBER and the PO_ITEM. If no purchase order item exists in the system that release order is ignored.
  3. However, if a purchase order item is found then look to see if a release order item already exits in the system matching the RELEASE_ORDER_ITEM and having the same purchase order item found in step 2. If no release order item exists in the system a new one is created, else it is ignored.

Consignees

Below are the required fields:

  • CONSIGNEE_NAME
  • CONSIGNEE_CODE

NOTE: All other consignee fields pulled down from the WebService will be ignored. Only the CONSIGNEE_CODE will be treated as the identification as consignees with the same name may have multiple CONSIGNEE_NAME.

Current functionality for the consignee import goes as follows for each consignee object:

  1. Look to see if a consignee exists in the system matching the CONSIGNEE_CODE, if a matching one is found, the consignee name will be updated as per the CONSIGNEE_NAME, else a consignee will be created.

Programmes

  • OUTCOME_DESCRIPTION
  • OUTCOME_WBS

NOTE: All other programme fields pulled down from the WebService will be ignored.

Current functionality for the programme import goes as follows for each programme object:

  1. Look to see if a programme exists in the system matching the OUTCOME_WBS, if a matching one is found, the programme description will be updated as per the OUTCOME_DESCRIPTION, else a programme will be created.

Code Instruction

sales_order_synchronizer.py
The class is used to sync sales orders.
purchase_order_synchronizer.py
The class is used to sync purchase orders.
release_order_synchronizer.py
The class is used to sync release orders.
order_synchronizer.py
The parent class of three orders synchronizers above.
consignee_synchronizer.py
The class is used to sync consignees.
programme_synchronizer.py
The class is used to sync programmes.
vision_data_synchronizer.py
The parent class of orders, consignee, programme synchronizers above.
sync_runner.py
The class is used to run cronjob.
handles.py
The class is used to listen the change of the start date, once an earlier start date is set, this class will trigger a sync task immediately.
vision_sync_info.py
The database table to record the sync status.

Add a custom footer
Add a custom sidebar
Clone this wiki locally