This blog is continuation of my earlier blog about a 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 the last blog we discussed the following process and were ready to create a delivery.
Design Considerations: Delivery Creation (sub-process 4)
This proved to be rather a tough step to design, In any case, here it goes.
If the delivery is created directly from the sales order, and the device and enrollment service are in same delivery group then this process is quite standard. A new FM during PGI will take the information and write a record to trigger table for enrollment.
If the delivery is created after the lab (production order) processing, then you will have to be creative on how to restrict the enrollment but still show service in delivery and then on billing document. Biggest hurdle is matching how you have set up your material and how that affects the delivery group. In our case, we had both scenarios where we had delivery group populated in one scenario (configurable material) and not populated in one scenario (free goods). So we ended up handling the situation first with configuration and then with following custom code
Here's the coding part, considering you already have the device in your delivery...
As a next step, find out line/s with following 3 characteristics
Design Considerations: Returns
Returns were second on the tough list. Quite a bit of custom things to do. But most important thing to remember is that enrollment service may end up being an individual line item on a separate sales order i.e. customer will call for enrollment after the sale order has shipped.That means device and service will be on separate sales orders, and if that device is returned later, you will have to get both of the items on same return order. It's nothing but pure unadulterated fun 🙂
Design Considerations: Custom tables for tracking enrollment
Ok, last topic for this blog. We ended up creating a few custom tables for the enrollment process because any of the interface points may fail during a transaction, and we did not want to loose the oversight of enrollment process.
So the enrollment design was to get all enrollment requests spooled in a table, and then schedule a program that runs repeatedly through out the day and puts response back in a tracking table. We had one separate table for tracking errors and also build a custom screen for operations team to track enrollments and take corrective actions, if required.
In the last blog we discussed the following process and were ready to create a delivery.
Design Considerations: Delivery Creation (sub-process 4)
This proved to be rather a tough step to design, In any case, here it goes.
If the delivery is created directly from the sales order, and the device and enrollment service are in same delivery group then this process is quite standard. A new FM during PGI will take the information and write a record to trigger table for enrollment.
If the delivery is created after the lab (production order) processing, then you will have to be creative on how to restrict the enrollment but still show service in delivery and then on billing document. Biggest hurdle is matching how you have set up your material and how that affects the delivery group. In our case, we had both scenarios where we had delivery group populated in one scenario (configurable material) and not populated in one scenario (free goods). So we ended up handling the situation first with configuration and then with following custom code
Here's the coding part, considering you already have the device in your delivery...
- If item's VBAP-GRKOR NE blank (part of the same delivery group)
- Check if any other item in the sales order has VBAP-UEPOS EQ current item, (is a sub-line item associated with higher line item we are looking at)
- Check if sub-item material is in low of TVARV-variable (is a valid device enrollment service)
- If yes, pull the sub-item into the delivery with the same quantity as the higher level item.
As a next step, find out line/s with following 3 characteristics
- VBAP-GRKOR EQ blank, (is not part of any delivery group)
- VBAP-UEPOS EQ current item, (is a sub-line item associated with higher line item we are looking at)
- VBAP-UEPVW EQ B, (line created due to free goods determination)
- Check if sub-item material is in low of TVARV-variable (is a valid device enrollment service)
- If yes, pull the sub-item into the delivery with the same quantity as the higher level item.
Design Considerations: Returns
Returns were second on the tough list. Quite a bit of custom things to do. But most important thing to remember is that enrollment service may end up being an individual line item on a separate sales order i.e. customer will call for enrollment after the sale order has shipped.That means device and service will be on separate sales orders, and if that device is returned later, you will have to get both of the items on same return order. It's nothing but pure unadulterated fun 🙂
Design Considerations: Custom tables for tracking enrollment
Ok, last topic for this blog. We ended up creating a few custom tables for the enrollment process because any of the interface points may fail during a transaction, and we did not want to loose the oversight of enrollment process.
So the enrollment design was to get all enrollment requests spooled in a table, and then schedule a program that runs repeatedly through out the day and puts response back in a tracking table. We had one separate table for tracking errors and also build a custom screen for operations team to track enrollments and take corrective actions, if required.
- SAP Managed Tags:
