Case Study: Custom SAP Make-to-Order Packing Solution

This case study is based on one of my projects for a medium size multi-national chemical product company.  The significance of this case study is that it demonstrates how SAP ERP (ECC 6.0) can be properly customized to fit client’s business requirements by leveraging existing SAP functions enhanced with custom code.  This is also an interesting and detailed overview of a make-to-order packing solution designed for a chemical industry business process.

Background

This chemical industry customer implemented SAP for one of their plants/business lines. Although pure MTO processes are not typical in the process/chemical industry (and not part of SAP’s best practices process industries template), this customer believed that their make-to-order (MTO) focus provided them a unique competitive advantage. Their MTO process was reflected in how they took orders, scheduled manufacturing, and mainly, how they packed products to order. They called this a “custom-fill” process where they package a product in custom fill quantities offering a large number of different container types and sizes. For example, 55 gallon drum could contain 300 pounds of one of their product; they would package different quantities in the same 55 gallon drum per order from their customers – e.g., 200 lbs. one time, 150 lbs. another time, and 300 lbs. yet another time.

Production Planning Solution

SAP supports various variations of the MTO process. By selecting Strategy group 50 in the material master record (MRP view) for the finished material, SAP triggers a MTO process of the finished product and a make-to-stock (MTS) production of the intermediate material. This fit well with my client’s requirements. They would plan the production of the bulk material to stock and then only execute the final packaging operation to order.
As an example, please refer to the following graphic that depicts the bill-of-material (BOM) structure with related material master parameter settings.

As indicated, material 99043347 was assigned Strategy group ‘50’ and Consumption mode ‘2’ (controls how independent requirements are consumed by sales orders) in the material master. Its BOM could contain the bulk material and the necessary packaging material. However, in this case (for reasons to be explained below), its BOM contained only the Bulk material 99043346. Therefore, physically there was no difference between the two materials. The only difference was that the finished material was assigned to the packing operation in routing and was produced to order (i.e., its production was triggered only when a sales order for this material was created). Bulk material was produced to stock.

The production of Bulk material was triggered by Independent Requirements maintained for the finished materials. Finished products were planned by either using a forecast, based on knowledge of the sales people, or a combination of forecast tool output and knowledge. This plan was then copied into SAP Independent requirements in monthly buckets. MRP would then develop production orders for bulk materials based on these independent requirements for the finished materials. Once sales orders were entered for the finished material, they would consume independent requirements (i.e., be confirmed against independent requirements). Process orders were created for each sales order of the finished material (sales order and item numbers were referenced on the process order header data).

Packing Solution in SD

MTO planning requirements were addressed with standard SAP MTO functionality. Satisfying the Custom-fill packing requirement was not that straight forward. SAP has packing functionality. The system allows for packing of materials in a sales orders, production/process order and delivery documents. This packing can either be manual by manually selecting a packing material (material type VERP) and assigning a required packing quantity, or this process can be automated via a packing proposal.

First, SAP requires creating packing instructions -- master data records that capture the relationship between packing material and finished material (or any material type that can be sold). An example of a packing instruction is shown in the following screen shot.


In this example a finished material (990433067) was assigned to 5 gallon plastic pail packing material (91008375) in this packing instruction. As you can see, target quantity of 4 pounds was specified. It was also possible to specify other optional parameters. Packing instruction can contain multiple packing materials (item category P) and packed materials (item category M). However, I typically advise to create a packing instruction for each packing material to capture all relationships with finished materials (i.e., in this case 91008375 will contain a list of all finished materials that could be packed in this pail).

Packing instruction can be automatically proposed in a sales order, delivery or production/process order by a packing proposal. Packing proposal is determined by implementing a typical SAP access sequence. In this case, my client needed to select packing instructions based on type of transportation and generic package type specified in the sales order. In SAP several parameters could represent either variable. For various reasons, it was chosen to select Shipping type and Special processing indicator (both fields are available on sales order item detail shipping screen) – both parameters could be customized in IMG.

In order to be available to the access sequence table, both fields needed to be part of allowable data dictionary fields for the packing condition tables. Special processing indicator field was not on a list of allowable fields. For this reason, the allowable field table needed to be extended with a custom Include to add the additional field. This modification is allowed by SAP.

