You are on page 1of 124

TASD41 Sales and Distribution Appendices TASD41

R/3 System Release 46B 06/29/2000

TASD41 Sales and Distribution - Appendices

TASD41
Sales & Distribution Appendices
SAP AG 1999

System R/3, Sales and Distribution - Appendices Release 4.6B April 2000 Material number 50037387

Copyright

Copyright 2000 SAP AG. All rights reserved. Neither this training manual nor any part thereof may be copied or reproduced in any form or by any means, or translated into another language, without the prior consent of SAP AG. The information contained in this document is subject to change and supplement without prior notice. All rights reserved.

SAP AG 1999

Trademarks: Microsoft , Windows , NT , PowerPoint , WinWord , Excel , Project , SQL-Server , Multimedia Viewer , Video for Windows , Internet Explorer , NetShow , and HTML Help are registered trademarks of Microsoft Corporation. Lotus ScreenCam is a registered trademark of Lotus Development Corporation. Vivo and VivoActive are registered trademarks of RealNetworks, Inc. ARIS Toolset is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrcken Adobe and Acrobat are registered trademarks of Adobe Systems Inc. TouchSend Index is a registered trademark of TouchSend Corporation. Visio is a registered trademark of Visio Corporation. IBM , OS/2 , DB2/6000 and AIX are a registered trademark of IBM Corporation. Indeo is a registered trademark of Intel Corporation. Netscape Navigator , and Netscape Communicator are registered trademarks of Netscape Communications, Inc. OSF/Motif is a registered trademark of Open Software Foundation. ORACLE is a registered trademark of ORACLE Corporation, California, USA. INFORMIX -OnLine for SAP is a registered trademark of Informix Software Incorporated. UNIX and X/Open are registered trademarks of SCO Santa Cruz Operation. ADABAS is a registered trademark of Software AG

The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2, R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript, SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included herein are also trademarks or registered trademarks of SAP AG. Other products, services, logos, or brand names included herein are trademarks or registered trademarks of their respective owners.

Appendices

SAP AG 1999

(C) SAP AG

TASD41

1-1

Appendix

This unit contains extra materials to be used for reference purposes This material is not part of the standard course Therefore the material might not be used during the course

SAP AG 1999

(C) SAP AG

TASD41

1-2

Content: Appendix

User Roles Frequently Used Menu Paths Table Structures Special Sales Special Pricing

Special Shipping Special Billing Special Transportation Special Credit/Risk Management Overview Standard Courses

SAP AG 1999

(C) SAP AG

TASD41

1-3

User Roles for SD (Sales and Distribution)

Sales manager Sales representative Personal responsible in sales order processing Personal responsible in invoice processing

SAP AG 1999

In order that SAP users can work with user-specific and workplace-related menus, the above user roles are already defined for Sales and Distribution.

(C) SAP AG

TASD41

1-4

User Roles for LE (Logistics Execution)

Shipping manager Person responsible for shipping Person responsible for transportation Shipment costs accounts payable clerk Shipment costs manager Transportation manager Transportation planner Person responsible for warehouse management Warehouse manager Warehouse worker

SAP AG 1999

In order that SAP users can work with user-specific and workplace-related menus, the above user roles are already defined for Sales and Distribution.

(C) SAP AG

TASD41

1-5

Frequently Used Menu Paths

Activity

Menu path

Master data

Sales and distribution Logistics Master data


Display sold-to party Display material Display bill of material Business partner Display Customer

Products Material Other material Display Products Bills of Material Material Material BOM Display Conditions Display Output Sales document Display Bill of

Display condition records (prices, discounts/surcharges, free goods, etc.) Display output master records Customer-Material-Information

Agreements Customer-Material Info Display

Order processing
Create/change/display order Create/change/display inquiry Create/change/display quotation Create/change/display scheduling agreement Create/change/display contract Display list of orders Display list of incomplete orders

Logistics Sales
Order

Sales and distribution

Create/Change/Display Inquiry Create/Change/Display Quotation Create/Change/Display Scheduling agreement Create/Change/Display Contract Create/Change/Display Information system of sales documents Information system incomplete orders Orders Orders List List of

(C) SAP AG

TASD41

1-6

Shipping

Sales and distribution Logistics Shipping and Transportation


Create/change/display delivery Create transfer order Post goods issue Outbound delivery Create/Change/Display Picking Create transfer order Single Document Post goods issue Outb. delivery Single Document

Billing

Logistics Billing
Create/change/display billing document Display financial accounting documents

Sales and distribution

Billing document Create/Change/Display Billing document Display overview Accounting

(C) SAP AG

TASD41

1-7

Customizing

Access

AcceleratedSAP Tools Customizing Project editing Display SAP Reference IMG

Define organizational units


Maintain sales organization

Enterprise structure Definition


Sales and Distribution Define sales organization ... Define, copy, delete, check Sales Organization Sales and Distribution Define distribution channel ... Define, copy, delete, check distribution channel Logistics - General Define division ... Define, copy, delete, check division Sales and Distribution office Sales and Distribution office Maintain sales Maintain sales

Maintain distribution channel

Maintain division

Maintain sales office Maintain sales group

Assign organizational units


Sales organization Company code

Enterprise structure Assignment

Sales and Distribution Sales Organization - Assign sales organization to company code Sales and Distribution Assign distribution channel to sales organization Sales and Distribution to sales organization Sales and Distribution area Assign division Set up sales

Sales organization Distribution channel

Sales organization Division Sales area

(C) SAP AG

TASD41

1-8

Sales area Sales office Sales office Sales group

Sales and Distribution Sales area

Sales office

Sales and Distribution Sales group - Assign sales office to sales group Sales and Distribution Assign sales Organization - Distribution channel plant

Sales organization distribution channel Plant

Master data
Common distribution channels Common divisions Maintain account group

Sales and Distribution Master data Define common distribution channels Sales and Distribution Master data Define common divisions Logistics General Business Partner Customers Control Define account groups and field selection for customers Logistics General Material master Basic settings Material types Define attributes of material types

Maintain material type

Basic functions
Define pricing procedure Define free goods procedure Define output

Sales and Distribution Functions


Pricing Pricing Control

Basic

Free Goods Condition Technique for Free Goods Output Control Output Determination Output Determination using Condition Technique ... Material Determination Listing/Exclusion ... ...

Define material determination procedure Define listing/exclusion procedure Partner determination Incompletion procedure

Partner determination Incompletion ...

Sales document control


Define sales document types Restrict sales document types to organizational units (C) SAP AG TASD41

Sales and distribution Sales documents

Sales

Header

Sales document header Define sales document types Sales document header Assign sales area to sales document types 1-9

Item

Define item category Assign item category

Sales document item categories Sales document item categories Schedule lines categories Schedule lines categories

Define item Assign item

Schedule line

Define schedule line categories Assign schedule line categories

Define schedule line Assign schedule line

Copying control Contracts


Define value contracts Define contract data

Sales and Distribution Sales Maintain copying control for sales documents Contracts Contracts Value contracts Contract data ... ...

Shipping
Determine shipping points Document control in shipping Set up delivery blocks Lean WM

Logistics Execution

Shipping

Basic Shipping Functions Shipping and Goods Receiving Point Determination Deliveries ...

Deliveries Define reasons for blocking in Shipping Picking Lean WM ...

Billing

Sales and Distribution

Billing

Define billing document types Set up billing blocks Copying control for billing documents

Billing documents Billing documents reasons in Billing

Define billing types Define blocking

Billing documents Maintain copying control for billing documents

Maintain requirements and forms

Sales and Distribution Modification Routines ...

System

(C) SAP AG

TASD41

1-10

(C) SAP AG

TASD41

1-11

Table Structure for Customers - SD View

KNA1

KNVK

KNVV

KNVA

KNVI

KNVS

KNVP

KNVD

KNVL

SAP AG 1999

These tables contain the following information: KNA1: KNVK: KNVV: KNVA: KNVI: KNVP: KNVD: KNVL: KNVS: Customer master, general information Contact person Customer master, sales area Unloading points Tax indicators Partner functions Documents Licenses Shipping data

Logical databank for customer master: DD F: Customer database

(C) SAP AG

TASD41

1-12

Table Structure for Customer Hierarchies

KNVH

SAP AG 1999

This table contains customer hierarchies. You create customer hierarchy nodes as customer master data.

(C) SAP AG

TASD41

1-13

Table Structure for Materials

MARA

MAKT

MARM

MVKE

MLAN

MAEX

MCH1

MARC

MBEW

MLGN

MVER

MAPR

MCHA

MARD

MLGT

MCHB
SAP AG 1999

These tables contain the following information: MARA: MAKT: MARM: MVKE: MLAN: MAEX: MARC: MBEW: MLGN: MLGT: MVER: MAPR: MARD: MCH1: MCHA: MCHB: General material data Short texts Conversion factors Sales data (for each sales organization and distribution channel) Sales data (for each country) Export licenses Plant data Valuation data Warehouse management inventory data Warehouse management inventory type data Consumption data Pointers for forecast data Storage location data Cross-plant batches Batches Batch stocks

Logical databank for material master: CKM: MSM: (C) SAP AG Material master Material master TASD41 1-14

Table Structure for Customer - Material Information

KNMTK

KNMT

SAP AG 1999

These tables contain the following information: KNMTK: Header table for increased performance KNMT: Data table

(C) SAP AG

TASD41

1-15

Table Structure for Bills of Material

MAST

EQST

KDST

DOST

STST

TPST

STKO

STZU

STAS

STPO

STPU
SAP AG 1999

These tables contain the following information: MAST EQST KDST DOST STST TPST STKO STZU STAS STPO STPU Material assignment to BOM Equipment assignment to BOM Sales order assignment to BOM Document assignment to BOM Standard object assignment to BOM Functional location assignment to BOM BOM header data Time-independent STL data BOM item selection BOM item data BOM sub-item data

(C) SAP AG

TASD41

1-16

Table Structure for Sales Activities

VBUK

VBKA

VBUV

VBPA

NAST

STXH

SADR

STXL

VBFA

SAP AG 1999

These tables contain the following information: VBUK: VBKA VBUV: VBPA: SADR: VBFA: NAST: STXH: STXL: Header status and administrative data Sales activity Incompletion log SD document: Partner Address SD document flows Output Texts: Header Texts: Lines

