Friday, July 24, 2009

SAP Advance Planner and Organiser. (APO)

SAP APO enables organizations to create a very close match between supply and demand by integrating purchasing, manufacturing, distribution, and transportation into one consistent model. SAP APO also includes functionality to enable organizations to dynamically determine how and when inventory should be distributed. The system draws on the data universally available in liveCache to optimize deployment plans based on available algorithms, as well as user rules and policies. In the benchmark, we use mass processing, which allows you to run the heuristic planning for large numbers of product-location combinations, with mass processing jobs running concurrently in the background. SAP APO is the application component of SAP SCM 4.0 and
mySAP SCM that helps you solve the seeming dilemma of improving customer service while lowering costs, yet increasing profits at the same time.
APO is an entire suite of supply chain planner applications that increase overall knowledge of the supply chain and provide forecasting, planning and optimization. There are eight application levels within SAP APO: network design, supply network planning, demand planning, production planning and detailed scheduling, transportation planning and vehicle scheduling, global availability and supply chain collaboration. The SAP APO is not a standalone application and requires a backend ERP system such as SAP R/3 for the execution. SAP R/3 communicate with SAP APO using the the APO Core Interface (CIF) which supplies SAP APO with the master and the transaction data in the real time. Interaction between the SAP R/3 at backend and the SAP APO is in real time and any data related to the production, the sales or the supplies is immediately transferred from one system to another without requiring any batch processing.

Alternative to APO in Oracle is Demantra
So how does APO differ from Demantra an Oracle product? To my understanding it is not able to fully perform PTPM (Predictive Trade Planning Management) capabilities? How does APO complete pre/post analysis of trade spend? Demantra is NetWeaver certified and able to run on an ERP backbone of SAP. Meaning it can be fully integrated. There are many customers currently doing this at Oracle from what I understand. What would you say to this option?
Apart from the different in PTPM, Demantra has a inbuilt Multi Lag Forecast accuracy analysis report also called Waterfall Model of analysis. This has to be built from scratch in SAP using BI. This is a best practice report and having it readily available is an advantage with Demantra
Materials in R/3 are known as Products in APO.
Allocations in APO are a way of controlling the stock levels permitted to be confirmed to a specific transactional requirement in R/3; e.g. a sales order
E.g. If an allocation is set up (via the APO planning book) to restrict the quantity of a product for a specific customer to a quantity of 10, when the actual unrestricted stock (ATP quantity) is 100, the second step of the ATP (Available To Promise) check will only allow that customer for this specific material to confirm a maximum of 10.
Key features:
· Allocations can be set up at different levels of an organization's structure through characteristic combinations
Allocations can be controlled periodically
· Allocations can be proportionate
· Allocations can be amended manually to satisfy the business's requirements during economic climate change or due to seasonal factors
· Allocations do not have a direct link to stock in R/3

LUW(Logical Unit of Work) in SAP


LUW and significance of it.
I have been working on SAP-ABAP from past one year. This is one of the question that has been particularly asked from me many times. So I have decided to properly document the question.
By the book defination taken from IBM site
A logical unit of work identifies input operations that are either committed or rolled back as a group. A unit of work begins when your code changes a recoverable resource; and ends when the first of these events occurs:






  • Your code invokes the system function sysLib.commit or sysLib.rollback to commit or roll back the changes


  • Your program executes a transfer with a commit specified


  • EGL run-time services performs a rollback in response to a hard error that is not handled in your code; in this case, all the programs in the run unit are removed from memory


In nomal day to day work, if we want to understand a LUW, we have to take an example of a small business.



While building a business(in fact any other) software( in any language), the most important thing is consistancy of data. Let's take an example of fligh booking software, The overall process can be divided into 2 parts,



1. The selection of flight then deducting the money from the user's account.



2.The transferal of the money from user's account to the concerned account.



In between these two process the data is inconsistant (the money belongs to no one) What if some system failure occurs at this point of time? Because the whole process comes under one LUW hence the data can be recovered( Technically Rollbacked).



Every application devloper should understand the fact that while communicating between any two logical points the consistancy should be maintained. If by any chance there is some error in between, we should be able to reset the database/data to the previous consitant state. (While studying the LUW concept , I came across a very interesting phenomenon called Transaction deadlock I will be writing about it and handling this condtion in ABAP here)



There are three units related to this term in SAP are :



1) Database Logical unit of work



The database LUW is a sequence of various database operations that usually ends with the database commit statement. If there are no errors in between the operations then only the LUW will be executed. Hence it's either 100% execution or zero. The changes to the database are not fully written untill database commit is executed. The whole system can be seen graphically as shown.

The commit to database can be performed in two way either implicit or explicit.
A work process when finished, triggers an implicit commit statement. This is due to the fact that a work process can use only execute one LUW. Hence as soon as it ends it has to close the LUW.
Example of work processes are
A. When a dialogue step is completed, (control changes back to SAP GUI).
B.When a new screen is created.
C. When a system sends a RFC (Remote function Call)


2) SAP LUW:
A SAP LUW may have a longer span than a DB LUW, there may be one or more DB LUW corresponding to one SAP LUW. A SAP LUW is triggered.
  • A transaction run with a new SAP LUW ( there may be more than one database commit used during one transaction)
  • A report run with a new SAP LUW.




2) SAP Logical unit of work



3) SAP Transaction.


What is BAPI??
Can we use commit or rollback in user exit and will it work ?