Thursday, August 28, 2008

Note 566025 - Consumed and not consumed forecast together from DP to SNP

Note 566025 - Consumed and not consumed forecast together from DP to SNP

Summary

Symptom

It is needed to release Consumed and not consumed forecast together from DP to SNP.

Other terms

/sapapo/mc90 release-functionality-DP->SNP

Reason and Prerequisites

It is needed to release Consumed and not consumed forecast together from DP to SNP.

Solution

There are two possible solution.

    1. Solution #1.

Please set your SNP data view in a way to have:

  • a standard forecast key figure with category type FA,
  • a standard forecast key figure with category type FC.

Using transaction SE18 and selecting the definition name '/SAPAPO/SDP_RELSTRAT', please push the display button and add in your own implementation for the method 'SET_STRATEGY' the following code:
if IV_CATEGORY = 'FC'.
CV_NO_STRAT = 'X'.
endif.

Using transaction SMOD and selecting the Enhancement APODM017 and the Components radio button, please double-click on the Function module 'EXIT_/SAPAPO/SAPLAPO_EXIT_001'.
Then in your own include add the following code:
FIELD-SYMBOLS: like line of SCHEDULE_LINE_TAB.
LOOP AT SCHEDULE_LINE_TAB assigning
where CATEGORY = 'FC'.
-IGNORE_PEGGING = 'X'.
ENDLOOP.

The forecast ATPcat FC must not be used for other purposes already.
Activate all objects where these changes are done.
The consumed forecast should be displayed by the key figure with category FA, the not consumed forecast should be displayed by the key figure with category FC and no problem or side effects should occur in the consumption and PP/DS processes.

    2. Solution #2.

If the forecast ATPcat FC is used for other purposes already then this second solution can be implemented.

      a) The following way is valid for APO3.0 and APO3.1.

Please set your SNP data view in a way to have:

  • a standard forecast key figure with category type FA,
  • a standard forecast key figure with category type FA and semantic value = 011.

With this setting, releasing by /sapapo/mc90 to category FA once you will have then values in both key figures and no badi and no user exit are necessary any more.
Consumed forecast will be available in the first standard forecast key figure, not consumed forecast will be available in the standard forecast key figure with semantic value = 011.

      a) The following way is valid for SCM4.0 and newer releases.

Please set your SNP data view in a way to have:

  • a standard forecast key figure with category group DF1, category FA and quantity type initial, ( standard forecast key figure setting),
  • a standard forecast key figure with your own category group, category FA and quantity type = 01, Key Figure Semantics = 000 and Key Figure Funcs initial.

With this setting, releasing by /sapapo/mc90 to category FA once you will have then values in both key figures and no badi and no user exit are necessary any more.
Consumed forecast will be available in the first standard forecast key figure, not consumed forecast will be available in the standard forecastkey figure with quantity type = 01.

Tuesday, August 26, 2008

ABAP programming

When you run an ABAP program, you call its processing blocks. ABAP programs are controlled
from outside the program itself by the processors in the current work process.



Type I
Type I programs - called includes - are a means of dividing up program code into smaller, more
manageable units. You can insert the coding of an include program at any point in another ABAP
program using the INCLUDE statement. There is no technical relationship between include
programs and processing blocks. Includes are more suitable for logical programming units, such
as data declarations, or sets of similar processing blocks. The ABAP Workbench has a
mechanism for automatically dividing up module pools and function groups into include
programs.



SY is a structure with the ABAP Dictionary data type SYST. The components of SY are known as
system fields. System fields contain values that provide information about the current state of the
system. They are automatically filled and updated by the ABAP runtime environment. Examples
of system fields:
SY-SUBRC: Return code for ABAP statements
(zero if a statement is executed successfully)
SY-UNAME: logon name of the user
SY-REPID: Current ABAP program
SY-TCODE: current transaction
SY-INDEX: Number of the current loop pass

LIKE
can be used in the same ABAP statements as the TYPE addition to refer to any data
object that is already visible at that point in the program. The expression is either
the name of the data object or the expression

Definition of local types in a program using
TYPES LIKE .
The new data type inherits all of the technical attributes of the data object .

Wednesday, August 20, 2008

SAP architechture

Processing a User Request

IDocs, ALE

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.

A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.

IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.

An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.

Source:http://searchsap.techtarget.com/sDefinition/0,,sid21_gci852485,00.html


What is ALE?
The ALE (Application Link Enabling) concept available in R/3 (Release 3.0) supports the development of applications across different SAP systems. It incorporates the exchange of business information across these systems whilst ensuring consistency and integrity of the data. This functionality is achieved with the use of IDocs (Information Document) as opposed to the use of a centralized database. ALE allows the user to perform an SAP transaction in the sending system, after-which
the following steps occur:
• One or more communication IDocs (intermediate documents: container for the application data) are created in the sending system database. An ALE distribution
model, that needs to have been configured, determines which systems the IDocs are to be sent
• These communication IDocs, that contain the relevant application data of the transaction that was performed, are then passed to the ALE communication layer
• This layer performs an RFC call, using the port definition and an RFC destination determined through the customer model
• The IDocs are then transferred to the respective receiving systems. These could be SAP R/3, R/2 or external systems
• If the receiving system is an SAP system then:
• In the case of master data distribution the same transaction that was performed on the sending system is again performed on the receiving system with the data contained in the IDoc. This allows the data to go through the SAP checks before posting occurs
• In the case of transaction scenarios the relevant data is passed to the respective transactions in order to load the required application document. E.g., a PO is loaded on the sending side, yet a SO is created on the receiving system
• Master data has another difference:
• It can be set up in such a way that any changes made to specific fields in master data tables can automatically trigger off the ALE distribution process for that particular master data object
• If a master data object is created or changed on a sending system and distributed to another system the respective transaction is used to either create or change that respective master data object on the receiving system
In general, if standard SAP can't perform the task required then neither can ALE. It doesn't add functionality; it merely de-couples it and allows you to distribute it onto other remote systems.

What can be distributed?
Control data
The control data includes all objects that describe how the system is organized.
These include Customizing data like company codes, languages, purchasing organizations, plants and user maintenance.
The customer details his specific distribution in the customer distribution model. Once the control data is distributed the control data cannot be changed on the receiving systems. All changes are made to the central system and transported to the receiving systems.
Master Data
The distribution scenarios for the master data are contained in the reference model.
Rather than distributing the entire master data information, views on it are distributed
(for example, sales views on the material master). By configuring the views, the customer can select the master data fields to be distributed.
Transaction Data
The distribution scenarios for the transaction data are stored in the distribution reference model. Examples of transaction data are customer order, distributed contracts, purchase order, shipping notification and invoice.
Why ALE?
ALE is business solutions to a very real need emerging in the SAP market. This is the need for businesses to move towards tighter integration between systems, yet, at the same time, provide independence to the various business units within the company.
In the past the move was towards centralized systems.
Standardization of business processes accompanied by ever-tighter integration within the central system no longer represents a practicable approach to this problem. The following are some of the most commonly encountered difficulties:
• Technical bottlenecks,
• Upgrade problems,
• The effect of time zones on international corporations,
• Excessively long response times in large centralized systems.
In order both to meet the requirements of today's customers and to be open for future developments, ALE must meet the following challenges:
• Communication between different software releases.
• Continued data exchange after a release upgrade without special maintenance.
• Independence of the technical format of a message from its contents.
• Extensions that can be made easily even by customers.
• Applications those are decoupled from the communication.
• Communications interfaces that allow connections to third party applications.
• Support for R/3-R/2 scenarios.

Source:https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/abap/An%
20Advanced%20Guide%20to%20Implementing%20Application%20Link%20Enabling.pdf


Tuesday, August 19, 2008

Note 429422 - SAP APO System Requirements for multiple Planning Versions

Summary

Symptom

This SAP Note describes how to optimize your liveCache Main Memory
Requirements when using multiple SAP APO Planning Versions
and especially how to enter the correct amount of Planning Versions
in the Quicksizer in oder to obtain realistic main memory
requirements for the SAP liveCache.

Other terms

Multiple Planning Versions, DP, SNP, PP/DS, liveCache, requirements,
main memory, swap, performance, sizing, hardware resources, Demand
Planning, Supply Network Planning, Planning Versions

Reason and Prerequisites

