Complaints Processing in SAP Sales & Distribution

Complaints Processing in SAP Sales & Distribution

Complaints Processing is a critical business processes in SAP Sales and Distribution Module. As soon as a complaint is received from a customer, one of several actions needs to be initiated, such as create a return sales order, issue replacement items or free of charge item and so on. The complaints processing functionality enables an end user to trigger actions based on a complaint received from a customer.

Different activities available under complaint processing sub process that can be broadly category under below area

• ·         Free-of-charge Delivery

            Just like a sample good issue by the business, shipping charge will not be charge to customer

•  Free-of-charge Subsequent Delivery

            Goods have been damaged in transit, So business will compensate with subsequent Delivery

• ·         Invoice Correction Requests

            Invoice correction request has been raise to correct quantity or price of any item

• ·         Releasing Complaints

            After reviewing term & condition, release for further processing

• Rejecting Complaints

            If evaluator find any inconsistency ,Reject for further clarification

Based on most relevant approach for the current situation, an appropriate sales document, with or without reference, can be created. The sales document can be automatically blocked from delivery or billing based on customizing settings.

Hence after the manual clarification of goods, the user can:-

• Accept the complaint and release the sales order
• Reject the complaint, and give a rejection code

Debit Memo Request

A Debit memo request is a sales document used in complaints processing to request debit for a customer.

You can create a debit memo request if the prices calculated for the customer were too low (for example, if the wrong scale prices were calculated). The debit memo request can be automatically blocked for checking. Once it has been approved, you can remove the block.

Credit Memo Request

A credit memo request is a sales document used in complaints processing to request credit for a customer.

If the price calculated for the customer was too high (for example, with the wrong scaled prices or because a discount was forgotten), you can create a credit memo request. The credit memo request can be automatically blocked for checking. Once it has been approved, you can remove the block.

AFS Route Determination configuration

1.    Define Routes and Stages

IMG à Enterprise Structure à Sales and Distribution à Basic Functions à Define Routes à Define Routes and Stages

• Enter Route, Description, select Shipping type and Factory calendar.

• Click on details
   to ensure that the values entered above are populated.

1.    Define AFS Route Determination in Purchase Order

IMG à Enterprise Structure à Sales and Distribution à Basic Functions à Define Routes à Define Routes and Stages

• Define Route:

Routes default from previous step. Transportation Lead Times are entered in this step (which are used in Ex-factory date calculations)

• Define Transportation Zones:

Routes default from previous step. Transportation Lead Times are entered in this step (which are used in Ex-factory date calculations)

• Define Route Determination

Assign the Route to the Transportation zone combinations.

Route Determination calculation rules

Route determine by the system based on the below parameter:

Firstly, Country of departure (taken from the shipping point)

Secondly consideration will Country of destination ( of the ship-to-party)

Third point is shipping condition (from customer master)

Forth, Transportation Group (from material master) and if any Weight group (optional)                                                                                      

In a nutshell ,

Route by which the delivery item is to be delivered to the customer

Routes can be pre defined in the system. These are dependent on:

•          Where the delivery comes from i.e. the country of the Vendor or manufacturer

•          Where the delivery is going to i.e. the plant or the customer address

•          Under what conditions the delivery is to take place i.e. Shipping conditions – via Road or Rail

Let’s understand Calculation rule for the Route determination

The route is calculated based on the following fields:

Determining the Origin:

The country, the Vendor, or the Manufacturer in conjunction with the following three fields from the vendor Informationrecords:

Transportation zone from which the goods are delivered

Transportation group

Shipping conditions like Sea or Air

In a procurement point view Determining the Destination:

This works in differently for the Direct Deliver and Non Direct PO’s:

In case of Direct Deliver PO’s, transportation zone of the customer and Country of the customer is derived from the customer master within SAP and inn case of Non Direct Deliver PO’s the transportation Zone and the country comes from the plant for which you wish to procure materials.

Based on the Origin, Destination and the shipping conditions defined in the Vendor Info Recs the system determines the route from the predefined set of routes in the configuration. Accordingly the delivery/ Ex factory dates are updated on the PO.

Item Category Determination in sales order

In Sales Document, Default item category propose by system automatically based on the below setting :-

Sales Documented Type  

Sales Document distinguishes different type of business processes represent in SAP system. Sales document type determines how the system process in sales processing

Item Categories group from Material Master

A group of material that have same Item categories. Based on this System automatically proposes an item category in the document. For example, Third party item Or Normal item

Item usages

This item usage indicator controls the system when you process a sales document item in a certain context For example. the any text items and packing items,

Higher Level Item categories  

 Higher Level Item categories influence main item category of the higher-level item determines the item category of related sub-items.

Based on the above data records system propose default item category for the document

Sales Documented Type  + Item Categories group from Material Master + Item usages + Higher Level Item categories  =Default item category 

Plant Determination in sales order

Plant Determination in sales order based on below three criteria