Logical database: AK V: Sales documents

(C) SAP AG

TASD41

1-17

Sales Document Tables - Header

VBUK Header status VMVA Matchcodes STXH/STXL Texts NAST Output PP-Status JSTO

VBAK Header

VBKD Business data VEDA Contract VEPA Partners VAKPA Partner indexes VBUV Incompletion VBFA Document flows

SAP AG 1999

These tables contain the following information: VBUK: VBAK: VBKD: VAKPA: VEDA: VBPA: VBUV: VBFA: VMVA: STXH: STXL: NAST: JSTO: Header status and administrative data Sales document: Header data Sales document: Business Data Partner index Contract Partner Incompletion log SD document flows Matchcodes Texts: Header Texts: Lines Output PP status

(C) SAP AG

TASD41

1-18

Sales Document Tables - Item

VBUP Status VAPMA Material index VEPVG Shipping index VMVA Matchcodes STXH/STXL Texts NAST Output CO object KONV Conditions
SAP AG 1999

VBAP Item

VBKD Business data VEDA Contract VBLB Forecast dlv. sched. VBEP Settings VBBE/S Requirements

Variants Technical objects Services

VBUV Incompletion VBFA Document flows VBPA Partners JSTO PP status

These tables contain the following information: VBUP: VBAP: VBKD: VEBA: VBLB: VBEP: VBBE: VBBS: VBUV: VBFA: VBPA: JSTO: NAST: STXH: STXL: KONV: Item status Sales document: Item data Sales document: Business Data Contract Forecast delivery schedules Sales document: Schedule line Individual requirements Summarized requirements Incompletion log SD document flows Partner PP status Output Texts: Header Texts: Lines Conditions

(C) SAP AG

TASD41

1-19

Section: Sales

SAP AG 1999

(C) SAP AG

TASD41

2-1

Order Processing
SD
SO Sales Order
Sold-To Party: C1 Payer: C3 Ship-To Party: C2 Bill-To Party: C3 Net Value 1500.Conf. Qty 0 7 8 Net Value 250.Conf. Qty 0 5

LF Delivery
Ship-To Party: C2 Delivery Date: Picking Date Loading Date: Release Date: Pos. 10 20 MatNo. M1 M2 29.08.99 20.08.99 21.08.99 22.08.99 Del.Qty 7 5 Pick-Qty 7 5 Payer: C3 Invoice Date: Pos. 10 20 MatNo. M1 M2

F2 Invoice
Bill-To Party: C3 22.08.99 Inv.Qty 7 5 Net Value 700.250.--------------950.95.======== 1045.-

Pos. MatNo. Qty Req.Date 10 M1 15 20.08.99 [Unit Cost (VPRS) = 70.-/Pc ] SL-No. 1 2 3 SL-Date 20.08.99 29.08.99 15.09.99 Order Qty 15 0 0

Total Net: + Taxes 10% Total:

Pos. MatNo. Qty Req.Date 20 M2 5 20.08.99 [VPRS = 30.-/Stk ] SL-No. SL-Date 1 20.08.99 2 29.08.99 Order Qty 5 0

Transfer Order

Picking

From: Storage 005 To: Storage 916

MM-WM: Warehouse Management

MM
Goods-Issue. Document

Goods-Issue

FI
Assets Docmt 2 1 Account Bank Accounts Receivable Inventories Debit 1045

MatNo Qty M1 7 M2 5

MvTyp 601 601

MM-IM: Inventory Management

BALANCE-SHEET
Liabilities Credit Docmt 2 640 Account Accounts Payable Taxes Payable 10% Stockholder Equity Debit Credit 95

Accnting Docmnt
WL Goods-Issue

PROFIT AND LOSS STATEMENT


Expenses Docmt 1 Account Inventory Change Debit 640 Credit Docmt 2 Income Account Sales Rev. (Domestic) Sales Rev. (Foreign) Rebates Rev. Freight Charges Debit Credit 950

FI
Accnting Docmnt
RV Customer Invoice

SAP AG 1999

(C) SAP AG

TASD41

2-2

Make-To-Order Flow
SD Order
Customer cust. reqmts

MM / PP Materials planning

Production Delivery

Goods receipt Goods issue


Reduced sales order stock

Sales order stock

Billing
SAP AG 1999

Make-to-order production is characterized by the fact that materials are not stored in the warehouse but produced especially for a particular sales order. An individual customer requirement is generated from the sales order item and transferred to materials planning (PP). You can use materials planning to plan requirements. Once this has been done, production is carried out. After the product has been manufactured, you post it by goods receipt to sales orders stock speicifcally for this sales order item. As soon as the delivery is due, you can enter the delivery in SD and post goods issue. This reduces the sales order stock. Then you enter a billing document in SD.

(C) SAP AG

TASD41

2-3

Make-To-Order Production without Assembly Processing

Other sales requirements Sales order K

MRP run Dependant requirements breakdown

Planned order Plan

Quantity, date

Production order

SAP AG 1999

The requirement quantity (planned independent requirements), delivery date and configuration specifications are transferred from the sales order to materials planning (PP) as an individual customer requirement. You then use a planning run to generate a planned order. Here, bills of material are exploded and dependent requirements for the assemblies and components are generated. As soon as production can start, you create a production order from the planned order. The system returns the confirmed quantity and delivery date from the production order to the sales order.

(C) SAP AG

TASD41

2-4

Make-To-Order Production with Assembly Processing

Sales order K

Production order Quantity, date

SAP AG 1999

The individual components for the final product have already been produced for make-to-order production with assembly production. You then only need to assemble the components according to the customer's wishes. This means you just need a one-level bill of material explosion and you do not need to generate dependent requirements. This means that you do not need a planning run at this point for make-to-order production with assembly processing. You can create a production order directly from the sales order. The system returns the confirmed quantity and delivery date from the production order to the schedule lines in the sales order. Any changes made to the confirmed schedule lines or the delivery date are immediately visible in the sales order and/or in the production order.

(C) SAP AG

TASD41

2-5

Item Category Determination in the Standard Order

Material master
Material 1400-200 Item category group NORM

Standard order
Sold-to party 2300

Item

Material

Item Category Normal item TAN Make-to-order prod. TAK

10 1400-200 120 1400-700

Material master
Material 1400-700 Item category group 0001

SAP AG 1999

The item category in the sales document is found using the sales document type and the item category group from the material master. The item category group is maintained in the material master on the sales and distribution tab page: in the Sales Org. Data 2. Another item category than that for a material with item category group 0001 is found for a material with the item category group Norm.

(C) SAP AG

TASD41

2-6

Cost Management by Item

CO object for Sales order item Pricing Sales order Bill. document Plan. rev. Plan. costs Act. rev. Act. costs Costing Material samples Production order(s) Settlement

CO-PA Profitability analysis


SAP AG 1999

In sales order processing, the costs and sales revenue for a sales order item are collected in a controlling object for that item and settled in a profitability analysis. Pricing in the sales order determines the planned sales revenues (net value 2) and the actual sales revenue is posted in the billing document. The planned costs are compared to the revenues. They arise from product or unit costing, or from the valuation price in the material master (standard price or moving average price). The actual costs are calculated from the withdrawal, production orders, internal activity allocation and surcharges. The accrued actual sales revenues and costs are settled in the CO-PA Profitability Analysis in order to determine the profit or loss.

(C) SAP AG

TASD41

2-7

Outbound Delivery from Sales Order Stock

Outbound del.
Ship-to party 2300

Stock
Material 1400-700 Quant. Del. 1 unit Goods issue Material 1400-700 Sales order stock 0 unit

Goods issue for outbound delivery of an individually made material reduces the sales order stock. stock.

SAP AG 1999

After Production has finished making the material, goods receipt is posted in the sales order stock. Sales order stock is special stock, which can only be used for a specific sales order. After goods issue for outbound delivery, the sales order stock is reduced accordingly.

(C) SAP AG

TASD41

2-8

Section: Pricing

SAP AG 1999

(C) SAP AG

TASD41

3-1

Special Condition Types

Contents:
Manual order value HM00 Net Price PN00 Minimum order value AMIW, AMIZ Minimum price PMIN Interval price PR02 Hierarchy discount HI01 Pallet discounts KP00, KP01, KP02, KP03 Rounding DIFF

SAP AG 1999

(C) SAP AG

TASD41

3-2

Special Condition Types: Course Objectives

At the conclusion of this unit, you will be able to: Enter order values and net prices manually Set a minimum price for a material or a minimum value for an order Set interval scales for conditions Use customer hierarchies for price agreements See the effect of condition formulas Round final amounts

SAP AG 1999

(C) SAP AG

TASD41

3-3

Manual Order Value HM00

Header PR00 Price 4000 deactivated!

HM00 Order value

3900

Item 1 Net item value 1000 Net value 975

Item 2

deactivated!

Net item value 3000 Net value 2925

SAP AG 1999

A condition exists in the standard version, which allows you to enter the order value manually. The difference between the old and the new order value is distributed between the items (taking into account the net item value). Taxes are redetermined for each item.

(C) SAP AG

TASD41

3-4

Net Price PN00

Order
Item 1 PR00 K007 PN00 ... M1 Price 1 piece 1600

deactivated!
Customer discount 160 Net price Net item value ... 1300 1300

SAP AG 1999

The PN00 condition in the standard system allows you to specify the net price for an item manually. The original conditions are deactivated.

(C) SAP AG

TASD41

3-5

Minimum Order Values AMIW and AMIZ

Condition record AMIW


Price group 02 DM 200

Order header
Customer C1 Net item value AMIW AMIZ Net value Price group 02 160 200 40 200

Item 10
Net item value AMIW AMIZ Net value
SAP AG 1999

Item 20
100 125 25 125 75 15 Net item value AMIW AMIZ Net value 60 75 15 75 75 15

You may create a minimum value for each order using condition type AMIW. If the value in the order header falls short of this minimum order value during pricing, the system will copy it as the net order value automatically. The minimum order value is a statistical condition. Condition type AMIW is a group condition and is divided among the different items according to value. Calculation formula 13 is assigned to condition type AMIZ in the pricing procedure. This calculates the minimum value surcharge by subtracting the net item value from minimum order value AMIW.

(C) SAP AG

