Hi, Guest Log On Join Us true Search for: HomeActivity Communications Actions BrowseMore o Content o People o Places o Recent Bookmarks More discussions in SAP Advanced Planning & Optimization (SAP APO)Where is this place located? 7 Replies Latest reply: Sep 26, 2010 9:41 AM by Loknath Rao Tweet Product allocation functionality in APO SCM 09 Apr 17, 2010 8:35 PM Hi, 1) If we want to use prod alloc functionality in APO, do we need to have both DP and GATP for sure? If yes, can we turn on GATP just to use product allocation functinality? If yes, will the config be easy or complex? 2) how can we use product allocation functinality only in DP? does product allocation functinality makes any sense only in DP without GATP? if yes how? Thanks.. 3211 Views Re: Product allocation functionality in APO Dogboy 49 Apr 17, 2010 9:51 PM (in response to SCM 09) 0925, If we want to use prod allocation functionality in APO, do we need to have both DP and GATP for sure? Depends on what you mean by "DP". For basic Allocation, you will have to set up a specialized Allocation planning area, and it will have has it's own specialized planning book. You don't need the full suite of DP functionalities to make GATP allocation work. Realistically, though, yes, you will have to set up the allocation solution by creating Demand Planning structures. These will almost always be used ONLY for Allocation, and for no other purposes. can we turn on GATP just to use product allocation functionality? If yes, will the config be easy or complex? Allocation limits the amount of product that you allow to be sold, based on configured settings and required groupings. Allocation by Itself does not check for availability of product. Normally, allocation is used in combination with a product check (which is similar to a standard R/3 availability check). Complexity is moderate. Review the best practices doc to get an idea of the complexity. You DO NOT have to set up RBA to use allocation. GATP http://help.sap.com/bp_scmv250/BBLibrary/Documentation/ATP_BB_ConfigGuide_EN_DE.doc Allocation http://help.sap.com/bp_scmv250/BBLibrary/Documentation/S59_BB_ConfigGuide_EN_DE.doc how can we use product allocation functionality only in DP? does product allocation functionality makes any sense only in DP without GATP? Not really. I think we have a problem with terms. GATP means all of SCM's suite of availability checking solutions. DP by itself has NO availability checking, and is not part of SCM GATP. If you ONLY set up an allocation planning book, and nothing else, you will not get any availability checking and you will not get the Product allocation functionality. Rgds, DB49 o Alert Moderator o Like (0) o Re: Product allocation functionality in APO SCM 09 Apr 17, 2010 11:22 PM (in response to Dogboy 49) we do not use GATP module. But we want to use product allocation functionality. so I have 2 ways 1) use Pro allocation functinality in r/3 - sd module 2) use pro alloc functiinality in APO using GATP module.. am i right in sayng that? Alert Moderator Like (0) Re: Product allocation functionality in APO Dogboy 49 Apr 18, 2010 3:30 PM (in response to SCM 09) 0925. Yes. It appears you have never done this before. Most people engage an experienced consultant to install allocation their first time. If you are feeling brave, setup for SCM Product allocation shown in links in my previous post. Setup for R/3 Product allocation Best Practices below, in section 3.7. http://help.sap.com/bp_bl604/BBLibrary/Documentation/105_BB_ConfigGuide_EN_US.doc Rgds & good Luck, DB49 Alert Moderator Like (0) Re: Product allocation functionality in APO AD kumar Apr 18, 2010 9:40 PM (in response to Dogboy 49) Hello Dogboy49, I apologize for writing in the wrong thread but you seem to be very knowledgeable in GATP , please reply to my thread of rounding in GATP. I donot agree with statement that rounding works only in CRM scenario. The help for procedure assignment says " The following conditions must be met for the system to round: o You have set the indicator Rounding Procedure Active. o You have set the indicator that permits an availability check with rounding in the OLTP system." which is done by me. even if this is a true then I should not get any error in T code /SAPAPO/AC12 - Global ATP -> Reporting -> Simulation Rounding which has nothing to do with business event. I am getting error An exception has occurred in this case also. Even for CRM scenario I tried using business event AC (CRM order) in t code /SAPAPO/AC04 , same error comes An exception has occurred . Debugging for this error tells some error in class /SAPAPO/CX_ATP_RND. Thanks, AD Alert Moderator Like (0) Hi, Guest Log On Join Us Getting Started Newsletters Store true Search for: Search the Comm Search the Community Search All of SAP Products Services & Support About SCN Downloads Industries Training & Education Partnership Developer Center Lines of Business University Alliances Events & Webinars Innovation HomeActivity Communications Actions BrowseMore o Content o People o Places o Recent Bookmarks More discussions in SAP APO - Production Planning, Interfaces and Global ATPWhere is this place located? 4 Replies Latest reply: Nov 8, 2009 9:41 PM by Pavan Verma Multi Level ATP / CTP in APO This question is Assumed Answered. Pavan K. Vankadaru Jul 1, 2009 7:36 PM Dear colleagues, our client is a discrete manufacturer of industrial equipment with a complex product mix which fall in to MTO / ETO philosophies. The client is currently on R3 and have a real need for doing multi level ATP. We have explored the option to do assembly orders in R3 to do a component availability check. But assembly orders perform only one level explosion. Therefore, we are now thinking about other alternatives to do a multi level ATP check. While the client is not very excited about APO, they might consider if APO offers real robust solution. As with so many clients, APO is not an easy affair to adopt. So at this time, I request some implementation lessons if you have gone through multilevel ATP or CTP. if anyone has workarounds to do multilevel ATP in R3, your suggestions are welcome too. 1543 Views Average User Rating (0 ratings) Re: Multi Level ATP / CTP in APO vaibhav sareen Jul 3, 2009 11:07 AM (in response to Pavan K. Vankadaru) hi! pavan Multi level ATP and CTP are quite diffrent. let me explain u based on my experience CTP:- Capablle to promise , it is a combination of GATP and PPDS and is meant for company who is a combination of MTO+ some left over stock (due to excess manufacturing) scenerio . The person logs the order in R/3 and during the creation of order gatp gives you the option of all the product/substituted products in locations/substituted locations and if there is a shortage you can trigger production also. this will tell you at what time goods will be available for dispatch( Adding loading,manufacturing,storage/handling time osfits component also).This creates aplanned order using PPDS. Multilevel ATP this is usually used when you want to do the availaibility check for the component of the product, classic example is an assembled computer , when the order for the computer comes you donot search the header material instead you search the component, you need to define a PPM/PDS for the product in APO. This will explode multi level BOM. Note M ATP does not support product/location substitution now it is you decide which fits ur bill for further question feel free to ask regards vaibhav sareen o Alert Moderator o Like (0) o Re: Multi Level ATP / CTP in APO Pavan Verma Nov 8, 2009 9:41 PM (in response to vaibhav sareen) Hi Vaibhav, MLATP does support Product or location substitution. We have used this in one of our project. Regards, Pavan Verma Alert Moderator Like (0) Re: Multi Level ATP / CTP in APO Guest Sep 15, 2009 9:41 PM (in response to Pavan K. Vankadaru) Sareen, In my way of thinking, CPT doesnu2019t check alternative products and locations, as you said above. These functionalities are check on RBATP. What you think? Best Regards. BDV o Like (0) o Re: Multi Level ATP / CTP in APO Dogboy 49 Sep 16, 2009 5:31 AM (in response to Guest ) BDV, You are right, CTP invokes production, and then yields a confirmation date based on the PP/DS planned order schedules that are created - all in real time. You can use RBA and CTP together. I have seen an implementation where various locations were first checked for stock, and the balance of unconfirmed requirement went to CTP. Let me warn you in advance though that the more complex your ATP logic is, the harder it is to implement, maintain and control. This is not just true of SCM, but for any availability checking system you care to us ATP Scheduling based on Custom fields This question is Not Answered. Karthik T Jul 11, 2014 5:21 PM Hi experts, Requirement is that scheduling needs to be happen in APO side based on custom fields at the sales order header level. To achieve this, here are the steps i have followed: 1. Enhance the KOMGO and KOMGU structures in the APO side. 2. Written code in user exit: FV45VFZY_USEREXIT_CATALOG_VALU in ECC side to populate the field catalog with custom field name and related value. Functional team has already configured the condition record based on the custom fields at the APO side. Whenever i'm performing the ATP check in ECC side, scheduling screen shows that condition record has been found and determined, but couldn't see the dates reflecting in the ECC side. One weird part is forward scheduling happens sometime even though my requested delivery date is well in the future. I believe this requirement is common in most of the APO GATP area. Can you please let me know is the issue in the code or configuration and related steps to correct it. Thanks, K 120 Views Tags: apo, scheduling_apo, atp_check_scheduling Average User Rating (0 ratings) Re: ATP Scheduling based on Custom fields Dogboy 49 Jul 12, 2014 11:46 PM (in response to Karthik T) Karthik, Pretty vague question. There is more than one place where scheduling can take place within GATP, that can be affected by conditions and by enhancement of the field catalogue. Are you talking about transportation/shipment scheduling of the item schedule during GATP? Or....? Best Regards, DB49 o Alert Moderator o Like (0) Re: ATP Scheduling based on Custom fields SAP Consultant Jul 25, 2014 10:03 PM (in response to Karthik T) Hi , Look at exits APOSC002.and APOSC001 for doing scheduling using custom field. from Requested delivery date the material avl. date will be calculated and on required MAD materials are not avl. , then forward scheduling might happen , if supplies are in future. Regards, Jit GATP Prod Alloc Procedure Issue This question is Not Answered. Sanjeevi Sampath Jul 23, 2014 11:01 AM Hi SAP Gurus, I am facing issue related to GATP setting. I created a new Prod Alloc procedure, PAG, and setting on connection to planning area in Dev system and moved to Quality. Once the changes moved, In connection to planning area, I could not see ATP version instead GUID is displayed. Can you please help me on this issue? is there any setting missed out? Thanks Sam 73 Views Average User Rating (0 ratings) Re: GATP Prod Alloc Procedure Issue Nihar Padal Jul 23, 2014 1:14 PM (in response to Sanjeevi Sampath) Hi Sampath, Please check whether Model Planning Version is set up or not in QA Tcode: /sapapo/mvm Thanks, Nihar o Alert Moderator o Like (0) o Re: GATP Prod Alloc Procedure Issue Sanjeevi Sampath Jul 23, 2014 4:49 PM (in response to Nihar Padal) Hi Nihar, Thanks for your reply.. Version is already set up in QA. There are many Product allocation procedure already existing and connected to ATP version. Thanks Sanjeevi Alert Moderator Like (0) Re: GATP Prod Alloc Procedure Issue Rorie P Jul 24, 2014 4:42 AM (in response to Sanjeevi Sampath) Hi, have you moved the planning area? Regards ************************** GATP BOP Issue with STOs This question is Not Answered. Terry O'Brien Jun 25, 2014 8:59 PM We have recently discovered a problem with GATP where BOP is not updating the committed dates in APO on STOs from our factory after the corresponding production order has been entered. However if we manually re-run ATP on the same PO it will pick up the proper dates. Running BOP Manually will show the results correctly however when we close of the results that we see in /SAPAPO/BOP and the system says updating the changes do not reflect on the ECC side. In the Inbound Queue of ECC we see many PO's stuck with a SYSFAIL and the error "BOP: Different number of lines" during the function module CIF_PO_INBOUND_30A. We have deleted the queue and it fills up again when BOP is run specifically for the plants that we need to reschedule the PO's from. I found notes 1547002 and 1696509 and we applied them to the system with no success. The error number in those two notes was XC260 which makes me suspect this is something different since the error we are getting is Message no. SR053 with the same message text as XC260. If anyone has come across this error or has any insight it would be greatly appreciated. Capture2.JPG63.6 K Capture1.JPG201.5 K 216 Views Average User Rating (0 ratings) Re: GATP BOP Issue with STOs Rorie P Jun 26, 2014 5:33 AM (in response to Terry O'Brien) Hi Terry, there could be issue with one or 2 STOs, you may need to do some analysis. Just try deleting the first Failed Queue in SMQ2 of ECC and see if the others are still visible. If not, then just try to exclude that from the BOP run and analyse that particular STO. Regards o Alert Moderator o Like (0) o Re: GATP BOP Issue with STOs Terry O'Brien Jun 26, 2014 4:34 PM (in response to Rorie P) Unfortunately is appears that the issue is with all of the STOs from our factories. I have deleted all of the errors and re-ran BOP and they all show up again. Alert Moderator Like (0) Re: GATP BOP Issue with STOs Bala B Jun 26, 2014 8:54 AM (in response to Terry O'Brien) Hi Terry, If you had error activated log please check what sysfail is speaking about the error. Also check below note which can be useful for your error. 1547002 Integration after BOP - error 'Different number of lines'. Thanks, Bala. o Alert Moderator o Like (0) o Re: GATP BOP Issue with STOs Terry O'Brien Jun 26, 2014 4:36 PM (in response to Bala B) I did find that note in my searching and the error number is actually different from the one I am receiving. I found notes 1547002 and 1696509 and we applied them to the system with no success. The error number in those two notes was XC260 which makes me suspect this is something different since the error we are getting is Message no. SR053 with the same message text as XC260. Both of them have been applied and the issue persists. Alert Moderator Like (0) Re: GATP BOP Issue with STOs Bala B Jun 27, 2014 5:47 AM (in response to Terry O'Brien) Hi Terry, I remember in my project also these errors BOP: Different number of lines came. These errors comes due to CCR issue. Please re run CCR and check. Also while BOP is running do not process CCR. Thanks, Bala. Alert Moderator Like (0) Re: GATP BOP Issue with STOs Andy P Jun 28, 2014 12:49 AM (in response to Terry O'Brien) Hi Terry Please run the /SAPAPO/CQ in APO and check for the inbound EDI. That error message will help you to get more detailed message then SMQ1/2. Also you can run delta report for the same. This may happen if line item is deleted in ECC. Cheers!! o Alert Moderator o Like (0) Re: GATP BOP Issue with STOs Terry O'Brien Jul 7, 2014 5:20 PM (in response to Terry O'Brien) Some further diagnosis was needed so I used /SAPAPO/ATPLOG to setup ATP logging for my user , then ran BOP and used /SAPAPO/ATPLOG_DSP to view the results. I noticed there were 107messages under TRC with the error Scheduling of STO order / not allowed, reason LOGSYS Message no. /SAPAPO/ATP_PINCH014. I do not know how to debug the issue and get more details than LOGSYS. I read a similar issue where this was used and I am just not sure how to get more detail , any help would be appreciated. o Alert Moderator o Like (0) o Re: GATP BOP Issue with STOs Bala B Jul 7, 2014 8:36 PM (in response to Terry O'Brien) Hi Terry, Did you ran CCR for those orders. If yes, the inconsistent/ faulty orders will be displayed in report. Thanks, Bala. Alert Moderator Like (0) Re: GATP BOP Issue with STOs Terry O'Brien Jul 7, 2014 9:26 PM (in response to Bala B) I have ran CCR and these errors do not show up in Purchase Orders. They show up in Confirmations and can not be cleared. Some have the error Schedule line does not exist in R/3 Message no. /SAPAPO/CIF183 Others have Schedule line does not exist in APO Message no. /SAPAPO/CIF181 --------------------------------------------- The issue is when I clear the ones not in APO they show up in the missing in R/3 bucket and vise versa. Alert Moderator Like (0) Re: GATP BOP Issue with STOs Rorie P Jul 8, 2014 4:51 AM (in response to Terry O'Brien) Hi Terry, Wanted to know if you have selected "STOs" in your BOP filter? Alert Moderator Like (0) Re: GATP BOP Issue with STOs Terry O'Brien Jul 8, 2014 4:59 AM (in response to Rorie P) Yes absolutely have STO 's checked. In fact in the BOP results we see STO's that have date movements and splits. However when we look in the ECC side the said changes are not taking place. The checkmark for update is also checked so that is not the issue. The issue is for some reason the STO's are not able to updated by BOP from SCM to the ECC. Alert Moderator Like (0) Re: GATP BOP Issue with STOs Nihar Padal Jul 21, 2014 1:12 PM (in response to Terry O'Brien) Hi Terry, Is there any Custom enhancement in place for PO's ? And also can you please check this configuration for STO's in ECC side. SPRO -> Material Management -> Purchasing -> Purchase Order -> Set up Stock Transfer Order -> Assign Delivery Type and Checking Rule Check whether ATP Conf. MRP field is checked or not? Thanks, Nihar Partially delivered orders which was not issued consuming allocations from QTTAB This question is Not Answered. mani krishna Jul 21, 2014 12:58 PM Hello Dear Experts, I came across a strange issue in APO GATP where i see the partially delivered items which was not goods issued yet(Open deliveries) consuming allocations from QTTAB in APO upon back order processing ,which is incorrect according to my opinion.I have checked all the config setting in APO GATP and every thing seems to be perfect.We are configured to consume allocations based on sales order MAD date in QTTAB. Can you please throw some light on this issue. Thanks Mani SAP APO - Production Planning, Interfaces and Global ATP Previous postNext post Rules-Based Availability Check Overview and Steps to Configure Posted by SATISH WAGHMARE in SAP APO - Production Planning, Interfaces and Global ATP on Jan 25, 2014 9:43:05 PM inShare4 Rules-Based Availability Check Overview and Steps to Configure I think, RBA is one of the area in which we have highest number of questions posted on SCN. I am posting this blog to consolidate my understanding/knowledge with RBA. Hope this blog will help our community members. Introduction : An ordinary ATP check is restricted to the requested locationproduct and checks only the according timeseries. Using Rules Based Availability Check(RBA or RBATP) it is possible to substitute both the location and the product. In branched supply chain networks, rules-based ATP allows companies to take full advantage of multiple shipping assets to ship goods from alternative sites to customers. In addition, it permits certain products to be substituted as required to successfully satisfy customer demands. This is a functionality available in GATP Rules Based Availability Check is used to automatically or manually optimize the decision making process using predefined rules Rules Based Availability Check allows to react automatically to the incomplete availability of a product based on the following o Determining Alternative Locations: This automatically chooses one or more sources (= plants) from a list of supply sources that can be used to satisfy a product requirement. o Determining alternative products: This automatically allows to react to a shortage without producing or procuring the product. The alternative products can be chosen automatically from a predefined list. Combination of above two methods Rule Based Availability Check can include basic methods as Product Availability Check and Product Allocation check per Product/Plant combination Rule Based Availability Check is activated via Check Instructions, triggered based on condition records maintained in APO and executed according to a predefined rule set. Benefits of Rule Based Availability Check : Deliver product on time, right quantity to customer. Delivery product in most cost-effective way. Minimize order to delivery lead time. Leverage the full distribution network effortlessly. Prerequisites: Following are the prerequisites for Rules Based ATP Check : Product and Location are transferred into APO along with setting up of necessary fields in ATP Tab in Product Master(/SAPAPO/MAT1) Check Control is setup for ATP group and Business Event combination. Set "Activate RBA" in the Check Instruction. Besides there are few additional(optional) settings which offers some additional functionality namely Start Immediately, Use Calculation Profile, Create Subitems and others. Please refer sample screen below. Go to SPRO>Advanced Planning and Optimization > Global Available-to-Promise (Global ATP) > General Settings > Maintain Check Instructions Configuration Details: Using below SPRO Menu in APO, Required configuration settings for Rules Based ATP Check can be done. 1. Field Catalog : With this activity, you can add new fields that you use for creating the condition tables. (/SAPCND/AO01) 2. Condition Table : In this activity, you create the condition tables used in the rule-based ATP check.(/SAPCND/AO03). You add fields from Field Catalog to create Condition Tables. FYI- Technical Name of Condition Table starts with /SAPCND/KOTO* 3. Access Sequence : In this activity, you determine the access sequences. Using the access sequence, you determine: Which condition tables are used to access the condition records. The sequence of these condition tables Which field contents are used as criteria for reading the condition tables. (/SAPCND/AO07). In Access Sequence, set the Exclusive indicator, only if you do not want the system to evaluate additional condition tables after the first successful access (not recommended to set the exclusive indicator). 4. Condition Type : In this step, you maintain the condition type and assign it to an access sequence. Condition types are used for determining rules in the rules-based availability check. (/SAPCND/AO06). 5. Maintain Rule Strategy : In this step, you maintain the rule strategy. The rule strategy determines the condition types and defines the sequence in which they are evaluated. 6. Assign Rule Strategy : In this activity, you determine the following activation parameters to determine the rule strategy: – Technical scenario (This is nothing but communication technique– EDI(DD)/Batch Input(BB)/Online Dialog(AA) etc) – Business transaction (Basically it is business context, You need to define a business transaction using VOV8 in the ECC system and assign it to an order type). – Action type (This corresponds to manipulation technique creating(A), changing(B), and copying(C)) 7. Maintaining the Rules (using Integrated Rule Maintenance /SAPAPO/RBA04): – Creating Product Substitution Rules : In this activity, you create the substitution chains for product substitution. – Defining the Rules Control : Using the rule control you can define the strategy. For example, the rule control determines whether the system checks the same product in different locations, or it checks a substitution product, first. Access Strategy is an important setting which you make in Rule Control. – Defining the Location Determination Procedure : For the location determination procedure, you define a list of locations. During the availability check, SAP APO takes all listed locations into account. If the requirement cannot be fulfilled in the original location, it is substituted by one of the alternative locations. Activity(refer below details) is assigned to Location Determination procedure for additional actions. – Calculation Profile: Allowed delays, Early confirmations, Consumption limit, Maximum number of partial deliveries etc. – Activity for Location Determination: In the Activity, you can maintain actions that are carried out if a determination is executed. (Example – Override the Check mode with 050 to Z50 to allow different check instruction to use in ATP Check) – Maintaining Rules : The rule combines the possibility of location and product substitution with the rule control strategy. Location Determination Procedure, Product Determination Procedure, Calculation profile and Rule Control are assigned to Rule. 8. Creating the Rule Determination(/SAPCND/AO01) : In the rule determination, you enter data for the key combination of a condition table and assign a rule to it. Additional Resources: Rules-Based Availability Check - SAP Library Global Available To Promise (GATP) Overview Rule Based ATP with Exclusive Rule Strategy Please do let me know your comments/feedback/input if any. Thank you Satish Waghmare Partially delivered orders which was not issued consuming allocations from QTTAB Posted by mani krishna Jul 21, 2014 Hello Dear Experts, I came across a strange issue in APO GATP where i see the partially delivered items which was not goods issued yet(Open deliveries) consuming allocations from QTTAB in APO upon back order processing ,which is incorrect according to my opinion.I have checked all the config setting in APO GATP and every thing seems to be perfect.We are configured to consume allocations based on sales order MAD date in QTTAB. Can you please throw some light on this issue. Thanks Mani 3 Views 0 Comments Permalink Differences between ECC and APO Calculation Posted by Joaquin Perez Jun 15, 2014 APO and ECC have different approaches to the calculation of time and capacity in a production order. These may create different results for the same order when complex calculations or variant configuration are used, confusing the users and - in extreme cases - making a good APO plan unfeasible when dropped to ECC. This article explains these differences in detail and explore options to align the APO calculation to the calculation done in ECC. How ECC calculates The core of the ECC calculation for an operation’s time, capacity and cost is the formula assigned to the workcentre. The formula calculates based on parameters that take their values from the order, the operation standard values (usually copied from the routing) and the workcentre itself in the form of workcentre constants. The most generic formula for a workcentre is the linear formula shown below. It has both a proportional term and a fixed term. It uses standard SAP parameters that translated to their description would be: Where the standard value 1 is the proportional time and standard value 2 is the fixed time. For example, let’s assume a process that requires 5 min to set the operation and 3 minutes to process 1,000 units. The time calculated for an operation for 30,000 units would be: 30,000 units / 1,000 units x 3 min + 5 min = 95 min The formula can work for any workcentre with any combination of proportional and fixed time, including workcentres where the time is fixed regardless of the operation quantity (e.g. an oven). The standard approach covers many requirements but cannot handle more complex situations as is the case with nonlinear formulas or when additional parameters are involved. Nonlinear formulas require functions that are not supported by workcentre formulas. Sin(x). Log(x) and X n are some examples. The use of tables to determine a formula parameter is also nonlinear. When used Variant Configuration (VC) the configured values for a specific order or product can be used to alter the calculations as well. Dimensions like length and surface are typical examples, for example the diameter in a pipe cutting operation. ECC can accommodate these complex requirements with two functionalities: CAPP standard value calculation and Variant Configuration object dependencies. CAPP Standard Value Calculation This functionality uses formulas and rules based on characteristics values from different origins to modify the standard values of the operation. The calculation can be complex, using math functions or reference tables to determine the standard value for specific operation parameters. The standard value is then used in a regular work centre formula to determine times, capacity requirements and costs. CAPP is being superseded by Variant Configuration (VC) as it covers the same requirement with additional advantages, like compatibility with APO’s Characteristics Dependent Planning (CDP). Variant Configuration Object Dependencies Variant configuration is a powerful functionality that is normally used to produce orders for customer specific requirements, for example a particular colour or cruise control option in a basic car model, in order to handle the exponential number of combinations without the need of a material record for each. Regular materials can also adopt VC functionality in order to reduce the BOM and routing master data with the use of “Super” BOMs and routings that are shared by many materials but are dynamically modified to adapt to the material or specific order characteristics. A third use for this functionality, and the one related to the subject of this article, is to allow a more accurate calculation using parameters from multiple sources and complex formulas to modify the standard values copied from the routing into the order, as CAPP does. In addition to standard values ODs can also access and modify directly an extended number of fields both in ECC and APO. There are different kinds of Object Dependencies but the ones used to determine the standard values (procedures) are scripts that can have conditionals, arithmetic operations and math functions. They can also determine values using reference tables or call ABAP functions. With all these options, ODs can handle complex calculations of time and capacity with accuracy. Accuracy is important in this case as small differences can accumulate to significant variations for large order quantities. The following diagram shows ECC’s approach to the operation calculations. A Configuration Example Suppose there is an operation to cut a pipe to a specific length from a continuous supply. The time required to process each pipe is a combination of the time to move it into place, that depends on the length, and the time required to cut it that we assume is proportional to the square of the diameter. Processing Time = A x Length + B * Diameter 2 Where A and B are standard values that depend on the machine and material. The diameter and length value are coming from characteristics configured in the material master if there is a limited number of length cuts. Alternatively, the length may be defined during sales order entry and transferred to the customer segment, making possible to produce a pipe of any length without having an extremely large number of material records. We can use the OD to copy the values of length and the diameter squared into two of the remaining standard values (2 of 6 already used by A and B), then use a simple workcentre formula to calculate the operation duration or capacity using these 4 values. How APO Calculates APO calculate times and capacities in a simpler way. The formula is already predefined in the operation and is a linear formula of the kind explained at the beginning of this article. It has a variable term and a fixed term. You can see them for the duration of the operation (expressed in seconds) in the mode tab for the resource: In APO there are no standard values and the duration formula is predefined for the operation as: Duration = Dur.(V) * Operation Qty / Base Qty + Dur.(F) The capacity works in a similar way. APO can work with variant configuration and object dependencies as well. In APO the equivalent to Variant Configuration (VC) is the Characteristic Dependent Planning (CDP) functionality. In APO the object dependency con modify the fixed and variable terms used in the predefined linear formula. It can also modify the duration and capacity result fields directly. This assume the use of Production Data Structures (PDS) that are compatible with object dependencies and supposed to be substituting the previous SAP approach to routings in APO (PPMs). Deriving the Variable (V) and Fixed (F) terms for APO If the operation has a linear formula in ECC the standard functionality has no issue delivering an accurate calculation in APO even if the approach is different in the two systems. To do this the system takes a couple of results from the ECC formula (for example for 0 and 100 units). With those 2 points the line is defined and the variable and fixed terms for the duration in APO can be calculated. So, regardless of the complexity of the formula the calculation is perfectly replicated in APO if the ECC formula is lineal. This approach is not good for non-linear formulas as APO tries to replicate them with a linear approximation. The error incurred by this approximation can be better explained with an example. Let’s assume following non-linear ECC formula, with terms are in seconds for simplicity. Duration = 5 + 10 * Quantity 2 This generates the following variant and fixed terms in APO. Calculating the ECC and APO durations for different quantities shows the variances in the result. The difference is substantial. Graphing the formulas is clear that the two give the same result in the two points used by the system to calculate the APO linear terms (0 and 1,000 units). This example may be exaggerated and unrealistic but it clearly shows the problem of non-linear ECC formulas when approximated by APO linear terms. Solution Options The way the calculations in ECC and APO can be aligned will depend on the specifics of the situation and how close you can keep to the standard. A flexible solution is usually a better approach but a hardcoded approach can also work well if the requirement is stable and well defined. A logical place to adjust the calculation is in the BAdI at the creation of the order in APO, which allows the adjustment of the duration and capacities before the order is saved in LiveCache (/SAPAPO/RRP_SRC_EXIT method RRP_USEX_PLORD_CREATE). It may be tricky when variant configuration and object dependencies are involved in the calculation but the functionality offers additional options to the point that you may want to consider using VC and ODs even if the material doesn’t need to be configured from the sales point of view. In very general terms the idea is to put the complex part of the calculation in the object dependency instead of the work centre formula and use reference characteristics to get the parameters values for the formula. The object dependency is transferred to APO as a procedure in the PDS and the parameters can be passed between systems as part of the configuration. The approach works as long as a few complications are resolved. The characteristics for parameters and results have to reference different fields in ECC than in APO as their internal structures are different: SAP offers a configuration table to map fields in ECC with their equivalent fields in APO. This can also be done manually after the reference characteristics are transferred to or created in APO as long as it is before they are used there. The object dependency is copied “as is” from ECC into a procedure in APO but sometimes it makes sense to have a different version of the formula in each: A trick can be used in this case to include two different formulas in the same object dependency. The result characteristic of the first formula references a field in ECC but no field in APO. The second formula result points to a valid field in APO but no field in ECC. Both formulas are calculated in both systems but ECC gets the result from the first and APO from the second. Standard values are not transferred to APO and they cannot be passed as configuration since the configuration is for the whole order and the standard values can be different for each operation: The blunt and simple way of solving this is to include the standard values as numeric values in the object dependency. This means a different object dependency for each different combination of standard values, making maintenance of the values difficult as mass tools like LSMW or the Engineering Workbench cannot be used to change the values. I designed a solution that uses a BAdI to modify the object dependency when the PDS is being transferred to APO. It substitutes in the object dependency formula the characteristics referencing standard values with their numerical value for that specific operation. This approach uses a single object dependency while allowing mass change of the standard values in ECC. The values in the APO procedure are updated when the PDS is retransferred with CURTO_CREATE. For historical reasons it has always been difficult to align ECC and APO – the CIF wouldn’t exists otherwise - and the way they calculate is no exception. By understanding their approach, and with a little bit of work, it is possible to get them to speak the same numbers even for the most complex cases. Theirs a estrange feeling of satisfaction when they do. (This post was first published on the author's professional blog, see profile) 208 Views 0 Comments Permalink Tags: apo, calculation, formula Extended Selection in Interactive APO Posted by Joaquin Perez Jan 28, 2014 Introduction APO interactive transactions for multiple products don’t usually have all the options for selection that the business may need. This article explains how to use ABAP Query functionality to extend and customize the selection for these transactions. The article shows - as an example - how the receipts view can be selected by the ABC indicator of the products; a field not present in the standard selection screen. The technical details are explained so it should be easy to adjust the query for other fields and more complex selection requirements. ABAP query is a powerful functionality that allows complex reporting. It can include ABAP code without the need for a developer key. In this example we combine the query selection with a transaction screen called directly from within the query. Queries can be exported and shared easily. You can download a file with the definition of the query in this article in the original post in my professional blog (see my profile). You will also find instructions on how to load it into your system. Interactive transactions Receipt view (/SAPAPO/RRP4) Requirement view (/SAPAPO/RRP1) Product planning Table (/SAPAPO/PPT1) Product overview (/SAPAPO/POV1) These are APO transactions that use the same selection screen. As you can see below the selection options are limited, even if we consider the additional tabs. Selection screen of /SAPAPO/RRP4 “Other” tab in /SAPAPO/RRP4 selection screen This is enough in most cases but the user may need a different selection field or approach. Using the product-location free attributes fields in this way can be particularly useful as these fields can be populated with specific parameters from ECC not available in standard APO. In the example presented the selection screen will look as follows and includes the ABC indicator as a selection option. The output result will depend on the interactive transaction extended. In this example it will be the receipts list for those product- locations matching the query selection. Technical details of the interactive transactions The transactions indicated in the previous chapter all have a similar internal structure. The transaction calls a program include that does the following: 1. Calls function /SAPAPO/PT_SELSCREEN: This function encapsulates the selection screen and brings back a selection of pegging areas that will be used in the report. Some additional conditions - like the date range - are also returned. All 4 transactions call the same function passing only a different title in a variable so that it shows at the top of the selection screen. 2. Some manipulation of the selection parameters is performed: For example converting dates into timestamps. 3. A function is called to display the transaction main screen: This can be just the order list or more complex functionality like the production planning table. This function takes as input the list of pegging areas from the function in point 1. The following table shows for the 4 transactions the program include where the functions are called and the function used to run the main transaction. Report Transaction Program Include Function to run/display Receipt view /SAPAPO/RRP4 /SAPAPO/SAPRRP_RECEIPTS_ENTRY /SAPAPO/RRP_SHOW_RECEIPTS Requirement view /SAPAPO/RRP1 /SAPAPO/SAPRRP_REQMTS_ENTRY /SAPAPO/RRP_SHOW_REQMTS Product planning Table /SAPAPO/PPT1 /SAPAPO/SAPRRP_PT_ENTRY /SAPAPO/RRP_PLANNING_TABLE Product overview /SAPAPO/POV1 /SAPAPO/POV_ENTRY /SAPAPO/RRP_POV_SHOW Implementing the query The query selection substitutes the first function call with a customized extraction of the pegging areas that is then feed to the function that runs the transaction. In this way, we can make the selection much more complex, adding any field available in the product-location master data tables and filtering the combinations before calling the transaction. For this article we are going to use a simplified selection of product, location and ABC indicator. First of all we create an infoset by joining the tables indicated below. Then select the fields to be used in the query. The “from” and “to” dates are important parameters to reduce processing time. These transactions are usually slow even for a small set of materials and any additional restriction will help performance. Create them as parameters in the query infoset. Additional selection parameters in query Definitions for date and time fields Query Code ABAP code is required to call the transaction function with the parameters determined by the query. The following is an explanation of the code logic by sections in the query code tab. DATA In this section the data variables and structures are defined. DATA: lt_pegarea TYPE /sapapo/pegid_tab, ls_selection TYPE /sapapo/rrp_pt_selection, ls_pegarea TYPE /sapapo/pegid, lv_time_from TYPE timestamp, lv_time_to TYPE timestamp, lv_simid TYPE /sapapo/vrsioid, lv_confr_sel TYPE REF TO /sapapo/cl_confr_sel. Record Processing This is the code that is executed for each of the records returned by the query select of the data. The query returns a list of pegging areas in table /SAPAPO/PEGKEY for those product-locations included in the selection. Each pegging area ID is copied and appended to the temporary tablelt_pegarea. * * Append the pegging area returned by the query * in /SAPAPO/PEGKEY into temporary table lt_pegarea * ls_pegarea = /SAPAPO/PEGKEY-PEGID. APPEND ls_pegarea TO lt_pegarea. END-OF-SELECTION (Before List) After the query has collected the pegging areas for the product-locations in the selection, the function that runs the transaction is called. In addition to the pegging areas, the FROM and TO date timestamps and the active version (000) are passed to the function. * * Fill selection for all order types * Data: ls_sel TYPE /sapapo/ordtype_rstr. ls_sel-option = 'CP'. ls_sel-low = '*'. ls_sel-sign = 'I'. APPEND ls_sel TO ls_selection-order_type_rtab. * * Convert the FROM date and time in the selection * into a timestamp format * CALL FUNCTION '/SAPAPO/DATE_CONVERT_TIMESTAMP' EXPORTING iv_date = dtsta iv_time = utimest IMPORTING ev_timestamp = lv_time_from. * * Convert the TO date and time in the selection * into a timestamp format * CALL FUNCTION '/SAPAPO/DATE_CONVERT_TIMESTAMP' EXPORTING iv_date = dtend iv_time = utimend IMPORTING ev_timestamp = lv_time_to. * * Active version 000 is set as default * lv_simid = '000'. * * Call the transaction function using the * pegging area table collected by the query * and other parameters * CALL FUNCTION '/SAPAPO/RRP_SHOW_RECEIPTS' EXPORTING iv_simid = lv_simid it_locno_source_rtab = ls_selection-source_locno_rtab it_pegid = lt_pegarea it_resnam_rtab = ls_selection-resnam_rtab it_prio_rtab = ls_selection-prio_rtab it_order_type_rtab = ls_selection-order_type_rtab iv_confr_sel = lv_confr_sel iv_time_from = lv_time_from iv_time_to = lv_time_to iv_internal_call = 'X'. Query definition The query itself (SQ01) is straightforward. The selection screen shows the parameters defined in the infoset. Add the others parameters as selection. This query will not have any list displayed as the transaction will be called first. Include the fields in the display anyway to make sure the code is executed. It is also important that the query is set as ABAP List to make sure the code in the END-OF- SELECTION section is included and used in the query. Stepping beyond This basic query can be extended in different ways, for example: Additional fields from the product-location can be added as well as complex checks to exclude pegging areas not needed. Even if the field is included in the transaction list and can be hidden with a layout; it is much more efficient to exclude it in the selection screen. The planning version is hardcoded here to 000 but it can be part of the selection to allow the use of other planning versions. You can have 4 different queries for the 4 different transactions or a single query with a radio button in the selection screen to choose. Have fun. (This post was first published on the author's professional blog, see profile) 370 Views 1 Comments Permalink Rules-Based Availability Check Overview and Steps to Configure Posted by SATISH WAGHMARE Jan 25, 2014 Rules-Based Availability Check Overview and Steps to Configure I think, RBA is one of the area in which we have highest number of questions posted on SCN. I am posting this blog to consolidate my understanding/knowledge with RBA. Hope this blog will help our community members. Introduction : An ordinary ATP check is restricted to the requested locationproduct and checks only the according timeseries. Using Rules Based Availability Check(RBA or RBATP) it is possible to substitute both the location and the product. In branched supply chain networks, rules-based ATP allows companies to take full advantage of multiple shipping assets to ship goods from alternative sites to customers. In addition, it permits certain products to be substituted as required to successfully satisfy customer demands. This is a functionality available in GATP Rules Based Availability Check is used to automatically or manually optimize the decision making process using predefined rules Rules Based Availability Check allows to react automatically to the incomplete availability of a product based on the following o Determining Alternative Locations: This automatically chooses one or more sources (= plants) from a list of supply sources that can be used to satisfy a product requirement. o Determining alternative products: This automatically allows to react to a shortage without producing or procuring the product. The alternative products can be chosen automatically from a predefined list. Combination of above two methods Rule Based Availability Check can include basic methods as Product Availability Check and Product Allocation check per Product/Plant combination Rule Based Availability Check is activated via Check Instructions, triggered based on condition records maintained in APO and executed according to a predefined rule set. Benefits of Rule Based Availability Check : Deliver product on time, right quantity to customer. Delivery product in most cost-effective way. Minimize order to delivery lead time. Leverage the full distribution network effortlessly. Prerequisites: Following are the prerequisites for Rules Based ATP Check : Product and Location are transferred into APO along with setting up of necessary fields in ATP Tab in Product Master(/SAPAPO/MAT1) Check Control is setup for ATP group and Business Event combination. Set "Activate RBA" in the Check Instruction. Besides there are few additional(optional) settings which offers some additional functionality namely Start Immediately, Use Calculation Profile, Create Subitems and others. Please refer sample screen below. Go to SPRO>Advanced Planning and Optimization > Global Available-to-Promise (Global ATP) > General Settings > Maintain Check Instructions Configuration Details: Using below SPRO Menu in APO, Required configuration settings for Rules Based ATP Check can be done. 1. Field Catalog : With this activity, you can add new fields that you use for creating the condition tables. (/SAPCND/AO01) 2. Condition Table : In this activity, you create the condition tables used in the rule-based ATP check.(/SAPCND/AO03). You add fields from Field Catalog to create Condition Tables. FYI- Technical Name of Condition Table starts with /SAPCND/KOTO* 3. Access Sequence : In this activity, you determine the access sequences. Using the access sequence, you determine: Which condition tables are used to access the condition records. The sequence of these condition tables Which field contents are used as criteria for reading the condition tables. (/SAPCND/AO07). In Access Sequence, set the Exclusive indicator, only if you do not want the system to evaluate additional condition tables after the first successful access (not recommended to set the exclusive indicator). 4. Condition Type : In this step, you maintain the condition type and assign it to an access sequence. Condition types are used for determining rules in the rules-based availability check. (/SAPCND/AO06). 5. Maintain Rule Strategy : In this step, you maintain the rule strategy. The rule strategy determines the condition types and defines the sequence in which they are evaluated. 6. Assign Rule Strategy : In this activity, you determine the following activation parameters to determine the rule strategy: – Technical scenario (This is nothing but communication technique– EDI(DD)/Batch Input(BB)/Online Dialog(AA) etc) – Business transaction (Basically it is business context, You need to define a business transaction using VOV8 in the ECC system and assign it to an order type). – Action type (This corresponds to manipulation technique creating(A), changing(B), and copying(C)) 7. Maintaining the Rules (using Integrated Rule Maintenance /SAPAPO/RBA04): – Creating Product Substitution Rules : In this activity, you create the substitution chains for product substitution. – Defining the Rules Control : Using the rule control you can define the strategy. For example, the rule control determines whether the system checks the same product in different locations, or it checks a substitution product, first. Access Strategy is an important setting which you make in Rule Control. – Defining the Location Determination Procedure : For the location determination procedure, you define a list of locations. During the availability check, SAP APO takes all listed locations into account. If the requirement cannot be fulfilled in the original location, it is substituted by one of the alternative locations. Activity(refer below details) is assigned to Location Determination procedure for additional actions. – Calculation Profile: Allowed delays, Early confirmations, Consumption limit, Maximum number of partial deliveries etc. – Activity for Location Determination: In the Activity, you can maintain actions that are carried out if a determination is executed. (Example – Override the Check mode with 050 to Z50 to allow different check instruction to use in ATP Check) – Maintaining Rules : The rule combines the possibility of location and product substitution with the rule control strategy. Location Determination Procedure, Product Determination Procedure, Calculation profile and Rule Control are assigned to Rule. 8. Creating the Rule Determination(/SAPCND/AO01) : In the rule determination, you enter data for the key combination of a condition table and assign a rule to it. Additional Resources: Rules-Based Availability Check - SAP Library Global Available To Promise (GATP) Overview Rule Based ATP with Exclusive Rule Strategy Please do let me know your comments/feedback/input if any. Thank you Satish Waghmare 1156 Views 0 Comments PermalinkTags: rules, apo, based, atp, gatp, rba, order_confirmation, check_instructions, rbatp Sap List Viewer queries using code in the END-OF- SELECTION section Posted by Joaquin Perez Jan 21, 2014 The Problem Reports and Queries using the “Sap List Viewer” format are a huge improvement from the old “ABAP List” format. Columns can be moved by drag and drop, export options are better, looks are nicer and it has many other advantages. The END-OF-SELECTION section is very handy. It runs after the records have been processed by the query but before the report is displayed. It is the right section to do aggregated calculations and actions that can only be done when data from all the selected records has been extracted. However, there is a problem when queries use code in the END-OF-SELECTION section in combination with the Sap List Viewer format. In short, the code is never reached. Here is a trick to make the combination work. The Trick When defining the query change the output format option to ABAP List. This will trigger the old source code generation that includes the code in the END-OF-SELECTION section. Run the query and in the selection screen change the option to SAP List Viewer. Save a default variant Include any other default values that you may need for the selection fields in the query. Change the query and add the default variant as the standard variant of the query. In this way, the query is generated internally for an “ABAP List” report and it will include the END-OF-SELECTION code. When the query is executed, the default variant will change the option and the query will display with a flexible “SAP List Viewer” format. Enjoy. 397 Views 0 Comments Permalink sample code to display resource of the first operation at the product view Posted by Tiago Furlanetto Jan 19, 2014 Hi all. At the Product View, Elements tab, there is field Resource. This column displays, in general, the resource assigned to the last operation of the order (or the output resource). Overtime, I've seen a couple of customers who wanted to display in this field the resource assigned to the first operation of the order instead. This can be done by creating an implementation of BAdI /SAPAPO/RRP_IO_COL, Method RRP_USEX_COLS_FILL_01. When the BAdI is reached, there is table CT_IO which contains field MAIN_RESOURCE, which is the resource id of the resource displayed in Elements tab. When we want to show a different resource, we have to assign a different main_resource. An example of how this could be done is shown below: method /SAPAPO/IF_EX_RRP_IO_COL~RRP_USEX_COLS_FILL_01. INCLUDE /sapapo/constants_om. DATA: lt_rc TYPE /sapapo/om_lc_rc_tab, lt_order TYPE /sapapo/om_ordid_tab, lt_activities TYPE /sapapo/om_tab_act, ls_gen_params TYPE /sapapo/om_gen_params, lv_simsession TYPE /sapapo/om_simsession, ls_exclude_fields TYPE /sapapo/om_exclude_fields, ls_exclude TYPE /sapapo/om_getdata_options. FIELD-SYMBOLS: <io> LIKE LINE OF ct_io, <act> LIKE LINE OF lt_activities. * get orders LOOP AT ct_io ASSIGNING <io>. APPEND <io>-orderid TO lt_order. ENDLOOP. CLEAR <io>. * get simsession and parameters for LiveCache call CALL FUNCTION '/SAPAPO/RRP_SIMSESSION_GET' IMPORTING ev_simsession = lv_simsession es_gen_params = ls_gen_params. * no need to calculate pegging ls_exclude_fields-slacktime = gc_true. ls_exclude_fields-devquantity = gc_true. CALL FUNCTION '/SAPAPO/OM_ORDER_GET_DATA' EXPORTING is_gen_params = ls_gen_params iv_simsession = lv_simsession it_order = lt_order is_exclude_exports = ls_exclude is_exclude_fields = ls_exclude_fields IMPORTING et_rc = lt_rc et_activities = lt_activities EXCEPTIONS lc_connect_failed = 1 lc_com_error = 2 lc_appl_error = 3 OTHERS = 4. IF sy-subrc <> 0 AND lt_activities IS INITIAL. EXIT. ENDIF. * only activities with assigned resources DELETE lt_activities WHERE resid IS INITIAL. * so resource of GR activities will not be shown first * unless it is the only activity of the order. SORT lt_activities DESCENDING BY opr_level. * first activity of first operation with assigned resource SORT lt_activities BY orderid oprcounter group_oprcounter. LOOP AT lt_activities ASSIGNING <act>. LOOP AT ct_io ASSIGNING <io> WHERE orderid = <act>-orderid. <io>-main_resource = <act>-resid. ENDLOOP. " delete remaining activities of the order to keep " the new main resource. DELETE lt_activities WHERE orderid = <act>-orderid. ENDLOOP. endmethod. 234 Views 0 Comments PermalinkTags: resource, rrp3, product_view, rrp_io_col, rrp_usex_cols_fill_01, main_resource, output_resourc e, input_resource,orderid Pro Customization Manifesto Posted by Joaquin Perez Jan 7, 2014 An organism like your SAP system can evolve and adapt to its particular business jungle. Become faster, more efficient and make users happier. It requires you to be bold, to stay safe but assume the risk. This evolution should be the next step after a successful implementation of a basic standard platform. This is the logical thing to do. Like starting building the house after the foundation is set. Yet, you see everywhere cautions words about customization, portrayed as something to fear, a last resort option. Progress becomes a steady succession of upgrades and support packs that offer not much improvement over what you already have. I’m a pro-customization consultant and this is the manifesto of my beliefs. I believe constant improvement techniques should be applied not only to your processes but to your system, finding new ways to help users do their jobs, supporting those characteristics that make your business particular and competitive. The blog that this post starts will explore customization ideas and projects in production planning in the hope to attract like-minded professionals and maybe converting a few nonbelievers. SAP aims to be a platform for any industry. By adjusting its configuration it can cover many requirements and adjust to most processes. There is however a limit to what standard functionality can accomplish. The indication that SAP knows its own limitations is the wide range of customization options it offers. Its source code is there for all to see and it lets you ABAP your solutions in many ways. The list is long: user exits, BAdIs, coded queries and programs of all kinds as well as standard functionality with code-like flexibility (e.g. object dependencies in variant configuration). We can also consider as customization the use of standard functionality in clever ways for which they were not originally intended. There’s a place you rather be. I exhort you to step beyond the line, unmask the ghosts by the road, plan for ambushing bandits, and get on your way. Ghosts, bandits and the NO-NO policy Ghosts are unsubstantial characters in horror tales used by those who want to keep you boxed inside the standard functionality for their own reasons. Depending on their role these people will suggest or impose a NO-NO customization policy because: They don’t know how: Consultant tend to reuse approaches that has been successful in the past, functionality they know in detail. In addition to knowledge shortage, they may lack the willingness to search, learn and try a different way. It requires more work: To customize you need to think and test different options and occasionally be sent back to the drawing board by the unsuitability of an idea. Maintenance is also harder than with standard functionality. Plain is more profitable: A lot of recycling is possible, when doing a customer after another, if standard functionality is used. Much can be saved by copy-pasting documentation. Firms can do standard implementations with cheaper consultant with little experience while customized solutions require time from their high value gurus. They want to cover their backs: Risk is ever present in any implementation, but blame can be diverted to SAP when the solution is standard. Customizing requires you to assume responsibility for your decisions and actions. You should not be afraid of ghosts. Use your time instead preparing for real bandits.As with any myth, there are aspects of truth that you should be aware of, real problems that you should plan for or situations where customization should be better avoided. Upgrades: Upgrades are SAP changing the rules of the game and that causes a lot of problems. This is true even for standard functionality but bad, as in fragile, customized code can be particular sensitive as it is your job to test it and adjusted for SAP changes. Standard functionality can cover it: Do not reinvent the wheel. Check first if an off the shelf functionality can do it. Something you have not used before, even obscure. There is no need: It is frustrating to invest money and effort in a tool that no one uses because the need is not real, the solution is too complex or the benefit is not realized. Zombie systems: The worst use of customization is to keep alive reports, screens and procedures that should have died with the legacy system. This happens when users are unwilling to incorporate the best practices on which SAP is built on – or even try a slightly different way to do the same thing. They don’t know what they want: When first implemented, users don’t know what SAP is capable of or its limitations. They may ask for things they don’t need, things they won’t use or figures that cannot be derived from the data in the system no matter how much you play with it. These are valid reasons to treat customization with respect. The way you should treat electricity even if you wouldn’t consider adopting an Amish lifestyle because of the potential danger. Step Beyond There is a right way to do customization and you can archive it by following a few guidelines including these: Embrace customization: If you fear customization you will shun from it, will not dedicate the time and effort required and the result will be a half-baked solution, fragile and dangerous, that will bite you back when less expected. Give customization the importance it should have, invest time and people in it, design procedures and rules to produce valuable and resilient solutions to be proud of. Assume the risk: Life is risky, SAP implementations are risky; manage it. Even the most standard of systems will have some risk – it can fold down your company by not being complex enough for your needs. The solution is not to dodge customization but to be prepared. Most of the points that follow will help you reduce the risk or recover from an adverse event. Eliminating risk completely is unrealistic. Determine the real need: Some customization undertakings start with the wrong foot by jumping to the solution without properly defining the requirement. Users are particularly bad specifying what they want. Uncovering the real need behind the request is fundamental to deliver a value added solution that the user won’t abandon. The distance between users and programmers introduced by outsourcing has contributed to the proliferation of spec perfect solutions nobody uses. Analyst should be capable to challenge the users in order to give them not what they want, but what they need. Sell it: You should be so proud of your solution to brag about it; or at least to sell it to others with confidence on the advantages it provides. Why don’t use the tested tools of marketing: surveys, focus groups, promotion during training and post implementation customer service? Make sure that a good idea doesn’t go to waste because people do not know about it. The upgrade should be optional when possible, so the user make the decision to use it because they see the benefits. This also forces the IT team to make sure that the customization has a real value that can be measured. Get it stable first: Customization during the initial implementation of the system is necessary to adjust the system to business specific processes that are fundamental and the standard cannot support. It is however preferable to let the system stabilize for some time before starting to incorporate further enhancements, allowing the business to understand better what the system can give them and what they lack. Incremental steps giving time for the new features to get assimilated are better. Document for maintenance: People don’t read documentation, so make it readable. As with any form of writing documentation should grab the reader attention and express ideas clearly. Don’t write to yourself; don’t assume the other knows what you do. Always start exposing the origins and the rational of the tool, selling its benefits and warning about known issues and limitations. Leave the technical details to the bottom of the document. Having the original document with changes appended at the bottom is a bad idea, it makes understanding the document a torture. Use versioning to keep track of history but keep the main document as a consolidated view of what is currently there. Make parachuting into the project easy for newcomer consultants and users with a central compilation of all the customization in the system with a link to each feature’s document. Use technologies like Wiki to let anyone expand or correct, rearrange and link what becomes no longer documentation but a useful reference and help tool. Code for maintenance: Always choose readability over performance. People may complain about speed but it never reaches the level of hysteria caused by a problem that is taking time to fix. Segregate every step in blocks or function calls (extract_data, do_calculation, display_report). Put additional effort while commenting the code, using several lines for each step to explain what it does and the logic behind it. Make the code your main technical document. Use resilient code: Fragile code is the result of rushing things, bad practices and poor understanding between analyst and developer. Fragile code fails during upgrades or if a special case is encountered, failure is usually unexpected, catastrophic and difficult to fix. Resilient code fails too but knows how to fold graciously instead of exploding and falling in flames. Suggestions of good coding practices – like checking if a number is zero before dividing by it – require a post of their own. Leverage your team: Don’t allow the consultants to leave your people in the dark, make sure that the understanding of the details is passed to your team, that they make it their own. If you team is not capable of owning the solution, develop them. In particular, I believe that the most effective investment you can do in training is to teach your analysts enough ABAP to read and debug code, write specs for solutions that are feasible and discuss on the same level with the developers. Make your customization configurable: Create a table for any new piece of code with an indicator that you can set or reset to activate the code or skip it; either as a global switch or dependant on a group (a plant, a material type, an MRP controller). If you code allows for different approaches let the configuration table define which. Avoid hardcoding, use a customized table or a selection parameter instead. By configuring your customization you can activate the functionality just for a pilot and then roll it over in a controlled way. This also allows you to easily fall back to a previous version, or all the way to the standard, in case there are problems. Test, test, test: It cannot be stressed enough, you should test as much as possible as many cases as possible. But also understand that real testing only starts when you move the solution to you production environment. Do not be surprised that the business has issues with your solution; you should be in alert and ready to act. Ask for feedback and adjust the code as soon as the need arises. So these are the precepts that I have based my career on and that guide what I currently do. They are also the basis of this blog where I will promote customization by sharing ideas and giving away solutions that you can use and expand. M. Night Shyamalan’s film “The Village” shows how people can feel a moral duty to make you fear what they fear, to keep you away from danger. You can however have a different view. Stepping beyond that line can take you to a whole new world of opportunities. (This post was first published on the author's professional blog, see profile) 177 Views 2 Comments Permalink Planning Run: program error affects behavior of various heuristics Posted by Tiago Furlanetto Jan 3, 2014 You use /SAPAPO/CDPSB0, /SAPAPO/CDPSB1 or report /SAPAPO/BACKGROUND_SCHEDULING for planning in APO. You face any of the symptoms below: You execute in a Planning Run heuristic New Explosion (SAP_PP_021). At the end of the Planning Run, you notice that no orders were reexploded You execute in a Planning Run heuristic Rescheduling: Top-Down (SAP_PP_010). The Planning Run is terminated and in the Planning Logs error message "Order Not Found" can be seen. Also, error message "Invalid Order" (/SAPAPO/OM010) is raised You execute in a Planning Run heuristic "Conversion SNP --> PP/DS" (SAP_SNP_SNGL or SAP_SNP_MULT). After the planning run, you notice that no Planning Logs were created and that no orders were converted You execute in a Planning Run heuristic Rescheduling: Bottom-Up (SAP_PP_009). The heuristic is terminated with error message "Product xxx in location xxx could not be planned" /SAPAPO/RRP_HEUR032 There is a program error in the selection of objects for planning in /SAPAPO/CDPSB0 and /SAPAPO/CDPSB1 and this program error affects all of the heuristics above. If you are having one of these issues, please, check whether note 1655314 - Rescheduling: Bottom Up fails during the Planning Runs is implemented. Apply it, if necessary. 542 Views 0 Comments PermalinkTags: sap_pp_009, sap_pp_010, sap_snp_sngl, sap_snp_mult, sap_pp_021, new_explosion, reschedul ing:_bottom-up,rescheduling:_top- down, snp2ppds, conversion_snp, /sapapo/cdpsb0, /sapapo/cdpsb1, /sapapo/background_scheduling,/sapapo/rrp_heur032, /sapapo/om01 0, invalid_order, order_not_found Error "Activity Not Valid" (/SAPAPO/OM_ERROR 043) during order creation with PDS Posted by Tiago Furlanetto Dec 30, 2013 You use Subcontracting in PP/DS and a PDS is used for order creation at Subcontracting Location. When creating a Purchase Requisition for the Product at Plant Location, the order creation fails with error "Activity Not Valid" (/SAPAPO/OM_ERROR 043). Conversely, if you try to create a Planned Order for the Product at Subcontracting Location, the same error is raised. At the Product View, the following popup may be shown in this case The issue is caused, in general, by a program error in PDS transfer. To solve it, you may 1) Implement note 1824590 PDS-EXP: Dump TABLE_INVALID_INDEX after PDS explosion 2) Make an initial transfer of the Subcontracting PDS from ECC to APO 3) Retest the issue 313 Views 1 Comments PermalinkTags: scm, apo, vendor, subcontracting, pp/ds, pps, production_planning, subcontractor, scm_apo, /sa papo/rrp3,pds_explosion, scm-apo-md-pds-exp, scm-apo-int-md-pds, scm-apo- pps, error_occurred_while_creating_order, /sapapo/rrp251,/sapapo/om043, activity_not_valid Merging the sub-items in SCM 7.0 EHP2 Posted by Babu Kilari Dec 28, 2013 Recently, I was exploring some of the options in Rules Based Availability Check ( RBA ) and found that SAP has introduced the option of merging the sub items to ease the handling of transactional documents in ECC. However, it has some pre-requisites that has to be met. As part of the implementation I was running through, I always had the following questions in Product Substitution (in fact many users did come to me with the same question ) for which I didn't have any answer. If there is a Product Substitution between two products P1->P2; and if the Product 1 is fully available to the extent of ordered quantity ? Why would system create a sub item with the same ordered product ? Initially when I approached SAP with this question, they reverted to me saying that the "Rules Immediately" option in the check instructions is responsible for such a behavior, however from business perspective it doesn't make any sense to create a sub item when the same product is fully being fulfilled with enough stock being available. With the recent upgrade to SCM 7.0 EHP2; I found something in check instructions that made me to setup some test data and see how it behaves and it did answer me the questions I initially had ( mentioned above ) I have created a sub item between two products P1->P2 with rule control as "Start from top of list" approach. There is some stock of 900 PCs available for P1 in the location L1 (1000 ) and there was no stock for Product P2 in the same location (1000) . I have selected the check boxes "Activate RBA", "Start Immediately" in check instructions and I have created the sales document for 2000 Pcs with Product P1 as shown below I have seen that the sub item has been created though P2 doesn't have any stock. This particular case is something similar to normal ATP check wherein P1 is being ATP checked to look out for confirmation. Following screenshots shows the ATP picture and sales order situation. Note :- The behavior is same ( sub item is created ) when the sales order quantity is less than or equal to the stock available for Product P1. Now, I have selected the "Merge Sub items" option in the Check instructions and executed the ATP check. There has not been any change in the delivery proposal however, the sub items have been merged together and only main item is available in the sales order with the confirmation 900. Also, you can see the confirmation picture of schedule line at main item level as shown below. Now, I have created a stock of 500 PCs for Product P2 and re-executed the availability check ( by keeping "Merge Sub-items option ticked ) and following is the delivery proposal screen for the same ordered quantity 2000 PCs. After accepting the proposal, I see the sales order situation as shown below. Hence, it looks like whenever the partial confirmation picture is identified, the pegging areas are being shared for a single sales document and hence as per the SAP documentation, the merging of sub item is not possible. In short, whenever the substitution takes place between two same products, sub items can be merged to ease the transactional document in OLTP for further steps. But, there is one thing that we need to keep in mind in terms of location substitution. If there is one single product that is being substituted between two locations and if the quantity is completely being fulfilled with only one single product though two locations are being substituted, in this case merging the sub items is still possible because there can be a Stock transport requisition that could be created between the two locations. This can be configured in location substitution procedure using an activity to tranship the product between two locations. Hope the above information helps. 416 Views 3 Comments PermalinkTags: apo, atp, available, gatp, substitution, rba, product_substitution, (gatp), subitems, check_instruct ions,location_substitution Errors /SAPAPO/RRP297 and/or MD5020 in PP/DS transactions and Alert Monitor Posted by Tiago Furlanetto Dec 27, 2013 You are in SCM 7.02, 7.12 or 7.13 and in support packages SAPK-71302INSCMBASIS, SAPK-70209INSCMBASIS, SAPK- 71204INSCMBASIS or lower When you open the Alert Monitor (/SAPAPO/AMON1), the Product View (/SAPAPO/RRP3), the Requirements View(/SAPAPO/RRP1), the Receipts View (/SAPAPO/RRP4) or even when you execute extractor 0APO_PPDS_ORDER_01, one of the messages below is raised: Error occured during range of coverage calculation - /SAPAPO/RRP 297 Parameter length error (parameter too long or too short) - MD5 020 The issue should be solved with note 1828850 Hash generation error - Unicode 321 Views 0 Comments PermalinkTags: apo, pp/ds, pps, product_view, /sapapo/rrp1, 0apo_ppds_order_01, days'_supply, requirements_ view, /sapapo/rrp3,/sapapo/rrp4, receipts_view, /sapapo/amon1, alert_monitor Global Available To Promise (GATP) Overview Posted by SATISH WAGHMARE Nov 19, 2013 Introduction : Global Available To Promise (GATP) in APO supports online searches to determine if requested products are available at specific times in quantities that satisfy customer demand. GATP processes are run via SAP live Cache, which processes large volumes of data and enables data sharing across several applications. GATP meets the challenge of providing availability information across a global enterprise. The concept of available to promise (ATP) used in Sales and Distribution (SD) module in SAP R/3 provides check capabilities that deliver results for basic business scenarios. More complex scenarios, however, require more robust capabilities to make delivery commitments that are in line with the real-world demands. In short, global scenarios require global solutions. Global ATP — or GATP — takes advantage of SAP APO technology and picks up where the SAP R/3 ATP solution leaves off. Following are the functionalities using GATP allows you to answer questions related to promising products to your customers. GATP quickly makes information available to provide real-time optimized decision support. It offers the functionality to perform availability checks which consist of online searches that determine if requested products are available at requested times in the quantities that satisfy customer demand. GATP can be used for Sales Order, Scheduling Agreement, Delivery, stock transfer orders and production orders (for their input components). GATP Methods can be classified into three areas: 1. Basic methods and their combination (product check, product allocation, and check against forecast) 2. Rules-based ATP (RBA) 3. ATP integrated with production You can combine several GATP methods to provide more advanced capabilities. Product Check A basic product availability check generates positive results if the so-called ATP quantity for a product is available on the requested delivery date. If it is not available, a new delayed delivery date is proposed. The ATP quantity referenced during the product availability check is based on categories defined in Scope of Check. Product Allocation Check (PAL) The second basic method is product allocation (PAL). Using information in the DP module, PAL lets you know your availability to promise when sales orders compete for quantities in a constrained supply chain. New products, production downtimes, and other factors lead to fluctuating demands, which can affect product supply. For these situations, PAL provides a tool to ensure a better distribution of the total amount when a company cannot deliver the full available quantity to a customer. Check against Forecast The last method on the list is a check against forecast. It provides a check method that is especially important in make-to-order environments, where inventory is not available to confirm the quantity ordered by the customers. In this case, the quantity confirmation is performed against the forecast. Like PAL, this functionality is integrated with the DP module. Rules-Based ATP An ordinary ATP check is restricted to the requested locationproduct and checks only the according timeseries. Using rules-based ATP it is possible to substitute both the location and the product. In branched supply chain networks, rules-based ATP allows companies to take full advantage of multiple shipping assets to ship goods from alternative sites to customers. In addition, it permits certain products to be substituted as required to successfully satisfy customer demands. RBA is beneficial for Distributors, consumer product goods Industries Capable-to-Promise(CTP) CTP technology taps into SAP APO Production Planning and Detailed Scheduling (PP/DS) functionality. CTP triggers an online check when a sales order is created. If the supply cannot cover the new demand, the PP/DS functionality is called on as a part of the ATP check. Product Master- PP/DS Tab - PP Plng Procedure determines the action in CTP. Example - Cover Dependent Requirements Immediately option is selected, a product heuristic for a specific product is called immediately when a sales order is created or changed. In general, the PP planning procedure determines the actions to be executed after a planning event like - sales order creation, goods movement, planned order change, etc. CTP is beneficial for Steel manufacturers, paper, chemical Industries. Please refer SAP Note#426563 for additional information. Multilevel ATP The basic idea of the multi-level ATP is to confirm a customer request if the components for the product are available in time (i.e. taking the lead-time to produce the finished product into account). Basically, multilevel ATP explodes a bill of material (BOM) for the assembled product, then checks the availability of each item at the component level. A multilevel ATP check determines the availability of each component required by the finished good. A big difference between this check and CTP is data is stored in the ATP tree. It's a new object that prevents the creation of the receipt elements generated by CTP. It is especially helpful for business scenarios that require products to be configured for individual customers (assemble-to-order scenarios). If component availability is the critical factor for your planning, multilevel ATP is the best option. Because CTP focuses on detailed scheduling strategies, it is the best choice when bottlenecks are the critical factor. SAP note 480292, Multilevel ATP documentation also provides helpful information about the functionality. CTP and ML-ATP In a make-to-order environment there are no receipts per definition. The idea of an ATP check is therefore not to check whether there are receipts for the requested product but whether there is enough available capacity to produce the product and/or whether the required components are available. This can also be done using third option - ATP check against allocations, where the allocations represent an aggregated capacity. Transportation and Shipment scheduling The transportation and shipment scheduling is an integral part of the availability check in APO, and calculates the time difference between the requested delivery date at the customer site and the required material availability date at the factory. In between the requested delivery date and the material availability date the goods issue date, the loading date and the transportation planning date are scheduled. The scheduling starts from the requested delivery date and time. The requested delivery date is meant as the date when the material has to arrive at the customer site. This is the date which is entered in the sales order. Backorder Processing The basic idea of backorder processing is to carry out a new ATP check for a set of order items. This way backorder processing can also be used to distribute quantities in case of shortage (resp. lateness) according to priorities. Backorder processing is usually performed in the background, but interactive backorder processing is also possible. Basically, BOP consists of three steps: Filter the treated elements, sort those sales documents, and schedule them. Additional References http://help.sap.com/saphelp_scm50/helpdata/en/04/5e7237412a5249e10000009b38f842/content.htm http://help.sap.com/saphelp_apo700_ehp03_on_erp/helpdata/en/26/c2d63b18bc7e7fe10000000a114084/f rameset.htm http://scn.sap.com/community/scm/apo/production-planning-interfaces-and-global-atp http://help.sap.com/saphelp_scm70/helpdata/EN/05/7e1f3bc779144ae10000000a114084/frameset.htm Appreciate if you post your comments/feedback/additional inputs on the document, it will help with my next blog/documents. Thank you Satish Waghmare 2639 Views 1 Comments PermalinkTags: overview, back, order, to, global, processing, atp, available, gatp, rba, ctp, promise, (gatp), mat p Two INT notes you shouldn't miss after upgrade to SCM7.02 Posted by Tiemin Wang Sep 9, 2013 After upgrade to SCM7.02, some customers reported incidents that didn’t happen in earlier releases. From integration area, I’ve found the following two notes are quite often recommended: 1751405 Process order integration results into LiveCache error RC 43 valid for: SAPKY70201 - SAPKY70205 >> It’s also applicable if you see error messages during planned order conversion. The error message can be backward scheduling (enter finish date) Forward scheduling (enter start date) Dump MESSAGE_TYPE_X in program SAPLCXTK 1794856 PO or STO dates incorrect in SCM or not visible in APO valid for: SAPKY70201 - SAPKY70207 >> It’s also applicable when CCR can detect/correct the missing PO. If you’re using BAPI_POSRVAPS_SAVEMULTI3, it should be implemented as well. It’s solved similar issue about purchase requisitions and PO memo. 415 Views 2 Comments PermalinkTags: important, apo, integration, cif, notes, pps, pur, sap_advanced_planning_&_optimization S&OP can be done using ERP only. But! It's very dangerous if your adviser does not know APO Posted by Uwe Goehring Dec 9, 2012 There are people talking at SAP supply chain conferences about how Sales & Operations Planning is playing the most important role in your planning process. I do believe it is important and a good plan for the right product can save you money in inventory holdings and make your customers happy with great service levels and fill rates. It can also reduce noise in the supply chain and, with a good forecast, provide a great tool to anticipate demand and therefore inventory holdings of finished goods, help with decision making in regards to the resources you need to make available and allow you to simulate various version and effects of a corporate supply chain strategy. The question is how do you get to a good plan in S&OP. For those of you whose company has purchased SAP software, the speaker should lay out good practices (if not the best) and give you valuable insight on how to best use that tool - SAP. And as we all know SAP software is comprised of an S&OP tool in its ERP version but they also sell advanced planning tools with APO. Now, if you get an adviser who tells you to use ERP or another one who tells you to use APO, then you know that neither one understands both. And that is a problem! Because you certainly don't want the knowledge (or lack thereof) of your adviser drive your use of SAP's Sales & Operations Planning. I agree with the ERP proponents that, without a good basic data setup in ERP, any APO planning process is sub-optimized. So if your company has bought APO, you should make sure that your data basis in ERP is sound before you go use DP or SNP. That is mainly because your history (consumptions, sales etc.) is collected in an info structure in ERP and then loaded into an info cube in BI from where it can be used for Advanced Planning in Demand Planning in APO. If your company did not make an investment in APO yet, it is an easy sell for the adviser to convince you to make use of ERP's S&OP (granted they know how it works). But beware! there is a lot of potential for a false setup that you will have a very hard time with later... especially when your company thinks about getting APO later. And they should, because in the long run and after getting more and more functions inside of SAP, APO should be the system of choice for your demand planning, distribution planning, production planning and procurement planning. And if you don't set up your ERP S&OP with APO in mind, you will have a very hard time to make the switch later! And if your adviser doesn't know APO, you can not setup your ERP S&OP with APO in mind! Just as an example: in APO the Planner (an object) is independent of the location (plant or DC) whereas the MRP Controller in ERP is plant specific. So the product portfolio design should be setup with this in mind. Also, in APO there are Characteristics Value Combinations. These are essentially the Planning Hierarchies used in ERP. You really don't want to redesign all that later. Yes! You need to use what you have today. But! You will also have to prepare for the future. You can not ignore and dismiss what's possible for you tomorrow... just because your consultant doesn't know about it. Don't let anybody tell you that you are not ready for APO. It's like they sell you a Porsche and don't let you drive past second gear. Backorder Processing (BOP) run on orders with custom ATP categories created by Mitesh Verma on Jul 8, 2013 8:43 AM, last modified by Mitesh Verma on Jul 15, 2013 11:32 PM Version 1 inShare There are many instances where it is required to change the ATP category of sales orders based on the order type (or other reasons) so that those orders are visible separately to the users in APO. But once the ATP categories are changed to a custom ATP category, the orders line items are not picked during the BOP run since the custom ATP categories are not available in customizing table as shown below. Even the consignment orders (ATP Category "EK") are not available here and hence you can't execute BOP run on consignment orders. The solution to resolve this problem is pretty straightforward. All we need to do is to add the custom ATP category to the table /SAPAPO/BOPFLT_S. In my previous implementations, I had directly added the custom ATP categories in this table by going to SE16 and adding new records for the ATP categories which I wanted to process through BOP. Enter the data for the custom ATP category order as shown below. Once the records are added in the table, the custom ATP category will be available to be added in the filter as shown below. Some time last year, SAP came up with a note which also does the same thing. So instead of adding the record directly in the table /sapapo/bopflt_s, you need to execute the program and it will add the records automatically. Note 1747917 - Customer-specific ATP categories and /sapapo/bopflt_s This note describes how to get BOP relevant ATP categories to be part of the table /sapapo/bopflt_s so that BOP run can be executed on them. The note is valid only for SCM release 7 and up. For SCM 5.1 and below, you can try adding the record directly in the table /sapapo/bopflt_s but it has not been tested. 1648 ViewsProducts: sap_advanced_planning_&_optimization Tags: sap, categories, custom, apo, atp, gatp, bop, atp_confirmation Average User Rating (3 ratings) inShare Comments 1 Comment Manav Sahay Oct 24, 2013 12:46 PM Nice document. Thanks for sharing Regards, MS CIF Superfluous object clean up and performance tweaks created by Guru Charan on Jul 26, 2014 11:52 AM, last modified by Guru Charan on Jul 26, 2014 11:55 AM Version 1 inShare Delete Superfluous objects: There are hundreds of thousands of superfluous filter objects that might get accumulated in ECC with reference to the CIF_IM* tables. Program RCIFIMDL is supposed to be scheduled regularly in ECC at the end of the daily CIF job to clean up such entries which get created when master data is removed from a CIF integration model. Once the program has run, there should be no superfluous filter objects remaining. With so many superfluous objects in the system, this is likely to be causing multiple performance issues for most CIF activities (eg daily CIF job, CCR, CIF steps during system refresh etc). Delete old entries from CIFBALSEL: Old entries are not being deleted from table CIFBALSEL in ECC. This table stores a key to the application log for planned orders to enable easy searching of the application log via program RFINDLOG (e.g. with document number, material etc). Program RDELBALS is supposed to be scheduled regularly in ECC at the end of the daily CIF job to cnnlean up any entries which no longer exist in the system application log. Note 1816974 can improve the vperformance of this report. Reorganize superfluous CIF update counters: Program RCFUPDCR is supposed to be scheduled regularly in ECC at the end of the daily CIF job to clean up any superfluous CIF update counters. The SAP Help should help understand much better. Reorganize inconsistencies in table CIFORDMAP: Program RCFORDCH is supposed to be scheduled regularly in ECC at the end of the daily CIF job to clean up any inconsistencies in table CIFORDMAP. Delete CIF application logs in ECC/APO: It might be possible that you would have already been running a regular job to delete the application logs, but just make sure that you are in fact dealing with SBAL_DELETE but not RDELALOG. As per note 1460194, we should not be using RDELALOG; instead we should use SBAL_DELETE (transaction SLG2). You may check the number of entries in BALHDR table for reference in this regard. Reorganize CIF post processing records in APO and ECC: Background job /SAPAPO/CIF_POSTPROC_REORG can be run as per our needs (whether to go for deletion of only the obsolete records or the old records). This will make sure we clean up regularly the entries from the tables /SAPAPO/CIFERRLG from APO and CIFERRLOG from R3 (the same report has the impact on these two tables). ************************************************************************************* If in case any of these clean up procedures is not yet seen implemented in your system, but you plan to implement them: just make sure to reorganize the corresponding tables and rebuild the indices of all these tables to actually enjoy a good improvement in CIF performance. 82 Views Topics: performance Tags: cif Rule Based ATP with Exclusive Rule Strategy created by M Manimaran on Jun 16, 2012 2:50 AM, last modified by M Manimaran on Jun 16, 2012 4:07 AM Version 3 inShare Rule Based ATP with Exclusive Rule Strategy Scenario: Rule Based ATP is setup to carry out product and location substitutions. At one point of time, business does not want to promise materials from one of the locations involved in the RBA substitution. In some situation, business wants to replace the discontinued location with some other location temporarily. Using an exclusive rule strategy, we can exclude the particular location from the RBA and also we can make the system to select alternative location for the excluded location. Scenario set-up: First we will set up the Rule Based ATP scenario with 3 locations DC3000, PL0001 and PL0006. Then we will test how the exclusive Rule strategy works for excluding the location DC3000. Materials used: DEMO_1 DEMO_2 DEMO_3 Locations: DC3000 PL0001 PL0006 Product List: Maintain the Rule with Product substitution and Location determination procedure Maintain the Rule Determination in customizing, (In SPRO, APO --> GATP --> RBA) Create Condition Table Create Access Sequence: Create Condition type and assign the Access Sequence Create Rule Strategy Create Rule Strategy Sequence and assign the created Rule Strategy. Assign the Rule Strategy Sequence to make it to determine the correct rule while calling RBA. Assign the rule DEMO to the Sales Organization 0001, Sold-to- Party 0000001000 and the Product DEMO_1 In the Check Instruction, make sure that RBA is active. (Check mode ZQT and Business event A) The available stock for different products in different locations: Product Location Stock (EA) DEMO_1 PL0001 5 DEMO_2 PL0001 5 DEMO_3 PL0001 2 DEMO_1 PL0006 10 DEMO_2 PL0006 10 DEMO_3 PL0006 2 DEMO_1 DC3000 10 DEMO_2 DC3000 0 DEMO_3 DC3000 0 Simulate the ATP check using ATP Simulation transaction /SAPAPO/AC04 The substitution takes place across all locations and products. Excluding location DC3000 from RBA: Now the situation arises that the business does not want to promise materials from the location DC3000. Create a rule with the location list containing DC3000 The rule should be of type 'Inclusive'. Setup the Rule Determination with the Rule strategy to exclude the location DC3000 Create a new Condition type and assign the Access Sequence already created Create Rule Strategy In the Rule Strategy Sequence (RSS1) already created, assign the newly created Exclusive Rule Strategy. Assign the created rule DEMO-EX to the required rule determination conditions Now Simulate ATP check in the ATP Simulation transaction /SAPAPO/AC04. We can see that the location DC3000 is not considered for the substitution. Only PL0001 and PL0006 are considered. Click the Rule button and check that both the rules are picked correctly. Thus the location DC3000 can be excluded from the RBA check temporarily by introducing an exclusion rule strategy. Once the location is ready to supply the products back, the rule strategy can be removed from the rule strategy sequence, so that it will be included back to the RBA. Alternative Location PL1300 in the place of excluded location DC3000 Now the business wants to include the location PL1300 temporarily in the place of DC3000. Maintain Alternative rule: Maintain location determination procedure DEMO_ALT1 with the 'Alternative' type. Maintain the location PL1300 as an alternative location for the DC3000 location. Create Rule 'DEMO-ALT'' with rule type 'Alternative' and assign the created Location Determination Alternative procedure DEMO_ALT1. Setup the Rule Determination Create new condition type and assign the access sequence already created. Assign this condition type as the second level in the Rule Strategy EXC2, which was created earlier to exclude DC3000. Assign the created rule DEMO-ALT to the required rule determination conditions. The available stock for different products in the location PL1300: Product Location Stock (EA) DEMO_1 PL1300 5 DEMO_2 PL1300 5 Now Simulate ATP check in the ATP Simulation transaction /SAPAPO/AC04. Now we can see that location PL1300 is included in the list in the place of DC3000. Click the Rule button and check the rule determination has been carried out correctly. Thus the alternative rule can be used to replace a location with another location. ***************************************************************