Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
This blog series is about the device enrollment process that I architected at a recent project. Business requirement was to have a device enrolled as part of a customer group before it ships out to customer. You can think of it like Best Buy enrolling your daughter's new I-phone as part of your family group before it ships out, though I wonder if my daughter will be happy about that 🙂

In addition, this process can also be used to enroll devices automatically for warranties or any special promotions. Basic pieces of information that are required to enroll are...

  1. Device ID or serial number

  2. Customer's account/ID number at the device manufacturer

  3. Sales order or any other document number, which shows that the device was sold.

The manufacturer that we dealt with had provided an API, so we had to build not only an interface but also transaction and error tracking tables to track enrollments. We ended up activating device enrollment in two possible places,

  • First, during delivery (PGI), if no additional services are to be performed,

  • Second, if there are additional services to be performed, then during 261 when device is assigned to the production order.

In short, here's the process

Design ConsiderationsSetting up Material

Adding the service automatically during the order entry was a huge requirement, so your options are

  • Regular material/service using material determination, has to be delivery relevant. Worthwhile if there is plan to charge for this service, disadvantage is Material determination may not work in all scenarios (multiple order types for example),

  • Exclusive Free goods, Great choice if there is no plan to charge for this service in future. Disadvantage is free goods do not support delivery group, so you will have to do some changes to make sure it goes on with the device.

  • Configurable material, user will have to configure, so there is a learning curve for the business folks. No automatic addition of service.

Design Considerations: Setting up Customer

You will need to  save customer's ID/account number at manufacturer. Create a new field and make sure its gets passed on to sales order.

Design Considerations: Creating sales order (sub-process 1)

As such there is nothing much you need to do in sales order except making sure that you save the customer's ID/account number at manufacturer in VBAP. In addition, we ended up adding an extra field to VBAP to store the higher level item number of the device for which enrollment service is being done.

Design Considerations: Material movement document (sub-process 2)

If there are more services to be performed on the device, like installing extra software, putting it in a sleeve etc, the order was routed through a lab using  production order. So when the device is assigned to production order in lab and material document with movement 261 is created, we added a function module towards the tail end of 261 program, which writes a record to what we called "Trigger table". This record contained device id, customer account at manufacturer, sales order and material movement document or delivery number. This trigger table was initiation point for device enrollment. (more on that in my next blog in this series.)

This sub-process ran through the same logic for movement 262 to dis-enroll the device.

Design Considerations: Production order processing (sub-process 3)

During production order operations, we designed a new screen that will let the technician process and record the operation/s done on the device and resolve issues with the device. There were two possible issues that a device could have at this stage.

  • Device is not powering on (Dead-on-arrival). In this case simply return the device to warehouse and create a 262.

  • If device did not enroll at all, send enrollment again via a custom screen. If the device still does not enroll, return the device to warehouse and create a 262.

  • Validation in 262 will check if device was enrolled or not. If it was never enrolled then change the status of enrollment request instead of sending a dis-enrollment request.

At this stage we are ready to create a delivery. In my next blog I will discuss creating delivery, returns and transaction processing for device enrollments.