TASD41

3-6

Minimum Price PMIN

Condition record PMIN


Material M1 1500

Order
Item 1 PR00 M1 Price 1 piece 1600 16060 1500

K007 Customer discount PMIN Minimum price Net item value


SAP AG 1999

You can create a minimum price for a material using condition type PMIN. If the minimum price is not met during pricing, the system determines the difference using condition type PMIN.

(C) SAP AG

TASD41

3-7

Interval Price PR02

Condition record PR02


Customer C1 to 10 pieces 20 pieces 9999999 pieces Material M1 $ 5/piece $ 4/piece $ 3/piece

Order
Customer C1 Item 10: M1 25 pc $ 50 $ 40 $ 15 $ 105

PR02 $ 5/piece PR02 $ 4/piece PR02 $ 3/piece Net item value $ 4.20/piece

SAP AG 1999

You can maintain condition records with interval scales if the condition type is set to scale type D in Customizing. Interval scales cannot be used for group conditions.

(C) SAP AG

TASD41

3-8

Customer Hierarchy
Miller Head office 8000 Miller South 8200
Customer 2742

Unique node number

Miller North 8100 Miller Central 8120


Customer 2743 Customer 2744

Miller North east 8110

SAP AG 1999

Customer hierarchies are available in Sales and Distribution, so that you can create flexible hierarchies to reflect the structure of customer organizations. If your customer base includes multilevel buying groups, cooperatives, or chains of retail outlets, for example, you can create hierarchies to reflect the structure of these groups. Use customer hierarchies during sales order processing and billing for determining pricing and running statistics. A customer hierarchy consists of nodes. To create a customer hierarchy: 1. 2. 3. Create master records for each node. Assign the nodes to each other. Assign the customer master records to the relevant nodes.

Hierarchy nodes are only valid for a certain period of time. They may also be moved. If a node is moved, the system automatically reassigns all related nodes and customer master records.

(C) SAP AG

TASD41

3-9

Hierarchy Path
Hierarchy path Miller Organizational Organizational data data Head office 8000 1000 10 00
Sold-to party: 2743 Node/ customer 8000 8100 8120 2743 Hierarchy step Top level Second level Third level Fourth level Partner functions 1D 1C 1B AG

Pricing X

Miller South 8200 1000 Pricing Customer 2742 Customer 2742 Miller Central 8120 1000 Pricing
SAP AG 1999

Miller North 8100 00 1000 10 00 Pricing X Miller North east 8110 00 1000 10 00 Pricing X Customer 2744 Customer 2744

10

10

Customer 2743 Customer 2743

With customer hierarchies, you can assign price or rebate agreements to a higher level node. The agreements are then valid for customers at all subordinate levels to this node. You can create pricing condition records for each node indicated as relevant for pricing. If one or more nodes in the hierarchy path of a sales order contain pricing information, the system takes them into account automatically during pricing. The customer hierarchy above represents the multi-level buying group Miller. The headquarters, Miller Head office, is the highest node defined in the hierarchy. The southern, northern, central and northeastern regional offices are also defined as nodes. A price agreement is reached with the Miller buying group for a particular product line. You offer a discount valid for all regions and offices in the buying group. In addition, you grant a promotional discount for Miller North. You create the appropriate condition records for the Miller Head office and Northern nodes. An order for customer 2742 is received and granted the cross-regional discount. When you receive orders from customers 2743 and 2744, however, the system uses the pricing data stored for Miller North and grants the exclusive promotional discount.

(C) SAP AG

TASD41

3-10

Hierarchy Discount HI01

Condition record HI01


Hierarchy: 8000 Miller Head office 8100 Miller North 5- % 8- %

Order
Customer 2743 Item 10: M1 10 pc PR00 HI01 ... Price Discount $ 100 8- %

SAP AG 1999

Customer 2743 belongs to the Miller northern office. This is why a discount of 8% has been assigned. In the standard system, the access sequence is set in Customizing so that the discount is initiated at the lowest hierarchy level.

(C) SAP AG

TASD41

3-11

Pallet Discount KP00 Order 1


Material M1 50 CAR $ 5Condition record KP00 $ 5Discount per pallet

Order 2
Material M1 100 CAR $ 10-

+
Material master M1 50 CAR ^ 1 pallet =

Order 3
Material M1 70 CAR $ 5-

SAP AG 1999

The pallet discount grants the customer a discount for whole units of measure only. For example, a complete pallet. This is controlled by basic formula 22 in the pricing procedure, which only takes the number of complete pallets into account.

(C) SAP AG

TASD41

3-12

Incomplete Pallet Surcharge KP01

Order 1
Material M1 50 CAR Condition record KP01 $ 50 per pallet

+
Order 2
Material M1 70 CAR $ 50 Material master M1 50 CAR ^ 1 pallet =

SAP AG 1999

In this case, the customer pays a surcharge for an incomplete pallet. This is controlled in basic formula 24 in the pricing procedure, which tests the quantity for a fractional portion.

(C) SAP AG

TASD41

3-13

Mixed Pallet Discount KP02

Order 1
Header: KP02 $ 10M1 M2 20 CAR 30 CAR Condition record KP02 from 1 pal from 2 pal $ 10$ 20-

+
Order 2
Header: KP02 $ 10M1 M2 20 CAR 40 CAR Material master M1, M2 50 CAR ^ 1 pallet =

SAP AG 1999

The mixed pallet discount accumulates the quantities of the individual items, then calculates the discount for complete pallets only. This is controlled by condition type KP02 (group condition = X, unit of measure = PAL) and the corresponding condition record.

(C) SAP AG

TASD41

3-14

Surcharge for Incomplete Mixed Pallets KP03

Order 1
Header: M1 M2 20 CAR 30 CAR Condition record KP03 from 1 pal $5

+
Order 2
Header: KP02 $ 5 M1 M2 20 CAR 40 CAR Material master M1, M2 50 CAR ^ 1 pallet =

SAP AG 1999

The mixed pallet discount accumulates the quantities of the individual items. It then calculates the surcharge on any fractional portion of the total quantity. This is controlled by condition type KP03 (group condition = X, unit of measure = PAL and scale formula 23, which calculates the fractional proportion of the total quantity).

(C) SAP AG

TASD41

3-15

Rounding DIFF

Order header
Net value TAX Final amount DM 67.25 DM 10.08 DM 77,33

Table 001R
CCod 1000 Curr DM Rounding unit 5

Order header
Net value 2 TAX DIFF Final amount DM 67.25 DM 10.08 DM 0.02 DM 77.35

SAP AG 1999

You can maintain a rounding unit in Table T001R for each company code and currency. If the final amount in the order header differs from the rounding unit, the system will round the amount up or down as specified. Condition DIFF determines the difference amount. Condition type DIFF is a group condition and is distributed among the different items according to value.

(C) SAP AG

TASD41

3-16

Unit Summary

You are now able to: Enter order values and net prices manually Set a minimum price for a material or a minimum value for an order Set interval scales for conditions Use customer hierarchies for price agreements See the effect of condition formulas Round final amounts

SAP AG 1999

(C) SAP AG

TASD41

3-17

Statistical Condition Types

Contents:
Cost VPRS Cash discount SKTO Expected customer price EDI1 and EDI2

SAP AG 1999

(C) SAP AG

TASD41

3-18

Statistical Condition Types: Course Objectives

At the conclusion of this unit, you will be able to: Determine costs and cash discount amounts statistically in pricing Describe how expected customer prices transferred via EDI are used

SAP AG 1999

(C) SAP AG

TASD41

3-19

Cost VPRS

Cost Statistical

Condition category G

Material valuation segment

SAP AG 1999

In the standard version, condition type VPRS is used to retrieve the standard cost of the material. It is used as a statistical value by the pricing procedure. Using condition category G, VPRS accesses the valuation segment of the material master locating either the standard cost or the moving average cost, as specified in the material master. Condition category S will always access the standard cost, while condition category T will always access the moving average cost. The profit margin is calculated using formula 11 in the pricing procedure. This formula subtracts the cost from the net value 2 subtotal.

(C) SAP AG

TASD41

3-20

Cash Discount SKTO

Cash discount SKTO Statistical

Condition category E

Table 30 days

T052 3%

SAP AG 1999

In the standard system, condition type SKTO is used to retrieve the cash discount rate. It is used as a statistical value by the pricing procedure. Table T052 is accessed using condition category E and an amount is calculated from the first percentage rate of the item payment terms.

(C) SAP AG

TASD41

3-21

Customer Expected Prices EDI1 and EDI2

Customer expected price Statistical

Order
Item 10 M1 1 piece $ 1500 / piece $ 1400 / piece

Condition category J

Net item value EDI 1 ... ...

Save
Incompletion log

Incoming IDoc
Allow required customer price

SAP AG 1999

The customer expected price can either be entered manually in the order, or retrieved from the incoming IDoc in an EDI environment. Condition type EDI1 is used to compare the net price for each item. Condition type EDI2 is used to compare the overall item value (net price * quantity). Calculation formula 9 is assigned to condition type EDI1 in the pricing procedure. This formula tests for a maximum deviation of 0,05 currency units. Calculation formula 8 is assigned to condition type EDI2 in the pricing procedure. This formula tests for a maximum deviation of 1.0 currency units. If the customer expected price differs from the automatically determined price or value by more that the maximum difference allowed, the system will regard this order as incomplete when it is saved. You may process lists of orders having differences in prices, allowing the system to use or correct the price it determined.

(C) SAP AG

TASD41

3-22

Unit Summary

You are now able to: Determine costs and cash discount amounts statistically in pricing Describe how expected customer prices transferred via EDI are used

SAP AG 1999

(C) SAP AG

TASD41

3-23

Section: Shipping

SAP AG 1999

(C) SAP AG

TASD41

4-1

Dangerous Goods and their Transportation


Dangerous goods are materials or items, which because of their nature their properties their state may pose a threat to humans, animals, or the environment when they are transported. Transportation covers packing, loading, sending, transporting, receiving, unloading, and unpacking.

The Transport of Dangerous Goods Act 2 (German)


SAP AG 1999

