Sap Sd Document

FUNDAMENTALS BY Mohammed Imran Ahmed

Contents INTRODUCTION ............................................................................................................................................. 1 Introduction to SAP ................................................................................................................................... 1 Architecture of SAP ............................................................................................................................... 1 The SAP GUI .......................................................................................................................................... 2 SAP Basics.................................................................................................................................................. 4 Basic Transaction Codes ........................................................................................................................ 4 Shortcuts in Transaction Codes............................................................................................................. 5 Match code ............................................................................................................................................... 8 The Matrix Copy ........................................................................................................................................ 9 Exercise ................................................................................................................................................... 10 Organizational Structure in SAP SD............................................................................................................. 12 Enterprise Definition ............................................................................................................................... 12 1.

Company Code: ........................................................................................................................... 16

2.

Sales Organization:...................................................................................................................... 18

3.

Distribution Channel: .................................................................................................................. 21

4.

Division:....................................................................................................................................... 23

5.

Sales Area: ................................................................................................................................... 25

6.

Sales Office: ................................................................................................................................. 25

7.

Sales Group: ................................................................................................................................ 26

8.

Business Area: ............................................................................................................................. 27

9.

Plant: ........................................................................................................................................... 29

10.

Storage Location: .................................................................................................................... 31

11.

Shipping Point: ........................................................................................................................ 32

12.

Regions: ................................................................................................................................... 35

13.

Calendar: ................................................................................................................................. 36

Relationship between Various Units of Enterprise ................................................................................. 37 Enterprise Assignment ............................................................................................................................ 39 1.

Sales Organization to Company Code: ........................................................................................ 41

2.

Distribution Channel to Sales Organization: ............................................................................... 41

3.

Division to Sales Organization:.................................................................................................... 42

4.

Set up Sales Area:........................................................................................................................ 42

5.

Sales Office to Sales Area: ........................................................................................................... 43

6.

Sales Group to Sales Office: ........................................................................................................ 44

7.

Sales Area to Business Area: ....................................................................................................... 45

8.

Plant to Company Code: ............................................................................................................. 47

9.

Plant to Sales Organization and Distribution Channel: ............................................................... 48

10.

Shipping Points to Plant: ......................................................................................................... 49

Common Distribution Channels and Divisions ........................................................................................ 50 Define Common Distribution Channels .............................................................................................. 50 Define Common Divisions ................................................................................................................... 51 Exercise ................................................................................................................................................... 52 Master Data ................................................................................................................................................ 54 Customer Master Data ............................................................................................................................ 54 Account Group .................................................................................................................................... 55 Creating Number Ranges .................................................................................................................... 58 Assigning Number Range to Account Group: ......................................................................................... 59 Partner Determination Procedure ...................................................................................................... 60 Creating Customer .................................................................................................................................. 66 Extending the Customer to New Sales Area ........................................................................................... 83 Material Master Data .............................................................................................................................. 86 Creating The Material ......................................................................................................................... 86 Customer Material Information Record ................................................................................................. 96 Conditions Record Maintenance .......................................................................................................... 100 Maintaining Condition Records Using Condition Type ..................................................................... 101 Questions and Exercises ....................................................................................................................... 109 Sales Document Processing ...................................................................................................................... 111 Creating Basic Sales Order .................................................................................................................... 112 Structure of a Sales Order ..................................................................................................................... 119 The Origin of Data in the Sales Document ............................................................................................ 123 Status of the Sales Document ............................................................................................................... 123 Controlling the Data in Sales Document ............................................................................................... 124 Sales Document Type ........................................................................................................................ 124 Item Category.................................................................................................................................... 133

Schedule Line Category ..................................................................................................................... 138 Questions and Exercises ....................................................................................................................... 142 Copy Control ......................................................................................................................................... 145 Special Sales Document Types .............................................................................................................. 154 The Inquiry ........................................................................................................................................ 154 The Quotation ................................................................................................................................... 154 The Cash Sale Process ....................................................................................................................... 156 The Rush Order Process .................................................................................................................... 157 The Credit Process ............................................................................................................................ 157 The Debit Process.............................................................................................................................. 159 Invoice Correction Request ............................................................................................................... 161 The Returns Process .......................................................................................................................... 162 Differences between Cash Sales and Rush Order ............................................................................. 163 Item Proposal ........................................................................................................................................ 164 Creating Item Proposal ..................................................................................................................... 164 Using Item Proposal in Sales Order................................................................................................... 166 PRICING ..................................................................................................................................................... 169 Why is Condition Technique Used ........................................................................................................ 170 1.

Condition Tables ....................................................................................................................... 171

2.

Access Sequence ....................................................................................................................... 177

3.

Condition Types ........................................................................................................................ 182

4.

Pricing Procedure Definition ..................................................................................................... 191

5.

Pricing Procedure Determination ............................................................................................. 200

Optimizing Performance in the Condition Technique .......................................................................... 204 SAP Pricing Header Condition type vs. Item Condition Type ................................................................ 205 Activate Pricing for Item Categories ..................................................................................................... 208 Condition Exclusion Groups .................................................................................................................. 210 Defining Condition Exclusion Groups................................................................................................ 211 Assigning Condition Types to Exclusion Groups ............................................................................... 212 Maintain Condition Exclusion for Pricing Procedures....................................................................... 212 Creating New Price List Type in SAP ..................................................................................................... 215 Condition Supplements......................................................................................................................... 217

Changing Condition Records Using Condition Type.............................................................................. 217 Creating Condition Records with Template Using Condition Type....................................................... 222 The Condition Record Change Log ........................................................................................................ 223 Questions and Exercise ......................................................................................................................... 225 Special Processes Using the Pricing Condition Technique ........................................................................ 229 Free Goods Determination ................................................................................................................... 229 Inclusive Free Goods ......................................................................................................................... 229 Exclusive Free Goods ........................................................................................................................ 229 Free Goods Configuration ................................................................................................................. 230 Setting up Inclusive Free Goods Condition Records ......................................................................... 238 Setting up Inclusive Free Goods Condition Records without Item Generation ................................ 242 Setting up Exclusive Free Goods Condition Records......................................................................... 244 Material Listing and Exclusion .............................................................................................................. 248 Maintain Condition Records for Material Listing and Exclusion ....................................................... 255 Material Determination ........................................................................................................................ 260 Cross Selling .......................................................................................................................................... 272 Maintaining Condition Technique for Cross Selling .......................................................................... 272 Contracts and Agreements ....................................................................................................................... 281 Contracts ............................................................................................................................................... 281 Quantity Contract ............................................................................................................................. 281 Service Contract ................................................................................................................................ 282 Master Contract ................................................................................................................................ 283 Value Contract .................................................................................................................................. 284 Configuration for Contracts .............................................................................................................. 286 Contract Profile ................................................................................................................................. 288 Assortment Module .......................................................................................................................... 292 Outline Agreements .............................................................................................................................. 294 Scheduling Agreement ...................................................................................................................... 294 Configuring Scheduling Agreement .................................................................................................. 294 Creating Scheduling Agreement ....................................................................................................... 300 Item Category Determination for Scheduling Agreement and Contracts ............................................ 302 Exercises ................................................................................................................................................ 302

Status Profile ......................................................................................................................................... 303 Incompletion Procedure ....................................................................................................................... 312 Available to Promise and Transfer of Requirements ................................................................................ 318 Posting Stock in Plant ............................................................................................................................ 318 Materials Requirements Planning and Transfer of Requirements ....................................................... 329 Individual or Collective Requirements .............................................................................................. 330 Transfer of Requirements ................................................................................................................. 332 Configuring the Transfer of Requirements ....................................................................................... 337 Maintaining Requirements for Transfer of Requirements ............................................................... 343 Availability Check .................................................................................................................................. 345 Terminology Used in the Availability Check...................................................................................... 345 Basic Elements of the Availability Check........................................................................................... 346 Configuring the Availability Check with ATP Logic ............................................................................ 349 Delivery ..................................................................................................................................................... 358 Delivery Process .................................................................................................................................... 358 Delivery Document Configuration .................................................................................................... 358 Defining Delivery Types..................................................................................................................... 358 Functionality of Delivery Document Types ....................................................................................... 360 Delivery Item Categories and Determination ................................................................................... 362 Defining the Delivery Item Category ................................................................................................. 362 Functionality of Delivery Item Category ........................................................................................... 363 Defining Delivery Item Category Determination .............................................................................. 365 Shipping Point Determination........................................................................................................... 365 Configuring the Shipping Point Determination................................................................................. 367 Defining Loading Groups ................................................................................................................... 368 Delivery Creation Process ..................................................................................................................... 369 Creating a Delivery With Reference to Sales Order .......................................................................... 369 Collective Processing of Orders due for Delivery.............................................................................. 372 Creating Partial Deliveries ................................................................................................................. 372 Picking and Interfacing with Warehouse Management ....................................................................... 373 Item Categories Relevant for Picking ................................................................................................ 373 Interface with Warehouse Management.......................................................................................... 373

Picking Requirements ....................................................................................................................... 375 Determine Storage/Picking Locations............................................................................................... 375 Defining Rules for Picking Location ................................................................................................... 375 Define Storage Conditions ................................................................................................................ 376 Backward and Forward Scheduling ....................................................................................................... 378 Delivery Blocks ...................................................................................................................................... 379 Blocking Reasons............................................................................................................................... 379 Delivery Blocking at Header Level..................................................................................................... 381 Delivery Blocking at Schedule Line Level .......................................................................................... 382 Delivery Blocks at the Customer/Header Level ................................................................................ 383 Packing .................................................................................................................................................. 384 Packing by Item Category ................................................................................................................. 384 Packing Requirements ...................................................................................................................... 385 Returnable Packaging ....................................................................................................................... 386 Special Stock ..................................................................................................................................... 386 Special Stock Partners ....................................................................................................................... 388 Posting Goods Issue in the Delivery ...................................................................................................... 388 Consignment Sales ................................................................................................................................ 389 Process Flow of Consignment Sales ...................................................................................................... 390 Route Determination ............................................................................................................................ 395 Defining Routes ................................................................................................................................. 395 Maintaining Route Determination .................................................................................................... 401 Billing ......................................................................................................................................................... 403 Billing Process ....................................................................................................................................... 403 Defining Billing Document Types ...................................................................................................... 403 Functionality of Billing Type .............................................................................................................. 404 Special Billing Document Types ............................................................................................................ 405 Pro Forma Invoice ............................................................................................................................. 405 Cancellation Invoice .......................................................................................................................... 405 Copy Control for Billing Documents...................................................................................................... 408 Invoice Lists ........................................................................................................................................... 412 Billing Plans ........................................................................................................................................... 414

Defining Billing Plan Types ................................................................................................................ 414 Rebate Agreements .............................................................................................................................. 421 Configuring Rebates .......................................................................................................................... 421 Maintaining Condition Technique for Rebates ................................................................................. 421 Defining Rebate Agreement Types ................................................................................................... 424 Functionality of Rebate Agreement Types........................................................................................ 424 Condition Type Groups ..................................................................................................................... 425 Assigning Condition Type/Table to Condition Type Groups ............................................................. 426 Assigning Condition Type Groups to Rebate Agreement Types ....................................................... 427 Creating Rebate Agreement ............................................................................................................. 428 Managing Rebate Agreements and Payments.................................................................................. 430 Making the Rebate Payment to the Customer ................................................................................. 431 Retroactive Rebate Processing ............................................................................................................. 431 Payment Terms ..................................................................................................................................... 432 Configuring Payment Terms.............................................................................................................. 432 Inter-Company Sales ............................................................................................................................. 434 Inter-Company Stock Transfer .......................................................................................................... 435 Defining Order Types for Inter-Company Sales Transaction ............................................................ 435 Assigning Organizational Units by Plant ........................................................................................... 436 Defining the Internal Customer Number by Sales Organization....................................................... 437 Processing an Intercompany Sale ..................................................................................................... 438 Determinations ......................................................................................................................................... 439 Tax Determination ................................................................................................................................ 439 Defining Tax Determination Rules .................................................................................................... 439 Defining Regional Codes ................................................................................................................... 440 Assigning Delivering Plants for Tax Determination........................................................................... 442 Defining Tax Relevancy of Master Records-Customer Taxes............................................................ 442 Defining Tax Relevancy of Master Records-Material Taxes.............................................................. 443 VAT Registration Number in Sales and Billing Documents ............................................................... 444 Tax Condition Records ...................................................................................................................... 445 Tax Integration with Financial Accounting........................................................................................ 446 Revenue Account Determination.......................................................................................................... 448

Sales Incompletion Logs ........................................................................................................................ 455 Text Determination ............................................................................................................................... 458 Output Determination .......................................................................................................................... 471 Credit Management .................................................................................................................................. 485 What is Credit Management ................................................................................................................. 485 Types of Credit Management ............................................................................................................... 486 Simple Credit Check .......................................................................................................................... 486 Dynamic Credit Check ....................................................................................................................... 487 Organizational Structures & Master Data ............................................................................................. 488 Customization Settings for Credit Management in SD ......................................................................... 492 Maintaining Credit Limits for Customers .............................................................................................. 494 Questions .............................................................................................................................................. 503 Blocking Customers............................................................................................................................... 505 Defining Shipping Blocks ................................................................................................................... 506 Defining Order Blocks ....................................................................................................................... 509 Defining Billing Blocks ....................................................................................................................... 510 Miscellaneous Topics ................................................................................................................................ 511 Third Party Sales Processing ................................................................................................................. 511 Factory Calendars ................................................................................................................................. 518 Standard SD Reports in SAP ...................................................................................................................... 523 Commonly Used Transaction Codes in SD ................................................................................................ 524 Commonly Used Tables in SAP SD ............................................................................................................ 527 SAP System Landscape .............................................................................................................................. 529 ASAP Methodology ................................................................................................................................... 532 Most Common Errors, Scenarios and Their Resolution ............................................................................ 536

1

INTRODUCTION Introduction to SAP SAP was founded in 1972 in walldorf, Germany. The name is an acronym for “systeme, Anwendungen, Produkte in der Datenverabeitung,” meaning “Systems, Applications and Products in Data Processing.” SAP is in a consistent state of change with over 9,000 developers and researchers adapting it to the market and striving to offer consistently better business solutions. As a result, this company is the world’s leading enterprise resource planning software provider. The latest release of mySAP ERP is SAP ERP Central Component (ECC6). Within mySAP ERP there are a number of applications, such as Financials and Manufacturing. Of these applications we are focusing on the Sales and Distribution application. mySAP ERP is built on the SAP Netweaver platform, which is an open source business process platform that permits customers to create among other things, tailor-made business solutions. mySAP ERP is an application that is designed for mid-size to large customers. SAP is an ERP software product that seamlessly integrates the different functions in a business (such as sales, procurement, and production). SAP provides rich functionality in each of these business areas without sacrificing the convenience if an integrated system. These applications update and process transactions in real time, allowing seemingly effortless integration and communication between areas of a business. For example, you can create a billing document and release it to Accounting and observe the updated billing values in a customer analysis immediately without having to wait for day-end or month-end processing.

Architecture of SAP The first release of SAP was in R/2 (Real-time/2 Tier). The 2 tiers (layers) were Application and Database layers. Later, R/3 ((Real-time/3 Tier) version was released in 1990s. The 3 tiers are (a) Presentation, (b) Application and (c) Database Layers. The Presentation layer is the front end that you see, input and display on the terminal SAP has developed and used its own presentation layer called SAP GUI. The Application layer contains the programs that work between the presentation layer and the database layer. It retrieves data from the database layer, manipulates the data and puts

2 back to the database layer. SAP has developed and used its own programming language called ABAP (Advanced Business Application Programming) for writing the SAP codes. It is a 4 GL language. The Database layer is the database where the data is stored and retrieved by the application layer. The main databases supported by SAP are Oracle, DB2, and Informix etc.

The SAP GUI The SAP Graphical User Interface or SAP GUI runs on all well-known operating systems. The appearance of the screens and the menus displayed on them are configurable. In ECC there are numerous SAP GUIs

SAP R/3 Login Menu: When you login to SAP R/3 Version 6.0, you will get the following menu.

The status bar provides general information on the SAP System and transaction or task you are working on. At the left of the status bar, system messages are displayed. The right end of

3 the status bar contains three fields: one with server information, the other two with status information. This view is called SAP Easy Access view, shortly EA. You can come back to this view from anywhere in the system by entering \n or S000 in the command field. This S000 is the transaction code (T-code) for EA view. Like this you can enter various T-codes in the command field to execute various transactions directly. You can open up to 6 sessions at a time. If you know the T-code of a transaction you can go open another session and go to that transaction by entering \O and the T-code of that transaction directly. For example, if you enter \OVA01, system will open a new session and open the transaction sales order creation [VA01]. Similarly, you can go to another mode of view called IMG (Implementation Guide) where most of the implementation settings for the enterprise are done. If you enter SPRO at the command field of EA view and then click on “SAP Reference IMG”, you get the following IMG screen:

If you enter ‘\n’ at the command field you will go back to EA view.

4 SAP Basics This section is a guide to navigation and usability of an SAP system from transaction codes to user settings and the matrix copy.

Basic Transaction Codes Transaction codes are the shortest path to a specific screen in SAP. For example, when you type the transaction code “VA01” in the command field navigates you to the Sales Order screen. To view the transaction code from within the screen you are accessing, select SystemStatus. The T-codes are represented in square brackets to identify them. Here are a number of simple transaction codes you will get accustomed to using: Code VA01 VL01N VF01 SPRO

Description Create Sales Order Create Outbound Delivery with Reference Create Billing Document Enterprise SAP Customizing Implementation Guide

A fantastic navigation tip is to use central “Easy Access” Menus, which provide a menu tailored to the function you are processing. For example, all transactions related to sales master data can be found by using [VS00]. Refer to following list for transaction codes to further menus. Code VS00 VC00 VA00 VL00 VT00 VF00 VX00

Description Sales Master Data Sales Support Sales Shipping Transportation Billing Foreign Trade

Naturally there are thousands of such codes and it would be irrelevant to list them all. However, if anyone is looking for a specific transaction code, a time-saving tip is to use [SE16N] with table TSTC. To get a list of transactions including a particular text string, use the table TSTCT. Note that as transaction codes call up screens, there must be a link from the screen you are trying top access to the relevant screen you wish to call. You will not be able to use the

5 Transaction code [VA00] while in the SAP Customizing Implementation Guide because the screen related to [VA00] is not available from within this transaction. A tip in cases like this is to enter /n before the transaction code. For example [/nVA00] will take you out of whatever transaction you are in to the VA00 screen. The /n terminates the transaction you are working with, so be aware that you will lose any unsaved data in the screen you are currently on. As an alternative, you can use /o in front of the transaction code (for example, [/oVA00]). This opens the transaction in a new SAP session, keeping your existing screen in place.

Shortcuts in Transaction Codes To save time in transfers between screens when you call up transaction, you can utilize the shortcut commands. The following function keys allow for additional shortcuts: F1 F3 F4 F8

Help Back Lists possible entries or match code for the field you are accessing Executes a transaction or report

These function codes are to be used from a specific field. For example, from the customer group field Pressing F1 gives you Help screen as shown in below figure.

6

The Help dialog box may be displayed differently based upon the user settings. To change the display options of the Help screen, select the menu from SAP Easy Access screen [S000] HelpSettings as seen in below figure.

7 In the above screen if we choose the option as “In Modal Dialog Box” option then Help screen appears as shown in below figure.

Shortcut Description /n Ends the Current Transaction

/nxxxx /i /nend /nex /o /oxxxx

Moves you from anywhere into transaction xxxx. Note, however, that you are terminating the current screen and will lose any unsaved data Deletes the current session Logs off from the system Logs off from the system without a confirmation prompt Opens a new session Opens transaction xxxx in a new session

From the Help screen, pressing F9 or click the Technical Info button, depending on your display option, will give you the technical information screen as given below.

8

Match code A match code is a comparison key. It allows you to locate the key of a particular database record by entering a field value contained in the record. The system then displays a list of records matching the specifications for you to select from. An example of this would be searching for the customer number in the sales order. When you press F4 from within the customer number field, you will have an option to select a suitable match code to obtain the customer number you are after as shown in below figure.

9

The Matrix Copy The copy and paste function in SAP is called the Matrix Copy. Use the Matrix Copy to copy more than one line of text by clicking on the dialog box or screen one wish to copy from and pressing the commands as described: 1. Press CTRL-Y and then select the text by dragging the mouse from the top left to the bottom right of the selection. 2. Once the text is highlighted, press CTRL-C 3. Insert the text by moving to the new location and pressing CTRL-V

10 Exercise SAP GUI Navigation 1. How do you find out the client you have logged on to? 2. How to open a new log on session? 3. How many simultaneous SAP Log on sessions are allowed? 4. How to bookmark a transaction as a Favorite? 5. How to find out the current transaction code? 6. What is a Transaction code? 7. What is the use of a Status Bar? 8. How to get ‘help’ on a field on the SAP GUI? 9. Can you log in without specifying the client number? 10. What is meant by Matchcode in the system?

Business Example Task 1: What is the name of the following function accessed via the standard SAP menu and what transaction code do you use to start this function? Path: SAP Easy AccessToolsAdministrationMonitorSystem MonitoringUser Overview Name of function: _________ Transaction code: _________

Task 2: Default user-specific settings by choosing SystemUser ProfileOwn Data 1. Set the logon language to the one used on your course 2. Specify the decimal notation you require and the appropriate data format

Task 3: Maintain your personal favorites 1. Create at least one new folder in the favorites folder 2. Add two of your favorite transactions to this folder 3. Add the Internet address http://www.sap.com under the title “SAP Homepage”

11 Task 4: Define a start transaction in the “Extras” Menu 1. Set a transaction of your choice as the start transaction. Once you have done this, you must log off and then log on again to activate this change. Hint: If required, you can restore the original start transaction by simply deleting your entry

Task 5: What is the maximum number of sessions (windows in the SAP system) that you can open simultaneously?

Task 6: The help functions 1. Use either the system menu or enter transaction code SU3 to call up the screen in which you can maintain your own user data. Call up the F1 Help for a selection of fields here. Choose Technical Information to find the parameter ID for the Logon Language field. Parameter ID: __________ Call up the F4 Help for the Logon Language field. What is the language key for Ukrainian? Language key: __________ 2. Display the transaction code for the current transaction in the status bar.

12

Organizational Structure in SAP SD SAP is an ERP (Enterprise Resource Planning) system and hence we have to setup the Enterprise very carefully. Hence, a thorough study about the enterprise is to be done before defining various units of Enterprise and interlinking them together. In fact the Organization (the organization in which SAP is being implement) should have selected the appropriate module (R/3 or industry specific solutions such as IS-Oil, IS-Retail etc) based on their business nature. For making Sales Transactions, we have to create the Enterprise Set up, Master Data, Pricing and Determinations. Hence, first we will make the set up ready before we make sales transactions. The set up are done based on the version ECC 6.0

Enterprise Definition We will setup our Enterprise structure to understand the basic function of SAP SD. The Enterprise setup begins with IMG view. We have to define organizational units first and then link these organization units in Enterprise Assignment. We are setting up only one set of data to explain about the entire process. You can define more data later. Before discussing the same, let’s look at another pictorial representation of the same picture as above – but with GE’s org units.

13

Company GE Medicals is the name of the company. This company has presence across the world. And when GE Healthcare declares profits in the US, it is not just including the US Company but the entire world. In SAP parlance, GE Medicals is a Company.

Company Code GE Medicals in the US will be run through a legal entity. A company code is an entity that has to report its financials to the government on a timely basis. For example an incorporated entity can be called a company code. In this case, GE Medicals in the US is being called as a legal entity.

Sales Organization Since the company has presence across the US; there will be sales organizations across the United States responsible for selling goods. For example, the Western division is responsible for selling goods in the Western states. The same organization is also responsible for handling returns, credits, availability of materials etc.

Distribution Channel

14 Just as the name speaks; a distribution channel is the sales channel through which products are distributed. In this case, the medical equipment could be sold through the direct channel or through an agency. Each of them will be represented as a distribution channel. A more common example could be Retail or Wholesales

Division Division is purely related to the product/service we are selling. It’s a grouping of our products. For example all different types of X-Ray machines would fall under the X-Ray division.

Sales Office The western division of the company might be having multiple sales offices in California. For example there could be one in the bay area and another in Los Angeles

Sales Group Each sales office contains multiple sales groups who have a fixed set of responsibilities. It could be based on the products that they sell or the type of sales that they perform or the role they play in the actual sale. For example, a sales group could be responsible for selling consumables used in the X-Ray while the field-apps will be responsible for selling the software used in the machines.

Plant A plant is where goods are manufactured. Sometimes, you might not even manufacture anything – Just trade goods. Still you would need a plant. So a plant could be a physical or virtual place where goods are manufactured or stored at a high level. For example, there could be a plant in New Jersey.

Storage Location Each plant could be associated with multiple storage locations – A place where goods are stored before being sold. For example, the New Jersey plant could have storage locations in Edison and Iselin.

Warehouse A warehouse is an extension of the storage location. While a storage location represents a location where goods are stored, a warehouse goes much further and describes how the goods are sold, the topography of the storage, storage conditions etc. Goods can still be sold without using Warehouse Management, but a sale cannot happen without a storage location.

15 The first step before doing the configuration is to assess the requirement as to how the company is organized and how best it can be represented in SAP. Each company is run in a different way. Since SAP’s enterprise structure is rigid, you might have to try different things to fit their organization’s model into SAP’s org structure. After you have fully understood the organizational units in the company, start by defining those in SAP. The following picture shows the path of the enterprise structure definition in IMG. While the Company and company codes are defined by FICO consultants, the ones highlighted in red below are absolutely necessary for the functioning of the SAP Sales & Distribution Module. In Enterprise Definition menu, we will define the following Enterprise Units in IMG view:

16 1. Company Code: It is the legal entity which takes care of all the business transactions in company. The Company Code is an organizational unit used in accounting. It is used to structure the business organization from a financial accounting perspective.

Note: Company Code is defined in Finance Module.

Defining Company Code Path: SPROIMGEnterprise StructureDefinitionFinancial AccountingEdit, Copy, Delete, Check Company Code

17 Company Codes are to be copied from an existing one because of copying a lot of standard set ups. Choose the first option “Copy, Delete, Check Company Code”. When you select the first option, you will get the following blank screen:

In this blank screen click on copy button (2nd button in application toolbar) Select the Source Company Code as 1000, a standard existing company in the system and the target Company Code as “DELL” Note: Note down the source company code for future purposes. For example, it is needed to maintain currency conversion from the Source Currency to Target Currency. Profit and Loss statements are taken according to Company Codes

18 Say Yes when asked for Copying General Ledger account. Say Yes, for change of currency if Target Company’s currency is different from that of Source Company then enter the new currency. Currency of Source Company 1000 is EUR and currency of Target Company DELL is INR (Indian Rupees). Like this, say yes for all other standard messages that appear. Go back to the previous screen and select the 2nd option “Edit Company Code” and edit the Company Code “DELL” for additional data as shown in below screen.

2. Sales Organization: It is the responsible organizational element which takes care of the entire Sales Transactions

(Buying and Selling of Product, Negotiating terms of sales, sales policies etc) taking place in the company. The responsibilities of a Sales Organization include legal liability of products and customer claims.

19

It is always a recommended practice to define one Sales Organization defined for one Company Code, but in some cases where the territory of sales is too large; there may be more than one Sales Organization for a Company Code. For Example, Sales South, Sales North, Sales Export etc. At least one Sales Organization must be defined in SD. Each Sales Organization has its own master data such as customer and material masters.

Defining Sales Organization: Path: SPROIMGEnterprise StructureDefinitionSales and Distribution Define, Copy, Delete, Check Sales Organization

Select the first option “Define Sales Organization”

20 Select the “New Entries” Button and Specify the name of Sales Organization, Currency and Calendar.

If the sales organization is offering rebates for customers, we have to check the field “Rebate

Process Active”. Select the Address Icon and specify the required data.

Save the Sales Organization.

21 3. Distribution Channel:

Distribution Channel is the medium through which the product or service reaches the customers. Example: Wholesale, Retail, Direct Sales etc. Distribution Channel is mandatory in SD. Distribution Channel is mainly used for pricing purpose. Note: Within a sales organization you can deliver goods to a given customer through more than one Distribution Channel

Defining Distribution Channel: Path: SPROIMGEnterprise StructureDefinitionSales and Distribution Define, Copy, Delete, Check Distribution Channel

22

Select the first option “Define Distribution Channel” Select the “New Entries” Button and Specify the name of Distribution Channel

For test case scenario we have defined 2 Distribution Channel as DR (Dell Retail) and DW (Dell Wholesale)

23 4. Division:

The range of products for which the company is carrying out sales is divided into different divisions. The division is nothing but the product line of the company which is the categorization of products depending on their purpose and usage. Division is used for Reporting Purpose. Division is mandatory unit in SD. A material is always assigned to one division only.  The system uses divisions to determine the sales areas and the business areas for a material, product, or service. A product or service is always assigned to just one division. From the point of view of sales and distribution, the use of divisions lets you organize your sales structure around groups of similar products or product lines. This allows the people in a division who process orders and service customers to specialize within a manageable area of expertise. Divisions have two main applications: They are organizational units for Sales and Distribution, and they are necessary for business area account assignment for logistics transactions in Financial Accounting

Defining Division: Path: SPROIMGEnterprise StructureDefinitionLogistics-General Define, Copy, Delete, Check Division

24

Select the first option “Define Division” Select the “New Entries” Button and Specify the name of Division

For test case scenario we have defined 2 Distribution Channel as DD (Dell Desktops) and DL (Dell Laptops)

25 5. Sales Area: It is the combination of Sales Organization, Distribution Channel and Division. The Sales Area always represents the basic sales process of the company and all the sales transactions will be executed within a sales area. A sales area is used for reporting purposes; all data relevant for sales can be defined per sales area. For example, you can define pricing per sales area, or do your sales information analyses per sales area.

6. Sales Office: Your organization may require your sales teams to be structured along the geographical aspects of the organization. These geographical groups are easily created using the term sales office. A sales office is in turn assigned to sales area. A sales office may be assigned to more than one sales area. For example, when you create a sales order for a sales office, the sales office must be assigned to the same sales area the sales order is assigned to. When you create sales statistics, you can use a sales office as one of the selection criteria. When you print out order confirmations, you can include the address of the sales office.

26 Defining Sales Office: Path: SPROIMGEnterprise StructureDefinitionSales and Distribution Maintain Sales Office

Select the “New Entries” button and specify the name for sales office. Select the address icon and specify the required data.

7. Sales Group: The staff of sales office may be divided into sales groups. For example, sales groups can be divided for individuals divisions with sales team. By using sales groups you can designate different areas of responsibility within a sales office. When you generate sales statistics, you can use the sales group as one of the selection criteria.

27 Defining Sales Group: Path: SPROIMGEnterprise StructureDefinitionSales and Distribution Maintain Sales Office

To define a sales group, enter a three-character alphanumeric key and a description. Select the “New Entries” button and specify the name for sales group Note: Sales offices and sales groups are optional organizational elements; you do not need to configure them if you have no use for them. In this case, make sure that sales office and sales group fields are not marked as mandatory on the customer master or the order entry screens. Otherwise, the users will be required to enter a value that you have not maintained.

8. Business Area: A Business Area is an organizational unit within accounting that represents a separate area of operations or responsibilities in a business organization.

28 Business Area is just a code with a description. Business Area is used for taking internal reports on business details by the finance department. Hence, you should discuss with the FI/CO while defining Business Areas. Defining at least one Business Area for a company is mandatory. It is a company independent organizational unit and can be used to take reports across companies, if needed. Hence, it is defined to take internal reports, for example based on plants and divisions. For each sales order item, a business area must be determined and hence a set of standard rules are defined in the system for determining sales areas. In a client, you can set up several business areas to which the system can assign the postings made in all company codes defined in this client. To ensure consistency in document entry, you should give business areas the same name in all company codes. When defining a business area, you enter a four-character alphanumeric key and the name of the business area.

Defining Business Area: Path: SPROIMGEnterprise StructureDefinitionFinancial AccountingDefine Business Area.

Select the “New Entries” button and specify the name for Business Area.

29 9. Plant: Plant is an organizational unit where the production is done and also it is considered as the material stocking place. Storage locations are defined for each plant and assigned to plants. Material stocks are maintained at Storage location of plants. Many shipping points can be assigned to a plant. Also a plant can be used as Maintenance Planning Plant where all the plant maintenance activities are scheduled and carried out. Plant is a mandatory requirement in SD. A Company Code can have many plants. Plant belongs to one country. Material creation, inventory management, material valuation, MRP planning, Production etc are done with reference to a plant. Hence, more than one Company Code cannot be linked to a plant. If you create a plant by copying from a plant belonging to another country, you must change the country details of the new plant by going to the address area of the plant. Use plant 0001 or 1000 as a reference plant for copying.

Defining Plant: Path: SPROIMGEnterprise StructureDefinitionLogistics-GeneralDefine, Copy, Delete, Check Plant

Select the second option Copy, Delete, Check Plant

30 When you select the second option, you will get the following blank screen:

In this blank screen click on copy button (2nd button in application toolbar) Select the Source Plant as 1000, a standard existing Plant in the system and the target Plant as “DBLG” Go back to the previous screen and select the 1st option “Define Plant” and edit the Plant “DBLG” for additional data as shown in below screen.

31 10.Storage Location: Storage Locations are the locations where materials are kept in plant. Storage Locations are mandatory requirements for each plant. You can have many Storage Locations for a plant.

Defining Storage Location: Path: SPROIMGEnterprise StructureDefinitionMaterials ManagementMaintain Storage Location

Here you enter the plant for which you are going to create storage locations.

32

Select the “New Entries” button and define the storage locations. After saving storage location, select the same and the click on “Address of Storage Location” on left hand side of window and enter the address of the storage location. Defining the Storage Location and assigning the same to a plant is done in the same session. Hence, Storage Location can be defined only after defining the plant.

11.Shipping Point: Shipping Point is the location from where the goods are shipped out. Also it is the goods arrival point. Each shipping point is assigned to one or more plants. It is mandatory in SD. Shipping Point can be determined by the system based on shipping point determination. Generally, companies create deliveries using a background job, running the delivery due list. The Shipping Point is used as a criterion for delivery creation, so if you have express shipping and want the background job to run more frequently for those deliveries it is advisable to have an express Shipping Point. This Shipping Point may be used for the scheduled background job

33 and may be executed more frequently (for example, every 15 minutes) than the other shipping points. A Shipping Point is the top level of organization in shipping. Deliveries are always initiated from exactly one shipping point. A shipping point can be subdivided into various loading points. A Loading Point is a voluntary entry, merely a subdivision of a Shipping Point. It is manually entered into a header data of the delivery. Various Loading Points such as Rail Loading, Marine Loading, Air way Loading, and Truck Loading etc may be defined for each Shipping Point for different types of tracking and documentations.

Defining Shipping Point: Path: SPROIMGEnterprise StructureDefinitionLogistics-ExecutionDefine, Copy, Delete, Check Shipping Point

34

Select the second option “Copy, Delete, Check Shipping Point” When you select the second option, you will get the following blank screen:

In this blank screen click on copy button (2nd button in application toolbar) Select the Source Shipping Point as 1000, a standard existing company in the system and the target Shipping Point as “DBSP”

35 Go back to the previous screen and select the 1st option “Shipping Point” and edit the Shipping Point “DBSP” for additional data as shown in below screen.

The country here specifies the country from which the delivery originates. Departure zone is used in Route Determination. ‘Loading Time’ and ‘Picking/Pack time’ are used in Delivery Scheduling. For our scenarios, only the country is important. Select the Address Icon and specify the required data.

12.Regions: Path: SPROIMGSAP NETWEAVERGeneral SettingsSet CountriesInsert Regions

36 Select the “New Entries” button and create a region for the required country.

13.Calendar: Path: SPROIMGSAP Net weaverGeneral SettingsMaintain Calendar Public Holidays specifies the list of public holidays. Holiday Calendar specifies the list of holidays followed in the company. Factory Calendar specifies the number of working days in calendar. Note: The calendar is a cross-client component or client independent component i.e. if we maintain the calendar in a client that by default will be displayed across all other clients in that server. But the other components that can only be displayed in that server in which they are created are maintained are called as client specific or client dependent components.

37 Relationship between Various Units of Enterprise 1. Company Code and Sales Organization: One Company Code can have many Sales Organizations to look after the sales but whereas One Sales Organization can only work for One Company Code. So, the relation between Company Code and Sales Organization is One to Many. Company Code

Sales Organization

One to Many

2. Sales Organization and Distribution Channel: One Sales Organization can use many Distribution Channels for carrying out sales and One Distribution Channel can be used for many Sales Organizations. So the relationship between Sales Organization and Distribution Channel in Many to Many Sales Organization

Distribution Channel

Many to Many

3. Sales Organization and Division: From One Sales Organization we can sell many divisions and one division can be sold from many Sales Organizations. So, the relationship between Sales Organization and Division is Many to Many. Sales Organization

Division

Many to Many

4. Distribution Channel and Division: From one Distribution Channel we can sell many Divisions and one Division can be sold from many Distribution Channels. So, the relationship between Distribution Channel and Division is Many to Many

38 Distribution Channel

Division

Many to Many Note: Division is always Sales Organization Specific i.e. it is the Sales Organization that decides number of Divisions to be sold.

5. Company Code and Plant: In a standard business practice one Company Code can have many plants whereas One Plant can only work for One Company Code. So, the relationship between Company Code and Plant is One to Many. Company Code

Plant One to Many

6. Sales Organization and Plant: One Sales Organization can have many Plants and One Plant can work from Many Sales Organizations. So, the relationship between Sales Organization and Plant is Many to Many. Sales Organization

Plant

Many to Many The diagram shows the relationship between Sales Organization and Plant.

39 7. Plant and Shipping Point: One Plant can have many Shipping Points and One Shipping Point can have many Plants. So, the relationship between Shipping Point and Plant is Many to Many Plant

Shipping Point

Many to Many Following diagram shows the relationship between Plant and Shipping Points

Enterprise Assignment In this area, we will assign the enterprise units that we defined in the Enterprise Definition area. In assignment of the organizational data you link the different modules in the system by defining how the structures relate to one another. This is best shown by the association of Sales Organizations and Plants. A Plant is always linked to one Company Code, and can be linked to several Sales Organizations. This means that the Plant is owned by the Company Code and can take only order from and make deliveries to customers in its Sales Organization.

40 After you have defined your data, and the other application components have defined theirs (Such as the Company Codes having been defined by FI and the Plants by MM), it is time to assign the SD organizational data. The assignments are extremely easily settings to make once you understand how the structures should be build up.

Enterprise Assignment in Pictorial View Sales Organization

s Distribution Channel

Company Code

Plant

Division

Shipping Point

Storage location

41 1. Sales Organization to Company Code: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionAssign Sales Organization to Company Code

Select the required Sales Organization and assign the required Company Code created by you.

2. Distribution Channel to Sales Organization: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionAssign distribution channel to sales organization

42 Select the “New Entries” button and enter the required combination of Sales Organization and Distribution Channels.

3. Division to Sales Organization: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionAssign division to sales organization

Select “New Entries” button and enter the required combinations of Sales Organization and Divisions

4. Set up Sales Area: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionSet up sales area

43

Select the “New Entries” button and enter the required combination of Sales Organization, Distribution Channel and Division.

5. Sales Office to Sales Area: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionAssign Sales Office to Sales Area

44 Select “New Entries” button and enter the required combination of Sales Organization, Distribution Channel, Division and Sales Office

6. Sales Group to Sales Office: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionAssign Sales Group to Sales Office.

Select the “New Entries” button and enter the required combinations of sales group and sales office. Following diagram shows the assignment of Sales Offices and Groups to Sales Area.

45 7. Sales Area to Business Area: Business Area is determined by the system in sales orders for each line item. This determination is based on assigning a rule to a combination of Sales Organization, Distribution Channel and Division in which we make a sales order. The determined business area can be seen in accounting document. For all the combinations of Sales Organization, Distribution Channel and Divisions, you must assign a rule for how the Business Area is to be determined by the system when sales order is created. Three rules are available to select from. They are: 1. Business Area Determination by (Plant + Division) Rule 1 2. Business Area Determination by Sales Area  Rule 2 3. Business Area Determination by (Sales Organization + Distribution Channel + Item Division)  Rule3 Path: SPROIMGEnterprise StructureSales and DistributionBusiness Area Account AssignmentDefine rules by Business Area

46 Figure shows that Rule 1 “Business Area Determination based on Plant and Division” is set for the Combination of Sales Organization “DELL”, Distribution Channel “DR” and Division “DD”. Hence any Sales made in Sales Organization “DELL”, Distribution Channel “DR” and Division “DD” will be using Business Area defined for the Plant and Division Figure also shows that Rule 2 “Business Area Determination based on Sales Area” is set for the combination of Sales Organization “DELL”, Distribution Channel “DR” and Division “DL”. If the Rule is “1”, then the Business Area has to be assigned to the combination of Plant and Division and if the Rule is “2”, then the Business Area has to be assigned to the Sales Area

Assign Business Area to Plant and Division: Path: SPROIMGEEnterprise StructureSales and DistributionBusiness Area Account AssignmentAssign Business Area to Plant and Division

Select the required combination of Plant and Division and assign the required Business Area

47 Assign Business Area to Sales Area: Path: SPROIMGEEnterprise StructureSales and DistributionBusiness Area Account AssignmentAssign Business Area to Sales Area

Select the required Sales Area and assign the required Business Area

8. Plant to Company Code: Path: SPROIMGEnterprise StructureAssignmentLogistics-GeneralAssign Plant to Company Code.

48

Select the “New Entries” button and enter the required combinations of Plant and Company Code

9. Plant to Sales Organization and Distribution Channel: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionAssign Sales Organization-Distribution Channel-Plant.

49 Select “New Entries” button and enter the required combination of Sales Organization, Distribution Channel and Plant. Note: In a standard business practice to assign a Plant to Sales Organization both of them must belong to same Company Code

10.

Shipping Points to Plant:

Path: SPROIMG Enterprise StructureAssignmentLogistics ExecutionAssign Shipping Point to Plant

Select the required plant and the select the “Assign” button to assign the shipping point to the required plant. Note: To see the entire Enterprise Structure select the button “Structure” where we have copied the Sales Organization and the select the button “Navigation”

50 Common Distribution Channels and Divisions Master Data Records are multiplied by each additional organization element you have. Thus, 10 Customer Master Records with 2 Sales Organizations, 2 Distribution Channels and 2 Divisions would have a total of 80 Customer Master Record views. Add another Sales Organization and you have 120 Customer Master Record views. Adding Divisions does not multiply the Material Master views; however, it does multiply the Customer Master views. To reduce the master data required you can combine sales areas for Customer Master Data purposes.

Define Common Distribution Channels Path: SPROIMGSales and DistributionMaster DataDefine Common Distribution Channels.

Select the required combination of Sales Organization and Distribution Channel and specify the same Distribution Channel value for the fields Reference Distribution Channels for

51 Conditions “Dch-Conds” and Reference Distribution Channels for Customer/Master Data “DchCust/Mast”.

Define Common Divisions Path: SPROIMGSales and DistributionMaster DataDefine Common Divisions.

Select the required combination of Sales Organization and Division and specify the same Division value for the fields Reference Division for Conditions “Dch-Conds” and Reference Division for Customer Data “Dch-Cust”. Note: If we do not define the Common Distribution Channels and Common Divisions then while creating the customer we will get the error “Sales Area is Not Defined for the Customers”

52 Exercise Write down the Organization Elements that you have created. 1. 2. 3. 4. 5. 6. 7.

Sales Organization Distribution Channel Division Sales Office Sales Group Plant Storage Location Shipping Point

Also write down the assignments that you have created 1. 2. 3. 4. 5. 6. 7. 8. 9.

Plant to Company code Sales Organization to company code Distribution channel to Sales Organization Division to Sales Organization The Sales area you have set up Sales Office to Sales Area Sales Group to Sales Area Sales Organization + Distribution Channel to Plant Shipping Point to Plant.

Questions 1. Can you assign multiple company codes to a Sales Organization? If not why? 2. Can you assign multiple Sales Organizations to a company code? If yes, give a business scenario. 3. Can you assign multiple distribution channels to a Sales Organization? If yes, give a business scenario which would require such an assignment. 4. Can you assign multiple divisions to a sales organization? If yes, give a business scenario which would require such an assignment. 5. Can you set up multiple Sales Areas using the same Sales Organization? 6. Can you assign a single sales office to multiple sales areas? If yes, why would you want to do that? 7. Can a sales group belong to multiple sales offices? If yes, give a business scenario which would require it 8. Can the same shipping point belong to multiple plants? 9. Mention the total number of the Shipping Points that can be assigned to a Sales Organization.

53 Exercise 2: Organizational Structures Task 1: 1. Organizational units in the system represent the structure of an enterprise organization. Which organizational units represent only sales and distribution 2. Which organizational unit can you use in the system to represent a sales facility or a sales subsidiary? 3. Which organizational units can you use in the system to represent a means to ship goods to the customer? 4. Which organizational units can you use in the system to represent different product lines and to group materials 5. Which organizational units can you use in the system to organize and process outbound deliveries from different places? Task 2: 1. A corporate group can be divided up into several companies or subsidiaries. Which organizational unit can you use in financial accounting to represent a legal entity and an independent accounting unit in the system? 2. In a company, you can manufacture and store materials in different places. Which organizational unit can you use in the system to represent a production facility or a distribution center? 3. Within a plant, material storage can be divided up according to various locations or rooms. Which organizational unit can you use in the system to represent such a location or room? Task 3: 1. The subsidiaries of IDES Holding Inc. are organized according to country-specific situations and laws. In Germany, IDES AG is a subsidiary in the USA, IDES US INC. is a subsidiary. Which organizational unit and number is used to represent these subsidiaries in the system? 2. Two sales facilities organize the sales and distribution process for IDES AG in Germany (for this training course). Which organizational unit and number is used to represent the two sales facilities in the system?

54

Master Data

 Master data forms the basis of the SD processing. Master data is the responsibility of all modules, as each module has an element of it. However, the SD master data will be accessed by many other modules other than SD, such as PP, FI, and CO. The structure of this master data represents how the system is to perform in the future. It is the highest level of data and thus it has the largest effect on the standard business process. Master data in SD is divided into three main areas.

Customer Master Data  We have to create the database of all the customers of the company in the SAP system with whom the company carrying out the business. For each customer we specify a code which is unique and maintain the corresponding data of the customer for that code. During the sales transactions if we specify that customer code, the system automatically determines the corresponding data of the customer from that Customer Master record.

55 Following are the steps to be followed before creating a customer master data: 1. 2. 3. 4. 5. 6.

Define Account Group Create Number Ranges for Customers Assign Number Range to Account Group Define Partner Determination Procedure Create Customer Save the required data

Account Group: Account group is used to create customer master data and in the partner determination procedures. It specifies whether the customer we are creating is a sold to party or ship to party etc. All the customers with particular account group will have same features.

Account Groups classify different types of customers as shown in figure above Account Group decides the following important features in the customer master: 1. 2. 3. 4. 5.

Number series for customer and whether the series is external or internal Whether the customer is one time account or not Which entries in customer master is suppressed, mandatory, display or optional Default Customer Pricing Procedure in customer master Partner Determination function for customer master

Path: SPROIMGFinancial AccountingAccount Receivable and Accounts PayableCustomer AccountsMaster DataPreparations for creating Master DataDefine Account Groups with Screen Layout (Customers)

56

Click on New Entries to Create an Account Group

57 Click on “General Data” in Field status to go to overview screen

This Screen Consists of various Tab Pages maintained in General Data View of Customer Master Click on individual tabs to control the fields in that particular Tab page

58

Creating Number Ranges: Path: SPROIMGFinancial Accounting Account Receivable and Accounts PayableCustomer AccountsMaster DataPreparations for creating Master DataCreate Number Ranges for Customer Accounts Select the button Change Interval.

59 For creating a new number range select the button insert interval

For a Number range if we check the field “External”, it becomes an external number range i.e. while creating the customer we have to manually specify a number for the customer. If we don’t check that field it becomes an internal number range where the system automatically generates numbers for the customers.

Assigning Number Range to Account Group: After creating the number range, it has to be assigned to the required Account Group. For this Assignment Go to below mentioned path. Path: SPROIMGFinancial Accounting Account Receivable and Accounts PayableCustomer AccountsMaster DataPreparations for creating Master DataAssign Number Ranges to Customer Account Groups

60  Select the required account group and assign the required number range.

Partner Determination Procedure In order to get the required partner functions into customer master record, we have to configure the partner determination procedure. For this Go to Below mentioned path. Path: SPROIMGSales and DistributionBasic FunctionsPartner Determinationset up partner determinationSet up Partner Determination for Customer Master.

61

 There are 5 steps to create a Partner Determination Procedure. They are as follows:

Step1: Defining Partner Functions:-

62 Select the “Partner Functions” as shown in below figure.

For each partner function we need to specify a partner type which controls the functionality of that partner. For example, for a partner function if we specify the “Partner Type” as “KU” it becomes a customer and if we specify the “Partner Type” as “LI” it becomes Vendor. For a partner function if we check the field “Unique”, we cannot have more than one partner of that function within in a customer master record.

Step 2: Assigning Partner Functions to Account Group:Select the “Account Groups-Function Assignment” as shown below

63

Go to “New Entries” and assign the required partner functions to the required account group and save the data.

64 Step 3: Defining Partner Determination Procedure:Select the “Partner Determination Procedures” as shown below.

Go to “New Entries” and create a New Procedure

Step 4: Placing the Partner Functions in Procedure:Select the created procedure and click on “Partner Functions in Procedure.” You will be navigated to the below screen.

65 Go to “New Entries” and enter the required partner functions in the procedure.

For the partner functions if we check the field “Not Modifiable”, it cannot be changed in the customer master and if we check the field “Mandatory Function”, it becomes mandatory to have at least one partner of that function within a customer master.

Step 5: Assigning the Procedure to Account Group:Select “Partner Determination-Procedure Assignment”. Select the Required Account Group and Assign the Partner Procedure. Save the Data.

66

Creating Customer Type the transaction code XD01. You will be navigated to following screen below. 1. Specify the Account Group created. 2. Specify the Customer Number (Only in case if we select the option as External while creating Number Range for Customers) 3. Specify the Company Code with which the customer is doing business 4. Specify the Sales Organization with which the customer executes the Sales Transactions 5. Specify the Channel through which the customer executes the Sales Transactions 6. Specify the Division through which the customer executes the Sales Transactions

67

Give the required values and press Enter. You will be navigated to following screen below.

68  The customer master record consists of 3 views for which we have to maintain data. 1. General Data 2. Company Code Data 3. Sales Area Data

 Each view contains different tab pages and each tab page contains different fields for which we need to maintain the data.

1. General Data: - This includes the information such as address, telephone number, etc., and is maintained for every customer. This data is only identified by the customer number, and is not specific to the company code or sales area. Following are the Important Tab Pages and the respective fields in General Data:

69

1. Address: - Specify the required data of the customer on the Address Tab Page (Checked fields are mandatory).

70 (a) Search Term ½:- It is an important field. This field is used to search/find customers. Hence, during your leaning period put your name in this field to search the customers created by you. You can also use wild character (*) to search customers. (b) Transportation Zone: - It is used in Route Determination. Refer Route Determination in later chapters. 2. Marketing:-

(a) Customer Classification: - This can be best utilized for pricing purpose. It specifies the classification of customers which can be based on their sales turn over Defining Customer Classification: Path: SPROIMGSales and DistributionMaster DataBusiness PartnersCustomersMarketingDefine Customer Classifications Go to New Entries and create

71

3. Unloading Points: Specifies the location at which the goods are to be unloaded for the customer

72 (a) Goods Receiving Hours: - Specifies the timings in which the goods can be unloaded at customers location Defining Goods Receiving Hours: Path: SPROIMGSales and DistributionMaster DataBusiness PartnersCustomersShippingDefine Goods Receiving Hours

4. Contact Person: - Specifies the contact person at the customers location

73 Creating the Contact Person: Path: SAP Easy AccessLogisticsSales and DistributionMaster DataBusiness PartnerContact PersonVAP1-Create

2. Company Code Data: -

This data is mostly of interest to the accounting

department. It includes, for example, information on the reconciliation account and dunning procedures and withholding tax. This data applied only to one company code

1. Account Management:-

74 (a) Reconciliation Account: - This account in the G/L accounting is the account that is updated parallel to the sub ledger account for normal postings. 2. Payment Transactions:

(a) Terms of Payment: - Specifies the key for the payment terms composed of payment periods and cash discount percentage (Dunning). Defining Terms of Payment:Path: SPROIMGSales and DistributionMaster DataBusiness PartnersCustomersBilling DocumentDefine Terms of Payment

75 (b) Payment History Record: - If we check this field, the payment history of the customer will be recorded and displayed in the credit master data of that customer

3. Sales Area Data: -

This data is only of interest for the sales and distribution area. It

includes, for example, data on pricing or shipping. This data applies only to one sales area, and therefore is dependent on the sales structure (Sales Organization, Distribution Channel, Division)

1. Sales:-

76 (a) Sales District: - Specifies the district in which the customer exists. Defining Sales District:Path: SPROIMGSales and DistributionMaster DataBusiness PartnersCustomersSalesDefine Sales Districts

(b) Sales Office: - Specifies the sales office in which the customer exists © Sales Group: - Specifies the sales group taking care of the customer (d) Customer Group: - This can be used for Pricing Purpose. It specifies a grouping of customers which can be based on the kind of transactions they execute. The customer group is a wonderful field that is copied into the header and item level of the sales document. This is very useful for reporting and pricing purpose. Example: - Wholesalers, Bulk Buyers, Exclusive Wholesalers etc. Defining the Customer Group:Path: SPROIMGSales and DistributionMaster DataBusiness PartnersCustomersSalesDefine Customer Groups

77

(e) Currency: - Specify the currency of the customer. Note: - If the currency of the customer differs from the currency of the company code, we need to maintain the exchange rate from the customer’s currency to the company code currency for the required exchange rate type by using the transaction code “OC41” and specify that type in the customer master record for the field exchange rate type. (f) Switch off Rounding: - If we check this field the rounding of the order quantity will not be allowed for the customer. (g) Customer Pricing Procedure: - This field enables the system to automatically determine a corresponding “Pricing Procedure” for the customers during sales document processing.

78 2. Shipping:-

(a) Shipping Conditions: - It enables the system to automatically determine a corresponding shipping point for the customers during the sales document processing Defining Shipping Conditions:Path: SPROIMGLogistics ExecutionShipping Basic Shipping FunctionsShipping Point and Goods Receiving Point DeterminationDefine Shipping Conditions

79

(b) Delivery Plant: - Specifies the plant from which goods are delivered to the customer © Relevant for POD (Proof of Delivery):- If we check this field the customer becomes relevant for POD i.e. he sends an acknowledgment to the company after receiving the goods. If the customer is relevant for POD we can also specify the POD time frame. (d) Order Combination: - If we check this field we can combine multiple orders for customer to create a single delivery. (e) Partial Delivery for Item: - Specifies whether the customer requires full or partial delivery of the item.

80 3. Billing Documents:-

(a) Rebates: - If we check this field the customer becomes eligible for receiving the rebates. (b) Inco terms: - The Inco terms specify certain internationally recognized terms and conditions that the shipper and the receiving party must follow for the shipping transaction to be successfully completed. The part 2 of Inco terms specifies the place from which goods are delivered to the customer Defining Inco terms:Path: SPROIMGSales and DistributionMaster DataBusiness PartnersCustomersBilling DocumentDefine Inco terms

81

For any Inco terms if we check the field “Location Mandatory”, the part 2 of the Inco terms becomes mandatory in the Customer Master. © Account Assignment Group: - This field enables the system to post the sales values of different customers to the corresponding accounts during Revenue Account Determination Procedure. (d) Tax Classification: - Specifies whether the customer is liable for tax or not. The country (here IN) is the country from which the materials are sent. Note: - Tax Data can only be maintained if the Tax Category by Country [OVK1] is maintained and also the tax classifications are defined in the session Maintain Customer Taxes [OVK3].

82 4. Partner Functions:-

(A) Sold to Party (SP):- Specifies the customer placing order with the company (b) Ship to Party (SH):- Specifies the customer receiving the goods © Bill to Party (BP):- Specifies the customer on whom the bill is raised (d) Payer (PY):- Specifies the customer making the payment These partner functions are defaulted into Customer Master Record based on the partner determination procedure linked to account group. Note: 1. The information regarding the partners is always provided by sold to party. So, we need to maintain partner function in the master record of sold to party only. 2. Depending on the requirement all partners can be same or different

83 3. If all the partners are same then we need to create the customer as sold to party and specify the same customer number for the remaining partner functions in the master record of the sold to party 4. If the partners differ, we need to create customer master records for those partners and specify those customer numbers in the master record of sold to party for the corresponding partner functions 5. If required on sold to party can have multiple Bill to Party, Ship to Party and Payer. Specify the required data for all 3 views and save it. The customer is created. Use XD02 for modification and XD03 for display of already created customers. See ExtrasAdmin data to know against which account group this customer was created. Use transaction codes SE17 or SE16 for tables KNB1 (Customer Master Company Code) and KNVV (Customer Master Sales Data) to know the above data for an already created customer.

Extending the Customer to New Sales Area Go to XD01 and specify the Account Group. Specify the customer for whom the data has to be extended Specify the Company Code Specify the New Sales Area to which the customer has to be extended In the “Reference Section” specify the same Customer, Company Code and Sales Area in which the customer is already created. Press Enter.

84

The data will be extended to the new sales area. Give the values for required fields and save the data. Note: - Even though the data is copied to new sales area, if required it can be changed in that sales area but those changes which are made on the sales area data view are specific to that particular sales area only in which it has been made. Control over the customer master records is vitally important to ensure consistency in reporting and usage of the system. If you do not intend to use all the address fields of the customer basic General Data view, it is advisable to suppress the fields. Often, companies leave all the fields open and maintainable, resulting in non-uniformity of address field usage. This leads to messy layouts for output and inconsistent reporting.

85 Important Notes: 1. What if we assign four Partner Functions to Account Group but place only three Partner Functions in the Procedure and create a customer? Sol: In the Customer Master Record the system displays only those three partner functions which are placed in the procedure. So the partner determination procedure enables the system to automatically determine the partner functions into customer master record. 2. What if we assign only three Partner Functions to Account Group but place all four Partner Functions in the procedure and create a customer? Sol: In the Customer Master Record the system determines all the four Partner Functions but it proposes the customer number only for those three Partner Functions which are assigned to the Account Group. So assigning Partner Functions to the Account Group enables the system to propose customer numbers for the Partner Functions in the Customer Master Record 3. In the Customer Master Record where can we see all the changes that have been made to the fields? Sol: In the Customer Master Record screen from the Main Menu select EnvironmentAccount ChangesAll Fields. Otherwise, you can also see the changes at following path: Easy Access ScreenLogisticsSales and DistributionMaster DataBusiness PartnerCustomerDisplay changes-XD04 4. After creating the customer where we can see the Account Group by using which that customer is created in that Customer Master? Sol: In the Customer Master Record screen from the Main Menu select ExtrasAdministrative Data to see the Account Group with which the customer has been created. 5. How to change the Account Group of the Customer? Sol: Use the Transaction Code XD07 to change the Account Group of the Customer. To change the Account Group for a customer, the current and new Account Group’s shall have same number range.

86

Material Master Data The Material master data is used by the system to represent the product or service your company is selling or producing. It is compiled in much the same way as the customer master record using multiple views to represent the same material within the different areas of business. For example, the plant view contains all the plant-specific material and can be different for each plant in the organization.

Creating The Material:Path: SAP MENULogisticsSales and DistributionMaster DataProductsMaterialOther MaterialCreate-MM01

87

1. Material: - Enter the material code. In SAP, the number of characters for material is fixed as 18. It is set through the use of transaction code “OMSL”. Material Numbering is based on the settings in the Number Ranges for materials [MMNR]. Leave the field material Blank if the system has to allot material number. 2. Industry Sector: - Industry sector that you specify here determines which screens appear and in what order. Also it decides which industry-specific fields appear on the individual screens. 3. Material Type: - The material type field is mandatory on the screen as this screen is used to create all types of materials. Material type is similar to account group as it governs what fields are relevant for data input. It also controls how material behaves. A few common material types are HAWA- Trading goods NLAG- Non-Stock Material FERT- Finished good product

88 Then click on the tab ‘Select Views’. Note: If the same material code already exists for any other Industry sector or Material Type, the system will pop up with the existing organizational level to copy to other organizational level. If no such code exists in the system, the following screen appears to select the views

Select the following views to maintain the data 1. 2. 3. 4. 5. 6.

Basic Data 1 Sales: Sales Org. Data 1 Sales: Sales Org. Data 2 Sales- General and Plant Data Sales Text Accounting 1

89

Click on Default values if you want to save the screen selection activity so that when you create materials again, the same set of screen selection will be defaulted Then click on the tab “Organization Levels”.

90 Specify the plant and storage location in which the material exist and also specify the sales organization and distribution channel from which the material is sold. Specify the data for the following views to create the material.

1. Basic Data 1:

(a) Material Description: Specify the description of the material (b) Base unit of Measure: Specify the unit of measure in which the stocks of the material are maintained. (c) Division: Specify the division in which the material exist (d) Material Group: Material Group is used for grouping materials based on various criteria and can be used for searching materials on this field. For example materials belonging to a particular carbon contents can be grouped together for analysis (e) Net Weight: Net Weight cannot be more than Gross Weight.

91 2. Sales Org 1:-

(a) Sales Unit: Specify the unit of measure in which the material is sold Note: 1. we need to specify a sales unit only if it differs from base unit. 2. If the sales unit differs from base unit, we can maintain the conversion factors i.e. the quantity relation between the sales unit and base unit (b) Delivering Plant: Specifies the plant from which the material is delivered to the customers © Cash Discount: If we check this field the material qualifies for the cash discount specified in the terms of payment. (d) Tax Classification: Specifies the material is liable for tax or not

92 (e) Minimum Order Quantity: Specifies the minimum order quantity of the material that may be ordered for each sales transaction Note: The minimum order quantity can always be maintained in base unit of measure only (f) Minimum Delivery Quantity: Specifies the minimum delivery quantity of the material that is to be delivered for each shipping transaction (g) Rounding Profile: Specifies the rule that the system uses to adjust the order proposal quantity to the nearest deliverable units.

3. Sales Org. 2:

(a) Material Pricing Group: This field is used for grouping material for pricing conditions. For example, you can create pricing condition records for the combination of Material Pricing Group and Material Group. (from Basic Data 1 Screen) (b) Account Assignment Group: This field enables the system to post the sales values of different materials of different material types to the corresponding G/L accounts using Revenue Account Determination Procedure

93 (c) Pricing Reference Material: It is an important field. If an existing material is entered here, the price for this material is taken from this reference material. Please note that even if you maintain price for this material, system always checks and takes price from the reference material only. (d) Item Category Group: This field enables the system to automatically determine a corresponding Item Category for the items during the sales document processing. Item category determines schedule line category during the sales document processing. Example: NORM- Standard Item BANS- Third Party Item ERLA/LUMF- BOM Item 4. Sales- General/Plant:

(a) Availability Check: Specifies whether and how the system checks the availability of material in the sales document.

94 (b) Batch Management: Specifies whether the material is maintained in batches or not (c) Transportation Group: Specifies grouping of materials that have same transportation requirements. (d) Loading Group: Specifies grouping of materials that have same loading requirements. 5. Sales Text: Here we can specify any information regarding the material, which explains the material in more detail and which is useful for further processing of the material

6. Accounting 1:

95

(a) Valuation Class: This field enables the system to post the cost of different material types to the corresponding G/L accounts. (b) Price Control: Depending on “Price Control” either we need to specify “Moving Price” or “Standard Price”. Note: While creating material, if we get the error “The company code does not exist or not fully maintained” then go to following path. Path: SPROIMGLogistics-GeneralMaterial MasterBasic SettingMaintain Code for Material Management.

96

Select the required company code and specify the current year and period. Extending a material can be done by using MM01 and entering the same material number again and select the additional views

Customer Material Information Record Sometimes, Customers refer to a material using their own material number. For example, a material M-01 that we call with a description as “Bio Reagent – 101″ could be referred to as REAGENT-1201 or some other name. When the Purchase Order comes in from the customer, it comes in with the name REAGENT-1201. If this is bound to happen all the time, it makes sense to map this name to our material in SAP to ensure that all further orders coming in from that particular customer for REAGENT-1201 are mapped to material M-01. This mapping is done in Customer Material Info Record (CMIR)

97 If a customer is placing order for a material by his own code (called Customer Material

Number) rather by the original code of the material, we need to maintain this record where we have to assign that Customer Number to the original material code.

During Sales Order Processing if we specify the customer material number the system automatically determines the original code. To maintain this record Go to following Path, Path: Easy AccessLogisticsSales and DistributionMaster DataAgreementsCustomer Material InformationVD51-Create

98

Specify the customer for whom the record has to be maintained and also specify the “Sales Organization” and “Distribution Channel” of the customer.

99

In the overview screen specify the original material for the field “Material no.” For the field “Cust. Material” specifies that code by which the customer orders the original material. Select the record and click on Go to Info Record Details (F2) where we can specify Customer Description, Minimum Delivery Quantity etc... Note: While creating the sales order we can specify the customer material number on the view “Ordering Party” The system defaults the plant data in the sales order from the relevant entries in the master records based upon the following priority: 1. Customer Material-Info Record 2. Customer Master Record 3. Material Master Record

100

Conditions Record Maintenance In a business scenario the entire pricing is categorized into 4 elements. They are: 1. 2. 3. 4.

Basic Price Discount/Surcharge Tax Freight

For each pricing element we have corresponding condition types in SAP system. For example, PR00 Price, K004 Material Discount, K005 Customer-Material Discount, MWSTTax, KF00 Freight The Condition Record is a combination of the Condition Type, Access Sequence that is linked to that Condition Type and Condition Tables of the Access Sequence. Depending on the settings in a Condition Type, certain fields and features are displayed or suppressed in the Condition Record.

101 Condition Records cannot be created for Condition Types without an Access Sequence. There are several ways to create Condition Records: using a unique Condition Type (via Transaction “VK11”); for multiple Condition Types at same time (via Transaction “VK31”); and with a program (via Transaction “VK15”).

Maintaining Condition Records Using Condition Type Path: Easy AccessLogisticsSales and DistributionMaster DataConditionSelect using Condition TypeVK11-Create This method of creating Condition Records was one of two ways before SAP R/3 release 4.0. To create a Condition Record, execute either transaction code “VK11” or use the SAP menu path. The resulting screen requires the entry of the Condition Type for which the condition record has to be maintained

102

Enter our previously created Condition Type “ZCT1”. Either hit enter or click on the “Key Combination” button. This will display the Condition Tables from the Access Sequence that are attached to the entered Condition Type as you can see in below figure. Note that they appear in the same order as in the Access Sequence, from the most specific to most generic key combination. Select the key combination for which you would like to enter Condition Records; for example, the “Material” combination. Click check mark.

103 The screen where we maintain condition record is called Fast Entry. On the Fast Entry screen, you will see the “Sales Organization” and “Distribution Channel” fields in the Header section of the Condition Record. The “Material” field is on line item level, just as configured on the “Technical View” of the Condition Table. Enter the material number you want to create a price for and hit enter.

Although only the material number was entered, the pricing currency, the pricing UoM as well as the Validity Period are defaulted. The pricing currency, if not manually entered, defaults from the currency of the Company Code to which the entered sales area is linked. If the Condition Type is a percentage, the percentage sign is defaulted. The pricing UoM is defaulted with the base UoM of the entered material. If a key combination was selected that does not have the material number in the key, no UoM is defaulted and an error message requires the entry of a Unit of Measure.

104 The condition record is always valid within two dates specified for the fields Valid-From and Valid-To. The Valid-From and Valid-To are defaulted according to the settings in the Condition Type. Generally it is recommended that the Valid-To date is always set to “12-31-9999” unless you are creating Condition Records for, say, promotional discounts that should be limited to a certain period of time. The “12-31-9999” date will make price changes easier when they are needed The “Deletion ID” column “D” indicates if the Condition Record is marked for deletion. A check in this column would indicate this. The “Suppl.cond” column shows the existence of Condition Supplements for this Condition Type. The “Scales” column indicates if scales were maintained for this Condition Record. The “Texts” column indicates if text was maintained for this Condition Type. The “Exclusion” column would display “X” if the Exclusion Indicator was set in the configuration of the Condition Type. The “Payt Terms,” “FixValDate” and “AddValDays” columns on this “Fast Entry screen reflect the values that have been set in the “Additional Sales Data” screen of the Condition Record If we need to change the amount as the Quantity (or Weight or Volume etc.,) changes, we need to maintain scales. For this select the record and select the icon “Scales (F2)” Select any condition record and select Go to->Details to access the Condition Record “Details” screen as shown in below figure. Alternate ways to get there are by pressing “F6” key or clicking on the “Details” icon. Some data from the “Fast Entry” screen is displayed here as well, such as the Validity Period, the amount with currency and UoM. The “Details” screen also shows the Scale Calculation Type and base, if the Condition Type was configured for Scales. The Exclusion and Deletion Indicator is displayed as well. These two fields cans be manually maintained. The “Lower Limit” and “Upper Limit” fields allow the user to maintain a value range between which manual changes would be allowed on a Sales Document. Entering the values for this Condition Record manually on the Sales Document outside the specified range would result in an error message. The maintenance of these two fields is optional.

105

From both the “Fast Entry” screen and the “Details” screen, you can branch over to the “Additional Data” screen. Either select Go to->Additional Data or click on “Additional Data” button or press “F7.” The Valid-From and –To dates in Figure below are displayed and open to be changed. Be aware that these are the validity dates for the selected Condition Record only. If you would like to link the selected Condition Record to an existing Sales Deal, you can enter that Sales Deal number in the field “Sales Deal.” If the Condition Record was maintained from within a Sales Deal, this number is automatically populated. The same is true for the field “Promotion,” although it is not available for input within the Condition Record. If the entered or applied Sales Deal is linked to a Promotion, the Promotion number is pulled into this field. As mentioned before, the Terms of Payment, Value Days and Addition Value Days are maintained here. These dates and values will overwrite the defaulted line item data on a Sales Order. An example would be a specific promotion for which you would like to extend the terms of payments for a specific customer or a group of customers.

106

If Condition Supplement were defined for the Condition Type, they can be maintained by select Go to->Condition Supplement. This Option is only available if a Condition Supplement Pricing Procedure was maintained in the Condition Type for which the Condition Records are being created.

After all necessary Condition Records are maintained, they can be reviewed either on the “fast Entry” screen or on the “Create list Price ZCT1: Overview” screen. To get there, either

107 select Go to->Overview of Condition Records or Click on the “Overview of Condition Records” button or press “F5” key.

The default view in above figure is the “Condition Rate” view, which displays the Condition Record rate in the maintained currency and UoM. Try all of the alternative views that will show different data by pressing the respective buttons on the bottom of the screen. All the data can be found in the other screens explained above. One more important note on the creation of Condition Records is that it is possible that a Condition Record was previously created for the exact same Condition Key and Validity Period. The system recognizes that and presents the following screen as shown below upon save time. This screen displays the overlapping Condition Records. Clicking on the check mark will delete the previous overlapping Condition Record and let the currently entered record take precedence. On the other hand, Clicking on Delete button next to the check mark will delete

108 the currently entered Condition Record, and allow the previous Condition Record to remain intact.

Note: In the sales document the pricing information of the material is displayed on the “Conditions” Tab page in the corresponding item data of that material.

109 Questions and Exercises: Question 1 : Based on the Scenario 1 discussed above, please create a customer master and give the Customer Number and the other details the customer has been created with ( Like, Inco terms, Payment Terms, Distribution Channel , Division, Customer Group, Account Assignment Group, Shipping Conditions, tax classification and the different partner functions used. Scenario 2: The Sales Executive has successfully created the Customer. Now the Finance Department (Amy) needs to be intimated that a customer has been created and needs to be extended with the Financial Data as well. Julie sends an email to Amy specifying the customer number created. Amy looks at the Customer Number and sees which Sales Area the customer has been created in and chooses the right company code and extends the customer to the company code. Amy uses the Company Code’s A/R account as a Reconciliation Account. However, after consulting the Finance Controller decides not to offer the payment terms as created by Julie. Instead, the company chooses to offer the customer a payment terms as net due in 50 days with a 2% cash discount if paid in 10 days and 1% if paid in 30 days. Question 2: Based on the scenario above, please extend the customer master and give the customer number’s Company code, payment terms and Recon. Account. Scenario 3: An order has come in from Ehsaan Shah and Julie is creating the order for material M-01 for a quantity of 10. Question 3: When creating the Customer, does the order use the payment terms from the Sales View or the Company code view of the customer master? Question 4: Does the Inco terms of the SAP Customer Master (as created in Scenario 1) match with the Inco terms in the Sales Order? Question 5: Can you change the Inco Terms in the SAP Sales Order? What does this illustrate? Question 6: Specify the SAP Customer Group that the Order contains? Question 7: How do you know from the order that this order’s revenue belongs to a domestic customer? Question 8: Where does the bulk of the data from the Customer Master go – SAP Sales Order Header or SAP Sales Order Line Item? Question 9: Is Dominik Adam available in the SAP Sales Order? If yes, which tab in the Sales Order is he in?

110 Question 10: Find out all the Sales Areas that the Customer Master 1000 exists in? (Here is how to find out all the sales areas that the SAP customer master is associated with)

Questions on Customer Material Info Record Question 1: Describe in your own words the uses of Customer Material Info Record (CMIR)? Question 2: What is the Transaction code to create CMIR? Question 3: Can you create CMIR’s without being Sales Org and Dist. Chnl specific? Question 4: Create a CMIR for the following combination. Customer: 1400 Sales Org: 1000 Dist. Chnl: 10 Material: M-03 Customer Material: DELL-xxx Create a sales order for customer 1400 and which column will you use to enter the material at the line item level to make use of CMIR? Specify the SAP Sales Order # here. Question 5: Enhance the CMIR you created in Q.4 above to include a delivering plant of 1200. Now create another Sales order in SAP for the same combination and specify the following 1. 2. 3. 4.

The delivering Plant at the SAP Material Master Level for m-03 The delivering Plant at the SAP Customer Master Level for 1400 The delivering Plant at the SAP CMIR level The delivering Plant at the SAP Sales Order level

Question 6: Where is the delivery tolerance (in which tab) at the line item level in the SAP Sales Order? Question 7: Enhance the CMIR you created in Q.4 above to include a delivery tolerance of 10%. Also, enhance customer 1400 to include a delivery tolerance of 5%. Now create another sales order in SAP for the same combination and specify the following 1. Find out the delivery tolerances in the Sales Order Line Item level. 2. Where is the delivery tolerance in the Sales Order coming from? Question 8: Is the Customer material Number pulled up automatically when you enter the standard material number in the sales order line item?

111

Sales Document Processing The following diagram shows the flow of Sales Process in Sales and Distribution:

Customer asks for a quotation •

Desired materials and amounts are recorded

Available Amounts, Dates and Prices are communicated to Customer

Sales Order Processing is the central step •

Document with legal meaning for both parties

Delivery subsumes all outbound logistics activities •

Picking, Packing and Goods Issue

112 Accounts Receivable takes care of cash-related topics •

Billing, Dunning and Incoming Payments

Creating Basic Sales Order Path: Easy AccessLogisticsSales and DistributionSalesOrderVA01-Create.

This is the initial screen of Sales Order creation. Specify the Sales Order Type as “OR.” Specify the Sales Area in which the Order is processed. After entering the above data, press Enter. The following Sales Order Overview screen appears: In the Overview screen, specify the Sold to Party (Customer Number), Material and Order Quantity.

113

Note: This is the basic idea of creating Sales Order. We will look into depth of Sales Order later. While Creating Sales Order if we get the following errors, resolve them by using the solutions given. 1. The Order Type “OR” is not defined for this Sales Area Go to the Path mentioned below: Path: SPROSales and DistributionSalesSales HeaderAssign Sales Area to Sales Document type

DocumentsSales

Document

114

a) Combine Sales Organization : Select the required Sales Organization and assign the same as Reference Sales Organization.

b) Combine Distribution Channels: Select the required combination of Sales Organization and Distribution Channel and assign the same as Reference Distribution Channel

115

c) Combine Divisions: Select the required combination of Sales Organization and Division and assign the same Division as reference Division

d) Assign Sales Order Types Permitted for Sales Areas: Select the “New Entries” button and Enter the required combination of Sales Area and the Document Type “OR”

116

2. No Pricing Procedure Could be Determined: In the required Customer Master Record specify the Customer Pricing Procedure as “1” Go to transaction “OVKK” screen.

117

Select “New Entries” button and assign the Pricing Procedure “RVAA01” and Condition Type “PR00” for the combination of Sales Organization, Distribution Channel, Division, Document Pricing Procedure and Customer Pricing Procedure. 3. Assigning Chart Off Accounts to Company Code: Go to Transaction “OB62” screen. Select the required Company Code and assign the Chart Off accounts value as “INT” No need to configure this step if a Standard Company Code such as “1000” is copied as the Company Code you are creating

118

4. Assigning Fiscal Year Variant to Company Code: Go to Transaction “OB37” screen. Select the required Company Code and assign Fiscal Year Variant value as “K4” No need to configure this step if a Standard Company Code such as “1000” is copied as the

Company Code you are creating

119 Structure of a Sales Order The entire information in the Sales Order lies at 3 levels. They are 1. Header Data: This level of Sales Order is responsible for master data such as customer material master as well as sales area and organization data.  Sales Order header usually contains Customer related information such as payment terms, customer id etc. It is usually recorded on basis of sale done to a particular customer. As it is mentioned above, sales order header may contain data which are customer specific such as customer number, name, payment terms, shipping information. It is the Sales Order Header which is common throughout the Sale Order topic and it also applies to all the Line Items. To see the Header Data in the sales document overview screen select the icon “Display Document Header Details” or In the overview screen from the main Menu select Go toHeaderSelect the required view.

120 2. Item Level Data: This level of Sales Order is responsible for material item data such as item quantity and material master data. Even though the general data entered at header level by default applies to all the items in the documents, still each and every item in the document will be having its own related information called Item Data. Example: Each and every item will be having its own material code, description, order quantity, unit of measure, plant, price etc... Even though the data at header level is copied to all the items in the document, if required it can be changed at item level but those changes are specific to that particular line item only for which they have been made  The Line Items contains all information related to the customer’s need and the data is saved in a listed format. It will quote the items such as M01 M02 or M03 etc as required by the customer. It also contains quantity of product requested by the customer. Based on this information the SAP system develops a Schedule Line data. In short, Sales Order Line Items are customer’s request for material; the customer may have requested M01, M02 etc, in the needed quantity.  In order to reach to the Sales Order Line Item detail screen, for a particular item, you just need to double click on the relevant line item row. The next screen will show detail related to particular Sales Order Line item, e.g. 10 and particular material, say M01. On this interface there are several similar tabs, such as Shipping, Billing Document, Payment Cards, Accounting, Conditions, Account Assignments, and Partners etc. However, if you seek more detailed information, then you can click on the Arrow sign on the extreme right of all the tabs, this will open remaining tabs which are not generally seen on the screen due to lack of space on the screen. By clicking on the relevant arrow button you will find a list popped up, which will include the tabs, in order to select these tabs you need to just click on the desired tab title in the list.

121

3. Schedule Line Data: This level of Sales Order is responsible for delivery dates and delivery quantity.  For each of the line item there is a Schedule Line, which depicts the schedule of delivery. It may include information on dates of delivery and product units available etc. For example a customer has requested item M01 on 1st April 2010 and requires the item in quantity of 10, the information will be reflected in Sales Order Schedule Line section along with its availability on the particular delivery day. The availability is decided by determining the quantity of requested item that can be delivered on the date and scheduling another date for delivering the remaining amount of the item. After a complex calculation, when the SAP system decides to set a later date for the delivery of remaining amount of product, it is called as Forward Scheduling. On the Schedule Line screen you may find different columns such as Item, Material, Order Quantity, Description etc. Under these columns you will find Items listed with their relevant information. If you want to retrieve information on Schedule Line details, you need to click on the particular line item and then click on the schedule line button which is at the bottom of the screen, this will open the Schedule Line details for the particular item and the information may include dates and confirmed quantity etc. You will also be able to determine that whether the item requested on the particular date was confirmed or not, this can be done by matching the

122 Order Quantity column on the upper screen and the Confirmed Quantity column on Schedule Line detail screen. If the ordered quantity was not confirmed on the requested date then the further scheduled date on which the remaining quantity was confirmed will be mentioned. To see the Schedule Line Data of an item, first go to the corresponding item data and then select the view schedule lines.

In addition, you have business data (table VBKD), which can exist at header or item level. An example of business data is the Inco terms for the sales order, which are copied from ship to party master data into the sales order header business data. By default, this header business data applies to all the items on the sales order. You can change the Inco terms at header level and the change will apply to all items.

123 The Origin of Data in the Sales Document During the sales document processing the system automatically determines the data at all three levels in the sales document in the following way. 1. Header Level: At this level the system determines the data from the customer master record. When we enter Sold to Party in the sales document, the system goes to the corresponding master record of that sold to party and checks whether the partners are same or they differ. If all the partners are same then the system retrieves the entire data from the sold to party record itself. If the partner differs the system retrieves the information from different master records. For example, certain information like sales area, sales office etc., will be determined from the sold to party record and certain other information like unloading point, receiving point, shipping conditions, taxes etc., will be retrieved from ship to party record where as certain other details like Inco terms, payment terms etc., will be determined from the payer record. 2. Item Level: At this level the system determines the information in different ways. Certain information like material description, unit of measure, conversion factors, material group etc., will be determined from the corresponding material master and certain other details like payments terms, unloading point, Inco terms etc., are copied from header data. The pricing information of the material will be determined from the conditions master data. 3. Schedule Line Level: At this level the system proposes the delivery dates and the corresponding confirmed quantities by checking the availability of material and also by considering the corresponding lead times.

Status of the Sales Document We have three different statuses for a sales document. They are “Open”, “Completed” and “Being Processed”. The status of the sales document always depends on the status of the items in the document. If the status of all the items is “Open”, then the status of the document is also “Open”. If the status of all the documents is “Completed”, then the status of the document is also “Completed”. If the status of any one of the items in the document is either “Open” or “Being Processed” (with other items having the status as “Completed” or “Being Processed”), the status of the document is “Being Processed”. The status of an item always depends on the quantity that has been referenced. If the item is completely referenced the status is completed and if the item is partially referenced the status is “Being Processed”, where as the status of the item is “Open” if it is not at all referenced.

124 In the sales document we can check the status by selecting the button “Status Overview” in the document flow or we can select the tab page “Status” at the header level. To check the status of individual items we need to select the button status in the corresponding item data.

Controlling the Data in Sales Document As per the clients requirements the data at all three levels in the sales document has to be controlled accordingly. For this we have three controlling parameters in the sales document. 1. The data at header level is controlled by “Sales Document Type”. 2. The data at item level is controlled by “Item Category” 3. The data at Schedule line level is controlled by “Schedule Line Category”

Sales Document Type In a business process we have different sales transactions like Inquiry, Quotation, Sales Order, Returns Order etc. Each sales transaction is having its own purpose and behavior. For example, against transaction Quotation we can’t deliver the goods to the customer and we can’t even bill the customer whereas the other transaction Sales Order is relevant for both delivery and billing. For each sales transaction we have to create a corresponding sales document in SAP R/3 system. While creating the sales document we have to specify the sales transaction for which that sales document is created and is always controlled by sales document type. Each and every sales document in the SAP R/3 system is created by a sales document type which is the representation of the sales transactions in the SAP R/3 system and the sales document type helps the system in further processing of that sales document. The number of sales document types that we need to define depends on the sales requirements of the client. The figure below shows the examples of various Sales Document Types.

125

Defining Sales Document Type Path: SPROIMGSales and DistributionSalesSales DocumentsSales Document HeaderDefine Sales Document Type Example: IN Inquiry, QT Quotation, OR Standard Order, REReturns, CS Cash Sale, RO Rush Order, DS Scheduling Agreement, CR Credit Memo Request (G2 in SAP 4.7), DR Debit Memo Request (L2 in SAP 4.7) etc.,

126 When dealing with the configuration of Sales Document Types, generally one of the two functions is performed. One either creates a new document type or alters an existing document type. It is recommended you follow these few basic guidelines: 1. When creating a new Document Type, one should always reference the document type that is closest match to the one you are aiming to create. For example, should you need a new Sales Order Document Type, you should copy the Document Type “OR”. Once you have copied the document type, the system copies all assigned data such as item category, schedule line category determination and copying rules. You can make changes from this copy. 2. It is not recommended to modify any standard Sales Document Type’s (SDT’s). When you want to change an SAP document type, it is better for you to copy the document type and assign it a new name in the customer name range (Y or Z). For example if you wish to change the pricing procedure determination indicator for document type OR, it would be better to copy OR to ZOR and then make the changes. This leaves the standard settings in place. To copy a sales document type, select the document you wish to copy and click the Copy button. When you click the copy the system will prompt with a dialog box asking if you would like the entry to be valid for copy control rules. Select Yes to ensure the copy control rules are automatically created. Note: When you create a delivery from a sales order, SAP copies the data from the sales order into the delivery. You can define the copy control rules that determine the data that is copied and the order types that may be copied into corresponding delivery types. We will next look at the configuration settings necessary for a Sales Order Document Type.

127 Functionality of Sales Document Type

1. Document Category: Specifies a classification for different types of documents that we can process in the sales and distribution system, the document category determines how the system stores and keeps the track of the document data. For example, if you create sales order with SDT “IN”, system will give a message indicating that this order type is not for sales order. Hence, you must use SDTs with document category “C” while creating a sales order Example: A Inquiry, B Quotation, C Order etc. 2. Sales Document Block: Specifies whether the sales document type is blocked for processing. If we block the sales document type, the user cannot create new sales document of that type but those documents that have already been created before seating the block can be changed or displayed.

128 3. No. Range Internal/External Assignment: Specifies the number ranges that enter the system (If it is internal) or the user (If it is external) uses for giving numbers for sales documents while saving them. Creating the Number Range: Path: SPROIMGSales and DistributionSalesSales DocumentsSales Document Header Define Number Ranges for Sales Document 4. Item No. Increment: Specifies the value by which the item number for materials in the sales document increases when the system automatically generates item numbers. 5. Sub-Item Increment: Specifies the value by which the sub-item number is incremented in the sales document. Note: If we don’t specify any value for this field, the sub item number will be incremented by a value by which the main item number is incremented. 6. Reference Mandatory: Specifies whether a reference document is mandatory for creating the sales document. If so it also specifies the document type that should be used as reference. 7. Item Division: If we check this field the division at item level in the sales document will be determined from the corresponding material master record. Otherwise the division entered at header level will be copied to all the items in sales document. This field is used for cross division sale. If a sales order is to be created with items from various divisions, this field should be selected. 8. Check Division: Specifies whether and how the system reacts if the division at item level in the sales document differs from the division at header level. 9. Check Credit Limit: Specifies whether the system carried out a credit limit check during the sales document processing. Note: It is not required to carry out the credit limit check for certain document types like IN, QT, RE, CS etc., where as it is always recommended to carry out the credit limit check for “OR” 10. Read Info Record: In the sales document if we enter the customer material number, the system automatically determines original material number. For this we have to check this field in the definition of corresponding sales document. 11. Check Purchase Order Number: Specifies whether and how the system reacts if multiple sales documents have the same Purchase Order number.

129 Note: With the help of this field we can get either warning message or No message if multiple sales documents have the same PO number but if the requirement is that no two sales documents must have same PO number, rather warning we shall get error message. For this enhancement we have to use “USER EXITS” in ABAP. 12. Enter PO Number: If this field is selected and if you save the sales document without entering anything in the field “PO Number”, the system puts, by default, the sales document number at the “PO Number” 13. Screen Sequence Group: Specifies which screens we see during the sales document processing. 14. Transaction group: Specifies a grouping that allows you to control certain characteristics of a transaction according to sales document type. The transaction group controls the types of documents that we can process with certain system transactions. 15. Document Pricing Procedure: This field enables the system to automatically determine a corresponding “Pricing Procedure” during the sales document processing depending on the sales document type. 16. Display Range: Specifies whether the system displays all the items or only main items in the sales document. 17. F Code for Overview Screen: Specifies F function which overview screen we reach during the sales document processing after specifying the data on initial screen. 18. Quotation Messages: Set an indicator here if we want to receive a message informing that open quotations exists while creating the sales document. Depending on the indicator we selected the system searches for open quotations in the sales document either at header level for the customer or at an item level for the material. Note: We can always use this field for “OR”, never use it for “IN” and depending on the requirement it can be used for “QT”. 19. Outline Agreement Messages: Same as above but used for Open Agreements 20. Message Master Contracts: Same as above but used for Open Contracts 21. Incompletion Messages: If we check this field we can’t save the sales document if it is incomplete.

130

22. Delivery Type: Specifies the corresponding delivery type of the sales document. For example, “LF” delivery with reference to order. Document Type will be used while creating Delivery document of the sales order. Also, it is used in Delivery Item Category Determination. Note: No shipping data has to be specified for certain document types like “IN” and “QT” 23. Delivery Block: Specifies whether the sales document is blocked for delivery processing. 24. Shipping Conditions: If we specify shipping condition for this field in the definition of sales document type then during sales document processing the value for shipping conditions will be determined from this field only but not from the customer master record. 25. Immediate Delivery: If this field is selected, the delivery document will be created along with sales document number when you save the sales document. This feature is used for Rush Order and Cash Sales Order. For rush and cash sales, you must make the order lead time to zero.

131 26. Delivery Related and Order Related Billing Type: Specifies the corresponding billing type of the sales document. Example: F1 Order related Invoice F2 Delivery related Invoice Note: No billing data has to be specified for certain document types like “IN” and “QT” 27. Billing Block: Specifies whether the sales document type is blocked for billing. 28. Propose Delivery Date: If we check this field, the system automatically proposes the current date as requested delivery date. 29. Lead Time in Days: Specifies the number of days into future that the system used to propose the requested delivery date in the sales document. 30. Propose PO Date: If we check this field, the system automatically proposes the current date as PO date in the sales document. 31. Proposal for Pricing Date: Specifies the date that the system uses to propose the “Pricing Date” in the sales document. 32. Proposed Valid from Date: Specifies date that system uses to propose the valid from date while creating the documents like Quotation.

Assign Sales Area to Sales Documents Path: SPROIMGSales and DistributionSalesSales DocumentsSales Document HeaderAssign Sales Area to Sales Document Types Assign sales order types permitted for sales areas If the Sales Document types you created are permitted to be used by all Sales Areas, there is no need to create settings here. However, there may be a need to assign Sales Document to specific Sales Areas. For example, if a unique Sales Document type is used for all Sales Order for a specific Sales Organization. You may assign reference Sales Organizations as well as reference distribution channels and divisions. Do not confuse this referring with the assignment of Common Distribution Channels and Common Divisions. The referencing done here is only used by the system to determine which Sales Documents are permitted for which Sales Areas. If all Sales Document types are allowed for use by all Sales Areas, leave the assignment fields blank. Select the “New Entries” button and for the required combination of Sales Organization, Distribution Channel and Division assign the Sales Document Type.

132

Create Order Reasons for Sales Documents Path: SPROIMGSales and DistributionSalesSales DocumentsSales Document HeaderDefine Order Reasons You can create order reasons as to why a customer is purchasing or using a sales document. This is helpful in determining the trigger which creates the Sales Order, which in turn may be useful for analysis on order entry. The order reason can be “Sales Call” or “Good Price” or while processing returns can be “Poor Quality” or “Damaged Material.” Should the order reason be a crucial field for your reporting, you can assign to an incompletion log for the particular sales order to ensure no sales order may be saved or further processed until the order reason has been completed.

133

Item Category The data at item level in a sales document is controlled by item category. Depending on the sales document in which an item is entered and depending on the item that is entered in the sales document, the way we process the data always change. Item categories are automatically determined by the system while creating sales document. Following are the few scenarios in which Item Category plays an important role. 1. The same item has to be processed in different ways in different sales documents. For example, if a standard item is entered in a quotation it is not relevant for shipping and billing whereas the same item become relevant for both of them if it exists in sales order. 2. The same item has to be processed in different ways in the same sales document. For example, If we offer free goods for an item, the main quantity has to be priced but not the free goods quantity even though the material is same. 3. Different items are to be processed in different ways in sales document. For example, If we enter a third party item in the sales order the system shall automatically create a purchase requisition which is not required for a standard item. To fulfill all such sales requirements we need to define different item categories with the corresponding functionalities and make sure that the system automatically determines an appropriate item category for the items during sales document pricing.

134

Defining Item Categories Path: SPROIMGSales and DistributionSalesSales DocumentSales Document ItemDefine Item Categories. Example: AFN Inquiry, AGN Quotation, TAN Order (Standard item) AFNN Inquiry (Free goods item), AGNN Quotation (Free goods item), TANN Order (Free goods item) TAS Third Party Item

135 Functionality of Item Category

1. Item Type: Blank means standard item (means Pricing, Delivery, Scheduling etc can be applicable for this). Other items types are Text Item, Packing item etc. 2. Completion Rule: Specifies the rule for establishing the status of quotation or contract. For example we can specify that the status of a quotation is completed after the full quantity has been referenced or with the first reference or also we can specify that it is not relevant for completion. 3. Billing Relevance: Specifies whether the item is relevant for billing. If so it also specifies the reference document for creating the billing document. Note: Certain items such as the items in inquiry and quotation can’t be billed. So, the corresponding item category AFN and AGN respectively are not relevant for billing but the item category TAN which is used in sales order is relevant for billing. 4. Billing Block: Specifies whether the item is blocked for billing purpose. If blocked, no billing document can be generated till the block is removed 5. Pricing: Specifies whether the item is relevant for pricing or not

136 6. Business Item: If we check this field, the business data at item level is allowed to differ from the business data at header level in the sales document. In most cases they vary and hence, this field is selected always. Note: The business data at item level in the “Returns” document should not be changed. So we have to uncheck this field in the item category of returns item. 7. Schedule Line Allowed: Specifies whether we can have the schedule line data for the items in the sales document. If not checked, you cannot enter quantity in the sales document. This is the field which decided whether physical delivery is applicable for sales order lines (Items) or not. Note: Certain items such as the items in credit memo request need not have schedule lines. So, we shall not check this field in that corresponding item category “G2N” 8. Item Relevant for Delivery: This field is applicable for text items and value items only for which schedule lines will not be applicable. Specifies whether the “Text item” is relevant for delivery. Note: To make a text item relevant for delivery, we have to check this field in that corresponding item category of text item “TATX”. We need to make an item category as text item by specifying the value “B” (Text Item) for the field item type. 9. Returns: If we check this field, the item becomes a return item. Note: The items processed in the sales document of type “RE” are the return items. So, we have to check this field in that corresponding Item Category “REN” 10. Weight/Volume Relevant: If we check this field the system determines the weight and volume of the item into sales document from the corresponding material master record. 11. Credit Active: If we check this field, the item becomes relevant for credit management activities. Note: Certain items such as the items in cash sale transaction are not relevant for credit processing. So, we must not check this field in that corresponding item category “BVN”. 12. Determine Cost: If we check this field, the system determines the cost of the item during pricing in the sales document. Note: The cost condition type is “VPRS” 13. Automatic Batch Determination: If we check this field, the system automatically determines corresponding batch number for the item in the sales document.

137 14. Rounding Permitted: If we check this field, the order quantity of the item will be rounded to the nearest deliverable units depending on the rounding profile specified in the material master. 15. Order Quantity=1: If we check this field the order quantity of the item will be limited to 1. Note: During Item Category Determination, whatever the item category that is assigned as manual item category with that we can replace the default item category in the sales document 16. Incompletion Procedure: During sales document process, you can make entry of certain fields mandatory and if they are skipped without entry, the same will be logged in incompletion log. This is done through Incompletion Procedure. The incompletion procedure defines fields in which user must enter the information. Example: Validity periods and Customer Purchase Order numbers are required entries for both contracts and scheduling agreements.

Item Category Determination During the sales document processing the system automatically determines a corresponding item category for the items. For this following setting has to be configured. Sales Document Type IN IN QT QT OR OR RE CS RO CR DR OR

Item Category Group NORM NORM NORM NORM NORM NORM NORM NORM NORM NORM NORM BANS

Usage

High Level Item Category AFN AGN TAN

Item Category AFN AFNN AGN AGNN TAN TANN REN BVN TAN G2N L2N TAS

Sales Document Type is determined from Sales Document Type Category and Item Category Group is determined from Material Master.

138

Path: SPROIMGSales and DistributionSalesSales DocumentsSales Document Item Assign Item Categories. Go to New Entries and assign the item category to the combination of sales document type, Item Category Group, Usage and Higher Level Item Category

Schedule Line Category The data at schedule line level in a sales document is controlled by schedule line category. Mainly the schedule line categories specify the movement type, physically delivery can be created or not, delivery is to be always blocked etc. Schedule Line Category plays a major role in third party order processing.  Depending on the requirement we need to have different schedule line categories with the corresponding functionalities to be used in different sales documents.

139 Defining Schedule Line Category Path: SPROIMGSales and DistributionSalesSales DocumentsSchedule LinesDefine Schedule Line categories. Example: AT Inquiry Schedule Line BN Quotation Schedule Line CP, CV, CN Order Schedule Line

Functionality of Schedule Line Category

1. Delivery Block: Specifies whether the item is blocked for delivery. There are some sorts of deliveries that when delivery documents are created and saved, the deliveries are to be blocked immediately. For Example, when a free of goods sales delivery is saved, it must be automatically blocked. The reason is that all free goods delivery is to be approved by somebody and then the block must be removed, if required, manually, before proceeding further.

140 2. Movement Type: Specifies the physical or logical movement of materials leading to a change in the stock level or resulting in the consumption of the material. It is defined by MM consultants. Example: 601 Goods Issue Delivery 631  Consignment Fill Up 632 Consignment Return 633  Consignment Issue 634  Consignment Pick Up 651 Goods Returns (Restricted Use) 653 Goods Returns (Unrestricted Use) 655 Good Returns for Quality Inspection 661 Good Returns to Vendor 301 Plant to Plant Stock Transfer 561 Entry of Stock in Plant 3. Item Relevant for Delivery: Specifies whether the item is relevant for delivery processing. If marked only, the Delivery Document can be created and subsequently the delivery can be made. Otherwise, you will get the message “No delivery-relevant items in order xxx, order type "yyy” Note: Certain items such as items in Inquiry and Quotation are not relevant for delivery. So we must not check this field in those corresponding schedule line categories AT, BN respectively 4. Order Type: Specifies the document type “NB” for creating the purchase requisition. Note: We need to specify the document type “NB” for this field in the schedule line category of third party item “CS”. For CS we have to specify the Value “5” (Third Party) for the field Item Category. 5. Requirement/Assembly: If we check this field, the requirement (Order Quantities) will be transferred from sales and distribution to Inventory Management

141 6. Availability: If we check this field the system carries out the availability check for the items in the sales document 7. Product Allocation: If we check this field the product allocation will be activate i.e. the order quantities will be reserved for the customer.

Schedule Line Category Determination During sales document processing the system automatically determines a corresponding schedule line category for the items. For this following setting has to be done. Path: SPROIMGSales and DistributionSalesSales DocumentsSchedule LinesAssign Schedule Line Categories. Default Item Category

MRP Type

Schedule Line Category

AFN

ND

AT

AGN

ND

BN

TAN

ND

CP

TANN

ND

CP

REN

ND

CN

BVN

ND

CP

TAN

ND

CP

TAS

ND

CS

Go to New Entries and assign the schedule line category to the combination of Item Category and MRP type

142 Questions and Exercises Question on Document Types: Scenario 1: ABC Computers Inc. is preparing to launch a new high-end product line in January 2011 and has chosen to make sure that customers exclusively order this product line separately in a separate order. Since this is a high-end product line, this requires that the order be verified thoroughly before the corresponding products are delivered. Since these are premium products, in order to make sure that a certain QoS is maintained, the shipping is always to be done ASAP although the standard delivery type will be used for the same. The company also wants the sales Order’s line items to increment in multiples of 100. Question 1: Configure a new SAP SD Sales Document Type that satisfies the business criteria mentioned in Scenario 1. List the SAP SD document type and the corresponding controls you have tweaked. Question 2: List a Sales Order in SAP that you have created using the document type you have created based on Question 1 above. Scenario 2: It is December 2011 now, and ABC Computers Inc., has decided to drop the product line it launched in January (Scenario 1 above) and prevent any further orders from being created by the Sales users even by mistake. Question 3: Which field in the SAP SD Sales Document type configuration will help you achieve the business scenario 2? Other Questions (Not based on the Scenarios above) Question 4: What is PO Type? Why would you use it? Where is it available in the Sales Order?

143 Question 5: Do you need to explicitly assign a sales order type to a Sales area? If not, what is the necessity to do the assignment?

Question 6: What is the difference between Standard order and Rush Order? What configuration would effect this change? Question 7: What is the difference between Standard order and Rush Order? What configuration would effect this change?

Questions on Item Category: 1. Describe in your own words the significance of “Completion Rule” with an example document you have created in the system? 2. Create a new item category Zxxx as a copy of TAN and set the billing relevance to ‘blank’. Do the corresponding determination for the new item category in such a way that you can change the item category for a standard order ‘OR’ for material ‘M-01′. Create a new order; perform the delivery and subsequent billing. Give the SAP Sales Order #, SAP Delivery # and SAP Billing #. 3. Describe in your own words the kind of items where you would set the billing relevance to ‘blank’? 4. Create a Return Order (‘RE’) and write down the item category for material ‘M-01′? 5. Write down the key differences in the configuration between SAP Sales Item category ‘TAN’ and the item category you noted down in Q. 4 above? 6. What is the value in the ‘Pricing’ configuration field of the item category you created in Q. 2? 7. Create a Sales Order for Customer 1400, material M-01 using the item category you have created in Q.2 and write down the SAP pricing conditions you see in the sales order?

144 8. Change the Pricing Relevance of the item category (Zxxx) to ‘B’ and create another sales order that uses this sales item category and write down the pricing conditions you see in the sales order? 9. Change the Pricing Relevance of the item category (Zxxx) to ‘blank’ and create another sales order that uses this sales item category and write down the pricing conditions you see in the sales order? 10. What is the difference between the pricing conditions you see between Q.8 and Q.9? 11. In your own words, describe the use of billing block? 12. What is the SAP standard item category for Service? 13. Describe the key configuration differences between the item category ‘TAN’ and the item category in Q. 12? 14. Create your own copies (Zxxx) of the following SAP standard item categories. 1. TAN 2. TANN 3. TAD

Questions on Schedule Line Category: 1. Configure a new schedule line category say ‘Zx’ as a copy of the standard schedule line category ‘CP’? 2. Configure the schedule line category ‘Zx’ you have created in Q.1 above to be determined manually for sales item category TAN and material M-01. 3. Create a standard sales order for a material M-01 and change the schedule line category to ‘Zx’ and write down the standard order 4. Create a material similar to M-01 using the SAP Material Master (This time without a MRP Type) and create another standard order with the new material and identify the schedule line category determined by default. Explain the reasons for the determination. ( Hint: If the material is not in the SAP Material Listing and Exclusion, please add the same) 5. Deliver the order you have created in Q. 4 above and write down the Movement type associated with the corresponding item in the delivery. 6. Give the goods movement type associated with the SAP Sales Order # 4969 , Item No. 10 7. Can you determine if the line item.10 of the Sales Order # 4969 is externally procured or sent from our own warehouse? Give the reasons for your answer. 8. Can you find out the Movement type associated with Line Item 10 of the SAP Sales Order # 4969 directly from the Sales Order without going to the Goods Issue Document?

145

Copy Control Document Flow Each document is either created on its own or created with reference to another document. For example, a sales order can be created with reference to the quotation, whereas the quotation itself can be created on its own. The following diagram illustrates all the possible document flows in SAP. Transaction Codes Tip: The transaction codes can for the respective document flow configuration transactions can be easily identified by visualizing the picture below. If ‘A’ stands for Sales documents, ‘L’ stands for Deliveries and ‘F’ stands for billing documents, then the transaction for configuring the Sales document to the delivery document is VTLA. So it is VTXY with X as the target document and Y as the source document.

Let’s see some examples of different types of document flow using examples of standard commonly used sales scenarios.  

Sales-to-Sales Document Flow: For example you can create a Sales Order from a Contract or a Quotation. Sales-to-Delivery Document Flow: For example you can create a standard or a rush delivery from an order. Similarly you can create a consignment delivery from a consignment.

146   

Delivery-to-Billing Document Flow: A standard invoice is created with reference to a delivery. Billing-to-Billing Document Flow: Invoice cancellations are typically done with respect to the original invoice. Billing-to-Sales Document Flow: In case of debit memo requests or credit memo requests, the original invoice is used as a reference document.

Without going further, let’s dig a little deeper into the concept of “Reference”. Whenever we mean a document is referencing another document, this means that information is copied over from the previous document into the subsequent document. What is the need for information to be copied over..? There are many reasons for this. For example, this reduces burden on the person entering the subsequent document. Also, this ensures that information is accurately copied over without mistakes. Let’s take an example. A customer has called us and asked for a quotation. Our sales force has responded with a quotation.

The quotation could contain a bunch of data like who the customer is, his/her internal number with us, date of the quotation, date valid until, prices, discounts, surcharges, taxes, materials, quantity etc.

147 The customer then places an order referring to the prices in the quote.

During the process of creating the order referring to the quotation a bunch of data needs to be copied. Example data could include prices, customer data, materials and quantity, discounts given etc. In order to do these efficiently copy control routines are used. Copy control configuration is also part of the document flow.

148 Copying Control for Sales Document  Copy control in sales order processing is used by the system to determine what document types, item categories, and schedule line categories (the three tiers of the sales document type) can be copied into each other for example, when you are copying from a quote to an order, from an order to a delivery, OR from a delivery to an invoice. This permits all three tiers of data copied into sales, delivery and billing documents (including contracts and scheduling agreements etc) Path: SPROIMGSales and DistributionSalesMaintain Copy Controls for Sales Documents

1. Copying Control: Sales Document to Sales Document [VTAA]

a) Header Level:  At the header level you can see the document types that can be copied into one another, such as QT into OR. This is a SAP standard setting that is used in order to create a sales document with reference to another sales document At this level we need to specify copying requirements and data transfer routines. We have the source document type QT and the target document type OR The Copying Requirements specify when the data has to be copied from the source to target document i.e. if the system has to copy the data. The conditions specified here must be satisfied. An example is checking for the same customer – Meaning the order should be placed for the same customer as the quotation has been created for.

149

The data transfer routines specify which data has to be copied. For example: the routines “051”, “101” and “001” are used to copy General Data, Business Data and Partner Data respectively at header level. If we check the field “Copy Item Number”, the item number for materials will be copied from the source to the target document. So, line number 20 in the quotation will exactly be line number 20 in the sales document If we check the field “Complete Reference” the source document will be completely copied to the target document b) Item Level: Here also we need to specify Copying Requirements and Data Transfer routines. For example: the routines “151”, “102”, “002” and “251” are used to copy General Data, Business Data, Partner Data and Conditions respectively at item level. If we check the field “Copy Schedule Line”, the schedule line data will be copied from source to target document Update Document Flow: When we create the documents with reference, the system forms a flow of documents in which if we know one document number, we can see the remaining document number with the help of document flow. For this we have to specify the value “X” (Create document flow records) for this field while maintaining the copying controls between those documents. Do not Copy Batch: If we check this field, the batch number will not be copied from source to target document

150

The field “Pricing Type” specifies how the system treats the pricing data while copying it from the source to target data.  The FPLA field is a routine that checks certain billing plan requirements have been met and then copies relevant billing plan data into the proceeding document.  The indicator copy schedule line must be set, should you wish the data of these items schedule line to be transferred to the new document. Be sure to also create the schedule line copy control rules.  The indicator Re-explode structure/free goods is used when you wish the system to redetermine the BOM in the proceeding sales document. Thus, the system does not copy the actual BOM from one sales document into another, but by controlling the copy rules for the main item in the BOM; the system can copy a header BOM item into the proceeding document, which then re-explodes itself.  Copy quantity is best left blank when copying from a sales order to another sales order, as there is no affect on the quantity. However, in copying between the following, it would be advisable to follow the standard rules:  Quotation to Sales order: Positive  Contract to Return: Negative  Sales order to Sales order: No effect  The copy product selection indicator should be left blank if you wish the system to carry out a new product selection in the target document you are creating

151 c) Schedule Line Level:

At this level also we need to specify Copying Requirements and Data Transfer routines. For example: The routine “201” is used to copy schedule line data 2. Copying Controls: Billing Document to Sales Document When copying from a billing document type into sales document type, you again have the same layout of screens, however, without the following • • • •

Copy Quantity Contract Item Copy Copy Product Selection Re-explode Structure Free Goods

There is also no requirement to copy schedule line categories. DEMO Let’s create a quotation and create an order with respect to the quotation to see how this works. Step 1: Creation Quotation for customer 1400 and with material M-01

152

Step 2: Create a sales order referring this quotation No. 20000035. Enter the transaction [VA01] and click on the “Create with Reference” to enter the quotation with reference to which we wish to create the sales order.

Step 3: Enter the Quotation Number in Quotation field of the pop-up. As you can see from the pop-up screen, you can create orders with reference to an inquiry, contract, scheduling agreement, a billing document etc.

153

Step 4: After creating the quotation, if you want to track back and see with respect to which document the current order has been created, click on the document flow button.

Step 5: The document flow will be displayed. If deliveries were created with respect to the order, they will also be shown.

154

Special Sales Document Types  Many sales document types exist, and you have the ability to create endless more. However, the sales document types we will focus on are the standard processes most commonly used in SAP SD. These documents encompass their own business process procedures. The document flows we will look at are the following: the quotation, special sales orders such as the cash sale process and the rush order process, credit and debit cycles, and the returns and free of charge subsequent deliveries process. We will also look at the new document type as of Version 4.0, which is the invoice correction request. That is a combination of the credit and debit document. Following this, we will look into contracts and scheduling agreements. Path: SPROIMGSales and DistributionSalesSales Documents HeaderDefine Sales Document Types. The Inquiry—Sales Document Type AF (IN in English)  The sales inquiry is actually a request for a quotation. It is a non-obligatory request for sales information. The inquiry can relate to materials and services, and is sent to a specific sales area. The inquiry comprises of materials and/or services that can have schedule lines and delivery dates.  When configuring the sales document types for inquiries note the following: After an inquiry, you can create a quotation. Should your business decide to use inquiries, ensure you have the sales document category “A” for inquiries? No reference is necessary and should not be mandatory. The transaction group should be 1 for inquiries, and the screen sequence group can be different than the standard sales process. The SAP standard screen sequence group is AG.  If you are utilizing inquiries, be sure to have the item category determination set up for Inquiries as well as the schedule line category determination. Do not forget the copy control rules, should you wish a quotation to be created subsequent to an inquiry. The standard item category for inquiries is AFN

The Quotation—Sales Document Type AG (QT in English)  The quotation is a sales document type that comes before the sales order and after an inquiry. It is used as a proposed agreement of a price and quantity for a particular material or service for a particular date. Most quotations have a validity date  The quotation can include pricing and schedule lines. It can also have output assigned and credit checks assigned. A quotation is usually copied into a sales order. Depending on the customizing entries, you can copy the pricing elements, the header data, and the material and order quantities into the sales order

155  When configuring the sales document type for inquiries note the following: Your quotation should have sales document category “B.” This sets all relevant document types to read the customer material info record. Thus, set the indicator to “read info record.” The screen sequence group can be set as AG, which is the SAP standard for quotations. The transaction group should be set as “2”  It is also proposed that you set the indicator for open quotations. The indicator can read the item or header levels to indicate to the user, when he or she is creating a new quotation, that an open quotation exists for the customer, if set at the header level, or for the material, if set at the item level  Do not forget to set the item category determination and schedule line category determination as well as the copy control rules, such as from a quotation to a sales order. The standard item category used in quotations is AGN.

How to Create Quotation Step No. 1: Enter the Quotation type of QT with the Sales Organization as 1000, Distribution Channel as 10 and division as 00 and hit Enter. Step No. 2: Enter the Customer Number as 1400 and a sample PO Number say” Test Quote” Step No. 3: Enter the Material Number and quantity. You can use the same material numbers as used in “How to create a sales order in SAP” section. Step No. 4: Additionally, you have to enter a Quotation Start Date and Quotation end date. The reason for having a validity date for a quotation has been discussed in the class already.

Save the quotation and it will be displayed in the status bar.

156 Order Probability  When a sales inquiry or quotation is created, you may want to know whether or not the customer will follow through with a purchase. The system uses an order probability percentage from the customer master record and combines it with the order probability percentage of the sales document type. The combination of the two percentages results in an order probability percentage, as displayed in Figure. This percentage is available for lists of sales documents; thus, you can create a list of sales quotations that has the highest probability of being confirmed first.

Determination of an order probability percentage

The Cash Sale Process  One uses the cash sale process displayed in Figure below, when the customer places the sales order and picks up and pays for the goods at the same time. Thus, the system automatically proposes the current date in the sales order as the date for the delivery and billing. Once the sales order is saved, the system then creates a delivery automatically and prints out a cash sale invoice that can be given to the sold-to party. This cash sale invoice is a form created via output determination of the systematic invoice, which must be created using the standard process.

 The delivery can be relevant for Picking, or if the goods are not to be picked, the delivery can have the goods issue automatically happen in a batch process and then the billing can occur. Note the billing follows the standard process. Note: 1. The Order Type for Cash Sales is “CS.” 2. When we save the Cash Sales Order the system automatically creates the delivery. For this we have to specify the value “X” (Create delivery immediately, if quantity confirmed for today) for the field immediate delivery in the definition of “CS.” 3. While creating the Cash Sales the requested delivery date must be the current date. For this we should not specify any “Lead Time in Days” in the definition of “CS.” 4. The items in the Cash Sales Process are not relevant for credits. So we must not check the field “Credit Active” in the corresponding Item Category “BVN.”

157 The Rush Order Process  In the rush order process displayed in below figure, the customer places the order and collects the items immediately or we ship the materials immediately. However, we only invoice the customer later.

 The system automatically creates a delivery when we save the sales order, but no invoice is printed. Instead, the system follows the standard procedures for creating the invoice. Both the rush order process and the cash sale process utilize the shipping conditions passed on from the sales document. The shipping conditions in turn are used to determine the shipping point and the route. The Only difference between a rush order and a standard order is that the rush order has an immediate delivery creation. This delivery, however, may still need to progress through the logistics process of picking, packing, loading and goods issue processing Note: 1. When we save the Rush Order the system automatically creates the delivery. For this we have to specify the value “X” (Create delivery immediately, if quantity confirmed for today) for the field immediate delivery in the definition of “RO.” 2. The items in the Rush Order Process are relevant for Credit Processing. So we can use the Item Category “TAN” where the field Credit Active is checked.

The Credit Process—Sales Document CR/G2  The credit procedure displayed in Figure generally follows two business procedures, the first being the scenario where the customer returns products previously purchased and requires a credit. This we will look at in the returns process. The second general form of credit procedure is when the customer is credited without reference to a return

 This would be used in the following examples. The customer discovers the products we sent him are defective and the costs to initiate a return delivery would exceed the costs obtained in rehabilitation or repair of the product. Thus, we instruct the customer to scrap the material and we subsequently issue a credit note.

158  The second commonly used process is when the customer is overcharged for a product or service and we issue a credit for the difference. Again there is no movement of material. When configuring the sales document type “credit memo request,” note the following: You can automatically set a billing block that can be released by an authorized person prior to the billing. It is the billing which in turn is the actual creation of the credit note.  You should also set a mandatory indicator that the credit memo request can only be created with reference to the invoice document that originated with the problem. That way, you ensure traceability. It is also possible to select an order reason on the credit note, which can provide the reason why the credit was given. The standard item category used by credit memos is G2N. (Don’t forget in the copy control to ensure “update document flow” is activated when copying from an invoice to a credit memo request.)  You may not wish to credit for everything, such as the entire freight charge from one invoice. You can instead have a new returns pricing procedure in the credit memo request that is similar to the standard pricing procedure you use, but not have the freight condition type. Thus, the standard values are copied over, excluding freight. However, this new pricing procedure may have an additional manual condition type, such as “total transfer costs credit,” which can be manually entered in the credit memo request. Creating Credit Memo Request: Use the transaction code VA01 to create Credit Memo Request. While creating the Credit Memo Request, we need to specify the order reason along with the other required data. Remove the billing block if any and Save the document. Note: For “CR” 1. 2. 3. 4.

Document Category is “K” Screen Sequence Group is “GA” Transaction Group is “O” No Shipping Data has to be specified and corresponding billing document is “G2”

Note: The Item Category is “G2N.” For G2N, 1. We must not check the field “Schedule Line Allowed” and we must check the field returns. 2. The Billing Relevance is set to “C” and it is relevant for Pricing. Creating Credit Memo: Use the transaction code VF01 to create Credit Memo. For the field document specify the Credit Memo Request number and execute. The entire data will be copied from Credit Memo Request to Credit Memo and save it.

159 Note: 1. When we save the Credit Memo, the system automatically generates an accounting document which is posted to finance where the Company’s revenue account is “Debited” and the customer’s account is “Credited.” 2. The accounting document type is “RV” and the posting key for the payer is “11” which will credit the payer account.

The Debit Process — Sales Document DR/L2  The debit process displayed in Figure is used when we charge a customer too low a resale price for a material or service. We then create a debit memo request and invoice it using standard billing procedures. There is no movement of material.

When configuring the sales document type debit memo request, note the following: You can automatically set a billing block that can be released by an authorized person prior to the billing being carried out. This, however, is not commonly used when we are charging customers. The billing is the actual creation of the debit note. You can also set a mandatory indicator so that the debit memo request can only be created with reference to the invoice document that originated with the problem. That way, you ensure traceability. It is also possible to select an order reason on the debit note, which can offer the reason why the debit was given. The standard item category used by debits is L2N.  Rather than merely debit the customer for the disputed amount, it is recommended in almost all instances to credit the customer for the discrepancy in full and create another standard sales order to invoice, with the correct amounts for the original disrupted sales order. This procedure can be followed for all disputed short-priced orders and overpriced orders, thus resulting in one standard solution.  As already discussed, should you be using an intercompany sales process and want to create an intercompany credit or debit memo originally created from a credit or debit memo request, you will experience difficulty as this is not a standard procedure until SAP Version 4.5. Creating Debit Memo Request: Use the transaction code VA01 to create Debit Memo Request. While creating the Credit Memo Request, we need to specify the order reason along with the other required data. Remove the billing block if any and Save the document.

160 Note: For “DR” 1. 2. 3. 4.

Document Category is “L” Screen Sequence Group is “GA” Transaction Group is “O” No Shipping Data has to be specified and corresponding billing document is “N2”

Note: The Item Category is “L2N.” “L2N” is same as “G2N” except the field “Returns” which must not be checked. Creating Debit Memo: Use the transaction code VF01 to create Debit Memo. For the field document specify the Debit Memo Request number and execute. The entire data will be copied from Debit Memo Request to Debit Memo and save it. Note: 1. When we save the Credit Memo, the system automatically generates an accounting document which is posted to finance where the Company’s revenue account is “Credited” and the customer’s account is “Debited.” 2. The accounting document type and the entries in that are absolutely same as that of Invoice. Credit Memo Cancellation: Use the transaction code “VF11”. For the field document specify the Credit Memo Request number and execute. Go to the details of “Credit Cancellation” and save it Note: When we save the Credit Memo Cancellation the system automatically generates an accounting document which is posted to finance where the values that have been already posted to the corresponding G/L accounts during the Credit Memo creation will be reverted. The accounting document type is “AB” and the posting key for the payer is “O2” whereas it is “50” for the company’s revenue account. The Debit Memo Cancellation is absolutely same as Invoice Cancellation.

161 Invoice Correction Request—Sales Document Type RK  As of 4.0, SAP has a new document type called an invoice correction request. This document proposes a new way of processing complaints and issuing credit and debit memos. The document enables you to correct the quantity and/or the price for one or more items in an invoice.  Each invoice correction request that is made in reference to an invoice contains two items for each item in the invoice (you cannot create an invoice correction request in reference to a sales or delivery document type). The first item is the copied value and quantity copied from the invoice; this item appears as the credit item. The second item is the debit item, which represents the correct quantity and/or value. Should you change this second debit item due to a new pricing or whatever reason, the difference of the two would automatically be passed on to billing as either a credit or debit memo. It would be advisable to set an automatic billing block on the sales document type. As in a number of instances, you may wish to credit the customer. This may require authorization before the credit/debit is issued.  The billing document type assigned to the invoice correction request is order-related, a G2 (credit memo), and has the characteristic as K, which indicates a credit memo request. The system creates a credit memo for a positive total value and a debit memo for a negative total value. If the invoice correction request is characterized as a debit memo request, that is, the document type RK has a characteristic as L and has order-related billing assigned to it in the form of an L2 or debit memo, the opposite occurs. Creating Invoice Correction Request: Use the transaction code VA01 to create Invoice Correction Request. We need to create the Invoice Correction Request with reference to Invoice. For each item in the invoice the system automatically generates one more line item in the Invoice Correction Request. For that item we need to make the required change The difference amount of the “Net Value of Invoice Item” and “the Net value of that item in the Invoice Correction Request” will be the net value of the document. Save the Document. Note: The document type is “RK” is same as the document type “CR.” Apart from that we have to specify the value “D” (Invoice Correction Request) for the field “Indicator” in the definition of “RK.” Creating Credit Memo: Use the transaction code VF01 to create credit memo. For the field document specify the Invoice Correction Request number and execute.

162 The entire data will be copied from the Invoice Correction Request to Credit Memo and save it.

The Returns Process — Sales Document Type RE  The returns process displayed in Figure is different than the standard credit process in that a delivery is made. Although we cannot map all the functionality you may require in the physical process, such as goods receipts and warehouse management movement, we will look at the basic flow of the returns order procedure.

 The returns order can be created with reference to an invoice to ensure traceability of the process. It may be worthwhile ensuring this is mandatory when creating the returns order type. It may also be worthwhile ensuring the returns order reason was entered on the sales document. Thus, it may be necessary to add this in an incompletion procedure. You may want to copy the pricing from the invoice back into the sales order. Note: There is no need to indicate a negative value in the copying control rules, as the system sees the document type as a return. It automatically posts the entries in the finance document as opposite entries on the ledger. By using the same pricing values, you ensure a reversal of the externally created invoice.  It is advisable to have a billing block assigned to the return order to prevent a credit for returns being created until an authorized person releases the billing block. Go to Sales Sales documentsSales document headerDefine sales document type in the billing block field in the billing section  Once the returns delivery is created, the material is receipted back into our plant. The material should use a goods movement back into stock that inspects the stock, such as blocked stock, before placing it back into available stock to be consumed by the next sales order that places a demand for the material in the plant.  It is advisable to indicate a shipping condition that is specifically used for returns Thus, all return deliveries or goods receipts can be done by specific shipping. This is useful when running the delivery due list. You can select only to process the returns deliveries, as well as offer better visibility of stock movements. The standard item category used by returns is REN.

163  After the creation and goods issue of the delivery, the billing block is removed from the sales order and the invoice is created with reference to the sales order. This way, you can create a credit for the return in the sales order, which in turn has the order quantity copied from the preceding invoice

Differences between Cash Sales and Rush Order Cash Sales: In this type of order CS, as soon as you save the sales order the delivery is automatically created as same date and billing will also be generated at the same date as soon as you save the delivery document. In a rush order, the customer picks up the goods immediately, or you deliver them on the same day as when the order was created. When you save the rush order, a delivery is automatically created in the standard system. Billing of the rush order takes place as normal, after the delivery. In the standard system, sales document type RO is saved for rush orders with immediate delivery type LF. Once the goods have been removed from storage, the goods are picked, and goods issue is posted. Once the billing documents are created (for example, in collective processing), invoice papers are printed and sent to the customer. Rush Order: In this type of Order RO, The delivery will be created as soon as you save the sales order. But you bill the customer later. In cash sales, you can process an order for when the customer orders the goods, picks them up, and pays for them immediately. The delivery is processed at the same time as when the order is created and a cash invoice is printed immediately: billing is therefore related to the order, unlike rush and standard orders. Receivables are not created for the customer, as they are for rush and standard orders because the amount in the invoice is immediately posted to a cash account. In the standard system, sales document type BV (CS) is saved for cash sales with immediate delivery type BV. When the sales employee creates a cash sale, the system automatically proposes the current date as the date for delivery and billing. Once the order has been posted, a delivery with type BV is created immediately in the background and the system prints a document that is used as an invoice for the customer. The invoice papers are controlled with output type RD03, contained in the output determination procedure for order type CS.

164

Item Proposal The frequently occurring material combinations and common delivery quantity can be stored as “Item Proposals”. While creating the sales order, we can take the items from the item proposal. An item proposal consists of materials of different material types. The order entry can be processed more efficiently using item proposals.

Creating Item Proposal Path: SAP Easy Access Sales and DistributionMaster DataProductsItem ProposalVA51-Create

Specify the document type as “PV” and the Sales Area. In the overview screen, specify the required description, validity periods and the required materials with the corresponding quantities. Save it.

165

Note:

1. We need to specify the ‘item proposal’ number in the customer master for the field ‘item proposal’ on the ‘sales’ tab page under the sales area data view

166 2. For Document Type “PV” Document Category – D Screen Sequence Group – MA Transaction Group – 5 No shipping and billing data has to be specified

Using Item Proposal in Sales Order In the sales order, after specifying customer, select the icon “Propose Items”.

When we select the icon “Propose Items”, the following screen appears:

167

The system automatically determines the item proposal from the corresponding customer master, where we have following 3 options: 1. If we select the button “Default without Quantity”, the system copies all the items from item proposal into sales order without the quantities.

2. If we select the button “Default with Quantity”, the system copies all the items from item proposal with corresponding quantities.

168

3. If we select the button “Selection List”, the system displays all the items in the item proposal from which we can copy the required materials with or without quantities

In the above screen, if we select the button “Copy Material” the system copies the material without quantity into the sales order and if we select the button “Copy Quantity” the system copies the material with the quantity.

169

PRICING Pricing is the heart of SD and hence, you must understand thoroughly the fundamentals of pricing. SAP uses Condition Technique for handling the pricing. The easiest example to explore pricing is to take a simple grocery bill and expand on it.

Consider this as an extract of a grocery bill. You have purchased some items from the Produce section and some from the stationery section. Your Produce sub-total is 18.00 and your stationery sub-total is 10.00. You have been taxed 10% and your total comes to 27.00 as shown in the picture above.

While creating the Sales Documents, system select automatically a Pricing Procedure based on the Pricing Procedure Determination set up in the system. Pricing Procedure contains a series of Pricing Condition Type (PCT) for all the pricing elements such as one Pricing Condition

170 Type for basic price, another PCT for discounts, another PCT for rebate, another one for tax etc. Pricing values are recorded against each PCT. Certain PCTs can be set as mandatory (for example, basic price) so that before creating sales order itself, the price records should have been entered again such PCTs. While creating sales order, system will pick up pricing values against each Condition Types for each line (Item) and net price will be calculated for the entire sales order. For each PCTs you can enter different pricing values based on various options and system should choose one value from each condition type and the same will be assigned to sales order lines. System should choose only one which it finds in the order sequence mentioned in Access Sequence. For example, you can enter one values based on a combination of the customer and material and another value based on a material. If the more specific value is found (based on customer and material) system should take that value and add to the sales order line. If this specific value is not found, system should search for General value and the same should be added to sales order line. This search sequence is based on sequence set up in the system. Because pricing values are selected based on some conditions, this method is called a “Condition Technique”. Condition Technique is used in Pricing, Text Determination, Output Determination, and Material Determination---basically anywhere you have a condition record. The Condition Technique is the Technique that SAP uses to find a choice from among a number of alternatives. SAP makes the choice based on conditions, hence the name “Condition Technique”

Why is Condition Technique Used The Condition Technique is the single largest configuration technique used in the Sales and Distribution module. It is used throughout the pricing section. Condition technique is used when a complex, ever-changing set of business rules need to be configured as generically as possible in the system. Nothing could capture the essence of this statement more than the complex rules that businesses use to Price their products/services. For example, in pricing, each organization has their own set of business rules including base price, margins, discounts, taxes, surcharges, deals/promotions, price lists etc. For a single system to be generic enough to cater to all of these complex needs is a challenge in itself and that is exactly what condition technique tries to solve. For example, a customer wishes to purchase a product such as a television. This television has a standard sales price of $500 to all customers. However should the customer be a part of large corporation, a different pricing structure is sued, offering a lower sales price of $450. This is governed by the Condition Technique.

171 Procedure for Pricing comprises of OR The Condition Technique comprises of 1. 2. 3. 4. 5.

Condition Tables Access Sequence Condition Types Pricing Procedure Definition Pricing Procedure Determination

1. Condition Tables: The Condition Table is the first step in a pricing configuration. Condition Tables contains the key fields for maintaining condition records for the condition types. The key fields can be a combination of Organizational, Customer Master and Material Master Fields. Depending on the requirement we can take any field while defining the condition table. One condition type can have multiple condition tables and one condition table can be used for multiple condition types If a condition table is used for more than one condition type, the usage of condition records maintained in that condition table depends on the condition type to which it is assigned. Field Catalog: In the standard version of SAP R/3 system, a list of available fields with which a Condition Table can be built is stored in a “Field Catalog”. This “Field Catalog” can be found in following Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine Condition TablesConditions: Allowed Fields. You will see a list of technical field names from the Data Dictionary (DDIC) with their respective descriptions as shown in figure below

172

The list is not a complete representation of all the organizational, customer or material master fields that are available in the SAP system. Scroll through the list to see which fields are available in the standard Field Catalog. If there is a field you would like to price on, but it is not in this list, click on the “New Entries” button and select the pull-down for field “Field”. All available DDIC fields in the pricing communication structures “KOMG”, “KOMK” (Header) and “KOMP” (Item) will be displayed. Select one you are looking for and save it to be included in Field Catalog. If a field name is added that already exists in the Field Catalogue, an appropriate error message is given. In case you attempt to add a new field name that is not in the current DDIC structure for pricing Field Catalog, such as Sales Area specific “Customer Group 1” field, the error message “Field KVGR1 doesn’t exist in table KOMG, KOMK, or KOMP” is displayed as shown in below figure.

173

In the coming topics we will see how any field you would like to price on can be added to the pricing Field Catalog.

Defining Condition Tables: Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine Condition TablesCreate Condition Tables.

174 Specify a three digit number for the condition table which must be between 501 and 999. This is the available number range for SAP customer created Condition Tables, which is protected during SAP release upgrade. If a number selected that already exists, the system will issue an appropriate error message. To avoid that, select the pull down to see which table numbers are already taken. To save time, an existing Condition Table can be copied by entering the existing Condition Table number in the field “Table” in the “Copy from Condition” box. After the new Condition Table number is entered, press enter. The following screen appears.

The left column, labeled “Selected Fields”, displays any selected fields on the Condition Table. The right Column, labeled “FieldCatlg”, display the available fields from the Field Catalogue that was discussed. From the “FieldCatlg” column select the required fields and double click on them to be moved to “Select Fields” column.

175 To specify the description for the Condition Table select the Icon “Propose or Maintain Text” as shown in figure. Clicking on the “Other Description” button on top of the screen toggles between the following different descriptions of the Field Catalog fields: “Long Keyword”, “Short Description”, “Technical and Medium”, “Medium and Technical”, “Short Keyword” or “Medium Keyword”. As a general rule when creating custom Condition Tables, select document Header fields first, like “Sales Area” and “Customer”. Then add line item fields such as “Material Number”. When creating your own Condition Tables, be aware that there is a maximum of 200 bytes for the length of the Condition Table. If you want to see how long a field is before you select it from the Field Catalog, click on it once and press “Field Attributes” button. This also works for the fields that are already selected in left column. You should be aware that the same field can’t be selected twice. If a field was selected by mistake, it can easily be deleted by selecting it in the “Selected Fields” column and pressing “Delete Line” Button. Confirm that you want to delete the field in the resulting pop-up window. If instead a field should be inserted in the Condition Table, select the field in front of which you would like to add the new field and press the “Insert Row” button. Then select the field to be inserted from the Field Catalog. This is useful when an existing Condition Table is referenced and additional fields need to be added. Below the field are two selection boxes. The “With Validity Period” option indicates that when Condition Records are created later, a beginning and an end date for when the price or discount should be valid will be assigned. Always select this box. The second box “With Release Status” is turned on by default. You should only turn this option on if you want to work with price releases. Once all required fields are selected, click on the “Technical View” button.

176

The “Key” column in Figure indicates which fields of the Condition Table define its key. Leave these defaults unchanged. The “Footer Fld” field indicates which fields of the Condition Table will appear on line item level of the “Fast Entry” screen when a condition record is created. Finally, the text field defines which line item level field on the “Fast Entry” screen during Condition Record creation shows its field description. Only one of the fields can be selected to show this text. In addition, the DDIC fields of the selected table fields with their individual length are displayed on this screen. After making all the necessary selections, the newly created Condition table needs to be generated. To do that, click on “Generate” button. Confirm that you want to generate the Condition table and enter a development package from the available options.

177

Select the button “Local Object” for saving the condition table. A message will confirm that a new Condition Table AXXX has been saved, XXX= new Condition Table number. The “A” identifies the generated Condition Table as a pricing table. You can change a Condition Table by selecting the Path: Sales and DistributionBasic FunctionsPricingPricing ControlDefine Condition TablesChange Condition Tables. The only thing that can be changed is the description of the Condition Table on the assignment of footer or text fields of the “Technical View” Screen.

2. Access Sequence: It is a search strategy with the help of which the system determines valid condition records for the condition types in the sales document. For this we need to create an access sequence and place the required condition tables in it and then assign that access sequence to the required condition type.

178 One access sequence can have multiple condition tables and if required one access sequence can be assigned to multiple condition types. If an access sequence is having multiple condition tables, the order in which they are kept in access sequence is always important. Generally it is from most specific to most generic combination.

Defining Access Sequence: Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine Access SequenceMaintain Access Sequence.

To create a new Access Sequence, click on the “New Entries” button and enter a new four-character Access Sequence name. The first letter of an Access Sequence should be a “Z” to protect it from being overwritten during system upgrades. Enter “ZR01” for the Access Sequence and a description in field “Description”. The “Ty” field should be left blank for pricing Access Sequence.

179

Select the line for “ZR01” and double click on the “Accesses” folder in the left window pane. Since we are creating a new access sequence, no Condition Tables will be displayed initially. Click on “New Entries” button on that screen and enter the Condition Tables for this newly created Access Sequence. In below figure, Column “No” indicates the sequential number of the Condition Table in Access Sequence. The most specific Condition Table key should always be listed first, going from the most specific to the most generic one.

180

Based on Column “No” in the above figure, the system should search the data first in table “734”, then in table “660”, then in table “7” and at last in table “4”. If the Exclusive field is marked and also if data is found in table “734” then the system picks price from table “734”and stops searching further tables. If Exclusive field is not marked then the system puts data in the sales document from all the tables. Enter the Condition Table number in the “Tab” column. By entering the number here, all fields of the Condition Table will be pulled into the Access Sequence. The description of the Condition Table is automatically displayed in column “Description”. The same condition table can be listed more than once. This is useful when a Condition Type can be priced by different partners, like Sold-to, Ship-to or Payer. There is no need to create separate Condition Tables for that. Different partner types can be assigned in next configuration step. The “Requirements” column allows the addition of pieces of ABAP code that controls whether a Condition Table can apply under certain circumstances or not. The use of “Exclusions” column improves the system performance by selecting it for each Condition Table in the Access Sequence. The system will stop looking for valid Condition Records after finding a valid one in its Access Sequence search, if this field is selected.

181 There are some cases where you should not check the Exclusive indicator. For example, if you want to read the data from more than one table and select the best record among them and put it in sales order. This is most useful in case of discounts. For Example, you can have many tables for various discount types of discounts and only one which gives maximum discount should be selected and put in the sales document. To see which fields are populating the Condition Table in the Access Sequence, select one Condition Table (for our example, table “734”) and double-click the “Fields” folder in left window pane. The system gives a warning message saying that “The fields assignment is not yet been made”. Press enter and proceed further till we get the fields. Repeat the same procedure for all the Condition Tables in the Access Sequence and save it.

The DDIC field names of the source fields of the Condition Tables are displayed in Figure. DDIC table “KOMK” indicates fields from the document Header, “KOMP” from the document line item. If you would like to change the source of a field, select the respective

182 line of the field you want to change and click on the “Field Catalog” button. The Field Catalog is displayed as shown in below Figure, where you can select the desired field. If a value is entered in column “Spec.Val.Source” it becomes default value for this Condition Table field during pricing on a document. This default value overwrites the value that would normally originate from the source field. It is important to get to the field level for every single Condition Table in Access Sequence, even if no source fields are being changed. The Access Sequence will not work if this step is missed. After going through field level step for all Condition Tables, Save Access Sequence.

3. Condition Types:

The types of calculation (whether it’s a price, discount or a tax calculation, and in price – if it’s a retail price or a wholesale price or a variant price etc) are called condition type. Normally, condition types of a particular kind are not cumulative – Meaning if there are more than 1 Pricing condition type, they don’t add up – instead the last pricing condition type is taken by the system. There are some exceptions to this however. For example when pricing a car, it’s the sum of the different pricing condition types that gives you the Price. They are called variant condition types.

183 The Condition Type is the heart of the pricing configuration. The most important settings are made in this configurations setup. The Condition Type defines what type of pricing element it is. It can be a price, a discount or surcharge, a tax or an expense (Rebate) item. The Condition Type defines if the amount of pricing condition is positive, negative or if it can be both. As there are many controlling features inside the Condition Type, it is suggested to copy an existing standard condition type to your own condition type and modify the new one to your requirements. As usual, use Z as the starting letter for your own Condition Type as per recommendation of SAP.  Condition Types are then lined together in “Pricing Procedures” in a particular sequence to determine net price for the Sales Documents. Access Sequence is assigned/linked to Condition Types inside the Condition Types. If you want to use any Condition Type in a sales document, it should have been included in the Pricing Procedure. Let’s just explore on how the pricing is calculated on line item No. 10 – Milk. However, they might not be shown on the bill but are internal to the company selling the product. Let’s explore how a potential bill could be created. As you can see from the picture below, there is a Base Price from the price list – 5.00. And since the bill is for a retail customer, there is a retail discount of 1.00. So the sub-total for the line item 10 is 4.00.

184 Creating Condition Type: Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine Condition TypesMaintain Condition Types

Almost all Condition Types are already defined in the system with all the necessary links. Hence, it is recommended to create condition types by copying from standard Condition Types. Copy the standard Condition Type “PR00” to our new Condition Type “ZCT1”and click on the details button. On the top of the screen in below figure, the Condition Type and its description are displayed. This description will print on an Invoice or order acknowledgment. In field “Access Seq.” the previously created Access Sequence “ZR01” is assigned. During document processing the system then knows for which Condition Tables in the Access Sequence to find Condition Records of this Condition Type. If the Condition Type should not be using Condition Records, but only be applied manually on a document, no Access Sequence needs to be assigned here. Certain fields in the Condition Type configuration will become

185 unavailable in this instance (for example: “Condition Index”, “Reference Condition Type” and “Reference Application”). The “Record for Access” button will let you branch out to transaction “VK13” to display Condition Records of this Condition Type. C Type B001 B002 B003 B004

Condition Class Expense Reimbursement Expense Reimbursement Expense Reimbursement Expense Reimbursement

Calculation Type Percentage Quantity Dependent Percentage Percentage

Prices

Quantity Dependent

EDI2 EK01 EK02 HA00 HB00 K005 K007

Condition Type Group Rebate Material Rebate Customer Rebate Hierarchy Rebate Customer Expected Price Customer Expected Value Actual Costs Calculated Costs Percentage Discount Discount (Value) Customer or Material Customer Discount

Prices Prices Prices Discount or Surcharge Discount or Surcharge Discount or Surcharge Discount or Surcharge

KF00 KUMU PI01 PI02 PR00 R100 RA00 RA01 RB00 VPRS

Freight Cumulation Conditions Inter-Company Price Inter-Company % Price 100% Discount % Discount from Net % Discount from Gross Discount (Value) Cost

Discount or Surcharge Discount or Surcharge Prices Prices Prices Discount or Surcharge Discount or Surcharge Discount or Surcharge Discount or Surcharge Prices

Fixed Amount Quantity Dependent Quantity Dependent Percentage Fixed Amount Quantity Dependent Percentage Gross Weight Dependant Formula Quantity Dependent Percentage Quantity Dependent Percentage Percentage Percentage Fixed Amount Quantity Dependent

EDI1

186 Functionality of Condition Types:

187 Let us look up into fields defined in Condition Type “ZCT1” in detail. 1. Access Sequence: Specifies the corresponding Access Sequence of the Condition Type. 2. Condition Class: Specifies the preliminary structuring of Condition Type that allows you to control each Condition Type differently. This identification is important since it defines later, during document processing, how the Condition Type behaves. Example: The Condition Class Taxes specifies that the tax component has to be re-determined of the location of ship to party is changed in the sales order. The system will then re-determine the following condition types:      

Taxes (Condition Class D) Rebate (Condition Class C) Inter-Company Billing Condition (Condition Category I) Invoice List Conditions (Condition Category R) Cost Conditions (Condition Category G) Cash Discount Conditions (Condition Category E)

3. Calculation Type: Specifies how the condition amount of a Condition Type is calculated. The Calculation Type also controls the allowable field inputs during pricing. The system calculates the price depending on quantity/weight/volume etc. For example, when you try to create a Condition Record for a Condition Type that has a percentage Calculation Type, the Pricing Unit of Measure automatically defaults to “%”. 4. Condition Category: Specifies classification of the Condition Types according to predefined categories. With the Condition category it is possible to group multiple Condition Types together. For example, all freight-related Condition Types could be assigned to Condition Category “F” for freight. As you can see when you select the pulldown for this field, there are several categories labeled as “Customer Reserve.” This allows the creating of your own groupings that can later be used in custom Pricing Rule. 5. Rounding Rule: Specifies the rule that determines how the system rounds off the condition values during pricing in the sales document. A blank entry in this field rounds based on common business rules (i.e. 20.355 rounds up to 20.36 and 29.544 round down to 29.54). 6. Plus/Minus: If you want to allow only positive values for the specified Condition Type, mark this field with an “A.” This setting is valid for entries in the Condition Records as well as manual entries on any kind of Sales Document. Even if the entry of negative value is attempted, the system will revert to a positive value. In contrast, the value of “X” in this field will only allow negative values. This should be a setting for all discountrelated Condition Types. A blank value in this field will allow both. Example: For a

188 Condition Type if we specify the “Negative” value for this field it becomes discount whereas it becomes surcharge if we specify the “Positive” Value. 7. StrucCond: This field is only necessary if you are pricing materials with a sale Bill of Material (BOM), such as configurable materials. For all other pricing scenarios, this field will remain blank. 8. Group Condition: If we check this field, for Header Condition it becomes a group condition where the condition amount is not copied as it is to all the items in the sales document but it is distributed proportionally among the items in the sales document depending on the net value of the item. Example for group condition is “HB00” Condition Type. 9. Group Condition Routine: This field goes along with the Group Condition setting. Here it is defined which items will be valid to be included in a Group Condition Table. SAP system provides some default routines and they can be used depending on the requirement. If none of these routines satisfies your business needs, you can certainly define your own Grouping Conditions routine. Go to transaction “VOFM” and select FormulasStructure of Group key to add a routine in the customer reserved areas, starting with number 500. 10. Rounding Difference Comparison: The “Rounding Difference Comparison” field is used if a Group Condition amount is distributed across multiple line items. For example, if the Group Condition amount is $100 and this amount should get distributed across the three line items on the Sales Document, $33.33 would be allocated to each line item. The sum of the line items ($99.99) is then compared with the amount from the Header ($100). Checking the rounding field will allocate the difference between these amounts to the item with the largest net value, making it therefore $33.34. If all line items have same value, the difference is allocated to the last line item. If no Group Condition Rounding is specified, the system automatically assigns the rounding difference to the last line item, regardless of its value. If the defined Condition Type is a Fixed Amount (Calculation Type “B”), the setting of the Rounding Difference Comparison is mandatory. 11. Manual Entries: This field determines if values of Condition Records or manual entries for the same Condition Type in a sales document take priority. It also shows whether in the sales document we can alter the system calculated condition values or altogether we can enter in the document a new Condition Type and value Blank or “A” = No limitations. For example, if you add manually in sales document, one more Condition Type in addition to the system picked same Condition Type, the total values of both these Condition Types are considered for the discounts.

189 “B” = Automatic Entry has Priority. If a Condition Record exists, the condition type cannot be entered manually. If no Condition Record could be determined, a manual entry would be possible. “C” = Manual Entry has Priority. If a value for this Condition Type is entered manually, the system does not check for a Condition Record. “D” = No Manual entry is Possible. 12. Header Condition: If we check this field for a Condition Type, it becomes a header condition where it has to be entered at header level in the sales document. The condition amount of the header condition will be copied as it is to all the items in the sales document. Note: The Header Condition Type doesn’t have Access Sequence. 13. Amount/Percent: Checking this field allows the manual change of the amount or the percentage value of the Condition Type in a document. 14. Quantity Relation: This setting allows the change of the conversion factors of the pricing Unit of Measure. For example, instead of $10 per 1 piece you could change the quantity relation to $10 per 10 pieces. 15. Item Condition: If we check this field for a condition type, it becomes an item condition where it has to be entered at Item Level in the Sales Document. The condition amount of the Item Condition is applicable to that particular line item only for which it is entered. 16. Delete: If we check this field, the Condition Type can be deleted during pricing in the sales document. 17. Value: If we check this field, the condition value of the condition type can be changed during pricing in the Sales Document. 18. Calculation Type: If we check this field, the calculation type of a Condition Type can be changed during the pricing in the sales document. Note: If we change the calculation type for a condition type in the sales document, it applied to that particular line item only for which it is changed. 19. Valid From: Whenever a Condition Record is created, a date from which the record should be valid needs to be entered. The “Valid From” field determines the default in the Condition Record. 20. Valid To: Each Condition Record also has a date on which the validity ends. This “Valid To” date is defaulted based on this setting. A blank value will default the date of “12/31/9999”.

190 21. Reference Condition Type: You can reference Condition Records of another Condition Type with the “Reference Condition Type” field. This eliminated dual maintenance. 22. Reference Application: This field represents the system application from which the Reference Condition Type is referenced. Within Sales and Distribution, “V” is the correct entry. 23. Pricing Procedure: This Pricing Procedure is Condition Supplement Pricing Procedure. Condition Supplement procedure is a group of condition types that should be applied every time this Condition Type is found. 24. Delete from Database: Specifies whether the Condition Record has to be deleted physically from the data base or only deletion flag has to be set while deleting the Condition Record of the Condition Type. 25. Condition Update: Turning on this field tracks how often a Condition Record for this Condition Type is used and allows you to set limits on it as well (for example, how many times it can be used). 26. Scale Basis: Defines the values on which the scale is based. A quantity scale, for example, uses the number of units to determine which level of Scale is reached. A volume Scale would use the volume of the item. 27. Check Value: Specifies whether the scale rates must be entered in ascending or descending order. A descending scale might look like this: From 1 PC = $10 From 10 PC = $8 From 100 PC = $5 The Descending term is related to this price, not the quantity levels of the scale. This means the quantity of units is in ascending with each level of the scale and the price for each level is actually being reduced. 28. Scale Formula: Specifies the formula based on which the system calculates the scale amount of a Condition Type 29. Unit of Measure: Depending on the Scale Basis, a default Unit of Measure can be entered in this configuration field, which will automatically apply in the Condition Record. 30. Condition Exclusion: If we maintain the exclusion indicator for a Condition Type, during pricing in the sales document the system excludes (will not determine) the other condition types that exist below to that Condition Type and having the same requirement as that Condition Type in which the condition exclusion is maintained. We can maintain the exclusion indicator in the Condition Type OR in the Condition Records. If we maintain the exclusion indicator in the Condition Type it is by default applies

191 to all the condition records of that Condition Type so that condition exclusion will be working. Whereas if the exclusion indicator is maintained in the Condition Record rather in the Condition Type, the condition exclusion will be working only if that record is determined into sales order. 31. Currency Conversion: If this field is checked, it will cause the system to convert the condition currency to the document currency after the multiplication of the items. Should the value not be checked, the system converts the currency of the condition into the document currency before multiplying the value for the items. 32. Accruals: The accruals check box makes the value determined by this condition type statistical for example, to be used in finance for accruals for rebates. 33. Inter-Company Billing Condition: This field permits you to indicate that this condition type is used for internal costing 34. Pricing Date: The date of pricing, that is the system date that must be used to determine a condition record’s validity, must be indicated by the entry in the pricing date field. Should you leave it blank, the system will use the standard pricing date KOMK-PRSDT for pricing; however, for taxes and rebates, the system will use the date KOMK-FBUDA 35. Relevant for Account Assignment: This field is used to identify if standard account determination or specific account determination must take place, which identifies this condition value, to controlling 36. Text Determination Procedure and Text Id: Both these fields are used to determine if a text is relevant for this condition type

4. Pricing Procedure Definition: So far, you learned what type of prices, surcharges, discounts and taxes comprise the way the final price for a customer is calculated. The sequence in which this calculation is processed is defined in a Pricing Procedure. This pricing schema defines which Condition Types are used, under which circumstances they are allowed or blocked, what subtotals exist and to which G/L accounts each Condition Type should be posted. The Pricing Procedure is responsible for mapping the business needs and processes. For Example, correct pricing and discounting, while also keeping to the legal requirements placed on the business. For example, adhering to the tax laws of the respective country The Pricing Procedure is also used in Account Determination. This determines which GL accounts the prices, discounts and taxes must be posted to. The Condition Types in the pricing

192 procedure are linked to an account key. This key in turn is linked to the general ledger accounts. This shows the integration between the pricing in the invoice and the FI module. Pricing Procedure is determined by the system while creating Sales Documents. It is based on settings in the Pricing Procedure Determination which will be explained in detail later. Remember that you can only enter manually in a sales document those condition types which are listed in the Pricing Procedure. For our example, we will create a new pricing procedure ZR0001 and link the following Condition Types to it.

Defining Pricing Procedure: Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine and Assign Pricing ProceduresMaintain Pricing Procedure

A list of Pricing Procedures with their respective description is displayed. On top of the screen the fields “Usage” with value “A” and “Application” with Value “V” indicate the listed Pricing Procedures are related to Sales and Distribution Pricing. In comparison, in a different configuration task, Shipment Cost Pricing Procedures are shown as Usage “A” and Application “F” for Shipment Cost.

193 The field “Pricing Type” allows the definition of a Pricing Rule to be used when manually updating the Sales Orders with EditNew Pricing Document. Leaving the “Pricing Type” field blank will apply Price Type “B” as a default rule during re-pricing To create a new Pricing Procedure, click on the “New Entries” button. Enter a six-character alphanumeric Pricing Procedure name starting with a “Z” in field “Procedure” and its description in field “Descript”. Select that line and double-click the “Control Data” folder in left window pane.

1. Step Number: Specifies a sequential numbering of a Condition Type in the Pricing Procedure. Give the step number in increment of 10, which will make it easier to insert Condition Types or sub totals at later time. Pricing Procedures with steps like 1, 3, and 5 will requires the re-numbering of the whole Pricing Procedure if additional steps need to be inserted later. 2. Counter: Specifies the sequential number of a Condition Type with in a step in the Pricing Procedure. This field is rarely used. 3. Condition Type: Enter the applicable Condition Type in the “Condition Type” field. Leaving this field blank defines a subtotal in the Pricing Procedure. 4. Description: Specifies the description of the Condition Type which will be automatically determined by the system from the definition of Condition Type.

194 5. From: This field indicates the Step Number from which the current line in the Pricing Procedure is referencing its Condition Base Value. This field is used for percentagebased Condition Types or subtotals. For example, if a discount is defined as a percentage, you need to indicate which step must be used as the basis for the calculation. If calculation must be performed on step 100, you would enter 100 in the “from” field. 6. To: This field indicates the Step number up to which the current line in the Pricing Procedure is referencing its Condition Base Value. This is used for percentage-base Condition Types or subtotals. Together with “Fro” field, it defines a range of Condition Types values as reference. For example, you might want to base your cash discount on the gross value of a line item that is calculated from line 10 to 50. However, there are several Condition Types between line 50 and let’s say 600 where the cash discount Condition Type is listed. Enter “From” line 10 and “To: line 50 for the cash discount Condition Type, and the percentage is calculated from that base value. 7. Manual: Conditions that are given this indicator will be determined during pricing in the Sales Document either if they are entered manually or determined from other application such as Costing. 8. Required: If we check this field for a Condition Type, it becomes mandatory during pricing in Sales Document. In SAP releases prior to ECC 6.0, this column was labeled as “Mandatory”. 9. Statistical: This is a flag (A Check mark) that is used to signify if the pricing condition type is being used in the calculation or not. For example, the actual cost of the material (not the price but the cost price) is available in all pricing procedures, since this is used by Controlling (CO) to evaluate profitability. However, the value should not be relevant when pricing to the customer. So, if you need informational condition types for further analysis set them up in the pricing procedure as statistical.

195 Setting a Condition Type as statistical will not include its value in the calculated net value of the line item that is being charged to the customer. Accrual Condition Types are automatically statistical and don’t have to be flagged as such in the Pricing Procedure. 10. Print Id: The print flag is another check mark that is used to tell SAP if the particular pricing condition type should be printed on the final bill or not. As discussed in the previous example, the cost condition type should not be printed on the invoice. With the advent of advanced technologies like Smart Forms, Adobe Forms etc, this flag has almost no use (Since what is printed and what is not is decided mostly by these programs).

11. Subtotal: A sub-total as the name implies holds temporary totals before the final price is calculated. As shown in the picture below, the Gross price is a sub-total that results from the base price. The Net Price is a sub-total that is arrived at subtracting the Discount percentage off of the Gross Price. There are many additional steps that might be required to arrive at the final price. For example, if the item is taxable, should the tax be applied on the Gross Price or the Net Price..? That actually depends on the business scenario. However, the Sub-totals allow for easily identifying and computing values for further use.

196 12. Requirements: The “Requirements” field controls if and when a Condition Type is taken into account in the calculation of the total value of an item. The Requirement number refers to a piece of ABAP code that describes those requirements. There are several standard requirements to choose from, but you can create your own requirements to suit your business needs. Example: The condition types like PR00, K004 etc. are to be determined into sales document for those items which are relevant for pricing and even for Free Goods also because we need to know the worth of free goods offered to the customers. The relevancy of an item for pricing is controlled by item category with the field pricing. If an item is relevant for pricing, the value for this field will be “X” and for Free Goods it will be “B” So these Condition Types are to be determined for those items where the corresponding item category for the field “Pricing” contains either “X” or “B”. This is controlled by specifying the Routine “2” for the field requirement while placing these condition types in the Pricing Procedure. But the Condition Type R100 which gives 100 percent discount has to be determined only for free goods i.e. only for those items where the corresponding item category for the field “Pricing” contains “B”. This is controlled by specifying the routine “55” for the field “Requirement” while placing R100 in the Pricing Procedure. The following picture shows a simple requirement. There are 2 types of discount condition types – Retail and Wholesale. If the customer is retail, then apply that discount. If the customer is wholesale, then apply the other discount. So the actual total depends on who the Order’s customer is. The same can be achieved using many different ways, but this is sure one hardcoded way to do it.

197 13. Calculation Type (Alternative Calculation Type): Specifies an alternative formula to the standard formula that specifies how the condition amount of the Condition Type is calculated. For example, the profit margin of an item has to be calculated by deducting the cost of the item from the net value of the item in the sales order. This is controlled by specifying the Routine “11” for this field while placing the profit margin in the Pricing Procedure. The value 5.00 for the Base Price is derived based on condition records which we will see much further in the discussion. However, if the condition type should NOT be calculated based on a condition record, but should be calculated based on an external or internal logic, then an alternative calculation routine should be used. Each alternative calculation routine is a 3 digit number between 1 and 999 that contains a piece of code that does some calculation either internally or externally and returns a value. That value will be used to calculate the condition type as opposed to a condition record. A simple example for the same is US Taxes. Taxes in the US and Canada are based on Jurisdiction code. There are around 50000+ jurisdiction codes in the US alone (Based on all possible variations of City, County, State and District). And they change continuously. So it is not practical for companies to keep track of the changes in tax rates. There are external tax companies (Called Tax Vendors) that only does this. So it is wiser for companies to just call an external tax vendor using a remote function call, get the tax rate as relevant for the corresponding jurisdiction code and return that value to the pricing procedure.

198 14. Base Type (Alternative Condition Base Value): Specifies a formula for determining the condition basis as an alternative to the standard. For example, the condition base value of the condition type R100 is 100% discount which will not change depending on any key combination. So rather maintaining Condition Records for R100, we can maintain the Condition Base Value as 100% discount by specifying the routine “28” for this field while placing R100 in the Pricing Procedure. 15. Account Key: The Account Key enables the system to post the condition values of different Condition Types to the corresponding G/L accounts during “Revenue Account Determination Procedure”. When an invoice is created, the finance departments wants the corresponding Sales,

expenses, tax accounts etc to be updated on the fly. The account key in the pricing procedure (with the help of Account Determination) helps in identifying which G/L account this should the amount flow into. A simple example could be Account Key Description Customer A/C Group Material A/C Group G/L Account ERL Sales Wholesale Consumables 1000040 ERL Sales Wholesale Stationery 1000050 ERS Discounts Wholesale Consumables 1100040 ERS Discounts Wholesale Stationery 1100050

16. Accruals: The accrual key enables the system to post the rebate accruals to the corresponding G/L accounts. The accrual key for Rebate Condition Type (B003) is “ERU”.

199 Now that we know what the columns represent we need to allocate the Condition Types to the pricing procedure in the best way possible in order to meet both the needs of the business and the legal requirements. Let us create a simple Pricing Procedure using all the already specified columns: 1. Enter the Price Condition “ZST1” which is the copied version of Standard Price “PR00” as step 10. 2. As this is the price of the item, it should be mandatory, so indicate the Condition Type as Mandatory. 3. As it is quite possible some items are not relevant for pricing, it is advisable to assign a requirement indicating this condition type is not necessary for items and relevant for pricing. To do this, assign the requirement 002 to the “Rqt” column. 4. You may also assign the account key ERL to the “ActKy” column, in order to post these values to the revenue account. 5. Should you not have any further values you wish to add to your gross price, you may add a second step 40 (allow yourself some space between steps at this early stage) 6. On step 40 do not assign any further Condition Types, but in the description field you may specify the description “Gross Value”. 7. In all probability the customer will want to see this value printed on his documentation, so indicate S in the print column. 8. The gross value may also be used later to assign so assign the subtotal value 1 in the “SubTo” column. 9. Create a step 50 and assign the discount Condition Type K007. 10. Create a step 60 and assign another discount Condition Type K005. 11. It is possible you may have a negotiated discount between the sales person and the Sold-to Party at the time of creating the sales order. For this you may require a manual discount Condition Type, so allocate Condition Type RB00 as step 70. 12. For all these three steps the customer would want to see the discount he is obtaining so indicate them relevant for printing S in the Print Column. 13. Again for all these three steps it is advisable to indicate to the system from what value it should offer the discount, so specify 40 in the Fro column. 14. These Condition Types are only valid should the item in the sales order be relevant for pricing, so assign requirement 002 to the three new discounts. 15. You may assign the general ledger account key ERS to each condition type. 16. Do not forget that the condition type RB00 is manual, so you should enable the manual indicator on the pricing procedure. 17. Lastly, you may specify a “Total Discount” value in step 100.

200 You may now decide the customer should be liable for additional charges such as freight costs. 18. In step 110 add a Condition Type KF00 and in step 120 add HD00. As HD00 is manual Condition Type, you should indicate this on pricing procedure. 19. The values represented by freight should be updated into subtotal field 4, so assign 004 to the SubTo column for both condition types. 20. Both condition should also be posted to the general ledger in a specific revenue account for freight, so assign the conditions the account key ERF 21. You may wish to now have a net value total, so assign the net value description to a new step 130. This net value should use the net value alternative calculation type 002 as well as subtotal 002. It should be relevant for printing. You can now assign the taxes relevant to be levied against the customer. As taxes and their maintenance vary from place to place, we will use Condition Type MWST to represent our taxes 22. Add Condition Type MWST to step 140. 23. This Condition Type is mandatory, so select the mandatory indicator. 24. As the taxes are obtained on the basis of the delivering plant in order to obtain the country delivered from, it is advisable to use the requirement to check if the plant has been maintained in the sales order first, so assign the requirement 010 to step 140. 25. The alternative condition base value used by the standard system for the MWST is 16 26. As the revenue for the tax must be posted to a separate general ledger account, the account key assigned is MWS.

5. Pricing Procedure Determination: During the Sales Document Processing the system automatically determines a corresponding Pricing Procedure. A unique Pricing Procedure is determined by a combination of the following: Sales Organization, Distribution Channel, Division, Document Pricing Procedure Indicator and Customer Pricing Procedure Indicator.

201

Defining Customer Pricing Procedure: Before you can proceed with the Pricing Procedure Determination, you need to maintain the Customer Pricing Procedure Indicator. Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine and Assign Pricing ProcedureDefine Customer Pricing Procedure. Go to “New Entries” and create a new Customer Pricing Procedure. This value has to be specified in the required Customer Master Record. In this step we need to assign a single character alphanumeric key with a short description.

202 Defining Document Pricing Procedure Indicator: Now you can define a similar single-character alphanumeric key with a short description to represent the document type. Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine and Assign Pricing ProcedureDefine Document Pricing Procedure.

Go to “New Entries” and create a new Document Pricing Procedure. This Value has to be specified in required Sales Document Type.

Assign Document Pricing Procedure to Order Types: After the document pricing procedure indicator has been created, you need to assign it to sales document types. This will ensure that, for example, all sales order created using a standard sales order type OR, which has been assigned to a document pricing procedure, will use the same pricing procedure if created in same sales area and with same customer pricing procedure. Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine and Assign Pricing Procedure Assign Document Pricing Procedure to Order Types

203 Defining Pricing Procedure Determination: Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine and Assign Pricing ProcedureDefine Pricing Procedure Determination

Click on “New Entries” button and assign the Pricing Procedure to the combination of Sales Organization, Distribution Channel, Division, Document Pricing Procedure and Customer Pricing Procedure.

204

Optimizing Performance in the Condition Technique  Pricing is a function that occurs repeatedly and in great volume. Thus, the maintenance of condition techniques should be strictly governed to ensure the system resources are optimized A few tips on ensuring optimal performance in pricing would be the following: 

As standard SAP has pricing procedures with its own pricing condition types, ensure that no unnecessary condition types exist in the pricing procedure. Thus, copy the SAP standard pricing procedure and change it, being sure to delete the unneeded condition types.



Ensure that only automatic condition types have an associated access sequence, that is, that no manually used condition types have been incorrectly assigned an access sequence that has a resultant condition record that is ignored and overwritten.



Ensure the access sequence does not have unnecessary access steps. For example, if you have copied a SAP standard access sequence and the standard has an access searching for “product hierarchy” and you do not use “product hierarchy,” be sure to delete the step not required.



Be sure to use the exclusion indicator in the access sequence, thereby ensuring the system does not search for further condition records after having already found a valid condition record.

205 



Ensure that the condition table you are using does not have unnecessary searches for fields. For example, if you search for price per material, customer price group, and customer number, you are performing an extra unnecessary step when you should merely search for customer number and material Try to group fields in a condition table by table searched. This will allow the system to not have to fetch and reread tables



Be sure to use requirements as much as possible. The higher up in the process, the better. For example, a requirement in the pricing procedure to access a condition type (the highest level) will ensure no unnecessary reading of an access sequence. Thus, no unnecessary reading of all condition tables and all tables and fields in the condition table is carried out. Also, a requirement placed in the access sequence will ensure no unnecessary reading of the access step, and thus no unnecessary reading of all associated tables and fields is carried out.



Should your business be large enough to warrant it, you may investigate buffering of the prices in your system? This will ensure that all prices are accessed within a faster response time.

SAP Pricing Header Condition type vs. Item Condition Type SAP Pricing Condition types can be two types. Header condition types vs. Item Condition Types. Most condition types belong to Item Condition Type. Very few however are header condition type. Some examples of header condition type are HB00, RB00 and so on. The configuration that specifies whether a condition type is Header or Item Condition type is specified in the “Changes which can be made” section of the Condition type. Go to [V/06] t code and open the condition type say HB00

206

One important thing to notice here is that the condition type HB00 does not have an Access Sequence associated with it. So by definition this does NOT have a Condition Record. In this case, how is the price/discount data being determined? YES – You have guessed it right. These condition types are NOT automatically determined. They can ONLY be entered manually. That is the reason why the option “Manual Entries” has No Limitations as the option. Now, let’s consider a simple scenario and build up on top of it. Both these scenarios refer to a sales order like the one below.

207 Scenario 1: We are negotiating the price of a sales order with a customer and have finally decided to offer a discount of $100 in total. There are 2 line items in the sales Order. How can we distribute $100 as discount among all the line items proportionally? Use Condition type HB00 and apply it at the header level as shown below (Go to Header -> Conditions tab)

Let’s see how this discount has been distributed across the line items. Typically, they are distributed by value but this can be changed.

208 And line item 20 will have a value of 75 EUR for the HB00 being distributed to it. There can be many other bases on which the header discount can be distributed between line items. This can be configured in the SAP Pricing Procedure at the condition type level using Alternate Calculation Routine.

Activate Pricing for Item Categories  Here you can define per item category if the item in the sales order is relevant for pricing, statistics and costing Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine Pricing by Item categoryActivate Pricing for Item Categories

You will see a table like the one shown in above figure. For each item category, you can define if the item should be relevant for pricing. Should the items not be relevant for pricing, these items can be indicated with a blank. Should standard pricing be carried out for the item, you can indicate these item categories with an X. The statistical value column adjoining the pricing column represents if the item must be used for statistical purposes, that is, in updating the logistics information system (sales information systems and so on). A blank entry indicates

209 that the item is relevant for statistics updating and the value of the item will be added to the header totals. Items that would not be relevant for pricing would be text items Activating Cost Determination for Item Categories Path: SPROIMGSales and DistributionBasic FunctionsPricingPricing ControlDefine Pricing by Item categoryActivate Cost Determination for Item Categories

Here you can determine if pricing is carried out for the particular item category while determining if the item should be relevant for cost determination. If you want the cost of the item to be determined, you must indicate that the item is relevant with an X.  The cost of the item will only be available should you have a condition type in the pricing procedure that determines cost, such as the SAP standard condition type VPRS. The cost of the item is taken automatically by the system from the fixed cost price of the material in the material master record. Should the material not have a fixed cost, the system will then take the cost price from the moving average price in the purchase information record.

210 Condition Exclusion Groups  It is quite possible that you may have more than one condition type in your pricing procedure offering a discount to a customer. Should the discounts be automatically determined, there is the risk that the customer will receive all the relevant discounts and thus purchase the product lower than he should. By using condition exclusion groups, you can ensure the customer does not receive all discounts, but instead only receives, for example (the best of the four discount condition types). Path: SPROIMGSales and DistributionBasic FunctionsPricingCondition ExclusionCondition Exclusion for Groups of Conditions

 A condition exclusion group is merely a grouping of condition types that are compared to each other during pricing and result in the exclusion of particular condition types within a group or entire groups  There are four possible methods of using the condition exclusion groups: Selection of the most (or least) favorable condition type within a condition exclusion group Selection of the most (or least) favorable condition record of a condition type, if more valid condition records exist (such as selection from different condition records of the condition type PR00)

211 Selection of the most (or least) favorable of the two condition exclusion groups (in this case, all condition types of the two groups are cumulated and the totals are compared) An exclusion procedure in which if a condition type in the first group exists in the document, all condition types in the second group are set to inactive

Defining Condition Exclusion Groups Path: SPROIMGSales and DistributionBasic FunctionsPricingCondition ExclusionCondition Exclusion for Groups of Conditions Defining Condition Exclusion Groups

We will use the example of the most (or least) favorable condition type within a condition exclusion group as an example, using the two discount condition types K005 and K007. Thus, we will place both these condition types in an exclusion group Proceed to define an exclusion group by using a four-character alphanumeric key.

212 Assigning Condition Types to Exclusion Groups You can now assign the condition types to the exclusion group. Path: SPROIMGSales and DistributionBasic FunctionsPricingCondition ExclusionCondition Exclusion for Groups of Conditions Assigning Condition Types to Exclusion Groups

Assign the relevant condition type to the relevant condition exclusion group Maintain Condition Exclusion for Pricing Procedures  After completing the assignment of the condition types to the exclusion group, proceed with assigning the condition exclusion group to the pricing procedure using the following menu path: Path: SPROIMGSales and DistributionBasic FunctionsPricingCondition ExclusionCondition Exclusion for Groups of Conditions Maintain Condition Exclusion for Pricing Procedures

213

 After selecting the pricing procedure for which you want the condition exclusion to be active, select the button “Exclusion.”

214  Do not forget the condition types that you want the system to compare must exist in the pricing procedure and have valid condition records created for them.  If you now create a sales order using the same pricing procedure that the exclusion group is assigned to, you will find that the condition offering the most favorable discount to the customer is represented in the pricing procedure  One can see in below figure, that the condition type K007 has offered a discount of 50 percent off the sale price or a real value of 150 INR, while condition type K005 has offered a real value discount 45 INR. The system then takes the best discount for the customer between the two which is K007, and makes the other discount, K005, inactive.

This can be seen by double-clicking on K005. You will then be faced with the screen in below Figure. Note the entry “Inactive A condition exclusion item.”

215

 It is possible to see the advantages of the exclusion groups in the previous example. Imagine the product has a lower sales price of, say, 80 INR. The result would be that condition type K007 offers a 50 percent discount, which is a real value of 40 INR, while K005 still offers a discount of 45 INR. In this case, K007 would be inactive and the system would use K005  When using the best condition record within a condition type, only use one condition type in the exclusion group. Also note that you must deactivate the Exclusive indicator on the access sequence assigned to that condition type. Otherwise, the system will merely find the first condition record and stop searching for other records  If the exclusive indicators are not set, but condition record exists for the condition tables in the access sequence, and no condition exclusion group exists for the condition type, the system will bring all valid condition records into the sales document

Creating New Price List Type in SAP Price List type is a very important SAP SD Pricing master data. They are freely definable and assigned to the Customer Master. So an SAP Sales Order created for a particular customer will have that price list type available in pricing. Here are the steps used to define them. Step No. 1: Go to [SPROIMGSales and DistributionBasic FunctionsPricingMaintain price relevant master-data fields]

216

Step No.2: Choose “Define Price List Categories for Customers” and click on Choose

Step No.3: Click on new entries and create your own price list type.

217 Condition Supplements A condition supplements is a group of conditions that you want to apply every time a certain condition is found. For example, if you define a material price, you would enter condition records for every material and the associated price for those materials. If for one of those materials you also wanted to include a discount every time that price is determined, you can enter additional Condition Type discount as condition supplement. When SAP determines the condition records in the pricing procedure, it will automatically also include the discount condition record.

Changing Condition Records Using Condition Type Path: Easy AccessLogisticsSales and DistributionMaster Data ConditionSelect using Condition TypeVK12-Change.

After Condition Records were created, it might be necessary to make changes to them, such as price, Validity of the record or Scales. To do that either execute transaction “VK12” or use the SAP menu path. Enter the Condition Type you want to change Condition Records for and either hit enter or click on the “Key Combinations” button. Tables of the Access Sequence attached to the Condition Type are displayed. Select the one you would like to change and click the check mark. On the following below screen, you will see a number of selection fields according to selected Condition Table in the previous pop-up window

218 The Header fields of the Condition Table are mandatory on the selection screen. The fields marked as line items in the Technical view of the Condition Table are optional. In our example of the “ZCT1” Condition type with the material specific key combination, the “Sales Organization” and “Distribution Channel” are mandatory selection fields and “Material Number” is the optional selection field. The Valid-On date is the selection date that valid Condition Records should be looked for. The condition Records will have to have the same or an earlier From-date than the selected Valid-On date and the same or a later Valid-To date in order to be selected. Make your selections and click on the “Execute” button. The Condition Records based on our selections are displayed in below figure. Since no material number was specified, all material-specific list prices are displayed. It is not possible to change the currency or UoM of an existing Condition Record, but you can change the rate and the Validity Period. These changes can be made manually for each Condition Record or they can be changed all at once. To do it manually, just overwrite the rate or the Validity dates. In order to change the multiple Condition Records at once, select all the applicable Condition Records either one by one or by clicking on the “Select All” button.

To change the Condition Record amount by a specific value or a percentage, select the “Change Amount” button at the bottom of screen that looks like a calculator.

219

In the resulting pop-up (as shown in above figure) you can enter either a percentage in field “Percentage” or an amount in field “Absolute Amount.” To increase the Condition Record value, enter a positive amount. In order to reduce the value, enter the amount with a negative sign. If the Condition Record value should be changed by a percentage, rounding issues may occur. For these instances you can enter a Rounding Rule in the field with the same name. This Rounding Rule is a piece of ABAP code that can, for example, round the changed amount to the nearest nickel. It is possible to create your own Rounding Rules by using transaction “VOFM”, Menu Formulas->Rounding Rules. The resulting screen (in below figure) shows the old and new values for each selected Condition Record. Use the back button from this screen to return to the “Change Overview” screen which will then display newly changed Condition Record values.

220

Unfortunately, if you want to change the amount of a Condition Record to a specific value, this “Change Price” function cannot be used; the desired amounts have to be manually entered. Also, be aware that if you change the value of a Condition Record that has scales, you either need to use the “Change Amount” function or go to the “Scales” screen to manually adjust each scale level. If you just manually change the value on the “Change List Price (ZCT1): Overview” screen, it will only change the first Scale level of the Condition Record, leaving the other levels unchanged. In order to change any of the Validity dates, select the applicable Condition Records and click on the “Change Validity” button on the bottom of the aforementioned “Change List Price” screen. It is important to use this button on the bottom of screen since there is an identicallooking button on the top of screen, called “Validity Periods.” Clicking that button will change only the first Condition Record on the screen, ignoring the rest, although they might all be selected.

221

On the resulting pop-up screen (in above figure), change the Valid-from, the Valid-To or both dates. Click the check mark and the changed Validity dates are reflected on the “Change List Price” screen. If one or more Condition Records should be deleted, select them on the “Change List Price” screen and click on the “Delete Row” button. If the Condition Types was not configured to delete the Condition Record from the data base, the Condition Record will be marked for deletion. This is indicated with a check mark in the “Deletion” column. To reverse a deleted record, select it and click the “Undo Deletion” button. The check mark in the “DeletionID” column is then removed. Although “VK12” is a change transaction, fields are open to potentially enter new Condition Records. If the same key as an existing Condition Record is entered again, a message is issued, stating that “The Condition is being processed in the current session.” The system will then delete the last instance of this Condition Record key. It is possible to add Condition Records of different keys in the change transaction but it is recommended not to do so.

222 Creating Condition Records with Template Using Condition Type Path: Easy AccessLogisticsSales and DistributionMaster Data ConditionSelect using Condition TypeVK14-Display.

This option of creating a Condition Record uses existing Condition Records as a template or reference. It is the ideal tool to execute price increases or decreases. To execute this transaction, also known as “Create Condition Records with Reference”, execute either transaction “VK14” or use the SAP Menu Path. Enter the Condition Type you would like to create Condition Records for, hit enter or click on “Key Combination” button and select the appropriate key combination from the resulting pop-up screen. The resulting selection screen is identical to the one for transaction “VK12” with one addition. The field “Keep End of Validity Period” determines the Valid-To date of the new Condition Records that will be created. If this field is selected, then “Valid-To” field of the new Condition Record is taken from the referenced Condition Record. If the field is unchecked, the “Valid-To” field for the Condition Record is proposed from the customized setting of the Condition Type. In short, if the referenced Condition Record Valid-To date is 12/31/2008 and the field is turned on, the new Condition Record Valid-To date would be 12/31/2008 as well. Un-checking the field would default the 12/31/9999 date, as defined in configuration for our Condition Type as the Valid-To date. Enter your appropriate selection criteria and execute. One final note for the “Condition Record Create with Reference” option. Don’t mistake it with the “Copy Condition Records” function. The difference is that when you “Create with

223 Template,” you create new Condition Records for the same Condition Table key, whereas when you copy Condition Records, you create Condition Records for different key.

The Condition Record Change Log Changes to a Condition Record can be viewed in the change log either the change or display transaction of a Condition record. From any screen within the Condition Record, select menu EnvironmentChangesPer Condition Record. The “Change Documents for Conditions” screen shown below is displayed. The tree menu displays the date and time of a change in the “Date/Time” column. In the next column, the SAP user ID and the transaction code with which the change was made are displayed. Besides this information, the Condition Type, Condition Table for which the Condition Record was created, and the Validity Period of the Condition Record are all displayed. If the detailed information for the change is not displayed, click on the “Expand All” button or press “F9.” The sub-level for this Change Record displays the description of the change, with its respective old and new value. Looking at the figure below for one of the “ZCT1” condition Records, it clearly indicates that that the price for Material “MAT-003” is changed.

If you would like to see changes made to more than the one Condition Record you selected, use the EnvironmentChangesChange Report menu option from any of the Condition Records screen. This report can also be accesses outside of the Condition Records display or change transactions by executing report “RV16ACHD.” The selection screen of this report is displayed below

224

I advise using as many selection criteria as possible to reduce the runtime of this report. The date of changes and Condition Type selections are a good start. From a technical point of view, the information for Condition Record changes is stored in the change tables “CDHDR” and “CDPOS”. The change document object for pricing changes in “COND_A.” This information is useful when you want to create your own change reports.

225 Questions and Exercise Business Scenario Company ABC has decided to give discount to customer 1400. For this it has been decided to create a new Pricing Procedure and include this discount condition type in the pricing procedure. You will need to design a pricing model that includes creating 1. 2. 3. 4. 5.

Condition Table Access Sequence Condition Type Pricing Procedure Condition Records

And finally test and see if the Condition Type is getting determined automatically in the Sales Order. 1. Create a condition table 9## and include the fields Sales Organization, Distribution Channel, Division and Customer. Select the fields Sales Organization, Distribution Channel, Division and Customer from the field catalog. Give a description to the table. Click on Generate button. Use development class Z001 when prompted and save the table. 2. Create an access sequence Z### and assign the condition table created in Step 1 to this access sequence. Click on ‘New entries’, enter the Access Sequence and description. Select ‘Accesses’ (on the left hand side) and enter the condition table created in Step 1. Select ‘Fields’ and you should be able to see the fields defined for the condition table created earlier. Save the access sequence. 3. Create and save a new condition type, ZD## and then assign access sequence created in previous step to it. Select condition type K007, click on ‘Copy As’ enter condition type ZD## and description. Change the access sequence used for condition type from K007 to Z###. Save the condition type. 4. Create a new pricing procedure Z##PRC and assign the condition type ZD## to it.

226 Select existing pricing procedure RVAA01 and click on ‘Copy As’, enter pricing procedure Z##PRC and description. Add your new condition type ZD## to your new pricing procedure Z##PRC, by replacing the K007 condition type with ZD##. Save the pricing procedure. 5. Creating a new customer pricing procedure key ‘A’. If it already exists use the same. Click on new entries and enter the customer pricing procedure key ‘A’ and description and then save. 6. Pricing procedure determination. Enter a Sales area, the document pricing procedure key ‘A’, and the customer Pricing Procedure key created in the earlier step and the new Pricing Procedure Z##PRC. 7. Change your customer to use the new pricing procedure. For customer 1400, change the customer pricing procedure key to the key that you created in Step 5. (T-code: xd02). 8. Create and save a discount condition record using your ZD## condition type for sales organization entered during Pricing Procedure determination (Step 6), sold-to-party 1400. The discount percentage should be 5%. (T-code: VK11). 9. Testing: Create a standard order. Customer: 1400 PO number: ### Requested delivery date: In one week Material: M-01 Quantity: 10 Business Scenario 2 ABC Computers wants to price its desktop range of products (material group 00200) and has decided on the following Logic. All prices are in USD. Logic: First pricing should be checked for Customer-Material Combination. If such a price is not found, then look for material group specific price for the material (i.e. if the material is found under a certain material group, then select that price list). If such a price is also not found, then default to the Base Price List. Find below the examples of their price lists. Please understand that these Price lists are different from the SAP Pricelist type field in the SAP Customer Master.

227 Base Price List Material

Price

M-01

100

M-02

120

M-03

130

M-04

140

Customer Specific Price List Material

Customer ( sold-to )

Price

M-01

1400

90

M-02

1400

100

M-03

1400

110

M-04

1400

120

SAP Material Group Specific Price List Material

Material Group

Price

M-01

00103

95

M-02

00207

85

M-03

00200

80

M-04

00200

130

228 Question 1: Configure an SAP Pricing Condition type and corresponding SAP Access Sequence and associate it to the SAP Pricing Condition tables that can cater to the scenario above and provide the following 1. The SAP Pricing Condition type you have configured 2. The SAP Access Sequence you have configured 3. The SAP Pricing Condition tables you have configured Question 2: Configure a new SAP Pricing Procedure and include the configuration you have done on Q.1 above 1. Provide the SAP Pricing Procedure you have created Question 3: Configure the SAP Pricing Procedure Determination so that for Customer 123456, when a sales order of type ZYYY is created, the pricing procedure will be determined. List the configuration to do the same below. Question 4: Create an SAP Sales Order and ensure that the pricing procedure has been determined 1. Give the SAP Sales Order Number 2. How did you determine in the transaction that the pricing procedure you have configured is being used in the transaction?

229 Special Processes Using the Pricing Condition Technique

Free Goods Determination One of the most requested pricing functionalities in the SAP releases prior to 4.0 was the “buy one get one free” scenario. Development or manual work-around was necessary to accomplish this functionality. The Free Goods functionality offers the opportunity to give a customer product free or charge, based on specific purchase requirements. For Free goods, two different scenarios have to be distinguished: Inclusive Free Goods and Exclusive Free Goods.

Inclusive Free Goods: This is called as Inclusive Free Goods because a proportion of the Sales Order Quantity is given away as Free Goods, meaning the customer does not have to pay for it. He only pays for some of the goods requested; the rest of the goods are free of charge. Example: A customer orders 100 boxes of cookies. Since the customer ordered a full pallet, 10 of these 100 boxes will be free of charge, meaning the customer only has to pay for 90 boxes. The Unit of Measure of the material delivered as Free Goods will also match the UoM of the ordered material.

Exclusive Free Goods: This is called as Exclusive Free Goods because in addition to the goods ordered, a specified quantity of materials is given away as Free Goods. The additional quantities in excess of the ordered quantities are delivered as Free Goods. The customer pays for the goods ordered and is given extra goods free of charge. Example: A customer orders 100 boxes of Vanilla cookies. In addition, he will receive 10 boxes of Chocolate Chip Cookies free of charge. He will receive a total of 110 boxes but will pay only for 100. Contrary to the Inclusive Free Goods scenario, the material given away as Free Goods can be either the same material as material ordered or a different material. In the Inclusive scenario, the ordered and Free Goods are always same materials.

230 Free Goods Configuration: The configuration steps for the Free Goods functionality are similar to those for pricing. The Condition Technique is used as well, so I will not go into great detail for every step of the Configuration but will only point out the differences for the Free Goods functionality. In order to build Condition Tables, a separate Field Catalog is available, accesses via Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsCondition Technique for Free Goods Maintain Field Catalog. All fields available for the pricing Field Catalog are also available for the Free Goods Field Catalog.

1. Condition Tables: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsCondition Technique for Free Goods Maintain Condition Tables.

231

The Free Goods Condition Tables are created the same way as pricing Condition Tables. The only difference is that there is no Release Status available for the Free Goods Condition Table. After the Condition Table is generated, the Condition Table number starts with “KOTN” instead of “A” as with the pricing Condition Table.

2. Access Sequence: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsCondition Technique for Free Goods Maintain Access Sequence.

232 The Access Sequence is created just like a pricing Access Sequence. The difference here is that there is no Exclusion Indicator for the Condition Tables in Access Sequence.

3. Condition Types: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsCondition Technique for Free Goods Maintain Condition Types.

A big difference exists between the Condition Type configuration of the Free Goods Condition Type and the one for pricing. The only option that are available for Free Goods Condition Types are to assign an Access Sequence to condition Type, as well as assign a default date for the Valid-From and the Valid-To date for the later creation of Free Goods Condition Record. The same date options as for the “Valid-From” and “Valid-To” fields in the Pricing Condition Type configuration are available.

4. Pricing Procedure Definition: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsCondition Technique for Free Goods Maintain Pricing Procedure

233

Another difference compared to pricing is the configuration of the Free Goods Procedure. As can be seen in field “Usage” in above figure, the Procedures for Free Goods have a different usage indicator, namely “N” compared to usage “A” for pricing. On this screen, there is also no transaction-specific Pricing Procedure Indicator and no “Pricing Type” field, as is the case with a pricing-related Pricing Procedure.

234 By selecting a Free Goods Procedure and double-clicking the “Control Data” folder in the left window pane, the detail of the Pricing Procedure shows that only a step and counter number, the Free Goods Condition Type, as well as a potential requirement options are unique o Free Goods and don’t include any of the pricing-related requirements. The Free Goods requirements can be maintained via transaction “VOFM” with menu RequirementsFree Goods. In addition to the Free Goods Procedure, additional configuration is necessary in regular Pricing Procedure in which Free Goods are calculated. The standard Condition Type “R100” discounts 100% of the sales price of the item that is given away as Free Goods. Figure displays the configuration of “R100” Condition Type in Standard Pricing Procedure “RVAA01”. Requirement “55” ensures the 100% discount only applies on Free Goods items by checking for Pricing Type “B” of the item category. Condition Base Value “28” automatically applies a “100%” discount without having to create a Condition Record for it.

Pricing Condition Type “NRAB” is required if a Free Goods scenarios is used where no item is generated for the Free Goods quantity. In this scenario, the discount is given on the item. To

235 accomplish this, it is necessary to maintain Pricing Requirement “59” and Condition Base Value “29” for the “NRAB” Condition Type in the respective Pricing Procedures. This formula calculates the discount based on the Free Goods of the Free Goods Condition Record. The “NRAB” Condition Type also has the Condition Category “f”, which ensures that this Condition Type is re-determined every time the main item quantity changes, since this could have an effect on the Free Goods quantity.

5. Activate Free Goods Determination: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsCondition Technique for Free Goods Activate Free Goods Determination.

As with the Pricing Procedure in pricing, the Free Goods Pricing Procedure needs to be assigned to a Combination of Sales Area, Customer Pricing Indicator and Document Pricing Procedure Indicator. The combinations of field for assignment are the same as for pricing. The difference for Free Goods is that no pricing Condition Type can be defaulted as in for pricing.

236 For our example, the standard Free Goods Procedure “NA0001” is assigned to Sales Area, Customer Pricing Indicator and Document Pricing Procedure Indicator.

6. Item Category for Free Goods Item: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsDetermine Item Category for Free goods

Items that are delivered as Free Goods have to be identified as such. A Free Goods item is displayed as a separate line item on a Sales Order. It is a sub-item of the main Sales Order line item. The Free Goods items are also Delivery-relevant and are copied to Billing Document. In the standard SAP system this item category is “TANN”. Figure shows the assignment of the “TANN” item category for Sales Order Type “OR,” item category group “NORM,” usage “FREE” and higher level item category “TAN.” This means the Free Goods item, if set up will be a sub-item of a regular item with item category “TANN.”

237 7. Pricing for Free Goods Item Category: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsControl Free Goods PricingControl Pricing for Free Goods Item category

The “TANN” item category must also be configured corresponding from a pricing perspective. This configuration step defines if pricing is carried out for a line item of that item category. The standard item category “TAN” and all other regular item categories have an “X” for standard pricing in field “Pricing.” The Free Goods item category “TANN”, however, has to have value “B” in this field as seen in figure. The “Statistical Value” field in the same figure defines if the value of the line item should be taken into account or not when the net value of the item is determined. Since we want to affect the net value, this field is left blank.

8. Cost of Free Goods Item to Main Item: Path: SPROIMGSales and DistributionBasic FunctionsFree GoodsControl Free Goods PricingSet Transfer of Costs to Main Item.

238

Another Configuration step to set up Free Goods is the determination of how the cost of the Free Goods item should be copied to the main item. This is done in copy control from the Delivery to the Billing Document. Select the Copy control for your respective Delivery and Billing Document Types and select the appropriate item category for Free Goods item (in our example “TANN”). Select field “Cumulate Cost” (See Figure) so the cost of these items is copied to the main item.

Setting up Inclusive Free Goods Condition Records Path: Easy AccessLogisticsSales and DistributionMaster DataConditionsFree GoodsVBN1-Create

239

To create a Free Goods Condition Record, either execute transaction “VBN1” or use the path. On the resulting screen, enter “NA00” as the Free Goods Condition Type in field “Discount Type.” Since only one Condition Table exists for the Access Sequence assigned to Free Goods Condition Type “NA00”, figure shown below is displayed after pressing enter. The only valid key combination for “NA00” is Sales Organization, Distribution Channel, Customer and Material. In the top part of the screen, enter a Sales Organization, Distribution Channel and the Customer number of who should receive the Free Goods. In addition, maintain the Valid-From and Valid-To dates in the respective field. The default type for Free Goods Condition Record is the “Inclusive Free Goods” type. To switch to the “Exclusive Free Goods” type, click on the “Exclusive” button on the top of the screen. But first let us take a look at an Inclusive Record. Enter the Material Number on which Free Goods should be based in field “Material.” The “Min. Qty” field defines the minimum quantity of this material that needs to be purchased in order for Free Goods to kick in. In other words, if the minimum quantity is defined as 100 and only 50 units are ordered, no Free Goods will be given.

240 The “From” field defines the Free Goods quantity. The description of this field is a bit misleading since it is not the quantity of goods that are given away free of charge, but the base quantity the Free Goods are determined from. Example: For every 100 units, 10 units are given away as Free Goods. The 100 units will be maintained in the “From” field.  The Unit of Measure of the Free Goods quantity is entered in field “UnitFG”. Although a material number is part of the Condition Table key, its base UoM is not defaulted as it is during the creation of a pricing Condition Record and has to be entered manually. The quantity of Free Goods given away is maintained in field “are free goods”. Looking at our example above, the 10 units that should be given away as Free Goods need to be entered in this field The “AddWtyUnit” field maintains the UoM for the Free Goods given away. For an Inclusive Free Goods Condition Record, this UoM has to be the same as in field “UnitFg”. If you attempt to enter a different UoM, the system will issue a respective error message. The “in %” column shows the Free Goods percentage rate and is also called “Free Goods Factor.” For an Inclusive Free Goods Condition Record, it is calculated as: (Free Goods Quantity * Additional Free Goods Quantity)/100. In our example that would be: 100 * 10/100 = 10%. This factor is important for Free Goods category “3” in this field “Free Goods” for which no additional Free Goods line item is being generated, but the Free Goods Discount is calculated on the main line item. The “Calc.Rule” field defines the Calculation Type for determining the Free Goods quantity. The standard SAP system delivers three of these rules. Rule “1” is automatically defaulted. Even if you removed the rule and hit enter again, rule “1” defaults. The rule is best explained again with an example. Example: For every 100 units, 4 units are Free Goods. A Sales Order is entered for 230 units. Free Goods Quantity = 100 units Additional Quantity = 4 units Document Quantity = 230 units Calculation Rule “1”, called “Proportional” or “Pro Rata,” determines the number of Free Goods as 9: (230/100) * 4 = 9.2, rounded down = 9 units

241 Calculation Rule “2” named “Unit reference” only taken full increments of the Free Goods Quantity into account. The calculation here is (200/100) * 4 = 8 units The last standard Calculation Rule “3” (“Whole Units”) is the most stringent. It only allows Free Goods to be calculated if the document quantity is a multiple of the Free Goods quantity. Since the Sales Order quantity of 230 units is not a multiple of 100, no Free Goods are allowed. Only Document quantities of 300, 400, etc. would calculate Free Goods. These rules and any custom rules that need to be added can be maintained via transaction “VOFM” with menu FormulasCalc.rule RebateInKd. The “Free Goods” field defines if the Condition Record is for an Inclusive (Value “1” or “3”) or an Exclusive (Value “2”) Free Goods scenario. The “FGDelyCont” field (Free Goods Delivery Control) control if and how the Free Goods line item is copied to a Delivery Note. A blank entry, which is the default, allows the Free Goods item to be delivered regardless of the main Sales Order line item. Other options: the main item has to be partially delivered in order to deliver the Free Goods line item, or the Free Goods item is delivered proportionally to the Delivery quantity of the main item. Example: If 10 Free Goods items are delivered for every 100 regular items, only 1 Free Good item would be delivered if only 10 regular items are available at delivery time. After all necessary data is entered in the Free Goods Condition Record, save the record. Entering a Sales Order for the customer and material for which the Free Goods Condition Record was created nicely displays the regular and the Free Goods item in Figure. Although item 10 was originally entered with an order quantity of 100 PC, the system finds the Free Goods Condition Record, identifies it as an Inclusive Condition Record and therefore changes the order quantity for line item 10 to 90PC and adds the Free Goods sub-item with the Free Goods quantity of 10 PC. As you can in column “HL Itm” (Higher Level Item), line item 11 refers to the main line item 10.

242

Setting up Inclusive Free Goods Condition Records without Item Generation A different flavor of the Inclusive Free Goods Condition Record is one for which no additional Free Goods line item should be generated. In this scenario, the same Condition Record is created as in figure (Free Goods Condition Record) with the exception of value “3” in field “Free Goods.” The resulting Sales Order then only displays one line item with the originally ordered quantity of 100 PC. As you can see in figure below that only one line item is generated.

243 Looking at the pricing of this line item in Figure below shows that the “NRAB” discount of 10% (which is the Free Goods factor as displayed in the respective Free Goods Condition Record) applied on the main item. As you can see in figure below that the Net Value is shown as 36,000 INR because 10 PC are given as Free Goods whose value is reflected in “NRAB” Condition Type as 4000 INR. Although the system do not generate a sub-item line but still 10 PC are given as Free Goods.

Looking at the pricing detail of the “NRAB” Condition Type in Figure, we see the variant factor is 10, as indicated in the respective Free Goods Condition Record.

244

Setting up Exclusive Free Goods Condition Records The Exclusive Free Goods Condition Record also comes in two variants. First, we will set up a Condition record that will give additional quantities of the same material as Free Goods. The transaction to maintain this record is the same as the Inclusive Free Goods Record. As mentioned above, click on the “Exclusive” button to switch to Exclusive Free Goods Condition record maintenance. This option adds an additional field “AddMat FrGd” for the option to add an additional material for Free Goods, and a field for the respective material description. The “AddMat FrGd” field is grayed-out after the Condition Record view is switched from Inclusive to Exclusive, due to the default Inclusive rules in field “Free Goods.” Switch this rule to “2” for Exclusive. This opens up the field “AddMat FrGd”. For the first Exclusive scenario, leave this field blank.

245

Figure of a Sales Order displays the same material twice, but compared to Inclusive scenarios, line item 10 shows the originally ordered quantity of 100 PC, and a second line item with 10 PC of Free Goods.

246 The second Exclusive Free Goods scenario involves a different Free Goods material than the one originally ordered. Looking at Figure, we can see that for each ordered Monitors of 100 PC, 10 PC of Key Boards are given away as Free Goods.

Looking at Figure at the application of this Condition Record in a Sales Order, the only difference to the first Exclusive scenario is that the second line item is for a different material. Line item 10 still has the originally ordered 100 PC and the second line item is for the 10 PC free of charge.

247 In all scenarios that generated a separate Free Goods item, the second line item is a sub-item of the originally ordered line item. This is evident when looking at column “HL Itm” for the higher level item. For line item 20, the higher level item number is 10, linking this item to the main item. Also identical for all the Free Goods scenarios is the pricing of the Free Goods line item. The item that is originally ordered prices as any other regular item of your Pricing Procedure. However, as can be seen in figure of the Free Goods line item, the “R100” 100% discount Condition Type applies. This is due to the pricing requirement that checks for the “carry out pricing” flag “B” of Free Goods item categories, which is item category “TANN.”

As helpful as the Free Goods functionality is, there are certain limitations I would like to point out: 1. Free Goods can only support 1:1 ratio between an ordered item and a Free Goods item. For example, it is not possible to define that the purchase of a material 1 results in Free Goods material 2 and 3. Also, the scenario that bases Free Goods material 3 on the purchase of material 1 and material 2 is not supported.

248 2. Free Goods are not supported in combinations with material structures such as product selection, Bill of Material (BOM) variants with BOM explosion etc. 3. Free Goods are only supported for Sales Orders with document category “C.” Quotations or Inquiries are therefore not supported. 4. Free Goods are not supported for deliveries without reference to a Sales Order, such as “NL” Delivery Type. 5. Free Goods cannot be used in make-to-order production, third-party order processing or scheduling agreements.

Material Listing and Exclusion Material listing and exclusion lets you control which materials specific customers may or may not buy. Material Listing and exclusion is configuring the system to restrict customer’s buying choices. For example, if we include a set of materials in the “Listing” list of a customer, then those are the only materials that customer can buy from us. Similarly if we include a set of materials in the “Exclusion” list of a customer, then those materials cannot be bought from us by that customer.

249 As you can from the Business Scenario section, we are forcing the customer to only order materials M-01, M-02 and M-03. These are in the “Include” list (signified in green). Similarly, we can force the customer to not order from the “Exclude” list. Those materials are M-04, M-05, M-06. At the time of ordering, if the user enters materials any other materials other than M-01, M-02 or M-03 for the customer for which they include list is configured, the system throws up an error. Same with the exclude list. They include and exclude list are complementary and typically not used together. Let’s explore the configuration. The configuration for material listing and exclusion follows the familiar condition technique in SAP. The image below shows the menu path for configuring the Material Listing and Exclusion

1. Maintain Condition Tables for Listing/ Exclusion

Condition Tables are necessary to create the new combination for which this listing or exclusion needs to kick in. Typically this is only done with a Customer and a number of other

250 fields (You can freely choose from the Field Catalog). Let’s start by examining standard condition table. Give the table name as 001 and press enter. Table 001 contains fields of material and customer. Condition Table 001 is the SAP standard table. This table 001 comprises of fields Customer and Material. This is the simplest listing possible. There could be more complex combinations like Customer Hierarchy/Material combination or any other possible combination based on the field catalog.

Come back and click on Maintain Access Sequences for Listing/Exclusion 2. Access Sequence: Depending on the requirement we need to create one or two Access Sequences with the corresponding Condition Tables to be used for Listing/Exclusion. You may copy an existing Access Sequence, followed by changing the name of the newly created Access Sequence. This will also copy all subsequent entries such as tables and fields. Alternatively, should you not want to copy the Access Sequence, you may create your own. Either way, after creating or copying and changing, select Accesses on the left side of the screen. In our example we will use the Access Sequence A001 called Listing (This does not mean we can only use this Access Sequence for listing. We can also use this Access Sequence for Exclusion. But in order to keep to clear customizing rules we will have an individual Access Sequence for Listing and Exclusion). Select A001 and click on Accesses.

251

Access sequence A001 contains 501 and 001 tables

Similarly click on B001 and click on accesses. Access sequence B001 contains table 001.

Come back and click on Maintain Listing / exclusion types 3. Maintain Listing / Exclusion Types: We need to define two Condition Types, one each for Listing and Exclusion and assign the corresponding Access Sequences.

252

 Access sequence A001 and B001 are assigned to condition type A001 and B001. Come back and click on Procedures for Maintaining Listing/Exclusion 4. Procedures for Maintaining Listing/Exclusion: We need to define two Procedures, one each for Listing and Exclusion and place the corresponding Condition Types in them.  These are the standard Procedures.

Here we will copy the standard procedures. Select A00001 and click on copy, name it as ZA0001. Press enter and click on copy all

Press enter

253

Listing Procedure ZA0001 is created. Similarly copy B00001 to ZB0001. Press enter and click on copy all. Press enter. Click on save New exclusion Procedure ZB0001 is created These Exclusive and Listing procedures has to be assigned to order type.

Select your procedure and click on control data

254

Standard condition type A001 is assigned to listing procedure

Similarly Standard condition type B001 is assigned to Exclusive Procedure

5. Activate Listing/Exclusion by Sales Document Type: Select the required Sales Document Type and assign the Procedures for Listing and Exclusion

255

Maintain Condition Records for Material Listing and Exclusion Path: Easy AccessLogisticsSales and DistributionMaster DataProductsListing and ExclusionVB01-Create

256 Specify the Condition Type for Listing and also specify the required key combination.

On the Fast Entry screen enter the required materials in Listing and save it

257 Come back to previous screen, specify the Condition Type for Exclusion and also specify the required key combination.

On the Fast Entry screen enter the required materials in Exclusion and save it

258 Start creating a sales order for the customer for which you have created the condition

records. If you enter the materials that have been listed, you should get no error. However, if you enter any other materials you should get an error message. Similarly, if you enter a material that has been excluded in the sales order you should get an error message also – however this time it is because this material is in the excluded list. When creating the sales order the system will first check to see if the material the customer is ordering is allowed for the sales area the order is placed in. Then it checks to see if the material is excluded for that customer and lastly it checks to see if the material is on a list of allowed materials for the respective customers. Example of the error message for a material that is in the Exclusion List

As the Material “MAT—002” was in Exclusion list, when you enter the material in Sales Order for required Customer the system throws an error message as shown in above figure. Example of the error message for a material that is in the Listing List

259 As the Material “MAT-004” was not listed in Listing Condition Record, when you enter the material in Sales Order for required Customer the system throws an error message as shown in below figure.

Note: Partner Functions in Material Listing Material listing applies to two partner functions in Sales & Distribution: the sold-to party and the payer. In the standard version of the SAP R/3 system, when the sold-to party and payer are different, the material listing check is as follows:  

If the sold-to party has a material listing, the system only checks this listing (no other check takes place). If there is no listing for the sold-to party, but a listing has been created for the payer, the system automatically checks the payer’s listing.

260 

If no material listing data exists for either the sold-to party or payer, then the customer may order any material.

If a Material exists both in Listing and Exclusion Condition Records, by default Exclusion is given preference over Listing.

Material Determination Material Determination is a method in SAP SD to determine the material to be used in the Sales Order. Material Determination uses the Condition Technique to substitute one material in the Sales Order for another when certain conditions are met. Example - When a product is under engineering change or there is a bug and you have another product, which is acceptable as replacement, then material determination can be used to set this scenario. During Sales Document processing by the customer, the system automatically proposes the list of substitute items from which the customer can select the required materials OR he can go with the main item itself he ordered. To configure the Material Determination Path: SPROReference IMGSales and DistributionBasic FunctionsMaterial Determination Maintain Prerequisites for Material Determination (As shown in the screenshot below):

Following screen appears:

261

We would go by step-by-step for the Material determination. The first step is “Maintain field catalog”. This screen can also be accessed from the transaction OV26. Field catalog contains fields used by the system to determine substitution materials in the Material Determination procedure. Click on “Maintain field catalog” in the screenshot above. Following screen appears:

262 For our demo purpose, we would work on only MATNR (Material Number). Scroll down the list to find the field MATNR.

Click on Backspace and come back to the main screen:

263 Click on “Display Condition tables”

Use F4 help to select a table.

Select 001 from the list and press Enter. Following list appears:

264 For our demo purpose, we would go ahead with this condition table. Go back to the earlier screen. Now click on “Maintain access sequences”. Access sequence is a sequence of steps SAP follows in order to obtain the condition record.

Select A001 and click on “Accesses”

265

In the above screenshot, the first field “No” is the access number. The access number is the order in which the system will read the access sequence. For e.g., if the access numbers are 5,10,12,15 and 20, then the system would start with the lowest entry (in this case it is 5). It would proceed further to 10 if it is not able to process 5. If no record found, then no material determination would be carried out. Select the record and click on Fields.

Now let us check out the Condition Types available. Go back to the earlier screen and click on “Define condition types”. Following screen appears:

Now let us check out the procedures configured in the system:

266

Select a procedure and click on control data.

267 Assigning Procedures to Sales Document Types: In this step, we would assign the above procedure to Sales Order document type. Go to Transaction OV14 or go to Transaction SPRO -> Reference IMG -> Sales and Distribution -> Basic Functions -> Material Determination -> Assign Procedures to Sales Document Types (As shown in the screenshot below)

Scroll down the list for the order “OR” (Standard Order)

268

Maintaining Condition Records for Material Determination: Go to Transaction VB11 or follow the navigation shown in the screenshot below:

Enter the condition type in the above screen and click on Enter. Select the required key combination.

269

On the Fast Entry screen specify the data for the following fields to maintain the record Material Entered: Specify the main material that has to be substituted 2. Material: Specify that material with which the main item has to be substituted 3. Reason: Specify the Reason for Substitution 1.

Now to maintain the substitution reasons: While maintaining the Condition Records for Material Determination, we have to specify the reason for substitution. For this Go to Transaction OVRQ OR else go to following path: Path: SPROIMGSales and Distribution Basic FunctionsMaterial DeterminationDefine substitution reasons

270

In this screen, you can maintain the substitution reasons. Go to New Entries and create. 1. 2. 3. 4. 5.

6.

Substitution Reason: Specify the required code for the reason Description: Specify the reason for substitution Entry: If we check this field, the system prints the original material ordered by the customer on the corresponding output Warning: If we check this field the system gives a warning message before substituting the main item in the sales order Strategy: Specifies whether the product selection should occur automatically in the background or whether the alternative materials should be offered for a selection in dialogues box Outcome: Specifies whether the outcome of product selection should replace the original entry or whether it should be recorded as a sub-item of the original entry.

Note: We can use this functionality outcome if the requirement is to deliver the substitute item at the price of main item For this following settings must be done:

271 1. The system has to determine the price for the main item but not for the substitute item. For this the item category for the main item “TAX” must be relevant for pricing and the item category of the substitute item “TAPS” must not be relevant for pricing Sales Document Type OR OR

Item Category Group NORM NORM

High Level Item Category

Usage PSA1/PSHP PSA2 TAX

Default Item Category TAX TAPS

2. It is the substitute item that has to be delivered but not the main item. So, the system has to reduce the stock for the substitute item but not for the main item. For this reason we must specify the Movement Type “601” in the Schedule Line category of Substitute item which is “PP” and we must not specify an Movement Type in the Schedule Line category of main item which is “CX”

Item Category TAX TAPS

MRP Type ND

Schedule Line Category CX PP

Testing To test the condition records, let us go to transaction VA01:

272 In the above screenshot, we have entered the material MAT-001. Now press ENTER.

In the above screenshot, you can observe that the material is automatically converted from MAT-001 to MAT-003

Cross Selling It is a sales practice where the customer’s are offered additional merchandise to what they ordered in an effort to increase sales volume Ex: If the customer placed for the order for computer then computer stand can be suggested as a combination material. It can be mapped by using cross selling concept that uses condition technique. When the user raises the sales order and specifies ordered material then system automatically pup-up a box in which system displays suggested material

Maintaining Condition Technique for Cross Selling Path: SPROIMGSales and DistributionBasic FunctionsCross SellingDefine Determination Procedure for Cross Selling.

273

1. Create Condition Table: Create the required Condition Table with corresponding key fields.

274 2. Maintain Access Sequence: Create an Access Sequence and place the required Condition Tables in it.

3. Define Condition Types: Go to New Entries and create a Condition Type with the corresponding Access Sequence.

275 4. Maintain Procedure: Define a Procedure and place the required Condition Type in it.

Cross Selling Profile: The Cross Selling Profile specifies how the Cross Selling materials to be displayed in Sales Document. For creating this Go to following path. Path: SPRO IMGSales and DistributionBasic FunctionsCross SellingDefine and Assign Cross Selling ProfileDefine Cross Selling Profile

276 Go to New Entries and create a Cross Selling Profile with the corresponding description. Enter the Cross Selling Profile Procedure The field “Cross Selling Dialog Box Indicator” specifies whether the Cross Selling materials are to be automatically determined by the system or we need to manually retrieve them in the Sales Document. If we check the field “Cross Selling ATP” indicator the system checks the availability of Cross Selling materials in the Sales Document. Save the Profile. Creating Customer and Document Procedures for Cross Selling Path: SPRO IMGSales and DistributionBasic FunctionsCross SellingMaintain Customer/Document Procedures for Cross Selling a) Define Customer Procedure for Cross Selling: Go to New Entries and Create. Note: We need to specify this value in the required customer master for the field “Customer Procedure for Product Proposal.” (Sales Area DataSalesPP Cust Proc.)

b) Define Document Procedure for Cross Selling: Go to New Entries and Create.

277 Note: This value has to be assigned to the required sales document type.

c) Assign Document Procedure for Cross Selling to Sales Document: Select the required Sales Document and then to it assign the required Document Procedure.

278 Assigning Cross Selling Profile: Path: SPRO IMGSales and DistributionBasic FunctionsCross SellingDefine and Assign Cross Selling ProfileAssign Cross Selling Profile

Go to New Entries and assign the Cross Selling Profile to the combination of Sales Area, Customer Procedure for Cross Selling and Document Procedure for Cross Selling Maintaining Condition Records for Cross Selling: Path: Easy AccessLogisticsSales and DistributionMaster DataProductsCross SellingCreate-VB41

279

Specify the Condition Type for Cross Selling and select the required key combination. In the first field for “Material” specify the main item for which the Cross Selling Materials are offered. In the second field for “Material” specify that item which is offered in Cross Selling. The field “Cross Selling Delivery Control” specifies whether the Cross Selling Materials can be delivered regardless of the main item OR in conjunction with the main item. To specify multiple materials for Cross Selling select the record and select the icon “Alternative Materials”. Save the Record. Note: When we enter the main item in the sales order the system automatically retrieves the cross selling materials. If we need to manually retrieve them, select the line item in the sales document and select the icon “Cross Selling Products.”

Testing: Let us create a Sales Order with the material maintained as for Cross Selling

280

You can see in above figure that as soon as I enter the material “MAT10” in Sales Order the system automatically proposes a Cross Selling Material maintained for material “MAT10”. Enter the material quantity for Material “M11” and click on “Copy” button. The Cross Selling Material with the quantity entered gets copied into Sales Order as shown in below figure.

281

Contracts and Agreements Contracts Contracts are agreements between the Customer and Vendor to supply materials/services for a specific price between fixed periods of time. Many possible types of contracts exist based on the types of contracts. For example, there are maintenance contracts, service contracts, quantity contracts, value contracts all of which we will be discussing over the course of this article. The bottom line however remains the same – A contract is an agreement between the Customer and vendor to supply goods/materials/services of specific quantity/value for a specific price over a specified period. Let’s discuss the different types of contracts.

Quantity Contract A quantity contract is an agreement to supply a fixed quantity over a period of time. Since the customer promises to buy the fixed quantity of goods/services, they will get a discounted price.

282

The document type in SAP for quantity contract is QC. For example, in this example, the quantity contract is for quantity 100 of say material M-01. Release orders are orders created with reference to the contract to consume the quantities in the contract. So the first release order is for quantity 20 which consumes 20 % of the quantity in the contract. Similarly, the rest of the release orders consume the remaining quantity in the contract. Document flows should exist between the contract and the release order types. There are 2 primary reasons why quantity contracts are used. 1. When Quantity is Limited – When the production quantities are limited in numbers, then customers are allocated a specific quantity by time -period (say a month, or a quarter). And customers cannot place ad-hoc orders, but have to first sign a contract for a fixed quantity and always order via release orders that specifically refer to the contract. 2. When Vendors want to lock-in Customer quantities – Some times to give deep discounts, sales folks require that customers commit to buying a fixed quantity over a time-period. This satisfies the sales figures.

Service Contract A service contract is normally created for service-oriented items – examples are annual service contracts, annual maintenance contracts.

283

For example, when you buy an internet connection from Comcast, they are providing services to you for a fixed period – say 1 year or 6 months. And for providing those services, they charge you monthly. In this case, there are no release orders because in case of service since there are no logistics operations, directly the customers are invoiced with reference to the contract. In this case, the customer is charged $100 a month for 12 months with a total of $1200. The items in these types of contracts follow billing-plan. Repairs also follow service contract methodology.

Master Contract A master contract is used when a particular type of contract is created regularly for a customer and you want all the header data to be consistent across all of the contracts. Normally, the header data of a sales document contains data from the Customer master.

284

For example, if a contract is created for a customer say 1400, key data like Inco-terms, payment terms, delivery preferences, taxability etc flow from the customer master data for that sales area for customer 1400. However, if you consistently change the data in the contract to a fixed value, say the Inco-terms should always be FOB Destination for all contracts, while regular sales order have CIP Philadelphia, you can create a master contract for customer 1400 and change the Inco-terms in the master contract to FOB Destination. All subsequent contracts that refer to this master contract will have the Inco terms as FOB Destination.

Value Contract A value contract is very similar to a quantity contract – except that instead of a fixed quantity, the value of the contract is fixed (i.e. the dollar amount of the contract is fixed) while the materials that the customers procure could come from either a fixed basket of materials or a single material only.

285

For example, in the example shown above, the type of contract is a value contract for a specific material – ‘WK2′. Essentially, this contract is limiting the value of the contract to a fixed dollar value and the customer can release multiple release-orders referring to the value contract for that specific material. If the customer wants to create contracts for specific value and not limit them to a particular material, then an assortment module can be used. The type of value contract that refers to an assortment module is ‘WK1′. An assortment module is a basket of materials (a fixed set of materials) without any specific quantities or prices. When some of the materials in the assortment module needs to be used in the value contract, the assortment module is searched for (by name or number) and the materials in the assortment module are selected and quantities specified. Price can be either manually specified or automatically done. We will discuss more on this during the configuration section.

286

Configuration for Contracts Path: SPROIMGSales and DistributionSalesSales DocumentsContracts

The configuration for master contracts is shown below. The child contracts (contracts that refer the master contracts) are called referencing sales documents. We have to first define the

287 contract document types that can reference a particular master contract document. The standard master contract document type in the IDES system is GK.

288 The child contracts that reference the master contracts are bound by the referencing requirements. The referencing requirements are specified in the reference procedure – SDGK. The fields that can be referenced in the lower level contract are specified as technical fields (Table, Field combination) along with the copy rule and message. As shown in the picture below, the reference copy rules can be ‘A’ – Check for Agreement, ‘B’ – Always copy or ‘C’ – Copy only if agrees. These copy rules are used to over-ride customer master derived data (Inco terms, payment terms, taxability etc) by the data in the master contract header. The message flag is used if a warning message should be shown in case data differs. However, this message cannot be changed to error in configuration.

Contract Profile A contract profile primarily specifies the automatic rules for determining dates (start date, end date and validity period) and cancellation procedure. Some of the reasons why they are used could be to automatically populate the dates for some contract types. For example if a particular contract document type always is used for a period of 2 years, then a contract profile with a validity period category of 2 years can be assigned to the document type in Sales document type configuration [VOV8 ]. The validity period for example can be defined as follows.

289

As shown, the validity period category of ‘Z5′ indicates that he contract profile is valid for 5 Years (’4′ is the validity period unit for years). This finally comes together in the Date determination rules. For example, the date determination rule ’08′ says the contract end date should be computed based on the contract start date ( as opposed to another date, say goods acceptance date or billing date ) + the contract validity period.

290

Contract Creation Demo Path: Easy AccessLogisticsSales and DistributionSalesContractsCreate-VA41 Enter the contract type from the drop downs. The typical contract document types in a standard IDES system are GK – Master Contract QC – Quantity Contract QP – Rental Contract Wk1 – Value Contract WK2 – Material relevant value contract SC – Service and Maintenance Contract etc

291

1. Quality Contract (QC):

292 For “QC” 1. 2. 3. 4.

Document Category is “G” Screen Sequence Group is “4” Transaction Group is “4” No Shipping and Billing data has to be specified.

Note: The Item Category is “KMN.” For KMN 1. We must not check the field “Schedule Line Allowed” 2. Completion Rule is set to “C” 3. It is not relevant for billing but relevant for pricing. 2. Value Contract General (WK1): The functionality is same as “QC” except screen sequence group which is “WK” Note: The Item Category is “WKN.” For WKN 1. We must not check the field “Schedule Line Allowed” 2. Completion Rule is set to “E” 3. It is not relevant for Billing but relevant for Pricing. Note: For creating this contract first we need to create “Assortment Module.”

Assortment Module  An assortment module is an order entry tool that displays a list of materials and services that can validity date and a restriction that only the materials and services that belong in the same sales organization and distribution channel for which your release order is being made will be displayed Path: Easy AccessLogisticsSales and DistributionMaster DataProductsValue ContractAssortment ModuleWSV2 - Create

293

You will have to give a name (in this case Module-1), enter the materials and validity dates. Now you can use the assortment value in the value contract by entering the assortment module in the contract. To release the contract however, you will have to select the materials from the value contract. The way you do it is as follows. As usual create the release order with reference to the contract, and during the process of selecting the items in the pop-up, select the line item and click on “Expand Assortment” and select the materials and quantities. Depending on the quantities selected, the order will be priced. You can do the same using material specific contracts as well – Just that you do not need an assortment module to do the same. 3. Material Relevant Value Contract (WK2): This contract is created by specifying the materials with the corresponding values rather than assortment module. WK2 is same as WK1 except the screen sequence group which is “WK1.” The Item Category is “WKN.” 4. Service and Maintenance Contract (SC): Service and maintenance contracts typically follow a billing plan that is typically periodic. For “SC”

294 a. b. c. d. e.

Document category is “G” Screen Sequence Group is “VT” Transaction Group is “4” No shipping data has to be specified. The corresponding Billing Type is “F2”

The Item Category is “WVN.” WVN is same as KMN. Apart from that “WVN” is relevant for billing also 5. a. b. c. d.

Master Contract (GK): For “GK” Document Category is “0” Screen Sequence Group is “GK” Transaction Group is “4” No Shipping and Billing Data has to be specified.

Outline Agreements Scheduling Agreement:

It is an outline agreement with the customer containing the delivery dates and quantities. These are entered as schedule lines in the delivery schedule. We can create these schedule lines while creating the agreement or later also.  We fulfill a scheduling agreement by creating the deliveries in the schedule as they become due. The deliveries are processed for a scheduling agreement in exactly the same way as we process a normal delivery. After we have carried out the delivery, the system automatically updates the field “Delivered Quantity” for scheduling agreement item with the delivery quantity.

Configuring Scheduling Agreement Path: SPROIMGSales and DistributionSalesSales DocumentsScheduling Agreements with Delivery SchedulesDefine Schedule Line Types.

295

 Schedule line types are not schedule line categories. Schedule line types are used for information purposes only. Should you need to create one, follow the standard process of copying and changing a SAP standard? We will be focusing on just-in time (JIT) delivery scheduling. Use the following Menu Path Path: SPROIMGSales and DistributionSalesSales DocumentsScheduling Agreements with Delivery SchedulesMaintain Planning Delivery Sched. Instruct. / Splitting Rules The planning delivery schedule is an internal delivery schedule used to plan requirements more efficiently. It is subdivided into three sections: 1. Maintain Delivery Schedule Splitting Rules: These instruction shown in below figure, define the split of schedule line quantities between the different days in the planning delivery schedule and the forecast delivery schedule.

296

2. Maintain Planning Delivery Schedule Instructions: These instructions determine the characteristics of the planning delivery schedule. 3. Assign Delivery Schedule Splitting Rules: This is concerned with splitting rules for planning delivery schedule instructions. You may have more than one splitting rule for each instruction. You can thus assign a date type and a splitting rule range, which will allow the system to carry out the splitting rules in sequence.

297  Proceed by setting up the planning delivery schedule instructions first. This determines if schedule line categories are relevant for deliveries and how the planning delivery schedules are to be generated. Note schedule lines in the planning delivery schedule replace those in the forecast delivery schedule with regards to planning relevance, and if required, delivery relevance

 The two examples of SAP1 and SAP2 are useful in explaining the overview of this functionality. SAP1 indicates that the schedule lines in the planning delivery schedule are relevant for delivery and should replace the schedule lines in the forecast delivery schedule, should their dates lie outside the dates of the JIT delivery schedule. This is indicated by an “X” in the column “D.”  Column “B” is crucial; it indicates the baseline date used by the system for the planning of delivery schedules. Should no date be entered here, the system will not generate any schedule lines in the planning delivery schedule. You may select date type 1, which sets the delivery schedule date as the base date, or date type 2, which selects the planning delivery schedule generation as the base date.  Column “T” represents the date type for the validity period of the delivery schedule split. It is used to indicate if the validity period is measured in weeks or months. The validity period is the period of time in weeks or a month that the delivery schedule split is valid. The system does not

298 take into account the schedule lines in the forecast delivery schedule; its date lies after the validity end date. The associated column Val represents the value in units in order to determine the end date of the validity period. Thus, example SAP2 has a date type of 3, which is months, and a value of 7, or seven months after the baseline date of column “B.”  Column “P” indicates whether the system should adopt schedule lines from a previous planning delivery schedule when generating a new one. It would only be valid for those schedule lines occurring after the validity end date of the delivery schedule split. Column “A” indicates if the system should automatically generate a planning delivery schedule when a forecast delivery schedule is created. Column “A” indicates if the system should automatically generate a planning delivery schedule when a forecast delivery schedule is created.  Proceed to maintain the delivery schedule splitting rules. Highlight the Instruction SAP2 and select Assign Delivery Schedule Splitting Rules. Here you define the split share sum into daily periods, as shown in Figure. Should you have an initial schedule line quantity of 600 pieces using split rule SD1, that schedule line will be divided up into three equal schedule lines of 200 pieces each (600 divided by 3). Each set of 200 pieces will be delivered on Monday, Wednesday and Friday respectively. Note: It is easier to make the splits add up to 100; that way, you are working with a percentage of the total schedule line quantity. For example, the split rule SD2 adds up to 100, so you would assign 15 percent of the schedule line quantity to be delivered on Mondays, 30 percent on Tuesdays, and so on.  The column “H” defines the holiday rule for the delivery schedule split. You can select to treat the holidays as workdays or you can choose to have the schedule line quantity move to the last preceding workday. You can also choose to have the system split the quantity via the remaining days according to the delivery split Note: The calendar used to define the holidays and workdays is the calendar of the ship-to party. The system uses the calendar of the schedule agreement items, unloading point as the calendar. This calendar may be changed using the assigned user exit C_CALENDAR  Column R represents the rounding rule for schedule line quantities. You may select to round up to three decimal places according to the sales unit or you may round up to a multiple of the delivery- rounding quantity.  After you have defined your delivery schedule splitting rules, assign them a brief description for ease of use later. After you have completed this task and saved, proceed back to Maintain Planning Delivery Schedule Instructions. Select the instruction again, such as SAP2, and then select Assign Delivery Schedule Splitting Rules.

299  The split rules we have defined, such as SD1, are now assigned to a date range again using weeks and months as the date type followed by the range of this date type. Thus, in Figure, the date range is eight weeks for split rule SD2 from the start of the base line date. Note: Although the split rule range and the delivery schedule split influence schedule line splits, the split validity period overrides the splitting rule range in every case. One is now able to proceed with sales document type configuration. Proceed as with any other sales document type configuration process. A Scheduling Agreement does not need to have release orders. You can create the delivery exactly from the Scheduling Agreement. This is the benefit of having a Scheduling Agreement.  The standard sales document type for scheduling agreements is LZ. This LZ sales document type is configured in the same process as all other sales document headers. Note that this sales document type has the following changes to the standard order sales document. The BL document type must have E as the SD document category, indicating a scheduling agreement. It too has a different screen sequence group using the standard LL. The pricing Procedure can be same as that of the standard Sales Orders. Thus you can leave the document Pricing Procedure Indicator blank or set it the same as for standard Sales Orders. The Transaction group must be 3, indicating this sales document transaction is a Scheduling Agreement.  The sales document type has the following section with relation to scheduling agreements, as shown in below Figure.

 The correction delivery type is LFKO. (A correction delivery is used when the customer returns goods before accepting them and processing goods receipt. The Correction Delivery will update the cumulative quantity in the scheduling agreement, to indicate that the original delivery quantity is still available to be called off in the Scheduling Agreement.) The usage indicator can be any indicator you set. The value set here will default into all scheduling agreements at the header level and thus will be copied into all items. This is the default usage as found on the line item of the sales document. (This is often used in analysis of sales transactions.)  The MRP for delivery schedule type is the key entry that defines how the schedule lines are to be controlled. This value is proposed when creating a scheduling agreement. Standard

300 deliveries are created for the scheduling agreements. Thus, the delivery type used is LF.  The standard billing type is used as well. However, just as you may copy and change the sales document types, you can also copy and change the delivery and billing documents, should this be necessary.  The standard item category is LZN. LZN behaves like a standard item category. It is relevant for delivery-related billing as well as pricing and it does allow schedule lines. The schedule line categories used are as follows: CP: Deterministic MRP. Although CP is the standard schedule line category, posting requirements through to materials planning and doing the availability check CV: Consumption MRP. CV is also a standard schedule line category that does an availability check, but it does not post the demand through to MRP CN: No MRP. CN does no availability check and no MRP.

Creating Scheduling Agreement Path: Easy AccessLogisticsSales and DistributionSalesScheduling AgreementCreate

301 Enter the Scheduling Agreement Type value as “DS.” While creating the agreement we need to specify the description and validity periods along with other required data. For the scheduling agreement item we have to enter the delivery dates and the corresponding quantities in the schedule line data of that item. Note: For Scheduling Agreement Type “DS”, 1. 2. 3. 4. 5.

Document Category is “E” Screen Seq. Group is “LP” Transaction Group is “3” Delivery Date is “LF” Billing Type is “F2”

Note: The Item Category is “LPN.” “LPN” is same as “TAN” except “Incompletion Procedure”. The Schedule line Category is same as that of Sales Order.

302

Item Category Determination for Scheduling Agreement and Contracts SD Type DS QC WK1 WK2 SC

Item Cat. Grp NORM NORM NORM NORM DIEN

Usage

HLevltCa Dfltc LPN KMN WKN WKN WVN

Note: Because the contract does not have Schedule Lines, we need to create a Sales Order (Release Order) with reference to contract and create Delivery and Billing against the Release Order

Exercises 1. All Contracts document types require release orders. (Give examples of document types in either case) 1. TRUE 2. FALSE 2. Why is the ‘Completion Rule’ of the Quantity Contract Related SAP Item Category set to ‘C’? 3. What is the Transaction code to create Contracts in SAP? 4. Create a Quantity Contract in SAP for Customer 1400 and for material M-01 with quantity 100. Specify the Contract # 5. Create a Release Order for a quantity of 50 , with reference to the SAP Contract created in Q.4 and specify the Release Order # 6. Create another Release Order with reference to the SAP Contract created in Q.4 and this time, fully reference the quantity and specify the Release Order # 7. Describe in your own words, why businesses use quantity contracts? 8. A _____________ order is created to release quantity from a quantity contract or value contract Scenario 1: Samsung has 1,000 computers in their New Jersey office and are constantly facing issues related to software and aging hardware. ABC Computers Inc. suggests that they enter into a contract whereby they will take care of the computers/software for a fixed yearly fee. Question 9: What kind of contracts would they enter into?

303 Scenario 2: Samsung likes ABC Computer’s performance and after 1 year wishes to buy 300 more computers from them. However, since the company wishes to purchase so many computers, they wish to get a discount. Question 10: What kind of contract would they enter into? Scenario 3: Release Orders for Contracts created (For Q.9 and Q.10 above) will have to be created with reference to the contracts. However, the sales personnel entering the contracts might not be aware of the contracts that were created. ABC Computers want to put a system in place so that anytime orders are created for Samsung, they should be reminded that open contracts exist (if any) Question 11: What kind of configuration would have to be done to achieve the same in SAP?

Status Profile Different user defined statuses can be assigned to a sales order at the header or at the line item level. These statuses are assigned using a status profile. This concept is present in SAP CRM as well. What are more important to understand is the different business scenarios that demand statuses for the sales document.

304 For example, in typical office situations, quotations beyond a certain sum need to be approved by the sales manager. Let’s take a simple IDES example of a ZQT status profile. This status profile has 3 statuses – Quotation Approved, Quotation Declined, and Quotation Not Approved. If the quotation is not approved, we should configure the system in such a way that an order cannot be created from the quotation. Which means, each status can influence the way the sales order’s subsequent steps are performed. We will also look at a more complicated example that has 6 statuses and the sequence in which the user changes the statuses is also controlled via configuration. Configuration The configuration menu path for Status Profile is as shown in the picture below [SPRO -> IMG -> Sales & Distribution -> Sales -> Sales Documents -> Define and Assign Status Profile]

As already mentioned, status profile can be created for both header and line item level. The procedure is very similar for both of them. So the steps required for creating a status profile at the header level are  

Define Status Profile [BS02] Assign Order Types to Status Profile [VOV8]

305

Let’s go through the process of creating the status profile first. Based on the example that we have discussed, select the status profile ZQT which contains the statuses that we have discussed above for the quotation scenario. As you can see from the picture below, there are 3 statuses assigned to status profile ZQT. They are   

NAPP – Not Approved APP – Approved REJE – Rejected

Each of these statuses has a long description and a short description. Just in case you need to maintain a long description, you can select the button highlighted below to create a long description for the status. Also there is a check box called “Init St.” . Each document which has a status profile assigned to it starts with an initial status. The one check marked here will be the initial status. Meaning, if you create a quotation of type QT (that is assigned to a status profile ZQT), the user status initially during the creation will be NAPP.

306

The next thing would be to identify all the allowed business transactions possible for a particular status. You can double click on the status or select the magnifying glass to view the allowed business transactions.

307 As you can see from the picture above, if the quotation is in status NAPP, then the transactions “Create Billing Document” , “Create Delivery”, Create Goods Issue” etc are not possible. The only transaction that is possible is “Complete” which means you can just save the quotation. It makes sense right..? What is the point in doing anything with a quotation that is not approved? This time let’s take a more complicated example (Based on the first picture shown in the concept section). The business scenario is the installation of complex equipment (Say an MRI Scanner) that the customer has brought from us. After placing the order, there are 6 steps that are involved before invoicing the customer.     

The customer has placed the order, but the installation procedure was not Instantiated yet. The customer needs to register with us over the web with the order number and that start the installation process. Our Service Representative will visit the Customer location and validate if the site is suitable for the installation of the product. After the site is found suitable physically, the technician will visit the site and make sure that there is proper ventilation, power and cooling available. Only after this final validation will the product is shipped to the customer location.

In order to accomplish this, let’s create a new status profile ZORD_INS and assign this to the order type OR.

Maintain different statuses (as discussed above) for the status profile ZORD_INS. Each of these statuses will have a number (to the far left below). And as discussed above, the first status ZNOT will be the initial status. The highest and lowest numbers are a little bit complicated and will be easy to understand in the demo. Nevertheless, the reason why they exist is that not all statuses can be attained before certain statuses are passed. Meaning, you cannot go to status ZINS (Installation Confirmation) directly from ZNOT (Not Initiated) without going through the other statuses like Initial registration, Site Verification etc. So when the lowest and highest numbers are 10 and 20 against status ZNOT, that means that from status ZNOT, the user cannot place the order in another status beyond 20 – Meaning the only way for changing the status of an order in ZNOT status is to first go through status ZREG. This is just a

308 complicated way of saying the statuses need to go lock and step in a particular sequence. This depends on the business scenario and is not always the case.

The next step would be to define all the object types that are affected because of the status. For a standard sales order you can just select “Sales Order Header” and be done with it. For more complicated scenarios like service orders, equipment masters etc, you would have to select the appropriate object type.

Each of these transaction types are associated with a number of business transactions. You would have to select the new button to import all the business transactions associated with the object type.

After importing the business transactions, you can view them here. Now, you would have to choose and set the “influence” that the status has on each of the transactions.

309

Since the order is in its initial stage, we should configure the status to only allow completion (save) and forbid any other transactions on the order (Like billing the order, delivering the order, PGIng the order etc). Because, until the site is ready, the service engineer has checked the site, there is no point in delivering the transaction or billing the transaction.

Similar to the ZNOT example, go ahead and configure the rest of the statuses and set the influence on the transactions. The next job is to assign the status profile ZORD_INS to the order type OR. That is being shown in the following 2 pictures. That will finish the basic configuration. Let’s follow through with a demo and see the effect of our configuration.

310

Status Profile Demo Let’s start by creating a sales order and see the effect of the status profile on the different transactions that we perform. Go to HeaderStatus to see the effect of the Status to view Status Profile In the status tab, you will see the current status ZNOT (because this is the initial status after creating the sales order). If you want to explore the statuses further, click on the Object Status button.

User Statuses are shown here. If there are more than 5 statuses here, you can click on the button highlighted in red below to scroll down and view more.

311

If you change the status now to 50, you will get an error message as shown below. This is because we have defined the highest step of ZNOT to be 20. That means the only upper status that the status NO. 10 – ZNOT can go to is 20. If the user tries to set the status of the sales document to something higher, the system will give an error message.

Similarly, if you try to deliver this order while the status of the sales order is ZNOT, the delivery transaction VL01N will throw up an error message as shown below. This is a way to control the different business transactions that an order can subsequently perform under a given status.

312

Exercise: Create a new Status Profile as follows (Take Cues from ZQT Status Profile) 1. Not Approved 2. Approved 3. Rejected. If the status is “Not Approved”, then don’t let any subsequent documents be created from it. If the status is “Approved”, then allow all subsequent transactions to be created. If the status is “Rejected”, then don’t let any subsequent documents be created from it. Create a new SAP Quotation Document Type ZXXX and assign the newly created status profile to it. Please write down the new status profile you have created along with the new document type you have created in the forum. Give the Unit Test Plan for testing the configuration above.

Incompletion Procedure An incompletion log or an incompletion procedure defines how the system should respond when a sales document is incomplete – meaning some of the necessary fields is not filled up. Typical choices include forcing the user to enter the data and not let the user save the order before all the necessary fields are filled. This incompletion procedure can be assigned set to not just the sales order, but sales order line item level, schedule line level, delivery header and delivery line items. (Incompletion log cannot be set for billing documents) Depending on the requirement we need to make the fields as mandatory in a document. For this we need to define an incompletion procedure in which we have to place the required fields that are to be made mandatory and use that procedure for the required document.

313 Defining Incompletion Procedure Path: SPROSales and DistributionFunctionsLog of Incomplete ItemsDefine Incompletion Procedure [OVA2]

As you can see, you can create incompletion procedures for sales order headers, items… etc as shown in the picture. What this means is that you can have a separate set of mandatory fields for the header and a separate set of fields for the line items etc. Select the Sales -Header for now and click on the Procedures. If you remember from the Sales Document Types Configuration, the sale document of type OR had an incompletion procedure of 11. Select the required Incompletion Group and Click on Procedures.

314 Select 11 and go into fields. (You can as well create a new incompletion procedure but we will hold off on it for now.) After selecting the fields, you will see a screen like below which is essentially a list of fields in the sales order header along with a set of controls.

Instead of fiddling with the existing fields, let’s start a new entry. Let’s say that we want to make the PO Number field mandatory in the sales order ( Which can be done via the sales document type configuration also but let’s do it just for the heck of it – Always remember there could be multiple ways of doing the same thing in SAP . And sometimes unfortunately there would not even be a single way. ). Choose VBKD as the table name and the field name is ( Just in case you are not sure, click on the field in the sales order, hit F1 and then click on the button that says “Technical Information” ) BSTKD. The Screen field is a simple drop down that contains SAP pre-set screens. Choose the one that closely resembles your situation. This is the pre-built screen that is shown to the user when the fields are missing. A warning message is used when you want to show a warning to the user when the field is missing.

315 The Status is a little bit tricky. As you can see from the picture above, there is a matrix with status groups going down to the left and the sequence of activities that go to the right. (Delivery, Billing, Pricing, Goods Movement, Picking, Packing etc) These set of fields ensure that the incompletion log message is shown up in all those transactions marked here against the status group. Save this configuration and let’s see the effect of this on the sales order (with the understanding that the sales order type OR is assigned the incompletion procedure 1). Note: Like this we need to define the Incompletion Procedures for the required Incompletion Groups and assign them to the corresponding transaction. For assignment Go toAssign Incompleteness Procedure Status Group: It specifies which subsequent transactions can be blocked for processing if the mandatory fields are missing the data. For defining the status groups go toDefine Status Group Go to New Entries and Create Note: In the above example the system will automatically block the transaction “Billing Document” if the mandatory field to which the Status Group is assigned is missing the data. Incompletion Log Demo Let’s start by creating a sales order of type OR, and not fill the PO Number field. Now, let’s try to save it. The first pop-up message that you see is that the system is telling you that there is something missing.

316 At this point, you can either choose to save it or edit it further. Let’s choose to save it for now. But remember that when we did not enter the PO Number, the system did not warn us.

If you have selected the warning checkbox for the PO Number field, the system would prompt you with a warning.

Of course since it’s a warning, you can choose to ignore it. Now, let’s create another sales order, but this time chooses to edit the incompletion log. The following screen appears. As you can see there is only one field that is incomplete. If there is more than one field, the sequence field in the incompletion log configuration comes into picture. You can now choose to select the field that is missing (PO Number in this case) and click on complete data so that the system automatically takes you to the right screen to fill the field. This does not happen sometimes because the set of screens are hard coded and you cannot go beyond them unfortunately.

317 Let’s try to assign a different status group (02 now which has delivery also checked). What should happen in this case..? If you try to save the order without entering the PO Number and try to deliver that order, you will see an error message.

318 Available to Promise and Transfer of Requirements Posting Stock in Plant  When doing delivery, we will face an issue with stock not being available. This is a very common problem faced by anybody. To resolve this, you would have to put dummy stock into the storage location (As though real stock has come in). The easiest way to do this is via Transaction code [MB1C]. The Menu Path for the same is: Path: Easy AccessLogisticsLogistics ExecutionInbound ProcessesGoods Receipt for POMB1C-Good Receipt for Other Activities

Step 1: Use Transaction Code MB1c

Step 2: Enter the Movement Type of 561, enter the plant and storage location where you want to input the stock

319

Step 3: Enter the Materials and Quantities that you want to input. Save the Transaction. You can immediately go to MMBE (Verify Stock in SAP) and check the increase in quantity under the respective plant/storage location combination.

320 Troubleshooting: During the stock posting if we get the following errors resolve them by using the solutions given. 1. Posting is only possible in the periods XX/2011 Sol. Closing the Posting Periods. To resolve this issue follow the following steps: The transaction path to close posting period is [MMPV] and the menu path for the same is [LogisticsMaterial ManagementOtherClose Period]

Enter the company code (This could be done in one-shot for a series of company codes) the new fiscal period to open (This is normally the next fiscal period) or you can specify the current date or the date based on which SAP needs to choose the fiscal period to open/close.

321 Some materials have negative postings enabled. If that is the case and if you are OK to have negative quantities/values allowed in the previous fiscal period, select the “Allow negative quantities in previous period “check mark. To find out which periods are currently open go to transaction code [ OMSY ] and select the company code to find out the current fiscal year/period, the previous fiscal period/year etc. Also, the flag highlighted allows posting to the previous period.

2. Maintaining Plant Parameters Sol. Use the following Path: SPROIMGMaterials ManagementInventory Management and Physical InventoryPlant Parameters

322 3. No Stock posting is possible for the material Sol. Use the transaction code “OMS2”.

Select the required material type and go to quantity and value updating. Select the required Valuation Area (Plant) and check the fields quantity updating and value updating.

323 4. If we get the error regarding “Account Determination” Sol: During the stock posting the cost of the material will be posted to the corresponding G/L accounts. For this we have to assign the G/L account to the combination of Transaction Key, Chart of Accounts, Valuation Modification, Valuation Grouping Code and Valuation Class In this combination Valuation Grouping Code is the one element which has to be assigned to the Valuation Area without which the cost of the material cannot be posted to the corresponding G/L account without which the system will not allow you to post the stock For this assignment Use the Transaction Code “OMWD”.

5. Creating G/L Accounts Sol: Use the Transaction Code “FS00”.

324

Enter the Company Code. From the Main Menu select SettingsHierarchy Display. Select the option “Display Accounts in Navigation Tree.” Select the required G/L Account and select the icon “Copy” 6. While Creating the G/L Accounts if we get the error regarding “Field Status Variant” Go to following Path: SPROIMGFinancial AccountingAccounts Receivable and Accounts PayableBusiness TransactionOutgoing Invoices and Credit MemosCarry out and Check Document SettingsAssign Company Code to Field Status Variant.

325 Select the required Company Code and assigned the Field Status Variant Value as “0001” or “1000” 7. While creating the G/L Account if we get the error “The G/L Account is blocked for creation in Chart of Accounts” Sol: Use the Transaction Code “FSP0.” Select the required G/L Account and select the Icon “Block.” Uncheck the field “Blocked for Creation” and Save it.

8. Opening the Periods Sol: Assigning Posting Period Variant to Company Code. Use the transaction Code “OBBP”. Select the required Company Code and assign the variant “0001” or “1000”

326

Use the transaction code “OB52.” Select the required variant and specify the current year for all the account in the 2nd and 4th Columns of year.

327 9. No Direct Posting is possible to G/L Account. Sol: Use the transaction code FS00. Select the required G/L Account and select the Icon “Change”. Check the field “Post Automatically only” on the Tab Page Create Bank Interest.

10. Creating Number Range for Material Document. Sol: Use the transaction code “FBN1.” Enter the required company code and select the button “Change Interval.” Create the required Number range and save it.

328 Note: 1. To see the list of Material Documents use the transaction code “MB51”. Enter the required details and click on execute button.

2. To check the stock in the plant use the transaction code “MMBE.” Enter the required details and click on execute button.

329 Question 1: Describe what Movement type 561 stands for in your own words? Question 2: Using MB1c enter the following materials and quantities in Plant 1000 and storage location number 0001 1. M-01 100 2. M-02 250 3. M-03 300 Give the SAP Material Document Number generated. Question 3: Which Transaction do you use to view SAP Material Documents? Question 4: Specify the Accounting Document Number generated for the corresponding Material Document Number and the Description of the G/L Accounts updated by the A/C doc

Materials Requirements Planning and Transfer of Requirements  At the time of a sales order, a line item in the sales order creates a schedule line. The schedule line represents the customer’s intended delivery date and quantity to be delivered. This information is transferred (a transfer of requirements, TOR) to materials requirements planning. Materials requirements’ planning is then able to determine if there is enough quantity of stock available for the scheduled delivery date. The Transfer of Requirements TOR is closely integrated with the Materials Management (MM) and Production Planning (PP) modules; which are both part of Logistics within SAP ERP Central Component of SAP. Thus TOR must be closely configured in association with the respective logistics team. Path: SPROIMGSales and DistributionBasic FunctionsAvailability Check and Transfer of Requirements Transfer of Requirements

330

 As described earlier, the schedule lines in the sales order transfer the requirements through to materials requirements planning (MRP). You can then select the documents on which you would like the TOR to happen. For example, you may not wish any TOR to happen for quotations, but you may want the TOR to happen for standard sales orders.

Individual or Collective Requirements The transfer of requirements can either be a transfer of requirements with an individual requirement or a transfer of requirements with collective requirements. This is set in the Availability check field on the material master record in the Sales: General/Plant view. Not only does this control how the availability check is processed, but also how the requirements are transferred to MRP.  Individual requirements are, as the name implies, an individual transference of demand to MRP for each schedule line. An advantage of this is that the availability overview [CO09] will show the order quantity, the sales document number, the item number, and the requirements class (discussed later) for each schedule line for which a demand has been created. Often one may refer to the stock requirements list (transaction [MD04]) and view a requirement from a sales document, however with this view it is difficult to see if a requirement has been confirmed, that is stock has been allocated to the requirement. By using the availability overview transaction [CO09] one is able to see the confirmed “allocated” quantity for a requirement. The view of the availability is configured using a checking group. Collective requirements are a collective grouping of requirements created either daily or weekly that are transferred to MRP. The documents created in collective requirement processing cannot be individually identified from the availability overview. Collective requirements are useful to have a clearer view of the availability overview as well as speeding

331 up response within the system.  To access the availability overview screen, use the following path Path: Easy Access LogisticsMaterials ManagementInventory Management EnvironmentStockAvailability overview [CO09]

By clicking on Total Records button, the overview will display all the documents that have requirements. There are number of key transactions relating to integration between logistics in MM and SD in this menu path. They include: 

[MMBE] – Stock Overview



[MD04] – Stock/Requirements List



[MB53] – Plant Stock Availability



[CO09] – Availability Overview



[MB52] – Warehouse Stock

332 

[MB5M] – Expiration Date List



[MB5B] – Stock for Posting Date



[MB5T] – Stock in Transit



[MBBS] – Valuated Special Stock



[MBLB] – Stock with Subcontractor

 The system will automatically create individual requirements for materials with collective requirements indicated on the material master for transactions that create special stock. Examples of this would be consignment, returnable packaging, or make-to-order stock.

Transfer of Requirements  Essentially, the same control elements are used for the TOR as are used for the availability check. The TOR is dependent on the following data: 

The requirements type



The requirements class



The checking group



The schedule line category

 The requirements class is the key factor in the TOR. It is based on the requirements type for the sales document. These requirements class are also used in PP, so be sure to involve PP and MM in any changes you envisage in the SD module. The requirements type and eventually the requirements class are determined in the strategy group, so all changes made there should also be coordinated with PP. The strategy group can be found in the material master [MM02] MRP 3 view under planning.  For TOR to be carried out, you need to ensure a few criteria are met:    

A plant must be assigned to the sales document line item level The schedule line category must be switched on for the TOR. The TOR must be switched on at the requirements class level A checking group must be defined and allocated to the material master record in the sales/plant view in the availability check field.

333  When the TOR is switched on at the requirements class level, it can be switched off at the schedule line level. However, you cannot switch on the TOR at the schedule line level if it is switched off at the requirements class level  Settings for the TOR specific to the schedule lines are only relevant for sales documents, such as the sales order. In the shipping documents, however, the settings for the requirements class apply. The requirements class is determined from the requirements type of the material. An example of how the TOR is carried out is shown in figure below.

 Let’s say the customer orders 100 pieces for the requested delivery date of 06/01 /92. Block “A” represents the availability check, which shows the confirmed quantities at the schedule line level. Block B represents the passing of requirements, which shows the passing of the demand for 100 pieces for 01/06 /92. The result would be the confirmed quantities as confirmed in the schedule lines with an open order quantity of 10 pieces, which could be procured from a purchase order.

334 Consumption Modes  The consumption mode defines whether and in which direction on the time axis from the requirements date the consumption of customer requirements with planned independent requirements should occur. The requirements date corresponds to the date when the sales order items were created. One has the following options: 

No planning consumption



Backwards consumption only: starting from the requirements date, backwards consumption is carried out within the relevant consumption period.



Forwards consumption only: starting from the requirements date, forward consumption is carried out within the relevant consumption period



Backwards/forwards consumption: starting from the requirements date, backwards consumption is performed first. Then, if no planned independent requirements can be allocated before the requirements date, forward consumption is performed. Both procedures are carried out for the relevant consumption period.



Forwards/backwards consumption: Starting from the requirements date, forward consumption is performed first. Then, if no independent requirements can be allocated after the requirements date, backwards consumption is performed. Both procedures are carried out for the relevant consumption period.

Planning Materials  It is possible to create a common planning material and assign similar materials to it. Independent requirements are created for the planning material to cover the requirements that are expected for the materials assigned to the planning material. Thus, customer requirements for these materials are consumed by the independent requirements of the planning material. This means that you do not have to create independent requirements for each material.  You assign the planning material to the materials on the MRP 3 screen. You must also enter the appropriate strategy group for planning with planning materials on the MRP 1 screen.  You cannot perform a TOR from the sales or delivery documents when using a planning material. Rather, the actual requirement from the order or delivery consumes the independent requirement of the planning material. The independent requirement is thus reduced. Then when MRP is run, requirements are created for the order or delivery and for the balance of the independent requirement.

335  For example, let’s say we have an independent requirement of 100 tons and an order of 20 tons. The order becomes a requirement of 20 tons, and the independent requirement is reduced to 80 tons. The total requirement is still 100 tons. The Stock Requirements List  The stock requirements list is the central table for planning and stock control. It is accessed via various menu paths, but the most straightforward method is as follows: Path: Easy AccessLogisticsMaterials managementInventory managementEnvironmentStockStock requirements list [MD04].

 You can clearly see the order number or the delivery number as well as the line item and schedule line placing the demand on plant DBLG. The Stock Overview  Another view of stock that is invaluable to the interpretation of the available stock and the situation of stock levels in a plant is the stock overview (previously used in consignment stock [MMBE]). There are many menu paths to this display, however, the following menu path is simple to use

336 Path: Easy AccessLogisticsMaterials managementInventory managementEnvironmentStockStock Overview [MMBE]

Enter the material and plant in the selection parameters. If required, restrict the selection parameters further, and then click Execute.  This view will show you the total stock per company code, then plant followed by storage location, and finally a breakdown per batch. A useful tool here is the material movements, which can be viewed by selecting the stock line and proceeding to Environment, Material movements.  You may find from time to time that you may have inconsistencies between the stock requirements list [MD04] and the actual placed orders. This can be solved by implementing OSS note 25444  This OSS note explains the possible reasons for the inconsistencies. Most inconsistencies are generally caused by poor user training, resulting in poor usage of the system. The note proposes implementing a report ZSDRQCR21 that will regenerate all the requirements for a particular material in a particular plant. I have found this report to be very useful

337 Configuring the Transfer of Requirements As the transfer of requirements is very closely linked to the materials management module, we will be focusing on the SD configuration areas only. Defining Requirements Classes To define requirements classes, use the following path: Path: SPROIMGSales and distributionBasic functionsAvailability check and Transfer of RequirementsTransfer of requirementsDefine requirements classes

 The requirements class is the controlling factor for the availability check and the TOR for all sales documents types. The system uses the entries at the requirements class level as a default and brings the data into the sales order. The schedule line category is used to fine-tune the settings at the requirements class level.  Generally, SD will not need to create a new requirements class for a standard business process. However, should a new requirements class be necessary, simply copy and rename the

338 class that resembles the requirements class you need. Be sure you rename the class using the SAP-standard name range that begins with a Z.  A useful tip is to select the requirements class you want to configure and then select the Display button represented by a magnifying glass. This will produce an easily configurable overview of the indicators you may set at the requirements class level.  Use the indicators to select if this requirements class must carry out an availability check and/or a TOR. Once the requirements class has been created, proceed to define the requirements types Defining Requirement Types Once the requirement class has been created, you need to define requirement types.  A requirements type is allocated to a single requirements class, but a requirements class can be allocated to more than one requirements type. The requirements type is displayed in the sales order. It is based on the item category and the MRP type of the material. It is possible to change the requirements type at the time of creating the sales order. Assign the requirements class you created to a requirements type. Once this assignment has been made, proceed to determine the requirement types Determination of Requirement Types Using Transaction Once the assignment has been made proceed to determination of requirement types using transaction Path: SPROIMGSales and DistributionBasic FunctionsAvailability Check and Transfer of RequirementsTransfer of RequirementsDetermination of Requirement Types using transaction

339

 Here you assign the requirements type to the relevant item category in the sales order and the MRP type found on the material master record. The MRP type is used in the material master to determine how a material is planned for automatic reorder point planning, manual reorder point planning, or forecast based planning. Generally, the system uses the following process to determine the requirements type, as shown in Figure

 However, the system uses a predefined search strategy to determine the requirements type: 1. First, an attempt is made to find a requirements type using the strategy group in the material master 2. Then if the strategy group has not been maintained, the system will determine it using the MRP group. 3. If, however, the MRP group has not been defined, the system uses the material type, instead of the MRP group, when accessing the corresponding control tables

340 4. If no requirements type is found here, the system assumes a special rule and attempts to a requirements type with the aid of the item category and the MRP type. 5. If this is not possible, a last attempt is made to find a requirements type with the item category only. 6. If the last attempt fails, the system declares the transaction as not relevant for the availability check or TOR  Should you not want this strategy to be used to search for a requirements type and instead would like the system to immediately determine the requirements type based on the item category and MRP type as you assigned them, you can select an alternative search strategy where you assign the requirements type as shown in below figure. For this particular example, you would select a 1, which determines that the source is used as the item type and MRP type strategy.

Defining Procedure for Each Schedule Line Category Once this assignment has been made proceed to the menu path for Define procedure for Each Schedule Line Category Path: SPROIMGSales and DistributionBasic FunctionsAvailability Check and Transfer of RequirementsTransfer of Requirements Define Procedure for Each Schedule Line Category

341  As discussed previously, the TOR and the availability check can be fine-tuned at the schedule line category level. Note that this only allows you to deactivate a setting at the schedule line level only if it is already set at the requirements class level. Thus, you can select that a particular requirements class be active for the availability check or TOR and then decide that you do not want the schedule line to transfer requirements at the schedule line level. However, you must have selected the requirements class as relevant for TOR before trying to activate it at the schedule line level. Proceed with indicating which schedule line category will be available for the TOR availability check and/or product allocation. Note that the product allocation is also controlled in the requirements class. This is seen in Below Figure.

Block Quantity Confirmation in Delivery Blocks  After completing this, proceed to the Block quantity confirmation in the Delivery blocks menu. Path: SPROIMGSales and DistributionBasic FunctionsAvailability Check and Transfer of RequirementsTransfer of Requirements Block Quantity Confirmation in Delivery BlocksDeliveries: Blocking Reasons/Criteria

342

This blocking indicator is used to control many functions: Order: Blocking of sales document for delivery Confirmation: Blocking of the confirmation from availability check; thus, the stock will not be confirmed in the schedule line level and the stock will be available for other sales documents. Delivery Due List: Blocking sales document for automatic creation by the delivery due list. With this block in place, only manually created deliveries via VL01N will be possible. Picking: Blocking of Picking Goods: Blocking of Goods Issue To set a deferment period for the block of the confirmation of the reservation of the transfer of requirements from MRP, proceed with the menu path Path: SPROIMGSales and DistributionBasic FunctionsAvailability Check and Transfer of RequirementsTransfer of RequirementsReasons for and Scope of Delivery Blocks: Transfer of Req. Block

343

 In standard sales order processing, the system transfers the requirements to MRP, but in some cases you may need to block a transaction due to a bad result of the credit check, for example. In cases where the transaction is blocked, the requirement still sits in MRP and still reserves a quantity. This often is unfavorable; thus, you may indicate here that the system does not reserve the stock. It will still transfer the requirement to MRP but will not reserve the quantity  You can set a limit on the number of days you would want the system to postpone this block on confirmation of requirements. This can be carried out by setting a number of days to the block in the Def.period column.  This postponement period will only affect the order confirmation if the postponement falls within the confirmation period. For example, if a material is ordered on the 01.10 and confirmed for the 02.10 and the period for the block is 10 days, the resulting confirmed date would be 11.10. However, should the original schedule line only be confirmed in 20 days, the block would have no affect on the sales order? Once the block is removed in the document, the system will do an availability check and confirm quantities with respective dates.

Maintaining Requirements for Transfer of Requirements Path: SPROIMGSales and DistributionBasic FunctionsAvailability Check and Transfer of RequirementsTransfer of Requirements Maintain Requirements for Transfer of Requirements

344

 In the same way as requirements are used in access sequences, that is, a number of preconditions must exist for the transaction to be carried out; requirements can be used to determine that the TOR to MRP is not carried out unless a number of conditions are met. A good example of this would be the standard SAP requirement that you can assign “102,” which prevents reservations from being carried out in the event of a credit block. You can also set requirements at the Maintain requirements for purchase and assembly orders menu  In standard sales order processing, a purchase order may need to be created in order to meet the demands of the customer. This purchase order is used to purchase new stock in order to meet the demand on MRP for a particular customer’s sales order.  Here you define requirements that must be met in order for the purchase order or assembly order to be created. An example is the standard SAP requirement 101, which will cause a purchase order or assembly order from being created, should a credit block exist on the sales order.  This completes the SD module’s task of configuring the TOR. The TOR is closely associated with the availability check. They should be planned and configured at the same time.

345 Availability Check  The availability check is an integral part of the business process. It determines if the requested delivery quantity can be available for shipping in order to meet the customer’s requested delivery date. The availability check is carried out at a Plant level. It results in a material availability date. This represents the date the system has determined the requested material will be available. Added to this date is the pick pack time, the loading time, and the transportation scheduling time, which may or may not be added depending on how long it is. All of those dates result is a planned goods issue date, which is the planned date the goods are transferred from the business ownership and control, possibly to a shipping agent. The shipping dates are then added to goods issue date, resulting in a delivery date. This automatically determines delivery date is then communicated to the customer when the sales order is placed.

Terminology Used in the Availability Check  Rescheduling is a proposal of how confirmed quantities already assigned to sales orders can be reassigned to other orders that have a higher priority, such as an a earlier delivery date.  ATP stands for available to promise. It is the process of checking the available quantities of a material. The ATP quantity is equal to warehouse stock plus the planned receipts (incoming stock) minus the planned issues (outgoing stock). ATP takes into account all movements into and out of the warehouse. If selected, it can check the stock examined for ATP that can be safety stock, stock in transfer, stock in quality inspection, and blocked stock, although the planned receipts and planned issues of the stock associated with ATP may be purchase orders, purchase requisitions, planned orders, production orders, reservations, dependent reservations, dependent requirements, sales requirements, and delivery requirements. If the business produces special stock such as made-to-order goods or consignment stock, the ATP check is done against the special stock.  Replenishment lead time (RLT) is the time needed to produce the requested stock. It can be the time taken by the business to produce a material or the time taken to externally procure the material from a vendor. This includes the goods receipting time; thus, the RLT is the time taken for the material to become available. RLT is only used when doing an ATP check. The value of the RLT for a material is specified on the material master record. It can be determined in one of two ways: 1. The RLT for an externally procured material. This is determined based on the total of the processing time for purchasing, the planned delivery time, and the goods receipt processing time. These settings can be made on the Purchasing and MRP 2 views of the material master record.

346 2. The RLT for an internally procured material. This is based on the in-house production time, found in the MRP 2 view, and the goods receipt processing time or alternatively on the total replenishment lead time, which is found in the material master record on the MRP 3 View Note: If a sales order is created, there is no available stock, and the ATP check is set to include RLT, the system will automatically confirm the desired quantity for the end of RLT based on whether the material is externally or internally procured. Thus, should you have an order for 100,000 pieces of material XYZ and the system has no available stock, it will still give a confirmed date according to the end of the lead time. Should there be partial stock available, the system will confirm this partial quantity and move the remaining quantity to the end of RLT. Thus, it does not do an availability check outside of the RLT. If RLT is three days for a specific material, it will not do an availability check outside of those three days, as it automatically thinks it will definitely have stock on the fourth day.  To examine stock on hand you may use the availability overview, proceed with the path: Path: Easy AccessLogisticsSales and DistributionSalesEnvironmentAvailability Overview [CO09]  To examine stock on hand from a created order, proceed to change mode [VA02] to the schedule line, the select the menu path Environment Availability  There are three types of availability checks: 1. The first is the availability check on the basis of the ATP quantities, as previously described 2. The second is the availability check against product allocation, with which one is able to do an availability check against product allocation, allowing a predefined distribution quantity of products to customers 3. The third availability check is the check against planning.

Basic Elements of the Availability Check: Checking Groups:  The checking group defines what type of requirements we will pass on. Do we record summarized requirements daily or requirements in the stock requirements list weekly? Or do we record individual requirements for each sales order, line item, and schedule line in the stock

347 requirement list?  The advantages of individual requirements over summarized requirements are as follows: 

Backorder processing is possible for individual processing



We can access the order and line items and schedule lines in MD04. This gives one greater control over the available stock and the requirements placed on the stock.

 The disadvantages are that there may be slightly more impact on system performance as each demand is placed immediately into the stock requirements list.  Do not forget the system automatically uses individual requirements for special stock movements such as consignment stock, returnable packaging, and so on, even if summarized requirements have been selected  The checking groups are configurable, yet SAP standard uses the following checking groups:  

01 to represent daily requirements 02 to represent individual requirements

 The checking group plus the checking rule determines how the availability check is to be performed. The checking group is found on the material master record MRP 3 view. Checking Rule  The checking rule is used to control the scope of the availability check for each transaction in sales and distribution. The control of the availability check is defined by the checking group on the material master record and the checking rule representing the transaction. The checking rule may be configured in the system depending on the application or module, but in the sales and distribution module, it is predefined. Schedule Line Category  The availability check can be fine-tuned at the schedule line level in the same way as the TOR is carried out at the schedule line level. Those schedule lines that are not relevant for an availability check can be switched off at the schedule line level by ensuring the availability check indicator is not flagged.

348 Delivery Item Category  The delivery item category can be used to control whether an availability check takes place in deliveries Requirements Class  The requirements class, as used in the TOR, controls the relevance for the requirements planning strategy and the requirements consumption strategy. It is also responsible to determine if an availability check is to be performed for the material on the basis of the ATP quantity and whether the TOR is passed on. Requirements Type  The requirements type refers to the requirements class and its features. The requirements class is assigned to the requirements type in the TOR. Required Data for the Availability Check to Be Carried Out  In order for the availability check to be carried out, the following data in addition to the configuration entries, described later, must be defined in the system: 

The availability check must be switched on at the requirements class level. Refer to the Transfer of Requirements TOR configuration process [OVZG]



For the availability check in the sales document, the indicator must be set at the schedule line category level [OVZ8]



A requirements type must exist by which the requirements class can be found. Again refer to the TOR [OVZH]



A plant must be defined in the sales order for the line item. It can either be automatically proposed by the system from the customer, the customer material information record, or the material master record. It can also be entered manually in the document.



A checking group must be defined in the material master record in the MRP 3 screen in the Availability check field

349 Configuring the Availability Check with ATP Logic We can now progress to the configuration of the availability check Defining Checking Groups: To define Checking Groups, use the following Path: Path: SPROIMGSales and distribution Basic functionsAvailability check and transfer of requirementsAvailability checkAvailability Check with ATP logic or against planningDefine checking groups.

 You can use the standard SAP checking groups of 01 for summarized requirements and 02 for daily requirements or you can create your own entries. Should you create your own, do not forget to copy and name them using the SAP allocated range beginning with a Z.  The columns total sales and total deliveries are selection options whereby you can configure a checking rule to sum up requirements to post to MRP either individually or by day or week.  Do not forget that by selecting the summarized requirements you will lose out on the connection to the individual sales order and associated line item in the stock requirements list [MD04]

350  Note column 5, Block QtRq; set this block if you want several users to be able to process the material simultaneously in different transactions without blocking each other.  The No check indicator is used when you want a material to not be relevant for an ATP check; thus, no check is carried out for the material with a checking rule indicating “no check.” For materials that there is a high quantity of stock for, it would be impossible and unnecessary to validate the available quantity. Defining a Material Block for Other Users To define a material block for other users, use the following path: Path: SPROIMGSales and distribution Basic functionsAvailability check and transfer of requirementsAvailability checkAvailability Check with ATP logic or against planningDefine Material Block for other users

 The Block checkbox is an indicator that enables you to block the particular material from being checked for availability if it is already being checked at the same time by another user. This block serves a valuable purpose in that, should the block not be set, two users can confirm the same quantity for the same material at the same time.  You cannot change the field value for the initiator of the availability check, such as A-order or B- delivery note, as in the configuration menu.

351 Defining the Default Value for Checking Groups To define a material block for other users, use the following path: Path: SPROIMGSales and distribution Basic functionsAvailability check and transfer of requirementsAvailability checkAvailability Check with ATP logic or against planningDefine Checking Groups Default Value

 We have defined the checking groups, which are introduced into the sales order based on the setting in the material master record. However, should no entry exist in the material master record, one can set a default value per material type and plant. This default value will be used by the system based upon the material type of the material master record and the plant in the sales order, unless an entry exists in the material master record, whereby it will be overwritten by the material master checking group. Carry Out Control of the Availability Check: Here you finally define what values must be checked in order for the system to determine the availability quantity. Use the following Path: Path: SPROIMGSales and distribution Basic functionsAvailability check and transfer of

352 requirementsAvailability checkAvailability Check with ATP logic or against planningCarry out Control for Availability Check

Select the line item and click the Display Button. In this section, you tell the system what stock on hand and what inward and outward movements of stock it must take into account when performing the availability check  These settings are based on the checking group that is assigned to the material master record and the checking rule that is predefined and assigned to the sales and distribution transaction.  The carry out control for the availability check must be maintained for both the sales order and delivery as seen in below figure.

353  This is due to the fact you may want to include specific stock or incoming stock for the sales order, yet at the time of the delivery only include physical stock on hand waiting to be shipped. Select the indicator, should you wish to take the respective stock into account when carrying out the availability check, such as    

Safety stock Stock in transfer Quality inspection stock Blocked stock

 Now select the planned inward and outward movements of stock you would like to take into account when doing an availability check: 

Include sales requirements is used to include the requirement based on a sales transaction that could have been previous orders placed for the material or even quotations



Include deliveries is used by the system to include requirements passed on from a delivery document for this material.



Include reservations is used to determine if the system should take into account the reservations of stock for this material



Include dependent requirements is used by the system to indicate if dependent requirements such as components of a production order are taken into account



Include purchase requisitions are used by the system to determine if it should use the requisition for purchasing to obtain more stock in the availability check.



Include purchase orders is slightly better than purchase requisitions as it tells the system to include actual orders placed for more stock.



Include shipping notifications is used by the system to include confirmed purchase orders, ensuring that stock is coming into the plant or warehouse.

 You can then check dependent reservations and release order requirements, planned orders, and production orders  It is also possible to indicate to the system that you would like the availability check not to check the stock at the storage location level. Should you set this indicator, the system will automatically use the check based on the plant. We covered replenishment lead time earlier

354 on. Should you not want the system to automatically check the replenishment lead time, you may indicate so here.  The business now needs to define the elements necessary to be included in the availability check. No one can define what your specific business would need to include or exclude in the check, but a few tips in making these decisions would be the following: 

When controlling the availability check at the time of the sales order, a purchase requisition does not necessarily indicate the stock requested by it is going to come in to the plant



A shipping notification, which is a confirmed purchase order, on the other hand is a good indicator you will be receiving stock at a certain date.



Should you select shipping notifications as an element for the availability check in the sales order, be careful if selecting it for the delivery. You may discover you actually did not receive the stock and may be creating a delivery with no materials in the plant or warehouse



Both sales and delivery requirements are taken into account in the availability check in sales documents. However, in deliveries, only the delivery requirements are taken into account and there is a danger that quantities reserved in the sales documents are considered to be available by the availability check in the deliveries. This results in the deliveries being created and the material availability dates of the materials in the sales order being pushed out.

Determining the Procedure for Each Delivery Item Category  In this step, you switch off the availability check for specific delivery item categories. This should be done for returns deliveries. Use the following Path: Path: SPROIMGSales and distribution Basic functionsAvailability check and transfer of requirementsAvailability checkAvailability Check with ATP logic or against planningDetermine Procedure for Each Delivery Item Category

355

Checking the Rule for Updating Backorders  The checking rule used here is the same checking rule as configured in the carry out control of the availability check. This checking rule is used in the availability overview [CO09] and during backorder processing [CO06]. Use the following Path: Path: SPROIMGSales and distribution Basic functionsAvailability check and transfer of requirementsAvailability checkAvailability Check with ATP logic or against planningCheck Rule for Updating Backorders

356 Defining Default Settings for the Results of the Availability Check in the Sales Order  Here you define the default setting according to the sales organization, distribution channel, and division (sales area). Use the following Path: Path: SPROIMGSales and distribution Basic functionsAvailability check and transfer of requirementsAvailability checkAvailability Check with ATP logic or against planningDefine Default Settings

If you should automatically fix the date and quantity of the delivery date, and thus the resultant material availability date and you select this indicator, the delivery dates are fixed in MRP. However, should you not select the fixed date and quantity and can speed up the supply of the materials into your plant, the resultant material availability date is more favorable and you can reschedule the dates in order for them to obtain a more favorable delivery time.  The availability check rule is a rule defining what the result of the availability check in the sales order should be. This can take the form of either a pop-up window where the user can select either a delivery proposal or a complete delivery or it could take the form of the system automatically selecting a delivery proposal, a one-time delivery, or a complete delivery without a pop-up window being shown Note: The availability checking rule set here not only determines what the user sees when

357 carrying out an availability check online; it also determines the result of the availability check in background mode. The entry in parentheses defines how the system behaves in background mode. Background mode can be active during any batch rescheduling that you carry out. One-time delivery: The system will try to confirm material for the requested delivery date. Should it not be able to confirm stock for the requested delivery date, it will confirm a value of zero  Complete Delivery: The system will only confirm a delivery date on a date when the entire scheduled, ordered quantity for that line in the sales order is available. For example, should the quantity ordered be 100 pieces for an order on January first with a requested delivery date of January first and you have 90 pieces available, the system will wait until 100 pieces can be confirmed, which may be at the end of the lead time for the material. If the lead time is one month, the complete delivery will only be made on the first of February Delivery proposal: Here the system will confirm the quantity it has available for the requested delivery date. It will then create another confirmation for the resulting outstanding material for the end of the lead time or for when new stock will be available. Using the previous example, the system will confirm the 90 pieces immediately, use forward scheduling to propose the delivery date (plus six days, for example), and will then confirm a second delivery date for the remaining 10 pieces at the end of the lead time that is February the first.  You can select an availability check across plants from the availability control screen by selecting Go toOther plants. This will display a selection for the user to select the other plant he wishes to check. Note only those plants in which the material is maintained will be displayed  By selecting Go toScope of check in the Availability Control screen, the system will display the automatic control of the availability check, that is, the selections of stock availability  You may receive two specific messages when carrying out an availability check on a line item. One may be a “product allocation found changes to the confirmation.” This means that the customer purchasing the stock has exceeded his allowed quantity and the product allocation has limited the quantity he may consume for this material or for this particular line item. It is possible to see his allocated quantity by proceeding from the availability control screen to go toProduct allocation. This will also show his consumed quantity and the quantity he still has available to consume. We will cover product allocation later.  The other message you may get is “no feature combination exists ........” This message is also linked to product allocation, yet this message will mean that no availability check will be carried out. This is because the system has tried to do an availability check according to product allocation yet has found errors in the process setup. These errors could be that the customer is absent from a planning hierarchy (used in product allocation) or an incorrect schedule line category is being used to allocate according to product allocation, but neither the customer nor the transaction are relevant for product allocation.

358

Delivery Delivery Process The delivery process is a continuation from the sales process. It is generally used to outbound processing to move goods from the plant to the shipping vendor to the customer. However, the returns process of inbound deliveries is also included as a standard SAP delivery process, where instead of “posting goods issue” for outbound deliveries, we “post goods receipt” for an inbound flow of products back into our plant. A delivery document can be created with reference to a sales document such as an order or a scheduling agreement or it may be created for an example with reference to an inbound return sales document.

Delivery Document Configuration  A delivery document type is similar to the sales order document type. Whereas in the sales process the sales document structure and control were defined largely by the sales document type, in the delivery process the delivery document type controls how the delivery is to function. The structure is very similar to a sales document type in that a delivery document has a header and item structure. The output of an SAP delivery is a goods movement.

Defining Delivery Types The SAP delivery document is usually the step subsequent to a sales document type and preceding a billing document. However, a delivery is not restricted to being created from a sales document type. Path: SPROIMGLogistics ExecutionShippingDeliveriesDefine Delivery Type [OVLK] Ex: LF  Delivery with reference to Order LO  Delivery without reference to Order LR  Returns Delivery BV  Cash Sales Delivery NL  Replenishment Delivery (For Intra Company Sales) NLCC  Replenishment Delivery (For Inter Company Sales)

359

360 Functionality of Delivery Document Types 1. Document Category: This is a critical field that identifies to the system what document type is being used. It is used in internal table controls, for example, to determine system responses and messages. For Delivery, you must use the value “J” only. 2. Number Ranges: Here you assign the particular number range your delivery will follow as well as the item incrimination in the delivery document type. You can create the number ranges relevant for delivery documents by proceeding to SPROIMGLogistics Execution ShippingDeliveriesDefine number ranges for deliveries [VN01]. After creating the interval, refer to the section on defining number ranges. If necessary, you can assign your delivery document number range to the document type. 3. Order Required: Specifies whether a reference document is required for creating the delivery document. For example, if you create Delivery Documents without a Sales Order Reference, you must use the option “No Preceding Document Required” in this field. 4. Default Order Type: It is the pseudo Sales Document Type. It is also an important field. This is required when delivery is made without referring to a Sales Document. When Delivery Document is made without a Sales order, the Billing Document Type is taken from this Sales Document type. The Movement Type is also based on this Sales Document Type.  When it is necessary to have a specific goods movement assigned to a delivery that has no sales document type used as a reference, your pseudo-sales document type must have an item category followed by an assigned schedule line category. It is this schedule line category that must have the assigned goods movement. Be sure when creating document types and objects in SAP to copy the standard and change the name beginning with the permitted naming convention Z.  An example of a pseudo-sales document would be when the warehouse asks for a specific delivery that must not be created from a sales order but will use a special goods movement type. This goods movement type, such as 901, is used to show the return of stock to a supplier. a. You would configure this by copying a standard delivery type. An example would be LF and you would name it ZLF. b. You would then copy a sales document type, such as TA, and name it ZTA, followed by copying an item category TAN and naming it ZTAN. c. Finally, you would copy a schedule line category such as CP and name it ZCP.

361 Assigned to this schedule line category would be the movement type 901. d. You would then assign the sales document type ZTA to the delivery type ZLF as the default order type. e. Do not forget your individual settings in the relevant document types and item categories as well as the copy control settings. 5. Item Requirement: It Specifies a requirement routine for a delivery item that does not refer to the order i.e. if that item has to be further processed it has to fulfill the requirement of this routine. 6. Storage Location Rule: This field is applicable if you want to determine storage location. It specifies the rule that the system uses to automatically determine a corresponding storage location for the delivery item. There are 2 rules, MALE and MALA, for determining Storage Locations. The Storage Location is determined by a combination of Shipping Point + Plant + Storage Condition. However, this only applies if the storage location rule on the delivery document type is MALA. 7. Output Determination Procedure and Output Type: These fields are used by the system in allocating output to the delivery document type. 8. Text Determination Procedure: It is used by the system to determine where the texts are allocated from in the delivery. 9. Document Statistics Group: The document statistics group is the determining field that updates the logistics information structures (LIS). It is not possible to assign a value to this field, but you can assign a value to the delivery document type in the control settings for LIS. Note it is only advisable to assign a statistics group value to those deliveries and delivery items that do not contain a reference to an order. 10. Application: The settings for the application are internally used by the system to allocate output, such as output used for sales orders or delivery documents. 11. Delivery Split Warehouse Number: If you check this field the delivery can be split depending on the warehouse number. You can also force a delivery split by partners by setting the delivery spilt part checkbox. 12. Partner Determination Procedure: The partner determination is also not available in the delivery document type. It is set in the assignment of document types to the partner’s determination procedure 13. Rescheduling: The rescheduling indicator is used to reschedule backlog deliveries

362 14. Automatic Packing: The automatic packing indicator controls if the packing proposal should be adhered to and if the items in the delivery automatically are packed or not. If you permit the delivery document type to automatically create packing items based on the configuration for packing, then check the generate packing material item box. 15. Distribution Mode: If you use a decentralized warehouse management system, you will wish to update the system automatically. This is defined by the setting in distribution mode. 16. Screen Sequence Group: The screen sequence group determines the screens and their sequence for a certain delivery type. 17. Display Range: The display criteria controls the data display for the delivery items. For example, you can limit the display to only main items and to suppress all items dependent on main items Save the Delivery Document Type

Delivery Item Categories and Determination  A delivery item category is similar to the sales document item category in that it controls how the item is to behave in the document type. Generally, the delivery item category has the same naming convention as the sales document item category from which it is determined, yet it has its own control features.

Defining the Delivery Item Category To define delivery item categories, use the following menu path Path: SPROIMGLogistics ExecutionShippingDeliveriesDefine Item Categories for Deliveries [0VLP]

363

Functionality of Delivery Item Category

364 1. Document Category: The item category is assigned to a document category; in this case the document category is for deliveries, represented as a “J” 2. Material Number “0” Allowed: The Material Number 0 allowed field is used to permit the item to be created without having a reference to a material reference. This is used in examples for text items, where on creates a line item with a special item category and types text in the description of material description. 3. Item Category Statistics Group: The Statistics Group for the item category is used to generate statistics in the logistics information system. 4. Stock Determination Rule: The stock determination rule is used in conjunction with the stock determination group to determine the stock determination strategy. 5. Check Quantity 0: The check quantity of 0 specifies whether you can create an item that has a zero quantity and, if you do, how it is to react with a warning or error message or no message at all. 6. Check Minimum Quantity: Specifies whether the system checks the minimum delivery quantity specified in the material master or customer material info record. If so, it also specifies how the system reacts if that minimum quantity is not met in the delivery. 7. Check Over delivery: Specifies whether and how the system reacts if the delivery quantity of the item exceeds the order quantity. 8. Availability Check Off: Specifies whether the system carries out availability check for the delivery item. 9. Rounding: Specifies whether and how the delivery quantity of the item is to be rounded. 10. Relevant for Picking: If we check this field, the item becomes relevant for picking. Note: Certain items such as returns are not relevant for picking. So we must not check this field in that corresponding item category REN 11. Storage Location Required: If we check this field, the storage location becomes mandatory for the delivery item before it can be further processed. 12. Determine Storage Location: If we check this field, the system automatically determines a corresponding storage location for the delivery item. 13. Don’t Check Storage Location: If we check this field system will not run a check for the storage location entered for the delivery item 14. No Batch Check: If we check this field, it ensures the system does not check to determine if the batch entered in the delivery item exists in the system or not 15. Automatic Batch Determination: If we check this field, the system automatically determines a corresponding batch number for the delivery item 16. Packing Control: The packing control indicates to the system that the line item can be packed, must be packed, or cannot be packed. Should “must be packed” be selected, the materials must be packed before goods issue can happen 17. Pack According to Batch Items: The pack according to batch is an indicator selecting packing according to a batch split or to the main item only Save the Delivery Item Category

365 Defining Delivery Item Category Determination: While creating a delivery, system automatically determines a corresponding item category for the delivery item. For this the following setting must be done. Path: SPROIMGLogistics ExecutionShippingDeliveriesDefine Item Category Determination in Deliveries. The Item Category Determination is not defined for those delivery items created with reference. Because, the system copies the item category from reference sales document to delivery document. For those delivery items created without reference, we have to maintain the item category determination where we have to assign the item category to the combination of “Delivery Type”, “Item Category Group”, “Usage” and “Higher Level Item Category.”

Shipping Point Determination Shipping Points are independent organizational units that are linked to a plant and represent the point of departure or receipt of materials. A plant may have many shipping points. A delivery is created from one shipping point only. Shipping points are based upon the configuration settings. Use the following menu path. Path: SPROIMGLogistics ExecutionShippingBasic Shipping FunctionsShipping Point and Good Receiving Point DeterminationAssign Shipping Points.

366

The Shipping Point is the location from which a delivery originates. Whether that location is physical or a systematic location, no delivery may be made without a shipping point. The Shipping point is determined by the system based on the shipping conditions, which are either entered manually in the sales order or are copied from the customer master record. (Shipping Conditions may also be copied from the sales document type if not maintained on the customer master). The shipping point is also determined by the loading group, which is copied from the material master record, and the delivering plant of the line item in the sales order. This is illustrated in Figure

 Should a customer ask for a complete delivery, it makes sense that you should not have multiple shipping points manually entered for each line item in the sales order, or else the customer will receive multiple deliveries?  As each delivery is created via a shipping point, and each run of the delivery due list is made with reference to a particular shipping point, you may want to have an express shipping point. This way, you can run the due list every half an hour for one shipping point only to create deliveries for that particular plant. Likewise in the sales order, the user knows that if he manually enters a specific express shipping point, he will have the delivery created within half an hour. The remainder of the deliveries may be created via the delivery due list in the normal processing run.

367 Configuring the Shipping Point Determination First we have to define shipping condition, which we have already defined while configuring Customer Master Record. The shipping conditions are entered in the customer master record in the shipping screen and in the sales document type. These settings are then copied into the sales document and are used to determine the shipping point. The shipping conditions can be manually changed in the sales order, or they can be defaulted to a particular sales document type. Should they be defaulted to a particular sales document type, the system will ignore the setting on the customer master record  Now we define shipping conditions by the sales document type. As discussed, the shipping conditions defined by the sales document type override the shipping conditions automatically proposed by the system from the customer master record. This is useful in returns Path: SPROIMGLogistics ExecutionShipping Basic Shipping FunctionsShipping Point

and Goods Receiving Point DeterminationDefine Shipping Conditions by Sales Document Type.

368  In returns processing, a returns delivery must be made with a shipping point that represents the incoming goods. It would not be recommended to use the same shipping point for returns or receiving goods as you do for outgoing deliveries. Thus, you can assign all returns sales document types their own returns shipping conditions and promote a returns shipping point. Having a return shipping point allows greater visibility of material movements in the system and in the plant, as well as allowing the processing of the delivery due list for returns orders only.

Defining Loading Groups Path: SPROIMGLogistics ExecutionShipping Basic Shipping FunctionsShipping Point

and Goods Receiving Point DeterminationDefine Loading Groups

 The loading group is used in the determination of the shipping point and is copied from the material master record  As a delivery is not possible without a loading group, it is recommended that you indicate the field loading group of the material master record as a mandatory field. This way, no

369 material master record can be created without a respective loading group. The loading group in Figure is a four-character alphanumeric key. You may copy a standard and rename it After Configuring Shipping Point Determination, Go to Assign Shipping Point and then create new entries. Assign the shipping point to the combination of Shipping Conditions, Loading Group and Plant.

Delivery Creation Process Deliveries can be created either with reference to sales order or can also be created without reference to sales order.

Creating a Delivery With Reference to Sales Order Path: Easy AccessLogisticsSales and DistributionShipping and TransportationOutbound DeliveryCreateSingle DocumentVL01N – With Reference to Sales Order (Create Delivery Document)

1. Shipping Point: Specify the shipping point from which the order has to be delivered 2. Selection Date: Specify the delivery creation date 3. Order: Specify the Sales Order number for which the delivery is created Note: While creating delivery with reference, it is not required to specify the delivery type because it will be automatically determined from definition of reference sales order document type.

370

In the overview screen, select the ‘Picking’ tab page where we find the pick quantity as zero. We used to pick the required quantities either from the plant or warehouse. We need to pick the required quantities either from the plant or warehouse depending on the requirement.

371 Picking the stock from the plant depends on usage of batches for material. If the material is maintained in batches we have to pick the required quantity from the required batch number and for this select the delivery item, select the button ‘Batch Split’ and specify the required batch number and the corresponding picking quantity. If the material is not maintained in batches, we can directly enter the required picking quantity. To pick the material from warehouse, we used to create the document ‘Transfer Order.’ For creating transfer order, save the delivery document and from the Easy Access Menu go to following path: Path: LogisticsSales and DistributionShipping and TransportationPickingCreate Transfer OrderLTO3-Single Document You can also create transfer order by “Subsequent functionsCreate Transfer Orders” from the main menu of delivery document overview screen On the transfer order initial screen, specify the warehouse number from which the picking has to be done and specify the delivery number for which picking has to be done. The moment we get into overview screen, the system picks the required quantity and save the transfer order. Note: The delivery quantity in the outbound delivery will be copied as picking quantity in transfer order Come back to the delivery document which is already created by using transaction code “VL02N” and select the picking tab in the overview screen where we find completely picked quantity Select the button “Post Goods Issue” which specifies that goods are leaving the company. Effects of “Post Goods Issue”: The stock of the material will be reduced by the corresponding delivery quantity. For the system to reduce the stock, we have to specify the movement type ‘601’ in the corresponding schedule line category. The value changes are posted to the balance sheet account in inventory accounting Goods issue is automatically updated in the document flow

372 Collective Processing of Orders due for Delivery: 1. To combine multiple orders for a customer, we have to check the field “Order Combination” in the corresponding Customer Master 2. To combine multiple orders, all of them must have same “Shipping Point”, “Delivery Creation Date” and “Ship to Party”. To combine multiple orders for creating a single delivery go to following Path: SAP Easy AccessLogisticsSales and DistributionShipping and TransportationOutbound DeliveryCreateCollective Processing of Document Due for DeliveryVL10A-Sales Orders. 3. Specify the required “Shipping Point”, “Delivery Creation Date”, “Ship to Party” and select the icon execute 4. The system gives list of sales orders that are to be delivered from specified shipping point to the specified ship to party on the specified date 5. Select the required orders to be combined and select the button Create Delivery in background 6. Select the Icon ‘Log for Delivery Creation’ 7. The system generates a group number which contains the delivery created 8. To see the delivery created, select the group number and select the button “Documents” 9. For the delivery created by the system, we need to complete picking and post goods issue

Creating Partial Deliveries: To create partial deliveries for a customer, we have to specify the value “Partial Delivery Allowed” in the customer master for the field “Partial Delivery per Item.” We used to create partial deliveries in the following scenarios: 1. If the quantity ordered by the customer is confirmed on different dates, we need to create the deliveries on those dates for the corresponding confirmed quantity

373 2. Even though the entire quantity is confirmed on a single day, still we may need to have partial deliveries if the customer requires it. This can be done in the following 2 ways: A. When we create the delivery with reference to order, the entire quantity will be copied to delivery which we have to change as per the customer’s requirement and complete the delivery. The next time when we create one more delivery with reference to same order, the system copies the remaining quantity into delivery which again we have to change as per the customer requirement. Like this we need to create the deliveries till the entire order quantity is delivered B. We can directly enter the required delivery dates with the corresponding quantities in the schedule line data of the item in the sales order itself and create the deliveries on those dates

Picking and Interfacing with Warehouse Management  Picking is the process where the stock is selected from the storage facility to fulfill a delivery. One needs to pick the correct quantity of the right items for the delivery. Path: SPROIMGSales and DistributionShippingPicking  First, not all items are relevant for picking. You may have items such as text items or return items that are not picking-relevant. Picking is always carried out from a particular storage location. Thus, for a delivery to be picking-relevant, a storage location must always be entered. If interfacing with warehouse management, the storage location in the delivery determines which storage location to use in the warehouse.

Item Categories Relevant for Picking Here you indicate to the system which item categories are relevant for picking. This indicator can either be set here or when defining the delivery item category. Should the item not be relevant for picking, it is not necessary to have a storage location determined for the item either. Thus, when creating the delivery item category, you would not need to indicate “determine storage location” or “storage location required.”

Interface with Warehouse Management  In SAP, you can create a warehouse for a storage location. This means that all movements within that storage location need to be managed using the warehouse management (WM)

374 functions in SAP. You define warehouses in the enterprise structure for materials management. You also assign the warehouses to storage locations in the menu path for assignments. If you have defined a warehouse in SAP and assigned it to a storage location, and you use this storage location in a delivery, then you must use warehouse management to do the picking for that delivery.  The process of placing goods in the warehouse is as follows. The goods are received in the interim storage area for goods receipts (for example, from production). A transfer order is then created in WM to move the goods into the warehouse. This tells the warehouse staff where to put the stock. When the stock is put into the warehouse in the correct place, the transfer order is confirmed, which tells SAP that the goods have been moved out of the interim storage area (the loading and unloading area) into the warehouse  Later when you want to deliver the stock, you need to fetch it out of the warehouse. You can create a transfer order from the delivery and SAP will choose stock from the warehouse to be delivered. This choice is based on a number of inventory methods, such as last-in, first-out (LIFO) and first-in, first-out (FIFO). The transfer order will instruct the warehouse staff where to get the stock from and to deliver it to the interim storage area for goods issue.  Once all the stock has been picked, the transfer order is confirmed, which informs SAP that the stock has been taken out of the warehouse and made available for loading in a loading bay or another such place. If you created the transfer order from a sales delivery, SAP will confirm that the delivery has been picked when you confirm that you have fulfilled the stock quantity in the transfer order. It can now be loaded onto the truck and goods issued.  Picking can be done on an interface with the WM module of SAP. Should this be the scenario once the delivery is created, you need to create a transfer order. You can create a transfer order from the delivery within the delivery select delivery by going to save and subsequent functions, Transfer order. It is also possible to create a transfer order for a delivery by proceeding from the logistics screen by going to Materials managementWarehouse managementTransfer order Create, for Delivery  After the transfer order number has been created, it is necessary to confirm the transfer order by proceeding to Transfer orderConfirm transfer order. This transfer order would carry out the picking automatically. A brief overview is illustrated in Figure Below.

375 Picking Requirements Path: SPROIMGLogistics ExecutionShippingPickingDetermine Picking LocationDefine Requirements for Picking

 Here you can define your own requirements that must be met before picking can be carried out. SAP uses the standard requirement 111, which restricts picking to be carried out only after checking and passing the credit check. Should you wish to create your own picking requirement you can create one using a number in the range from 500 upwards.

Determine Storage/Picking Locations The picking location is an area in which all picking is carried out in the same manner. The storage condition refers to the storage of the material in the plant or warehouse. It is found on the Plant Data/Warehouse 1 Tab of the Material Master record.

Defining Rules for Picking Location Path: SPROIMGLogistics ExecutionShippingPickingDetermine Picking LocationDefine Rules for Picking Location Determination.

376

 The entry maintained here is copied into the delivery header data. This entry here enables the system to determine the storage location automatically, should the storage location not have been maintained in the delivery manually. Proceed in assigning a storage location rule, such as MALA to the delivery document type.

Define Storage Conditions Path: SPROIMGLogistics ExecutionShippingPickingDetermine Picking LocationDefine Storage Conditions.

377  The storage condition is a two-character alphanumeric key that is used by the system to indicate the storage conditions for a material. This field is then used in combination with the plant and shipping point to determine the storage location. Assign Picking Locations Path: SPROIMGLogistics ExecutionShippingPickingDetermine Picking LocationAssign Picking Locations

 The picking location is the storage location. The system bases the automatic determination of the storage location on the combination of the determination rule MALA. This is assigned to the delivery document type that combines the shipping point, the delivering plant, and the storage condition on the material master record to determine the storage location, as shown in Figure

378 Backward and Forward Scheduling The customer specifies a delivery date on the schedule line of the sales order. The business must determine if it can carry out the associated functions in procuring the requested quantity and delivering it to the customer by the requested delivery date in the sales order. The business functions required to be performed before a delivery date can be met are the following: 

Time taken for Procuring materials, such as for obtaining materials from a supplier



Time taken for planning the transportation to obtain space on a ship, for example



Time taken for Selecting and packing the items



Time taken for loading the materials



Time taken for transporting the materials to the customer

This process of scheduling the business process from the requested delivery date backwards in order to meet a specified delivery date is called backward scheduling  If a customer’s requested delivery date is on the 20th of January for a sales order it places on the 14th of January, the system carries out backward scheduling from the date of the requested delivery date. Let’s say the transit time (the time taken to move the materials to the customer’s site) is four days and the loading time in the warehouse is one day. The transportation lead time (the time taken to schedule the containers or shipping companies to move the materials) is one day, which usually falls into the time taken for the material to become available. We now have a delivery date of January 20th, less four days, less another day, less another day, which gives us the 14th of January. Should the material be available on the 14th, we could confirm a delivery date of the 20th.  However, should the materials not be available on the 14th, and indeed if the system finds the materials will only be available at a later date, it immediately carries out forward scheduling, projecting the earliest possible delivery date based on the scheduling of the business process from the material availability date forward. Forward scheduling takes the availability date of the material in the future and adds the business processing scheduled times required to meet the requested delivery date. Thus, should the stock be available on the 18th in the previous example, the materials will arrive at the customer’s site on the 18th plus six days, (4 _ 1 _ 1) _ the 24th, less the time taken for transportation lead time, one day, as this step could have been carried out during the period waiting for the materials’ availability. Therefore, the delivery date based on forward scheduling would be the 23rd of January. If the route is not used when the pick/pack time or loading time is determined, the shipping point and the weight are the only factors used in determining the pick/pack time.

379 The shipping point and the loading group are used for determining loading time. The route is used to determine the transportation lead time and the transit time for transport scheduling.

Delivery Blocks Delivery blocks are very powerful in that they have the ability to not only block the delivery from being created but they may also block available stock from being assigned to a sales document that is blocked

Blocking Reasons: There are many areas available in the Sales and Distribution module for blocking. Shipping or delivery blocks are commonly used and may be manually entered or automatically proposed in the sales order and the delivery documents. One may configure these delivery blocks using the following menu path: Path: SPROIMGSales and DistributionShippingDeliveriesDefine reasons for blocking in shippingDeliveries: Blocking Reasons/Criteria [OVLS]

380 

Order: This setting will permit this block to be used to block a sales order for delivery processing. This block may be defaulted from the customer master record or placed manually in the sales order.



Confirmation: This setting will block the confirmation of stock after an availability check. This means the schedule line of the sales order will have a confirmed quantity of Zero. The requirement will still be passed to the MRP list but will not consume stock, which ensures the stock is available to be confirmed for other sales orders. Note that the confirmed schedule lines will be set to zero only once the block is set and the document is saved.



Print: This setting will block the output of the document. For example, if you have a document with a failed credit check, you may wish to block the order confirmation output.



Delivery Due List: This setting will block the sales document from being processed automatically by the delivery due list. It seems confusing to some people that a delivery block set manually in the sales document may block the delivery from being created individually, but does not block the delivery from being created with the delivery due list. If you wish to block both, then check this checkbox as well as the order checkbox



Picking: This setting will block the picking. You can set this indicator if you want to block picking from being carried out.



Goods Issue: This setting will block the goods issue for the delivery document.

After you have defined the delivery blocks, you must assign them to the delivery types for which they function. Using the following menu path Path: SPROIMGLogistics ExecutionShippingDeliveriesDefine Reasons for Blocking in ShippingDelivery Blocks

381

Once set, delivery blocks must be removed manually from the sales order A delivery block set at header level in the sales document blocks, the confirmation and sets it to zero. If you look in [MD04] the requirement is there, however, it does not consume ATP quantities. If you look in [CO09] the requirement does not reduce ATP quantities. A delivery block set at schedule line level in the sales document does not block the confirmation. If you look in [MD04] the requirement is there. If you look in [CO09] the requirement does reduce ATP quantities.

Delivery Blocking at Header Level:  Delivery blocks can be assigned manually in the sales order by entering the desired block in the header, using the following path Path: From within the sales document Go to HeaderShippingthen enter the delivery block

382

 Should you desire the block to be automatically proposed for specific sales document types, you can set the delivery block in the sales document type for which you want to automatically block. This is done in the Shipping area of the Maintain Sales Order Types screen.  However, this delivery block is only effective if this delivery block has been assigned in the respective delivery document type.

Delivery Blocking at Schedule Line Level:  Delivery blocks are also available at the schedule line level. These are simply delivery blocks that are manually entered in the sales document at the schedule line level. It is possible to have the system automatically propose a delivery block in the sales document for particular schedule lines. This can be done by allocating the delivery block to the Define schedule line categories screen.

383

 This delivery block at the schedule line level is always effective, regardless of whether the delivery block is assigned to the respective delivery document type or not. The schedule line category block is very useful, as it is not copied into the sales document item. This enables you to create a sales order and to manually set the delivery block for schedule lines due for delivery with a delivery date of over one month. You can still allow deliveries for unblocked schedule lines to be created within the month, although both sets of schedule lines originate from the same line item.

Delivery Blocks at the Customer/Header Level:  You can also block a customer master record for a particular sales area, or for all sales areas as far as deliveries are concerned. This is done in [VD05]. To set this block use the following path Path: SAP Easy AccessLogisticsSales and DistributionMaster DataBusiness PartnerCustomerBlock-VD05

384

You can block the customer for a particular sales area or for all the sales areas for which the customer belongs. This block is then copied into the sales document.

Packing  Packing is carried out at the item level. You can determine that a specific item is to be mandatorily packed or will be packed when necessary. This packed item then in turn may be packed again into a shipping unit, which in turn may be packed into another shipping unit, thus creating a multilevel procedure.

Packing by Item Category:  Packing by Item Category Packing is carried out at the item level. Thus, some items may need to be packed and other items may be forbidden to be packed. Each item category that needs packing must have its corresponding setting at the item category level. Path: SPROIMGLogistics ExecutionShippingPackingPacking Control by Item Category 

For those item categories that need packing, set the indicator to an A.

385 

For those item categories that cannot be carried out, set the indicator to a B.



For those item categories that do not have to be packed, yet packing can be carried out, leave the assignment blank

 You may select that, should there be a batch split in the delivery, the system is to pack the main item with an accumulated batch quantity or the batch split items only. Should you wish the main item to be packed, leave the Pack main item field blank? If handling unit inventory management is in use for a storage location, then the Pack Accumulated Batch setting has no impact

Packing Requirements: Path: SPROIMGLogistics ExecutionShippingPackingDefine Requirements for Packing in the Delivery

 You may want to create a requirement for packing. This requirement performs the same way as all other requirements in the SD module, in that the criteria stipulated must be met in order

386 for packing to be carried out. An example of a requirement here could be that no packing is to be carried out for items that have a credit block

Returnable Packaging  Not all packaging materials are inexpensive enough for the cost of the sale to include the cost of the packaging as well. One may have packaging materials that are valuable, and should a customer decide to keep or destroy the packaging items, he should reimburse the business

 Thus, returnable packaging is used in the process whereby the business sells items to the customer. These items are packed into shipping units, such as boxes and crates. The customer can then keep the boxes or crates up to a certain period of time and then must return the items. Should the customer not have returned the shipping units specified by that set date or should he have destroyed the shipping units, the business may bill the customer.

Special Stock:  The stock you deliver has special packaging materials. This packing is kept at the customer’s location but will remain the property of your company. He must return the packing to you within a period of time or be billed for it. The stock is recorded automatically as special stock at the

387 customer’s location. This special stock can be seen using the Stock overview screen using the transaction code [MMBE].Returnable packaging has the stock indicator of V.  You can also view returnable packaging at the customer’s site by proceeding from the logistics screen and going to Materials managementInventory ManagementEnvironmentConsignment Consignment at customer. Then select returnable packaging at customer  The sales order functions as normal; there is no special order type, but one can use the sales order view of a double-line entry. This enables you to view the main item and the returnable packing stock, shown as the lower level item to the item it packs. This is merely for display and traceability in the sales order; the packaging material may also be the main item of a sales order.  The packaging’s material master record should use the material type VERP for packaging and the item category group LEIH. The item category group LEIH is the SAP standard for returnable packing  If you enter a packing proposal in the order (by going to Edit, Packing proposal from within the order document), it is copied into the delivery. If you enter the item category in the shipping unit (selected from the shipping unit from the Edit, Packing proposal screen, and then selecting the General header data button), SAP will create a delivery item in the delivery for the shipping material from the packing proposal, even if you have not entered it as an item in the sales order.  For example, if you enter TAL (the item category for returnable packaging) in the shipping unit header, then when you create the delivery, SAP will also create an item TAL for that shipping material in the delivery. When you goods issue the delivery, SAP will record that this shipping material has been issued to the customer and must be returned. Note that you only have to price the returnable packaging in the returnable packaging issue order document. It does not need to be priced in the sales order and cannot be in this method.  Proceed with the normal packing configuration. The returnable packaging material follows the same rules as a standard material, in that you must define an item category for it as well as the necessary copy control rules. The SAP standard is to use item category TAL  Should you wish to create your own sales document item categories, you can copy and change the SAP standard that uses the item category LAN for the returnable packaging pick-up and the item category LNN for the returnable packaging issue. Do not forget to give your returnable packaging material a price.

388 Special Stock Partners  A special stock partner is a partner that is assigned to the customer master record in the sales order. This partner need not be the sold-to (SP), ship to (SH), bill-to (BP), or payer (PY) partner. However, this partner may be the partner who actually consumes the materials.  For example, should a large organization have a central depot where all consignment stock goes, and then the consignment stock is shipped directly to each customer’s plant as needed. The central depot would be registered in the system as a partner. For both returnable packaging and consignment stock, you can have special stock partners. You must first create a new customer for them using the same account group as if you were creating a sold-to party. One must then assign these special stock partners to the relevant sold-to parties’ customer master records. The special stock partners have the partner function key SB. When materials are consumed by the special stock partner, should there be any consignment stock or returnable packing, the system automatically picks up the special stock partner and records the stock in the system as being stored at their site. You can view these allocations of stocks in the same way as previously discussed [MMBE] and [MB58].

Posting Goods Issue in the Delivery  Goods issue is posted for a delivery once the goods are transferred into the hands of the carrier; that is, the ownership of the goods leaves the business and transfers to the carrier. The carrier then relieves himself of ownership of the goods once the customer signs for the articles. Once goods issue is posted in a delivery, the system updates numerous records.

389  The posting of goods issue causes the system to update the stock quantities. That is, the warehouse or plant stock is decreased by the quantity of goods that have left the warehouse.  The system also automatically updates the posting to the general ledger accounts. Based on the account determination for the inventory posting, the system decreases the value of the stock on hand and increases the cost of goods sold. Later, when the invoice is created, SAP will update the revenue accounts and the amount to be received from the customer. This completes the sales transaction from an accounting perspective.  The system also updates the requirements in the stock requirements list. Once goods issue has occurred, there is no longer a need for a customer’s delivery requirement to sit in [MD04]. The system then proceeds to update previous documents with a status displaying that goods issue has been posted. The system updates the deliveries relevant for billing and adds the delivery, if billing-relevant, to the billing due list.  From SAP Version 4.0, one can cancel a goods issue posting. To do this, proceed from the logistics screen and go to Sales and distribution, Shipping, Goods issue, Cancellation. Enter in the selection criteria you want and hit the Execute button. You will then see the deliveries that match your selection criteria. Select the deliveries you want to cancel and press Cancel/ Reverse.

Consignment Sales The consignment goods are those goods that are stored at customer’s location but owned by the company itself. The customer is not obliged to pay for these goods stock. This is done through an agreement that the customer will sell or consume as many of these materials as he can. Only after the customer has consumed or sold anything will the business issue an invoice. Should the customer not want to sell or consume any more material, he informs the business and it returns their stock Note: All requirements transferred from consignment sales orders to materials planning are transferred as individual requirements. This occurs regardless of what availability checking group indicator is set on the respective material master record  The Stock Consignment stock is monitored in our system by individual customer and material. The consignment quantity is controlled separately from the available stock for standard sales orders. This type of stock is referred to as special stock. Other forms of special stock are returnable packaging.

390 Process Flow of Consignment Sales: There are 4 main transactions for carrying out the consignment stock processing in the R/3 system all of which support a separate management of stock. 1. 2. 3. 4.

Consignment Fill Up Consignment Issue Consignment Pickup Consignment Returns

1. Consignment Fill Up: The consignment fill up is used to supplement the customer’s consignment stock i.e. the stock is transferred to the customer’s location but owned by the company itself.

 The consignment fill-up uses a standard sales order document type KB. This KB order type is then followed by a standard delivery LF. Creating Consignment Fill Up:  The consignment fill-up sales document type KB and all other consignment related sales document types should have the sales document category setting C (sales order). It is also advisable to use a different number range, as you will want the consignment sales process to be highlighted as a different sales procedure to the standard sales cycle a. Create an Order: The Item Category is “KBN”. KBN is not relevant for billing and pricing Note: The item does allow schedule lines. This is a fundamental element in the consignment process. The schedule line category determines how deliveries are to perform and what types of goods movements are carried out. The standard schedule line categories to be used are E0 and E1. Schedule line category E1, is used with materials requirement planning (MRP) and uses availability checking.  The schedule line states the item is relevant for deliveries and when the delivery happens, the item must use movement type 631. Movement type 631 is the key that, at the time of

391 goods issue, posts the stock into a special consignment category in the delivering plants stock for that particular customer and material  Do not forget to set up the sales document copying control for the sales document, item category, and schedule line category. You may wish to assign a delivery block to the sales document type KB, as this will automatically propose a delivery block before the materials are shipped to the consignee. Thus, you are able to monitor what stock you are sending and if it is authorized.  After completion of the customizing entries, create a sales order [VA01] using document type KB for a specific material and customer. Create the consignment fill up for the required quantity that has to be dumped at customer’s location. Next proceed with the delivery and goods issue. b. Creating Delivery: Create delivery by using transaction code VL01N. Complete the picking and Post Goods Issue. After completing the Post Goods Issue, the system creates a special stock for the concerned customer.  To view the stock the customer has on consignment, you can use transaction code [MB58] or transaction code [MMBE]. Enter the material and the plant, which delivers the material. Press executes and you will be seeing a list of stock for that material in the plant. Should you not select a plant but merely enter the material and select execute, the system will propose material in all the plants within a company code.  You are then presented with the stock overview screen. This screen shows the material, its description, and its type, in this case a HALB. It also shows its unit of measure as well as the total stock available for the company code. Note: When a consignment fill-up is carried out, the system checks the available quantity of stock in the delivering plant to see if this quantity can be met. When the system proceeds with a consignment issue or consignment pick-up, the system checks the stock represented at the customer’s site to see if there is an available quantity  Now that we have completed the consignment fill-up, the consignee may consume the material or sell some. He then indicates to us that this has happened, usually after it has actually occurred. Because the business is usually only informed after the consumption happens, it is not sensible to have any checking in the consignment issue cycle. For example, there is no need to have a billing block or a delivery block. It is possible to have an automatic credit check for consignment issues as you determine open items that are unpaid. A manual credit check should be done on the consignee before every consignment fill-up is done, however, should a fill up already be carried out, it is not physically possible to stop the consignee from consuming stock at his site, should he fail his check, as he usually only informs

392 the business after he has consumed one stock 2. Consignment Issue: The consignment issue enables the customer to take the goods from the consignment stock for sales purpose. It involves removing the goods from the consignment stock and making them the property of the customer.

 The consignment issue document type KE is again a sales document with category C. It has a standard delivery type LF. This document type is relevant for billing and should be relevant for delivery-related billing using a standard delivery type F2  The standard item category used is KEN. This is relevant for billing as well as pricing. It has schedule lines and should determine the cost of the item. Thus, the item category control for business data Note: The special stock indicators are used to indicate that the material being controlled must be controlled as special stock. For consignment, the special stock indicator used is a W. The standard schedule line categories used are C0 and C1.  Schedule line category C1 does an availability check and performs materials requirements planning. It uses goods movement 633, which checks for available consignment stock at the consignee’s site. The schedule line is relevant for deliveries. To create a consignment issue order use transaction code VA01 and enter the required order type. Then proceed with the creation of delivery and invoice  Once stock has been consumed from the customer’s consignment stock, that is, the delivery has been made and the goods issue posted, the stock overview [MMBE] screen will represent this transaction by showing a lower available quantity available in the customer’s consignment for that particular material. 3. Consignment Returns: The consignment returns are used when the customer wants to return the goods to the consignment stock  The sales document type KR has a sales document type category H, which indicates a sales return document. The return should also have a different number range for the visibility of returned items. The returns document type should also promote a special shipping condition that causes a special shipping point to be used in shipping point determination, which, as discussed in sales document types, can be used to process all return deliveries.  I would suggest all return order document types be restricted to a mandatory reference procedure. Thus, an M would be assigned, indicating a reference to a billing document. Do not

393 forget to assign the reference document in the copying control rules and make sure you select the update document flow in the copying control rules. This will ensure a direct path through the consumption and returns of stock.  Should one wish to utilize a different return pricing procedure for all return process flows? Enter a different document pricing procedure indicator. The assigned delivery type is LR. The delivery- related or order-related billing type should be RE. It is valid to automatically propose a billing block in order to check if the credit is authorized and valid. Thus, assign the standard billing block 08 here.  The item category in the sales document that is passed through to the invoice is KRN. Item category KRN also has the special stock indicator W to indicate the consignment process. The item is also relevant for delivery related billing and is valid for pricing.  The standard schedule line category used in the system for consignment returns is D0, which uses the standard movement type 634. Being the receipt of the customer’s consignment, the item is relevant for delivery. However, no transfer of requirements should be carried out and no availability check should be done. This is due to the fact that we are receiving the goods back into our plant. We cannot do an availability check, as the articles are moving back into the customer’s site, nor does it make sense to transfer requirements to our materials management.  The stock is moved back into the customer’s consignment stock, not our plant. The logic is that the customer will call us to pick up the unused goods and simply consume other material in their stock that is not faulty. Thus, the customer’s consignment stock will increase by the quantity he returned. To create a consignment returns order use the transaction code VA01 and enter the order type. . Next, proceed with the delivery, goods issue and Credit for Returns. 4. Consignment Pickup: Any consignment goods that are left with the customer without being sold can be reposted to the company with a consignment pickup.

 The sales document type KR should have the SD document category C, being a sales order. Depending on your business, it may be beneficial to have a mandatory reference. This will restrict all consignment pick-ups from being made unless they make reference to a fill-up order type. You can restrict the reference to being mandatory and to an order type, thus setting C, and then further control the referencing procedure by using the copying control rules. Again, in the copying control rules indicate the document flow.  As the stock is coming back into the warehouse or plant, you will want a specific returns shipping point to be automatically determined. Assign the special shipping conditions you use

394 to determine this.  No invoice is necessary, as the goods are not changing ownership. The materials in the fill-up are still the possession of the business and remain in their possession until the goods issue process is carried out in a consignment issue. The goods issue is the trigger that transfers ownership from the business to the consignment consumer.  The standard item category for consignment pick-ups is KAN. The standard schedule line categories of the consignment pick-up process are F0 and F1. We will look at F1, keeping in line with the observance of a materials planning movement process. Schedule line category F1 is relevant for delivery as well as a transfer of requirements and an availability check. It has SAP standard movement type 632.  Do not forget the availability check is done against the stock on the customer’s consignment. To create a consignment pick-up, Use the transaction code VA01 and mention the required order type. Next, proceed with the delivery and goods issue.  After goods issue, if you proceed to the stock overview screen, you will notice that the material available at the customer’s consignment has decreased by the quantity picked up. Note: If the customer wants to resell the special stock created after consignment returns, we have to create consignment issue. Whereas we need to create a consignment pickup if customer wants to send it back to the company Consignment Type Consignment Fill Up Consignment Issue Consignment Pickup Consignment Returns

SD Type

DFT It It.Cat.Grp Usage H.LVL.IT.CAT Cat

MRP Type

Sch Li. Cat

KB KE

NORM NORM

KBN KEN

ND ND

E1-631 C1-633

KA

NORM

KAN

ND

F1-632

KR

NORM

KRN

ND

D0-634

Questions Q. 1 – Describe in your own words how a consignment fill-up is different from a regular order? (Try to think of the following aspects – Accounting, Goods Ownership, Special stock vs. unrestricted stock, Customer Premises vs. the company’s plant location etc) Q.2 – Describe in your own words how a consignment issue is different from a regular sales order?

395 Q.3 – Describe in your own words, how a consignment issue is different from a consignment fillup? Q.4 – The deliveries related to only one of the following SAP sales documents need picking. Which one and why? Consignment Fill-up Consignment Issue Q.5 – Are physical goods in an SAP consignments Fill-up document type relevant for Availability check? Give the procedure on how you found out the answer.

Route Determination  Route determination is automatically proposed for each sales document item in the sales order. It is a process whereby one can assign a specific route with transportation legs using different shipment types and carriers. Route determination can also be predetermined in the delivery; this will use the weight group of the item that can, if defined, propose a different route to be used. Before one can assign the route determination to be used by the system, one needs to define the data that is used in the route determination. The configuration is carried out using the following steps.

Defining Routes: Path: SPROIMGSales and DistributionBasic FunctionsRoutesDefining RoutesDefine Modes of Transport

396

 The modes of transport are self-explanatory. They may be, for example, road or plane. You define the mode of transport used in the business and assign a two-character alphanumeric key with a meaningful description  Now let’s define the shipping types. The shipping types are the actual vehicles used to transport the materials and can be defined as a train, or mail, and so on. In this assignment, you assign the shipping types along with the previously defined modes of transport  The next step is to define the transportation connection points. Transportation connection points can be airports, railway stations, and border crossings. They define points where transportation types connect or where a transportation type crosses a border  After completing the transportation connection points, you can proceed with defining the routes and stages. In this activity, one defines the route with its associated route stages and transportation connection points  Now let’s define a route that is a six-character alphanumeric key with a description. For the defined route, you can set a forwarding agent or carrier as well as define the transit times and the transit lead time, which is the number of days required for organizing a shipment for an item that is to be delivered via a certain route. One can also specify the distance to be traveled and the total transit duration. Do not confuse the settings when defining the route here. The transit duration in calendar days and the transit planning time in hours and minutes are used by the system to define delivery dates and timing. The system does not use the transit duration in hours and minutes for transportation planning and scheduling. After defining the route,

397 proceed with defining the route stages and select the Double-column button.  Now select your departure point from the list of transport connection points previously defined. Then select your destination point, such as an airfield, which also originates from the connection points previously defined. Proceed with a new entry and continue with the assignments.  Now that the route has been defined, you can proceed with an optional step of maintaining the stages for the routes. This can be carried out for each individual leg, but once you have many routes in the system and you need to define some “global” changes, you can proceed to maintain stages for all routes  Route determination occurs in the SAP system based on the following items: 1. 2. 3. 4. 5.

The country and departure zone (taken from the shipping point) The shipping conditions in the sales order The transportation group of the material master record The country and receiving zone of the ship-to party The weight group (optional)

 Now define and assign the transportation zones. Proceed to the Define Transportation Zones Screen Path: SPROIMGSales and DistributionBasic FunctionsRoutesRoute DeterminationDefine Transportation Zones

398

For route determination, you divide a country up into transport zones. A customer exists in a transport zone and so does shipping point. SAP determines the route for moving from a shipping point in one zone to a customer in another zone (also taking into account other conditions like the weight, shipping conditions of the customer, and the loading group of the material). Here you assign all the zones that you require in route determination. Each zone has a description and an assignment to a country key. This country key is later used to determine what zones are relevant for which shipping points. Now select maintain Country and Transportation Zone for Shipping Point. In this assignment, you assign the departure zone to the shipping points you use. Note the shipping point is maintained for a plant and the plant resides in a country; you must also enter the country key of the shipping point here. This country key determines what departure zones you are allowed to select from, based on the previous settings

399

 After defining the transportation departure zones, you can now proceed with the definition of the transportation group. From the route overview screen, go to Influencing factors, Transportation groups. The transportation groups are assigned to the material master record sales/plant view. This transportation group is then copied into the delivery item.

400 Note: Because the transportation group is a prerequisite for the determination of the route, it is advisable to include it as a mandatory field for the material master record to ensure that during the maintenance of the material the field empty is never left empty.  Proceed to the Define weight groups menu from the route overview screen and then to Influencing factors, Weight groups. You can use the weight group to further refine the route determination in the delivery. For example, let’s say the customer shipping condition is “as soon as possible.” It makes sense to send the stock by air, but this might be too expensive if the weight is more than 50 kilograms. So, you can say for this shipping condition to the customer, if less than 50 kilograms, use the route that has a transportation type by air; if over 50 kilograms, use a road or sea route. The weight group can therefore be used to determine the route, taking into consideration the weight of the delivery. This is very important when sending stock by rail or truck.

 It is generally cheaper to send the stock by truck, rather than rail, if the quantity is small, but for very large quantities, it is usually cheaper to use rail. For the smaller quantities, determine a route that is defined for road shipments; for large quantities, determine a route that is defined for rail shipments. Weight groups should be defined with a short meaningful description,  Always use the weight group as defined in “up to . . .,” as this offers a greater ease of use later.

401 Maintaining Route Determination: Path: SPROIMGSales and DistributionBasic FunctionsRoutesDefining RoutesRoute DeterminationMaintain Route Determination

Go to New Entries and specify the following data: Country of Departure, Departure Zone, Destination Country and Receiving Zone. Select the above entered combination and go to “Route Determination without weight group”

Go to New Entries and assign the route to the combination of shipping conditions and

402 transportation group If this setting is done properly, then while creating sales order the system automatically determines a corresponding route for the items Again select the required combination of Country of Departure, Departure Zone, Destination Country and Receiving Zone and go to “Route Determination with weight group”

 Go to New Entries and assign the route to the combination of shipping conditions, Transportation group and Weight Group. Note: Unlike the sales order items where each item can have its own route, all the items in the delivery must have same route.

403

Billing Billing Process The billing is able to invoice the customer for materials or services rendered. Generally, this takes place after the delivery process has been completed, whether this is a delivery of a physical item or a service. The billing process could be order or delivery related and may include billing of standard deliveries as well as the creation of debit and credit memos. The billing process may even include invoicing for financial deposits for large projects prior to construction and inception of the project.

Defining Billing Document Types: The billing document is similar to the delivery document in that it has a header and item level, but no schedule line level, as in the sales documents. Thus one must configure the header document type and the relevant item categories. Path: SPROIMGSales and DistributionBillingBilling DocumentsDefine Billing TypesDefine Billing Types.

404 Functionality of Billing Type: 1. SD Document Category: It specifies what type of document the system is using. The SAP standard for invoices is M 2. Transaction Group: One must also assign a transaction group 7 for billing documents and 8 for pro forma invoices 3. Negative Posting: Specifies whether the negative posting is allowed for the billing type. 4. Branch/Head Office: The branch/head office is important as it determines which customer master record is used to update the accounting documents. Generally, if the Payer is different than the Sold-to-Party, the payer is transferred to Financial Accounting as the customer. 5. Credit Memo with Valid Data: This checkbox is used for credit memos, to set the baseline date as the date from original billing document. 6. Posting Block: If we check this field, the automatic transfer of billing document to accounting will be blocked. Note: We can manually release the document to accounting in the following way: Use transaction code VF02, specify the billing document number and from main menu select Billing DocumentRelease to Accounting. 7. Invoice List Type: The invoice list type represents the document type that can be used to create invoice lists for this Billing Document. 8. Relevant for Rebate: Specifies whether the billing type is relevant for rebate processing 9. Cancellation Billing Type: Specifies the corresponding cancellation type of the billing type. The SAP standard invoice cancellation type for F2 billing documents is S1 as well as SV for a Cash Sale. 10. Account Determination Procedure: The account determination procedure is used by the system to propose which general ledger accounts entries must be posted. 11. Document Pricing Procedure: The document pricing procedure indicator is used to determine pricing in conjunction with the sales area and the customer pricing procedure indicator 12. Account Determination Reconciliation Account: This field is used to determine the reconciliation account to be used. This value is then used as opposed to the reconciliation account on the company code 13. Account Determination Cash Settlement: This field is used to determine if the value should be posted to a different account, as opposed to the standard increase in accounts receivable. In a cash sale there would be no need to increase the customer’s open items. However, you may wish to post the value somewhere. 14. Account Determination Payment Cards: This field is used to determine which general ledger accounts must be posted to for payment cards. 15. Header Partners: Specifies the partner determination procedure for billing document header 16. Item Partners: Specifies the partner determination procedure for billing document procedure

405 Following are the standard billing types used: Billing Type F1 F2 F5 F8 G2 L2 RE S1 S2 IV

Billing Type Name Order-related Invoice Delivery-related Invoice Pro forma invoice for sales orders Pro forma invoice for deliveries Credit Memo Debit Memo Credit for Returns Cancellation Invoice Cancellation Credit Memo Inter-Company Billing

Special Billing Document Types It is not possible to list all business scenarios, processes, and billing document types. However, there are a few that are very common that need to be mentioned, as they will not be discussed individually.

Pro Forma Invoice  The pro forma invoice uses billing type F8. It is an invoice that does not post any financial amounts into any general ledger. It is used in information purposes only. An example of using a pro forma invoice would be to accompany the shipment of products across a border post. The invoice would be used to represent the actual value of the articles. The actual invoice can be sent to the customer via post. Another example of using a pro forma invoice would be when a customer needs to be sent an invoice representing the value she must claim from a superior authority before the business sends her the actual payable invoice.

Cancellation Invoice  The standard cancellation invoice for a F2 invoice is the billing type S1. The cancellation invoice is used when one discovers that a billing document has errors on it and needs to be cancelled and recreated.

406 Note that it is illegal in a number of countries to permit this capability in a system, so be careful copying the standard billing document type F2, as you may wish to exclude this functionality Creating Invoice: Path: SAP Easy AccessLogisticsSales and DistributionBillingBilling DocumentVF01Create

For the field “Document”, specify the reference document number and select the icon execute. The entire document will be carried from the reference document to billing document and save it. Note: 1. The reference document for creating the billing document is controlled by item category with the field “Billing Relevance” 2. While creating the billing document, it is not required to specify the billing type. Because, it will be automatically determined from the definition of reference sales document type.

407 Note: 1. When we save the invoice, the sales value will be automatically posted to corresponding G/L account, where the company’s revenue is created and the customer account is debited. 2. When we save the invoice, the system automatically generates an “Accounting Document” which is posted to finance. The accounting document type is “RV” 3. To see the accounting document generated by the system, select the button “Accounting” from the initial or overview screen of the billing document 4. The system generates the following documents: a. b. c. d. e.

Accounting Document Profit Centre Document Specific Purpose Ledger Controlling Document Profitability Analysis

Fields in the Accounting Document: 1. Item: Specifies the number of records (accounts) in the accounting document. The first record is always for ‘Payer Account’ 2. Posting Key: The posting key specifies whether the account is created or debited. 01 is the posting key for debiting the payer account 50 is the posting key for crediting the company’s revenue account 40 is the posting key to debit the company’s deduction amount 3. Account: Specifies the account to which the entries are posted 4. Description: Specifies the description of G/L account 5. Amount: Specifies the amount that is posted to the corresponding account 6. Tax Code: Specifies the tax code of the country Note: For the system to generate the accounting document we have to configure Revenue Account Determination Procedure and we also need to specify the “Reconciliation Account” in the customer master record of payer. In the “Accounting Document”, the system displays the reconciliation account number in the details of payer record.

408 Invoice Cancellation: Path: SAP Easy AccessLogisticsSales and DistributionBillingBilling DocumentVF11Cancel For the field “Document”, specify the Invoice number and select the icon execute. Go to the details of Invoice Cancellation and save it. Note: When we save the Invoice Cancellation, those sales values that are already posted to the corresponding G/L accounts during invoice creation will be reverted When we save the invoice cancellation, the system automatically generates an accounting document which is posted to finance. The accounting document type is “AB” The posting key for payer is ‘12’ and for company’s revenues account it is ‘40’

Copy Control for Billing Documents  The copy control for billing documents is split into three overall copy control rules. They define copy rules for header and item levels between sales documents: 

Sales document to Billing Document: This is used for credit memos and debit memos that have no delivery document.



Delivery note to Billing Document: This is the most widely used copying rule and covers the standard sales process.



Billing Document to Billing Document: This is used by the system to determine copying control between an invoice and an intercompany invoice, for example

Billing Document Copy Control Rules: Delivery Document to Billing Document Path: SPROIMGSales and DistributionBillingBilling Documentsmaintain Copy Control for Billing DocumentsCopying Control Delivery Document to Billing Document.  As the copy control definition and maintenance is equal for all three types, we will only use the delivery note to the billing document as an example. Using this, we can fabricate an example whereby we have created five sales orders for the customer. Of these five sales orders, we have created two deliveries due to the fact that the shipping point on one of the sales orders was different. Now we have the scenario whereby two deliveries of delivery type LF are to be billed

409  Looking at the copy control rules from delivery type LF to billing document type F2, as shown in Figure below, we can select the relevant item category levels

Select the document types, then click the Details button (the small magnify glass) in the taskbar. You will see a screen similar to below Figure.

The target and the source document types are self explanatory. The copying requirements assign a number, which in turn is the key to a routine. The routine may be found in transaction code [VOFM] (Path: Copying RequirementsBilling Document). We’ll discuss more about VOFM later. The routine 003, which actually includes LV60A003, is used to check the specific

410 blocks and statuses to determine if the billing document may be created. The blocks and statuses it checks are as follows: 

Billing Block



Billing Status



Goods Movement Status



Incompletion Status for Billing Header



Overall Incompletion Status for Billing Document



POD (Proof of Delivery) Status

The determine export data field is used to re-determine the export control (foreign trade data) automatically in the billing document. The reference number is passes to accounting. The allocation number is similar to the reference number. Both of these numbers may have details assigned to them on the billing document type. For self-billing, the value of this field may be equal to “C”, meaning the delivery number is used as a reference. However, this also means that the delivery number will be passed to accounting as the reference field. The system therefore cannot combine deliveries like in a collective invoice as it does not know what number to use as a reference. The assignment number on table VBRK (VBRK-ZUONR) is actually the allocation number in the copy control at header level. If you set this field to check, for example, your sales document or delivery document, you will not be able to collectively bill document as the value of this VBRK field will be different. Billing Document Copy Control Item Select the Item folder in the file structure on the left. You will then see a screen similar to below figure.

411

Select the item category “TAN”, as shown in above figure, then click the details button and you’ll see a screen similar to below Figure.

412 Using the example of TAN, as seen in above figure, we have a similar view to the copy control rules as seen in the sales documents. The billing quantity is used to determine the quantity of items to be invoiced --- For example, setting B provides the invoice with the delivery quantity less the already-invoiced quantity  The pricing type used determines what type of pricing the system is to automatically use. The requirement field is used as a standard; that is, all elements requested by the requirement must be fulfilled in order for the billing document to be created The pricing exchange rate type is self-explanatory. The cumulate cost check box is used to cumulate sub-item costs into the main item cost amount. This is used, for example, if you have a delivery with an item that is free of charge and not relevant for billing, but is a sub-item of a main item. The price source field is used to determine where the pricing conditions are sourced. Generally, the field should be left blank, resulting in the copy being determined from the sales document. The copying requirements field is used as in the sales and delivery process i.e. all elements requested by the requirement must be fulfilled in order for the billing document to be created.  The data that is important to an invoice splitting or invoice combination is the entry in the field data VBRK/VBRP. Table VBRK is the billing header and table VBRP is the billing item. The key entered here is used by the system to defining splitting rules. For our example, the two deliveries created from five sales orders can be split into individual billing documents, each one representing a sales order, or the deliveries can be combined to form one billing document.

Invoice Lists  At specific time intervals or dates, invoice lists can be created. Invoice lists are merely a list of billing documents that is either individual and/or collective and these documents are combined into one document for a particular customer. Path: SPROIMGSales and DistributionBillingBilling DocumentsInvoice Lists.  Two types of invoice lists are available in the SAP standard system: 

For invoices and debit memos: LR



For credit memos: LG

413  An invoice list has header and item data. One cannot change the details of the invoices once they are in the invoice list. For invoice lists to be used, the following prerequisites must be maintained: 

Condition type RL00 [factoring discount] and the tax condition MW15, if required, must be maintained and placed in the pricing procedure



An invoice list type must be assigned to each billing type that you want to use to process invoice lists. The two invoice lists that can be used are LR and LG. Should you need an additional billing document type for invoice lists, copy the original and rename it beginning with a Z.



Proceed to assign the invoice list type for each billing type. Here you assign the invoice list type to be used by the associated billing document types, as shown in below Figure.



Copying requirements must be maintained between the billing document and the invoice list document. The system does not carry out copying at the item level for billing documents. The standard copying requirement used in invoice lists is 016



A customer calendar must be defined specifying dates on which invoice lists are to be processed, such as once every two weeks. This is assigned to the customer’s billing view in the customer master record



Output the condition records for condition types LR00 and RD01

414  To create an invoice list, Use the following path Path: SAP Easy AccessLogistics Sales and DistributionBillingInvoice List[VF21]Create. Proceed with entering each billing document separately. From within the billing document, select HeaderPricing. One is able to see the factoring discount as well as the factoring discount tax assigned to this invoice list.

Billing Plans  The SAP system uses two billing plans. The first, milestone billing, is a final billing in full at a particular milestone, according to items sold or services rendered. An example of this would be a project milestone, such as when an architect’s blueprint is finished, for which the service is invoiced. The alternative billing plan is periodic billing, which uses a predefined date proposal that bills the customer at periodic intervals. An example of this would be billing for rental of an object

Defining Billing Plan Types Path: SPROIMGSales and DistributionBillingBilling PlanDefine Billing Plan Types  The difference between milestone billing and periodic billing can be described as follows. Milestone billing bills an amount distributed between dates until the total value is billed. Periodic billing bills a total amount for each date until a predefined end date is reached.

Define Periodic Billing Plan Select Maintain Billing Plan Types for Periodic Billing. In this view seen in below figure, you assign values to a periodic billing plan type. To create your own, simply copy the standard and name your copy ID with a prefix of Z. Note all date setting you use is not actual dates, but rather date rules. Therefore the start date is a date rule representing the contract start date. In the origin of General Data section, you assign a start date rule, which may be the start date of the rental contract, as well as an end date rule, which may be the contract’s end date. The horizon is set as one year. Note that the horizon is not the end date of the billing plan; it is

415 instead the last day that billing plan will use to bill. The dates from and dates to rules are used to further restrict the start and end dates of the billing plan dates. The period of the billing date determines the frequency with which the billing dates are created in the billing plan and, in addition, whether a billing date is processed for billing on the first or the last day of the month. In the billing date: date proposal section, you define the next billing date for periodic billing. Figure below refers to “Monthly on First of Month.” You may assign a deviation billing date, which is a rule that may be set to determine if the customer is billed, for example, two days prior to the billing date as determined by the system.  In the control data, one can set the deadlines to be created automatically in the sales order as well as define that the system should bill in advance by indicating this in the In advance field. Should this indicator not be set, the system will automatically bill in arrears. The automatic correction dates field is used to automatically create a credit memo should the end date of the billing plan move closer to the start date, and for which a billing date has already been or is about to be executed. One is then able to define which screen the system uses to display as its overview screen for a billing plan by setting the default FCODE.

416 Defining Milestone Billing Plan Select Maintain Billing Plan Types for Milestone Billing.  This screen, as shown in Periodic Billing Plan, is similar to Milestone Billing Plan screen, the one for periodic billing; however, due to there being less data relevant for periodic billing, the only settings required here are the start date, usually set as today’s date, the date category, the on-line order indicator, which determines if the system automatically creates the billing deadlines, and the overview screen. The Value “01” in date category refers to “Milestone Billing” to determine the date proposals. The online order indicator determines if the system automatically creates the billing deadlines. Again, one is then able to define which screen the system displays as its overview screen by setting the default FCODE for overview screen of billing plan.

417 Defining Date Descriptions Select Define Date Descriptions.

These date descriptions are merely used for informational purposes. Create a four-character alphanumeric key with a meaningful description.

Defining and Assigning Date Categories Select Define and Assign Date CategoriesMaintain Date Category for Billing Plan Type.

418 In this screen as shown in above figure, assign a created date category with description to the billing plan type. In create mode you may assign a date description as previously defined, and then assign the billing rules to the date category, as seen in below figure.

A value billing rule is used by the system in taking the full billing amount, such as $10,000, and dividing it up into partial amounts, such as $3,000, $2,000, $4,000, and $1,000. The milestone billing based as a percentage would determine percentages of the total billing amount to be billed such as 30 percent, 20 percent, 40 percent, and 10 percent. The fixed date field is used to inherit the dates from the settings of the billing plan PS (Project Systems). If however, you wish to use a fixed date that does not fluctuate with the project milestones, and then use a value of “0” here. The billing block is used to set a billing block against all dates. This block is then removed automatically when PS confirms that a milestone has been reached. The billing type is the proposed billing type to be used for order related billing relevant to this billing plan.

Maintain Date Proposals for Billing Plan Types  Milestone billing has an allocation for date proposals. These milestones are defined in the settings for maintaining date proposals for billing plan types. As seen previously in milestone

419 billing, the milestone billing plan has a reference billing plan type. In this view, one can maintain the dates defined in the milestone billing plan type. Periodic billing does not have a need to define milestone dates, as it determines it’s billing date by following a repetitive procedure until finally reaching a termination date. By selecting Maintain dates, you will be faced with a screen in which you can enter the relevant dates and assignments in percentages or in a total value

Assigning Billing Plan Types to Sales Document Types and Item Categories Select Assign Billing Plan Types to Sales Document Types.

420

This section again is self-explanatory; one merely assigns the relevant billing plan type, be it milestone or periodic billing to the necessary sales document types.  After assignment of the billing plan type to the sales document, proceed to assign the billing plan types to item categories.

 As billing is carried out per item category, one assigns the billing to the sales document item. For example, the standard item category TAN would in most systems uses A, which is relevant for delivery-related billing. The SAP standard has item categories MVN, which is used for periodic billing, and item category TAO, which is created for milestone billing. Each item

421 category that is relevant for either of the billing plan types must be assigned a billing relevance I, which is relevant for an order-related billing plan. Assigned to the billing relevance would be the billing plan type, such as milestone or periodic billing.  One can define the rules used in the system to define the dates in the billing plans. To define these dates, proceed to define the rules for determining dates.

Rebate Agreements  A rebate agreement is an agreement between the business and a customer. This agreement takes the form of a special discount paid retroactively to the customer. This discount is based on the sales volume for the customer over a specific time period. The rebate is only relevant if the customer purchases the required sales volume. The rebate agreement has separate condition records for each product the customer buys. These condition types specify the rebate amount or percentage due to the customer for each product. One is able to specify a pricing scale so that the customer can earn a better rebate by ordering more products. Because rebates are always paid retroactively, the system keeps track of all billing documents that are relevant for rebate processing. This includes standard invoices, as well as credit and debit memos related to rebate. The system may also post accruals automatically so that the accumulated vale of a rebate is recorded for accounting purposes. A rebate agreement is finally settled when a credit memo is issued to the customer for the accumulated rebate total.

Configuring Rebates: Pre-Requisites: 1. In the definition of Sales Organization, we have to check the field “Rebate Process Active” 2. In the Customer Master Record of Payer, we have to check the field “Rebate” 3. In the definition of corresponding billing type, we have to check the field “Relevant for Rebate.”

Maintaining Condition Technique for Rebates:

422 Path: SPROIMGSales and DistributionBillingRebate ProcessingCondition Technique for Rebate Processing. 1. Maintain Condition Tables for rebate: This is similar to maintaining condition table for pricing’ 2. Maintain Access Sequence: This is similar to maintaining Access Sequence for Pricing 3. Define Condition Types: This is similar to Defining Condition Types for Pricing except few fields which are described below.

For rebate condition types; the condition class is “C” (Expense Reimbursement) The plus/minus field contains value “X” (Negative) For BO01 and BO03, the calculation type is percentage and for BO02, it is quantity. For rebate condition types we don’t have the fields like “Amount or Percent”, “Value” etc., which we have for regular condition types.

423  The field “Rebate Process” specifies whether the accruals will be posted on each applicable invoice. Leaving this field blank, will make the system to calculate accruals on the sales volume and specifying the value “A” (independent of sales volume) will prevent the automatic generation of accruals on the invoices. It makes sense to specify the value “A”, if we don’t base the rebate payment on the actual sales, but on the specific performance of the customer such as “Display Schemes” The field “Provision Correction” specifies whether we want to reverse the accruals at the time of partial payment. Leaving this field blank will reverse the accruals and the value “A” will prevent it. 4. Maintain Pricing Procedures: This is very much similar to maintaining pricing procedures for pricing with few exceptions mentioned below.

We need to place the rebate condition types in the main pricing procedure only. In the Pricing procedure, just above to net value of the item, we have to specify the subtotal “Rebate Basis” by specifying the value “7” (Carry over the value to KOMP-BONBA). Below to that we have to place the rebate condition types by specifying the step number of “Rebate Basis” in the field “from”. For the rebate condition types, we have to specify the requirement “24” which enables the

424 system to determine the rebate condition types in the billing document only. For the rebate condition types, we have to assign the account key as well as the accrual key. The posting of rebate accruals is done by those accounts assigned to the accrual key “ERU”. The settlement document (Credit Memo) uses those accounts assigned to the account key “ERB”, which will reverse the accrued amounts and credits the customer.

Defining Rebate Agreement Types Path: SPROIMGSales and DistributionBillingRebate ProcessingRebate AgreementsDefine Agreement Types.

Functionality of Rebate Agreement Types 1. Propose Valid from and Valid to: Specifies the default start and end date of rebate agreement. The default start date is very much important in regards to whether or not we want to allow the “Retro Active Rebates” i.e. if the default start date is the beginning of the current year, the system will calculate that rebate for all those invoice’s created from the first day of the year even the rebate agreement is created on the current date.

425 2. Payment: Specifies the default method of paying the rebate amount to the customer 3. Default Status: Specifies the default status of the rebate agreement 4. Condition Type Group: Specifies the allowed rebate condition types for the rebate agreement type. 5. Verification Levels: Specifies the default level of detail we see when we review the applied invoices within a rebate agreement 6. Different Validity Period: If we check this field, the validity period of rebate condition record can differ from the validity period of rebate agreement. 7. Payment Procedure: Specifies how much rebate amount can be paid out to the customer during partial settlements 8. Partial Settlement: Specifies the document type “R3” for creating the document “Partial Rebate Settlement Request” while making the rebate payment to the customer 9. Reverse Accruals: If we check this field, the accruals will be reversed in the rebate agreement when the rebate amount is paid to the customer 10. Final Settlement: Specifies the document type “B1” for creating rebate credit memo request while making final settlement to the customer

Condition Type Groups: It specifies the number of rebate condition Types that are to be used for the rebate agreements. To define Condition Type Groups, use the following path: Path: SPROIMGSales and DistributionBillingRebate ProcessingRebate AgreementsCondition Type GroupsDefine Condition Type Groups.

426

 In this activity, you define the condition type group that is to be assigned to the rebate agreement. Should you need to create your own condition type group, you can copy and change the name, but remember to use the prefix Z.

Assigning Condition Type/Table to Condition Type Groups: Path: SPROIMGSales and DistributionBillingRebate ProcessingRebate AgreementsCondition Type GroupsAssigning Condition Type/Table to Condition Type Groups.

427

 In this activity, one assigns the condition type from the pricing procedure to the condition type group found on the rebate agreement type. The sequence number (Cntr column represent the fields in the condition table that determine what the system is to use as the basis for the rebate. In this example, 1 determines that the condition type should use the field’s customer and material. The No. Column is actually equal to the pricing condition table number. The condition type group 0003 will use pricing condition type B003.

Assigning Condition Type Groups to Rebate Agreement Types: Path: SPROIMGSales and DistributionBillingRebate ProcessingRebate AgreementsCondition Type Groups Assigning Condition Type Groups to Rebate Agreement Types

428

 Here you are presented with a list of agreement types as created in the system and you can assign the relevant condition type group. If you recall, our example agreement type 0003 uses condition type group 0003.

Creating Rebate Agreement: Path: SAP Easy AccessLogisticsSales and DistributionMaster DataAgreementsRebate AgreementCreate-VBO1

429 Specify the required agreement type and press enter. Specify the sales area and press enter

In the overview screen, specify the rebate recipient and currency. Select the button “Conditions” and maintain the condition record for the required rebate condition type.

430

Note: If it is customer rebate we have to maintain the condition record for the payer. Select the record and go to details where we have to specify the “Material for Settlement” Whatever the material we have entered here, by using that, the system automatically created the document “Partial Rebate Settlement Request” while making the rebate payment to the customer.

Managing Rebate Agreements and Payments: Create few invoices in order to calculate rebates. After creating the invoices, the system will automatically calculate the rebate accruals and updates them in the rebate agreement. To see this, go to the overview screen of rebate agreement by using transaction code VBO2 From the overview screen, go to the condition record by using the button “Conditions” To see all the billing documents, based on which the system has calculated the rebate accruals, select the icon “Verification Level” in the overview screen of rebate agreement

431 Making the Rebate Payment to the Customer: Note: We cannot create a final settlement until all the open settlement requests are posted to accounting. The reason for this is the actual payments are updated in the rebate agreement only at the accounting time to determine the amount that is left to pay to the customer. Creating Partial Settlements: In the rebate agreement overview screen, select the button “Pay” (Create Manual Rebate Payment) Specify the required amount for the field “Amount to be paid” and save the agreement. The moment we save the rebate agreement, the system automatically creates the document “Partial Rebate Settlement Request” Note: For this system to automatically create this document, we have to specify the document type “RS” in the definition of corresponding agreement type for the field “Partial Settlement” Go to Overview screen of the document “Partial Rebate Settlement Request” by using the transaction code VA02 where the system displays that material which is entered as “Material for settlement” in the rebate agreement Go to item data of that material and select the conditions tab page where the system displays the rebate condition type for twice. One is to actually reverse the accruals and the other is to credit the customer with the specified amount. Remove the billing block if any and save the document. Note: The document type “R3” is same as CR except the corresponding billing type which is “B3” (Rebate Partial Settlement”. The item category is “B1N”. B1N is same as G2N except the field returns which must not be checked for B1N.

Retroactive Rebate Processing  One can create a rebate agreement with a validity period that has already started. Note that when maintaining a retroactive agreement that the system does not post accruals for billing documents created in the past.  Proceed to Compare rebate basis and correct accruals in the IMG. With the report RV15B002, one can check a rebate agreement with regards to the amount due for rebate to the accrual amount posted. These values may differ if one implement rebate processing retrospectively and wants to take into account old billing documents. One can then post a

432 rebate correction request to correct the accruals.  Should one reset rebate processing or alter the pricing procedures, because the subtotals used to calculate the rebate in the billing documents may not be available. If this is the case, you can proceed to recalculate subtotals for rebate processing. This is merely a program RV15B003 that is executed with the selection criteria as the desired billing document number range.  Following this execution of the program, one will need to restructure the billing rebate index. The rebate index is used to settle retroactive rebate agreements. Should you change one of the following determining factors, you will need to restructure the index:    

New rebate relevance of sales organizations New rebate relevance of billing types New rebate relevance of payers Creation or inclusion of new accesses for rebate processing

 To recreate the rebate index, proceed to Create billing index. Enter the parameters for the desired update, that is, the billing document number range as well as the scheduled run dates. Note that this updates the index of table VBOX, SD Document: Billing Document: Rebate Index. The system uses this index that is updated once the billing document is released to accounting in order to determine all the documents that may be relevant for rebates. The document doesn’t need to have a rebate condition at the time of the update.  One can also recreate the setup of statistical data. This is useful if there is an error in the statistical indicator assignments to the customer or material and/or the sales area. Standard SAP uses the information structure S060 for rebates. Proceed to the Setup of statistical data

Payment Terms Payment terms are the terms of payment the company offers the customer. Based upon the payment term a discount may be given for prompt payment. If the customer does not pay, it is possible to institute dunning, whereby the customer is “dunned,” that is, sent letters in a level of severity in accordance with the time period that he has not responded or paid. Although this topic belongs to finance module, you will deal with payments terms a lot and need to know where to access the data within them.

Configuring Payment Terms Path: SPROIMGFinancial AccountingAccounts Receivable and Account PayableBusiness TransactionsIncoming Invoices/Credit MemosMaintain Terms of Payment [OBB8]

433

If you select an item, then click the details button, you will see a screen similar to below one

434 It is possible to have an installment payment with a payment term too. Use the following menu path to get the screen below Path: SPROIMGFinancial AccountingAccounts Receivable and Account PayableBusiness TransactionsIncoming Invoices/Credit MemosDefine Terms of Payments for Installment Payments [OBB9]

Don’t forget that the cash discount base for determining the payment term base should be set. This depends on your company and setting is made in the Define Cash Discount Base for Invoices screen in the IMG.

Inter-Company Sales The Inter-Company Sales describes the business process between two company codes that belong to same company (client). In this process, the Sales Organization belongs to ordering Company Code and the Plant belongs to delivering Company Code. The Sales Organization of ordering company code processes the sales order and bills the customer whereas the plant of delivering company code delivers good to the customer and bills the ordering company code which is Intercompany Billing Document.

435  An intercompany sale may be described with the following example. The customer orders stock from the sales organization (for example 3001). The sales organization (3001) belongs to a company code, for example, 3000. The sales organization (3001) then creates the sales order and indicates the delivering plant as a plant that belongs to a different company code, for example, company code 1000. The sales organization (3001) then invoices the customer for materials purchased. The system automatically creates an Inter-Company billing document at the same time as the customer’s billing document is created. This Inter-Company invoice is sent from the delivering plant to the selling sales organization. This is defined as an Inter-Company sales transaction. The result of an Inter-Company sales transaction is that the system will create two billing documents. The first is the standard customer billing document that is sent from the sales organization to the customer who receives the goods. The second is the Inter-Company billing document that is sent from the delivering plant to the sales organization.

Inter-Company Stock Transfer  When dealing with different company codes, one may find a need to transfer stock between company codes. Should the stock be transferred within the same company code, there is no need for an intercompany transaction; however, should the stock be transferred between different company codes, transference of value occurs and is an intercompany sale  In Figure Below, company code 3000, which has plant 3000, creates a purchase order to purchase stock from plant 1000 based in company code 1000. The stock is then delivered to plant 3000. Company code 1000 creates an intercompany invoice and bills company code 3000 for the stock. This process is defined as an intercompany stock transfer

Defining Order Types for Inter-Company Sales Transaction Path: SPROIMGSales and DistributionBillingInter-Company BillingDefine Order Types for Inter-Company Billing

436 In order for an inter-company sales transaction to be carried out, you need to define which sales document types may be used in conjunction with inter-company sales. The SAP standard for inter-company sales billing document type is IV. Thus, should inter-company sales be permitted for sales document type OR, we need to assign the inter-company billing document type IV to OR. For IV the document category is “5” (Inter Company Invoice) and the corresponding cancellation type is “IG” We need to specify the document type “IV” in the definition of “OR” for the field intercompany billing type.

Assigning Organizational Units by Plant Path: SPROIMGSales and DistributionBillingInter-Company Billing Assigning Organizational Units by Plant

437

 In this process of assigning organizational units by plant, one assigns a sales area to the delivering plant.

Defining the Internal Customer Number by Sales Organization  In this step, one defines the internal customer number that represents the sales organization to be invoiced in intercompany sales processing, as seen in below figure. This customer number must be created in the system for the sales area specified

 For intercompany sales processing to be functional, some master data maintenance must be done. A checklist for intercompany sales processing can be the following:

438 

The enterprise structure must be maintained correctly; that is, the plants must be assigned to the correct company codes as well as to the correct combination of sales organizations and distribution channels



The intercompany customer numbers must be assigned to the relevant sales organizations



The delivering plant must be assigned to the sales organization



The material to be sold must exist in the original and delivering plant



The sales order must be relevant for intercompany sales and have an assigned billing document type



The copy control rules must be defined between the standard invoice, such as F2, and the intercompany invoice, such as IV.



For maintaining inter-company price, we have to use the condition types PI01/PI02

Note: For this condition types, the condition class is prices and condition category is “I” The calculation type is quantity for PI01 and it is percentage for PI02 We need to place these condition types in the pricing procedure below to net value with requirement “22” While maintaining condition records for these condition types, we must specify the sales organization of ordering company code and plant of delivering company code

Processing an Intercompany Sale  To create an intercompany sales transaction, proceed with creating the standard sales order. In the sales order, change the delivering plant at the line item level and create a delivery for the new shipping point represented for the delivering plant. Precede with the delivery functions of selecting the packing and posting the goods issue. Then create an external invoice that will be sent to the customer and create an intercompany invoice that will represent the billing document between the delivering plant and the selling sales organization.  An internal intercompany invoice can be created by entering the delivery number again for processing when using transaction [VF01]. One can also select the documents due for intercompany billing by using the billing due list [VF04]. When using the billing due list, be sure to select the intercompany billing documents as the documents to be used

439

Determinations Tax Determination  The SAP R3 system automatically determines and calculates taxes based on the organizational structure, country, region, or city of delivering plants and country or receiving customer in combination with tax relevancy indicators on the customer and material master records  The workload related to tax determination rules differs from country to country. Some countries have a simple, single VAT (value added tax) charge per sale; other countries have a tiered system of taxes (state, city, and other taxes); and still other countries like Brazil have a specific system enhancement to cater for their countries taxes. Prior to maintaining the tax section, you need to ensure your plants and country or geographical areas such as regions and cities are maintained. When determining taxes, you should always maintain the data relevant to taxes in consultation with the FI (Financial) module. The business requirements should also be strictly administered by an experienced accountant who represents and knows the business procedures. You should carefully consider the tax implications in the business blueprint of a project prior to creating an organizational model. It is only necessary to maintain the tax relevant data for foreign countries with which you do business

Defining Tax Determination Rules The system automatically determines the relevant taxes according to the country of the delivering plant, plus the country of the customer receiving the goods, in combination with the tax indicator of the customer master record and the tax indicator of the material master record. To define tax determination rules, use the following menu path. Path: SPROSAP Customizing Implementation GuideSales and DistributionBasic FunctionsTaxes Define Tax Determination Rules

440

As shown in Figure Above, you must assign the relevant tax condition types to the country key. The system will only list condition types that are regarded as “taxes” in the condition class of the condition type. While assigning the tax condition type or “tax category” to the country key, you need to specify if more than one tax is required and in which order the system is to access the condition records. This is done by assigning the relevant tax condition types to the relevant country keys and by assigning an access sequence number—for example, Canada has a GST ax and a PST tax. After you have assigned the tax condition types or categories, you must ensure the condition types are placed into the relevant pricing procedures and that the associated tax condition records are created/maintained.

Defining Regional Codes As some countries may have county and or regionalized taxes, it is possible to state specific regions within a country code. To define regional codes, use the following menu path Path: SPROSAP Customizing Implementation Sales and DistributionBasic FunctionsTaxesDefine Regional CodesDefine County Code

441

It is also possible to define city codes in the SAP Customizing Implementation Guide by using the following menu path. Path: SPROSAP Customizing Implementation Sales and DistributionBasic FunctionsTaxesDefine Regional CodesDefine City Code

442 Currently, the USA requires a tax based on the city level. It is possible to subdivide a country code further, into a region and then into a city

Assigning Delivering Plants for Tax Determination As the delivering plant must be assigned to a country, region, and or city code for tax purposes, you need to make this assignment using the following menu path. Path: SPROSAP Customizing Implementation Sales and DistributionBasic FunctionsTaxesAssign Delivering Plants for Tax Determination

As shown in Figure, Plant DBLG is assigned to India. After assigning the delivering plant, you need to create the indicators that are represented on the customer and material master records. This is covered in the following sections.

Defining Tax Relevancy of Master Records-Customer Taxes It is important to specify if the customer is liable for taxes or not. You can assign a relevancy indicator to the tax condition type or “tax category” using the following menu path.

443 Path: SPROSAP Customizing Implementation Sales and DistributionBasic FunctionsTaxesDefine Tax Relevancy of Master RecordsCustomer Taxes

For example, in Figure above, there are two indicators assigned to the MWST. Either of these two may be assigned to a customer master record. The system then uses this indicator as found on the Billing view of the customer master record Now you can proceed to create the material tax indicators

Defining Tax Relevancy of Master Records-Material Taxes To define tax relevancy of master records, use the following menu path. Path: SPROSAP Customizing Implementation Sales and DistributionBasic FunctionsTaxesDefine Tax Relevancy of Master RecordsMaterial Taxes

444

Here you can assign a tax relevancy indicator to the tax condition type or “tax category,” which will later be assigned to the material master record. This is seen in Figure 8-39.This indicator is then assigned to the material master record on the sales organization 1view

VAT Registration Number in Sales and Billing Documents This section is important as the tax classifications assigned to the partners may be taken from a different customer master record than that of the Sold-to Party. The same rule that defines how the system is to determine the tax classification number also defines how the system is to reproduce the tax or VAT registration number from the customer master record into the sales documents. To do this, use the following menu path. Path: SPROSAP Customizing Implementation Sales and DistributionBasic FunctionsTaxesMaintain Sales Tax Identification Number Determination There are four available options to be assigned per sales organization. In order to keep consistency throughout the system, it is recommended to keep the determining rules the same across all sales organizations. • Determination rule A means the tax number and tax indicator classification is generally taken from the Sold-to Party customer master record.

445 • •

•

Determination rule B indicates the tax number and tax classification is generally taken from the customer master record of the payer. Should the field be left blank (priority rule), the system determines the tax number and the tax classification according to the following sequence: 1. If the payer has a VAT registration number and is identical to the sold-to party, tax number and tax classification are copied from the payer (in this case, the Ship-to Party is not relevant). The tax number is copied according to the “country of destination relevant for taxes.” 2. If the previous step does not apply: If the Ship-to Party has a VAT registration number and the Sold-to Party does not, tax number, and tax classification are copied from the Ship-to Party. 3. If the second step does not apply: Tax number and tax classification are copied from the Sold-to Party. Determination rule C is the same as the priority rule. However, the destination country is taken from the Ship-to Party.

Generally, the VAT registration number on the customer master record will be11 characters long and begin with a prefix equal to that of the ISO code for the country—for example, the VAT registration number for Germany is DE123456789.

Tax Condition Records Do not forget to create the condition records for the tax condition type. These may be created by using the following menu path from the logistics. Path: SAP Easy AccessLogisticsSales and DistributionMaster Data ConditionsSelect Using Condition Type [VK11] – Create

446 Enter the tax condition type you are using, such as MWST. Being a condition type, this has an access sequence and condition tables. Therefore, when you press ENTER, you will see a dialog box asking for which key combination you wish to create the condition record. Select the departure country/destination country combination. For example, in above figure we have created a condition record for Great Britain shipping to Ireland using standard VAT at17.5 percent. Take note of the tax code A1.

Tax Integration with Financial Accounting There are numerous tax settings to be maintained in the FI (Finance) module in mySAP ERP. These settings are related to outbound and inbound taxes, and are split into three sections within the IMG: • Basic Settings • Calculation • Posting To reach the first section, use the following menu path. Path: SPROSAP Customizing Implementation GuideFinancial AccountingFinancial Accounting Global SettingsTax on Sales/PurchasesBasic Settings

447 This section is used to create and assign a tax calculation procedure to a country. For example a basic tax procedure would be South Africa, as seen in Figure Above. You can see that this determination procedure uses the condition technique. It also uses the account keys to make a posting. To reach the next section, use the following menu path Path: SPROSAP Customizing Implementation GuideFinancial AccountingFinancial Accounting Global SettingsTax on Sales/PurchasesCalculation When we created the tax condition record, we assigned a tax code assigned to it. This tax code is controlled in this section within FI. In Figure below we can see that the tax code A1 in tax procedure TAXGB has a value of17.5 percent assigned to it. This must be the same value that you use to create your condition record. To reach the next section, use the following menu path. Path: SPROSAP Customizing Implementation GuideFinancial AccountingFinancial Accounting Global SettingsTax on Sales/PurchasesPosting This section is used to define the GL account assigned to the tax transactions. This has only served to be an introduction to the tax definitions within FI. The complexity and variables you may encounter when implementing tax determination will vary between countries. However, the knowledge you have in the condition technique and the pricing procedure, as well as these simple introductions, should be enough to help you on your way.

448

Revenue Account Determination When we save the Billing document, the sales values will be posted to the corresponding G/L accounts. For this we have to configure Revenue Account Determination Procedure. Let us first configure the Condition Technique for Revenue Account Determination Procedure. Path: SPROIMGSales and DistributionBasic FunctionsAccount Assignment/CostingRevenue Account Determination 1. Define Dependencies for Revenue Account Determination:

449 No need to create a table. Just use the default table 001.

2. Define Access Sequence and Account Determination Types:

Select the first option “Maintain Access Sequences for Account Determination”. Create an Access Sequence and place the required Condition Tables in it.

450

Select the second option “Define Account Determination Types”. We need to create two Condition Types. One is for “With Controlling” and other is for “Without Controlling” and assigns the corresponding Access Sequence.

451 3. Define and Assign Account Determination Procedure:

Choose the first option “Define Account Determination Procedure”. Define a procedure and place the two Condition types in it. While placing the two Condition Types in the procedure we need to specify the same Step No. with different counter. While placing the Condition Types in Procedure we have to specify the requirement. The Condition Type with requirement “3” is used “Without Controlling” and the Condition Type with requirement “2” is used “With Controlling”

Select the second option “Assign the Account Determination Procedure”. Select the required Billing Type and assign the Procedure.

452

If required we can define our own Account Keys.

Select the First Option “Define Account Key”. Go to New Entries and Define an Account Key.

Select the second option “Assign Account Key” and account key to required Pricing Procedure and Condition Type

453

For the system to post the sales values to the corresponding G/L accounts, we have to assign the G/L account to a given combination of fields. For this assignment Go to following path: Path: SPROIMGSales and DistributionBasic FunctionsAccount Assignment/CostingRevenue Account DeterminationAssign G/L accounts

Go to the details of first table. Select “New Entries” button and assign the G/L account to the combination of following fields

454

1. Application: Specify “V” for Sales and Distribution. 2. Condition Type: Specifies the Condition Type in the Revenue Account Determination Procedure for which records are maintained i.e. G/L accounts are assigned Example: “KOFI”- This Condition Type is used without controlling, “KOFK” – Used with Controlling 3. Chart of Accounts: It is a classification scheme which contains the G/L accounts. It provides a frame work for the recording of values to ensure an orderly rendering of accounting data. Here we need to specify the chart of Account in which the G/L account we are assigning exists. 4. Sales Organization: Specify the Sales Organization from which the values are to be posted to the corresponding G/L accounts. 5. Account Assignment Group of Customer: This is specified in the Customer Master which enables the system to post the sales values of different customers to the corresponding G/L accounts 6. Account Assignment Group of Material: This is specified in the Material Master that enables the system to post the sales values of different material types to the corresponding G/L accounts 7. Account Key: This is specified in the Pricing Procedure for each Condition Type which enables the system to post the condition values to the corresponding G/L accounts. Note: Creating Account Assignment Groups of Customer and Material

455 Path: SPROIMGSales and DistributionBasic FunctionsAccount Assignment/CostingRevenue Account DeterminationCheck Master Data relevant for Account Assignment

a) Materials: Account Assignment Groups: Go to New Entries and create. This value had to be specified in the required Material Master Record. b) Customers: Account Assignment Groups: Go to New Entries and create. This value had to be specified in the required Customer Master Record.

Sales Incompletion Logs It is imperative that specific control is maintained over the entering and failure to enter values in specific objects—for example, sales documents. The data maintained in the sales document is passed through to the delivery and finally the billing document. Thus it is the sales document data that is used as a backbone in sales and distribution processing. In some instances a delivery document may also need specific data to be maintained. For this reason SAP has an incompletion structure that may be maintained for the delivery to highlight missing data in sales as well as delivery documents, sales activities, and partner functions. Defining Status Groups To define the status groups, use the following menu path. Path: SPROSAP Customizing Implementation GuideSales and DistributionBasic FunctionsLog of Incomplete ItemsDefine Status Groups

456

An incompletion process inspects the object—for example, sales document line item—and inspect specific fields in order to see if data has been maintained in these fields. Should data not be maintained in these specified fields, the system is told how to respond—that is, does it or does it not give a warning message and to what extent does it allow further processing of the document (based upon the status group). The incompletion log cannot register what data is maintained in the specified field and compare it to data that should be in the specified field. For example, should a sales document header have a purchase order number, the system will only check to see if data is maintained in VBKD-BSTKD (sales document header - purchase order number)? The standard system cannot check to see if the entry in the field is equal to, for example, 10002. You can create incompletion logs for the following: • • • • • •

Sales document header data Sales document item data Sales document schedule line data Sales activity data Partner data in sales documents, deliveries, and sales activities Delivery header data

457 •

Delivery item data

It may seem like we are configuring things in the wrong sequence, but we require a status group in order to assign it later, so first you need to define the status groups. This may be done by using the IMG path listed at the beginning of this section. These status groups are eventually assigned to the specific field in the incompletion procedure. It is possible to specify that in a sales document that field A may be incomplete but not hinder the document from being processed further, while field B may be incomplete and be the cause of the same document being blocked for further processing. The status groups, seen in Figure above, will be assigned to a field in the sales incompletion log. This is where the control of the availability check is carried out. The statuses that may be incomplete are General: Setting this status in the status group and assigning the status group to afield in the incompletion procedure will cause the sales document to be incomplete. However, it will allow the document to be processed further. • Delivery: Setting this status in the status group and assigning the status group to afield in the incompletion procedure will cause the sales document to be incomplete for further processing, that is, the creation of a delivery (it will not hinder the creation of a billing document) • Billing Document: Setting this status in the status group and assigning the status group to a field in the incompletion procedure will cause the sales document and delivery document to be incomplete for further processing, that is, the creation of the billing document, should the associated field not be filled. • Price: Setting this status in the status group and assigning the status group to afield in the incompletion procedure will cause the sales document to be incomplete for further processing should pricing not have been carried out. • Goods Movement: Setting this status in the status group and assigning the status group to a field in the incompletion procedure will cause the delivery document to be incomplete for further processing, that is, for goods movement, should a field not be filled (for example, quantity picked) • Picking: Setting this status in the status group and assigning the status group to afield in the incompletion procedure will cause the delivery document to be incomplete for further processing, that is, picking, should a field not be filled (for example, serial numbers). • Packing: Setting this status in the status group and assigning the status group to afield in the incompletion procedure will cause the delivery document to be incomplete for further processing, that is, packing, should a field not be filled (for example, quantity picked). Should you wish to change a status group, be sure to copy the status group that closely resembles your requirements, change its name, and continue to change this new status group’s assignments? •

458 In our example we will be using the Status group 01, which has a General status. Now we are able to proceed to defining the incompletion procedures.

Text Determination What is Texts? Text is a small piece of formatted or unformatted text that is functionally used to describe or note information in master data and Transactional Data. For example, a temperature sensitive material (say a bio-reagent) needs to be kept under freezing temperatures always. Although there is another field called Storage Conditions to denote this, we can use a text field with more specific comments so that the folks selling this material can ensure that they always inform the customer that they need to have storage facilities for the same. Since the information in this case is used to inform sales agents, it can be a “Sales Text”

Now, it’s not just enough that the material master contains this text. We will also have to ensure that the sales agents creating orders for this material has visibility to the same text. That means that the sales order should also have texts that can show the same. And since this text is specific to the specific material, this text needs to be part of the line item not the sales order header.

459

As you can see from the example above, there is myriad number of texts like item note, packing note, delivery text, purchase order text, production memo etc. All of these texts are either flown in from the corresponding master data (Customer master, material master etc) or entered in the transaction itself. In summary, texts are little pieces of information that are useful in communication information about master data or transaction specific data across the enterprise. Can Texts be formatted? Yes. These texts (Or Text Objects as they are normally called in SAP lingo) need not be constrained to plain text only. You can use the buttons highlighted below to import or export text. You can use the standard “Clipboard” (

) button to copy or paste text.

The best part is that on a windows machine, you can just double click on the white space to open your favorite rich text editor (Like MS Word or Text Pad) to format text as required. Also, these texts can be maintained in multiple languages as can be seen below.

460 How do Texts Flow? (Text Determination) As can be seen from the example above, the material sales text has flown in from the master data (Sales Text view of the material master) to the line item view of the sales order. This does not happen automatically. We will have to specifically configure the system to ensure the same. This process of creating new texts and letting them flow across the transactions and determine when and where these texts need to be is called “Text Determination”. The Sales and Distribution module is used in the text determination for the following objects: Customer   

Central Texts Contact Person Sales and Distribution

Info Record 

Customer/Material

Pricing Conditions  

Agreements Conditions

Sales Document  

Header Item

Delivery  

Header Item

Billing Document  

Header Item

Sales Act. 

General Text

Shipment

461 

Header

Financial Document 

General Text

Legal Control 

General Text

Agency Business  

Header Item

Trading Contract  

Header Item

Defining Text Types To configure text determination, use the following menu path Path: SPROIMGSales and DistributionBasic FunctionsText ControlDefine Text Types

462 You will see an overview screen with text objects. You may select any one text object, and then click the Text Types button, to define permitted text types for the text object We will maintain the text determination in the customer master record as an example. Text Determination for the Customer Master Record To create text determination, originating from the customer master record proceed as follows: 1. Select the customer—sales and distribution radio button. Then click the Text Types button 2. You will see an overview screen like the one in below figure. It is here that you define different text types you wish to have in the customer master record, and enter a short description for each of them. For example, “ZEXM” is used as “customer’s text”. Text determination data is client—independent.

3. Once the text type has been created, you need to define the access sequences. However, the access sequence is not necessary for the customer master record texts as the customer master record is the highest level possible in text determination 4. After creating the access sequences, you then create the text procedure by clicking the change button from the text object overview screen. This is seen in Below Figure. Create a two character key with a short description, for example, “Z1”

463

5. After creating the procedure, one can proceed to assign the text types to the procedure. This can be done by selecting the button “Texts in procedure.” It is here you assign the actual text types you would like to have assigned to the customer master record. There is the four-character key ID and the short description. In our example, as seen in below figure, we have added our text type, ZEXM—Customers text, to the list.

464 6. Once the text has been assigned to the procedure, it is time to assign the procedure to the customer’s account group. This is done by selecting the button Text procedure Assignment folder from the file structure seen in below figure. In our example, all the account groups have been assigned to the text procedure 01.

After completion of the customer account group assignment, it is now possible to create the text in the customer master record. The customer master record has four text objects, as we have previously seen. The sales and distribution text object is accessible from the Sales view of the customer master record and by selecting Extras, Texts. Note the description in the text as we will be using that for our next example Text Determination with an Access Sequence If you need to create text determination that is based upon the text being entered elsewhere and copied into the new text object, you need an access sequence. All other configuration steps remain the same with the addition of this access sequence. Let’s look at an access sequence in use, for example, with the sales document header. The text determination procedure screen is now as seen in below figure.

465

If you select the Access Sequences folder in the file structure on the left you will see a screen similar to below figure, which lists all the access sequence related to text determination

466 By selecting the access sequence and clicking the Access Sequence for Text IDs folder in the file structure on the left, which lists the text IDs and the text object they originate from in steps as a sequence. In figure below we see 5 steps. The text typed in ID 0001 in the sales document header (VBBK) will be determined first, followed by the text typed in ID 0001 in the sales view (KNVV) of the customer master record, followed by the text in ID 0001 in the sales general (KNA1) text of the customer master record.

At first this may seem strange to determine the text from the sales document header (VBKK) when the objective is to define how the text originates in the sales document header in the first place. The reason why this is the first step in access sequence is to permit this access sequence to be used to originate the text ID 0001 for more than one text object, that is, not only to originate text in the text object VBKK. Also, VBKK refers to the preceding sales document where the text is defined as header text. For example, if the preceding document was a quote copied into an order, the VBKK refers to the quote. If it was an order copied to a delivery, then VBKK refers to the order. If a delivery is copied to an invoice, then VBKK is the delivery. The last step that is different due to the access sequence in the assignment of the access sequence to the text ID This done by selecting the text ID’s in Procedure folder in the file structure on the left side, as seen in below figure

467

It is here you assign the actual text types you would like to have assigned to the sales document header. There is the four-character key ID and the short description. You can now assign the access sequence that must be used by the system in obtaining this text ID. You can also specify if the text is to be mandatory or not. If the text is specified as mandatory and does not exist in the sales document, the system will place an entry in the sales incompletion log. Note the reference/duplication rule: If you select copy, the system will copy the text from one document into the other where it can be changed and edited. If you do not select copy, the system does not copy the text. Instead, the system references the text from the previous document and displays it in the editor. Obviously, because the text does not belong to the document, it cannot be changed. To change it, you need to change it in the original document. Since the text is referenced, these changes will be visible in the reference documents immediately. Once the texts have been assigned to the procedure, it is time to assign the procedure to the sales document types. This is done by selecting the Text proc. assignment button from the

468 procedure overview. In our example, the standard sales order document type OR has been assigned to the text determination procedure. We can now create the sales order. By selecting Go to, Header, Texts, you can see that the customer-specific text has been automatically copied from the customer master record into the sales document header Do not forget that by selecting the Analysis button, one can find any errors or if the determination is correct Do not forget the Materials Management module (MM) has text determination too. These are split up into the different document types that are used in the MM module, such as the purchase order and the contract or scheduling agreement. This is accessible by following the menu path IMGMaterials ManagementPurchasingScheduling agreementDefine rules for copying (adoption of) text. In the maintenance of access sequences, it is useful to know the different objects. The most common are as follows:       

KNVV: Customer sales texts (texts entered in Extras–.Texts) in the customer master from one of the sales screens. KNA1: Customer master central texts (texts entered in Extras–.Texts) in the customer master from one of the general screens KNB1: The accounting texts KNMT: Texts defined for the customer material information record KNVK: Texts from the contact person’s screen in the customer master MVKE: Texts from the sales text screen in the customer master record VBBK: The preceding sales document where the text is defined as header text

For example, if the preceding document is a quote copied into a delivery, then VBBK refers to the quote. If it is an order copied to a delivery, then VBBK refers the order. If a delivery is copied to an invoice, then VBBK is the delivery. 

VBBP: Preceding sales document ITEM where the text is defined at the item level

TEXT: This refers to standard text that applies across the system (that is, it is not specific to a document, customer, or material). The text ID in this case must be ST. When you select this text object in the access sequence, an additional field will open for you to enter the name of the standard text. This is the name you give the text when you create it in the SAP Script editor. To create standard text from the Logistics screen, proceed to Tools, Word Processing, Standard text [SO10]

469 Demo of Customer Master Text Determination: To view the existing text types in the Customer master go to ExtrasTexts in the General Tab.

As you can see the following texts are available for the standard customer master for customer account group 0001 (Sold-to Party) Now that we have changed the text determination procedure of the customer master to ‘Z1’, we can see the new texts types that we have created for the customer text object KNA1 below.

This concludes the configuration for the text determination in Customer Master. The text determination for other master data (Material Master, Info Records etc) is very similar. Demo of Sales Order Text Determination: Create a new Customer and enter a Sales Note in the General Texts

470

Create a sales order for this customer and see what comes as the “Form Header” text ID. In this example, text created as the “Sales Note for Customer” from the General Text of the Customer master seems to flow down to the “Form Header” text in the sales order header text.

Let’s take this one step further and create a sales area text – Sales Note for Customer and see if it supersedes the General text – Sales Note for Customer as defined in the Access sequence. Enter a new sales note for the customer for the sales area text.

Now, create a new order of the same order type (OR). You should now be able to see that the newly entered sales text in the Sales Area tab supersedes the text entered in the General Text

471

This is because, the customer sales texts ( KNVV ) supersedes the Customer General Texts ( KNA1 ) in the Access sequence associated to the text ID Form Header in text determination procedure associated with the sales order of type OR.

Output Determination An Output is a form of media from a business to one of its business partners. The possible media forms are printouts, faxes, telexes, e-mails, and electronic data interchange (EDI). The output can be sent to any of the partners defined in the document. Outputs are usually in the form of order confirmations, delivery notes, invoices, and shipping notifications Maintain Output Determination for Sales Documents: Output Determination uses the condition technique to determine the condition record necessary for the application. An output type is simply a type of output and contains all the control features for the output. For example, it defines the kind of output (order confirmation, invoice etc.) which business transaction it applies to, which business partner receives the output, how the output is sent, the print program, and the form layout to use in formatting the output.

472 The output type is thus the central component of the output determination. To maintain Output Determination use the following path: Path: SPROIMGSales and distributionBasic functionsOutput ControlOutput determinationOutput proposal using the condition techniqueMaintain output determination for sales documents It is possible to maintain the output determination for eight activities using the condition technique that is used for the following: 

Sales Activities: Configured in the IMG in Sales and Distribution



Sales Documents: Configured in the IMG in Sales and Distribution



Deliveries: Configured in the IMG in Logistics Execution, Shipping



Handling Units: Configured in the IMG in Logistics Execution, Shipping



Groups: Configured in the IMG in Logistics Execution, Shipping



Shipments: Configured in the IMG in Logistics Execution, Transportation



Billing Documents: Configured in the IMG in Sales and Distribution

 Because the determination techniques used in output determination are the same, we will focus on the particular example of output determination for the sales documents.  As we know from pricing and the condition technique, when using the condition technique, one should follow the maintenance activities in sequence: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Put the fields you will need into the field catalog Create the condition tables Create the access sequence. Assign the condition tables to the access sequence Create the condition types Assign the access sequence to the condition types Create the determination procedure (if necessary) and assign the condition types to it Assign the determination procedure Lastly, create your condition records.

Unlike the standard headings depicting the configuration process, the following configuration is done in a logical sequence you should follow when creating condition technique as in steps 1

473 to 9 Steps 1 and 2  Last, create your condition records. The output determination is no different. Steps 1 and 2 are identical and are accessible by following the menu path Path: SPROIMGSales and DistributionBasic FunctionsOutput ControlOutput DeterminationOutput Determination Using the Condition techniqueMaintain Output Determination for Sales DocumentsMaintain Condition Tables. Steps 3 and 4  Step 3 and 4 are also identical, in that one follows the same customizing steps as used in pricing in creating the access sequence. This is available by following the menu path Path: SPROIMGSales and DistributionBasic FunctionsOutput ControlOutput DeterminationOutput Determination Using the Condition techniqueMaintain Output Determination for Sales DocumentsMaintain Access Sequence.

Steps 5 and 6  Step 5 and 6 are identical in theory and usage, in that one assigns an access sequence to the

474 output condition type, except that the output condition type controls different data. The output condition type is accessible by using the following menu path Path: SPROIMGSales and DistributionBasic FunctionsOutput ControlOutput DeterminationOutput Determination Using the Condition techniqueMaintain Output Determination for Sales DocumentsMaintain Output Types.

 The output type represents different forms of output such as order confirmations, sales quotations, and so on.  You can access the output type settings by selecting the output type, such as BA00, and selecting the Display button (the magnifying glass)

475

 You can see in Figure above (Output Types), that the access sequence 0001 is assigned to the output type. You can see the system uses condition records to find an output command. The output may be changed during processing (as this cannot be changed checkbox is blank). As the multiple issuing checkbox is blank, this indicates the output may not be sent more than once to the same partner. As the partner independent output checkbox is not active, the output is restricted to being received only by those partner functions as set in the Partner Functions folder in the file structure on the left side, as seen in Figure Below.

476 Proceeding back to the output type, the last check box that is not activated is the do not write processing log, which if set will de-activate a very useful function of the output determination log in the process that is using the output—for example, in this instance, the sales order creation The program that will be used to execute the output is defined in the Processing Routines folder in the file structure, as seen in Figure below.

The output program for example RVADOR01 is assigned to a transmission medium—for example, for (1) print output. This program uses form RVORDER01 to define the layout of the output. You may double-click on the line in Figure, to see a view similar to Figure Below.

477

 Should you double-click the program or form again; you will go into the ABAP editor or form editor, respectively. Proceed back to the output type and select the Default Values tab, as seen in Figure Above. These values entered per output type are automatically transferred as default values when creating a condition record by output condition. The dispatch time has the following four options: 1. Send with periodically scheduled job 2. Send with scheduled job with own time specification 3. Send with application own transaction 4. Send immediately You must understand that the output is automatically proposed and processed according to the rules governed in output determination. However, the user is still able to reprint (if permitted), or change the printing specifications online in the sales document. For example, the order confirmation might only be printed overnight and posted to the customer the following day. However, the customer may explicitly request that his order confirmation is handed to him immediately, so the user would change the output processing time to a4—immediately. The business, however, may not want the user to have this authority on all output types. For example, the order confirmation may be printed on a special printer with special paper, thus should only be done via a batch job at night. You can specify (on the Time tab) that specific times of dispatch are not allowed. This is set by indicating, for example, time of dispatch 4—not allowed.

478 You may also set the print parameter as seen on the Print tab. These criteria may be set as the sales organization or sales office, for example. It is also possible to print and archive a document automatically by setting the Storage mode to 3 (Print and Archive) and assigning the correct archiving document type. This field identifies whether the archived document is an invoice, quotation, or order confirmation, etc. The archiving object of outgoing documents begins with SD0. These settings are made on the Storage System tab Step 7  Prior to completing Step 7, follow this menu path Path: SPROIMGSales and DistributionBasic FunctionsOutput ControlOutput DeterminationOutput Determination Using the Condition techniqueMaintain Output Determination for Sales DocumentsAssign Output Types to partner functions

 One can assign the allowed output types and processing medium to the partner functions. For example, one can assign the order confirmation as a printout to the sold-to party and the order confirmation as a fax to the sold to party

479  Step 7 is also identical and is accessible via the following menu path Path: SPROIMGSales and DistributionBasic FunctionsOutput ControlOutput DeterminationOutput Determination Using the Condition techniqueMaintain Output Determination for Sales DocumentsMaintain Output Determination Procedure  One has an output determination procedure with the output condition types assigned to it. The condition types also have a requirement that can be assigned, restricting any access to the output type as well as access to the access sequence and condition records, unless specific conditions in the requirement have been fulfilled. The output determination procedure is seen in below figure by selecting the procedure CSA001 and clicking the Control Data folder in the file structure on the left.  After completing the assignment of the condition type to the procedure, proceed to Step 8, where you assign the procedure. Step 8  The assignment is achieved in the following menu path Path: SPROIMGSales and DistributionBasic FunctionsOutput ControlOutput DeterminationOutput Determination Using the Condition techniqueMaintain Output Determination for Sales DocumentsAssign Output Determination Procedures This assignment of the output occurs at the header and item level for sales documents. This assignment is shown in figure below for the header level. The assignment is similar at item level except the procedure is assigned to an item category

480

Step 9  Finally, one can now create the condition records necessary for output determination. This can be done by using the following path Path: SAP Easy AccessLogisticsSales and distributionMaster dataOutputSales Document. The Transaction Codes related to the creation, maintenance and display of output condition records are:  [VV11] Create 

[VV12]

Change



[VV13]

Display

 One assigns the output type, partner function, transmission medium (1 = printout), timing of the output (4 = immediately), and the language, English. By selecting communication one can assign the output device (due to the transmission medium being a printout), the number of messages, and whether the output must be printed immediately

481  If you now create a sales order with document type OR (English), the system will automatically propose an output type BA00 based on the output determination as set in the above steps.  The buttons in the sales order output are 

Communication methods that identify the details as set in the communication area of the condition record, such as printer name and so on.



Processing log records a log of the output already processed in the sales document.



Further data determines if the output has been processed as well as the timing data, that is, the output to be processed immediately or in batch



Repeat output can be used to repeat already-processed output



Change output can be used to change the output

This completes the maintenance of the output determination as required in the system. However, there is a lot of additional data that pertains to output that you should be aware of. Brief Overview of a Layout Set and Its Assignment to Output Types  Layout sets and SAP Script do not fall within the scope of this book, but it is beneficial for one to understand how the sales and distribution module integrates with the layout set and SAP script  How does output work? Each output type is linked to a processing print program and a layout set. For example, in the SAP standard, the output type BA00 (order confirmation) is linked to processing program RVADOR01 and layout set RVORDER01. When the user enters the output type in the business transaction and then selects to print it, SAP calls the print program. The print program reads the business transaction and collects all the information that needs to be printed on it. It puts this information into structures defined in the data dictionary. The fields in these structures are used in the SAP Script layout to define what data must be printed and where it must be printed  The print program then opens the SAP Script layout and calls each of the elements in the layout. The layout takes the information from the data dictionary structures as well as all the formatting information and then formats it for the printer, fax machine, or e-mail. Finally, the SAP system sends the output to the necessary device (printer, fax, or mail server).  In the order example, when the user enters the output type BA00 in the order transaction

482 and then issues the output, SAP calls the print program RVADOR01. This program reads the sales order and related information and transfers it into the structures VBDKA (header information), VBDPA (item information), KOMK (pricing information), and others. It calls SAP Script, printing the relevant elements. SAP Script uses the information in the structures and formats the output to be printed  When SAP sends the output to the printer, it is printed with the information collected by the print program in the format defined in the form. Defining Forms: You may define the forms, by using the following menu path: Path: SPROIMGSales and DistributionBasic FunctionsOutput DeterminationProcess Output and FormsDefine Forms

 The layout set is divided up into six elements, namely 

Header data: General information about the layout set, such as the user who is responsible for creating it and a short description of the layout set.



Paragraphs: This defines the paragraph styles used in the layout and defines how the paragraph will print. For example, must the paragraph be right- or left-justified?



Character strings: These define the styles for a string of characters. For example, should a word be printed as bold, underlined, or italic?

483 

Windows: Windows are separate sections on the page. For example, you could have a header window for a company log and a footer window for the page footer. The most important window is the Main window where the items are printed. You specify the text and fields to be printed in the layout set in the different windows



Page: This defines the pages in your layout. You may have a first page containing a lot of header information, but the following pages contain the overflow from the Main window.



Page windows: In this section, you arrange the windows you defined in the Windows section on the pages. You specify which windows are on each page and the positions they occupy on the page

Defining Form Texts You can define specific form texts per Sales Organization, Sales Office, or Shipping Point using the following menu path: Path: SPROIMGSales and DistributionBasic FunctionsOutput DeterminationProcess Output and FormsAssign Form TextsAssign Form Texts per Sales Organization  These specific texts are the address text, letter header, letter footer text, and greeting text. One can specify the position of these texts within the output document  The “number of copies” allocation to the customer master record output and the condition technique output is a bit of a red herring in that, in most instances, one will not be able to create more than one output (see OSS note 0003748), unless one dedicates a printer to print a specified number of outputs as a default for all outputs on that printer. The only alternative options are to manually reprint a specific output or to create a copy of the output type. For example, allow two order confirmations to be automatically determined by the system for specific conditions, thus causing two printouts.  One can view printer details and output specific data by using the transaction code Spool Administration (SPAD) and branching off to view necessary data, such as output devices and spool servers  Should one need to reprint a number of documents, such as billing documents, one will have to create a new specific print program in SAP version 2. However in version 3 and above one may use the menu path: Logistic, Sales and distribution, output, billing documents

484

Transaction Code: 

VF31—Billing documents



VT70—Shipping and delivery documents

 One must enter the number range of documents that must be printed, the output type, and the transmission medium and set the process mode, for example, to reprocess

485

Credit Management What is Credit Management? Most enterprises extend credit to their customers. This literally means, selling their goods and collecting money at a later point of time. The amount of credit extended is determined by the customer’s credit worthiness (Also called credit limit). The number of days for which credit is extended is based on the payment terms associated with that transaction. For ex., Customer A could be given a credit limit of $ 100,000 by the company.

Now let’s say the customer orders goods worth $ 20,000 with payment terms of Net 45 2 % ( Meaning if the customer pays for the goods within 45 days of purchase, he will be given a 2% cash discount. So instead of paying $20,000, the customer would need to pay ($20,000 – 2% of 20,000) = $ 19,600. This is to encourage timely payment of their bills and improve cash flow).

The same customer could also place another order for $ 60,000 and still be within his credit limit.

The value of Order A ($ 20,000) and Order B ($ 60,000) put together is called the credit exposure of the customer. If the customer places another order for $ 30,000 more, he now exceeds the credit limit set for him.

486

So, at the point of ordering (Order C) the customer’s total receivables (Value of Order A + Order B) along with his current order (Order C) are checked against this credit limit. Since the customer exceeds the credit limit set for him, the order would be blocked. Credit Exposure = Value of all Open Items + Value of the current Order $ 110,000 = ($ 20,000 + 60,000) + ($ 30,000) This is a very simple example of credit management. In reality, credit management can get pretty complicated and not all the scenarios will be covered in this document.

Types of Credit Management Types of credit checks: 1. Simple credit check 2. Dynamic Credit check 1. Static Credit Check 2. Dynamic Credit Check

Simple Credit Check This is very similar to the example we have discussed earlier. Simple credit check compares the Customer’s credit limit to the total of all the items in the order and the value of all open items. Credit Exposure in Simple Credit Check = Value of all Open Items + Value of the Current Sales Order. Open items are orders that have been invoiced to the customer but the payment for the invoices have not been received yet. The system can be configured to either block the delivery, send a warning or an error message when the credit exposure has exceeded the credit limit of the customer.

487 Dynamic Credit Check Simple Credit Check alone is not sufficient for most businesses. Instead of just considering open items only, there is a need to consider existing open orders and open deliveries as well. Also, for old and seasoned customers, even if the credit exposure exceeds the credit limit set for the customer, the order can still be processed because of the good payment history with the company. However, for new customers credit needs to be strictly monitored. For the purpose of Credit Management, SAP allows us to re-categorize customers into different ‘Risk Categories’. Some examples of risk categories could be Medium Risk, High Risk, and Low Risk etc. Dynamic Credit Management can be broadly divided into 2 components. Static Check Dynamic Check

Credit Open Deliveries + Open Invoices + Open Items Credit Open Sales Order Value with a Time period ( Called Time Horizon )

Horizon: The use of time horizon can be best explained with an example. Most orders for the holiday season are pre-ordered because of the holiday rush. Orders might start to pile in as early as June, July. The delivery however is to be done in November or December.

For example, in August, Order A for $ 50,000 is a Pre-Ordered to be delivered in November.

Similarly for the month of December, another order, Order B is placed for $ 40,000 to be delivered in December. In case of static credit check, the credit exposure is already $ 90,000. If a regular order is placed in August for another $ 30,000 the credit exposure would exceed the credit limit of $ 100,000.

488 However, in case of dynamic credit check, a horizon of say 2 months would be used to exclude all orders for which the delivery has to be beyond the stipulated horizon. So, order C would not be blocked in case of dynamic credit check.

Organizational Structures & Master Data Monitoring Credit during SD Processing The master data for those customers whose credit we wish to monitor is created in SD. We determine how high a customer’s credit limit is to be when creating this data. Credit Control Area It is the responsible Organizational element which takes care of all the Credit management activities within a Company Code. Defining Credit Control Area Path: SPROIMGEnterprise StructureDefinitionFinancial AccountingDefine Credit Control Area.

489 In the Definition of Credit Control Area (CCA) we need to specify the currency. We need to specify which documents must be updated from Sales and Distribution to Finance for calculating the credit limit that have been already used. We need to specify Fiscal Year variant.

The credit limit specified in the definition of CCA by default applies for all those new customers for whom the credit limits have not yet been maintained.  A credit control area is an organizational unit that is comprised of one or more company codes. One Company Code cannot have more than one Credit Control Area. Assigning Company Code to CCA: Path: SPROIMGEnterprise StructureAssignmentFinancial AccountingAssign Company Code to CCA

490

Select the required Company Code and assign the required CCA. Assigning Sales Area to CCA: Path: SPROIMGEnterprise StructureAssignmentSales and DistributionAssign Sales Area to CCA

Select the required Sales Area and assign the required CCA.

491 Defining Risk Categories:  A customer’s risk category is a grouping category that controls the credit checks when automatic credit control takes place. Thus, one can assign high-risk customers to risk category, for example A01, medium-risk customers can belong to B01, and low-risk customers can belong to group Path: SPROIMGFinancial AccountingAccounts Receivable and Accounts PayableCredit ManagementCredit Control AccountDefine Risk Categories.

Select New Entries button and create a risk category for the required CCA. After creating the risk category it has to be assigned to the required customer

492 Customization Settings for Credit Management in SD Define Credit Groups The Credit Group specifies which transaction can be blocked for processing if the credit limits are exceeded. For creating this Go to following Path: Path: SPROIMGSales and DistributionBasic FunctionsCredit Management and Risk ManagementCredit ManagementDefine Credit Groups The following credit groups are contained in the standard SAP R/3 system: 01 = Credit Group for sales order 02 = Credit Group for deliveries 03 = Credit Group for Goods Issue.  As a tip, it is advisable to be as simplistic as possible when defining the credit risk categories and document credit groups These Credit Groups will block the corresponding transaction only if they are assigned to those transactions. For this assignment go to following Path: Path: SPROIMGSales and DistributionBasic FunctionsCredit Management and Risk ManagementCredit ManagementAssign Sales Documents and Delivery Documents.

493 a) Credit Limit Check for Order Types:

Select the required Sales Document Type and assign the required Credit Group b) Credit Limit Check for Delivery Types:

494 Select the required Delivery Type and assign the required Credit Group to block Delivery and Goods Issue. Define type and scope of credit checks  A credit check can only occur in three places: the sales order, the delivery, and the goods issue. The system can use a simple credit check, a static credit check, or a dynamic credit check. 

Simple Credit check

A credit limit check can be carried out when sales documents are created or changed. The check is carried out within one credit control area. The simple credit check compares the payer customer master record’s credit limit to the total of the net document value and the value of all open items. Should the value of the document and open items be greater than the credit limit permitted, the system may respond with a warning message in the sales order, a warning message and a delivery block (which will allow the order to be taken but will block it for delivery), or an error message that will cause the document not to be saved. This setting for a simple credit check is set at the document type level; thus, the system will use this simple check for all sales orders created for this particular sales document type. The system will perform the simple credit check for all created and changed sales documents

Maintaining Credit Limits for Customers Path: Easy AccessLogisticsSales and DistributionCredit ManagementMaster DataChange-FD32

495 Specify the customer for whom the credit limits are to be maintained. Also specify the CCA of the customer and select all the views.

496 1. In the Overview screen from the Main Menu select Go toCentral Area DataStatus a) Credit Limit: Specify the credit limit of the customer. b) Credit Horizon Date: If we specify a date here, only those outstanding Sales Orders which fall within the specified Horizon Date are taken into account while calculating the credit limit used. c) Risk Category: Specifies the corresponding Risk Category of the Customer. d) Last Internal Review: Specifies the date on which the customer’s credit limits are last reviewed e) Next Internal Review: Specifies the date on which the customer’s credit limits are going to be reviewed. 2. From the Main Menu select go toControl Area DataPayment History. On this view the system displays the payment history of the customer (Provided we check the field “Payment History Record” in the corresponding Customer Master Data)

3. From the Main Menu select go toGeneral DataCentral Data. a) Total Amount: The amount for this field specifies the overall credit limit that a customer may receive in all the Credit Control Areas. b) Individual Limit: The amount for this field specifies the maximum credit limit that a customer may receive within a CCA.

497



Automatic Credit Check

The automatic credit check can target certain aspects during a check and run at different times during order processing. We can determine an automatic credit check for any combination of the following: - Credit Control Area - Risk Category of the Customer - Credit group Automatic Credit Control Path: SPROIMGSales and DistributionBasic FunctionsCredit Management and Risk ManagementCredit ManagementDefine Automatic Credit Control

498

During the sales document processing the system automatically blocks the required transaction if the credit limits are exceeded. For this we have to configure “Automatic Credit Control” We need to maintain Automatic Credit Control in the combination of CCA, Risk Category and Credit Group CCADLCC Risk Category 001 – Low, 002 – Medium and 003 – High Credit Group 01 – Order, 02 – Delivery and 03 – Goods Issue. CCA DLCC

Risk Credit Category Group 003

01

This Automatic Credit Control enables the system to automatically block Sales Order if the credit limits are exceeded for those customers with High Risk Category

499 CCA DLCC

Risk Credit Category Group 001

03

 This Automatic Credit Control enables the system to automatically block Goods Issue if the credit limits are exceeded for those customers with Low Risk Category CCA DLCC

Risk Credit Category Group 002

02

 This Automatic Credit Control enables the system to automatically block Delivery if the credit limits are exceeded for those customers with Medium Risk Category To create an Automatic Credit Control, Go to “New Entries” and enter the required CCA, Risk Category and Credit Group. Specify the corresponding description.

500 1. Item Check: If we check this field, the system carried out the credit limit check the moment we enter the item in the Sales Order. Otherwise it checks the credit limit while saving the Sales Order. 2. Credit Limit Season Factor: Specifies the percentage by which the Credit Limit has to be either increased or decreased during a specific period. 3. Checks: a) Dynamic: If we go for this check, for the purpose of evaluating the credits, the system ignores all those opened sales orders that are due for delivery after the horizon date. b) Static: If we go for this check, for the for the purpose of evaluating the credits, the system considers all those opened sales orders that are due for delivery after the horizon date c) Document Value: If we go for this check, the system carried a credit limit check for each sales document based on the value specified for the field “Maximum Document Value.” This is exclusively used for new customers for whom the credit limits have not yet been maintained. 4. Reaction: Specifies whether and how the system reacts in the Sales Document if the credit limits are exceeded 5. Status/Block: If we check this field the system blocks the corresponding transaction if the credit limits are exceeded. Save the Automatic Credit Control Note: For the system to carry out the credit limit check in the sales document, the following settings must also be done 1. In the definition of corresponding sales document type, we must not specify the value “No Credit Limit Check” for the fields “Check Credit Limit.” 2. In the definition of corresponding Item Category we have to check the field credit active.

Testing: Now let’s see an example, by creating 3 Sales orders. Check the Credit Limit for the Customer.

501

Here the Credit limit is set at 1,000,000 and the credit exposure is currently 0. Now let’s start creating the orders. Transaction Code: VA01 Order Value 1: 200.000,00

502 Create a second Order. Order value 2: 600.000,00

The credit exposure now is 800,000 (200,000 + 600,000)

Create a third order. Order value 3: 300.000,00 We get the following error message when we create the Order, because the total of the net document value and the open items value has exceeded the credit limit of the customer.

503

Questions Question 1: Create a new Customer (of SAP Customer Account Group - 001) in the sales area of your choice. Specify the SAP Customer Number Question 2: Find out the SAP Credit Control Area that is associated with the Customer’s Organizational Structure Question 3: Assign a Credit limit of 1, 00,000 to the customer created in Q.1 above. Question 4: Create a new SAP Sales Document Type (as a copy of standard order type OR if possible) and give the document type -Z019 Question 5: Set the Credit Management to the document type you created in Q.4 to Simple Credit Check. What are the different options available in Simple Credit Check? Question 6: Create a Sales Order for the Document type (Created in Q.4) and the Customer (Created in Q.1) for a material (say M-01) for a value of 30,000. Specify the SAP Order Number Question 7: What is the Credit Exposure for the Customer? Question 8: What percentage of the credit limit is used? Question 9: Create another order for the same customer and Order type – Only this time, create the order with a value of around 90,000 (It does not need to be exactly 80,000). What is the System Response? Did the credit limit warning come up? Question 10: What is the credit exposure for the Customer now?

504 Question 11: What percentage of the credit limit is used now? Question 12: Explain why the credit limit is not exceeded for Q.9 above even though the order value in Q.6 and Q.9 together exceeded the Credit Limit set by you in Q.3? Question 13: This time create another order for the same customer and Order type – Only this time, create the order with a value of around 1, 20,000 (It does not need to be exactly 1,20,000). What is the System Response? Did the credit limit warning come up? Question 14: Explain in your own words difference between the system responses for Q.9 vs. Q.13? Question 15: Delivery and Bill the Order you have created in Q.6. Make sure the Accounts are being posted to. Question 16: Check the total receivables for the Customer. What is the value? Question 17: After performing Q.15 above, what is the new effective Credit limit for the Customer? Addendum 1: The following is advanced SAP Credit Management Exercises that talks about Automatic Credit Management. This exercise should only be done after completing the SAP Simple Credit Management Exercises listed above. Hint: If you get confused in the middle, always start with a new customer, set a credit limit to a fixed value say 100,000 and start the transactions from scratch. This eases the pain of understanding SAP Credit Management configuration a bit. Question 18: Repeat Q.1 through Q.4 specified in and specifies the answers. Question 19: Create a new SAP Credit Group Zx and assign it to the new SAP Sales Document Type configuration you have created in Q.18 Question 20. This time set the Credit Management settings to Automatic Question 21. Create a new Risk Category ( How to create a new Risk Category in SAP ? ) say Zxx and assign it to the Credit Control area you have chosen in Q.18 above. Question 22: What are the 3 parameters used to determine Automatic Credit Control in SAP? Question 23: Specify the Automatic Credit Management settings to “Static” and specify the system reaction to Warning in case the limit exceeds. What configuration have you done to affect this? Question 24: Set the scenario in Q.23 to block the order in case of credit overage Question 25. Create the following Sales Orders with the Customer and Order type you have crated in Q.18 -> Order 1 – 30,000 Value -> Order 2 – 80,000 Value What is the system reaction to the second order? How is this different from SAP credit Management Reaction in Q.9 above? Question 26: Release the order from credit block for Order # 2 in Q.25 above. (How to release an SAP Sales Order from Credit Block)

505 Addendum 2: The following exercise in on SAP Automatic Credit Management with Dynamic Credit Horizon. It’s a little tricky especially with testing it and understanding the Dynamic Credit Horizon. Hint: Please try not to do all the questions in this post the same day – especially Addendum 2. Question 27: Create another Customer, a new Risk Category. Specify the same. Question 28: For the data in Q.27, set the Credit limit to100, 000, apply the newly created Risk Category to the Customer. Question 29: In Automatic Credit Management, specify the configuration for the corresponding Credit Control Area, Risk Category and Credit Group as follows -Dynamic Credit Management with “Warning” as the system response -the order should be blocked for credit in case the credit limit exceeds. -The SAP Dynamic Credit horizon should be 2 months. Specify the configuration you have done for the same. Question 30: Create a new Sale order for a value of 50,000, set the delivery date 4 months out into the future. Specify the SAP Sales Order and the delivery date Question 31. Create another Sales Order for a value of 50,000, set the delivery date 5 months out into the future. Specify the SAP Sales Order and the delivery date. Question 32: Create another sales Order for a value of 30,000 – do NOT change the SAP system proposed delivery date. Specify the SAP Sales Order Question 33. Specify the Credit Exposure for this customer and explain in your own words why it is so?

Blocking Customers  It is often necessary to block specific customer master records. This may be due to the fact that one has blacklisted a customer or there may be an embargo against the country in which the customer resides. Whatever the reason, it is possible to block customer master records from creating either sales orders, deliveries, or billing documents in specific sales areas or all of them Path: Easy AccessLogistics Sales and distribution Master dataBusiness PartnersCustomerBlock-VD05 Specify the Customer, Sales Organization, Distribution Channel and Division. After pressing Enter we will be navigated to below screen

506  These blocking reasons are assigned to the customer master record, as shown in Figure and one can assign the blocking reason to the selected sales area or for all sales areas for sales orders, deliveries, billings, or for sales support. The blocking reasons are each created in the individual path in the IMG.

Defining Shipping Blocks Once created, these blocks may be assigned. To create the blocks, use the following menu path. Path: SPROSAP Customizing Implementation GuideLogistics ExecutionDeliveriesDefine Reasons for Blocking in ShippingDeliveries: Blocking Reasons/Criteria As you can see in Figure Below, we have created a delivery block called ZV Once this delivery block has been created, it must be assigned to a delivery document type, by selecting Delivery Blocks.

507 After the delivery document types have been assigned, you can assign the blocking reason to the customer in transaction code [VD05]. This will then automatically default the block in the sales document. The delivery block is the most complex of blocks in sales and distribution processing. As opposed to simply blocking the document from being created, the block settings have the following impacts. Order Block The sales order will still be created. The user will receive a warning that there is a block on the order. This will stop the sales order from creating a delivery via the transaction code [VL01N], but will not stop a delivery being created via the delivery due list [VL10A].

508

Requirements Block The order quantity is blocked from being confirmed. Therefore, the system does not transfer requirements from the sales document to the plant. This permits the quantities in the plant to be used for other sales documents. Delivery due List Block This block will block the creation of deliveries with the delivery due list function. This block does not block the creation of an individual delivery [VL01N].

509 Picking Block This block does not permit the picking list to be created and picking to be carried out.

Goods Issue Block This block does not permit the delivery that has been created and picked from being goods issued, (i.e., from leaving the plant). This block is sensitive in a business process, as some companies do not have the controls in place to permit the goods issue from being executed only when the goods are due to be delivered/given to a carrier. If the goods leave your plant/warehouse prior to actually carrying out the goods issue, then it is not advisable to use this block. To create the blocking reasons for the sales documents, continue with the same procedure as above starting on the menu path as follows.

Defining Order Blocks Use the following menu path to configure the sales document block. Path: SPROSAP Customizing Implementation GuideSales and DistributionSalesSales DocumentsDefine and Assign Reason For Blocking The definition of the block is similar to the delivery block, and you can assign the sales document block to all those sales documents that you’d like to block being created.

510 An idea is to create multiple levels of blocks, such as the following • • • •

01 - Block Quotations and Orders and Contracts 02 - Block Contracts and Orders 03 - Block Contracts 04 - Block Orders

For example, by setting 02, you can set a customer block to enable a quotation to be created for a customer, but not a contract or an order.

Defining Billing Blocks Use the following menu path to configure the billing document block. Path: SPROSAP Customizing Implementation GuideSales and DistributionBillingBilling DocumentsDefine Blocking Reason for Billing These billing blocks are configured in the same manner as sales document blocks—simply a two-character key, which is then assigned to a sales document type, in this case a billing document. These blocking reasons are automatically copied into the sales document during creation. A message will appear at the base of the document, explaining, for example, that the customer has a billing block. You will also be able to find, for example, this billing block copied into the sales document (billing view of the sales order line item and billing header),where it may be removed by an authorized user. Naturally, a billing block will prevent a billing document from being created. In most instances this only makes business sense when one is creating a credit memo. However, it may also be required when creating a billing document for a particular project milestone related to a billing plan

511

Miscellaneous Topics Third Party Sales Processing In Third Party Order Processing, the company does not deliver the items requested by the customer. Instead, we pass on order to a third party vendor who then ships the goods directly to the customer and bills the company. A Sales Order may consist of wholly third party or partly of third party items Automatic Third Party Order Processing: If a material is always delivered from the third party vendor, we need to specify that the material is a third party item by specifying item category group “BANS.” During Sales Order Processing, the system automatically determines an appropriate item category for the third party item which is “TAS” Manual Third Party Order Processing: In the case of a material that we normally deliver our self but occasionally need to order from the third party vendors, during the sales order processing, we need to make that item as a third party item by changing the item category from “TAN” to “TAS” Note: For carrying out third party sales, the following settings must be done. 1. While creating the material master for third party sales item, we need to maintain the data for the view purchasing along with other required views. 2. Creating Purchasing Organization Path: SPROIMGEnterprise StructureDefinitionMaterial ManagementMaintain Purchasing Organization.

512

Go to New Entries, Fill in required details and save it 3. Assigning Purchasing Organization to Company Code Path: SPROIMGEnterprise StructureAssignmentMaterial ManagementAssign Purchasing Organization to Company Code

Select the required purchasing organization and assign the required company code

513 4. Assigning Purchasing Organization to Plant Path: SPROIMGEnterprise StructureAssignmentMaterial ManagementAssign Purchasing Organization to Plant

 Go to New Entries and specify the required combination of purchasing organization and plant. 5. Creating Vendor Path: SAP Easy AccessLogisticsMaterial ManagementPurchasingMaster DataVendorCentralXK01-Create

514

Specify the Vendor Number, Company Code, Purchasing Organization and Account Group (0001) Enter the required data for the views in master data and save it. Specify the Reconciliation Account as “160000.” 6. Creating Vendor Info Record Path: SAP Easy Access Material ManagementPurchasingMaster DataInfo RecordME11-Create

515 Specify the Vendor, Material Number, Purchasing Organization and Plant. Enter the required data and save the record 7. Maintaining Source List Path: SAP Easy Access Material ManagementPurchasingMaster DataSource ListME01-Maintain

Specify the Material and Plant In the overview screen, specify the required vendor with the corresponding validity periods Process Flow of Third Part Sales: 1. Create Sales Order for Third Party Item Use the transaction code VA01 and create the sales order for third party item.

516

Note: When we save the sales order, the system automatically creates purchase requisition for the third party item which is displayed in the corresponding schedule line data of that item.

517 For the system to create purchase requisition, we have to specify the document type “NB” for the field “Order Type” in the schedule line category of the third party item “CS” 2. Assigning the Purchase Requisition to a vendor and Creating Purchase Order Use the transaction code ME57

Specify the Purchase Requisition number, check the field “Assigned Purchase Requisitions’” and select the icon “Execute” The system displays a record where it automatically determines a vendor for creating “Purchase Order” Note: For the system to automatically determine a vendor, we need to maintain “Source List” Check the record and select the button “Assignment Overview” Select the record and select the button “Process Assignment” The system gives a pop-up box for creating Purchase Order. Drag and drop the Purchase Requisition Number on the basket symbol and save the Purchase Order

518 3. Creating the Goods Received Use the transaction code MIGO. Specify the Purchase Order Number and execute. Check the field “Item Ok” and select the button “Post Document” 4. Create Incoming Invoice  Use the transaction code MIRO. Specify the Purchase Order Number and Invoice Date. Specify the required amount to make the balance zero. Select the button “Simulate” Select the required G/L accounts and select the button ‘Post’ 5. Creating Customer Invoice  Use the transaction code VF01 and create the invoice with reference to sales order. Note: While creating the invoice with reference to sales order, the quantity has to determine from incoming invoice. For this we must specify the value “F” (Order Related Billing DocumentStatus according to Invoice Quantity) for the field “Billing Relevance” in the item category of third party item “TAS.”

Factory Calendars Factory calendars are used throughout the system. An easy way to understand them is to use them to specify which days are work days at a location. These calendars may be used by the business to determine when a delivery must take place in order for it to reach the customer’s site on a day when people are at work and can receive the delivery. We also used factory calendars in consolidated invoicing. That is, we specified that only one day a week was a working day for our customer and thus the billing documents were only to be created for that one day each week, causing many delivery documents from the whole week to be consolidated into one billing document. We will focus on the creation and maintenance of the customer’s shipping calendar. Defining Customer Calendars To define a customer’s shipping calendar, use the following menu path. Path: SPROSAP Customizing Implementation Guide-->Sales and DistributionBusiness PartnersShippingDefine Customer Calendars

519 You’ll see the screen shown in Below Figure. Two calendars must be maintained—the holiday calendar initially, followed by the factory calendar, which is created on the basis of the holiday calendar.

We will create a factory calendar called “ZG” that is “the international company working calendar.” Creating the Public Holidays The first step is creating the public holidays, by selecting the Public Holidays radio button on the initial screen as seen in above figure, and clicking the Change icon (pencil). Then select the new button or press SHIFT-F1 on the next screen. This will bring up a dialog box as shown in Figure below. Select “with fixed date” and click the Create icon (new page). You will see a screen in which you can define this holiday, as seen in Figure 10-26. Here, the day is set at 30 and the month at 10. The Guaranteed section sets the holiday to be automatically moved to the next working day if it should fall on a Sunday. The holiday is described as National celebration. After pressing ENTER, you may see the public holiday is not yet assigned to the holiday calendar. Creating a Holiday Calendar

520 You can now select the Holiday Calendar radio button seen in Figure 10-24 and click the Change icon (pencil). Select Create or press SHIFT-F1. Enter a Calendar ID—for example, “ZG”—with a description and a validity period. Click the Assign publ. Holiday button and you can select the public holidays, as shown in Figure 10-27.

521

522 After assigning the public holidays to the holiday calendar, click Save. You will be presented with a list of the public holiday calendars and whether they are used or not. Creating a Factory Calendar Now you can create a factory calendar by selecting the factory calendar radio button from the initial maintenance screen and clicking the Change button (pencil). You can specify a factory calendar ID with a short description as well as assign the holiday calendar that must be used for that factory calendar. This factory calendar has a validity period and most importantly specifies what days of the week are working days. Lastly, now that the customer-specific calendar has been created, do not forget to assign the calendar to the relevant master data—for example, to the unloading points assigned to the customer master record. When transporting changed factory calendars from one client to another (for example, after changing the factory calendar by increasing the factory calendar’s validity date), the system will first delete all factory calendars, holiday calendars, and public holidays before re-creating them all according to the data in the transport.

523 Standard SD Reports in SAP VA05 List of Sales Orders VA15 List of Sales Inquiries VA25 List of Sales Quotations VA35 List of Scheduling Agreements VA45 List of Contracts V.26

Sales Document by Object Status

VA14L Sales Documents Blocked by Delivery VL04 SAP Delivery Due List VF04 SAP Billing Due List VF05 List of Billing Documents Exercise: 1. Internally, the reports VA05, VA15 and VA25 pull out different data. The key difference between these reports is based on which one of the following fields? 1. SD Document Type 2. SD Document Category 3. SD Document Group 4. SD Document Rule 2. What does the field “Open Contracts” mean in the report VA45? 3. List YOUR Contracts between the last 2 months 4. Can you list Sales Orders by a particular material? 5. What is the program behind the standard SAP Billing Due List? 6. Can you run the Billing Due List based on Billing Document Type? 7. Can you run the billing due list based on sales document type? 8. List the field and its value you would search on if you were asked to select all Quotations or type ZQT in “Not Approved” status assuming ZQT is associated with the status profile ZQT? 9. Which report would you use to list all the open sales orders on the delivery block “01″?

524 Commonly Used Transaction Codes in SD SAP SD Sales Sales Order

[VA01] – Create Sales order [VA02] – Change Sales order [VA03] – Display Sales Order

Quotation

VA21 – Create Quotation VA22 – Change Quotation VA23 – Display Quotation

Inquiry

VA11 – Create Inquiry VA12 – Change Inquiry VA13 – Display Inquiry

Scheduling Agreement

VA31 – Create Scheduling AgreementVA32 – Change Scheduling AgreementVA33 – Display Scheduling Agreement

Contracts

VA41 – Create ContractVA42 – Change ContractVA43 – Display Contract

Back Order Processing

V_RA – Back Order Processing

Rescheduling

V_V2 – Rescheduling

List of Sales orders

VA05

List of Incomplete Orders

V.02

V.26

Sales Document By Order Status

V.15

Display Back orders

VA35

Display List of Scheduling Agreements

V.05

List of Incomplete Scheduling Agreements

525 VA45

List of Contracts

VKM3

Release Credit Hold Orders

SAP SD Delivery VL01N

Create Delivery with reference to Sales Order

VL02N

Change Delivery

VL03N

Display Delivery

VL04

Batch create deliveries

VL09

Reverse Goods Movements

LT03

Create Transfer order for Delivery

LT01

Create Transfer Order ( General )

SAP SD Billing VF01

Create Individual Billing Document

VF02

Change Billing Document

VF03

Display Billing Document

VF04

Billing Due List

Configuration Transaction Codes VOK0

Pricing Configuration

VOK2

Output Configuration

VOV8

Sales Document Type Configuration

VOV7

Sales Item Category

526 Configuration VOV6

Schedule Line Category Configuration

VOV5

Schedule Line Category Configuration

VOV4

Item Category Determination

VTLA

Sales to Delivery Copy Controls

VTFL

Delivery to Billing Copy Controls

VTAA

Sales to Sales Copy Controls

VOFM

VOFM Routines

VOPAN

SAP Partner Determination

VOTXN

SAP Text Determination

VK11 / VK12 / VK13

SAP Pricing Condition Records

VKM3

SAP Credit Blocked Documents

VOFA

SAP Billing Document Types

FD32

SAP Customer Credit Master

VTAF

Billing to Sales copy Controls

VTAF

Billing to Sales copy Controls

VTAF

Billing to Sales copy Controls

527 Commonly Used Tables in SAP SD Table Name KONP KONH KONV T077D TVKO TVKOS TVKOV TVTA KNB1 KNA1 KNB4 KNB5 KNBK KNKA KNKK KNVV KNVI KNVP KNVD KNVS KLPA VBUK VBAK VBKD VBUP VBAP VBPA VBFA VBEP VBBE LIKP LIPS VBRK VBRP

Description Conditions (Item) Conditions Header Conditions (Procedure Data) Customer account groups Organizational Unit: Sales Organizations Organizational Unit: Divisions per Sales Organization Org. Unit: Distribution Channels per Sales Organization Organizational Unit: Sales Area(s) Customer Master – Co. Code Data (payment method, reconciliation acct) Customers General Data Customer Payment History Customer Master – Dunning info Customer Master Bank Data Customer Master Credit Mgmt. Customer Master Credit Control Area Data (credit limits) Sales Area Data (terms, order probability) Customer Master Tax Indicator Partner Function key Output type Customer Master Ship Data Customer/Vendor Link Header Status and Administrative Data Sales Document - Header Data Sales Document - Business Data Item Status Sales Document - Item Data Partners Document Flow Sales Document Schedule Line Sales Requirements: Individual Records Delivery Document Header data Delivery: Item data Billing: Header Data Billing Document Item

528 Table Name VTTK VTTP VTTS VTSP VTPA VEKP VEPO

Description Shipment Header Shipment Item Stage in Transport Stage in Transport per Shipment Item Shipment Partners Handling-Unit Header Table Packing: Handling Unit Item (Contents)

529 SAP System Landscape The landscape describes the client’s strategy that will be used for its initial and post Go Live module configuration, ABAP development and the other project related work. Landscape is like a server system or like a layout of the servers or some may even call it the architecture of the server’s viz. SAP is divided into three different landscapes DEV, QAS and PROD.   

DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, and 180- Unit Test. QAS may again have multiple 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 are the client's business scenario. 1. Sandbox Environment: This environment is intended to be an area where the team can safely prove the concepts or resolve the problems without having to be concerned with the impact to that main system. This server can be refreshed periodically and whenever it is required Sandbox Client: In the initial stages of any implementation project, you are given a sandbox server where you do all the configuration/customization as per the company’s business process. This is the only client in this environment that is to be used for those tasks that do not fall under any typical run. For example: The proof of concepts that the development team does not have the experience of performing in the past OR not comfortable enough in performing can be done in this client. The production data issues can also be pulled down to this client to prove the solution

530 2. Development Environment: This environment is intended to be an area where the main activities occur and are tested before being moved through the quality environment on their way to production. Golden Client: This is the client where the main configuration settings will be done. All those configuration settings done here will be transported. The team member will have the restricted access to this client. No testing and customization is allowed in this client. ABAP Development Client: This client is used by the programmers to develop new ABAP programs. Those programs created here can be tested independent of the configuration changes that might be occurring in other clients. No configuration is allowed in this client. The configuration changes for this client are done by refreshing them using the Golden Configuration Client. Unit Testing Client: This client is used for unit testing of the configuration settings. This client is created from the golden configuration client and the sample test data will be uploaded here for unit testing. 3. Quality Assurance Environment: This environment is to be as close to the same as production environment as possible. This gives the developers a static version of the production environment. The entire completed unit test from the development environment. The changes to the cross client objects like table structures OR the programs are not allowed in this environment. These changes are to be made in the development environment. In rare circumstances where the changes has to be done directly in this environment a prior approval will be needed. Master Configuration Client: After the unit testing is completed in the development environment, all those requests are transported to this client who contains those transports. No transactional data is allowed in this client. So this client acts as Golden Client in Quality Environment. Integration Testing Client: This client is used for integration and User Acceptance testing. The Integration testing consist of Unit Tests strung together to comprise the entire business process. The integration Testing is performed in this client only after the functional configuration is completed. This client is refreshed from Master Configuration Client Training Client: This is the client where the actual SAP training is done for the users. It is refreshed from Master Configuration Client as per the requirements. Any configuration changes which go to the production client would also go to this client

531 4. Production Environment: This environment is used for the production operations of the company. Production Client: This client is used for the live transactions. The customizing and repository changes are only allowed to be transported to this environment after they have been fully tested in the quality environment and have a formal change control approved. No customizing or repository changes are allowed in this client under any circumstances. This client is unique in the Landscape which cannot be refreshed, can only be restored from a backup. Note: We need to transport the data from Development to Quality environment by transporting customizing request and workbench request. For this we have to use the transaction code “SE09” Select the request type and select the request status (Modifiable) and select the button display. Select the child request that has to be released and select the icon release directly. To transport the request from one server to another, in BASIS we have to configure Transport Management System (TMS)

532

ASAP Methodology Who needs to know about ASAP? Both project manager and team members. ASAP methodology gives the project managers the requisite technology and management roadmap to implement an SAP project following global standards and well acknowledged strategies. This approach also greatly reduces the risk and improves project timelines by giving the project manager tools to monitor and maintain metrics necessary for a successful implementation. Team members should be conversant with the general implementation roadmap as well as the specific accelerators that should be used to speed up the implementation. How is ASAP different from the standard Project Management Principles (from PMI)? If the project manager is well versed with the principles of PMP, then he/she should feel right at home. ASAP was developed by SAP (in collaboration with its implementation partners). The idea is to leverage this extensive experience and knowledge base to share the best practices specific to SAP implementations and apply them to the principles of PMI. So roughly speaking What are the advantages of using ASAP?   

Project time cut down in half. Lower Risk Reduced Costs.

Are there any other roadmaps that I should be aware of? Yes. ASAP is the roadmap proposed by SAP to implementations? There are other methodologies and roadmaps (also proposed by SAP) to effectively do other things in SAP like upgrades, support activities etc. What is ASAP Methodology? ASAP stands for Accelerated SAP. The word “Accelerated” refers to the many so called “Accelerators” (Tools & Information) available in SAP to expedite the implementation of SAP in an enterprise. So, simply put, ASAP is a methodology/ step-by-step approach used to effectively and efficiently implement SAP

533

Phases in ASAP Methodology 1. Project Preparation: This phase provides the initial planning and preparation for the implementation of the R/3 system.  Define your project goals and objectives  Clarify the scope of your implementation  Deciding the System Landscape  Preparing BRS (Business Requirement Specifications). It is the documentation of the business practice of the company (AS-IS Study)  Define your project schedule, budget plan, and implementation sequence  Establish the project organization and relevant committees and assign resources

2. Business Blueprint: In this phase we create the business Blueprint which is the detailed documentation of the results gathered during the requirements workshops. Furthermore the business Blueprint serves to document the business process requirements of the company. On this basis we will achieve a common understanding of how the company intends to run their business process in the R/3 system.     

Deciding Organization Structures Preparing Data collection sheets (For Data Migration) Deciding the data conversion strategy Preparing Business Blueprint Documentation (As-Is Vs To-Be) Gap Analysis

534  Identifying the areas where customization is required.  Estimation of Technical Resources  User rolls and Authorization. 3. Realization: In this phase we implement all the business requirements based on the business blueprint. We configure the entire system step by step in two work packages called as Base Line Configuration and Final Configuration.  

Carrying out organizational change management Baseline Configuration Confirmation: During Baseline configuration confirmation we work on those processes that can be configured without programming or enhancements.  Unit Testing of Configuration Settings  Final Configuration Confirmation: It is an iterative process in which we set up all the business requirements and confirm that all of them are met in the R/3 system. The final configuration is a transformation process that expands the baseline solution defined during business blueprint and baseline configuration through multiple cycles until a solution is found to deliver that satisfies all the stated requirements  Preparing the functional specification to pass on the requirement to the ABAPer’s  Testing the programs developed by ABAPer’s  Preparing User Manuals and Configuration Documents 4. Final Preparation: This is a crucial phase of the project. Apart from system testing and integration testing, the users are heavily engaged for the User Acceptance Testing (UAT). Users are also trained on how to perform the various business functions on the new system (User Training). Also, various master data and transactional data transfer requirements are evaluated to a much finer level of detail and the actual data migration is also performed. 5. Go-Live and Support: Now you are ready to go live. This step involves successfully planning the various go-live operations and strategies and subsequent support activities as well.  Except for some jargon, anybody who is familiar with the general principles of software engineering would be very familiar with the steps involved. ASAP Tools There are 3 key tools used in ASAP

535 1. SAP Solution Composer Solution Composer is the core tool of the ASAP implementation methodology. It provides a way to map and maintain the key business processes in an enterprise. It is a window’s installable that basically provides a graphical view of the solution maps 2. ASAP Roadmaps ASAP roadmaps are the heart of the ASAP implementation methodology. Solution composer is just a graphical tool used to create, maintain and manage ASAP (and other) roadmaps. The standard SAP provided roadmaps can be viewed either in Solution Composer or in plain HTML format. 3. SAP Solution Manager Sol Man is used in this phase primarily to materialize and store the roadmaps designed. The tools inside sol man that are used in this phase are the Question and Answers database, BPML, and document storage.

536 Most Common Errors, Scenarios and Their Resolution Problem: SAP Material documents associated with goods movements can be tracked via SAP Document Flow. Material documents generated via other processes like initial entry of goods into SAP, stock input into SAP cannot be viewed via document flow. Solution: Use Transaction code MB03. The menu path for the same is [SAP Easy AccessLogisticsMaterial ManagementPhysical InventoryEnvironmentMB03 Material Document]

Step 1: Enter SAP t code MB03 and Enter/ Search the material document number and Fiscal year

Step 2: SAP will display the material document number which includes

537

The materials associated with the material document Quantities, Plants etc Also the Accounting documents (By clicking on the Accounting Documents button in the toolbar) associated with the material movement if any. Question 1: What is the significance of “Posting Date” in the material document? Ans: It’s the date on which posting of the material is done Question 2: Can you change the material document after it is being posted? Ans. NO Question 3: Find out some (random) material documents generated for material M-01 in the FY 2003 and write them down here Ans. Can Use Transaction MB51 – No documents in 2003 Question 4: Do Material Document types have a Document Type? (Similar to SAP Sales Document type) Ans: Yes, could be relevant for MM

SAP MM Posting Periods How to Close Posting periods in SAP MM At most 2 periods (fiscal periods) can be open at any given time to post material accounts. Typically at the end of the month (or whatever the fiscal period is), the new period is opened and this automatically closes the last period. The transaction path to close posting period is [MMPV] and the menu path for the same is [SAP Easy AccessLogisticsMaterial ManagementOtherClose Period]

538

Enter the company code (This could be done in one-shot for a series of company codes) the new fiscal period to open (This is normally the next fiscal period) or you can specify the current date or the date based on which SAP needs to choose the fiscal period to open/close.

Some materials have negative postings enabled. If that is the case and if you are OK to have negative quantities/values allowed in the previous fiscal period, select the “Allow negative quantities in previous period “check mark.

539 To find out which periods are currently open go to transaction code [ OMSY ] and select the company code to find out the current fiscal year/period, the previous fiscal period/year etc. Also, the flag highlighted allows posting to the previous period.

Picked Quantity Grayed out in SAP Delivery – Feb 2011 SAP Training Batch

In this case, please observe that the “Overall WM Status” says “WM Transfer Order Required”. And there will be a warehouse no. assigned to it. Solution: This is happening because; Warehouse Management is enabled for the corresponding Plant’s storage location. The immediate and only solution to this is to create a “Transfer Order” in SAP

540

You will be prompted to save the delivery. Save it.

Complete the Transfer Order as guided by SAP. If Warehouse Management is configured well, then you should be able to complete the transfer order as desired.

541

Hit enter, and you will see the main SAP Transfer Order screen,

Hit the save button. If the material is available, it will be picked up by the transfer order and the picked quantity will automatically be populated by the SAP Transfer order into the SAP Delivery. Go back and open the Delivery again [VL02N]. The picked quantity will automatically be populated in the SAP Delivery.

542

You can proceed to save the delivery in SAP as usual. Error during PGI – PGI without entering picked quantities in SAP Delivery Error: The error occurs during Post Goods Issue (PGI) of the delivery

Solution: This happens when a delivery is not being picked. Enter quantity in the “picked quantity” field as shown below.

543

If the required delivered quantity is not available to be picked, you can under pick. (By selecting the correct line item in the SAP Delivery and go to EditCopy Picked Quantity as Delivered Quantity) and the delivery quantities will be adjusted accordingly.

What is a Sort Key in SAP and why is it used? A sort key is used to list the actual database value associated with a particular option in a drop-down. For example, when you are trying to create a customer of type sold-to 0001, if the sort key is not enabled, you would face a screen like this.

544

This results in confusion and makes the whole process error-prone for the end-users. Solution: The key used to internally identify the actual field needs to be enabled. Go to ‘Customize Local Layout’ in the SAP GUI and select ‘Options’ from the drop-down.

In the pop-up that opens-up go to the far right top corner and select ‘Expert’ from the drop-down. Make sure the two check-boxes (Show Keys in All Dropdown Lists” and “Sort Items by Key” are checked on

545

Apply and click OK. You can see the result in the drop-downs immediately – The Keys are enabled and sorted in alphabetic order.

Number Ranges for Trans. /Event type WL in year xxxx does not exist

546 When you try to do a PGI to an SAP Delivery, the following error message pops-up “Number Ranges for Trans. /Event type WL in year xxxx does not exist”

Solution: This problem occurs because the SAP goods movement number ranges were not extended for the fiscal period. Go to Tcode [OMBT] and open up the groups in it.

Select the group that contains the event type in question. In this case it is “WL” and hit enter.

547

Insert a new Interval for the fiscal year that does not exist. In this case, 2011 does not exist yet. So, create a new entry for the same in the number ranges and save the transaction.

Posting Period xxx 2011 is Not Open Not able to post invoices to Accounts because of the error “Posting Period xxx 20xx is NOT Open”

548

Solution: This problem needs to be corrected from the FICO configuration end. The transaction code to fix this is [OB52]

Select the account type, fiscal year variant and change the “To Period” to the current year, period. That’s it – you are done. Now, save it and go back to the invoice again and release it to accounting. SAP Material Master NOT defined for Sales Org distribution channel division Problem: “Material XXX is NOT defined for Sales Org, distribution channel, division”

549

Solution: There could be a couple of reasons for this, but the first check that should be done is to find out whether the material is actually created for the said sales organization, distribution channel and division. Go to the SAP Material Master, enter the material in question and hit enter. As you can see from the picture below, the Sales Org 1 and Sales Org 2 views are not even there. That is the reason why the system was throwing the error.

Start creating the Sales Org views of the material master as follows. Step 1: Go to material master creation (extension in this case) MM01 Step 2: Enter the material in question and hit enter. The Industry sector and Material type will already be selected (as created during the initial MM01 transaction)

550

Select the missing views (in this case Sales Org views) and then hit enter. Step 3: Enter the Sales org, Distribution channel and Plant.

Step 4: Fill the Sales Org Data as discussed in the SAP Material Master class. Now create the SAP sales order and it should work just fine for the respective Sales Area. SAP Material Account Determination Error

Problem: While posting stock or while performing PGI, have got the following problem with Material Account Determination. “Account Determination for entry INT GBB ____ ____ 3100 not possible”

551

Solution: This is purely an MM Configuration Step 1: Go to Transaction [OBYC] and select the Transaction GBB and double click.

Step 2: Enter the Chart of Accounts in the pop-up – In this case INT Step 3: The error was related to a missing entry for valuation class 3100. Let’s maintain an entry there and save it.

552

Now you can finish the transaction. Not able to create Customer Master for new Customer Account Groups in SAP Problem: Not able to create new Customers for newly created Customer Account Groups in SAP. For example, if you create a new Customer Account Group ZTES – Test Customer Account Group, you will have issues creating the Customer in the Sales Tab of the Sales Area of the Customer master.

Solution: This occurs because; when new Customer account groups are created the corresponding Partner Determination also needs to be done. To immediately fix this, you can just assign the partner determination procedure assigned to another Customer Account Group , sap 0001 soldto and assign it to the new Customer account group created. Step 1: Go to Transaction VOPAN (SAP Partner Determination) Step 2: Select Customer master in the radio buttons and then click on change.

553

Step 3: Identify the Partner Functions you need in the new customer account group ZTES and assign them by clicking on new entries.

If you get the warning message – choose the key from the allowed namespace, hit enter to ignore it. Step 4: Save it and go back and create the Customer master again. This time it will work.

Relationship between Programs and Transaction code in sap Problem: How to find out the transaction codes for some transactions in SPRO and also direct relationship between the transaction code and ABAP program associated with it. Solution: Typically, very few transactions under SPRO (Customizing) are remembered. And most of the times transaction codes do NOT exist for customizing transactions.

554

A transaction code is just a shortcut to execute an “executable” program. In order to find out the mapping between the transaction code and the program, go to tcode [SE93] and enter the name of the Transaction code to find out the name of the program. Enter the Transaction code as shown below and click on display.

The associated program will be displayed.

555

On the contrary if you want to find out the t-code associated with the program, there are a couple of methods (Like SE80 and then where used etc). The easiest method is to go to the database table TSTC. Enter the name of the Program and hit execute. (SAP Data Browser)

The associated transaction code (if any) will be displayed. As you can see, there are many transaction codes associated with the program SAP MV45A depending on the screen that is being called and the mode in which it is called.

556

Some examples in SD configuration transactions that are commonly referred by SAP consultants in real life are as follows. [VOK0] – Pricing Overview [VOPAN] – SAP Partner Determination [VOK2] – Output Overview [VOTXN] – SAP Text Determination [V/05] – Display Pricing Condition Tables [V/06] – SAP Pricing Condition Types [V/07] – SAP Pricing Access Sequences [V/08] – SAP Pricing Procedure [VKOA] – SAP Account Determination Exercises 1. List out the Program associated with Delivery Creation Transaction 2. List out the program associated with PGI Reversal 3. List out the transaction code associated with the program SAPMV80Z 4. List out some of the transaction codes associated with the program SAPMV50A

557 How to find out the menu path to Configure fields in SAP Many Consultants get confused with how to configure the menu path on how to configure certain fields in SAP. For example, in SAP Sales and Distribution, a field like “Delivery Block” in the SAP Sales Order is available. If a new Delivery block needs to be created, it can be very confusing to find out the exact menu path/transaction code in SAP for newbie’s.

Luckily, the solution is very easy. There are 2 ways to find out the menu path to a particular configuration. Solution 1: Go to SPROIMG and click on the “Find” button in the system tool bar. It is the button with a binocular icon.

The lists of Menu Paths that contain the keyword are displayed.

558

Double click on the one that you are looking for and it will take you directly to the menu area in SPRO. Solution 2: This is a more precise solution, but is only available in certain scenarios. Where available, use this solution. Hit F1 (or Help icon on the system toolbar) while highlighting the field in question. For example, if you want to find out the customizing menu path for the Customer Group in the Customer Master, then highlight the field and hit on F1.

Select the “Customizing” button as highlighted above. In the ensuing pop-up, click on “Continue without specifying Project” button.

559

SAP will automatically highlight the menu path for customizing the particular field.

Exercise: 1. Specify the menu path for how to configure “Material Group” in Basic View 1 of the Material Master 2. Specify the menu path in SPRO for how to configure “valuation Class” in Accounting view of the material master 3. Specify the menu path in SPRO for how to configure new “Terms of Payment” in billing view of the SAP Sales Order Header? No Schedule Lines Due for Delivery up to Selected Date Problem: This is one of the most common errors that newbie’s to SAP SD face when trying to create a delivery from a sales order

560

Solution: This problem could have 3 root causes. The first Reason is more straight forward and simple to solve – We will discuss all the reasons here and the solutions to each of these. Reason 1: This problem occurs when you are trying to create a delivery that the system is NOT ready to create yet. Here is an example. You just created an SAP Sales Order for M-01 for a quantity of 10. To understand this at a much greater level of detail, you would have to first understand what SAP Delivery Scheduling is. But let’s discuss how to just resolve it here. Since the delivery is not expected by SAP at this point in time, change the date to a future date. How far into the future? As far as SAP expects or any date beyond it. In order to find out that date, go to the SAP Sales Order’s ”Shipping” tab and check out the Delivery date – In this case its 15.07.2011

However, when you try to do the delivery and get the error message “No Schedule Lines due…” click on the back button, and future date the delivery. In this case change it from 06.07 to 15.07 and hit enter.

561

You should now be able to create the delivery as usual. Reason 2: This is a more serious problem and cannot be solved without either config changes or master data changes. Let me take this example that one of the students has provided.

562

Everything looks pretty innocent until this point. Now check out the Schedule lines associated with this line item.

563 As you can see, the confirmed qty is Zero. That means the system is not able to confirm the quantity either via procurement or via production. An alternative way to check it is via the Shipping Tab of the header where you should see the respective dates.

From the picture above, you can see that none of the dates were being calculated by SAP as part of the standard SAP delivery Scheduling Process. In order to understand the root cause for this, the first point to dig down to is the MRP type of the material (which in turn causes the SAP Schedule Line category to be determined). In order to do this, first check out the plant that this order has been created in (you can find it out at the line item level) and go to MM02 or MM03 to see what the MRP type is.

564

As you can see the MRP type is based on re-order point and the re-order point is 100. Now at that point, ideally MRP should be run which will ensure that the respective planned orders or purchase requisitions would be been created. Since this is a test system this did not happen and that’s the reason why the schedule lines could not show any confirmed qty at any date in the future. Reason 3: This could also occur because the Plant is not defined in the plant. Example, an order created for a new material shown below, does not have the Plant Determination –

565 Check here for the logic on SAP Plant Determination. Now, because of this reason – the system could not determine the stock and hence the schedule of dates and hence could not confirm schedule lines. And as discussed in the class you know the importance of schedule lines and the confirmation required there in order to be able to create a delivery. There are multiple ways to fix this problem as determined in SAP Plant Determination and the easiest way to do it is to set the plant up for the material master for the respective Sales Org views Reason 4: This is very similar to Reason 3 – Just a different set of changes at the material master level. As usual, stock is there in MMBE as shown below.

But still the order is being not confirmed at the schedule line level.

566 Again, check out if MRP type or Availability checking parameters (Checking Group) has been changed in the material master. I went to the change log and found out that the material has been changed for these parameters.

When I went inside I found out that the MRP type, reorder point and checking group of the material has been changed.

567 I tried changing the plant from 1000 to 1200 and it was able to confirm the schedule lines, but when I changed it back from 1200 to 1000, it gave me a message saying ” No Control Data Maintained for checking Group 04 and checking group A”

I immediately went to the Availability check controls [SPROIMGSales & distributionAvailability Check and Transfer of RequirementsAvailability Check Availability Check with ATP Logic Carry out Availability Check]

568 I found out that for the combination (Checking Group 04 and Checking rule A), there is no configuration available.

I did the configuration by copying from 01/A combination and VOILA!! The sales order for M-02 was created with confirmed schedule lines. Check out Order # 25182

569

What is SAP Transport Request? Transport Requests in SAP are the ONLY way in which you can record changes and move them across systems. Let’s take a simple example to understand this better. If you just want to quickly create a transport request in SAP, follow this link. If you want to understand a Transport request better, read through. Scenario: You have created a new Customer Group called ZA – Agency Customer by going through the following menu path in SPROSAP Reference IMG

570 The detailed steps to create this are available at How to create new Customer Groups in SAP. When trying to save the newly created customer group you get the following window. The fields Request and Short Description might be empty in your case. What does this mean and why is this being shown?

Solution: If you look at the “View Maintenance: Data...” field in the picture above, you can see some database table view V_T151. This is an internal SAP defined view which will contain a bunch of database tables that has been updated by this change. What this essentially means is that, the process of creating the new Customer Group “ZA” has resulted in a new database entry being created in the tables T151 (The view V_t151 consists of the database tables T151 and T151T as shown below)

Now, the database table T151 contains the new entries (for the new Customer Account group that you have created)

571

This example illustrates something very important. Most Customization requests are mere entries in some Internal SAP Database tables If some changes to the database are happening, it needs to be recorded. Why? In order to understand this you would have to understand the concept on SAP Landscape. To simplify things, let’s just say that if you need to move (“Transport”) the changes that you have done in a system to another system, (Instead of recreating them in the new system), you should let the source system record the changes. A “Transport Request” is SAP’s way of recording changes to the source system and generates a unique number for you so that you can just give that number to your SAP System Administrator (SAP Basis Consultant) and ask him to migrate the transport to the new system. Let’s say, the new Transport Request we have created is VANK900323 which is a unique number created by the SAP system.

572 These Transport Requests are a log of the database changes done due to some customizing (in this case, creation of a new customer group) and can be viewed in SE01

Click on Display to view all the Transport Requests you have created. The newly created Transport request VANK900323 has been highlighted below in red.

573

Let me take another example of SAP Product Hierarchy that I have created and saved using the SAP Transport Request Number VANK900319 (The one right above the highlighted one). Click on the folder button to the left of the Transport request to view the contents of the change.

574 As you can see, the views affected in this customization is V_T179 (which is tables T179 and T179T) and the database contents that have been changed are new entries being created as follows

It is exactly these entries that are being recorded in the Transport Request. Now you know the contents of a Transport Request, why transport requests are created, but who transfers these to the Target system? The Basis Consultant is responsible for this. When we discuss the SAP System Landscape, we will discuss more about this. Types of Transport Requests 1. Customizing Transport Request 2. Workbench Transport Request Material is not defined for Sales Org, distribution channel, language DE Problem: When trying to create orders for the materials you have created; sometimes you get the following error Material is not defined for Sales Org, distribution channel, language DE.

575

Solution: The solution to this problem lies in the fact that the material should also be defined in the language of the Sales Org. Go to the material master in change mode and click on “Additional Data”

576 And maintain the material in the language “DE” in case of sales org 1000/10/00

How to check the Account Postings associated with an SAP Delivery PGI Step 1: Locate the Delivery Document (Using the SAP Document Flow if required). If you want to see the postings related to PGI, please first ensure that the delivery document has been PGIed. You can find this from the doc flow. Here is an example.

Step 2: Select the GI Material document and click on “Display Document” button and you will be taken to the material document associated with the PGI.

577

Step 3: Click on Accounting Documents button and you will be shown all the accounting and controlling documents generated as a result of the PGI. Select the Accounting Document and either double click it or click on the magnifying glass button. You will see the COGS and Inventory Accounts.

578

th_popup This FM can be used to send a quick message to another user on any system in the landscape. This can be used when other users are locking certain transactions and not releasing them for a long time. Here are the steps. However, please use this judiciously and do NOT spam other users when not required. Step 1: Go to Txn [SE37]. Step 2: Enter TH_POPUP in the Function module and click on the Test button as shown below.

Step 3: Enter the client Number (In our case its 800, since this is an IDES client), user id that has locked your Txn and the Message. An example is shown below.

579

Result: The targeted user gets the message as shown below as a pop-up.

Number Ranges for SAP Transaction Type / Event WA in year does not exist

580 This error happens when you are working on a brand new installation of SAP. Although this is a MM Consultant’s job, SAP SD Consultants will also need to know this in case of system resets. This happens during all material movements (specifically PGIs, stock inputs etc as relevant for SD Consultant) and should be corrected ASAP. The solution lies in adding new number ranges for specific transaction types in OMBT. This could also be useful for other SAP Training students as well who are stuck with issues related to material movements. Another related post on closing material posting periods (MMPV) can be seen here. Step 1: Go to t code [OMBT] and click on “Groups”

Select the transaction type, in this case “WA” and click on the change icon

581

Since the number ranges are not maintained for 2011, choose EditInsert Year and then click on the “+” button

582 Scenario: At sales order we need to calculate Condition value for ZNOY condition Type as ZNOY-Condition Value = PR00-Condition Value * ZNOY-Amount Output

Step by step method to achieve this calculation. 1.

Go to Transaction VOFM

2.

Go to Formulas->Condition Value

3. Enter the Custom Routine Number 901 and the description. (Note: it is recommended that custom routine should start the 900-999 series)

583

4.

Take the Access Key for this object from Service Market Place

Give the Key & Press Continue

5. Place your cursor at start of ENDFORM. And press Insert.

584

6. Write Your Logic, Save & activate Data: lv_komv type komv. Read table xkomv into lv_komv with key kschl = 'PR00'. If sy-subrc ne 0. Xkomv-kinak = 'Z'. Exit. Else. Xkwert = (lv_komv-kwert * xkomv-kbetr) / 100. End if. 7. Activate the Routine as shown below.

8. Go to Pricing Procedures.

585

9. Select your pricing and double click on Control.

10. Attach your routine 901 against Cal Type for the condition type ZNOY.

11. Do run the report RV80HGEN at every client to activate the routine. 12. Go to Sales Order (VA01) and check the output. Prevent adding extra materials during the creation of Delivery

586 If you want the end users to create the delivery only for the items that are in the Sales Order and not any other material, do the following: Go to transaction OVLK.

Select the delivery type LF (as shown above) and double-click on the same.

587

Here change the field Item Requirement to 201, as shown below:

588

Now the users wouldn’t be able to add any material which is not available in the sales order. Order to Cash Cycle A customer orders some items from your company by creating a sales order (T codes: VA01, VA02, VA03, Tables: VBAK, VBAP etc). Your company decides to deliver the items ordered by the customer. This is recorded by creating an outbound delivery document (T Codes: VL01N, VL02N, VL03N, Tables: LIKP, LIPS etc). Once the items are available for sending to the customer, you post goods issue which reduces your inventory and puts the delivery in transit. This will create a material document. You will

589 post goods issue using VL02N but the material document created will be stored in tables MKPF, MSEG.

You will then create shipment document to actually ship the items. (T codes: VT01N, VT02N, VT03N, Tables: VTTK, VTTP etc). You finally create a sales billing document. (T Codes: VF01, VF02, VF03, Tables: VBRK, VBRP etc). This will have a corresponding accounting document created that will be in BKPF, BSEG tables. When customer pays to your invoice, it will directly hit your AR account in FI. You will have to remember that these are not a required sequence. Sometimes, you may configure your system to create a SD invoice as soon as you create a sales order or you may not create a shipping document at all. This is the position where Functional Consultant would come into picture and study the company's order to cash process and configure the SAP system to do so. Configuring credit card for the orders To implement the credit card functionality in SAP, do the following: Go to transaction VOV8.

590

Select the required order type and double-click on the same.

Scroll-down the window to find the following fields:

591

In the highlighted section above, we mention the payment type. In the "Paymt card plan type" select the value "03 (Payment card)" or use F4 functionality to select the same. Here are the F4 values:

In the checking group, enter the value "01(Standard)".

592 Extending/Reducing the credit limit for a specific period Go to transaction OVA8. Select the required record and click on “Change”. Following screen appears:

As noticed in the above screen, we can maintain the percentage by which the credit limit should be either extended/reduced and also can provide the period for which it is applicable. Following is the F1 help screenshot of the same:

593

Following is the screenshot after entering some values in the “Credit Limit Seasonal Factor”:

Maintaining Shipping instructions Shipment Instructions are used to instruct the carriers or forwarders or drivers anybody who actually would be shipping your goods from your warehouse to the customer's site. These instructions could be asking the driver to handle the goods with care or might be instructing him to make sure the delivery is at the customer premises by so and so date and time or once the delivery is handed over to the customer taking a receipt signature from the customer. Example if you order something from a store, after the goods are shipped to you the driver takes a signature on a receipt note or collects the check or cash form you or takes the inspection done signature, this is the shipping instructions for the driver.

594 Shipping instructions are maintained in the delivery document itself (Transaction VL01N). In the delivery document, click on GOTO-->Header-->Text

Here we can maintain the shipping instructions. MRP: PR to PO Conversion Go to Transaction SU3 and under Parameters Tab find the Parameter ID "EVO" and check if any value is assigned. If so, make a note of the value. Now go to transaction SPRO Click on SAP Reference IMGMaterial ManagementConsumption-Based PlanningProcurement ProposalsDefine Conversion of Purchase Requisition into Purchase Order (as shown below)

595

Following screen appears:

Check for the value we have noted earlier (the value of the parameter EVO in SU3). Select the read and check the check boxes appropriately. We have to select at least one of the check boxes from RefPRs or A/P PR to have all items copied to PO. Please use the F1 help for detailed information on the check boxes.

Special Processing Indicator The Special Processing Indicator defines the mode of shipment to be used for an order and applies the corresponding shipping costs based on the mode used. Express shipping or special tariffs are forms of special processing. Following is the process of defining “Special Processing Indicator”: Go to transaction SPROIMGLogistics ExecutionTransportationDefine Special Processing Indicator

596

Following screen appears:

Click on New entries. Add a Special Processing Indicator.

Save your entries. All entries regarding the “Special Processing Indicator” are stored in the table TVSAK and the texts for the same are stored in the table TVSAKT. Following is the procedure to set the “Special Processing Indicator” in the Sales Order:

597 Open any of the available Sales Order (Transaction VA02):

Click on “Display doc. Header details” (highlighted above):

Click on the tab “Shipping”

598

Enter the value in the field “Special Processing Indicator”:

This value is stored in the field SDABW of VBAK table.

599

Automatic Printing of a Sales Order Document immediately after saving the document in VA01 This scenario shows how to print a document whenever a sales order from VA01 is created immediately after saving the application. Before that we need to maintain the configuration in the NACE transaction. Step 1: Go to transaction NACE and select the application V1.This is a standard application to confirm the sales order.

Step 2: Click on condition records. a) It is used to set the values to process the output type based on the Business rule. The following screen will appear.

600

b) Double click on the BA00. The following screen will appear. Select the any one key combination based on the business rule. For example, if you want process the appropriate output by giving the Sales Organization, Distribution channel, Division and customer then select the first one. This means it processes the output only when the values found with this combination.

c) Set the values and click on Execute/F8 button. Consider the values according your database.

601

d) Provide the customer and partner details and in the Medium click on F4 help. You can see the list of available mediums. Select the medium 1 i.e. print output. In date/time filed click on F4 help and select time 4(Send immediately when saving the application). If we don’t select this option it won’t process the output immediately when saving the application. Maintain the language also.

e) Now click on Communications button to set the printer properties. Maintain your own printer settings and don’t forget to check the field ‘Print Immediately’.

602

The configuration to print the document automatically when saving the application is completed. Step 3: In order to process the output type we require programs and forms. The programs and forms to process the output are readily available in SAP system. There are some standard programs and forms are pre configured in the NACE transaction. a) Go to NACE, select V1 and click on ‘Output Types’.

603 b) Select BA00 and double click on ‘Processing Routines’.

The following screen will appear. Here we can find programs and corresponding forms to process the outputs for different mediums. As per our requirement the corresponding program and forms are preconfigured in the Print output Medium. If we want make our own Z program and Z form, simple just replace it in the corresponding fields in the Print Medium.

604 Step 4: Now go to transaction VA01. Give the values we mentioned in the condition records and press enter. Order type

: OR

Sales Organization : 0001 Distribution Channel:

01

Division

01

:

a) Enter the sold-to-party or customer as 1000 and enter the Item details.

605

Once the data is entered click on save button. Now the document will automatically print the document. Before that if you want to check the configured output type. Follow the steps. b) Go to transaction VA02 and enter the created sales order number.

Now Go to Extras OutputHeader-Edit. The following screen will appear.

606

Here we can see two types of statuses. The Yellow color indicates that it is ready to process. It will automatically come into the picture because we configured the values in NACE transaction. Whenever system found these values (0001, 01, 01, 1000) it will automatically process the above output. We need not to give the output parameters every time the document is to be printed. The Green color indicates that the document is successfully processed. c) Select Back button and click on SAVE. The document will automatically go to the printer. Now you can collect the document from the printer. Output:

607

Configuration steps for automatic packaging Automatic packing has some typical configuration and master data settings, see below: 1. Maintain number ranges for handling units, menu path SPRO  Logistics Execution  Shipping  Packing  Define number ranges for Handling Units. 2. Delivery type should be activated with Automatic Packing, menu path SPRO  Logistics Execution  shipping  Deliveries  define delivery types

608

Define packaging material types Menu Path SPRO  Logistics Execution  Shipping  Packing  Define packaging material types.

4. Define material groups for packaging materials, menu path: SPRO  Logistics Execution  Shipping  Packing  Define material groups for packaging materials.

609

Define allowed packaging materials, menu path: SPRO  Logistics Execution  Shipping  Packing  Define allowed packaging materials.

Along with these basic settings we also need to configure in handling unit management module for automatic packing. 6. Maintain packing transaction profile, menu path: SPRO  Logistics General  Handling Units Management  Automatic Packing  Maintain packing transaction profile. “T code: OVHU2” Select the transaction profile “0002 – Outbound Delivery” and go for details. Check “start automatically” in the details screen as shown below.

610

Also maintain the determination procedure for packing instructions as shown in the above screen. 7. Determination procedure for Packing Instructions. Menu path SPRO  Logistics General  Handling Units Management  Automatic Packing  determination of packing instructions. Handling units work based on the condition technique, configure all necessary config settings for condition technique to work appropriately. I used the procedure as “ZAU001 - Auto Pack Ref Material” and determination type as “ZSHP - Auto Packing Ref Mat”

Access sequence that I used is ZSHP with a condition table “499 - Reference material for materials packed in same way” 8. Maintain the master data for the packing instructions “t code: POP1”, menu path: SAP Easy Access  Logistics  Central functions  Handling Unit Management  Master data  Packing Instructions  Create/change/display. 9. Further maintain packing instruction determination record. “T code: POF1”, Menu path: SAP Easy Access  Logistics  Central functions  Handling Unit Management  Master data  packing instruction determination record  create/change/display. 10. Final master data settings need to be done in material master data under basic data tab and plant/general data tab for finished goods and also for packaging materials. These are the 10 important steps to configure automatic packing during delivery processing.

611 Configuration steps for automatic picking Automatic picking happens with an output type “WMTA” - Automatic TA, we need to maintain an output condition record using t code: VV21. Configuration steps for automatic picking.... WM should be active at delivery item level, t code: OVLP. Check “relevant for picking”.

2. To trigger WM transfer order in the delivery document we need one more config step in the IMG, for this go to SPRO  Enterprise Structure  Assignment  Logistics Execution  Assign warehouse number to plant/storage location.

612 3. Along with these settings we also need WM consultants to configure the WM settings. This includes the settings related to lean WM or central WM. 4. Number range for pick order should be maintained, for this go to  SPRO  Logistics Execution  Shipping  Picking  Define number ranges for pick order. 5. Assign the output procedure for the delivery type, t code: v/71, or SPRO  Logistics Execution  Shipping  Basic shipping functions  Output control  output determination  maintain output determination for outbound deliveries  Assign output determination procedures.

6. During maintaining a condition record for WMTA output type you can have any key combination as per the business requirement. In this system I have selected a key combination of Delivery type and shipping conditions.

Maintain the medium as “8 – Special function” and dispatch time as “4 – Send immediately” This concludes the configuration and master data maintenance for automatic picking. Can Sales Order and Billing Have Different Pricing?

613 Yes, can have 2 different pricing procedures 1. One for Sales Order 2. Another at the Billing Let us take an example: Generally in the Pharmacy industry this procedure is adopted because all the goods are batch price based. 1. In the Pharmacy Industry whenever the goods are manufactured it will done in a batch to keep track and price is fixed, I mean there will be a Batch Master which has a certain price fixed for it. This Batch Master will have certain number of batches. These batches will have the number series generated wither by internal or external generation depending upon the client requirement 2. So till all the batches are produced as per that particular Batch Master will have the same price. Like that there will n number of batches will different prices 3. So when you are preparing Sales Order you be only putting the tentative price for the goods that are sold 4. Then at the time of delivery we will be picking up the goods from different batches basing on the required delivery quantity and finally we do the PGI. 5. This is called Delivery Based Pricing because your price for the goods will be determined at the time of the delivery as the goods picked up from the different batches which have different prices. (Mind it there will very less difference in the prices). 6. So at the time of Billing the Pricing Procedure behaves differently depending upon the different batches that are picked basing on the batch determination. 7. So the prices which are determined from different batches will be the actual prices at which the goods are billed to the customer along with other condition that are applied as required.