Friday, 11 December 2015

Concept of SAP Landscapes

Landscape : is the arrangement for the servers

IDES : is purely for education purpose and is NOT INCLUDED in the landscape.
DEVELOPMENT ---> QUALITY ----> PRODUCTION
DEVELOPMENT : is where the the consultants do the customization as per the company's requirement.
QUALITY : is where the core team members and other members test the customization.
PRODUCTION : is where the live data of the company is recorded.
A request will flow from Dev->Qual->Prod and not backwards.

1.    Sandbox server: In the initial stages of any implementation project, You are given a sandbox server where you do all the configuration/customization as per the companies business process.

2.     Development Server: - Once the BBP gets signed off, the configuration is done is development server and saved in workbench requests, to be transported to Production server.

3.    Production Server: This is the last/ most refined client where the user will work after project GO LIVE. Any changes/ new develpoment is done is development client and the request is transported to production. These three are landscape of any Company. They organised their office in these three way. Developer develop their program in Development server and then transport it to test server. In testing server tester check/test the program and then transport it to Production Server. Later it will deploy to client from production server.

Presentaion Server- Where SAP GUI have. Application Server - Where SAP Installed. Database Server - Where Database installed.

Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD.

- DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test. - QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training. - PROD may have something like a 200 Production. These names and numbers are the implementer's discreet on how they want it or they have been using in their previous implementations or how is the client's business scenario.

Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you think you are satisfied with your configuration and you think you can use it moving forward, you RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it for rough usage). As you re-do everything that you had thought was important and usable, you get a transport request pop up upon saving everytime. You save it under a transport request and give your description to it. Thus the configuration is transported to the Unit Test client (180 in this example).

You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden) client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you have all the configuration in the Testing client, just as it is in the Golden client. The configuration remains in sync between these two clients. But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction only client where you perform the unit test. Upon a satisfactory unit test, you move the good configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is corrected in Golden (may again as well be practised in the sandbox prior to Golden) and accordingly transported back to 180 (Unit Test) until the unit test affected by that particular config is satisfactory.


The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the 'ultimate' reference client for all the good, complete and final configuration that is being used in the implementation.

New Fields in Pricing adding field

Few tips on adding new fields in Pricing Field Catalog: 

To use fields in pricing producer, we need to creates a condition table. This condition table can be created by using the allowed fields from the field catalog. we can add the fields from the list of available fields. However, we may find that a new field may not be in the list of available fields. For this reason, we must be specify new fields for pricing. The document and item data in SD is stored in data tables, such as VBAK (sales Order header)and VBAP (Sales order item). Many of the fields from these tables are available in the field catalog.

The field catalog is a  a basically structure (KOMG) that consists of two tables (KOMK  -header and KOMP-Item ). Structure KOM “x” since they are communications structures used to communicate the transactional data with the pricing procedure. Table KOMG contains the fields of tables KOMK & KOMP. If you require a field that is not in KOMG, that means it is not in KOMK or KOMP. This means that the field you require cannot be used in pricing because there was no communication structure in the pricing. To use a field not defined in the field catalog, we need to add this field to the KOMK or KOMP structures, and then write the ABAP code to transfer the data in the field from the transaction tables to the communication structure.

Follow these steps:

1. firstly ,we can Create the field in the KOMK (header data..) and KOMP (item data…) tables using the standard includes provided for this type requirement

 2. Secondly, Write some code in the user exit to read the transaction data and transfer data it to the KOM “x” structures.

Menu Path The menu path here is IMG--- Sales and distribution-- System modification--Create new fields by using SAP Condition technique

This process requires some knowledge of the ABAP dictionary and how to use the ABAP dictionary to create and change fields and tables. You may have to use an ABAP technical skill to help  you.