There are many legal regulations to be observed when transporting dangerous goods. Transportation of the goods includes shipment, receiving and delivering the goods, temporary stops during transportation, and preparatory and follow-on activities (packing and unpacking, loading and unloading) (Transport of Dangerous Goods Act 2 (German)). This means it may be necessary to check the delivery document to ensure the transportation meets these requirements. To do this in the R/3 System, you use the functions in the EH&S component (Environment, Health, and Safety).

(C) SAP AG

TASD41

4-2

Dangerous Goods Management in Logistics Execution


Order Outbound delivery Picking Packing Shipping docs Goods Issue Transportation

Dangerous Goods Management


Dangerous goods checks
e. g. Shipment of material on mode of transport category permitted?

Dangerous goods docs


e.g. delivery note, packing list, tremcard, dangerous goods label
.......................... .......................... .......................... .......................... .......................... .......................... .......................... .......................... .......................... .... ... .... .. .. .. . ... .... ... .... ... .... ...

33 1088

Dangerous goods master


SAP AG 1999

Within the logistics process, you can activate dangerous goods management in the (inbound or outbound) delivery document or in the shipment document. The system can then perform various dangerous goods checks automatically, or you can trigger them manually. For instance, you can check whether the transportation of particular materials on a particular mode of transported is permitted. This can prevent deliveries or shipments that do not meet safety requirements leaving the company. You can also create dangerous goods documents containing the relevant dangerous goods data. Dangerous Goods Management uses special master data and settings in EH&S. You can make your own settings in Customizing to define when the various checks should be performed and how the document should be processed.

(C) SAP AG

TASD41

4-3

Dangerous Goods Master Data

Material master Dangerous goods master


Dangerous goods indicator profile: Relevant for dangerous goods Relevant for DG docs Relevant for checks Materialsubstance assignment

Material Dangerous goods regulation (regulations modeled in system)

Substance database
Substance and reg. data Maintenance of: Properties Compositions Classification

SAP AG 1999

If a material is considered a dangerous good, you define a dangerous goods indicator profile in the material master record (basic data 2). You can then refer to this profile to find out whether a material is classified as a dangerous good and whether it requires dangerous goods documents and checks. The dangerous goods master complements the material master and is therefore created for materials that are already defined in the system. It contains data that is necessary for performing dangerous goods checks and creating dangerous goods documents according to existing law. The substance database is a flexible tool for managing and maintaining data on chemical substances and preparations. It contains all substance data and legal data. It provides the basis for comprehensive environment management. The assignment of a material number and a substance number establishes the link between material data and substance data, which means that the dangerous goods master and the substance data can be used in the dangerous goods checks.

(C) SAP AG

TASD41

4-4

Process for Dangerous Goods Checks


Dangerous goods checks Process and determine sequence Check processor
Call checks Return codes

SD document processing Call DG checks Process the reactions

Process check modules 1 2 3 4 5

SD - DGM interface

Call check log

Check log

SAP AG 1999

The basic process for a dangerous goods check is as follows: When the check is triggered, manually or automatically, the system calls the check processor via an interface. The processor determines the data for the dangerous goods check, such as the dangerous goods master records, validity areas, and mode of transport categories. The system then processes the different check methods of the check schema. Using return codes, entries are made in the check log, which you can call from the document. The overall reaction is determined from the reactions from the individual check methods.

(C) SAP AG

TASD41

4-5

Dangerous Goods Checks in the Delivery Document


Trigger dangerous goods check
Determining data and processing the DG checks:
Automatically Manually

Outbound delivery
Ship-to party: Shipping point: Sales org.: Delivery type: Item 1 Item 2 7341 1200 1000 LF

Check 1 Transport permitted Check 2 Materials must not be packed together

R-DG89 10 kg Route: USA east T-DG43 31 pc Route: USA east

Make changes

Overall reaction: reaction: Packing not permitted

Log

SAP AG 1999

From the delivery document, you can start the dangerous goods check either automatically or manually. The automatic start takes place when you save the document, if the dangerous goods checks are activated. You can start the check manually at any time, if the dangerous goods checks are activated. However, the following information must be available: Shipping point Sales organization Delivery type Ship-to party Route When the dangerous goods checks are complete, a dialog box appears displaying the message from the check method that determines the overall reaction for the check schema. If there are any log entries, you can branch to the check log. The check log displays all the messages that appeared while the dangerous goods checks were being processed. You can print out the log. What happens next: You continue processing the document as determined by the Customizing settings for the overall reaction. For instance, the document either cannot be saved, or is assigned a blocking indicator.

(C) SAP AG

TASD41

4-6

Structure of the DELVRY02 Delivery Interface


Delivery header
Dangerous goods data Control Partner Dates Texts Foreign trade Routes Delivery item Shipping Unit
SAP AG 1999

Delivery item
Dangerous goods data Control Serial numbers Batch characteristics Foreign trade Reference data Texts Configuration

The DELVRY02 delivery interface consists of different segments containing information from the delivery header, the delivery item, and the shipping units. DELVRY02 (Release 4.6A) has more segments than DELVRY01 (Release 4.0), which contain dangerous goods data at header and item level. DELVRY03 (Release 4.6B) also contains segments for the external release number, data on the express delivery company, tracking data, and the repacking of shipping units.

(C) SAP AG

TASD41

4-7

Communication Scenarios
Shipping notification to customer (LAVA) Notification from forward.agent (CANO) Warehouse notification from internal warehouse Shipping confirmation from service agent Warehouse order to internal whse (WSOR) Shipping order to service agent (SHOR)

SD delivery processing

MM delivery processing

Shipping notification from vendor

SAP AG 1999

Shipping notification (outbound) by EDI (message type LAVA/EDI message DESADV): additional information, for example, serial numbers and configuration, can be communicated. Shipping notification (inbound) by EDI (EDI message DESADV): for inbound shipping notifications, MM can also receive packing data. Shipping order by EDI to a service agent (message type SHOR/EDI message SHPORD). Shipping confirmation from a service agent by EDI (EDI message SHPCON): This EDI message combines the picking confirmation with the packing data confirmation. Warehouse order to your external system by ALE (message type WSOR/ EDI message WHSORD). Warehouse confirmation from your external system by ALE (EDI message WHSCON): This EDI message combines the picking confirmation with the packing data confirmation. The message can also update the actual weight and the actual volume in the delivery. Notification to forwarding agent by EDI (message type CANO/EDI message CARNOT).

(C) SAP AG

TASD41

4-8

Express Delivery Companies

Parcel tracking
12.6. 10.05 MA 12.6. 10.55 KA 12.6. 12.02 S Picked up Load transferred Delivered

Service agent specific information


Tracking no. Routing info Service code Product code

Manifest
Delivery list

Service agent specific labels

EXPRESS

XXL 563
Route AB

49211172

SAP AG 1999

Express delivery companies transport goods quickly and offer the opportunity to track the itinerary of the shipments. There are special requirements for processing this kind of shipment, which do not arise with ordinary shipments. With express delivery processing in R/3, you can model the special requirements of express deliveries. These requirements include: Information specific to the service agent recorded in the delivery; this information refers either to the entire delivery or to individual parcels. Printing out special labels with the required information (this is needed for the automatic sorting machines at the express delivery companies) Creating the manifest / delivery list (simplifies settlement for the express delivery company and eliminates manual entry of shipments; prevents delays) Parcel and status tracking

(C) SAP AG

TASD41

4-9

Outbound Delivery Using Express Delivery Company


Ship-to party
Purchase order Purchase order Order confirmation Inbound delivery
Tracking no.

Shipper
Order

Delivery note
Tracking no.

Outbound delivery
Tracking no. Routing Service code etc.

Optional: Shipping unit Goods issue


Tr

Optional: Shipping unit Optional: Transportation


st us ife at st an g M in ck a Tr

ac ki

ng

st at u

Express delivery company


s

SAP AG 1999

When express delivery companies are involved in the outbound delivery process, you usually require express delivery information as soon as you create the outbound delivery. This information includes the tracking number, routing information, the service code, and the product code. This data can be defined either at outbound delivery level or shipping unit level. If an express delivery company is specified in the outbound delivery, the system automatically loads the information from the data stored for that company. In the outbound delivery document, there is a tab page for this at header level called parcel tracking. The shipper informs the ship-to party of the tracking number and any other information relevant to the express delivery. The shipper also has the option of creating a shipment document containing all the shipments for a particular express delivery company. On the basis of this shipment document, the shipper can create a manifest and send it to the service agent (electronically using the shipment IDoc). Both shipper and ship-to party can monitor the tracking status of the shipments at any time using the tracking number. The parcel tracking function is available for this purpose. You maintain the data for the express delivery companies in the express delivery cockpit.

(C) SAP AG

TASD41

4-10

Parcel Tracking

Where is delivery 80001234 shipped by the express delivery company QUICKLY?

Change delivery 80001234: Header details


Parcel tracking

What is the tracking number of the delivery? What service code was determined?

Parcel tracking
Sales document Purchasing document Delivery 80001234 Shipment number Shipping unit Tracking number

SAP AG 1999

It is often important to track the itinerary of the shipment (delivery or parcel), and to know at any one time where the shipment is, what its status is (tracking status such as picked up, load transferred, or delivered) and so on. The parcel tracking function allows you to do this. This function has its own tab page in the header details of the outbound delivery called parcel tracking. This view gives you the tracking status and all other information relating to the express delivery processing of this outbound delivery. There is also a parcel tracking transaction. This allows you to select documents by order, purchase order, delivery, shipment, shipping unit, or tracking number. For the selected document, the system also displays the tracking status and express delivery company information. The tracking status is also displayed in the document flow, along with the delivery status or status of the shipping unit. Another method of tracking shipments is to access the order status using SAP's Internet Application Components (IAC). From there, you can branch to parcel tracking. This is particularly useful for ship-to parties, who can call up the tracking status using the order number. You can also access the status in the background. A workflow connection is possible in this case. In exceptional cases, this may mean that processors receive items in their inboxes.

(C) SAP AG

TASD41

4-11

Details of Parcel Tracking

Parcel tracking
Expr. field Quantity Track.stat. Location

Shipping Delivery 80005432 Tracking status London, sh.pt 3000 Frankfurt Munich

Picked up London Load transferred Frankfurt Delivered Munich

Express delievery data fields Service code Sender number Weight code Tracking number Not packed Floppy disk drive R-1150 10 Pc 99 6543 DE 777333 22 123886622

