tasd41

TASD41 Sales and Distribution - Appendices TASD41

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

0

© SAP AG 1999

TASD41 Sales and Distribution - Appendices

TASD41TASD41

Sales & Distribution -AppendicesSales & Distribution -Appendices© SAP AG

System R/3, Sales and Distribution - Appendices

Release 4.6B

April 2000

Material number 50037387

© SAP AG 1999

Copyright 2000 SAP AG. All rights reserved.

Neither this training manual nor any part thereof maybe copied or reproduced in any form or by any means,or translated into another language, without the priorconsent of SAP AG. The information contained in thisdocument is subject to change and supplement without priornotice.

All rights reserved.

Copyright

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, Saarbrücken

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.

(C) SAP AG TASD41 1-1

© SAP AG 1999

Appendices


© SAP AG 1999

Appendix

This unit contains extra materials to be used forreference purposes

This material is not part of the standard course

Therefore the material might not be used during thecourse


© SAP AG 1999

Content: Appendix

Special Shipping

Special Billing

Special Transportation

Special Credit/Risk Management

Overview Standard Courses

User Roles

Frequently Used Menu Paths

Table Structures

Special Sales

Special Pricing


© SAP AG 1999

User Roles for SD (Sales and Distribution)

Sales manager

Sales representative

Personal responsible in sales order processing

Personal responsible in invoice processing

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.


© SAP AG 1999

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

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.


Frequently Used Menu Paths

Activity

Menu path

Master data

Logistics Sales and distribution Master data

Display sold-to party Business partner Customer Display

Display material Products Material Other material Display

Display bill of material Products Bills of Material Bill of Material Material BOM Display

Display condition records (prices, discounts/surcharges, free goods, etc.)

Conditions Display

Display output master records Output Sales document Display

Customer-Material-Information Agreements Customer-Material Info Display

Order processing

Logistics Sales and distribution Sales

Create/change/display order Order Create/Change/Display

Create/change/display inquiry Inquiry Create/Change/Display

Create/change/display quotation Quotation Create/Change/Display

Create/change/display scheduling agreement

Scheduling agreement Create/Change/Display

Create/change/display contract Contract Create/Change/Display

Display list of orders Information system Orders List of sales documents

Display list of incomplete orders Information system Orders List of incomplete orders


Shipping

Logistics Sales and distribution Shipping and Transportation

Create/change/display delivery Outbound delivery Create/Change/Display

Create transfer order Picking Create transfer order Single Document

Post goods issue Post goods issue Outb. delivery Single Document

Billing

Logistics Sales and distribution Billing

Create/change/display billing document Billing document Create/Change/Display

Display financial accounting documents Billing document Display Accounting overview


Customizing

Access

Tools AcceleratedSAP Customizing Project editing Display SAP Reference IMG

Define organizational units

Enterprise structure Definition

Maintain sales organization Sales and Distribution Define sales organization ...

Define, copy, delete, check Sales Organization

Maintain distribution channel Sales and Distribution Define distribution channel ... Define, copy, delete, check distribution channel

Maintain division Logistics - General Define division ... Define, copy, delete, check division

Maintain sales office Sales and Distribution Maintain sales office

Maintain sales group Sales and Distribution Maintain sales office

Assign organizational units

Enterprise structure Assignment

Sales organization – Company code Sales and Distribution Sales Organization - Assign sales

organization to company code

Sales organization – Distribution channel Sales and Distribution Assign distribution channel to sales

organization

Sales organization – Division Sales and Distribution Assign division to sales organization

Sales area Sales and Distribution Set up sales area


Sales area – Sales office Sales and Distribution Sales office – Sales area

Sales office – Sales group Sales and Distribution Sales group - Assign sales office to

sales group

Sales organization – distribution channel - Plant

Sales and Distribution Assign sales Organization - Distribution

channel – plant

Master data

Common distribution channels Sales and Distribution Master data Define common distribution channels

Common divisions Sales and Distribution Master data Define common divisions

Maintain account group Logistics – General Business Partner Customers Control Define account groups and field

selection for customers

Maintain material type Logistics – General Material master Basic settings Material types Define attributes of material types

Basic functions

Sales and Distribution Basic Functions

Define pricing procedure Pricing Pricing Control

Define free goods procedure Free Goods Condition Technique for Free Goods

Define output Output Control Output Determination Output Determination using Condition

Technique ...

Define material determination procedure Material Determination ...

Define listing/exclusion procedure Listing/Exclusion ...

Partner determination Partner determination

Incompletion procedure Incompletion ...

Sales document control

Sales and distribution Sales Sales documents

Header Define sales document types Sales document header Define sales document types

Restrict sales document types to organizational units

Sales document header Assign sales area to sales document types


Item

Define item category Sales document item Define item categories

Assign item category Sales document item Assign item categories

Schedule line Define schedule line categories Schedule lines Define schedule line categories

Assign schedule line categories Schedule lines Assign schedule line categories

Copying control

Sales and Distribution Sales Maintain copying control for sales

documents

Contracts Define value contracts Contracts Value contracts ...

Define contract data Contracts Contract data ...

Shipping

Logistics Execution Shipping

Determine shipping points Basic Shipping Functions Shipping and Goods Receiving Point Determination

Document control in shipping Deliveries ...

Set up delivery blocks Deliveries Define reasons for blocking in Shipping

Lean WM Picking Lean WM ...

Billing

Sales and Distribution Billing

Define billing document types Billing documents Define billing types

Set up billing blocks Billing documents Define blocking reasons in Billing

Copying control for billing documents Billing documents Maintain copying control for billing documents

Maintain requirements and forms

Sales and Distribution System Modification

Routines ...


© SAP AG 1999

Table Structure for Customers - SD View

KNVK KNVA KNVS

KNVP KNVD KNVL

KNA1

KNVV KNVI

These tables contain the following information:

KNA1: Customer master, general information

