Professional Documents
Culture Documents
TASD41
Sales & Distribution Appendices
SAP AG 1999
System R/3, Sales and Distribution - Appendices Release 4.6B April 2000 Material number 50037387
Copyright
Copyright 2000 SAP AG. All rights reserved. Neither this training manual nor any part thereof may be copied or reproduced in any form or by any means, or translated into another language, without the prior consent of SAP AG. The information contained in this document is subject to change and supplement without prior notice. All rights reserved.
SAP AG 1999
Trademarks: Microsoft , Windows , NT , PowerPoint , WinWord , Excel , Project , SQL-Server , Multimedia Viewer , Video for Windows , Internet Explorer , NetShow , and HTML Help are registered trademarks of Microsoft Corporation. Lotus ScreenCam is a registered trademark of Lotus Development Corporation. Vivo and VivoActive are registered trademarks of RealNetworks, Inc. ARIS Toolset is a registered Trademark of IDS Prof. Scheer GmbH, Saarbrcken Adobe and Acrobat are registered trademarks of Adobe Systems Inc. TouchSend Index is a registered trademark of TouchSend Corporation. Visio is a registered trademark of Visio Corporation. IBM , OS/2 , DB2/6000 and AIX are a registered trademark of IBM Corporation. Indeo is a registered trademark of Intel Corporation. Netscape Navigator , and Netscape Communicator are registered trademarks of Netscape Communications, Inc. OSF/Motif is a registered trademark of Open Software Foundation. ORACLE is a registered trademark of ORACLE Corporation, California, USA. INFORMIX -OnLine for SAP is a registered trademark of Informix Software Incorporated. UNIX and X/Open are registered trademarks of SCO Santa Cruz Operation. ADABAS is a registered trademark of Software AG
The following are trademarks or registered trademarks of SAP AG; ABAP/4, InterSAP, RIVA, R/2, R/3, R/3 Retail, SAP (Word), SAPaccess, SAPfile, SAPfind, SAPmail, SAPoffice, SAPscript, SAPtime, SAPtronic, SAP-EDI, SAP EarlyWatch, SAP ArchiveLink, SAP Business Workflow, and ALE/WEB. The SAP logo and all other SAP products, services, logos, or brand names included herein are also trademarks or registered trademarks of SAP AG. Other products, services, logos, or brand names included herein are trademarks or registered trademarks of their respective owners.
Appendices
SAP AG 1999
(C) SAP AG
TASD41
1-1
Appendix
This unit contains extra materials to be used for reference purposes This material is not part of the standard course Therefore the material might not be used during the course
SAP AG 1999
(C) SAP AG
TASD41
1-2
Content: Appendix
User Roles Frequently Used Menu Paths Table Structures Special Sales Special Pricing
Special Shipping Special Billing Special Transportation Special Credit/Risk Management Overview Standard Courses
SAP AG 1999
(C) SAP AG
TASD41
1-3
Sales manager Sales representative Personal responsible in sales order processing Personal responsible in invoice processing
SAP AG 1999
In order that SAP users can work with user-specific and workplace-related menus, the above user roles are already defined for Sales and Distribution.
(C) SAP AG
TASD41
1-4
Shipping manager Person responsible for shipping Person responsible for transportation Shipment costs accounts payable clerk Shipment costs manager Transportation manager Transportation planner Person responsible for warehouse management Warehouse manager Warehouse worker
SAP AG 1999
In order that SAP users can work with user-specific and workplace-related menus, the above user roles are already defined for Sales and Distribution.
(C) SAP AG
TASD41
1-5
Activity
Menu path
Master data
Products Material Other material Display Products Bills of Material Material Material BOM Display Conditions Display Output Sales document Display Bill of
Display condition records (prices, discounts/surcharges, free goods, etc.) Display output master records Customer-Material-Information
Order processing
Create/change/display order Create/change/display inquiry Create/change/display quotation Create/change/display scheduling agreement Create/change/display contract Display list of orders Display list of incomplete orders
Logistics Sales
Order
Create/Change/Display Inquiry Create/Change/Display Quotation Create/Change/Display Scheduling agreement Create/Change/Display Contract Create/Change/Display Information system of sales documents Information system incomplete orders Orders Orders List List of
(C) SAP AG
TASD41
1-6
Shipping
Billing
Logistics Billing
Create/change/display billing document Display financial accounting documents
(C) SAP AG
TASD41
1-7
Customizing
Access
Maintain division
Sales and Distribution Sales Organization - Assign sales organization to company code Sales and Distribution Assign distribution channel to sales organization Sales and Distribution to sales organization Sales and Distribution area Assign division Set up sales
(C) SAP AG
TASD41
1-8
Sales office
Sales and Distribution Sales group - Assign sales office to sales group Sales and Distribution Assign sales Organization - Distribution channel plant
Master data
Common distribution channels Common divisions Maintain account group
Sales and Distribution Master data Define common distribution channels Sales and Distribution Master data Define common divisions Logistics General Business Partner Customers Control Define account groups and field selection for customers Logistics General Material master Basic settings Material types Define attributes of material types
Basic functions
Define pricing procedure Define free goods procedure Define output
Basic
Free Goods Condition Technique for Free Goods Output Control Output Determination Output Determination using Condition Technique ... Material Determination Listing/Exclusion ... ...
Define material determination procedure Define listing/exclusion procedure Partner determination Incompletion procedure
Sales
Header
Sales document header Define sales document types Sales document header Assign sales area to sales document types 1-9
Item
Sales document item categories Sales document item categories Schedule lines categories Schedule lines categories
Schedule line
Sales and Distribution Sales Maintain copying control for sales documents Contracts Contracts Value contracts Contract data ... ...
Shipping
Determine shipping points Document control in shipping Set up delivery blocks Lean WM
Logistics Execution
Shipping
Basic Shipping Functions Shipping and Goods Receiving Point Determination Deliveries ...
Billing
Billing
Define billing document types Set up billing blocks Copying control for billing documents
System
(C) SAP AG
TASD41
1-10
(C) SAP AG
TASD41
1-11
KNA1
KNVK
KNVV
KNVA
KNVI
KNVS
KNVP
KNVD
KNVL
SAP AG 1999
These tables contain the following information: KNA1: KNVK: KNVV: KNVA: KNVI: KNVP: KNVD: KNVL: KNVS: Customer master, general information Contact person Customer master, sales area Unloading points Tax indicators Partner functions Documents Licenses Shipping data
(C) SAP AG
TASD41
1-12
KNVH
SAP AG 1999
This table contains customer hierarchies. You create customer hierarchy nodes as customer master data.
(C) SAP AG
TASD41
1-13
MARA
MAKT
MARM
MVKE
MLAN
MAEX
MCH1
MARC
MBEW
MLGN
MVER
MAPR
MCHA
MARD
MLGT
MCHB
SAP AG 1999
These tables contain the following information: MARA: MAKT: MARM: MVKE: MLAN: MAEX: MARC: MBEW: MLGN: MLGT: MVER: MAPR: MARD: MCH1: MCHA: MCHB: General material data Short texts Conversion factors Sales data (for each sales organization and distribution channel) Sales data (for each country) Export licenses Plant data Valuation data Warehouse management inventory data Warehouse management inventory type data Consumption data Pointers for forecast data Storage location data Cross-plant batches Batches Batch stocks
Logical databank for material master: CKM: MSM: (C) SAP AG Material master Material master TASD41 1-14
KNMTK
KNMT
SAP AG 1999
These tables contain the following information: KNMTK: Header table for increased performance KNMT: Data table
(C) SAP AG
TASD41
1-15
MAST
EQST
KDST
DOST
STST
TPST
STKO
STZU
STAS
STPO
STPU
SAP AG 1999
These tables contain the following information: MAST EQST KDST DOST STST TPST STKO STZU STAS STPO STPU Material assignment to BOM Equipment assignment to BOM Sales order assignment to BOM Document assignment to BOM Standard object assignment to BOM Functional location assignment to BOM BOM header data Time-independent STL data BOM item selection BOM item data BOM sub-item data
(C) SAP AG
TASD41
1-16
VBUK
VBKA
VBUV
VBPA
NAST
STXH
SADR
STXL
VBFA
SAP AG 1999
These tables contain the following information: VBUK: VBKA VBUV: VBPA: SADR: VBFA: NAST: STXH: STXL: Header status and administrative data Sales activity Incompletion log SD document: Partner Address SD document flows Output Texts: Header Texts: Lines
(C) SAP AG
TASD41
1-17
VBUK Header status VMVA Matchcodes STXH/STXL Texts NAST Output PP-Status JSTO
VBAK Header
VBKD Business data VEDA Contract VEPA Partners VAKPA Partner indexes VBUV Incompletion VBFA Document flows
SAP AG 1999
These tables contain the following information: VBUK: VBAK: VBKD: VAKPA: VEDA: VBPA: VBUV: VBFA: VMVA: STXH: STXL: NAST: JSTO: Header status and administrative data Sales document: Header data Sales document: Business Data Partner index Contract Partner Incompletion log SD document flows Matchcodes Texts: Header Texts: Lines Output PP status
(C) SAP AG
TASD41
1-18
VBUP Status VAPMA Material index VEPVG Shipping index VMVA Matchcodes STXH/STXL Texts NAST Output CO object KONV Conditions
SAP AG 1999
VBAP Item
VBKD Business data VEDA Contract VBLB Forecast dlv. sched. VBEP Settings VBBE/S Requirements
These tables contain the following information: VBUP: VBAP: VBKD: VEBA: VBLB: VBEP: VBBE: VBBS: VBUV: VBFA: VBPA: JSTO: NAST: STXH: STXL: KONV: Item status Sales document: Item data Sales document: Business Data Contract Forecast delivery schedules Sales document: Schedule line Individual requirements Summarized requirements Incompletion log SD document flows Partner PP status Output Texts: Header Texts: Lines Conditions
(C) SAP AG
TASD41
1-19
Section: Sales
SAP AG 1999
(C) SAP AG
TASD41
2-1
Order Processing
SD
SO Sales Order
Sold-To Party: C1 Payer: C3 Ship-To Party: C2 Bill-To Party: C3 Net Value 1500.Conf. Qty 0 7 8 Net Value 250.Conf. Qty 0 5
LF Delivery
Ship-To Party: C2 Delivery Date: Picking Date Loading Date: Release Date: Pos. 10 20 MatNo. M1 M2 29.08.99 20.08.99 21.08.99 22.08.99 Del.Qty 7 5 Pick-Qty 7 5 Payer: C3 Invoice Date: Pos. 10 20 MatNo. M1 M2
F2 Invoice
Bill-To Party: C3 22.08.99 Inv.Qty 7 5 Net Value 700.250.--------------950.95.======== 1045.-
Pos. MatNo. Qty Req.Date 10 M1 15 20.08.99 [Unit Cost (VPRS) = 70.-/Pc ] SL-No. 1 2 3 SL-Date 20.08.99 29.08.99 15.09.99 Order Qty 15 0 0
Pos. MatNo. Qty Req.Date 20 M2 5 20.08.99 [VPRS = 30.-/Stk ] SL-No. SL-Date 1 20.08.99 2 29.08.99 Order Qty 5 0
Transfer Order
Picking
MM
Goods-Issue. Document
Goods-Issue
FI
Assets Docmt 2 1 Account Bank Accounts Receivable Inventories Debit 1045
MatNo Qty M1 7 M2 5
BALANCE-SHEET
Liabilities Credit Docmt 2 640 Account Accounts Payable Taxes Payable 10% Stockholder Equity Debit Credit 95
Accnting Docmnt
WL Goods-Issue
FI
Accnting Docmnt
RV Customer Invoice
SAP AG 1999
(C) SAP AG
TASD41
2-2
Make-To-Order Flow
SD Order
Customer cust. reqmts
MM / PP Materials planning
Production Delivery
Billing
SAP AG 1999
Make-to-order production is characterized by the fact that materials are not stored in the warehouse but produced especially for a particular sales order. An individual customer requirement is generated from the sales order item and transferred to materials planning (PP). You can use materials planning to plan requirements. Once this has been done, production is carried out. After the product has been manufactured, you post it by goods receipt to sales orders stock speicifcally for this sales order item. As soon as the delivery is due, you can enter the delivery in SD and post goods issue. This reduces the sales order stock. Then you enter a billing document in SD.
(C) SAP AG
TASD41
2-3
Quantity, date
Production order
SAP AG 1999
The requirement quantity (planned independent requirements), delivery date and configuration specifications are transferred from the sales order to materials planning (PP) as an individual customer requirement. You then use a planning run to generate a planned order. Here, bills of material are exploded and dependent requirements for the assemblies and components are generated. As soon as production can start, you create a production order from the planned order. The system returns the confirmed quantity and delivery date from the production order to the sales order.
(C) SAP AG
TASD41
2-4
Sales order K
SAP AG 1999
The individual components for the final product have already been produced for make-to-order production with assembly production. You then only need to assemble the components according to the customer's wishes. This means you just need a one-level bill of material explosion and you do not need to generate dependent requirements. This means that you do not need a planning run at this point for make-to-order production with assembly processing. You can create a production order directly from the sales order. The system returns the confirmed quantity and delivery date from the production order to the schedule lines in the sales order. Any changes made to the confirmed schedule lines or the delivery date are immediately visible in the sales order and/or in the production order.
(C) SAP AG
TASD41
2-5
Material master
Material 1400-200 Item category group NORM
Standard order
Sold-to party 2300
Item
Material
Material master
Material 1400-700 Item category group 0001
SAP AG 1999
The item category in the sales document is found using the sales document type and the item category group from the material master. The item category group is maintained in the material master on the sales and distribution tab page: in the Sales Org. Data 2. Another item category than that for a material with item category group 0001 is found for a material with the item category group Norm.
(C) SAP AG
TASD41
2-6
CO object for Sales order item Pricing Sales order Bill. document Plan. rev. Plan. costs Act. rev. Act. costs Costing Material samples Production order(s) Settlement
In sales order processing, the costs and sales revenue for a sales order item are collected in a controlling object for that item and settled in a profitability analysis. Pricing in the sales order determines the planned sales revenues (net value 2) and the actual sales revenue is posted in the billing document. The planned costs are compared to the revenues. They arise from product or unit costing, or from the valuation price in the material master (standard price or moving average price). The actual costs are calculated from the withdrawal, production orders, internal activity allocation and surcharges. The accrued actual sales revenues and costs are settled in the CO-PA Profitability Analysis in order to determine the profit or loss.
(C) SAP AG
TASD41
2-7
Outbound del.
Ship-to party 2300
Stock
Material 1400-700 Quant. Del. 1 unit Goods issue Material 1400-700 Sales order stock 0 unit
Goods issue for outbound delivery of an individually made material reduces the sales order stock. stock.
SAP AG 1999
After Production has finished making the material, goods receipt is posted in the sales order stock. Sales order stock is special stock, which can only be used for a specific sales order. After goods issue for outbound delivery, the sales order stock is reduced accordingly.
(C) SAP AG
TASD41
2-8
Section: Pricing
SAP AG 1999
(C) SAP AG
TASD41
3-1
Contents:
Manual order value HM00 Net Price PN00 Minimum order value AMIW, AMIZ Minimum price PMIN Interval price PR02 Hierarchy discount HI01 Pallet discounts KP00, KP01, KP02, KP03 Rounding DIFF
SAP AG 1999
(C) SAP AG
TASD41
3-2
At the conclusion of this unit, you will be able to: Enter order values and net prices manually Set a minimum price for a material or a minimum value for an order Set interval scales for conditions Use customer hierarchies for price agreements See the effect of condition formulas Round final amounts
SAP AG 1999
(C) SAP AG
TASD41
3-3
3900
Item 2
deactivated!
SAP AG 1999
A condition exists in the standard version, which allows you to enter the order value manually. The difference between the old and the new order value is distributed between the items (taking into account the net item value). Taxes are redetermined for each item.
(C) SAP AG
TASD41
3-4
Order
Item 1 PR00 K007 PN00 ... M1 Price 1 piece 1600
deactivated!
Customer discount 160 Net price Net item value ... 1300 1300
SAP AG 1999
The PN00 condition in the standard system allows you to specify the net price for an item manually. The original conditions are deactivated.
(C) SAP AG
TASD41
3-5
Order header
Customer C1 Net item value AMIW AMIZ Net value Price group 02 160 200 40 200
Item 10
Net item value AMIW AMIZ Net value
SAP AG 1999
Item 20
100 125 25 125 75 15 Net item value AMIW AMIZ Net value 60 75 15 75 75 15
You may create a minimum value for each order using condition type AMIW. If the value in the order header falls short of this minimum order value during pricing, the system will copy it as the net order value automatically. The minimum order value is a statistical condition. Condition type AMIW is a group condition and is divided among the different items according to value. Calculation formula 13 is assigned to condition type AMIZ in the pricing procedure. This calculates the minimum value surcharge by subtracting the net item value from minimum order value AMIW.
(C) SAP AG
TASD41
3-6
Order
Item 1 PR00 M1 Price 1 piece 1600 16060 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.
(C) SAP AG
TASD41
3-7
Order
Customer C1 Item 10: M1 25 pc $ 50 $ 40 $ 15 $ 105
PR02 $ 5/piece PR02 $ 4/piece PR02 $ 3/piece Net item value $ 4.20/piece
SAP AG 1999
You can maintain condition records with interval scales if the condition type is set to scale type D in Customizing. Interval scales cannot be used for group conditions.
(C) SAP AG
TASD41
3-8
Customer Hierarchy
Miller Head office 8000 Miller South 8200
Customer 2742
SAP AG 1999
Customer hierarchies are available in Sales and Distribution, so that you can create flexible hierarchies to reflect the structure of customer organizations. If your customer base includes multilevel buying groups, cooperatives, or chains of retail outlets, for example, you can create hierarchies to reflect the structure of these groups. Use customer hierarchies during sales order processing and billing for determining pricing and running statistics. A customer hierarchy consists of nodes. To create a customer hierarchy: 1. 2. 3. Create master records for each node. Assign the nodes to each other. Assign the customer master records to the relevant nodes.
Hierarchy nodes are only valid for a certain period of time. They may also be moved. If a node is moved, the system automatically reassigns all related nodes and customer master records.
(C) SAP AG
TASD41
3-9
Hierarchy Path
Hierarchy path Miller Organizational Organizational data data Head office 8000 1000 10 00
Sold-to party: 2743 Node/ customer 8000 8100 8120 2743 Hierarchy step Top level Second level Third level Fourth level Partner functions 1D 1C 1B AG
Pricing X
Miller South 8200 1000 Pricing Customer 2742 Customer 2742 Miller Central 8120 1000 Pricing
SAP AG 1999
Miller North 8100 00 1000 10 00 Pricing X Miller North east 8110 00 1000 10 00 Pricing X Customer 2744 Customer 2744
10
10
With customer hierarchies, you can assign price or rebate agreements to a higher level node. The agreements are then valid for customers at all subordinate levels to this node. You can create pricing condition records for each node indicated as relevant for pricing. If one or more nodes in the hierarchy path of a sales order contain pricing information, the system takes them into account automatically during pricing. The customer hierarchy above represents the multi-level buying group Miller. The headquarters, Miller Head office, is the highest node defined in the hierarchy. The southern, northern, central and northeastern regional offices are also defined as nodes. A price agreement is reached with the Miller buying group for a particular product line. You offer a discount valid for all regions and offices in the buying group. In addition, you grant a promotional discount for Miller North. You create the appropriate condition records for the Miller Head office and Northern nodes. An order for customer 2742 is received and granted the cross-regional discount. When you receive orders from customers 2743 and 2744, however, the system uses the pricing data stored for Miller North and grants the exclusive promotional discount.
(C) SAP AG
TASD41
3-10
Order
Customer 2743 Item 10: M1 10 pc PR00 HI01 ... Price Discount $ 100 8- %
SAP AG 1999
Customer 2743 belongs to the Miller northern office. This is why a discount of 8% has been assigned. In the standard system, the access sequence is set in Customizing so that the discount is initiated at the lowest hierarchy level.
(C) SAP AG
TASD41
3-11
Order 2
Material M1 100 CAR $ 10-
+
Material master M1 50 CAR ^ 1 pallet =
Order 3
Material M1 70 CAR $ 5-
SAP AG 1999
The pallet discount grants the customer a discount for whole units of measure only. For example, a complete pallet. This is controlled by basic formula 22 in the pricing procedure, which only takes the number of complete pallets into account.
(C) SAP AG
TASD41
3-12
Order 1
Material M1 50 CAR Condition record KP01 $ 50 per pallet
+
Order 2
Material M1 70 CAR $ 50 Material master M1 50 CAR ^ 1 pallet =
SAP AG 1999
In this case, the customer pays a surcharge for an incomplete pallet. This is controlled in basic formula 24 in the pricing procedure, which tests the quantity for a fractional portion.
(C) SAP AG
TASD41
3-13
Order 1
Header: KP02 $ 10M1 M2 20 CAR 30 CAR Condition record KP02 from 1 pal from 2 pal $ 10$ 20-
+
Order 2
Header: KP02 $ 10M1 M2 20 CAR 40 CAR Material master M1, M2 50 CAR ^ 1 pallet =
SAP AG 1999
The mixed pallet discount accumulates the quantities of the individual items, then calculates the discount for complete pallets only. This is controlled by condition type KP02 (group condition = X, unit of measure = PAL) and the corresponding condition record.
(C) SAP AG
TASD41
3-14
Order 1
Header: M1 M2 20 CAR 30 CAR Condition record KP03 from 1 pal $5
+
Order 2
Header: KP02 $ 5 M1 M2 20 CAR 40 CAR Material master M1, M2 50 CAR ^ 1 pallet =
SAP AG 1999
The mixed pallet discount accumulates the quantities of the individual items. It then calculates the surcharge on any fractional portion of the total quantity. This is controlled by condition type KP03 (group condition = X, unit of measure = PAL and scale formula 23, which calculates the fractional proportion of the total quantity).
(C) SAP AG
TASD41
3-15
Rounding DIFF
Order header
Net value TAX Final amount DM 67.25 DM 10.08 DM 77,33
Table 001R
CCod 1000 Curr DM Rounding unit 5
Order header
Net value 2 TAX DIFF Final amount DM 67.25 DM 10.08 DM 0.02 DM 77.35
SAP AG 1999
You can maintain a rounding unit in Table T001R for each company code and currency. If the final amount in the order header differs from the rounding unit, the system will round the amount up or down as specified. Condition DIFF determines the difference amount. Condition type DIFF is a group condition and is distributed among the different items according to value.
(C) SAP AG
TASD41
3-16
Unit Summary
You are now able to: Enter order values and net prices manually Set a minimum price for a material or a minimum value for an order Set interval scales for conditions Use customer hierarchies for price agreements See the effect of condition formulas Round final amounts
SAP AG 1999
(C) SAP AG
TASD41
3-17
Contents:
Cost VPRS Cash discount SKTO Expected customer price EDI1 and EDI2
SAP AG 1999
(C) SAP AG
TASD41
3-18
At the conclusion of this unit, you will be able to: Determine costs and cash discount amounts statistically in pricing Describe how expected customer prices transferred via EDI are used
SAP AG 1999
(C) SAP AG
TASD41
3-19
Cost VPRS
Cost Statistical
Condition category G
SAP AG 1999
In the standard version, condition type VPRS is used to retrieve the standard cost of the material. It is used as a statistical value by the pricing procedure. Using condition category G, VPRS accesses the valuation segment of the material master locating either the standard cost or the moving average cost, as specified in the material master. Condition category S will always access the standard cost, while condition category T will always access the moving average cost. The profit margin is calculated using formula 11 in the pricing procedure. This formula subtracts the cost from the net value 2 subtotal.
(C) SAP AG
TASD41
3-20
Condition category E
Table 30 days
T052 3%
SAP AG 1999
In the standard system, condition type SKTO is used to retrieve the cash discount rate. It is used as a statistical value by the pricing procedure. Table T052 is accessed using condition category E and an amount is calculated from the first percentage rate of the item payment terms.
(C) SAP AG
TASD41
3-21
Order
Item 10 M1 1 piece $ 1500 / piece $ 1400 / piece
Condition category J
Save
Incompletion log
Incoming IDoc
Allow required customer price
SAP AG 1999
The customer expected price can either be entered manually in the order, or retrieved from the incoming IDoc in an EDI environment. Condition type EDI1 is used to compare the net price for each item. Condition type EDI2 is used to compare the overall item value (net price * quantity). Calculation formula 9 is assigned to condition type EDI1 in the pricing procedure. This formula tests for a maximum deviation of 0,05 currency units. Calculation formula 8 is assigned to condition type EDI2 in the pricing procedure. This formula tests for a maximum deviation of 1.0 currency units. If the customer expected price differs from the automatically determined price or value by more that the maximum difference allowed, the system will regard this order as incomplete when it is saved. You may process lists of orders having differences in prices, allowing the system to use or correct the price it determined.
(C) SAP AG
TASD41
3-22
Unit Summary
You are now able to: Determine costs and cash discount amounts statistically in pricing Describe how expected customer prices transferred via EDI are used
SAP AG 1999
(C) SAP AG
TASD41
3-23
Section: Shipping
SAP AG 1999
(C) SAP AG
TASD41
4-1
There are many legal regulations to be observed when transporting dangerous goods. Transportation of the goods includes shipment, receiving and delivering the goods, temporary stops during transportation, and preparatory and follow-on activities (packing and unpacking, loading and unloading) (Transport of Dangerous Goods Act 2 (German)). This means it may be necessary to check the delivery document to ensure the transportation meets these requirements. To do this in the R/3 System, you use the functions in the EH&S component (Environment, Health, and Safety).
(C) SAP AG
TASD41
4-2
33 1088
Within the logistics process, you can activate dangerous goods management in the (inbound or outbound) delivery document or in the shipment document. The system can then perform various dangerous goods checks automatically, or you can trigger them manually. For instance, you can check whether the transportation of particular materials on a particular mode of transported is permitted. This can prevent deliveries or shipments that do not meet safety requirements leaving the company. You can also create dangerous goods documents containing the relevant dangerous goods data. Dangerous Goods Management uses special master data and settings in EH&S. You can make your own settings in Customizing to define when the various checks should be performed and how the document should be processed.
(C) SAP AG
TASD41
4-3
Substance database
Substance and reg. data Maintenance of: Properties Compositions Classification
SAP AG 1999
If a material is considered a dangerous good, you define a dangerous goods indicator profile in the material master record (basic data 2). You can then refer to this profile to find out whether a material is classified as a dangerous good and whether it requires dangerous goods documents and checks. The dangerous goods master complements the material master and is therefore created for materials that are already defined in the system. It contains data that is necessary for performing dangerous goods checks and creating dangerous goods documents according to existing law. The substance database is a flexible tool for managing and maintaining data on chemical substances and preparations. It contains all substance data and legal data. It provides the basis for comprehensive environment management. The assignment of a material number and a substance number establishes the link between material data and substance data, which means that the dangerous goods master and the substance data can be used in the dangerous goods checks.
(C) SAP AG
TASD41
4-4
SD - DGM interface
Check log
SAP AG 1999
The basic process for a dangerous goods check is as follows: When the check is triggered, manually or automatically, the system calls the check processor via an interface. The processor determines the data for the dangerous goods check, such as the dangerous goods master records, validity areas, and mode of transport categories. The system then processes the different check methods of the check schema. Using return codes, entries are made in the check log, which you can call from the document. The overall reaction is determined from the reactions from the individual check methods.
(C) SAP AG
TASD41
4-5
Outbound delivery
Ship-to party: Shipping point: Sales org.: Delivery type: Item 1 Item 2 7341 1200 1000 LF
Make changes
Log
SAP AG 1999
From the delivery document, you can start the dangerous goods check either automatically or manually. The automatic start takes place when you save the document, if the dangerous goods checks are activated. You can start the check manually at any time, if the dangerous goods checks are activated. However, the following information must be available: Shipping point Sales organization Delivery type Ship-to party Route When the dangerous goods checks are complete, a dialog box appears displaying the message from the check method that determines the overall reaction for the check schema. If there are any log entries, you can branch to the check log. The check log displays all the messages that appeared while the dangerous goods checks were being processed. You can print out the log. What happens next: You continue processing the document as determined by the Customizing settings for the overall reaction. For instance, the document either cannot be saved, or is assigned a blocking indicator.
(C) SAP AG
TASD41
4-6
Delivery item
Dangerous goods data Control Serial numbers Batch characteristics Foreign trade Reference data Texts Configuration
The DELVRY02 delivery interface consists of different segments containing information from the delivery header, the delivery item, and the shipping units. DELVRY02 (Release 4.6A) has more segments than DELVRY01 (Release 4.0), which contain dangerous goods data at header and item level. DELVRY03 (Release 4.6B) also contains segments for the external release number, data on the express delivery company, tracking data, and the repacking of shipping units.
(C) SAP AG
TASD41
4-7
Communication Scenarios
Shipping notification to customer (LAVA) Notification from forward.agent (CANO) Warehouse notification from internal warehouse Shipping confirmation from service agent Warehouse order to internal whse (WSOR) Shipping order to service agent (SHOR)
SD delivery processing
MM delivery processing
SAP AG 1999
Shipping notification (outbound) by EDI (message type LAVA/EDI message DESADV): additional information, for example, serial numbers and configuration, can be communicated. Shipping notification (inbound) by EDI (EDI message DESADV): for inbound shipping notifications, MM can also receive packing data. Shipping order by EDI to a service agent (message type SHOR/EDI message SHPORD). Shipping confirmation from a service agent by EDI (EDI message SHPCON): This EDI message combines the picking confirmation with the packing data confirmation. Warehouse order to your external system by ALE (message type WSOR/ EDI message WHSORD). Warehouse confirmation from your external system by ALE (EDI message WHSCON): This EDI message combines the picking confirmation with the packing data confirmation. The message can also update the actual weight and the actual volume in the delivery. Notification to forwarding agent by EDI (message type CANO/EDI message CARNOT).
(C) SAP AG
TASD41
4-8
Parcel tracking
12.6. 10.05 MA 12.6. 10.55 KA 12.6. 12.02 S Picked up Load transferred Delivered
Manifest
Delivery list
EXPRESS
XXL 563
Route AB
49211172
SAP AG 1999
Express delivery companies transport goods quickly and offer the opportunity to track the itinerary of the shipments. There are special requirements for processing this kind of shipment, which do not arise with ordinary shipments. With express delivery processing in R/3, you can model the special requirements of express deliveries. These requirements include: Information specific to the service agent recorded in the delivery; this information refers either to the entire delivery or to individual parcels. Printing out special labels with the required information (this is needed for the automatic sorting machines at the express delivery companies) Creating the manifest / delivery list (simplifies settlement for the express delivery company and eliminates manual entry of shipments; prevents delays) Parcel and status tracking
(C) SAP AG
TASD41
4-9
Shipper
Order
Delivery note
Tracking no.
Outbound delivery
Tracking no. Routing Service code etc.
ac ki
ng
st at u
SAP AG 1999
When express delivery companies are involved in the outbound delivery process, you usually require express delivery information as soon as you create the outbound delivery. This information includes the tracking number, routing information, the service code, and the product code. This data can be defined either at outbound delivery level or shipping unit level. If an express delivery company is specified in the outbound delivery, the system automatically loads the information from the data stored for that company. In the outbound delivery document, there is a tab page for this at header level called parcel tracking. The shipper informs the ship-to party of the tracking number and any other information relevant to the express delivery. The shipper also has the option of creating a shipment document containing all the shipments for a particular express delivery company. On the basis of this shipment document, the shipper can create a manifest and send it to the service agent (electronically using the shipment IDoc). Both shipper and ship-to party can monitor the tracking status of the shipments at any time using the tracking number. The parcel tracking function is available for this purpose. You maintain the data for the express delivery companies in the express delivery cockpit.
(C) SAP AG
TASD41
4-10
Parcel Tracking
What is the tracking number of the delivery? What service code was determined?
Parcel tracking
Sales document Purchasing document Delivery 80001234 Shipment number Shipping unit Tracking number
SAP AG 1999
It is often important to track the itinerary of the shipment (delivery or parcel), and to know at any one time where the shipment is, what its status is (tracking status such as picked up, load transferred, or delivered) and so on. The parcel tracking function allows you to do this. This function has its own tab page in the header details of the outbound delivery called parcel tracking. This view gives you the tracking status and all other information relating to the express delivery processing of this outbound delivery. There is also a parcel tracking transaction. This allows you to select documents by order, purchase order, delivery, shipment, shipping unit, or tracking number. For the selected document, the system also displays the tracking status and express delivery company information. The tracking status is also displayed in the document flow, along with the delivery status or status of the shipping unit. Another method of tracking shipments is to access the order status using SAP's Internet Application Components (IAC). From there, you can branch to parcel tracking. This is particularly useful for ship-to parties, who can call up the tracking status using the order number. You can also access the status in the background. A workflow connection is possible in this case. In exceptional cases, this may mean that processors receive items in their inboxes.
(C) SAP AG
TASD41
4-11
Parcel tracking
Expr. field Quantity Track.stat. Location
Shipping Delivery 80005432 Tracking status London, sh.pt 3000 Frankfurt Munich
Express delievery data fields Service code Sender number Weight code Tracking number Not packed Floppy disk drive R-1150 10 Pc 99 6543 DE 777333 22 123886622
SAP AG 1999
On the parcel tracking screen, you find detailed information about the tracking status and the data fields of the express delivery company, which the system supplies automatically. The data can be displayed both at outbound delivery level and at shipping unit level. There are no shipping units in the above example, so the data applies to the entire outbound delivery. User can define their own display variants so the information is displayed to suit their needs. From the parcel tracking screen, you can also request information from the express delivery company via the Internet.
(C) SAP AG
TASD41
4-12
COCKPIT
Control URLs Tracking status Weight codes Service codes Master data maintenance Set up Metadata
Data provider
Product codes
SAP AG 1999
The express delivery cockpit is the central point for making all the settings relevant to express deliveries. For each express delivery company, you must define which data fields are relevant for it and how they should be determined (= metadata). The master data includes: Product and/or service codes: Reflect the offering of the express delivery company (speed, services, and so on) Routing information: Depends on zip code; used by automatic sorting machines Tracking status: Possible status confirmed in parcel tracking URL links: Destination URLs for XML and URL templates for parcel tracking; documentation Number ranges: For numbers assigned by the express delivery company An XML-enabled setup interface simplifies the setup procedure if you are supported by the express delivery company or another data provider. In this case, you just need to create the express delivery company and assign it to a service agent (vendor master record) and shipping points. Next, all the meta and master data is loaded and can then be further processed manually.
(C) SAP AG
TASD41
4-13
Section: Billing
SAP AG 1999
(C) SAP AG
TASD41
5-1
SAP AG 1999
(C) SAP AG
TASD41
5-2
Double-Entry Accounting
Each business transaction is posted to at least two different accounts Debit postings always appear on the left hand side of a T account Credit postings always appear on the right hand side of a T account Total debit postings = Total credit postings
SAP AG 1999
The basic principle of double-entry accounting is that every business transaction is posted to at least two different accounts, and is therefore posted at least twice. In the most simple cases, only two accounts are affected. The most important thing to remember in this context is Debit to Credit. This means that you should post a transaction to the debit side in one account, but to the credit side in another. Basic principle: The total for debit postings is always the same as the total for credit postings, regardless of the number of accounts affected.
(C) SAP AG
TASD41
5-3
Property accounts Additions are entered on the debit side Disposals are entered on the credit side Examples: Stock, cash, bank, receivables
Capital and debtor accounts Additions are entered on the credit side Disposals are entered on the debit side Examples: Payables
SAP AG 1999
Business transactions are posted to accounts (= invoices kept on two sides, in which movements are registered). In a double entry accounting system it is possible to separate the accounts into different types of basic accounts, which themselves are divided into two partial accounts: Balance sheet accounts (property accounts and capital and debtor accounts), to which stocks and changes to these stocks are posted. P&L accounts (expense/cost accounts and revenue/sales accounts), to which transactions affecting net income are posted. The following basic equation applies to the structure of all accounts: Opening balance + addition - disposal = closing balance However, the basic accounts above differ in which side the opening balance, addition, disposal and closing balance are posted to.
(C) SAP AG
TASD41
5-4
Revenue accounts Additions are entered on the credit side Disposals are entered on the debit side Example: Sales revenue
Expense accounts Additions are entered on the debit side Disposals are entered on the credit side Example: Cost of materials, price difference
SAP AG 1999
(C) SAP AG
TASD41
5-5
SD Example
10 pieces at $ 12 per piece 10 pieces delivered, standard price $ 10 per piece 10 pieces at $ 12 per piece
(C) SAP AG
TASD41
5-6
SD Example: Postings
Material usage (Expenses) 100 Stock (Assets) 100
Goods issue:
Invoice:
Incoming payment:
SAP AG 1999
In the example of an SD business transaction, an accounting document is created at the point of goods issue and/or invoice creation. At the point of goods issue, the goods physically leave the warehouse. This results in a stock-related and value-related posting. This means that the stock is reduced and the materials used increased. The posting is therefore called "Materials used to stock". At the point of billing, receivables are accumulated by the customer, and additions are posted to sales revenues (posting record: Receivables to sales revenues). If the incoming payment is made in FI, the receivables are reduced again and the amount of the cash inflow is posted to a bank account (posting record: Bank to receivables). Posting output tax has been ignored for the purposes of this simplified example.
(C) SAP AG
TASD41
5-7
MM Example
Vendor
10 pieces at $ 10 per piece 10 pieces received, standard price $ 10 per piece 10 pieces at $ 10 per piece $ 100
SAP AG 1999
(C) SAP AG
TASD41
5-8
MM Example: Postings
Stock (Assets) 100
Goods receipt:
Invoice:
Payment:
SAP AG 1999
In the example of an MM business transaction, an addition to stock occurs at the point of goods receipt. The clearing entry is made against a special goods receipt/invoice receipt clearing account (stock to GR/IR clearing account). Provided that standard prices are used for valuation, it may be necessary to post to a price difference account the amount of the difference between costs for purchasing and valuation. At the point of invoice creation, the GR/IR account is credited and payables accumulated by the relevant creditor (GR/IR clearing account to creditors). The payables are reconciled in the payment run, and a disposal is is entered in the bank account (payables to bank). Posting the tax due has been ignored for the purposes of this simplified example.
(C) SAP AG
TASD41
5-9
Section: Transportation
SAP AG 1999
(C) SAP AG
TASD41
6-1
Shipper
Internet
Forwarding agent
Tender / quotation
Internet
Acceptance / rejection
SAP AG 1999
Using the recently developed Internet scenarios, you can tender a shipment created in R/3 and offer it to a service agent. Shippers and service agents communicate over the Internet, so the service agent needs neither an R/3 System nor EDI. An example of the usual tendering procedure: The shipper creates a shipment in R/3. Before it can be tendered, it must be planned - in other words, the service agent and stages must be defined. The shipper offers the shipment to the service agent via the Internet (tendering). The service agent has Internet access to the shipments offered, and can accept them, reject them, or accept them under certain conditions. The shipper confirms the acceptance or rejection by the service agent and sends further information if necessary. The service agent starts to process the shipment, defining planned data and setting a status for the shipment. The service agent can access information about new shipments at any time from the tendering list. The service agent can view the processing status of accepted shipments in the status list.
(C) SAP AG
TASD41
6-2
Shipment
Tend. status
Tender
Tender status
Not offered to any forw. agent / offer cancelled Offered by shipper Accepted by forwarding agent Accepted by forwarding agent with conditions Rejected by forwarding agent Confirmed by shipper Exception signalized by forwarding agent
SAP AG 1999
The tender tab in the shipment overview summarizes the most important information about the tendering of the shipment. The tendering status indicates the current status of a shipment with respect to negotiations with a forwarding agent over the Internet. Certain conditions are defined for setting each individual tendering status. Generally, you can only set a status if a forwarding agent is defined at header level in the shipment, if stages are defined, and Planned status is set. The shipper makes some status settings, and the forwarding agent makes others. In the Acceptance condition/rejection reason field, you can define the conditions under which a forwarding agent can accept a shipment or for what reason the shipment can be rejected.
(C) SAP AG
TASD41
6-3
Shipment costs
From NY to WA Conditions FB00 Basic freight 1100 USD FD00 Discount 1 -100 USD FD10 Discount 2 : -5 % 10 t
Access sequence: MATK Access sequence:MATK Condition tables: 1. Service agent/tariff zone/ freight class 2. Service agent/tariff zone Records for cond. type FB00 No valid record available Valid record available
SAP AG 1999
Scale
1300 USD 1 t or more 1100 USD 10 t or more 1000 USD 20 t or more
In this example, 10 tons of a material are shipped by a forwarding agent from New York to Washington. The system is to determine the shipment costs automatically. The system first determines the corresponding pricing procedure. This contains every possible condition type within shipment pricing in a particular sequence. The system reads the first condition type in the pricing procedure. The condition type identifies the characteristics of a condition. For this condition type, the system determines the assigned access sequence. The system reads the access sequence. In the sequence, the condition tables are accessed at least once. The sequence of the condition tables constitutes the search strategy to determine the corresponding condition record. The system searches for valid condition records for the condition tables (accesses). A condition record contains the actual shipment rates. If no valid condition record exists for the first condition table, the system searches for condition records for the second table. When the system finds a valid condition record for a condition table, the condition record is read and the corresponding value is copied into the shipment cost document. The system repeats all of these steps for each condition type until the entire pricing procedure is processed.
(C) SAP AG
TASD41
6-4
Shipping type
Service agent
SAP AG 1999
All condition types supported for pricing are determined in the pricing procedure. The pricing procedure is determined automatically based on different criteria: Transportation planning point of the shipment Shipping type (grouped in a shipping type procedure group) Service agent (grouped in a service agent procedure group) Shipment cost item category (grouped in an item procedure group) You set pricing procedure determination in Customizing.
(C) SAP AG
TASD41
6-5
Condition type:
Level at which the condition is defined
Service agent:
SAP AG 1999
The aim of pricing is to determine prices and surcharges/discounts (= conditions) for a business transaction and additionally allow the user to specifically influence these conditions manually. Prices, surcharges, and discounts are stored in condition records. You can define conditions at any level. A level corresponds to the fields in the condition table in which a condition record is stored. The level therefore also represents the key fields for the access to a condition. Common levels at which price agreements are made are predefined in the standard system. You can add any levels that you may need. Thus you can make conditions dependent on any fields of a business document. By specifying a validity period, you can restrict a condition to a specific period. You can maintain the values within a condition record (price, surcharge, discount) depending on a scale (weight-based, volume-based or value-based scale). You can also use multi-dimensional scales. There is no limit to the number of scale levels. For each condition record, you can define a lower and an upper limit that will allow you to manually change a pricing element within the limits specified.
(C) SAP AG
TASD41
6-6
to 10
185 USD/TO 295 USD/TO 373 USD/TO
to 20
152 USD/TO 252 USD/TO 333 USD/TO
to 25
127 USD/TO 213 USD/TO 285 USD/TO
Distance (Mile)
2000 USD
3500 USD
6000 USD
7100 USD
SAP AG 1999
You can maintain multi-dimensional freight agreements and represent them in an easy-to-use freight table for the freight cost area. Example: You have agreed on a tariff with your service agent that depends on both the distance and the weight of the load to be shipped. You have also agreed on minimum and maximum prices. The following freight costs arise from the freight table: A load of 9 tons is transported 320 miles. You determine a price of 373 USD per ton. This gives shipment costs of 3357 USD. A load of 4.9 tons is transported 400 miles. A price of 435 USD per ton was determined, giving 2131.5 USD in total. However, the maximum value is 2000 USD. A load of 1 ton is transported 250 miles. You determine a price of 336 USD but the minimum price is 450 USD so you charge 450 USD.
(C) SAP AG
TASD41
6-7
SAP AG 1999
To represent multi-dimensional freight charges, you must define a condition type with the multidimensional calculation type. Several scales (max. 3) can be assigned to this condition type. The scales are defined as master data - regardless of the condition type - and can be assigned to several condition types. They have different scale bases, for example, distance, gross or net weight, postal code, tariff zone, number of shipping units, travel time, total duration. A calculation type is specified for each scale level. You can also define maximum and minimum prices. When you create a condition record, the scales assigned to the condition type appear as default values. You can however replace these values with others, if necessary.
(C) SAP AG
TASD41
6-8
Condition type FB00: Service agent: Date: Tf zone point of dep: Tf zone destination: 2266 01/10/00 US10 US80 to US99
You can change several shipment condition records simultaneously. This enables you to respond quickly and efficiently to changes in the service agent's rates. To make the changes, select the condition record to be changed in change mode. Next choose Change amount, and enter the percentage or absolute value by which the condition record should be increased or reduced. If you would like to make the price change valid after a certain date (if the price is increased by 5%, say, as of the first of next month), you should proceed as follows: Using the function Create with reference, create new validity periods for the existing condition records. Using Change, call the condition records for the new validity period, and make the changes as described above.
(C) SAP AG
TASD41
6-9
Shipment Comparisons
Pricing procedure SDFC00:
0001 Weight-dep. basic freight Weight-dep. 0005 Insurance costs 0002 Basic freight - shipping unit Only choose the cheaper of the two freight types
Exclusion procedure
Cheaper
Net value: 1358 USD
SAP AG 1999
The system can carry out two different shipment cost calculations and compare them, automatically selecting the most favorable result. Example: You can, for example, create condition types with the delivery items calculation base and condition types with the shipping units calculation base in the same pricing procedure. You can then define condition exclusion groups (A and B) and assign the two condition types with additional discounts to the two different exclusion groups. You then assign these exclusion groups to the pricing procedure and specify the exclusion process "Best condition between the two exclusion groups". If you now carry out a shipment cost calculation for which the above pricing procedure is determined, the system calculates the freight value for exclusion group A and exclusion group B. In the first case, the calculation is performed for each delivery item. The final shipment price is 1,358 USD. In the second variant, costs are calculated by shipping unit. There are 6 pallets. The shipment price is 1250 USD. Based on the exclusion process, the system selects the most favorable variant and calculates the costs by shipping unit.
(C) SAP AG
TASD41
6-10
Shipment Mat.1 9t
Cheaper
Shipment costs: 540 USD Shipment costs: 500 USD
SAP AG 1999
The break weight calculation is used to choose the most favorable scale level for the calculation when using scaled shipment cost agreements. The break weight is the weight at which it is more favorable to calculate a heavier weight so that you reach a higher and cheaper scale level. Example: You have agreed on shipment costs for 60 USD per TO for the scale level 5 to 10 tons to be transported but only 50 USD per TO for scale level 10 to 15. A shipment of 9 tons would lead to a price of 540 USD in the scale level 5 to 10. It would be cheaper to calculate the shipment costs for a weight of 10 tons so that it reaches the next scale level and therefore only costs 500 USD.
(C) SAP AG
TASD41
6-11
Exclusion procedure
SAP AG 1999
You need two condition types to use break weight calculation. The first is for "normal" shipment cost calculations at the correct scale level. The second is for calculating at the next scale level. The system uses a condition exclusion procedure to compare the two values and use the cheaper one. You must make the following Customizing settings: Define two condition types. The second must refer to the first and use the same condition records. Assign the same scales to both condition types and activate the break weight indicator for the second condition type. For multi-dimensional scales, activate this indicator for the scale in which the break weight should be calculated. Define an exclusion condition procedure that chooses the cheapest value.
(C) SAP AG
TASD41
6-12
Parcel tracking
12.6. 10.05 MA 12.6. 10.55 KA 12.6. 12.02 S Picked up Load transferred Delivered
Manifest
Delivery list
EXPRESS
XXL 563
Route AB
49211172
SAP AG 1999
Express delivery companies transport goods quickly and offer the opportunity to track the itinerary of the shipments. There are special requirements for processing this kind of shipment, which do not arise with ordinary shipments. With express delivery processing in R/3, you can model the special requirements of express deliveries. These requirements include: Information specific to the service agent recorded in the delivery; this information refers either to the entire delivery or to individual parcels. Printing out special labels with the required information (this is needed for the automatic sorting machines at the express delivery companies) Creating the manifest / delivery list (simplifies settlement for the express delivery company and eliminates manual entry of shipments; prevents delays) Parcel and status tracking
(C) SAP AG
TASD41
6-13
SAP AG 1999
(C) SAP AG
TASD41
7-1
Sometimes there are deviations between the amount of the incoming payments and the existing receivables. When posting the residual items, your employees enter a difference code. Here, disputed residual items should not influence the commitments in credit management. Some customers make payments for orders. These incoming amounts should reduce the amount of credit limit used.
SAP AG 1999
(C) SAP AG
TASD41
7-2
$1,000
Reason 01
CCA data
Incoming payments
For each company code, difference reasons are determined to manage payment differences. Difference reasons are used, for example, when the cash discount period has been exceeded, when an unauthorized cash discount is claimed, or if the customer has simply made an error in calculation. You indicate for each difference reason whether payment differences should result in disputed items. Disputed items do not raise the total receivables within credit management due from a customer. When you carry out a credit check against the oldest open items and the percentage of open items with a certain number of days in arrears, the system does not take disputed items into account. For more information see the chapter on Automatic Credit Control.
(C) SAP AG
TASD41
7-3
$1,000
Reason 02
CCA data
Incoming payments
In this example, the receivable in credit management remains at the level of the outstanding receivable because the difference reason is not disputed (for example, an error in calculation by the customer).
(C) SAP AG
TASD41
7-4
Customizing: Financial Accounting - Incoming payments Account type: D = Customer Special general ledger indicator: A = Payment Credit limit relevance: x
CCA data
Special general ledger transactions represent special transactions in accounts receivable and accounts payable, which cannot be shown in the usual way in the sub-ledger account. Examples include down payments and bill of exchange posting. The Credit limit relevance indicator ensures that the system takes posting into account when the credit limit check is carried out for special general ledger transactions (in other words, this value is included in total commitments).
(C) SAP AG
TASD41
7-5
Order
Authorization
Card info
Clearing house
Outbound delivery
Billing document
Card info
SAP AG 1999
Acc. doc.
Authorization information
Card info
Payment card processing supports the following functions: A payment card plan is assigned to the sales order at header level. This plan contains information such as the card number, the card type and the authorization data. When the delivery is created, a validity check is carried out for the authorization. If the authorization is no longer valid, or if an increase in quantity requires an increase in value, then the user is required to carry out authorization again in the sales order. The payment card data is copied to the billing document from the order. The payment card data and authorization data are forwarded when the billing document is transferred to Financial Accounting. In Customizing, you can configure the system so that additional data needed for settlement is transferred from SD to FI when procurement cards are involved. Transactions with payment cards can be posted to deviating accounts (see the field Account determination for payment cards when controlling the billing types). The final settlement process is carried out via the clearing house on the basis of this information.
(C) SAP AG
TASD41
7-6
Authorization
Clearing house
POS
Settlement
Billing document
Card info
Acc. doc.
Authorization information
Card info
SAP AG 1999
This form of processing takes place in Retail. The Point-of-Sale (POS) is the point at which the goods are paid for (usually the cash register). No sales or shipping documents are created. When using Point-of-Sale systems, authorization is carried out in an external system. The relevant data is imported to the R/3 System. The billing document is created in the R/3 System.
(C) SAP AG
TASD41
7-7
Default Block reason Valid from Valid to X 01.01.1997 31.12.2002 01.01.1996 31.12.2001
Best Bank
VISA
4100 0000 0000 0001 Valid from 01/97 to 12/2002 K. King Euro Bank MC
SAP AG 1999
Payment card data can be stored in the payer master record via the Payment transactions screen (Payment cards button). Here, you specify the payment card type (for example, VISA), the payment card number, and the validity periods for this card. A card can also be entered as a default card. This will then appear in the F4 Help for order processing. If a card is blocked, the blocking reason can also be entered for the corresponding payment card (purely for information purposes, has no effect on the block in the order). When you enter payment cards in the customer master, the following checks are carried out: The system checks the validity of the card number, provided the corresponding check routines are maintained in Customizing for that card type. The system also checks whether this card has already been entered in a different customer master record. An identical card cannot be entered for more than one customer.
(C) SAP AG
TASD41
7-8
Converter 1
Converter 2
Converter 3
Clearing house 1
SAP AG 1999
Clearing house 2
Clearing house 3
Clearing houses issue authorizations for orders and are also responsible for settlement. A transparent interface to external systems allows the merchant to transfer and receive data. In the standard R/3 System, function CCARD_AUTH_SIMULATION is provided as a template for creating user-specific authorization functions. The standard system also contains function CCARD_SETTLEMENT_SIMULATION, for creation of user-specific settlement functions.
(C) SAP AG
TASD41
7-9
Authorization
One day before delivery creation Valid for 14 days Order entry Next material availability date by schedule line
Days
Authorization horizon
SAP AG 1999
Authorization is usually carried out in the order at header level. In other words, new authorizations must always be created through the order. Using checking groups, you can set requirements in Customizing, that control under what circumstances authorization is to be determined. You can then set the system so that authorizations are carried out only for complete orders. Depending on the checking group, you can also specify the authorization horizon (in other words, when authorization is to be determined). If you use authorization requirement 1 provided in the standard system, authorization is triggered when you save the order. Authorization requirement 2 is provided for background processing. The checking groups must be assigned to the sales document types. In the example above, an order has been entered today and is to be paid for using a VISA card. Authorization is to be carried out one day before delivery creation and will be valid for 14 days. The next material availability date according to the schedule line is in three days. This means that the authorization process must be carried out in two days time, according to the authorization horizon specified. The authorizations in the order are used in billing. A status in the order displays which authorizations have already been used. Note: You can use the checking groups in Customizing to control whether preliminary authorizations (value 0, if the current date is outside the authorization horizon) are to be carried out in order to check the correctness of the card data.
(C) SAP AG
TASD41
7-10
Settlement(1)
Invoice #900001
Customer: 58759 King VISA 4100000000000001 Order value $50
Customer 58759
50 50
Sales revenue
50 100
Invoice #900105
Customer: 98775 Kaiser VISA 4200000000000000 Order value
SAP AG 1999
Customer 98775
100 100
Clearing house
50 100
$100
When accounting documents are being created from transferred billing documents that include payment card data, the following postings are made: Debit and credit postings to the customer account Posting of the sales revenue Posting of receivables to the interim account of the clearing house This posting process can be explained in that the authorization guarantees the receivable and the clearing house represents the relevant partner for payment. An interim account should be created for every clearing house so that the condition technique can be used to carry out posting to the relevant account (all receivables paid with VISA and MC posted to the interim account of the GZS; all receivables paid with AMEX posted to the interim account for the AMEX clearing house, and so on).
(C) SAP AG
TASD41
7-11
Settlement (2)
B E F O R E
Clearing house
50 100
Clearing house
50 100 150
SAP AG 1999
At regular intervals, the individual postings can be cumulated in the interim account for the clearing house and posted as a full value to the corresponding interim bank account. Settlement with the clearing house is triggered via this interim bank account. This account now contains the receivables from the clearing house for which payment is now expected. The receivables were transmitted via a settlement run. The background processing number can be used for assignment purposes during incoming payments. The interim bank account is cleared upon payment of the receivables by the clearing house.
(C) SAP AG
TASD41
7-12
Contents:
Release, rejection and forwarding of blocked documents Reassignment Information functions
SAP AG 1999
(C) SAP AG
TASD41
8-1
At the conclusion of this unit, you will be able to: Name the different processing functions for blocked sales documents and describe their effects Explain how to access the different information sources used to decide which form of processing is applied to blocked documents
SAP AG 1999
(C) SAP AG
TASD41
8-2
Usually your credit representatives process at regular intervals their worklist of documents blocked for credit, for example once a day Since the decision as to whether a blocked transaction can be released or must be cancelled depends on several factors, they need various information functions
SAP AG 1999
(C) SAP AG
TASD41
8-3
Release
Order: 125
Order: 125
Order: 125
Released documents
Release
Order 125 -
The following status settings are provided for sales and distribution documents in Credit Management: Blank = credit status is not relevant A = transaction is valid for the purposes of credit management B = transaction is blocked by credit management D = transaction has been released by credit management 'C' is not currently used. This status is provided for every type of check activated for the automatic credit check. The system also determines a total status from the individual status settings.
(C) SAP AG
TASD41
8-4
CCA
Order Tilia Corp. Order value: $10,000 Credit status: B Release on June 1 Tilia Corp. Order value: $10,000 Credit status: D Order changed on June 1
A new check is carried out when: a) The amount is increased b) The time limit is exceeded
SAP AG 1999
You can determine the conditions under which a document is to be checked again once it is released. The check rule for orders can be used to determine the conditions under which an order is to be checked again once it is released. The check rule for deliveries can be used to determine the conditions under which a delivery is to be checked again once it is released. It also influences the check on a released transaction when a delivery is created from an order. When you create a delivery, the release date of the order is copied to the delivery and used for the check carried out in this document. If there are no entries made in the above fields, the transaction is checked again.
(C) SAP AG
TASD41
8-5
Rejection
$10,000
Item 10: Credit Limit Exceeded Item 20: Credit Limit Exceeded Item 30: Credit Limit Exceeded
SAP AG 1999
(C) SAP AG
TASD41
8-6
Credit overview
SAP AG 1999
In Credit Management the use of different information sources to help you decide whether a blocked document can be released or not is of prime importance. For this reason there is a large number of reports and tools that contain a wide range of information. Some of these information sources have been created especially for Credit Management, whereas others come from related areas that can also be relevant for decision-making. The credit master sheet serves to display and print the customer master data of an individual account that is needed for Credit Management. To get an overview of the customer master data of one or several customers you can generate a credit overview. This report is an exceptionally important tool for checking the credit management data of customers in regular cycles. Using the master data list, you can display and print customer credit data. In particular you can display information that is not contained in the credit data, for example customer-specific data or external data that you have created with special supplementary software. From Release 4.5A it is possible to generate an early warning list. However, you must first create a credit vector for the selected customers using program RFCMCRCV.
(C) SAP AG
TASD41
8-7
FI Info System FI Info System Sales Info System Sales Info System
SAP AG 1999
In Credit Management there is additional important information specific to the customer that can influence decision making. You can use general information on the last payment made by the customer and the oldest items due, for example, taken directly from a customer's credit control area data. Furthermore, it is possible to branch from Credit Management to the customer's dunning and count data. From the credit control area data, the credit master data, and the credit overview, you can list the customer's line items, carry out an account analysis or analyze the payment history. Using the FI info system you can also analyze due dates, the DSO, and overdue items.
(C) SAP AG
TASD41
8-8
You are now able to: Name the different processing functions for blocked sales documents and describe their effects Explain how to access the different information sources used to decide which form of processing is applied to blocked documents
SAP AG 1999
(C) SAP AG
TASD41
8-9
Exercises
Unit: Processing Blocked Documents Topic: Different Information Sources
At the end of these exercises, you will be able to: Describe and apply the different information sources available to help you decide how to process blocked documents.
You are processing a list of blocked orders and deliveries. To decide which documents to release/reject, you need to access various data from different areas.
1-1
Display which sales documents have been blocked within your group due to a credit limit check.
1-2
A transaction can appear in this list as a result of various credit checks. Find out which checks were carried out for the documents in your list and find out the results of those checks.
1-3
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
(C) SAP AG
TASD41
8-10
1-7
Reject the blocked sales document. The delivery should remain blocked.
(C) SAP AG
TASD41
8-11
Solutions
Unit: Processing Blocked Documents Topic: Different Information Sources
1-1
Display which sales documents have been blocked within your group due to a credit limit check. Accounting Financial accounting Accounts receivable Credit management Exceptions Blocked SD documents
1-2
A transaction can appear in this list as a result of various credit checks. Find out which checks were carried out for the documents in your list and find out the results of those checks. Select a document line and choose Environment Document info Document status
1-3
Display the credit master sheet for the customer concerned. Select a document line and select Environment Credit master sheet
1-4
Display a short summary of information on your customer by calling the credit overview. Select a document line and choose Environment Credit overview
1-5
Display the credit control area data and find out when the last payment was made. Select a document line and choose Environment Customer master credit Control area data Extras Last payment
(C) SAP AG
TASD41
8-12
1-6
Call the account analysis for customers. Accounting Financial accounting Accounts receivable Account Analysis
1-7
Reject the blocked sales document. The delivery should remain blocked. Accounting Financial accounting Accounts receivable Credit management Exceptions Blocked SD documents Select the relevant document line and choose Edit Reject (enter rejection reason 20)
(C) SAP AG
TASD41
8-13
Contents:
Standard Courses in MM Standard Courses in other areas
SAP AG 1999
(C) SAP AG
TASD41
9-1
Materials Management
Level 2
LO510 3 days Inventory Management LO515 3 days Invoice Verification LO520 3 days Purchasing Details and Optimization LO525 2 days Consumption-Based Planning and Forecasting LO540 2 days Procurement of External Services 2 days LO925 Cross-Application Business Processes in SD and MM LO640 3 days Foreign Trade 2 days LO715 QM in Procurement
SAP AG 1999
Level 3
5 days
LO235 KANBAN
2 days
With the help of this slide you may inform yourself about the standard courses in the MM module. Furthermore you are able to get an idea of how many topics are covered in standard courses in the TeamSAP Academy course TAMM40: LO020: LO510: LO511: LO515: LO520: LO521: LO525: LO540: LO550: LO955: all subjects all subjects Physical Inventory: Overview, Cycle Counting and Inventory Sampling nearly all subjects ca. 80 % (no vendor evaluation and no Material Part Numbers in the academy) overview & important details ca. 60 % (there is no forecast in the academy) Overview in week 1. For further details, please visit this course. all subjects overview & important details
Not covered in the academy are the following courses: LO235, LO640, LO715, LO925. If you are interested in subjects contained in these courses, please visit the relevant courses or the related Advanced Academy courses.
(C) SAP AG
TASD41
9-2
Financial Accounting
Level 2
AC200 5 days General Ledger/ Accounts Payable/ Accounts Receivable Configuration
Level 3
AC205 2 days Financial Closing AC260 2 days Additional Financial Functionality AC660 5 days EC-CS: Consolidation Functions *AC240 5 days FI-LC: Consolidation Functions **AC900 R/3 For Auditors CA550 3 days 4 days Consolidation
AC010
5 days
5 days
4 days
Funds Management: Processes, Organization and Configuration HR050 5 days AC270 3 days Travel Management Travel Expenses Human Resources
SAP AG 1999
**
(C) SAP AG
TASD41
9-3
Controlling
Level 2 Level 3
AC412 2 days Cost Center Accounting: Extended Functionality AC410 Cost Center Accounting 3 days AC415 2 days Overhead Orders AC420 AC040 5 days 2 days
Activity Based Costing AC510 3 days Cost Object Controlling for Products AC505 3 days Product Cost Planning AC605 5 days AC515 3 days Cost Object Controlling for Sales Orders AC530 2 days Actual Costing / Material Ledger AC650 Transfer Prices AC620 2 days Executive Information System (EIS) - Setting up the System AC625 1 day Executive Information System (EIS) 3 Business Planning 2 days
SAP AG 1999
(C) SAP AG
TASD41
9-4
Level 3
HR510 Personnel Development 3 days
HR515 3 days Training and Event Management HR310/311 5 days Time Evaluation HR307 2 days
Human Resources
Programming in HR HR530 3 days Technical Topics in Human Resources CA500 2 days CATS The Cross Application Time Sheet
3 days
(C) SAP AG
TASD41
9-5
Level 3
HR390 Introduction to Payroll HR400 2 days
5 days
Payroll Configuration HR050 5 days HR4xx 3 days Country-Specific Payroll HR7xx 2 days Payroll Reporting (Country-Specific)
Human Resources
SAP AG 1999
(C) SAP AG
TASD41
9-6
Logistics Execution
Level 2 Level 3
LO530 3 days Warehouse Management LO140 3 days Processes in Logistics Execution LO610 Shipping 2 days
LO531 3 days Additional Topics in Warehouse Management LO650 3 days Cross-Functional Customizing in SD
LO611 Transportation
3 days
SAP AG 1999
(C) SAP AG
TASD41
9-7
Level 3
LO606 Sales Workshop 1 day
LO645 2 days Credit and Receivables Risk Management 2 days LO925 Cross-Application Business Processes in SD and MM
SAP AG 1999
(C) SAP AG
TASD41
9-8
Production Planning
Level 2
LO980 3 days Engineering Change Management LO235 KANBAN LO050 5 days Manufacturing Planning & Execution for Discrete & Repetitive LO205 3 days Basic Data for Discrete Manufacturing LO985 3 days LO206 3 days Basic Data Part 2 2 days
Level 3
LO210 5 days Production Planning LO215 5 days Production Orders LO225 3 days Repetitive Manufacturing LO930 2 days Logistics Information System (LIS) Reporting 5 days LO990 Variant Configuration Part 1 LO991 3 days Variant Configuration Part 2 LO230 5 days
Capacity Planning
2 days LO720 CAP Calculation of Standard Values 2 days LO275 Special Features of LIS in Production 2 days LO935 Logistics Info Planning
SAP AG 1999
(C) SAP AG
TASD41
9-9
Enterprise Controlling
Level 2 Level 3
E C - E I S: Executive Information System AC615 2 days Executive Information System (EIS) 1 Reporting AC620 2 days Executive Information System (EIS) 2 Setting up the System E C - B P: Business Planning AC625 1 day Executive Information System (EIS) 3 Business Planning
E C - P C A: Profit Center Accounting AC040 5 days AC610 Profit Center Accounting 2 days
Consolidation of Investments
EC-CS: Consolidation Functions AC205 2 days Financial Closing AC220 5 days Special Purpose Ledger
Controlling Enterprise Controlling Financial Accounting
AC010
5 days
SAP AG 1999
(C) SAP AG
TASD41
9-10