SAP AG 1999

On the parcel tracking screen, you find detailed information about the tracking status and the data fields of the express delivery company, which the system supplies automatically. The data can be displayed both at outbound delivery level and at shipping unit level. There are no shipping units in the above example, so the data applies to the entire outbound delivery. User can define their own display variants so the information is displayed to suit their needs. From the parcel tracking screen, you can also request information from the express delivery company via the Internet.

(C) SAP AG

TASD41

4-12

Express Delivery Cockpit

COCKPIT
Control URLs Tracking status Weight codes Service codes Master data maintenance Set up Metadata

Data provider

Number range Routing info

Product codes

SAP AG 1999

The express delivery cockpit is the central point for making all the settings relevant to express deliveries. For each express delivery company, you must define which data fields are relevant for it and how they should be determined (= metadata). The master data includes: Product and/or service codes: Reflect the offering of the express delivery company (speed, services, and so on) Routing information: Depends on zip code; used by automatic sorting machines Tracking status: Possible status confirmed in parcel tracking URL links: Destination URLs for XML and URL templates for parcel tracking; documentation Number ranges: For numbers assigned by the express delivery company An XML-enabled setup interface simplifies the setup procedure if you are supported by the express delivery company or another data provider. In this case, you just need to create the express delivery company and assign it to a service agent (vendor master record) and shipping points. Next, all the meta and master data is loaded and can then be further processed manually.

(C) SAP AG

TASD41

4-13

Section: Billing

SAP AG 1999

(C) SAP AG

TASD41

5-1

Basic Accounting Principles

Double-Entry Accounting Balance sheet accounts P&L accounts SD Example MM Example

SAP AG 1999

(C) SAP AG

TASD41

5-2

Double-Entry Accounting

Account name Debit Credit

Each business transaction is posted to at least two different accounts Debit postings always appear on the left hand side of a T account Credit postings always appear on the right hand side of a T account Total debit postings = Total credit postings

SAP AG 1999

The basic principle of double-entry accounting is that every business transaction is posted to at least two different accounts, and is therefore posted at least twice. In the most simple cases, only two accounts are affected. The most important thing to remember in this context is Debit to Credit. This means that you should post a transaction to the debit side in one account, but to the credit side in another. Basic principle: The total for debit postings is always the same as the total for credit postings, regardless of the number of accounts affected.

(C) SAP AG

TASD41

5-3

Account Types - Balance Sheet Accounts

Property accounts Additions are entered on the debit side Disposals are entered on the credit side Examples: Stock, cash, bank, receivables

Capital and debtor accounts Additions are entered on the credit side Disposals are entered on the debit side Examples: Payables
SAP AG 1999

Business transactions are posted to accounts (= invoices kept on two sides, in which movements are registered). In a double entry accounting system it is possible to separate the accounts into different types of basic accounts, which themselves are divided into two partial accounts: Balance sheet accounts (property accounts and capital and debtor accounts), to which stocks and changes to these stocks are posted. P&L accounts (expense/cost accounts and revenue/sales accounts), to which transactions affecting net income are posted. The following basic equation applies to the structure of all accounts: Opening balance + addition - disposal = closing balance However, the basic accounts above differ in which side the opening balance, addition, disposal and closing balance are posted to.

(C) SAP AG

TASD41

5-4

Account Types - P&L Accounts

Revenue accounts Additions are entered on the credit side Disposals are entered on the debit side Example: Sales revenue

Expense accounts Additions are entered on the debit side Disposals are entered on the credit side Example: Cost of materials, price difference
SAP AG 1999

(C) SAP AG

TASD41

5-5

SD Example

Sales order Goods issue: Invoice:

10 pieces at $ 12 per piece 10 pieces delivered, standard price $ 10 per piece 10 pieces at $ 12 per piece

Incoming payment: $ 120


SAP AG 1999

(C) SAP AG

TASD41

5-6

SD Example: Postings
Material usage (Expenses) 100 Stock (Assets) 100

Goods issue:

Invoice:

Receivables (Assets) 120

Sales revenue (Revenues) 120

Incoming payment:

Receivables (Assets) 120

Bank (Assets) 120

SAP AG 1999

In the example of an SD business transaction, an accounting document is created at the point of goods issue and/or invoice creation. At the point of goods issue, the goods physically leave the warehouse. This results in a stock-related and value-related posting. This means that the stock is reduced and the materials used increased. The posting is therefore called "Materials used to stock". At the point of billing, receivables are accumulated by the customer, and additions are posted to sales revenues (posting record: Receivables to sales revenues). If the incoming payment is made in FI, the receivables are reduced again and the amount of the cash inflow is posted to a bank account (posting record: Bank to receivables). Posting output tax has been ignored for the purposes of this simplified example.

(C) SAP AG

TASD41

5-7

MM Example

Vendor

Purchase order: Goods receipt: Invoice: Payment:

10 pieces at $ 10 per piece 10 pieces received, standard price $ 10 per piece 10 pieces at $ 10 per piece $ 100

SAP AG 1999

(C) SAP AG

TASD41

5-8

MM Example: Postings
Stock (Assets) 100

Goods receipt:

GR/IR clearing account 100

Invoice:

Creditors Payable 100

GR/IR clearing account 100

Payment:

Creditors Payable 100

Bank (Assets) 100

SAP AG 1999

In the example of an MM business transaction, an addition to stock occurs at the point of goods receipt. The clearing entry is made against a special goods receipt/invoice receipt clearing account (stock to GR/IR clearing account). Provided that standard prices are used for valuation, it may be necessary to post to a price difference account the amount of the difference between costs for purchasing and valuation. At the point of invoice creation, the GR/IR account is credited and payables accumulated by the relevant creditor (GR/IR clearing account to creditors). The payables are reconciled in the payment run, and a disposal is is entered in the bank account (payables to bank). Posting the tax due has been ignored for the purposes of this simplified example.

(C) SAP AG

TASD41

5-9

Section: Transportation

SAP AG 1999

(C) SAP AG

TASD41

6-1

Internet Scenarios - Tendering for Service Agents

Shipper
Internet

Forwarding agent
Tender / quotation
Internet

Acceptance / rejection

Detailed information Status

SAP AG 1999

Using the recently developed Internet scenarios, you can tender a shipment created in R/3 and offer it to a service agent. Shippers and service agents communicate over the Internet, so the service agent needs neither an R/3 System nor EDI. An example of the usual tendering procedure: The shipper creates a shipment in R/3. Before it can be tendered, it must be planned - in other words, the service agent and stages must be defined. The shipper offers the shipment to the service agent via the Internet (tendering). The service agent has Internet access to the shipments offered, and can accept them, reject them, or accept them under certain conditions. The shipper confirms the acceptance or rejection by the service agent and sends further information if necessary. The service agent starts to process the shipment, defining planned data and setting a status for the shipment. The service agent can access information about new shipments at any time from the tendering list. The service agent can view the processing status of accepted shipments in the status list.

(C) SAP AG

TASD41

6-2

Tendering in the Shipment Document

Shipment
Tend. status
Tender

Tend. status Acc.cond/rej.reason Tendering text

Tender status
Not offered to any forw. agent / offer cancelled Offered by shipper Accepted by forwarding agent Accepted by forwarding agent with conditions Rejected by forwarding agent Confirmed by shipper Exception signalized by forwarding agent

SAP AG 1999

The tender tab in the shipment overview summarizes the most important information about the tendering of the shipment. The tendering status indicates the current status of a shipment with respect to negotiations with a forwarding agent over the Internet. Certain conditions are defined for setting each individual tendering status. Generally, you can only set a status if a forwarding agent is defined at header level in the shipment, if stages are defined, and Planned status is set. The shipper makes some status settings, and the forwarding agent makes others. In the Acceptance condition/rejection reason field, you can define the conditions under which a forwarding agent can accept a shipment or for what reason the shipment can be rejected.

(C) SAP AG

TASD41

6-3

Overview of Shipment Cost Calculation


Pricing procedure
1. Basic freight 2. Discount 1 3. Discount 2 Condition type FB00 FD00 FD10 FB00

Shipment costs
From NY to WA Conditions FB00 Basic freight 1100 USD FD00 Discount 1 -100 USD FD10 Discount 2 : -5 % 10 t

Access sequence: MATK Access sequence:MATK Condition tables: 1. Service agent/tariff zone/ freight class 2. Service agent/tariff zone Records for cond. type FB00 No valid record available Valid record available
SAP AG 1999

Scale
1300 USD 1 t or more 1100 USD 10 t or more 1000 USD 20 t or more

In this example, 10 tons of a material are shipped by a forwarding agent from New York to Washington. The system is to determine the shipment costs automatically. The system first determines the corresponding pricing procedure. This contains every possible condition type within shipment pricing in a particular sequence. The system reads the first condition type in the pricing procedure. The condition type identifies the characteristics of a condition. For this condition type, the system determines the assigned access sequence. The system reads the access sequence. In the sequence, the condition tables are accessed at least once. The sequence of the condition tables constitutes the search strategy to determine the corresponding condition record. The system searches for valid condition records for the condition tables (accesses). A condition record contains the actual shipment rates. If no valid condition record exists for the first condition table, the system searches for condition records for the second table. When the system finds a valid condition record for a condition table, the condition record is read and the corresponding value is copied into the shipment cost document. The system repeats all of these steps for each condition type until the entire pricing procedure is processed.

(C) SAP AG

TASD41

6-4

Determining the Pricing Procedure

Transportation planning point

Shipping type

Shipment cost item

Service agent

Pricing procedure SDFC00:


FB00 Shipment cost FB10 Flat rate FD00 Discount - absolute FD10 Discount - percentage Net value ...

SAP AG 1999

All condition types supported for pricing are determined in the pricing procedure. The pricing procedure is determined automatically based on different criteria: Transportation planning point of the shipment Shipping type (grouped in a shipping type procedure group) Service agent (grouped in a service agent procedure group) Shipment cost item category (grouped in an item procedure group) You set pricing procedure determination in Customizing.

(C) SAP AG

TASD41

6-5

Condition Records for Shipment Costs

Condition type:
Level at which the condition is defined

FB00 Basic freight 1120 DE20

Service agent:

Tariff zone - departure:

Tariff zone - destination: DE80 Freight class: B