KNVK: Contact person

KNVV: Customer master, sales area

KNVA: Unloading points

KNVI: Tax indicators

KNVP: Partner functions

KNVD: Documents

KNVL: Licenses

KNVS: Shipping data

Logical databank for customer master:

DD F: Customer database


© SAP AG 1999

KNVH

Table Structure for Customer Hierarchies

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


© SAP AG 1999

Table Structure for Materials

MCHB

MCHA MLGT

MAPRMVERMBEW MLGNMARC

MAKT MARM MVKE MLAN MAEX

MARA

MCH1

MARD


MARA: General material data

MAKT: Short texts

MARM: Conversion factors

MVKE: Sales data (for each sales organization and distribution channel)

MLAN: Sales data (for each country)

MAEX: Export licenses

MARC: Plant data

MBEW: Valuation data

MLGN: Warehouse management inventory data

MLGT: Warehouse management inventory type data

MVER: Consumption data

MAPR: Pointers for forecast data

MARD: Storage location data

MCH1: Cross-plant batches

MCHA: Batches

MCHB: Batch stocks

Logical databank for material master:

CKM: Material master

MSM: Material master


© SAP AG 1999

Table Structure for Customer - Material Information

KNMT

KNMTK


KNMTK: Header table for increased performance

KNMT: Data table


© SAP AG 1999

Table Structure for Bills of Material

STZUSTKO

STAS

STPO

STPU

MAST TPSTEQST STSTKDST DOST


MAST Material assignment to BOM

EQST Equipment assignment to BOM

KDST Sales order assignment to BOM

DOST Document assignment to BOM

STST Standard object assignment to BOM

TPST Functional location assignment to BOM

STKO BOM header data

STZU Time-independent STL data

STAS BOM item selection

STPO BOM item data

STPU BOM sub-item data


© SAP AG 1999

Table Structure for Sales Activities

VBFA

SADR STXL

VBUV VBPA NAST STXH

VBKA

VBUK


VBUK: Header status and administrative data

VBKA Sales activity

VBUV: Incompletion log

VBPA: SD document: Partner

SADR: Address

VBFA: SD document flows

NAST: Output

STXH: Texts: Header

STXL: Texts: Lines

Logical database:

AK V: Sales documents


© SAP AG 1999

Sales Document Tables - Header

STXH/STXLTexts

VBUKHeader status

VEDAContract

VMVAMatchcodes

NASTOutput

PP-StatusJSTO

VBAKHeader

VBKDBusiness data

VEPAPartners

VAKPAPartner indexes

VBUVIncompletion

VBFADocument flows


VBUK: Header status and administrative data

VBAK: Sales document: Header data

VBKD: Sales document: Business Data

VAKPA: Partner index

VEDA: Contract

VBPA: Partner



VMVA: Matchcodes

STXH: Texts: Header

STXL: Texts: Lines

NAST: Output

JSTO: PP status


© SAP AG 1999

Sales Document Tables - Item

VBKDBusiness data

VEDAContract

VBLBForecast dlv. sched.

VBEPSettings

VBUVIncompletion

VBFADocument flows

VBPAPartners

JSTOPP status

VBBE/SRequirements

VBUPStatus

VEPVGShipping index

KONVConditions

VAPMAMaterial index

VMVAMatchcodes

STXH/STXLTexts

NASTOutput

CO object

Variants

Technical objects

Services

VBAPItem


VBUP: Item status

VBAP: Sales document: Item data

VBKD: Sales document: Business Data

VEBA: Contract

VBLB: Forecast delivery schedules

VBEP: Sales document: Schedule line

VBBE: Individual requirements

VBBS: Summarized requirements



VBPA: Partner

JSTO: PP status

NAST: Output

STXH: Texts: Header

STXL: Texts: Lines

KONV: Conditions


© SAP AG 1999

Section: Sales


© SAP AG 1999

Order Processing

BALANCE-SHEETAssets Liabilities

Docmt Account Debit Credit Docmt Account Debit CreditBank Accounts Payable

2 Accounts Receivable 1’045 2 Taxes Payable 10% 951 Inventories 640 Stockholder Equity

PROFIT AND LOSS STATEMENT

Expenses IncomeDocmt Account Debit Credit Docmt Account Debit Credit

1 Inventory Change 640 2 Sales Rev. (Domestic) 950Sales Rev. (Foreign)RebatesRev. Freight Charges

MM-WM: WarehouseManagement

SO Sales OrderSold-To Party: C1 Ship-To Party: C2Payer: C3 Bill-To Party: C3

Pos. MatNo. Qty Req.Date Net Value10 M1 15 20.08.99 1‘500.-

[Unit Cost (VPRS) = 70.-/Pc ]

SL-No. SL-Date Order Qty Conf. Qty1 20.08.99 15 02 29.08.99 0 73 15.09.99 0 8

Pos. MatNo. Qty Req.Date Net Value20 M2 5 20.08.99 250.-

[VPRS = 30.-/Stk ]

SL-No. SL-Date Order Qty Conf. Qty1 20.08.99 5 02 29.08.99 0 5

LF DeliveryShip-To Party: C2Delivery Date: 29.08.99Picking Date 20.08.99Loading Date: 21.08.99Release Date: 22.08.99

Pos. MatNo. Del.Qty Pick-Qty10 M1 7 7

20 M2 5 5

F2 InvoicePayer: C3 Bill-To Party: C3Invoice Date: 22.08.99

Pos. MatNo. Inv.Qty Net Value10 M1 7 700.-20 M2 5 250.-

---------------Total Net: 950.-+ Taxes 10% 95.-

========Total: 1’045.-

FI

SD

Picking

Goods-Issue

Transfer Order

From: Storage 005To: Storage 916

Goods-Issue.Document

MatNo Qty MvTypM1 7 601M2 5 601

MM

Accnting DocmntWL Goods-Issue

1

Accnting DocmntRV Customer