You use multiple Planning Versions and want to optimize your Main
Memory requirements for the SAP liveCache.

Solution

---------------
Introduction
---------------

Multiple Planning versions held in the SAP liveCache Main
Memory have a linear multiplicator effect for the required amount of
liveCache Main Memory in the Quicksizer.
However, there are different ways to reduce your SAP
liveCache Main Memory requirements due to the amount of versions.
Furthermore, you must enter the correct amount of Planning versions
in the Quicksizer, so that the resulting memory requirements are
realistic. Please, note that if you enter "n" Planning Versions, the
Quicksizer will assume that these Planning Versions are all used at the
same time and that all Versions have the same size : This is usually
not the case.

A possible way to optimize main memory requirements due to the amount
of planning versions, is, for example, optimizing version copy
procedures.
Please, see more details below.

-----------------------------------------------------
1. Optimization of liveCache Main Memory Requirements
-----------------------------------------------------

----------------------------
1.1 SAP APO Demand Planning
----------------------------

In case of SAP APO Demand Planning, if you store few versions
in liveCache Main Memory and keep the rest on the BW Info Cube on the
SAP APO Database, you can optimize your main memory requirements for
SAP liveCache.
This recommendation can be important if your SAP liveCache Main
Memory Requirements are high independently of the amount of versions,
that is, if you plan with a high amount of characteristic
combinations, key figures, etc.
However, for performance reasons, this alternative is
only recommended if your SAP liveCache main memory requirements are
much higher than the available memory addressing capabilities of
your liveCache server, for example, if you are using SAP liveCache
on a 32-Bit Windows Server.
Please, also note that some Demand Planning Versions may only be
required for reporting purposes in form of BW Info Cube Backups on
the SAP APO Database and not necessarily in the SAP liveCache main
memory : In such cases it is correct to enter this amount of Planning
Versions in the Quicksizer as "Amount of Demand Planning Versions in
the BW Info Cube" and NOT as "Amount of Demand Planning Versions in
the liveCache".

------------------------------------
1.2 Planning Version Copy Procedures
------------------------------------

Not all SAP APO users need copies of 100 % of the objects
for a Planning Version. You can avoid the copy of unnecessary data
and reduce your memory requirements by using the following approach
when copying versions for DP, SNP or PP/DS :
a) The central transaction for administration of versions and models
is /sapapo/mvm. This version will allow you to create and copy versions
restricting the amount of data to be stored in the version.
b) For time series data, you can also use transaction /sapapo/tscopy
which is more effective than /sapapo/vercop because it offers you the
choice to select which data area is going to be copied. If you take
advantage of the selective capabilities of /sapapo/tscopy for Time
Series, the result will be similar as if you had performed a 50 %
version copy.
c) Transaction /sapapo/vercop is recommended to be used only with Order
data and not with Time Series data : Please, do not check the Time
Series box when using /sapapo/vercop.

Please, note that liveCache processes planning data in basically two
ways depending on the kind of planning concept in use :
a) If planning is based on time buckets processing, like for DP,
the so called Time Series liveCache will be used.
b) If planning is based on order (sales orders, stock orders, etc.)
processing, like for SNP or PP/DS, the so called Order liveCache will
be used.

SAP Notes about Model and Version Management for SAP APO are available
in the component APO-MD-VM.
You can also check the size of your planning versions with
/SAPAPO/OM16 : See SAP Note 431299 for details.

--------------------------------------------------------------------
2. Tips & Tricks : How to enter the "right" data in the Quicksizer ?
--------------------------------------------------------------------

Especially for global customers with several business units, multiple
users may work with multiple versions and/or copies of SAP APO DP, SNP
and PP/DS versions.
However, in general, not all versions will be used at the same time and
not all versions are equally big in size.

1) You can get a first approximation about the system requirements for
your SAP APO by using the Quicksizer for SAP APO in :
http://service.sap.com/quicksizer

Currently, the SAP APO quicksizer is available for DP, SNP, PP/DS, ATP
and CIF. The results of the quicksizer are optimized for mass
processing (batch planning) rather than for interactive planning.
However, overhead CPU resources for interactive planning are also
given based on the amount of concurrent users.
Please, ask your hardware
Partner to perform the sizing of your SAP APO and/or to review your
your quicksizer results. SAP is also available for final reviews in the
framework of the different Service offerings.
It is also strongly recommended that you perform mass/volume tests
before going productive. In this way you will be able to check
if all performance settings and sizing assumptions are adequated
for your productive system.