Validity period 07/01/1999 - 12/31/2002


Scale: to 1000 kg 10000 kg 20000 kg 10 USD pro 100 kg 9 USD pro 100 kg 8 USD pro 100 kg

SAP AG 1999

The aim of pricing is to determine prices and surcharges/discounts (= conditions) for a business transaction and additionally allow the user to specifically influence these conditions manually. Prices, surcharges, and discounts are stored in condition records. You can define conditions at any level. A level corresponds to the fields in the condition table in which a condition record is stored. The level therefore also represents the key fields for the access to a condition. Common levels at which price agreements are made are predefined in the standard system. You can add any levels that you may need. Thus you can make conditions dependent on any fields of a business document. By specifying a validity period, you can restrict a condition to a specific period. You can maintain the values within a condition record (price, surcharge, discount) depending on a scale (weight-based, volume-based or value-based scale). You can also use multi-dimensional scales. There is no limit to the number of scale levels. For each condition record, you can define a lower and an upper limit that will allow you to manually change a pricing element within the limits specified.

(C) SAP AG

TASD41

6-6

Multidimensional Freight Agreement


Freight Cost Agreement with Service Agent "Ontime" Weight (TO)
MIN to 5
230 USD/TO 336 USD/TO 435 USD/TO

to 10
185 USD/TO 295 USD/TO 373 USD/TO

to 20
152 USD/TO 252 USD/TO 333 USD/TO

to 25
127 USD/TO 213 USD/TO 285 USD/TO

Distance (Mile)

to 100 to 300 to 500 MAX

250 USD 450 USD 800 USD

2000 USD

3500 USD

6000 USD

7100 USD

SAP AG 1999

You can maintain multi-dimensional freight agreements and represent them in an easy-to-use freight table for the freight cost area. Example: You have agreed on a tariff with your service agent that depends on both the distance and the weight of the load to be shipped. You have also agreed on minimum and maximum prices. The following freight costs arise from the freight table: A load of 9 tons is transported 320 miles. You determine a price of 373 USD per ton. This gives shipment costs of 3357 USD. A load of 4.9 tons is transported 400 miles. A price of 435 USD per ton was determined, giving 2131.5 USD in total. However, the maximum value is 2000 USD. A load of 1 ton is transported 250 miles. You determine a price of 336 USD but the minimum price is 450 USD so you charge 450 USD.

(C) SAP AG

TASD41

6-7

Multidimensional Condition Types


Condition type FM00:
Multidimensional

Assigned scales: Scale with basis R = Distance


Scale values (to): Distance (mil): 100 300 500 Minimum can be defined

Scale with basis D = Gross weight


Scale values (to): Gross weight (TO): 5 10 20 25 Maximum can be defined

SAP AG 1999

To represent multi-dimensional freight charges, you must define a condition type with the multidimensional calculation type. Several scales (max. 3) can be assigned to this condition type. The scales are defined as master data - regardless of the condition type - and can be assigned to several condition types. They have different scale bases, for example, distance, gross or net weight, postal code, tariff zone, number of shipping units, travel time, total duration. A calculation type is specified for each scale level. You can also define maximum and minimum prices. When you create a condition record, the scales assigned to the condition type appear as default values. You can however replace these values with others, if necessary.

(C) SAP AG

TASD41

6-8

Mass Maintenance of Shipment Condition Records

Eastquick Shipping We are increasing our shipment tarif as of Oct. 1, 2000 by 5%

Condition type FB00: Service agent: Date: Tf zone point of dep: Tf zone destination: 2266 01/10/00 US10 US80 to US99

Shipping point 5000 Tariff zone US10


SAP AG 1999

You can change several shipment condition records simultaneously. This enables you to respond quickly and efficiently to changes in the service agent's rates. To make the changes, select the condition record to be changed in change mode. Next choose Change amount, and enter the percentage or absolute value by which the condition record should be increased or reduced. If you would like to make the price change valid after a certain date (if the price is increased by 5%, say, as of the first of next month), you should proceed as follows: Using the function Create with reference, create new validity periods for the existing condition records. Using Change, call the condition records for the new validity period, and make the changes as described above.

(C) SAP AG

TASD41

6-9

Shipment Comparisons
Pricing procedure SDFC00:
0001 Weight-dep. basic freight Weight-dep. 0005 Insurance costs 0002 Basic freight - shipping unit Only choose the cheaper of the two freight types

Condition exclusion procedure


Exclusion group A Condition type 0001 Calculation base: Delivery item

Exclusion procedure

Exclusion group B Condition type 0002 Calculation base: Shipping unit

Cheaper
Net value: 1358 USD
SAP AG 1999

Net value: 1290 USD

The system can carry out two different shipment cost calculations and compare them, automatically selecting the most favorable result. Example: You can, for example, create condition types with the delivery items calculation base and condition types with the shipping units calculation base in the same pricing procedure. You can then define condition exclusion groups (A and B) and assign the two condition types with additional discounts to the two different exclusion groups. You then assign these exclusion groups to the pricing procedure and specify the exclusion process "Best condition between the two exclusion groups". If you now carry out a shipment cost calculation for which the above pricing procedure is determined, the system calculates the freight value for exclusion group A and exclusion group B. In the first case, the calculation is performed for each delivery item. The final shipment price is 1,358 USD. In the second variant, costs are calculated by shipping unit. There are 6 pallets. The shipment price is 1250 USD. Based on the exclusion process, the system selects the most favorable variant and calculates the costs by shipping unit.

(C) SAP AG

TASD41

6-10

Break Weight Calculation

Shipment Mat.1 9t

Shipment cost agreement 5 to 10: 6 USD / 100kg 10 to 15 t: 5 USD / 100kg

Calculation 1 9 x 60 USD/TO = 540 USD

Calculation 2 10 t x 50 USD/TO = 500 USD

Cheaper
Shipment costs: 540 USD Shipment costs: 500 USD

SAP AG 1999

The break weight calculation is used to choose the most favorable scale level for the calculation when using scaled shipment cost agreements. The break weight is the weight at which it is more favorable to calculate a heavier weight so that you reach a higher and cheaper scale level. Example: You have agreed on shipment costs for 60 USD per TO for the scale level 5 to 10 tons to be transported but only 50 USD per TO for scale level 10 to 15. A shipment of 9 tons would lead to a price of 540 USD in the scale level 5 to 10. It would be cheaper to calculate the shipment costs for a weight of 10 tons so that it reaches the next scale level and therefore only costs 500 USD.

(C) SAP AG

TASD41

6-11

Break Weight Calculation Customizing

Condition type FS00


Scale 51

Exclusion procedure

Condition type FS10


Scale 51
Break wt.

Ref. cond. type: FS00

Condition record for FS00

Calculation with corresponding scale level

Calculation with the next higher scale level

SAP AG 1999

You need two condition types to use break weight calculation. The first is for "normal" shipment cost calculations at the correct scale level. The second is for calculating at the next scale level. The system uses a condition exclusion procedure to compare the two values and use the cheaper one. You must make the following Customizing settings: Define two condition types. The second must refer to the first and use the same condition records. Assign the same scales to both condition types and activate the break weight indicator for the second condition type. For multi-dimensional scales, activate this indicator for the scale in which the break weight should be calculated. Define an exclusion condition procedure that chooses the cheapest value.

(C) SAP AG

TASD41

6-12

Express Delivery Companies

Parcel tracking
12.6. 10.05 MA 12.6. 10.55 KA 12.6. 12.02 S Picked up Load transferred Delivered

Service agent specific information


Tracking no. Routing info Service code Product code

Manifest
Delivery list

Service agent specific labels

EXPRESS

XXL 563
Route AB

49211172

SAP AG 1999

Express delivery companies transport goods quickly and offer the opportunity to track the itinerary of the shipments. There are special requirements for processing this kind of shipment, which do not arise with ordinary shipments. With express delivery processing in R/3, you can model the special requirements of express deliveries. These requirements include: Information specific to the service agent recorded in the delivery; this information refers either to the entire delivery or to individual parcels. Printing out special labels with the required information (this is needed for the automatic sorting machines at the express delivery companies) Creating the manifest / delivery list (simplifies settlement for the express delivery company and eliminates manual entry of shipments; prevents delays) Parcel and status tracking

(C) SAP AG

TASD41

6-13

Section: Credit/Risk Management

SAP AG 1999

(C) SAP AG

TASD41

7-1

Payment Differences and Special Commitments: Business Scenario

Sometimes there are deviations between the amount of the incoming payments and the existing receivables. When posting the residual items, your employees enter a difference code. Here, disputed residual items should not influence the commitments in credit management. Some customers make payments for orders. These incoming amounts should reduce the amount of credit limit used.

SAP AG 1999

(C) SAP AG

TASD41

7-2

Payment Differences - Disputed Items

Customizing: Financial Accounting - Incoming payments Difference reason 01 02 Disputed Yes No

Incoming payments TILIA Corp. Open items $12,000

Incoming payments $11,000 Difference


CCA data

$1,000

Reason 01
CCA data

Tilia Corp. Receivables: $12,000


SAP AG 1999

Incoming payments

Tilia Corp. Receivables: 0

For each company code, difference reasons are determined to manage payment differences. Difference reasons are used, for example, when the cash discount period has been exceeded, when an unauthorized cash discount is claimed, or if the customer has simply made an error in calculation. You indicate for each difference reason whether payment differences should result in disputed items. Disputed items do not raise the total receivables within credit management due from a customer. When you carry out a credit check against the oldest open items and the percentage of open items with a certain number of days in arrears, the system does not take disputed items into account. For more information see the chapter on Automatic Credit Control.

(C) SAP AG

TASD41

7-3

Payment Differences - Undisputed Items

Customizing: Financial Accounting - Incoming payments Difference reason 01 02 Disputed Yes No

Incoming payments TILIA Corp. Open items $12,000

Incoming payments $11,000 Difference


CCA data

$1,000

Reason 02
CCA data

Tilia Corp. Receivables: $12,000


SAP AG 1999

Incoming payments

Tilia Corp. Receivables: $1,000

In this example, the receivable in credit management remains at the level of the outstanding receivable because the difference reason is not disputed (for example, an error in calculation by the customer).

(C) SAP AG

TASD41

7-4

Receivables from Special G/L Transactions