Invoice

2

FI

MM-IM: InventoryManagement


© SAP AG 1999

Billing

Goodsissue

Reduced sales order stock

Customercust. reqmts

DeliveryProduction

Materials planningOrder

Sales orderstock

Goods receipt

SD MM / PP

Make-To-Order Flow

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.


© SAP AG 1999

MRP runDependant

requirementsbreakdown

Other sales requirements

Quantity, date

Make-To-Order Production without AssemblyProcessing

Sales order K

Planned order Plan

Production order

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.


© SAP AG 1999

Quantity, date Production order

Sales order K

Make-To-Order Production with AssemblyProcessing

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.


© SAP AG 1999

Material 1400-700

Itemcategory group 0001

Material master

Item Category Determination in the Standard Order

Material 1400-200

Itemcategory group NORM

Material master

Standard orderSold-to party 2300

Item Material Item Category

10 1400-200 Normal item TAN120 1400-700 Make-to-order

prod. TAK

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.


© SAP AG 1999

CO-PAProfitability

analysis

Bill. document

CO object forSales order

item

Plan. rev. Plan. costs

Act. rev. Act. costs

PricingSales order

Productionorder(s)

Material samples

Costing

Settlement

Cost Management by Item

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.


© SAP AG 1999

Goods issue for outbound deliveryGoods issue for outbound delivery of of an an individually made materialindividually made material

reducesreduces thethe salessales orderorder stockstock..

Material

1400-700

Quant. Del.

1 unit

Outbound del.

Ship-to party 2300

Goods issueGoods issueSales order stock 0 unit

StockStock

Material 1400-700

Outbound Delivery from Sales Order Stock

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.


© SAP AG 1999

Section: Pricing


© SAP AG 1999

Special Condition Types

Manual order value HM00Net Price PN00Minimum order value AMIW, AMIZMinimum price PMINInterval price PR02Hierarchy discount HI01Pallet discounts KP00, KP01, KP02, KP03Rounding DIFF

Contents:


© SAP AG 1999

Special Condition Types: Course Objectives

Enter order values and net prices manually

Set a minimum price for a material or a minimumvalue for an order

Set interval scales for conditions

Use customer hierarchies for price agreements

See the effect of condition formulas

Round final amounts

At the conclusion of this unit, you will be able to:


© SAP AG 1999

Manual Order Value HM00

Item 1 Item 1

Net item value 1000 Net item value 1000

Net value 975 Net value 975

Item 2 Item 2

Net item value 3000 Net item value 3000

Net value 2925 Net value 2925

deactivated!

Header Header

PR00 Price PR00 Price 4000 4000

HM00 HM00 Order value Order value 3900 3900

deactivated!

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.


© SAP AG 1999

Net Price PN00

deactivated!

OrderOrder

Item 1 M1 1 piece

PN00 Net price 1300 Net item value 1300... ...

Item 1 M1 1 piece

PN00 Net price 1300 Net item value 1300... ...

PR00 Price 1600

K007 Customer discount 160

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

The original conditions are deactivated.


© SAP AG 1999

Minimum Order Values AMIW and AMIZ

Order headerOrder headerCustomer C1 Price group 02Net item value 160AMIW 200AMIZ 40Net value 200

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

Item 10Item 10

Net item value 100AMIW 125 75AMIZ 25 15Net value 125


Item 20Item 20



Condition record AMIWCondition record AMIW

Price group 02 DM 200Price group 02 DM 200

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.


© SAP AG 1999

Minimum Price PMIN

OrderOrder

Item 1 M1 1 piece

PR00 Price 1600

K007 Customer discount 160-

Net item value 1500

Item 1 M1 1 piece

PR00 Price 1600

K007 Customer discount 160-

Net item value 1500

PMIN Minimum price 60

Condition record PMINCondition record PMIN

Material M1 1500Material M1 1500

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.


© SAP AG 1999

Interval Price PR02

OrderOrder

Customer C1 Item 10: M1 25 pcPR02 $ 5/piece $ 50PR02 $ 4/piece $ 40PR02 $ 3/piece $ 15Net item value $ 4.20/piece $ 105

Customer C1 Item 10: M1 25 pcPR02 $ 5/piece $ 50PR02 $ 4/piece $ 40PR02 $ 3/piece $ 15Net item value $ 4.20/piece $ 105

Condition record PR02Condition record PR02Customer C1 Material M1to 10 pieces $ 5/piece

20 pieces $ 4/piece9999999 pieces $ 3/piece

Customer C1 Material M1to 10 pieces $ 5/piece

20 pieces $ 4/piece9999999 pieces $ 3/piece

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.


© SAP AG 1999

Customer Hierarchy

Head officeMillerMiller

Customer 2743 Customer 2744

Uniquenode number

Customer2742

8200

SouthMillerMiller

8100

NorthMillerMiller

8120

CentralMillerMiller

8110

North east

8000

MillerMiller

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 multi-level 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. Create master records for each node.

2. Assign the nodes to each other.

3. 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.


© SAP AG 1999

Hierarchy Path

Customer 2743 Customer 2743

MillerMiller

North east

1000 10 00Pricing X

8110

MillerMiller

South

1000 10 00Pricing

8200

MillerMiller

Customer 2744Customer 2744

Customer 2742Customer 2742

Organizationaldata

Organizationaldata

Sold-to party: 2743

Node/ Hierarchy step Partnercustomer functions

8000 Top level 1D8100 Second level 1C8120 Third level 1B2743 Fourth level AG

Hierarchy path

NorthMillerMiller

1000 10 00 Pricing X

8100

8000

Pricing X

1000 10 00

81201000 10 00Pricing

Central

Head office

MillerMiller

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.


© SAP AG 1999

Hierarchy Discount HI01

OrderOrder

Customer 2743 Item 10: M1 10 pcPR00 Price $ 100HI01 Discount 8- %...