Two access sequences were configured in support of automated selection of packing instructions as follows:

 

1. Material/Ship type/Spec ind/Ship to

2. Material/Ship type/Special ind

 

To support this functionality master data tables must be maintained. The master data table for the second access sequence is shown in the following screen shot.

Material 99043367 in the table is the finished material (i.e., the material sold in the sales order document). Special processing indicator represents a generic container size – in this case, a 55 gallon drum, and Ship type represents the type of shipping mode – in this case “CC” that stands for Common Carrier (other ship types were Air freight, UPS ground, UPS air, and Sea). Once SAP matched all these parameters in the sales order, it would select Packing instruction 1321 that pointed to packing material 91008375 and target quantity of 4 pounds.

The first access sequence is similar to the second with only the addition of Ship to party (i.e., Ship to customer number). The purpose of the first access sequence is to support customer preference. The first access sequence will be selected first by the system. If no data was matched, then SAP would attempt to match data in the second access sequence. Therefore, if a customer suddenly has a new packing material preference, my client only had to add the first access sequence and it would override in effect the previously setup default for just this customer.

The result of this packing proposal is seen in the following SAP’s packing screen shot (the same screen is available in the sales order and delivery transactions – product/process order use a different packing screen).  

 

The first challenge was that when a packing proposal was use, SAP would not allow changing target quantity. Business requirement was to allow customer service to change the target quantity based on their customer preference. For this purpose we developed an enhancement function to replace the target quantity read from the packing instruction record when a customer service user entered a different partial quantity that was less than the target quantity in the packing instruction, larger than the minimum quantity in the packing instruction, and less than the total order quantity.

SAP then calculated the number of packages required as well as quantity per package as shown in the screen shot below.

Another important requirement was to provide ability to price certain packing materials for certain customers.  For this purpose, I added packing surcharge condition. One of the fields in the access sequence for this surcharge condition was packing material (material type VERP). However, standard SAP does not consider packing material during execution of pricing procedure in the sale order. To address this challenge, I activated a standard enhancement point that prepares pricing determination related data (KOMP data). I also created a pricing calculation function to convert the packing surcharge data from price per each package to price per order quantity (in this case always price per pound).

Packing Solution in PP-PI

SAP’s functionality allowed for this packing proposal to be copied into the delivery document (or to be executed in delivery as a new proposal). The business process assumption that SAP made was that packing is done by the shipping department prior to delivery. My customer, however, packed its products in their productions as one of productions operations.

SAP supported the execution of packing proposals as part of the process order. However, it did not support the copy of packing proposal from a sales order into production/process order (even for MTO linked process orders). Also, packing proposal was kept as a separate record and did not impact the process order BOM list and was not considered for material costing. Therefore, a different solution needed to be developed to address this business requirement.

Instead of executing the standard SAP packing functionality in PP, it was chosen to copy packing materials into process order as components by developing another enhancement. This enhancement function was placed after SAP source code that copied BOM into the process order. The enhancement function read the handling unit tables (where packing information was kept in SAP). Please note that each packing material was also setup as a kit and had other components attached to it (such as lid, main container, labels, etc.). The results of this enhancement in a process order are shown below.

Summary and Conclusion

This article presented a creative solution in response to a chemical industry company’s make-to-order packing business process requirement (referred to as “custom-fill”). It showed how standard SAP ERP functions were leveraged and then enhanced with allowable SAP enhancement technologies to develop the required functionality.

It is important to emphasize that although these enhancements did not impact core SAP source code, the added functions would not be automatically added during upgrades. Also, SAP would not support the new functionality. For these reasons, the benefits of every such enhancement must be thoroughly analyzed prior to implementation. In this case, I helped my client to weigh the cost of developing the enhancement, total-cost-of-ownership (TCO), and potential risk against the impact of using standard SAP functionality and adapting the business process to SAP. Since this process was considered an important competitive advantage by my client, management decided to go ahead with its implementation.

Thank you for reading this article.  I also suggest to read the related article about guidelines for properly customizing SAP:
http://simonsayssap.blogspot.com/2014/02/guidelines-for-properly-customizing-sap_12.html