Customizing: Financial Accounting - Incoming payments Account type: D = Customer Special general ledger indicator: A = Payment Credit limit relevance: x

Tilia Corp. Payment : $2,000

CCA data

Tilia Corp. Receivables: Special commitments: Total commitments


SAP AG 1999

$12,000 $- 2,000 $10,000

Special general ledger transactions represent special transactions in accounts receivable and accounts payable, which cannot be shown in the usual way in the sub-ledger account. Examples include down payments and bill of exchange posting. The Credit limit relevance indicator ensures that the system takes posting into account when the credit limit check is carried out for special general ledger transactions (in other words, this value is included in total commitments).

(C) SAP AG

TASD41

7-5

Process Chain for Payment Card Processing

Order

Authorization
Card info

Clearing house

Outbound delivery

Check validity of authorization Authorization


Settlement

Billing document
Card info
SAP AG 1999

Acc. doc.

Authorization information
Card info

Payment card processing supports the following functions: A payment card plan is assigned to the sales order at header level. This plan contains information such as the card number, the card type and the authorization data. When the delivery is created, a validity check is carried out for the authorization. If the authorization is no longer valid, or if an increase in quantity requires an increase in value, then the user is required to carry out authorization again in the sales order. The payment card data is copied to the billing document from the order. The payment card data and authorization data are forwarded when the billing document is transferred to Financial Accounting. In Customizing, you can configure the system so that additional data needed for settlement is transferred from SD to FI when procurement cards are involved. Transactions with payment cards can be posted to deviating accounts (see the field Account determination for payment cards when controlling the billing types). The final settlement process is carried out via the clearing house on the basis of this information.

(C) SAP AG

TASD41

7-6

Payment Card Authorization with an External System

Authorization

Clearing house

POS

Settlement

Billing document
Card info

Acc. doc.

Authorization information

Card info

SAP AG 1999

This form of processing takes place in Retail. The Point-of-Sale (POS) is the point at which the goods are paid for (usually the cash register). No sales or shipping documents are created. When using Point-of-Sale systems, authorization is carried out in an external system. The relevant data is imported to the R/3 System. The billing document is created in the R/3 System.

(C) SAP AG

TASD41

7-7

Payment Card Data in the Customer Master record

Card type VISA MC

Card number 4100000000000001 5100000000000008

Default Block reason Valid from Valid to X 01.01.1997 31.12.2002 01.01.1996 31.12.2001

Best Bank

VISA

4100 0000 0000 0001 Valid from 01/97 to 12/2002 K. King Euro Bank MC

5100 0000 0000 0008 Valid from 01/96 to 12/2001 K. King

SAP AG 1999

Payment card data can be stored in the payer master record via the Payment transactions screen (Payment cards button). Here, you specify the payment card type (for example, VISA), the payment card number, and the validity periods for this card. A card can also be entered as a default card. This will then appear in the F4 Help for order processing. If a card is blocked, the blocking reason can also be entered for the corresponding payment card (purely for information purposes, has no effect on the block in the order). When you enter payment cards in the customer master, the following checks are carried out: The system checks the validity of the card number, provided the corresponding check routines are maintained in Customizing for that card type. The system also checks whether this card has already been entered in a different customer master record. An identical card cannot be entered for more than one customer.

(C) SAP AG

TASD41

7-8

Data Transfer to the Clearing House

SAP standard interface

Converter 1

Converter 2

Converter 3

Clearing house 1
SAP AG 1999

Clearing house 2

Clearing house 3

Clearing houses issue authorizations for orders and are also responsible for settlement. A transparent interface to external systems allows the merchant to transfer and receive data. In the standard R/3 System, function CCARD_AUTH_SIMULATION is provided as a template for creating user-specific authorization functions. The standard system also contains function CCARD_SETTLEMENT_SIMULATION, for creation of user-specific settlement functions.

(C) SAP AG

TASD41

7-9

Authorization

One day before delivery creation Valid for 14 days Order entry Next material availability date by schedule line

Days

Authorization horizon

Validity period (14 days)

SAP AG 1999

Authorization is usually carried out in the order at header level. In other words, new authorizations must always be created through the order. Using checking groups, you can set requirements in Customizing, that control under what circumstances authorization is to be determined. You can then set the system so that authorizations are carried out only for complete orders. Depending on the checking group, you can also specify the authorization horizon (in other words, when authorization is to be determined). If you use authorization requirement 1 provided in the standard system, authorization is triggered when you save the order. Authorization requirement 2 is provided for background processing. The checking groups must be assigned to the sales document types. In the example above, an order has been entered today and is to be paid for using a VISA card. Authorization is to be carried out one day before delivery creation and will be valid for 14 days. The next material availability date according to the schedule line is in three days. This means that the authorization process must be carried out in two days time, according to the authorization horizon specified. The authorizations in the order are used in billing. A status in the order displays which authorizations have already been used. Note: You can use the checking groups in Customizing to control whether preliminary authorizations (value 0, if the current date is outside the authorization horizon) are to be carried out in order to check the correctness of the card data.

(C) SAP AG

TASD41

7-10

Settlement(1)

Invoice #900001
Customer: 58759 King VISA 4100000000000001 Order value $50

Customer 58759
50 50

Sales revenue
50 100

Invoice #900105
Customer: 98775 Kaiser VISA 4200000000000000 Order value
SAP AG 1999

Automatic offsetting entry to the customer account

Debiting of clearing house account and posting of sales revenue

Customer 98775
100 100

Clearing house
50 100

$100

When accounting documents are being created from transferred billing documents that include payment card data, the following postings are made: Debit and credit postings to the customer account Posting of the sales revenue Posting of receivables to the interim account of the clearing house This posting process can be explained in that the authorization guarantees the receivable and the clearing house represents the relevant partner for payment. An interim account should be created for every clearing house so that the condition technique can be used to carry out posting to the relevant account (all receivables paid with VISA and MC posted to the interim account of the GZS; all receivables paid with AMEX posted to the interim account for the AMEX clearing house, and so on).

(C) SAP AG

TASD41

7-11

Settlement (2)

B E F O R E

Clearing house
50 100

Interim bank account

Postings to the clearing house account are cumulated and credited A F T E R

The cumulative value is posted to the corresponding interim bank account

Background processing #5584

Clearing house
50 100 150

Interim bank account


150

Settlement triggered via interim account

SAP AG 1999

At regular intervals, the individual postings can be cumulated in the interim account for the clearing house and posted as a full value to the corresponding interim bank account. Settlement with the clearing house is triggered via this interim bank account. This account now contains the receivables from the clearing house for which payment is now expected. The receivables were transmitted via a settlement run. The background processing number can be used for assignment purposes during incoming payments. The interim bank account is cleared upon payment of the receivables by the clearing house.

(C) SAP AG

TASD41

7-12

Processing Blocked Documents

Contents:
Release, rejection and forwarding of blocked documents Reassignment Information functions

SAP AG 1999

(C) SAP AG

TASD41

8-1

Processing Blocked Documents: Unit Objectives

At the conclusion of this unit, you will be able to: Name the different processing functions for blocked sales documents and describe their effects Explain how to access the different information sources used to decide which form of processing is applied to blocked documents

SAP AG 1999

(C) SAP AG

TASD41

8-2

Processing Blocked Documents: Business Scenario

Usually your credit representatives process at regular intervals their worklist of documents blocked for credit, for example once a day Since the decision as to whether a blocked transaction can be released or must be cancelled depends on several factors, they need various information functions

SAP AG 1999

(C) SAP AG

TASD41

8-3

Release
Order: 125

SP : Tilia Corp. Credit status: A OK

Order: 125

SP : Tilia Corp. Credit status: B Blocked

Order: 125

SP : Tilia Corp. Credit status: D Released

Blocked documents Order 125 SAP AG 1999

Released documents

Release

Order 125 -

The following status settings are provided for sales and distribution documents in Credit Management: Blank = credit status is not relevant A = transaction is valid for the purposes of credit management B = transaction is blocked by credit management D = transaction has been released by credit management 'C' is not currently used. This status is provided for every type of check activated for the automatic credit check. The system also determines a total status from the individual status settings.

(C) SAP AG

TASD41

8-4

Releasing Documents and Carrying Out Another Check

CCA

Risk category Operat.

Deviation: 10% Number of days: 5

Order Tilia Corp. Order value: $10,000 Credit status: B Release on June 1 Tilia Corp. Order value: $10,000 Credit status: D Order changed on June 1

A new check is carried out when: a) The amount is increased b) The time limit is exceeded
SAP AG 1999

Tilia Corp. Order value: $12,000 Credit status: B

You can determine the conditions under which a document is to be checked again once it is released. The check rule for orders can be used to determine the conditions under which an order is to be checked again once it is released. The check rule for deliveries can be used to determine the conditions under which a delivery is to be checked again once it is released. It also influences the check on a released transaction when a delivery is created from an order. When you create a delivery, the release date of the order is copied to the delivery and used for the check carried out in this document. If there are no entries made in the above fields, the transaction is checked again.

(C) SAP AG

TASD41

8-5

Rejection

List: Blocked documents Doc. no. credit value status Rejection


918 -

Order 918 Tilia Corp.


Reason for rejection

$10,000

Item 10: Credit Limit Exceeded Item 20: Credit Limit Exceeded Item 30: Credit Limit Exceeded

SAP AG 1999

(C) SAP AG

TASD41

8-6

Information Sources Specific to Credit Management

Credit overview

Credit master sheet

CCA data Customer: Tilia Corp. CCA: Europe Limit: $50,000

Early warning list

Master data list

SAP AG 1999

In Credit Management the use of different information sources to help you decide whether a blocked document can be released or not is of prime importance. For this reason there is a large number of reports and tools that contain a wide range of information. Some of these information sources have been created especially for Credit Management, whereas others come from related areas that can also be relevant for decision-making. The credit master sheet serves to display and print the customer master data of an individual account that is needed for Credit Management. To get an overview of the customer master data of one or several customers you can generate a credit overview. This report is an exceptionally important tool for checking the credit management data of customers in regular cycles. Using the master data list, you can display and print customer credit data. In particular you can display information that is not contained in the credit data, for example customer-specific data or external data that you have created with special supplementary software. From Release 4.5A it is possible to generate an early warning list. However, you must first create a credit vector for the selected customers using program RFCMCRCV.