Customer 2743 Item 10: M1 10 pcPR00 Price $ 100HI01 Discount 8- %...

Condition record HI01Condition record HI01Hierarchy:

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

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

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.


© SAP AG 1999

Pallet Discount KP00

Order 1Order 1

Material M1 50 CAR$ 5-


Order 2Order 2



Order 3Order 3



Condition record KP00

$ 5- Discount per pallet


$ 5- Discount per pallet

Material master M1Material master M1

50 CAR = 1 pallet50 CAR = 1 pallet ^ ^

+

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.


© SAP AG 1999

Incomplete Pallet Surcharge KP01

Order 1Order 1

Material M1 50 CAR Material M1 50 CAR

Order 2Order 2

Material M1 70 CAR$ 50

Material M1 70 CAR$ 50


$ 50 per pallet


$ 50 per pallet

Material master M1Material master M1


+

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.


© SAP AG 1999

Mixed Pallet Discount KP02

Order 1Order 1Condition record KP02

from 1 pal $ 10-from 2 pal $ 20-


from 1 pal $ 10-from 2 pal $ 20-

Material master M1, M2Material master M1, M2


+

Header: KP02 $ 10-

M1 20 CARM2 30 CAR

Header: KP02 $ 10-

M1 20 CARM2 30 CAR

Order 2Order 2

Header: KP02 $ 10-

M1 20 CARM2 40 CAR

Header: KP02 $ 10-

M1 20 CARM2 40 CAR

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.


© SAP AG 1999

Surcharge for Incomplete Mixed Pallets KP03

Order 1Order 1Condition record KP03

from 1 pal $ 5


from 1 pal $ 5

Material master M1, M2Material master M1, M2


+

Header:

M1 20 CARM2 30 CAR

Header:

M1 20 CARM2 30 CAR

Order 2Order 2

Header: KP02 $ 5

M1 20 CARM2 40 CAR

Header: KP02 $ 5

M1 20 CARM2 40 CAR

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).


© SAP AG 1999

Rounding DIFF

Order headerOrder header

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

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

Order headerOrder header

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

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

Table 001RTable 001RCCod Curr Rounding unit1000 DM 5CCod Curr Rounding unit1000 DM 5

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.


© SAP AG 1999

Unit Summary

Enter order values and net prices manually

Set a minimum price for a material or a minimumvalue for an order

Set interval scales for conditions

Use customer hierarchies for price agreements

See the effect of condition formulas

Round final amounts

You are now able to:


© SAP AG 1999

Statistical Condition Types

Cost VPRSCash discount SKTOExpected customer price EDI1 and EDI2

Contents:


© SAP AG 1999

Determine costs and cash discount amountsstatistically in pricing

Describe how expected customer pricestransferred via EDI are used


Statistical Condition Types: Course Objectives


© SAP AG 1999

Cost VPRS

Materialvaluationsegment

Condition category G

Cost

Statistical

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.


© SAP AG 1999

Cash Discount SKTO

Table T052

30 days

Condition category E

Cash discount SKTO

33 %%

Statistical

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.


© SAP AG 1999

Customer Expected Prices EDI1 and EDI2

Incoming IDoc

Condition category J

Customer expected price

StatisticalItem 10 M1 1 piece

Net item value $ 1500 / pieceEDI 1 $ 1400 / piece... ...

Item 10 M1 1 piece

Net item value $ 1500 / pieceEDI 1 $ 1400 / piece... ...

IncompletionIncompletion log log

Allow required customer price

Save

OrderOrder

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.


© SAP AG 1999

Unit Summary

Determine costs and cash discount amountsstatistically in pricing

Describe how expected customer pricestransferred via EDI are used



© SAP AG 1999

Section: Shipping


© SAP AG 1999

Dangerous Goods and their Transportation

Dangerous goods

are materials or items, which because oftheir naturetheir propertiestheir 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)

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).


© SAP AG 1999

Dangerous Goods Management in LogisticsExecution

Dangerous goodschecks

e. g. Shipment ofmaterial on mode

of transport categorypermitted?

Dangerous GoodsManagement

Order Outbounddelivery

Trans-portation

PickingPackingShipping docsGoods Issue

Dangerous goodsdocs

e.g. delivery note, packinglist, tremcard, dangerous

goods label .......................... .......................... ..........................

. . . . . . . . . . . . . .

.......................... .......................... ..........................

. . . . . . . . . . . . . .

.......................... .......................... ..........................

. . . . . . . . . . . . . .

Dangerous goods master

Dangerous goods master

331088

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.


© SAP AG 1999

Dangerous Goods Master Data

Material master

Dangerous goodsindicator profile:• Relevant for dangerous goods• Relevant for DG docs• Relevant for checks

Dangerousgoodsmaster

MaterialDangerous goods regulation

(regulations modeled insystem)

Substancedatabase

Substance and reg. dataMaintenance of:• Properties• Compositions• Classification

Material-substance

assignment

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.


© SAP AG 1999

Process for Dangerous Goods Checks

Checklog

SD documentprocessing

CallDG checks

Process thereactions

Call checklog

Processand determinesequence Process

check modules

12345

Checkprocessor

SD - DGM interface

Call checks

Return codes

Dangerous goodschecks

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.


© SAP AG 1999

Dangerous Goods Checks in the DeliveryDocument

Make changes Log

Trigger dangerous goods check

Determining data andprocessing the DG checks:

Check 1Transport permitted

Materials must not bepacked together

OverallOverall reaction reaction::PackingPacking not not

permittedpermitted

Check 2

Automatically Manually

Outbound delivery

Ship-to party: 7341Shipping point: 1200Sales org.: 1000Delivery type: LF

Item 1 R-DG89 10 kgRoute: USA east

Item 2 T-DG43 31 pcRoute: USA east

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.


© SAP AG 1999

Structure of the DELVRY02 Delivery Interface

Control

Partner

Dates

Texts