In Sales order processing screen system will try to find plant related data from the below sequence

1st Criteria:- Customer material info record (CMIR)

Transition Code:-VD51

We can maintain information for material, Material description quantity that are customer specific  !

If no records exits ..then system search CMR 

2nd Criteria :-Customer master records(CMR)

Customer master records are general data ,Company code data  & sales area data .Under the sales area data ,We can maintain propose plant for sales order 

Transition Code:-XD01/VD01

Navigate to Sales area Data as below 

Under shipping Tab we can specify Delivery priory,Shipping Condition & Propose Plant  

If no records exits ..then system search MMR

3rd Criteria:- Material Master Record 

Plant related information you can find it in Sales General /Plant data view 

Go To Transation Code -MM01..

we can also specify propose shipping point in Material Master as below 

Base On the records ,System propose delivery plant in sales Order ..!!!!! 

Billing related User Exits

Find some useful Billing related User Exits .

We can use as a Enhancement to meet customer specify requirement

Billing related exits

SDVFX001-This User exit header line in delivery to accounting 

SDVFX002 -This User exit for A/R line in transfer to accounting

 SDVFX003-This User exit cash clearing in transfer to accounting

 SDVFX004-This User exit G/L line in transfer to accounting

 SDVFX005-This User exit reserves in transfer to accounting

SDVFX006-This User exit tax line in transfer to accounting

SDVFX007-This User exit: Billing plan during transfer to Accounting

 SDVFX008-This User exit: Processing of transfer structures

SDVFX009-This users exits use in Billing doc. processing KIDONO (payment reference number)

 SDVFX010-This User exit  use item table for the customer lines

SDVFX011 Userexit for the komkcv- and kompcv-structures

V05I0001 --This User exits for billing index V05N0001 User Exits for Printing Billing Docs. using POR Procedure

V60A0001 -This users exits Customer functions in the billing document

V60P0001 --This users exits use in Data provision for additional fields for display in lists

 V61A0001 -This Customer enhancement: Pricin

Delivery related User exits

Find some useful Delivery related User Exits .

We can use as a Enhancement to meet customer specify requirement

Delivery related exits

V50PSTAT-This is use for  Delivery: Item Status Calculation

V50Q0001 -This is use for Delivery Monitor: User Exits for Filling Display Fields

V50R0001-This is use for Collective processing for delivery creation

V50R0002-This is use for Collective processing for delivery creation

V50R0004 -This is use for Calculation of Stock for POs for Shipping Due Date List

V50S0001 -This is use for User Exits for Delivery Processing

V53C0001 -This is use for Rough workload calculation in time per item

V53C0002 -This is use for W&S: RWE enhancement - shipping material type/time slot

V53W0001-This is use for User exits for creating picking waves

VMDE0001 -This is use for Shipping Interface: Error Handling - Inbound IDoc

VMDE0002 -This is use for Shipping Interface: Message PICKSD (Picking, Outbound)

VMDE0003 -This is use for Shipping Interface: Message SDPICK (Picking, Inbound)

VMDE0004 -This is use for Shipping Interface: Message SDPACK (Packing, Inbound)

V02V0001-This is use for Sales area determination for stock transport order

V02V0002 -This is use for User exit for storage location determination

V02V0003 -This is User exit for gate + matl staging area determination (headr)

V02V0004 -This is User Exit for Staging Area Determination (Item)

Sales related User exits

Find some useful sales related User Exits .

We can use as a Enhancement to meet customer specify requirement

Sales related User exits

User exits SDAPO001 being use for Activating Sourcing Subitem Quantity Propagation

User exits SDTRM001 being use for Reschedule schedule lines without a new ATP check

User exits V45A0001 being use for Determine alternative materials for product selection

User exits V45A0002 being use for Predefine sold-to party in sales document

User exits V45A0003 being use for Collector for customer function modulpool

User exits V45A0004 being use for Copy packing proposal

User exits V45E0001 being use for Update the purchase order from the sales order

 User exits V45E0002 being use for Data transfer in procurement elements (PRreq., assembly)

User exits V45L0001 being use for SD component supplier processing (customer enhancements)

User exits V45P0001 being use for SD customer function for cross-company code sales

User exits V45S0001 being use for Update sales document from configuration

User exits V45S0003 being use for MRP-relevance for incomplete configuration

User exits V45S0004 being use for Effectivity type in sales order

User exits V45W0001 use for SD Service Management: Forward Contract Data to Item

User exits V46H0001 being use for SD Customer functions for resource-related billing

User exits V60F0001 being use for SD Billing plan (customer enhancement) diff. to billing plan

BAPIs realted to SD Module

BAPI –Bapi  in long text -Business Application Programming Interface and has the role as communication platform.

Which can use as developing application .More over This Commonly a function module that is normally RFC enabled as well and acts as a method of a business object.

We can implement below Bapi based on requirement 