(C) SAP AG

TASD41

8-7

Information Sources - General


Customer master record Customer master record Oldest items due Oldest items due Last payment Last payment Account summary Account summary Line items Line items

CCA data Customer: CCA: Limit: Tilia Corp. Europe $50,000

FI Info System FI Info System Sales Info System Sales Info System
SAP AG 1999

Count data Count data Dunning data Dunning data

In Credit Management there is additional important information specific to the customer that can influence decision making. You can use general information on the last payment made by the customer and the oldest items due, for example, taken directly from a customer's credit control area data. Furthermore, it is possible to branch from Credit Management to the customer's dunning and count data. From the credit control area data, the credit master data, and the credit overview, you can list the customer's line items, carry out an account analysis or analyze the payment history. Using the FI info system you can also analyze due dates, the DSO, and overdue items.

(C) SAP AG

TASD41

8-8

Processing Blocked Documents: Summary

You are now able to: Name the different processing functions for blocked sales documents and describe their effects Explain how to access the different information sources used to decide which form of processing is applied to blocked documents

SAP AG 1999

(C) SAP AG

TASD41

8-9

Exercises
Unit: Processing Blocked Documents Topic: Different Information Sources

At the end of these exercises, you will be able to: Describe and apply the different information sources available to help you decide how to process blocked documents.

You are processing a list of blocked orders and deliveries. To decide which documents to release/reject, you need to access various data from different areas.

1-1

Display which sales documents have been blocked within your group due to a credit limit check.

1-2

A transaction can appear in this list as a result of various credit checks. Find out which checks were carried out for the documents in your list and find out the results of those checks.

1-3

Display the credit master sheet for the customer concerned.

1-4

Display a short summary of information on your customer by calling the credit overview.

1-5

Display the credit control area data and find out when the last payment was made.

1-6

Call the account analysis for customers.

(C) SAP AG

TASD41

8-10

1-7

Reject the blocked sales document. The delivery should remain blocked.

(C) SAP AG

TASD41

8-11

Solutions
Unit: Processing Blocked Documents Topic: Different Information Sources

1-1

Display which sales documents have been blocked within your group due to a credit limit check. Accounting Financial accounting Accounts receivable Credit management Exceptions Blocked SD documents

1-2

A transaction can appear in this list as a result of various credit checks. Find out which checks were carried out for the documents in your list and find out the results of those checks. Select a document line and choose Environment Document info Document status

1-3

Display the credit master sheet for the customer concerned. Select a document line and select Environment Credit master sheet

1-4

Display a short summary of information on your customer by calling the credit overview. Select a document line and choose Environment Credit overview

1-5

Display the credit control area data and find out when the last payment was made. Select a document line and choose Environment Customer master credit Control area data Extras Last payment

(C) SAP AG

TASD41

8-12

1-6

Call the account analysis for customers. Accounting Financial accounting Accounts receivable Account Analysis

1-7

Reject the blocked sales document. The delivery should remain blocked. Accounting Financial accounting Accounts receivable Credit management Exceptions Blocked SD documents Select the relevant document line and choose Edit Reject (enter rejection reason 20)

(C) SAP AG

TASD41

8-13

Overview Standard Courses

Contents:
Standard Courses in MM Standard Courses in other areas

SAP AG 1999

(C) SAP AG

TASD41

9-1

Materials Management
Level 2
LO510 3 days Inventory Management LO515 3 days Invoice Verification LO520 3 days Purchasing Details and Optimization LO525 2 days Consumption-Based Planning and Forecasting LO540 2 days Procurement of External Services 2 days LO925 Cross-Application Business Processes in SD and MM LO640 3 days Foreign Trade 2 days LO715 QM in Procurement
SAP AG 1999

Level 3

5 days LO550 Cross-Functional Customizing in MM 2 days LO521 Pricing in Purchasing

LO020 Processes in Procurement

5 days

LO955 3 days Batch Management

LO235 KANBAN

2 days

With the help of this slide you may inform yourself about the standard courses in the MM module. Furthermore you are able to get an idea of how many topics are covered in standard courses in the TeamSAP Academy course TAMM40: LO020: LO510: LO511: LO515: LO520: LO521: LO525: LO540: LO550: LO955: all subjects all subjects Physical Inventory: Overview, Cycle Counting and Inventory Sampling nearly all subjects ca. 80 % (no vendor evaluation and no Material Part Numbers in the academy) overview & important details ca. 60 % (there is no forecast in the academy) Overview in week 1. For further details, please visit this course. all subjects overview & important details

Not covered in the academy are the following courses: LO235, LO640, LO715, LO925. If you are interested in subjects contained in these courses, please visit the relevant courses or the related Advanced Academy courses.

(C) SAP AG

TASD41

9-2

Financial Accounting
Level 2
AC200 5 days General Ledger/ Accounts Payable/ Accounts Receivable Configuration

Level 3
AC205 2 days Financial Closing AC260 2 days Additional Financial Functionality AC660 5 days EC-CS: Consolidation Functions *AC240 5 days FI-LC: Consolidation Functions **AC900 R/3 For Auditors CA550 3 days 4 days Consolidation

AC010

5 days

Financial Accounting and Reporting

AC290 Real Estate Management AC305

5 days

4 days

Asset Accounting AC220 5 days

Special Purpose Ledger AC700 5 days

Funds Management: Processes, Organization and Configuration HR050 5 days AC270 3 days Travel Management Travel Expenses Human Resources
SAP AG 1999

Inflation Accounting AC275 1 day Travel Management Travel Planning

**

from July 2000 on

(C) SAP AG

TASD41

9-3

Controlling
Level 2 Level 3
AC412 2 days Cost Center Accounting: Extended Functionality AC410 Cost Center Accounting 3 days AC415 2 days Overhead Orders AC420 AC040 5 days 2 days

Activity Based Costing AC510 3 days Cost Object Controlling for Products AC505 3 days Product Cost Planning AC605 5 days AC515 3 days Cost Object Controlling for Sales Orders AC530 2 days Actual Costing / Material Ledger AC650 Transfer Prices AC620 2 days Executive Information System (EIS) - Setting up the System AC625 1 day Executive Information System (EIS) 3 Business Planning 2 days

Cost Management and Controlling

Profitability Analysis AC610 Profit Center Accounting 2 days

SAP AG 1999

AC615 2 days Executive Information System (EIS) 1 Reporting

(C) SAP AG

TASD41

9-4

Human Resources 4.6 (1)


Level 2
HR505 3 days Organizational Management HR305 3 days Configuration of Master Data HR315 Recruitment HR050 5 days AC270 3 days Travel Management Travel Expenses HR540 3 days Compensation Management HR325 3 days Benefits Administration HR580 Reporting in HR HR250 3 days 3 days HR306 3 days Configuration of Time Recording
see HR2

Level 3
HR510 Personnel Development 3 days

HR515 3 days Training and Event Management HR310/311 5 days Time Evaluation HR307 2 days

Human Resources

Configuration of HR System Controls HR350 5 days

Programming in HR HR530 3 days Technical Topics in Human Resources CA500 2 days CATS The Cross Application Time Sheet

3 days

Employee Self Service


SAP AG 1999

(C) SAP AG

TASD41

9-5

Human Resources 4.6 (2)


Level 2
HR305 3 days Configuration of Master Data

Level 3
HR390 Introduction to Payroll HR400 2 days

5 days

Payroll Configuration HR050 5 days HR4xx 3 days Country-Specific Payroll HR7xx 2 days Payroll Reporting (Country-Specific)

Human Resources

SAP AG 1999

(C) SAP AG

TASD41

9-6

Logistics Execution
Level 2 Level 3

LO530 3 days Warehouse Management LO140 3 days Processes in Logistics Execution LO610 Shipping 2 days

LO531 3 days Additional Topics in Warehouse Management LO650 3 days Cross-Functional Customizing in SD

LO611 Transportation

3 days

SAP AG 1999

(C) SAP AG

TASD41

9-7

Sales and Distribution


Level 2
LO604 Sales Support LO605 Sales LO610 Shipping LO611 Transportation LO615 Billing LO620 Pricing in SD LO640 Foreign Trade 1 day 4 days 2 days 2 days 2 days 3 days 3 days LO650 Cross-Functional Customizing in SD 3 days

Level 3
LO606 Sales Workshop 1 day

LO150 5 days Processes in Sales and Distribution

LO645 2 days Credit and Receivables Risk Management 2 days LO925 Cross-Application Business Processes in SD and MM
SAP AG 1999

(C) SAP AG

TASD41

9-8

Production Planning
Level 2
LO980 3 days Engineering Change Management LO235 KANBAN LO050 5 days Manufacturing Planning & Execution for Discrete & Repetitive LO205 3 days Basic Data for Discrete Manufacturing LO985 3 days LO206 3 days Basic Data Part 2 2 days

Level 3
LO210 5 days Production Planning LO215 5 days Production Orders LO225 3 days Repetitive Manufacturing LO930 2 days Logistics Information System (LIS) Reporting 5 days LO990 Variant Configuration Part 1 LO991 3 days Variant Configuration Part 2 LO230 5 days

Capacity Planning

2 days LO720 CAP Calculation of Standard Values 2 days LO275 Special Features of LIS in Production 2 days LO935 Logistics Info Planning

Classification LO955 3 days Batch Management

SAP AG 1999

(C) SAP AG

TASD41

9-9

Enterprise Controlling
Level 2 Level 3
E C - E I S: Executive Information System AC615 2 days Executive Information System (EIS) 1 Reporting AC620 2 days Executive Information System (EIS) 2 Setting up the System E C - B P: Business Planning AC625 1 day Executive Information System (EIS) 3 Business Planning

E C - P C A: Profit Center Accounting AC040 5 days AC610 Profit Center Accounting 2 days

Cost Management and Controlling

E C - C S: Consolidation AC660 5 days

Consolidation of Investments

EC-CS: Consolidation Functions AC205 2 days Financial Closing AC220 5 days Special Purpose Ledger
Controlling Enterprise Controlling Financial Accounting

AC010

5 days

AC665 3 days EC-CS: Integration

Financial Accounting and Reporting

SAP AG 1999

(C) SAP AG

TASD41

9-10

You might also like