Foreign trade

Routes

Shipping Unit

Delivery item

DeliveryDelivery header header Delivery itemDelivery item

Control

Serial numbers

Batch characteristics

Reference data

Texts

Configuration

Foreign trade

Dangerous goods data Dangerous goods data

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.


© SAP AG 1999

Communication Scenarios

SD delivery processing

Shipping confirmation from service agent

Shipping notification to customer (LAVA)

Notification fromforward.agent (CANO)

Warehouse order tointernal whse (WSOR)

Shipping order toservice agent (SHOR)

MM delivery processing Shipping notificationfrom vendor

Warehouse notification frominternal warehouse

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).


© SAP AG 1999

12.6. 10.05 MA Picked up12.6. 10.55 KA Load transferred12.6. 12.02 S Delivered

Tracking no.Routing infoService codeProduct code

Express Delivery Companies

Service agentspecific information

Service agentspecific labels

EXPRESS

49211172

XXL 563Route AB

Manifest

Parcel tracking

Delivery list

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


© SAP AG 1999

Outbound Delivery Using Express DeliveryCompany

Ship-to party

Order confirmation

Purchase orderPurchase order

Shipper

Order

Outbound delivery

Optional:Shipping unit

Express deliverycompany

Optional:Transportation

Tracking no.Routing

Service codeetc.Optional:

Shipping unit

Inbound delivery Delivery noteTracking no.

Goods issue

Tracking no.

Manifest

Tracking statu

sTracking status

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.


© SAP AG 1999

Parcel Tracking

Where is delivery80001234 shippedby the expressdelivery companyQUICKLY?

Parcel trackingParcel tracking

Sales documentPurchasing documentDeliveryShipment numberShipping unitTracking number

80001234

Parcel tracking

ChangeChange delivery delivery 80001234:80001234: HeaderHeader details details

What service code wasdetermined?

What is the trackingnumber of the delivery?

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.


© SAP AG 1999

Details of Parcel Tracking

Shipping Delivery 80005432

Parcel trackingParcel tracking

Service code 99 6543 DESender number 777333Weight code 22Tracking number 123886622

Express delievery data fields

Not packed

Floppy disk drive R-1150 10 Pc

QuantityExpr. field Track.stat. Location

Tracking statusLondon, sh.pt 3000 Picked up LondonFrankfurt Load transferred FrankfurtMunich Delivered Munich

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.


© SAP AG 1999

Express Delivery Cockpit

COCKPITCOCKPIT

Weight codes

Service codes

Master datamaintenance

Product codes

Number range

URLs

Routing info

Tracking status

Data provider

Control Set upMetadata

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.


© SAP AG 1999

Section: Billing


© SAP AG 1999

Basic Accounting Principles

Double-Entry Accounting

Balance sheet accounts

P&L accounts

SD Example

MM Example


© SAP AG 1999

Double-Entry Accounting

Account name

CreditDebit

• 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

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.


© SAP AG 1999

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

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.


© SAP AG 1999

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

SD Example

Sales order 10 pieces at $ 12 per piece

Goods issue: 10 pieces delivered, standard price $ 10 per piece

Invoice: 10 pieces at $ 12 per piece

Incoming payment: $ 120


© SAP AG 1999

SD Example: Postings

Goods issue:Material usage

(Expenses)

100

Stock(Assets)

100

Sales revenue (Revenues)

120

Receivables(Assets)

120

Invoice:

Incoming payment:Receivables

(Assets)

120

Bank(Assets)

120

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.


© SAP AG 1999

MM Example

Purchase order: 10 pieces at $ 10 per piece

Goods receipt: 10 pieces received, standard price $ 10 per piece

Invoice: 10 pieces at $ 10 per piece

Payment: $ 100

VendorVendor


© SAP AG 1999

MM Example: Postings

Goods receipt:Stock

(Assets)

100

GR/IR clearing account

100

GR/IR clearing account

100

CreditorsPayable

100

Invoice:

Bank(Assets)

100

CreditorsPayable

100

Payment:

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.


© SAP AG 1999

Section: Transportation


© SAP AG 1999

Internet Scenarios - Tendering for Service Agents

Forwarding agentShipper

Acceptance / rejection

Status

Tender / quotation

Detailed information

Internet Internet

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.


© SAP AG 1999

Tendering in the Shipment Document

Shipment

Tender

Tend. status

Acc.cond/rej.reasonTendering text

Tender status

Not offered to any forw. agent / offer cancelledOffered by shipperAccepted by forwarding agentAccepted by forwarding agent with conditionsRejected by forwarding agentConfirmed by shipperException signalized by forwarding agent

Tend. status

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.


© SAP AG 1999

Overview of Shipment Cost Calculation

Pricing procedure

1. Basic freight FB00

2. Discount 1 FD00

3. Discount 2 FD10

Condition type :FB00Access sequence:MATK

Records for cond. type FB00No valid record availableValid record available

1300 USD 1 t or more1100 USD 10 t or more1000 USD 20 t or more

Scale

Access sequence:MATKCondition tables:1. Service agent/tariff zone/ freight class2. Service agent/tariff zone

Shipment costs

ConditionsFrom NY to WA 10 t

FB00 1100 USDFD00 -100 USDFD10

Basic freightDiscount 1Discount 2 -5 %

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.


© SAP AG 1999

Shipment cost item Service agent

Pricing procedureSDFC00:

Transportation planningpoint Shipping type

FB00 Shipment cost

FB10 Flat rate

FD00 Discount - absolute

FD10 Discount - percentage

Net value

...

Determining the Pricing Procedure

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.


© SAP AG 1999

Condition Records for Shipment Costs

Validity periodValidity period07/01/1999 - 12/31/200207/01/1999 - 12/31/2002

1000 kg 10 USD pro 100 kg10000 kg 9 USD pro 100 kg20000 kg 8 USD pro 100 kg