BAPI_SALESGROUP_GET_DETAIL –This is use for Sales Group Name display

BAPI_SALESOFFICE_GET_DETAIL –This is use for Sales Office Display Name…..

BAPI_SALESOFFICE_GRP_EXIST –This is use for Sales Office or Sales Group Check….

BAPI_SALESORG_EXIST –This is use for Sales Organization Check

BAPI_SALESORG_GET_DETAIL–This is use for Sales Organization Display Data..

BAPISDORDER_GETDETAILEDLIST –This is use for List of All sales Order Data..

BAPI_ORDER_CHANGE_STATUS_GET –This is use for Change status for Sales order..

BAPI_SALESDOCU_CREATEFROMDATA –This is use for Creating a Sales Document ..

BAPI_SALESORDER_CHANGE Sales Order: –This is use for Change Sales Order…

BAPI_SALESORDER_CREATEFROMDAT1 –This is use for Sales Order: Create Sales Order..

BAPI_SALESORDER_CREATEFROMDAT2 –This is use for Sales Order: Create Sales Order..

BAPI_SALESORDER_CREATEFROMDATA –This is use for Create sales order, no more maintenance..

BAPI_SALESORDER_GETLIST –This is use for Sales order List of all orders for customer..

BAPI_SALESORDER_GETSTATUS –This is use for Sales order: Display status..

BAPI_SALESORDER_SIMULATE Sales Order–This is use for Simulate Sales Order..

SD Integration points with Other Module

Sales Order –           Integration Points Module

•Availability Check -         MM

•Credit Check -               FI

•Costing -                    CO/ MM

•Tax Determination -          FI

•Transfer of Requirements -   PP/ MM

Delivery & Goods Issue – Integration Points Module

•Availability Check -         MM

•Credit Check -               FI

•Reduces stock -              MM

•Reduces Inventory $ -        FI/ CO

•Requirement Eliminated -     PP/ MM

Billing -                 Integration Points Module

•Debit A/R -                  FI/ CO

•Credit Revenue -             FI/ CO

•Updates G/ L -               FI/ CO

(Tax, discounts, surcharges, etc.)

•Milestone Billing -          PS

Return Delivery & Credit Memo - Integration Points Module

•Increases Inventory -        MM

•Updates G/ L -               FI

•Credit Memo -                FI

•Adjustment to A/R -          FI

•Reduces Revenue -                                           

Cut over strategy in SAP

Cutover strategy is a planing ,How data load will be perform in production client before Go Live !

Normally, you decide the sequence of Data loads for Configuration settings, Master data, Transaction data which follows whom and then you make a copy of the system as a Production system a day before and after checking the successful data load

Cutover strategy depends upon how the organizations design their data load strategies

There are several way to perform cut over activity.

Go-live 100% or partial again depending upon organizational setup, policies & data volume.

Lets look in to this ...

Cutover strategy depends upon how the organizations design their data load strategies. Normally, you decide the sequence of Data loads for Configuration settings, Master data, Transaction data which follows whom and then you make a copy of the system as a Production system a day before and after checking the successful data loads, 

Cutover planning is highly site specific. There's no thumb rule. The stock data as on the date of going live should be correctly entered. But stock being a highly dynamic quantity, the strategy for loading should be crystal clear. Then you have to load all the back dated transaction on the stock. Some stock comes into your plant/storage location as return and some stock is actually delivered to your customer through sales orders of various kinds. The final phase before going live with SAP is often referred to as the cutover phase, which is the process of transitioning from one system to a new one. The organization needs to plan, prepare and execute the cutover, by creating a cutover plan that describes all cutover tasks that have to be performed before the actual go-live. Examples of cutover tasks are: Review and update all systems-related operations procedures like backup policies and system monitoring Assign ownership of SAP’s functional processes to individuals Let SAP AG do a Going Live check, to get their blessing to go live with the system Lock down the system, i.e. do not make any more changes to the SAP system

Cut-Over Activities: 

Cutover Plan - The details of how to move to the production environment and go live. Ensuring that all master data to be loaded to production server is ready & in correct format. User training is conducted & user is in a comfort or at least manageable position to work on production server. Preparation of user manual. All go-live preparatory activities.

Open Client activity: The activity or configuration to be done in production server, by opening an client should be ensured that it is done before go-live. We must request to Basis team for opening production client for certain periods once  .On that time all user will block by basis team  & system will not accessable .Cutover activity finished Basis will be close production client

Cutover Activities At the end of Phase 4, it is necessary to refine and validate the cutover plans generated in the Realization phase. Among other things, this includes tasks such as the reviewing of the runtime of test runs to estimate runtime for the complete data size. A conversion checklist for transporting all changes into the productive system is provided for all the configuration settings to be imported. At this stage, it is important to verify that required tasks have been successfully completed, for example, that the technical environment is in place, the cutover programs are ready and the application data is verified. Approval is now sought from project management and company senior management to start the cutover process.

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