The quicksizer questionnaire will ask you, among others, your planned
amount of characteristic combinations, key figures, time buckets,
sales orders, stock orders, purchase orders and planning versions
for DP, SNP and PP/DS. Some of these business figures, say, the
amount of Characteristics Combinations, Key figures,
Orders, that is, transactional data, Planning Versions, etc. have a
significant influence on the resulting main memory requirements for
liveCache. On the contrary, Master Data has a small influence on
the liveCache Main Memory Requirements.
If the figures entered in the Quicksizer are not accurate and do not
correspond to your business process reality, the resulting System
Requirements will also not be correct.
For example :
Please, take into account that the SAP APO sizing relevant amount
of characteristic combinations is NOT necessarily the mathematic
product of all your customers, locations, products, etc. :
Not all mathematic combinations may be relevant for your Demand
Planning run. A lower amount of characteristic combinations will
require less SAP liveCache Main Memory.
The same is valid for the key figures. For your SAP APO sizing, please
consider only the amount of key figures which will be relevant for
your Demand Planning run. In this way you will obtain realistic
liveCache Main Memory requirements.

Furhermore, some particular quicksizer figures such as Planning
Versions have a multiplicator effect on the resulting liveCache main
memory requirements.

If you type "n" versions, the quicksizer will
assume that these versions are used in parallel and have all exactly
the same size, that is, the maximum size which is associated to your
active version and which comes from all the figures you entered in the
quicksizer (maximum amount of characteristic combinations, key figures,
buckets, orders ...).
However, planners will define their own versions for their needs.
These may contain less orders than the active version, less master
data, and be therefore much smaller in size than the active version.
Therefore, the figure you have to enter in the quicksizer as amount
of planning versions must take this into account.
Example :
You plan to use 25 SNP versions presumably in parallel. 3 of these
versions are 100 % copies of the active version, 8 versions are
supposed to contain only 50 percent of the amount of orders of the
active version, 14 versions are planned to contain only 10 % of the
orders stored in the active version. Then, the figure you should enter
in the quicksizer must not be bigger than :
3 + 50% x 8 + 10% x 14 = 3 + 4 + 2 = 9
If you enter 9 versions, the quicksizer will give as result the
required amount of main memory to hold 9 versions in main memory.
However, SAP liveCache may not need to hold all 9 versions in main
memory at the same time.

2) You do not need to size your SAP APO so that all versions can be
held in Main Memory at the same time. Versions which cannot
be held on liveCache Main Memory will be swapped to the SAP liveCache
devspaces. Swapping is performed by the liveCache management system
automatically on a page level, the size of a Page being 8 KByte.
The liveCache swapping strategy is based on LRU (Last recently used),
as for all standard RDBMS.
liveCache keeps those 8KB-pages which are used most often in main
memory and swaps the rest of pages to disk. Eventually, the performance
may be reduced if there is not enough liveCache Main Memory available
to keep all versions which are often in use.
In some cases, the active Version may be swapped to disk if users
are running jobs which often require pages from non-active versions.
This should be avoided : Goal is to keep the pages belonging to the
active planning version in Main Memory.
Example :
Even if you use 9 versions presumably in parallel, not all concurrent
users will use the 9 versions exactly at the same time. The more
frequently used versions will be held in main memory, say, 3, and the
rest will alternately be swapped to disk until they are again needed.
That is, you may enter only 3 Planning versions in the Quicksizer and
not 9.
Please, also note the following.
Let's assume that your company has 2 Business Units working on one
central SAP APO. One Business Unit is located in the USA and the other
one in Europe. In such cases, most users in the USA will certainly
not work at the same time than users in Europe and therefore will not
need all Planning versions in main memory at the same time.

--------------
Conclusions
--------------

When sizing your SAP APO, you must take the following into account :

