Microsoft Dynamics Purchase Order Integration - Reference
Integrated Fields
The integration of Microsoft Dynamics Purchase Orders to Framework 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.
- Read profile keys to determine which actions to process.
- Process Cost Centres
- Read all eligible records from Framework table int_cCentreGrp where
- Int_cCentreGrp.l_link_sys_gl_id = -2124 (Dynamics)
- Int_cCentreGrp.l_int_cCentreGrp_id <> 0
- For each record get matching Dynamics record in table DynCostCentreGroupwhere
- DynCostCentreGroup. groupID= int_cCentreGrp.s_link_cCentreGrp
- Update the int_cCentreGrp.s_link_name field
- Read all eligible records from Framework table int_cCentre where
- Int_cCentre.l_link_sys_gl_id = -2124 (Dynamics)
- Int_cCentre.l_int_cCentre_id <> 0
- Int_cCentre.l_int_cCentreGrp_id <> 0
- For each record make sure the int_cCentreGrp linked record exists, and if so get the matching dynamics record in table dynCostCentre where
- dynCostCentre.costCentreID = int_cCentre.s_link_cCentre
- dynCostCentre.ccGroupID = int_cCentreGrp.s_link_cCentreGrp
- Read all eligible records from Framework table int_cCentreGrp where
- Process Entities
- Get the Framework Db Identifier preference for each context, if a context does not have a setting use the default value for that context.
- Read all eligible records from Framework table int_entityGrp where
- Int_entityGrp.l_link_sys_gl_id = -2124 (Dynamics)
- Int_entityGrp.l_int_entityGrp_id <> 0
- For each int_entityGrp record get the matching Dynamics record from dynSupplierGrp where
- dynSupplierGrp.groupId = int_entityGrp. s_link_entityGroup and update the group name
- Read all eligible records from Framework table int_entity where
- Int_entity.l_link_sys_gl_id = -2124 (Dynamics)
- Int_entity.l_int_entity_id <> 0
- For each record get matching Dynamics record in table dynSupplier where
- dynSupplier.supplierId = int_entity.s_link_entity
- dynSupplier.contextId = int_entity.l_context_id
- dynSupplier.sourceDatabase = value for FW Db Identifier for that context, update the int_entity.s_link_name, int_entity.f_nonCompliance and int_entity.f_preventAlloc fields.
- Get matching int_entityGrp.l_int_EntityGrp_id record where dynSupplier.groupId = int_entityGrp.s_link_entityGrp, update the int_entity record with the correct group link.
- Update the linked entity's name, abn and acn, update that entities address details, add or update that entities bh, fax, mobile or email details.
- Process Orders
- Get the Framework Db Identifier preference for each context, if a context does not have a setting use the default value for that context.
- Get eligible Framework jobs from v_sched_dbJobOrders where
- Job.s_link_boq <> ‘N/A’
- Job.l_job_id <> 0
- If profile key ‘Context’ is not 0 then add criteria
- Job.l_context_id = ‘Context’ (profile key)
- and apply order criteria where OrderCriteria is
- 2 – Construction Manager • Cst.l_mgr_e_id = ‘OrderCriteriaID’
- 3 – Supervsor • Cst.l_super_e_id = ‘OrderCriteriaID’
- 4 – Single Job • job.s_job_num = ‘OrderCriteriaID’
- For each job get orders and items from Dynamics where
- dynPurchOrder.projId = job.s_job_num
- dynPurchOrder.sourceDatabase = Fw Db Identifier for this jobs context.
- dynSupplier.sourceDatabase = Fw Db Identifier for this jobs context
- dynSupplier.contextId = job.l_context_id
- If profile key OnlyIntegrateNew is true, add additional criteria where
- dynPurchOrder.dateOrdered >= ‘StartIntegrationDate’ – 7 days
- dynPurchOrder. dateOrdered <= ‘EndIntegrationDate’ or now if endIntegrationDate is none.
- Once we have the Dynamics Order, see if it exists in po_order table where
- Po_order.s_jobNo = job.s_job_num
- Po_order.s_link_boq = dynPurchOrder.orderId
- And we check each Dynamics Order Item, by seeing if it exists in po_item table where • Po_item.s_link_item = dynPurchOrderItem.orderItemId
- Orders and items are updated or added. At the end of integration items are checked to see if there are any that need to be removed from Framework.
Needs to be in Construction Stage.
When doing the integration, the program looks at job.l_rpt_index2 it gets the number entered in that field and it checks the ini profile for the key OfficeContext(x)=y where x is equal to the value in job.l_rpt_index2. If it finds this key then it puts the value of y into the contextID. If it does not find an officeContext setting for that value then it uses job.l_context_id and copies this value into the contextID fields. So if you change a jobs context identification, it will only change the contextID field if the ini profile has a key for that OfficeContext. I hope you understand it? Here's an example Job #1 has a job.l_context_id of 1, but a job.l_rpt_index2 of 270 If the ini profile has the key OfficeContext(270)=4 then when integration runs, it will set the FramProj.contextID for Job #1 to be 4. If it does not have the OfficeContext key then the FramProj.contextID will be set to the job.l_context_id value of 1. If you then change the context identifier for Job #1 to be (269) then rerun integration, if there is a key called OfficeContext(269)=2 then the FramProj.contextID will change to 2. If the OfficeContext key does not exist then the FramProj.contextId will change to 1. This is because the key couldn't be found so it uses the value in the job.l_context_id field instead.