If the field is from the header table (Eg, the order table VBAK), we will  need to add it to the include table KOMKAZ in table KOMK. If the field is from the item table (eg, the order item table VBAP), we will need to add it to the include table KOMPAZ in table KOMP.

 Let’s say you need to use the “base price of the material” to define a price & the base of the material is not in the pricing field catalog. The base material is a field on the material master basic data screen and is defined as MARA-WRKST. Since this relates to the material, it is at the item level, so we  would add the field to the KOMPAZ include table. Note When you add a field to these tables, it must start with “ZZ.” & follow the basic coding standard. Therefore, you will be able to add field on ZWRKST.

 In ABAP, when we add any field, we use the same domain as in the field in the original table MARA-WRKST. After adding those fields, regenerate the structure KOMP


User Exits in Sales Order Processing

Sales Order Processing (Module Pool - SAPMV45A)

Include: MV45AFZZ

USEREXIT_DELETE_DOCUMENT ß (MV45AF0B_BELEG_LOESCHEN)
USEREXIT_FIELD_MODIFICATION ß (MV45AFFE_FELDAUSWAHL_LORD)
USEREXIT_MOVE_FIELD_TO_VBAK ß (FV45KFAK_VBAK_FUELLEN)
USEREXIT_MOVE_FIELD_TO_VBAP ß (FV45KFAK_VBAP_FUELLEN)
USEREXIT_MOVE_FIELD_TO_VBEP ß (FV45KFAK_VBEP_FUELLEN)
USEREXIT_MOVE_FIELD_TO_VBKD (Business Data) ß (FV45KFKD_VBKD_FUELLEN_TEIL_2)
USEREXIT_NUMBER_RANGE ß (MV45AF0B_BELEG_SICHERN)
Use this user exit to define the number ranges for internal document number assignment depending on the required fields. For example, if you want to define the number range depending on the sales organization (VKORG) or on the selling company (VKBUR), use this user exit.

Include: MV45AFZA

USEREXIT_MOVE_FIELD_TO_KOMKD (Header-Material Determination)
USEREXIT_MOVE_FIELD_TO_KOMPD (Item-Material Determination)
USEREXIT_MOVE_FIELD_TO_KOMKG (Header-Material Listing)
USEREXIT_MOVE_FIELD_TO_KOMPG (Item-Material Listing)
USEREXIT_REFRESH_DOCUMENT

Include: MV45AFZB

USEREXIT_CHECK_XVBAP_FOR_DELET
USEREXIT_CHECK_XVBEP_FOR_DELET
USEREXIT_CHECK_VBAK (Incompletion Check)
USEREXIT_CHECK_VBAP (Incompletion Check)
USEREXIT_CHECK_VBKD (Incompletion Check-Business Data)
USEREXIT_CHECK_VBEP (Incompletion Check, BOM Explosion-Schedule Line)
USEREXIT_CHECK_VBSN (Incompletion Check-Serial Number)
USEREXIT_CHECK_XVBSN_FOR_DELET
USEREXIT_FILL_VBAP_FROM_HVBAP
USEREXIT_MOVE_FIELD_TO_TVCOM_H (Text Determination for Header Texts)
USEREXIT_MOVE_FIELD_TO_TVCOM_I (Text Determination for Item Texts)
USEREXIT_CUST_MATERIAL_READ (To set another customer number in the customer material info record (e.g. with a customer hierarchy))
USEREXIT_NEW_PRICING_VBAP (Option for entry of preconditions for carrying out pricing again (e.g. changes made to a certain item field could be used as the precondition for pricing to be carried out again))
USEREXIT_NEW_PRICING_VBKD (Option for entry of preconditions for carrying out pricing again (e.g. changes to the customer group or price group could be set as the preconditions for the system to carry out pricing again))
USEREXIT_SOURCE_DETERMINATION (To determine which plant will be used for the delivery. In the standard system, the delivering plant is copied from the customer master or the customer-material info record. If you want to use a different rule, then you must enter it in this user exit))

Include: MV45AFZ4

USEREXIT_MOVE_FIELD_TO_KOMK (Header-Free Goods Determination)
USEREXIT_MOVE_FIELD_TO_KOMP (Item-Free Goods Determination)

Include: MV45AFZF


USEREXIT_AVAIL_CHECK_CREDIT (This user exit allows you to determine whether the system should or should not carry out an availability check after a blocked document has been released or after a new credit check)