Condition type: FB00 Basic freight

Service agent: 1120

Tariff zone - departure: DE20

Tariff zone - destination: DE80

Freight class: B

Level at which the condition

is defined

toScale:

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.


© SAP AG 1999

Multidimensional Freight Agreement

MAX

to100

to5 MIN

Weight (TO)

Dis

tanc

e (M

ile)

2000USD

230USD/TO

250 USD

450 USD

800 USD

185USD/TO

152USD/TO

127USD/TO

to10

to20

to25

3500USD

6000USD

7100USD

336USD/TO

295USD/TO

252USD/TO

213USD/TO

435USD/TO

373USD/TO

333USD/TO

285USD/TO

to300

to500

Freight Cost Agreement with Service Agent "Ontime"

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.


© SAP AG 1999

Multidimensional Condition Types

Condition type FM00: Multidimensional

Assigned scales:

Scale with basisD = Gross weight

Scale values (to):

Distance (mil):

100300500

Minimum can be defined

Scale values (to):

Gross weight (TO):5

102025

Scale with basisR = Distance

Maximum can be defined

To represent multi-dimensional freight charges, you must define a condition type with the multi-dimensional 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.


© SAP AG 1999

Mass Maintenance of Shipment Condition Records

ConditionCondition type type FB00: FB00:

Service agent: 2266Date: 01/10/00Tf zone point of dep: US10Tf zone destination: US80 to US99

Shipping point 5000Tariff zone US10

Eastquick Shipping

We areincreasingour shipmenttarif as ofOct. 1, 2000by 5%

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.


© SAP AG 1999

PricingPricing procedure procedure SDFC00: SDFC00:00010001 Weight Weight--depdep.. basic freight basic freight00050005 Insurance costs Insurance costs0002 Basic0002 Basic freight freight - - shipping unit shipping unit

Condition type 0001

Calculation base:

Delivery item

Condition type 0002

Calculation base:

Shipping unit

Condition exclusion procedureCondition exclusion procedureExclusion group A Exclusion group B

Net value: 1358 USD NetNet value: value: 1290 USD1290 USD

Cheaper

Shipment Comparisons

Only choose the cheaper of the two freight types

Exclusion procedure

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.


© SAP AG 1999

Break Weight Calculation

Shipment

Mat.1 9 t 5 to 10: 6 USD / 100kg10 to 15 t: 5 USD / 100kg

Shipment cost agreement

Calculation 1

Shipment costs: 540 USD

Cheaper

9 x 60 USD/TO = 540 USD

Calculation 2

10 t x 50 USD/TO = 500 USD

Shipment costs: 500 USD

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.


© SAP AG 1999

Break Weight Calculation Customizing

Exclusion procedure

Condition record for FS00

Condition type FS00 Condition type FS10

Scale 51

Scale 51

Calculation withcorresponding scale level

Calculation with the nexthigher scale level

Ref. cond. type: FS00Break wt.

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.


© SAP AG 1999

12.6. 10.05 MA Picked up12.6. 10.55 KA Load transferred12.6. 12.02 S Delivered

Tracking no.Routing infoService codeProduct code

Express Delivery Companies

Service agentspecific information

Service agentspecific labels

EXPRESS

49211172

XXL 563Route AB

Manifest

Parcel tracking

Delivery list

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


© SAP AG 1999

Payment Differences and Special Commitments:Business Scenario

Sometimes there are deviations between theamount of the incoming payments and the existingreceivables. When posting the residual items, youremployees enter a difference code. Here, disputedresidual items should not influence thecommitments in credit management.

Some customers make payments for orders. Theseincoming amounts should reduce the amount ofcredit limit used.


© SAP AG 1999

Payment Differences - Disputed Items

Incomingpayments

CCA data CCA data

Incoming payments TILIA Corp.Incoming payments TILIA Corp.

Open itemsOpen items

Incoming paymentsIncoming payments

DifferenceDifference

$12,000$12,000

$11,000$11,000

$1,000$1,000 Reason 01Reason 01

Customizing: Financial Accounting - Incoming paymentsCustomizing: Financial Accounting - Incoming payments

Difference reasonDifference reason DisputedDisputed0101 YesYes

0202 NoNo

Tilia Corp.Tilia Corp.

Receivables: $12,000Receivables: $12,000


Receivables: 0Receivables: 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.


© SAP AG 1999

Payment Differences - Undisputed Items

Incomingpayments

CCA data CCA data

Incoming payments TILIA Corp.Incoming payments TILIA Corp.

Open itemsOpen items

Incoming paymentsIncoming payments

DifferenceDifference

$12,000$12,000

$11,000$11,000

$1,000$1,000 Reason 02Reason 02


Difference reasonDifference reason DisputedDisputed0101 YesYes

0202 NoNo





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).


© SAP AG 1999

Receivables from Special G/L Transactions

CCA data


Account type: D = CustomerAccount type: D = CustomerSpecial general ledger indicator: A = PaymentSpecial general ledger indicator: A = Payment

Credit limit relevance: xCredit limit relevance: x


Payment : $2,000Payment : $2,000


Total commitments $10,000Total commitments $10,000

Receivables: $12,000Receivables: $12,000Special commitments: $- 2,000Special commitments: $- 2,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).


© SAP AG 1999

Process Chain for Payment Card Processing

AuthorizationClearinghouse

Settlement

Order

Card info

Outbound delivery

Billingdocument

Card info

Card info

Check validity of authorizationAuthorization

Authorizationinformation

Acc. doc.

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.


© SAP AG 1999

Payment Card Authorization with an ExternalSystem

Authorization

Billing document

Card info

Card info

Authorizationinformation

Clearinghouse

Settlement

POS

Acc. doc.

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.


© SAP AG 1999

Payment Card Data in the Customer Master record

VISA 4100000000000001 X 01.01.1997 31.12.2002

MC 5100000000000008 01.01.1996 31.12.2001