Guidelines for Properly Customizing SAP ERP

In my previous blog article titled “The Dilemma to Modify or Not to Modify SAP”, I discussed the classical question whether it is appropriate to customize the SAP ERP system. By “customizing” I meant not just configuring the SAP ERP thousands of options/tables, but also making code changes via SAP’s built in allowable code modification techniques such as user-exists, enhancements, and BADIs. It is important, however, to follow a good methodology and use experienced consultants when customizing the SAP ERP system. In this article I provide some guidelines for properly customizing the SAP ERP system.

 

My conclusion in the previous article was that it is not always possible to change company’s business process to fit SAP, and indeed, it is not always appropriate. However, customization should be designed and done by the best SAP consultants who have both functional and technical knowledge of the system after a careful analysis of alternatives. It is interesting to note that in the survey I have done on LinkedIn SAP Network Global group, 76% of participants agreed that SAP could be modified. As of February 20, 2014, 39 participants answered the survey questions as follows:     

• 43% thought that SAP is designed to be modified
• 33% thought that SAP should be modified by experts only
• 17% thought that the business process should be modified to fit SAP    
• 5% thought that SAP should be only modified by SAP, AG
• 0% thought that SAP should never be modified

Before engaging in any SAP customization, I strongly recommend to thoroughly analyze alternatives that include the available SAP configuration options and possibility of changing the business process to fit the SAP process. This is easier said than done. In my experience, even SAP consultants with over 10 years of experience may not know all the available options to configure SAP (especially cross functional options).  

 

Most customers are reluctant to consider changing the business process that was used for many years. It is often difficult to determine whether this reluctance is a natural resistance to change (in which case, rigorous change management should be applied), or the business process in question gives customer a unique competitive advantage. In the previous blog article I referenced earlier, I gave two examples of case studies – one for when it was decided to modify the existing business process, and another for when SAP was customized successfully to preserve an existing process that provided that customer a unique competitive advantage.  

 

Once the decision is made to modify/customize SAP, I recommend following these guidelines:

• If extensive new functionality is required, check if another commercial application that already interfaces with SAP is available.   
• Consider developing the required functionality outside of SAP and integrating with source code using SAP’s integration technologies such as RFCs, BAPI calls, and/or use of IDOCs. Such an add-on custom developed application will be independent of SAP’s source code and should provide an effective path to patching and upgrading SAP. Another option is to develop a custom SAP application that calls on various SAP functions. This is more closely integrated with SAP, but may still minimize the impact on SAP’s source code.
• When customizing SAP, check whether customization options available as part of IMG for your specific purpose. For example, pricing functions allow creating complex pricing logic to be used as part of pricing procedures (both in SD and MM) and can be attached to pricing steps in pricing procedure.
• I recommend using BADIs, whenever possible. BADIs are mode modular and better “insulated” from SAP’s source code, and therefore, are less likely to impact the SAP source code and be impacted by future upgrades. However, BADIs may be more complex to implement and require developers familiar with SAP’s object oriented syntax. Also, the same feature that makes BADIs more modular makes them less flexible in terms of availability of in-program variables that may need to be read and changed during customization.
• The next preferred method is the use of Enhancements or user-exists (this is probably the most popular method). 
• SAP allows creating custom Enhancements in various places inside the source code as well as delivers standard Enhancements. Enhancements are function calls that are isolated from the source code and can be managed in a special Enhancement Project. In the previous versions of ERP, Enhancements were referred to as CMOD (for customer modification function) and SMOD (for SAP modification function). An enhancement can be activated and deactivated.
• User-exits are places in source code that are provided by SAP as forms (hence also referred to as form exists) – they are basically empty subroutines. Many user-exits are documented in the SAP IMG, or could be found by searching the source code with the word “USEREXIT”. An example of a user-exit is USEREXIT_PRICING_PREPARE_TKOMK – this exit allows to change the content of the TKOMP table before pricing procedure is executed.

In conclusion, SAP modification/customization should follow a very rigorous approach outlined in this article and led by the most experienced solution architects and consultants that have excellent cross functional knowledge and good understanding of the SAP development environment. Please do not hesitate contacting me for any questions on this subject.