We are currently using Epicor P21. I am interested in particular to hear how one manages the transfer of inventory transactions from one platform to the other for operational/ServiceMax purposes in ServiceMax and then managing the Parts Usage lines back into the ERP for billing purposes.
Hi Scott - this could be a pages long reply but I'll keep it to a single idea. We are SAP house and design was to create Consignment Orders in SVMX, interface to SAP, and then interface back Consignment Delivery to SVMX. SVMX then tracks stock through semi-standard processes in adding to the Work Order. Work Order interfaces to SAP and issues goods out of consignment to service order. Parts Returns and Transfers are managed out of SVMX and interfaced back to SAP for corresponding order creation. We've done most of that customization on top of the base SVMX tools for inventory.
My one recommendation here is to absolutely, 100% hold firm on one system being the master for current consignment. For example (if your master is your ERP), you can do any number of transactional things on the CRM side to facilitate control/usage, but would strongly consider interfacing current master data over from your ERP to keep things in sync at all teams. It really needs to be able to self-heal or the support end of it becomes very difficult. This is not a reflection of any inherent SFDC/SVMX issue of course, but rather an architectural rule that should be held whereby your system of record is always positioned to keep consignment in order without support intervention. In my opinion, no fancy functionality on the transactional side is worth a challenging master data situation. Climbing down from my soapbox now
I sense the journey, from which your reply originates. We are currently in a 2 way integration with our crm and erp. It is cumbersome. We are relaunching with a one way street where the erp is master, and data is one way. We are looking for user experiences passing inventory, so that once in play in servicemax, its in limbo in the erp until billing,so we may follow it from receipt by servicemax user to consumption.
Thanks for sharing. I am inclined to agree.
We use Oracle as our ERP, and Oracle is very much our master (in many ways!) and we use Talend as the middle ware, though we run it in batch mode, where the transfers are scheduled to run on regular basis. Because we run scheduled jobs for both stock transactions and invoice orders, there is a inherent delay in getting all of the latest data, so our current compromise, is that we update trunk stock levels in Smx over night, and then use the Smx inventory process to manage the stock system in Smx during the day, this gives local Smx users real time details of stock consumption and availability, rather than having to wait for the Oracle updates to be processed.
This is similar approach to ours but with tighter intervals and using BOOMI. The problem on our end is that the concept of "Trunk Stock" is not used which makes more difficult the use of SVMX processes. Instead we tie inventory to specific Work Orders to drive required behaviors. I would definitely recommend leaving things as simple as you can, while putting focus on master data consistency. As we all know you can never start simply enough, but trying will give the most flexibility in evolving to follow tool and business going forward.
We have integration with JD Edwards (8.98.) and use Jitterbit for a middleware. We do not use any of the inventory functionality in SVMX other than reporting what was used on a work order. Inventory reconciliation is a manual process, but the data source is a report out of SF/SVMX. Our integrations, however, are on both the A/R and A/P side.
A/R side: for any Billable Work Orders, we create "Billing JDE" lines upon Close, which are extracted to a .csv, pushed to JDE, and returned with an upsert of the JDE order # back into the work order.
A/P side: Subcontractors (Partner Community members) complete their work order (they enter all financials like Labor, Travel, Parts, Expenses, etc) and Regional Service Managers approve and close the work order. Subcontractors have a Vendor A/P account # assigned to their technician record, and a GL account is based on the Order Type/Billing Type combo of the work order. This data, along with the dollar amount being billed from the subcontractor to us, is uploaded nightly. JDE A/P Voucher # is then returned to SVMX and upserted to the Work Order - notifying the subcontractor that payment is in process.
These two integrations had a huge impact on manual data entry reduction, "going paperless" initiative, streamlined and expedited business processes, revenue recognition timeliness, and overall visibility across the org and with our partners.
Hi Scott Willis, this is a great question and its brilliant to see you getting lots of feedback from the Community!
At Pitney Bowes we have integration with SAP for Parts.
We use Cases and Work Orders. When a Part is used on a job its recorded as a Work Detail. We have built functionality that then decrements the relevant Product Stock record at the point of Work Order closure. The next step is we send the consumption to SAP which is our stock system of record and the stock is decremented there.
There is a nightly refresh from SAP that updates ServiceMax Product Stock.
If a stock movement is required then I cant remember what we setup in ServiceMax for decrementation. However once it gets to SAP it does a move to the new location and then consumes the stock.
We use 'Parts Request' object to capture the moves.
We also have parts order functionality that uses the standard ServiceMax Parts Order and Parts Order Line objects. It then creates an outbound message record in an object we created for this. A batch job then picks it up and sends it to SAP. This runs every 30 minutes. I strongly recommend some sort of message content capture such as an outbound message log. It makes troubleshooting so much easier.
SAP sends updates back to us as well and we have functionality to dispatch the Work Order once the parts are shipped.
I think that covers it, let me know if you have other questions.
ServiceMax and Jitterbit collaborated last year to develop a predefined set of integration processes between SAP ECC6 and ServiceMax. The templates cover over 15-use cases including initial migration and ongoing synchronization of objects. These workflows and design patterns could be applied to other ERP's. For more information go to the SAP Connect listing in the Marketplace: Servicemax Connect for SAP by Jitterbit by Jitterbit | ServiceMax Marketplace or contact me and I would be happy to share additional information on SAP and other ERP's we have worked with Servicemax customers.
While integration with Servicemax is very robust, the challenges are typical with the other systems particularly with ERP's that have high degrees of customizations and no standard connectivity options.
Come see us next week in Vegas at Maximize.
We are a ServiceMax implementation partner and one of our main area of expertise is ERP integration
We have integrated with SAP, Oracle, JDE, Sage etc.
Are you attending Maximize next week? If so I will be happy to meet with you and assist with some integration best practices