Best BankBest Bank VISAVISA

4100 0000 0000 00014100 0000 0000 0001

Valid from 01/97 to 12/2002Valid from 01/97 to 12/2002K. KingK. King

Euro Bank MCEuro Bank MC

5100 0000 0000 00085100 0000 0000 0008

Valid from 01/96 to 12/2001Valid from 01/96 to 12/2001K. KingK. King

Card type Card number Default Block reason Valid from Valid to

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.


© SAP AG 1999

Data Transfer to the Clearing House

Converter1

Clearinghouse

2

Converter2

Clearinghouse

3

Converter3

SAP standard interface

Clearinghouse

1

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.


© SAP AG 1999

Authorization

0 1 2 3 4

One day before delivery creationValid for 14 days

Authorization horizon

Validity period (14 days)

Next material availability dateby schedule lineOrder entry

Days

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.


© SAP AG 1999

Customer 5875958759Invoice #900001

Customer: 5875958759KingKing

Order value $50

Invoice #900105

Customer: 9877598775KaiserKaiser

Order value $100

VISA 4200000000000000

Clearing house

Sales revenue

50 50

Customer 9877598775

100 100

Automatic offsetting entryto the customer account

Debiting of clearing houseaccount and posting of salesrevenue

50

100

100

50

VISA 4100000000000001

Settlement(1)

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).


© SAP AG 1999

Postings to the clearinghouse account are cumulatedand credited

Settlement triggered viainterim account

100

50

100

50 150

Interim bank account

150

The cumulative value isposted to thecorresponding interim bankaccount

Clearing house

Clearing house

Interim bank accountBEFORE

AFTER

Backgroundprocessing#5584

Settlement (2)

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.


© SAP AG 1999

Processing Blocked Documents

Release, rejection and forwarding of blockeddocuments

Reassignment

Information functions

Contents:


© SAP AG 1999

Processing Blocked Documents: Unit Objectives


Name the different processing functions forblocked sales documents and describe theireffects

Explain how to access the different informationsources used to decide which form of processingis applied to blocked documents


© SAP AG 1999

Processing Blocked Documents: BusinessScenario

Usually your credit representatives process atregular intervals their worklist of documentsblocked for credit, for example once a day

Since the decision as to whether a blockedtransaction can be released or must be cancelleddepends on several factors, they need variousinformation functions


© SAP AG 1999

Release

Order: 125

OK

Order: 125

Blocked documents

Blocked

Released

Released documents

Release

Order: 125SP : Tilia Corp.SP : Tilia Corp.

Credit status: ACredit status: A

SP : Tilia Corp.

Credit status:Credit status: BB

SP : Tilia Corp.SP : Tilia Corp.

Credit status:Credit status: DD

-- Order 125--

-- Order 125--

-- Order 125--

-- 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.


© SAP AG 1999

Releasing Documents and Carrying Out AnotherCheck

Order

Release

on June 1

A new check is carried out when:a) The amount is increasedb) The time limit is exceeded

Deviation: 10%Number of days: 5Deviation: 10%Number of days: 5

CCACCA Risk categoryRisk category Operat.Operat.

Order value:Order value:Credit status:Credit status:


BB$10,000$10,000 Order value:Order value:

Credit status:Credit status:


DD$10,000$10,000

Order changedon June 1

Order value:Order value:Credit status:Credit status:


BB$12,000$12,000

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.


© SAP AG 1999

Rejection

List: Blocked documents

Rejection

Order 918

Doc. no. credit value statusDoc. no. credit value status

BBItem 10:Item 10:


Reason for rejectionReason for rejection

Item 20:Item 20:Item 30:Item 30:

Credit Limit ExceededCredit Limit Exceeded



-- 918--

-- 918--

$10,000$10,000


© SAP AG 1999

Information Sources Specific to CreditManagement

CCA data

Limit:Limit:

Customer:Customer:

$50,000$50,000

CCA:CCA: EuropeEuropeTilia Corp.Tilia Corp.

Credit master sheetCredit overview

Early warning list Master data list

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.


© SAP AG 1999

Information Sources - General

CCA data

Limit:Limit:

Customer:Customer:

$50,000$50,000

CCA:CCA: EuropeEuropeTilia Corp.Tilia Corp.

Line itemsLine items

Account summaryAccount summary

Customer master recordCustomer master record

Last paymentLast payment

Oldest items dueOldest items due

Sales Info SystemSales Info System

FI Info SystemFI Info System Count dataCount data

Dunning dataDunning 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.


© SAP AG 1999

Processing Blocked Documents: Summary

Name the different processing functions forblocked sales documents and describe theireffects

Explain how to access the different informationsources used to decide which form of processingis applied to blocked documents



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.


1-7 Reject the blocked sales document. The delivery should remain blocked.


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


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)


© SAP AG 1999

Materials Management

Processes inProcurement

LO020 5 days

Inventory ManagementLO510 3 days

Invoice Verification3 daysLO515

Consumption-BasedPlanning andForecasting

LO525 2 days

Procurement ofExternal Services

LO540 2 days

Foreign TradeLO640 3 days

QM in ProcurementLO715 2 days KANBAN

LO235 2 days

Batch ManagementLO955 3 days

Pricing in Purchasing2 days LO521

Cross-FunctionalCustomizing in MM

5 days LO550

Purchasing Details andOptimization

LO520 3 days

Cross-ApplicationBusiness Processes inSD and MM

LO925 2 days

Level 2 Level 3

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: all subjects

LO510: all subjects

LO511: Physical Inventory: Overview, Cycle Counting and Inventory Sampling

LO515: nearly all subjects

LO520: ca. 80 % (no vendor evaluation and no Material Part Numbers in the academy)

LO521: overview & important details

LO525: ca. 60 % (there is no forecast in the academy)

LO540: Overview in week 1. For further details, please visit this course.

LO550: all subjects

LO955: 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.