a) How big are your sizing requirements independently of the amount
of versions (amount of sales orders, forecast orders, etc.) ?
If they are already big, more versions stored in main memory will
only increase the liveCache Main Memory requirements. If they are not
very big, you can afford to have more liveCache Main Memory available
for multiple planning versions.
b) How big is your active version ?
The active version is the one which should be held in Main Memory,
while the rest of versions may be swapped to disk without
necessarily affecting the performance of the system.
c) How many 100 % version copies will be used on average and in
parallel ?
If only some percent of the versions are used in parallel, only this
percent of versions will be relevant for your sizing.
d) How many versions are Time Series or Order relevant ?
Performing version copies with the transaction tscopy can reduce the
amount of effective versions to 50 %.
e) How big are your Planning Versions in general ?
If most of them are not as big as the active Version, you must take
this into account when entering the amount of Planning Versions in the
Quicksizer, so that the sizing results are realistic.


Header Data



Release Status:Released for Customer
Released on:05.04.2002 14:02:16
Priority:Recommendations/additional info
Category:Consulting
Primary Component:SCM-TEC In Case of LiveCache Problems: Please use SCM-APO-LCA
Secondary Components:BC-DB-LVC liveCache

SCM-APO-SNP Supply Network Planning (SNP)

SCM-APO-FCS Demand Planning

SCM-APO-MD-VM Version Management

BC-DB-LCA liveCache Applications

Affected Releases

Release-Independent

Related Notes




541703 - Collective consulting note on technical subjects in DP

500843 - Composite SAP note for COM and SAP liveCache 7.2 or higher

431299 - Determining the size of plan versions

Wednesday, August 13, 2008

User Exit

User Exit

In computer software, a user exit is a place in a software program where a customer can arrange for their own tailor-made program to be called. In the R/3 system from SAP, a user exit is contrasted with a customer exit and allows a customer's developer to access program components and data objects within the R/3 system. In R/3, some user exits use Include statements to include customer program enhancements that are called from the program. Other user exits use tables that are accessed through customization.

Debugging a User Exit or Program


Enhancement/Modifications

1) Execute tcode SMOD to find available enhancement/modifications.
2) Create a project for the enhancement in tcode CMOD.
3) You must activate your project first in order to hit a break-point or get into debug mode for your existing enhancements/modifications, if you do not, the best you will be able to do is step through the main program until you hit the call for that particular customer enhancement.
4) To get into debug, you can enter a hard break-point in the enhancement itself, set a soft break-point with the stop sign, or the long way, before you execute your transaction or while you are in your transaction, you can place a /h in the ok code area (this is the area of your gui where you can type in a tcode). Once you have the /h, hit enter and that will take you into debug, from there, you can do many different things to find exactly what you are looking for.

User Exits

1) Identify the main program you want to locate a user exit/debug.
2) For example, go to SE80 and do a search by program or dev class (SAPMV45A sales order or Dev Class VMOD, most SD user exits are in this dev class). In SE80 if you go by program, most user exit programs end in a 'Z' on a rare occasion 'X' or 'Y'.
3) If you are looking at including MV45AFZZ, you can see where there are different forms. These forms will get called at times within the program. If you are looking to fill the storage location on the sales order, you will probably want to take a look at the perform that fills in a field in vbap.
4) If this is what you are trying to accomplish, you will need to do the select against the config Table TVKOL based on the shipping point/plant and possibly storage condition based on your picking strategies.
5) For the debug part, you can do the same as in the enhancements/modifications but you will not need to activate any projects.

Wednesday, August 6, 2008

Procurement for production

Maintain Info Records:
Purchasing Info Records(info record) are maintained as master data. An info record links a material to a vendor. Data included in an info record are current prices and future pricing conditions, vendor and material relationship information and the amount of time it takes a vendor to deliver the material.

Scheduling Agreement:
An outline purchase agreement is a long-term agreement between a purchasing org. and a vendor. It is regarding the supply of materials or the performance of services within a certain period. A Scheduling Agreement is a form of outline purchase agreement under which materials are procured on predetermined dates within a certain time period.

Procurement Activity Flow:
Create and Maintain Material Master->Create Info Record in SAP for suppliers->Create Scheduleing Agreements for suppliers->Release Scheduling Agreement to suppliers->Create Delivery Lines->Review and Release Delivery Schedule to IEC