Integration Profile Configuration

The following outlines the settings for BuilderMT WMS Purchase Orders integration .ini file profiles.

Default initialisation filename: 

• Int_WMSOrders_Default.ini

Settings

Databases

Mail Configuration

Criteria

Actions

Integrated Fields

The integration of BuilderMT WMS Purchase Orders to Framework ECM is fixed in the content that is exchanged between the systems. There are no user-configurable integrated fields available to this type of integration.

Database Models

The following database model(s) displays the manner in which data is integrated between the third party application and Framework Integration.

Integration Process

The following information is a low level account of the integration process including criteria, decisions, and outcomes. This information is technical in nature and is provided "as-is" for a detailed analysis of the integration process for system administrators.

1. Read profile keys to determine which actions to process.
2. Process Cost Centres only performed if MaterialClassLink method is "Internal" (-2149)
   1. Read all eligible records from Framework table int_cCentre where
      1. Int_cCentreGrp.l_link_sys_gl_id = -2026 (Timberline)
      2. Int_cCentreGrp.l_int_cCentre_id <> 0
   2. For each record, get the matching WMS record in table pactivity where pactivity.pactivity_id = intcCentre.s_link.cCentre.
      1. Division.Div_id = int_cCentreGrp.s_link_cCentreGrp
   3. Update the int_cCentre.s_link_name field with pactivity.activity.
3. Process Entities
   1. Read all eligible records from Framework table int_entity where
      1. Int_entity.l_link_sys_gl_id = -2026 (Timberline)
      2. Int_entity.l_int_entity_id <> 0
   2. For each record get matching WMS record in table Supplier where
      1. Supplier.sub_number = int_entity.s_link_entity
   3. Update the int_entity.s_link_namewith supplier.sub_name
      1. The linked entity name and ABN are updated.
      2. The primary address is created or updated.
      3. The various telephone records are updated or created. These include Business, Fax, Mobile, and Email.
         • Business and Fax numbers are extracted from the appropriate Supplier fields.
         • The Mobile and Email fields are extracted from one of the three WMS Supplier Sub Contact fields, the appropriate field being determined by cycling through the supplier’s Scheduling Contact and Purchasing Contact flags and finding the first that is set to “T” – failing to find one will default to the first Sub Contact.
4. Process Orders
   1. If processApprovals is 1 or 2 then:
   2. If internal code is the preference setting for material class link method then the Framework po_order table is checked for any orders where the cost centre code is missing but the cost centre description is entered. We then use the description to find a match in int_cCentre. If a match on the name is found then the int_cCentre.s_link_cCentre value is copied into the po_order records cost centre code. Any orders that need updating will have their items checked to make sure there are no missing cost codes for the items. If there are then the items will be updated to match the order.
   3. Get eligible Framework jobs from v_sched_dbJobOrders where
      1. Job.s_link_boq <> ‘N/A’
      2. Job.l_context_id = ‘Context’ (profile key, if 0 all contexts)
      3. and apply order criteria where OrderCriteria is
      4. 2 – Construction Manager • Cst.l_mgr_e_id = ‘OrderCriteriaID’
      5. 3 – Supervisor • Cst.l_super_e_id = ‘OrderCriteriaID’
      6. 4 – Single Job • job.s_job_num = ‘OrderCriteriaID’
   4. For each job get orders and items from WMS where
      1. poHeader.poJobNumber = job.s_job_num
      2. If profile key OnlyIntegrateNew is true, add additional criteria where
      3. poHeader.poDateIssued >= ‘StartIntegrationDate’ – 7 days
      4. poHeader.poDateIssued <= ‘EndIntegrationDate’ or now if endIntegrationDate is none.
   5. Once we have the WMS Order, see if it exists in po_order table where
      1. Po_order.s_jobNo = job.s_job_num
      2. Po_order.s_link_boq = poHeader.poHeader_id
   6. And we check each WMS Order Item, by seeing if it exists in po_item table where
      1. Po_item.s_link_item = poDetail.poDetail_id
      2. Po_item.l_po_order_id = po_order.l_po_order_id
   7. Orders and items are updated or added if the poHeader.poStatus is <> 5(cancelled). Records that exist already for an order that has been cancelled are deleted when an order is created in Framework. A po_orderAppd record is also created.
   8. Cost Centre codes are determined based on the preference setting for the material class link method.
      1. If preference = description code (-2148) then
      2. orders are linked by poheader.poNumber > po_order.s_costCentreCode.
      3. Items are linked by podetail.pActivity > po_item.s_costCentreCode.
      4. else
      5. if preference = internal code (-2149) then
      6. orders are linked by poheader.poDescription = int_cCentre.s_link_name then the int_cCentre.s_link_cCentre value is copied to po_order.s_costCentreCode.
      7. items are linked by podetail.pactivity = int_cCentre.s_link_name then the int_cCentre.s_link_cCentre value is copied to po_item.s_costCentreCode.
   9. ix. The various supplier details (Name, Business, Fax, Mobile and Email) are obtained from either the WMS Supplier Area table, if there exists a supplier specific for the order, or from the WMS Supplier table if there is not.
      • The Mobile and Email fields are extracted from one of the three Sub Contact fields, the appropriate field being determined by cycling through the supplier’s Scheduling Contact and Purchasing Contact flags and finding the first that is set to “T” – failing to find one will default to the first Sub Contact.
   10. At the end all eligible jobs have all their orders checked to see if those orders still exist in WMS, any orders that are not found are set as cancelled.
5. Process Order Approvals
   1. If processApprovals is 1 or 3 then:
   2. The WMS User ID (from preferences) is checked to ensure validity.
   3. If valid, then Framework p_orderAppr records are retrieved based on the approval type being processed (from preferences).
   4. If type is Approval 1:
      1. poheader.task_complete_date is d_payment1_appd
   5. If type is Approval 2:
      1. poheader.task_complete_date is d_payment2_appd
   6. If type is Latter of Approval 1 or Approval 2 then:
      1. poheader.task_complete_date is the latest date entered in either d_payment1_appd or d_payment2_appd where only 1 of those 2 dates has a value entered.
   7. If type is Latter of Approval 1 AND Approval 2 then:
      1. poheader.task_complete_date is the latest date entered in either d_payment1_appd or d_payment2_appd where both dates must have a value.