© SAP AG 1999

Financial Accounting

Financial Accountingand Reporting

AC010 5 days Real EstateManagement

AC290 5 days

Asset AccountingAC305 4 days

Special Purpose LedgerAC220 5 days

Human Resources

HR050 5 days

Funds Management:Processes, Organizationand Configuration

AC700 5 days

EC-CS:Consolidation Functions

AC660 5 days

FI-LC:Consolidation Functions

*AC240 5 days

R/3 For Auditors

**AC900 4 days

Inflation Accounting

CA550 3 days

Level 3Level 2C

onsolidationFinancial ClosingAC205 2 days

Additional FinancialFunctionality

AC260 2 days General Ledger/Accounts Payable/Accounts ReceivableConfiguration

AC200 5 days

Travel ManagementTravel Expenses

AC270 3 days Travel ManagementTravel Planning

AC275 1 day

** from July 2000 on


© SAP AG 1999

Controlling

Cost Managementand Controlling

AC040 5 days

Cost CenterAccounting

AC410 3 days

Product Cost PlanningAC505 3 days

Profitability AnalysisAC605 5 days

Profit CenterAccounting

AC610 2 days

Executive InformationSystem (EIS) 1 -Reporting

AC615 2 days

Level 2 Level 3

Cost CenterAccounting:Extended Functionality

AC412 2 days

Activity Based CostingAC420 2 days

Cost Object Controllingfor Products

AC510 3 days

Transfer PricesAC650 2 days

Executive InformationSystem (EIS) - Settingup the System

AC620 2 days

Overhead OrdersAC415 2 days

Cost Object Controllingfor Sales Orders

AC515 3 days

Actual Costing /Material Ledger

AC530 2 days

Executive InformationSystem (EIS) 3 -Business Planning

AC625 1 day


© SAP AG 1999

Human Resources 4.6 (1)

Level 3Level 2

Human Resources

HR050 5 days

Employee Self ServiceHR250 3 days

OrganizationalManagement

HR505 3 days

Travel ManagementTravel Expenses

AC270 3 days

CompensationManagement

HR540 3 days

Reporting inHR

HR580 3 days

Training and EventManagement

HR515 3 days

Time EvaluationHR310/311 5 days

Configuration ofMaster Data

HR305 3 days

Configuration of TimeRecording

HR306 3 days

BenefitsAdministration

HR325 3 days

RecruitmentHR315 3 days

seeHR2

Configuration of HRSystem Controls

HR307 2 days

Programming in HR

HR350 5 days

Technical Topics inHuman Resources

HR530 3 days

CATS The CrossApplication Time Sheet

CA500 2 days

PersonnelDevelopment

HR510 3 days


© SAP AG 1999

Human Resources 4.6 (2)

Human Resources

HR050 5 days

Payroll Reporting(Country-Specific)

HR7xx 2 days

Level 2 Level 3

Payroll Configuration

HR400 5 days

Country-SpecificPayroll

HR4xx 3 days

Configuration ofMaster Data

HR305 3 days Introductionto Payroll

HR390 2 days


© SAP AG 1999

Logistics Execution

Transportation

LO611 3 days

Processes inLogistics Execution

LO140 3 days

Level 2 Level 3

Additional Topics inWarehouseManagement

LO531 3 days

Shipping

LO610 2 days Cross-FunctionalCustomizing in SD

LO650 3 days

WarehouseManagement

LO530 3 days


© SAP AG 1999

Sales and Distribution

Level 2 Level 3

Processes in Salesand Distribution

LO150 5 days

ShippingLO610 2 days

Pricing in SDLO620 3 days

TransportationLO611 2 days

Foreign TradeLO640 3 days

Credit and ReceivablesRisk Management

LO645 2 days

Cross-ApplicationBusiness Processesin SD and MM

LO925 2 days

SalesLO605 4 days

Sales SupportLO604 1 day

Sales WorkshopLO606 1 day

Cross-FunctionalCustomizing in SD

LO650 3 days

BillingLO615 2 days


© SAP AG 1999

Production Planning

Level 2 Level 3

ManufacturingPlanning &Execution forDiscrete & Repetitive

LO050 5 days

EngineeringChangeManagement

LO980 3 days

BatchManagement

LO955 3 days

KANBAN

LO235 2 days

Classification

LO985 3 days Special Features ofLIS in Production

LO275 2 days

Logistics InfoPlanning

LO935 2 days

CAP Calculation ofStandard Values

LO720 2 days RepetitiveManufacturing

LO225 3 days

Capacity Planning

LO230 5 days

LogisticsInformationSystem (LIS)Reporting

LO930 2 days

Basic DataPart 2

LO206 3 days Basic Data forDiscreteManufacturing

LO205 3 days

ProductionOrders

LO215 5 days

ProductionPlanning

LO210 5 days

VariantConfiguration Part 1

LO990 5 days VariantConfiguration Part 2

LO991 3 days


© SAP AG 1999

Enterprise Controlling

Cost Managementand Controlling

AC040 5 days

Financial Accountingand Reporting

AC010 5 days

Profit CenterAccounting

AC610 2 days

EC-CS: ConsolidationFunctions

AC660 5 days

Financial ClosingAC205 2 days

E C - E I S:Executive Information System

E C - B P:Business Planning

E C - P C A: Profit Center Accounting

Level 3

Special PurposeLedger

AC220 5 days

E C - C S: ConsolidationConsolidation ofInvestments

Executive InformationSystem (EIS) 3 -Business Planning

AC625 1 day Executive InformationSystem (EIS) 1 -Reporting

AC615 2 days

Level 2

Controlling Enterprise Controlling Financial Accounting

Executive InformationSystem (EIS) 2 -Setting up the System

AC620 2 days

EC-CS: IntegrationAC665 3 days

tasd41

Documents

automatic

xxl 563route

miller head

brand names

moving average

express delivery

express delivery

eliminates