76577865-46326151-sap-sd-billing
TRANSCRIPT
SAP SD ECC 5.0 - Billing
10th December, 2007
2
Billing Document Structure
Basic Functions in Billing
Billing Document Type
Copying Control
Billing Processing
Invoice List
The General Billing Interface
Down Payments for Sales Orders
Installment Plans
Retroactive Billing
Billing Plan
Contents
3
Billing Document
Definition : Umbrella term for invoices, credit memos, debit memos, pro forma invoices and cancellation documents.
Use: The billing document is created with reference to a preceding document, in order to create an invoice or a credit memo, for example.
Structure: All billing documents have the same structure. They are made up of a document header and any number of items.
4
Billing Document Structure
Header
Item 1
Item 2
Item 3
Company
Max Smith
Smithsville
J Miller
Richville
5 Units type 0815 Rs 3000
4 Units type 0816 Rs 1000
5
Billing Document Structure
Header : The header contains the general data that is valid for the entire billing
document. This includes:
• Customer number of the payer
• Billing date
• Net value of the entire billing document
• Document currency
• Terms of payment and incoterms
• Partner numbers, such as the identification number of the sold to party
• Pricing Elements
6
Billing Document Structure
Items: The items contain the data relevant for each individual item. This
includes:
• Material number
• Billing quantity
• Net value of the individual item
• Weight and volume
• Number of the reference document for the billing document (for example, the
number of the delivery on which the billing document is based)
• Pricing elements relevant for the individual items
7
Billing Document Screens
The data in the billing document can be displayed on different screens. These
screens are divided up as follows:
- Overview screens:
- Overviews with header and item data
- Detail screens:
- Screens at header level with general data
- Screens at item level with specific data for the item
8
Billing
Billing represents the final processing stage for a business transaction in sales and
distribution. Information on billing is available at every stage of order processing
and delivery processing.
Functions :
• Creation of invoices based on deliveries or services
• Issue credit and debit memos
• Pro forma invoices
• Cancel billing transactions
• Comprehensive pricing functions
• Issuing rebates
• Transfer billing data to financial accounting
9
Basic Functions in Billing
Billing Types
Number range
Match codes
Copying control
Blocking reasons
Displaying lists
Displaying the billing due list
10
The billing type controls the whole billing document.
The billing types are used to cover the full range of business transactions during
billing processing.
The following is a list of billing types:
• F2 Invoice
• F5 Pro forma invoice for sales order
• F8 Pro forma invoice for delivery
• G2 Credit memo
• L2 Debit memo
• RE Returns
• S1 Cancellation invoice
• S2 Cancellation credit memo
• LR Invoice list
• LG Credit memo list
Billing Types
11
Billing Types
• IV Intercompany billing (invoice)
• IG Intercompany billing (credit memo)
• BV Cash sale
12
Define Billing Types
Number that determines
how documents are to be
numbered by the system. It
indicates which number
range is relevant for a
document type
A classification for the
different types of
documents that you can
process.
13
Define Billing Types
To block automatic
transfer of the billing
document to accounting,
mark the field
A grouping that allows you
to control certain features
of transaction flow by
sales, shipping and billing
documents
14
Define Billing Types
Indicates whether the
system stores
information from billing
documents of this type
for the purposes of
statistical analysis
Used to differentiate the
billing documents by
requirements for invoice
printing, billing document
creation and forwarding to FI
15
Define Billing Types
The document type
classifies accounting
documents.
Indicator that causes
the transaction figures
to be reset for a
document item
16
Define Billing Types
The indicator controls
which partner functions of
the billing document can
be forwarded to financial
accounting.
Classification that
distinguishes between
invoice list types
17
Define Billing Types
If this field is set, the
reference billing
document is not settled
and the payment deadline
date for the base billing
document comes after the
billing date for the credit
memo, then field VALDT (
fixed value date) in the
credit memo request is
filled with the payment
deadline date of the
baseline date of the base
billing document.
18
Define Billing Types
Indicates whether the
billing type is used
exclusively during rebate
processing
Indicates whether
billing documents of
this type are relevant
during rebate
processing
19
Define Billing Types
Specifies the default
cancellation for this billing
type
Identifies a copying
routine. The routine
checks that certain
requirements are met
when one document is
copied into another
20
Define Billing Types
The reference number is a
piece of additional
information forwarded from
SD to FI
You can find the
allocation number under
additional information in
the (document) line item
that is forwarded from SD
to FI
21
Specific functions can be defined for each billing document type. This is done using control elements that are specified in tables.
The billing document type controls the following elements:
• The number range for the document number
• The billing type that can be used to cancel the billing document.
• The transfer status of the billing document is
- transferred to financial accounting
- blocked from transfer
- not transferred
• The procedure for account assignment in financial accounting
The allowed output for a business transaction and the procedure for output
• The partner functions allowed at header level
• The partner functions allowed at item level
Billing Type Controls
22
Invoice
Definition:
A sales document used to bill a customer for goods delivery or service.
Deliveries and services which are carried out on the basis of sales orders are
invoiced to the customer.
If no complaints are made about the delivery, the business transaction is
considered complete from the sales point of view.
When you create an invoice, you can refer to an order, a delivery, individual order
or delivery item or even partial quantities within an order item or a delivery item.
If you want to make sure that the goods are sent out before the invoice is created,
you would create an invoice on the basis of the delivery.
If you want to receive money before you send the goods to the customer, you
would create an invoice with reference to a sales order.
When you bill a customer for a service, you would probably refer to the sales order,
since a service is usually based on an order, not a delivery.
23
Billing Type Proposal
In customizing for the item category, you can determine whether billing is to be
carried out with reference to a delivery or an order.
The system proposes a relevant billing type from the underlying sales document
type. For example, in delivery-related billing, a standard order ( order type OR) is
invoiced using billing type F2.
24
Delivery-Related Invoices
You can use an invoice to refer to an order and a delivery simultaneously.
For example, you create one invoice for goods ( the carpet) and service
(installation) as long as the requirements for combining the two are met.
25
Order-Related Invoices
If you want to invoice a customer for services rendered, normally you
create an invoice with reference to the sales order because deliveries are not
usually created for services, such as laying a carpet.
26
Cancellation
To cancel a billing document, a cancellation document must be created. The
system copies data from the reference document into the cancellation and offsets
the entry in Accounting.
The reference document of the billing document (for example, the delivery for the
cancelled invoice) can now be billed again.
Credit memos can be cancelled with billing document type S2 in the standard
system.
We do not need to make an entry in copying control for cancellations. The
parameters to be changed ( for example, assignment number and reference
number) are stored per billing type directly in the cancellation area of the screen.
We also have the option of canceling individual items in a billing document.
27
Credit and Debit Memos
Credit memo: A sales document created on the basis of a customer complaint.
This reduces receivables in Financial Accounting.
Debit memo: A sales document created on the basis of a customer complaint. This
increases receivables in Financial Accounting.
Use: We need to create credit memos for various reasons (for example, because
of defective goods or because we have overcharged a customer)
Similarly, we may need to create a debit memo, if , for example, we have not
charged the customer enough.
28
Creating a Credit Memo / Debit Memo
Credit and debit memos may be created either with reference to credit or debit memo requests ( sales documents) or directly with reference to a billing document ( if the company does not require a release procedure in the case of complaints)
We can create credit and debit memo requests:
• Without reference to a previous business transaction
• With reference to an order
We can control in customizing whether the system is to set a billing block automatically for a credit or debit memo request. The employee responsible can:
• Release the credit or debit memo request after review. The employee responsible can decide the amount or quantity to be credited or debited.
• Reject items in the credit or debit memo request and enter a reason for rejection.
29
Releasing or Rejecting Credit Memo Requests
We can release a credit memo request or return by removing the billing block.
If the complaint has not yet been justified you can enter a reason for rejection for
each item.
The value of these items will not be copied into the billing document.
Using the reasons for rejection allows you to control whether the item:
• Is copied into the credit memo with a zero value
• Appears in the credit memo at all
Debit memo requests are processed in exactly the same way.
30
Workflow for Credit Memo Requests
Credit memo requests are usually blocked for billing (that is, credit) upon creation
until the employee responsible releases this block.
Within the company, we can make the definition of the point at which the check is
carried out and the employee responsible dependent upon the value of the credit
memo request.
If the value of the credit memo request is below a certain minimum limit, then it can
be released automatically by the system.
The workflow within the framework of credit memo processing now guarantees that
the employee responsible is automatically determined and informed when a credit
memo request is created, depending on the value involved.
The employee responsible can either reject, release, or process the credit memo
request.
31
Invoice Correction Process Flow
The invoice correction request represents a combination of credit and debit memo
requests.
On the one side, credit is granted fully for the incorrect billing item while it is
simultaneously debited ( automatically created as a debit memo item). The
difference created represents the final full amount to be credited.
The invoice correction request must be created with reference to the corresponding
billing document ( no reference to order or enquiry).
When creating an invoice correction request, the items are automatically duplicated
( this means that for every item in the billing document, a second item is created).
The resulting item categories must have +/- values.
First all credit memo items are listed, followed by all debit memo items. The
reference to the corresponding billing document is created when you specify the
preceding document and the preceding item.
32
Invoice Correction Process Flow
The credit memo item cannot be changed. The corresponding debit memo item,
however, can be updated according to new characteristics ( e.g. new pricing,
change in quantity).
We can delete the credit and debit memos in pairs ( unchanged pairs of items can
be deleted all at once in this way).
33
Quantity Difference
Quantity difference is used when a customer complaint is being processed due to a
certain amount of damaged or sub-standard goods.
The system corrects the quantity to be billed via the debit memo item.
If other item pairs arise from the relevant billing document and these item pairs are
unchanged, they can be deleted in one step, using the Delete unchanged items
function.
34
Price Difference
Price difference is used when a customer complaint is being processed for
incorrect pricing of goods.
A correction of the pricing elements must be carried out in the debit memo.
35
Returns
We create return for goods sent back from a dissatisfied customer.
Returns are processed in the same way as credit memo requests.
The credit memo is billed with reference to the order, which means it refers to the
return request document, not to the return delivery.
36
Pro Forma Invoices
Definition:
An invoice that is created on paper for exported goods to provide the
customs authorities with evidence of the cost of the goods.
When you deal in export, you may need to print pro forma invoices. They are used
to give the importer or the responsible authorities in the import country details
about forthcoming shipments.
A pro forma invoice appears exactly the same as a customer invoice. The
difference is that this invoice does not need to be paid. Therefore, the system does
not forward data to Financial Accounting (FI). No statistical data is created on the
basis of pro forma invoices.
You can create as many pro forma invoices as required, since the billing status in
the reference document is not updated.
In copying control, the field Quantity / value pos./ neg. is not available for entry in
order to avoid the possibility of a pro forma invoice updating the quantity that has
already been billed in the reference document.
37
Billing Process
Each billing document requires a reference document ( exception: billing external
transactions). This may be :
• Sales document
• Outbound delivery
• Billing document
When billing explicitly, you must enter the number of the reference document as
the transaction to be billed.
You must always refer to an existing document when creating a billing document.
Data will then be copied from the reference document to the billing document. For
delivery-based billing, the quantities to be billed, for example can be taken from the
delivery; the prices, however, are taken from the underlying order.
The reference document is displayed as the source at header level in the copying
control table.
38
Data Flow
You can, to a certain extent influence the data flow from reference documents to billing documents. This is done using:• Billing types ( for example, for texts, partners)• Copying control: the control options are as follows:
At header level:- Foreign trade data- Allocation number- Reference number- Item number assignment
At item value:- Quantity- Pricing
You can also use data transfer routines to influence the data flow to meet your individual requirements. For example, terms of payment can be copied from the customer master instead of the preceding sales document.
39
Data Flow
Example : Delivery –related billing
Order InvoiceOutbound Delivery
For example:
Payer, Item no.,
Pricing, texts
For example:
ship-to party,
amount, texts
40
Copying Control
Target Billing type Source Delivery Type
F2 LF
F2 LF TAN
Header
Target Source Source
Billing Type Delivery Type Item Category
Item
41
Copying Control
The system administrator can define how data is transferred in the billing process
in the copying control table. Controls are determined for:
• The header ( target: billing type, source: sales document type)
• The item (target: billing type, source: sales document type, item category)
The following controls are found at header level:
• Reference document: which documents may be used as reference for billing?
• Determination of foreign trade data, allocation numbers, reference numbers, and
item numbers
42
Copying Control at Item Level
The following controls are found at item level:
• Billing quantity: which quantity should be invoiced – the order or delivery quantity
?
• Pricing and exchange rate. Should pricing, for example, be carried out again or
should prices from the order be copied over, and at what exchange rate?
• Updating the quantity and value in the reference document
• Where should the conditions in the billing document be carried over from ( for
example, copying over shipment costs from the shipment cost document)?
Customizing: Billing -> Billing documents->Maintain copying control for
billing documents
43
Copying Requirements
Using requirements in copying control, you can specify how a sales document is to
be billed with regard to requirements.
You define the copying requirements in copying control. Controlling is carried out in
SD Customizing by Billing Billing Documents Maintain copying control for
billing documents, Navigation Header and Item, Field Copying requirement
If you want to define a copying requirement as a data transfer routine, enter this in
filed VBRK/VBRP. In this way, you can determine whether terms of payment are to
be copied from the customer master record instead of the sales document.
With requirements in copying control you can, for example, specify whether goods
issue has to be posted before billing can be carried out.
You can define your own requirements using transaction VOFM.
44
Copying Control
45
Copying Control
46
Copying Control
Identifies a copying routine.
The routine checks that
certain requirements are met
when one document is
copied into another.
47
Copying Control
Identifies a routine that
checks that certain
requirements are met during
the transfer of data from
billing document item fields
during copying
48
Copying Control
Specifies which quantity the system copies
from the source document into the target
billing document.
49
Billing Quantity
Delivery and order quantities are referenced in billing. You can also take into
account the quantity already billed ( depending on the area for which the relevant
billing type is used).
This makes it possible, for example, to create an order-related billing document for
quantities already delivered.
50
Billing Quantity Indicator
When you create an invoice for a standard sales order item, for example, the
quantity that the system copies into the invoice is the delivery quantity less the
quantity already invoiced. If you create a pro forma invoice, the system copies in
the order quantity.
Indicator uses:
• A Order-related billing
• B Delivery related billing
• C and D Pro-forma invoices
• E, F and I Third party business transaction
• G and H Batches
• Note: Make sure that control of the amount to be billed is directly related to the
item category billing relevance.
51
Billing Quantity
Billing document Billing quantity
Based on an order Order quantity minus quantity
(e.g. standard order) already billed
Quantity already delivered minus
quantity already billed
Based on a credit Order quantity minus quantity
memo request already billed
Based on a delivery Quantity already delivered minus
(e.g. billing types quantity already billed
F1 and F2)
Pro forma invoice F5 Order quantity
Pro forma invoice F8 Delivery quantity
52
Copying Control
Indicates whether, during copying, the quantity or
value in the target document has a negative effect,
positive effect or no effect at all on the quantity still to
be completed in the source document.
53
Pos./neg. Quantity
Use
The system uses this indicator to determine how the quantity in the source
document is affected. For example, if you create a quotation item for 100 pieces,
copy the quotation into a sales order and create a sales order item for 80 pieces,
the copying has a positive effect on the quotation. In effect, you have added 80
pieces to the quotation quantity that is now considered complete. 20 pieces in the
quotation remain to be completed.
If you do not make an entry in this field, or set indicator 0, the source document is
not blocked, which allows you to create several target documents at once ( for
example when using EDI and frequent contract releases).
While the source document ( such as quotation or quantity contract ) is being
processed, it is blocked. For instance, if you are working on a quantity contract, no
one can create a release order for that contract.
54
Pos./neg. Quantity
In sales documents, for example, you can expect the following results:
• Quotation Sales order : Positive
• Contract Return : Negative
• Sales order Sales order : No effect
In billing documents, for example, you can expect the following results:
• Delivery Invoice : Positive
• Delivery Cancellation : Negative
55
Pricing in the Billing Document
When a sales document is created, the system automatically carries out pricing.
During billing you have the option to copy the prices from the sales document to
the billing document or to have the system carry out pricing again. You can also
trigger pricing manually.
You define the pricing type in copying control.
56
Copying Control
Specifies how the system treats pricing data
when copying documents.
57
Pricing Types
At the time of billing, the following possible pricing types may be set for
the items:
A: The pricing elements are copied from the reference document and updated
according to a scale.
B: Carry out new pricing
C: The manual pricing elements are copied, and pricing is carried out again for the
others.
D: The pricing elements are copied unchanged from the reference document.
E: Copy pricing elements and values unchanged
F: Only used within the program
G: The pricing elements are copied unchanged from the reference document. The
tax conditions are re-determined.
H: The pricing elements are copied unchanged from the reference document. The
freight is re-determined.
58
Pricing in the Billing Document
59
Copying Control
Determine pricing exchange rate
60
Pricing Exchange Rate
Options in Pricing Exchange Rate are :
A Copy from sales order
B Price exchange rate = Accounting rate
C Exchange rate determination according to billing date
D Exchange rate determination according to pricing date
E Exchange rate determination according to current date
F Exchange rate determination according to date of services
rendered
61
Copying Control
This field controls from where and in what
sequence the conditions from the reference
documents are copied to the billing
document.
62
Price Source
Price Source Description
Blank Order
A Purchase Order
B Purchase order / delivery
C Not used
D Delivery
E Delivery / order
F Shipment costs
G External
63
Billing Processing
During billing processing, you create, change and delete billing documents.
You can create billing documents:
• With reference to a sales document
• With reference to a delivery order
• With reference to external transactions
You can refer to an entire document, individual items or partial quantities of items.
You can create billing documents in the following ways:
• By having the system process a billing due list automatically as a background
task
• By processing manually from a worklist
• By creating a billing document explicitly
64
Processing Billing Due Lists
You will not usually bill transactions individually. You are far more likely to carry out
periodic collective billing runs ( by goods issue posting, for example).
If you are working with the billing due list, enter the selection criteria ( such as sold-
to party, billing date, and destination country). The system uses the selection
criteria as a basis for combining the transactions to be billed.
When selecting, you can also decide whether the billing due list should only contain
documents that are order-related, delivery-related, or both.
After saving, you can display the log to determine which billing documents were
created from a billing due list and whether any errors occurred.
You can process the billing due list in simulation mode. The system displays the
billing documents without saving the documents. Transactions containing errors
are indicated with the corresponding processing status.
65
Process Billing Due List
66
Creating Invoices on Specific Dates
You can process invoices periodically. All deliveries due for billing on a certain date
can be combined into one collective invoice.
To do this, you must first :
• Maintain Individual billing dates in the factory calendar using special rules
• Enter the factory calendar in the customer master record of the payer ( Invoicing
Dates on the Billing document screen).
• When you enter a document, the system copies the next invoice date from the
factory calendar to the appropriate document as the billing document.
• The calendar is client-independent.
67
Billing in the Background
You may decide to create invoices using a background job because it is practical
and efficient. You can run the background job automatically in the following ways:
• Periodically ( for example, every Monday at 2 a.m.)
• At a specific time ( for example, June 19 at 8p.m.)
The system can divide the billing due list into multiple background jobs and start
them simultaneously. In this way, you can make better use of your hardware by
operating more than one processor.
If you do not require a log or a detailed list, SAP recommends that you do not
select these options in the selection screen. This will improve performance
considerably.
68
Background Processing
69
Cancellation of Collective Billing Run
The system contains functions to enable you to cancel the collective billing run.
This cancels all the billing documents in a collective run. The cancelled billing
documents are combined under a collective processing number in collective
processing type S and can be displayed under billing document Log.
You can then bill the preceding documents for the cancelled billing document
again.
Only users with the correct authorization can cancel collective runs.
In order to cancel the collective billing run, choose :
Billing Information system Billing document Log of collective run
Documents Reverse all.
70
Log of Collective Run
71
Transaction Codes in Billing Document
VF01 Create billing document
VF02 Change billing document
VF03 Display billing document
VF07 Display from archive billing document
VF11 Cancel billing document
VF04 Process billing due list
VF06 Creating background jobs for billing
VFRB Retrobilling
VFX3 Release billing documents for accounting
72
Methods in Billing
The following methods may be used in billing:
• One individual billing document per sales document
• A collective billing document for several sales documents
• Several billing documents for one or more sales documents ( invoice split)
73
Individual Billing Documents
74
Individual Billing Documents
Settings for Individual Billing Documents
Copying control is carried out in SD Customizing via Billing-> Billing Documents -
>Maintain copying control for billing documents, Navigation Item, field:
VBRK/VBRP. In this field you select data transfer routine 3
The number of the reference document is set in field VBRK-ZUKRI.
75
Collective Billing Documents
76
Collective Billing Documents
It is possible to include both order-related and delivery-related items in the same
billing document.
The following prerequisites must be met for collective billing document:
• The header data appearing in the billing document must agree.
• The split conditions specified do not apply.
• The system behaves differently for the functions Billing Due List and Create
Billing Document.
77
Invoice Splits
78
Invoice Split
In customizing for copy control, you can specify requirements for splitting to
prevent sales orders or deliveries being combined into a collective billing
document.
As a rule, the system combines into one billing document all transactions for the
same customer, default billing date and sales organization.
If data from the related reference documents differs in the header fields of the
billing document, the system will automatically split the invoice.
An order contains terms of payment at header as well as item level. These are
stored at header level in the billing document. However, if there are different terms
of payment in the reference documents, an invoice split will always be made.
If data from the related reference documents differs in the item fields of the billing
document the system does not split the invoice.
79
Invoice Split
The order basis is stored at the header level in the order and at item level in the
billing document. The system does not split the invoice. If you require an invoice
split, you must first define the appropriate splitting requirements in Customizing for
copying control.
Copying control depends on the following criteria:
• Reference document type (i.e. type of order, delivery or billing document on
which the sales document is based)
• Billing document type
• Item category in the reference document
80
Item-Dependent Invoice Split
The system administrator can also define additional split requirements in
Customizing for copying control to prevent the system from combining sales
documents in a billing document.
Example: Separation based on material group or profit center.
Field VBRK-ZUKRI is used in the billing header to store these additional split
criteria.
Fields that cause a split are displayed in the split analysis.
81
Performing a Split Analysis
You can use split analysis to review why the system has split a billing document. It compares two billing documents and lists the fields which have differing contents.
You can call up the Split analysis function with the following transactions:
Billing document -> Change or display
Billing document -> Billing due list
To display the split analysis for one of these screens, proceed as follows:
Enter the number of the billing document that you wish to compare.
Choose Environment -> Split Analysis
Enter the number of the second billing document which you wish to compare to the first in the dialog box.
Enter the billing document number and choose Continue.
The system displays the split analysis log. It is made up of three parts. The first shows the header partners and header fields which are different in the two documents while the second and third columns show the respective values for these fields.
82
Split Analysis
83
Invoice List
The invoice list lets you create, at specified time intervals or on specific dates, a list
of billing documents (invoices, credit and debit memos) to send to a particular
payer.
The billing documents in the invoice list can be single or collective documents (
collective invoices combine items from more than one delivery).
The standard version of the SAP R/3 system includes two types of invoice lists:
• For invoices and debit memos LR
• For credit memos LG
If you wish you can process invoices, debit memos and credit memos at the same
time. The system automatically creates a separate invoice list for credit memos.
84
Invoice List
Type of invoice list
85
Invoice List
A payer may be the head office of a buying group, which pays all the invoices for
goods that are shipped to individual members.
The group payer takes responsibility for paying the invoice lists and the collecting
payment from the individual members. In return for these services, the group
payer usually earns a factoring discount.
Prerequisites for invoice lists
If you have agreed upon a factoring discount, condition type RL00 ( factoring
discount) must be maintained and if required also the condition type MW15.
An invoice list type must be assigned to each billing type that you want to process
in invoice lists.
Copying requirements must be defined ( for example, the payer, terms of payment
and other fields that must be identical in the documents to be included in the
invoice list).
86
Invoice List
In addition, before you process an invoice list, you must maintain the following
master data.
• A customer calendar must be defined, specifying the time intervals or dates on
which invoice lists are to be created. This factory calendar is to be entered in the
payer customer master record. ( Billing screen, Invoice list schedule field)
• Maintain condition records for condition type RL00 for the payer.
• Create output condition records for condition types LR00 and RD01. ( you can
determine whether invoice papers are to be sent to the customer upon invoice
creation or only when the invoice list has been created).
87
Changing Header and Item Data in Invoice List
You can change some of the header data – for example, the billing date - when you
process the invoice list.
You can change an item – either an individual or collective invoice – and display
document details.
However, you cannot change any data in individual billing documents once they are
part of an invoice list.
88
Creating an Invoice List
To create an invoice list
1) Select the Billing screen
Depending on the number of billing documents that you want to include, you can
choose one of two ways to create the invoice list. You can either
• Select invoice list Create and enter each billing document separately
• Create a list of all billing documents that are relevant for the invoice list. You can
then process the work list for invoice lists.
This procedure shows you how to create the work list.
2) Select Invoice List Edit Work List
3) Enter your selection criteria and press ENTER
The system displays a list of billing documents that meet your selection criteria.
4) Select the billing documents that you want to include in the invoice list and select
Invoice List Save
89
Creating an Invoice List
You can also simulate creation of invoice lists via the work list for invoice lists. This
is useful as a test option. The simulation also allows you to carry a split analysis,
which show you why billing documents are written to different invoice lists (e.g. due
to different payers)
Incorrect invoice lists can also be cancelled.
90
Creating an Invoice List
91
Creating an Invoice List
92
Transaction Codes in Invoice List
VF21 Create invoice list
VF22 Change invoice list
VF23 Display invoice list
VF27 Display from archive invoice list
VF26 Cancel invoice list
VF24 Edit work list for invoice list
93
Customizing for Invoice List
Assign Invoice List Type To Each Billing Type
Maintain Conditions for Invoice Lists
Maintain Output for Invoice Lists
94
Assign Invoice List Type To Each Billing Type
95
Maintain Conditions for Invoice Lists
Create Condition Tables
Maintain access sequences
Maintain pricing procedures
Define condition types
96
Create Condition Tables
97
Maintain Access Sequence
98
Maintain Pricing Procedure
99
Define Condition Types
100
Maintain Output for Invoice Lists
Maintain output condition tables for billing documents
Maintain access sequences
Maintain output determination procedures
Output types
Two new output determination procedures have been created for determining
output in invoice lists:
• V30000 - Invoice list output
• V30001 – Invoice list item output
101
Maintain output condition tables for billing documents
102
Maintain access sequences
103
Maintain output determination procedures
104
Output types
105
General Billing Interface
Using the general billing interface, you can invoice external documents in the SAP
R/3 system ( that is, order and deliveries not created in the R/3 system).
To do this, you must first:
• Prepare the data in a sequential file of specified format
• Specify a minimum number of required fields to be filled from the data records.
• Specify the remaining fields required for billing either through the data records for
the sequential file or through the R/3 system ( optional fields)
Examples:
Required fields : Customer master, sales organization, …
Optional fields : Material master, price components, …
106
General Billing Interface
External reference numbers can be entered in the interface ( such as external
delivery numbers or external order numbers). When you create a billing document,
the system records document flow using these reference numbers
You may decide to work with a CpD customer master record instead of taking data
(such as an address) from a customer master.
Pricing elements and /or VAT amounts can be transferred. Alternatively, you can
carry out new pricing in billing, entirely or only for taxes.
107
Working with the General Billing Interface
The communication structure of the general billing interface distinguishes the
following fields during the transfer of data from an external system.
Required fields which must be transferred.
Optional fields, which may be transferred, or fields which are determined from
available master data in the system during the billing document run.
108
Extracting Data from an External System
Billing data from an external system must be prepared in a sequential file which
must fulfill the following requirements:
Sequential file structure
Record
1st main record (Billing data)
Data : Indicator A in first position
Structure as of 2nd position analogue communication structure KOMFKGN
1st – nth secondary record (Pricing element)
Data : Indicator B in first position
Structure as of 2nd position analogue communication structure KOMFKGN
The client in the secondary record (MANDT) must correspond to the client in the
main record (MANDT)
109
Extracting Data from an External System
The document condition record in the secondary record (KNUMV) must correspond
to the document number of reference document in the main record (VGBEL)
The condition item number (KPOSN) must correspond to the item number of the
reference business transaction item in the main record (VGPOS)
Sorting main records in the sequential file according to:
• Sales Organization : VKORG
• Distribution Channel : VTWEG
• Sold to party : KUNAG
• Document number of the reference document: VGBEL
• Item number of the reference item : VGPOS
110
Extracting Data from an External System
Processing errors:
You can carry out a check run with sample report RVAFSS00 to display faulty
records in the sequential file before final billing. All errors are displayed in error log.
After correcting the faulty records in the sequential file, you must restart the billing
procedure. The system ignores records which have already been billed and
creates billing document for records which have been corrected. Optionally, a list of
new billing documents is presented with the error log.
111
Communication Structures
Use
Sample report RVAFSS00 supplies communication structures XKOMFGN and XKOMFKKO with data from the sequential file and initiates the billing process.
The following fields in the sequential file‟s main record must be maintained.
Field Name Field Length Field Description
MANDT 3 Client
AUART 4 Sales document type
VKORG 4 Sales organization
VTWEG 2 Distribution channel
SPART 2 Division
FKDAT 8 Billing data
KUNAG 10 Sold-to party
WERKS 4 Plant or
LAND1 3 Country key
112
Communication Structures
Field Name Field Length Field Description
PSTYV 4 Item category
KWMENG 8 Cumulative order quantity
The following fields do not have to be maintained but it is recommended that you do so as it gives information on document flow.
VGBEL 10 Document no. of the reference document
VGPOS 6 Item number
If you are also transferring pricing elements, you must maintain the following fields in the sequential file‟s secondary record:
Field name Field length Field description
MANDT 3 Client in main record
KNUMV 10 VGBEL in main record
KPOSN 6 VGPOS in main record
KSCHL 4 Condition type
KBETR 6 Condition amount
113
Communication Structures
All the fields in both communication structures KOMFKGN and KOMFKKO are
optional. You may fill them with data from the system as necessary during the
billing run ( the payer field, for example).
Once the communication structures have been maintained, the system initiates
billing with function module GN_INVOICE_CREATE
114
Text Transfer
Texts (header and item) can be transferred in the general billing interface.
You can use the test report RVAFSS01 to write text information in a flat file.
The report RVAFSSS00 imports a flat file and completes the interface tables for the
program N_INVOICE_CREATE depending on the record type. This program is
then called up.
Record type Interface table Purpose
A XKOMFKGN Item data
B XKOMFKKO Condition data
C XKOMFKTX Text data
115
Text Transfer
The interface table has the structure XKOMFKTX
Component Component type
MANDT MANDT
VGBEL VGBEL
VGPOS VGPOS
TDOBJECT TDOBJECT
TDID TDID
TDSPRAS SPRAS
TDFORMAT TDFORMAT
TDLINE TDLINE
116
Text Transfer
Texts are only transferred into the billing document if the following are completed:
VGBEL or VGBEL/VGPOS
TDOBJECT ( as a rule TDOBJECT = „VBBK‟ or „VBBP‟)
TDID
If only VGBEL is complete, this is a header text. If VGBEL/VGPOS is complete, this
is an item text.
117
Reading the Material Master
If the NO_MARA field in the main record of the sequential file is marked, the
material master will not be read. In this case, the following additional fields in the
main record must also be maintained.
Field name Field length Field description
VRKME 3 Sales unit
WAERK 5 Currency
ARKTX 40 Material-short text
TAXM1 1 Material-tax indicator
118
Customizing
The following parameters should be taken into consideration:
• Billing Document Type
• Use billing document type FX for billing external transactions or create your own.
• Control of Document Flow
• If you wish to take into account secondary records copied to the sequential file,
maintain one of the following pricing types in Customizing under „Copying control
for billing documents‟:
Pricing type Description
D Copy pricing elements unchanged
G Copy pricing elements unchanged, re-determine tax
C Copy manual pricing element unchanged, re-determine all
others
You may also copy a scale quantity (XKOMFGEN-SMENG) from the interface with
pricing type B (new pricing)
119
Customizing
Condition types
Condition types that are transferred into secondary records must be set up so that
the manual value has priority (manual entry = C).
Pricing procedure
To prevent the material master from being read, make sure that no conditions
which initiate reading of the material master are set in the pricing procedure ( for
instance, costs – VPRS).
Copying control
Copy control 013 in copying control for billing documents at item category level
ensures that the customer master block is observed and that records having a
billing quantity of 0 are ignored.
Item category
Item categories used in external business transactions must be relevant for pricing
and billing.
120
Function Module Parameter
Function module GN_INVOICE-CREATE is the main component of the general
billing interface.
The system immediately initiates posting when you enter A and B in import
parameter WITH_POSTING. Among other things, this function module returns
values from the following tables:
Table number Table name
XVBFS Error logs
XVBSS Collective processing number
XVBRK Billing documents
XVBRP Billing items
XKOMV Condition records
121
Processing one-time customers
Use
You must work with a CpD customer master record if customer master data (such
as an address) can not be used.
If you are using a data extract in the billing interface to transfer CpD customer data,
address data must exist in this data extract. Maintain the following fields in the
main record of the sequential file.
Field name Field length Field description
Land1 3 Country key
Name1 35 Name 1
PSTLZ 10 Zip code
ORT01 35 City
122
Processing one-time customers
Address data transferred to the file is assigned to the partner functions (except for
SP) described in the following fields.
Field name Partner function – Example
CPD_PARVW1 BP (Bill-to party)
CPD_PARVW2 PY (Payer)
CPD_PARVW3 SH (Ship-to party)
CPD_PARVW4
Exception:
Partner function SP ( Sold-to party) must be a CpD customer and is always
transferred with the transferred CpD address data.
No check is carried out for partner function usage.
123
Processing one-time customers
In addition to required fields, the following fields in table structure KOMFKGN are
available for CpD customer processing.
Field name Field length Field description
ANRED 15 Form of address
NAME2 35 Name 2
ORT02 35 District
STRAS 35 Street and house number
REGIO 3 Region
You can add additional fields to table structure SADR in INCLUDE structure
KOMFKZZ if the fields in table structure KOMFKGN are not sufficient for
processing CpD customers.
124
Down Payments for Sales Orders
Purpose
Normally, down payment agreements are made for producing and delivering goods
to customers in the capital goods, or plant engineering and construction industries.
Down payments are payments made before completion of the product, with no
interest. They represent short or medium term outside capital procurement and
therefore improve the company‟s liquidity situation.
125
Down Payments for Sales Orders
Features
Down payments form part of the agreement with the customer and are saved in the
sales order.
A down payment agreement is created as a deadline in the billing plan. This
enables you to carry on as many down payments as required for different dates.
The date for the down payment yet to be created is specified in the deadline, and
the system uses payment conditions to assign a due date to the down payment,
The value of the agreed down payment can be entered either as a fixed amount or
as a percentage of the value of the item.
If a down payment agreement is assigned to one item with a billing plan, the down
payment agreement is contained as a deadline in this billing plan.
Down payment agreement can be used only for order-related billing and not for
delivery-related billing.
126
Customizing for Down Payment Processing
Settings for the billing plan
To activate the billing plan function, maintain the materials, for which you wish to
process down payments, with item category group 0005 (milestone billing). This
gives the item category TAO via item category determination. The item category
TAO calls up the billing plan function.
You need to implement the following activities in the billing plan for down
payments:
• Maintain the deadline type. This determines the billing rule (percentage or value
down payment) for the down payment request.
• The system assigns billing type FAZ ( payment request) defined in the standard
system with billing category P. ( For the billing type FAZ there is the cancellation
billing document type FAS in the system).
• Maintaining deadline proposal. Use down payments that are due for the
proposed deadlines.
127
Maintaining a pricing procedure with the condition type
AZWR
In the standard system, the condition type AZWR is delivered for the down
payment value already provided but which has not been calculated. You must
include this condition type in the relevant pricing procedure before output tax.
Enter condition 2 (item with pricing) and the calculation formula 48 (down payment
clearing value must not be bigger than the item value) for the condition type AZWR.
Before the condition AZWR you can create a subtotal with the base value
calculation formula 2 ( net value). If the condition AZWR is changed manually, you
can get information on the original proposal from the subtotal.
Maintain the printing indicator.
The pricing procedure cannot be marked as a transaction-specific pricing
procedure ( field Spec. proc.)
The condition type AZWR has the calculation type B (fixed amount) and the
condition category E (down payment request / clearing).
128
Maintaining the Billing Document
In the standard system there is the billing type FAZ ( down payment request) and
for canceling the billing type FAS.
Controlling the down payment is done using the billing category P of the billing
type. A billing type becomes a down payment request when the billing category P is
assigned.
You have to maintain blocking reason 02 (complete confirmation missing) for the
billing documents and assign it to billing type FAZ.
Copying control:
Copying requirement 20 must be entered in copying control at item level for the
down payment request. In the standard system the order type OR for copying
control is set up according to the billing type FAZ for the item category TAO.
Copying control 23 must be entered in copying control at item level for down
payment clearing. In the standard system the order OR for copying control is set
up according to the billing type F2 for the item category TAO.
129
Down Payment Request
Billing category is set as P
130
Financial Account Settings for Down Payment
A prerequisite for down payment processing is that the account is assigned to the
underlying sales account. To do this, change the field status settings in
customizing as follows:
Set reconciliation accounts (transaction OBXR)
For the received down payments and down payment requests from the
G/L accounts you have selected, you should assign the field status definition G031.
Maintain accounting configuration (transaction OBXB)
For the down payments (posting key ANZ in the standard system) and the
output tax clearing (posting key MVA in the standard system), you must maintain
the posting key.
You must also carry out a G/L account number assignment for the tax
account.
Maintain the posting key (transaction OB41)
For posting key 19 set the sales order as an optional field.
131
Financial Account Settings for Down Payment
Maintain the field status definition (transaction OB14)
For field status variant 0001, field status group G031, set the sales order
as an optional field.
Assign the company code to the field status variants (transaction OBC5)
132
Down Payment Agreements in the Sales Order
Control for Down Payment Agreement is carried out via the billing rule:
• Billing rule 4 : Down payment for percentage milestone billing
• Billing rule 5: Down payment for value milestone billing,
For percentage milestone billing, the percentage share of the down payment is not
included in the overall calculation of the individual milestone billing documents.
The percentage specified for the down payment is always based on the total sum
of the individual milestone billing documents.
As soon as you take away the billing block and save the sales order, a billing index
is created for the individual dates.
An example is given for down payment processing for the documents in SD.
133
Down Payment Agreements in the Sales Order
134
Down Payment Request
A down payment request is sent to the customer in time for the deadline. The
request can be generated by the system from the billing due list, or you can enter it
manually. The down payment request is posted as such to Financial Accounting.
Billing type FAZ is used for creating the down payment request.
Tax is determined and displayed automatically when the down payment request is
created.
The down payment request in FI is created automatically from the down payment
request in SD.
You can view the down payment requests created in SD and FI via the document
flow in the sales order.
135
Down Payment Request
When transferring into FI (financial accounting) a down payment requirement is
created as a noted item in „down payment requirement‟ account in financial
accounting. The account „down payment requirement‟ has no effect on the balance
sheet or the profit and loss account.
You can see the created down payment requests in the document flow for the sales
order.
You can print out the down payment requirement and send it. To print out you do
not need an extra printing program or form. You just use RVADIN01 which is set
up for billing documents in the standard system with the form RVINVOICE01. The
following information is also given for down payment requests:
• „Down payment request‟ appears in the billing header.
• The total is labeled as „payment to be made‟.
• The billing value contains the text „Amount to be paid‟.
136
Down Payment Request
137
Down Payment Request
138
Down Payment Processing in SD/FI
The down payment request (SD) is automatically posted in Financial Accounting
(FI) as a down payment request ( posted as a noted item). The item has special
General Ledger (G/L) indicator F, which ensures that posting is statistical. Posting
is made to a different reconciliation account, which allows you to differentiate down
payment requests from other receivables.
When posting an incoming payment for a down payment, the incoming payment is
assigned to the down payment request. The down paid amount is also account
assigned for the sales order. The item has special G/L indicator A.
When processing partial / final invoices, the down payments made are transferred
as down payments to be cleared. Within FI, the down payments are deducted from
the special reconciliation account and entered in the standard reconciliation
account. The down payments for clearing then appear as open items for the
customer and reduce the total of receivables.
139
Payments Made
The customer makes the payment. The incoming payment is posted in financial
accounting with reference to the payment request. In this transaction the down
payment request is labeled as cleared. The clearing can also be seen in the sales
order document flow.
The noted items in the customer account which were generated by the down
payment requests become cleared posts.
The payment request is determined by assigning the down payment request to the
sales order item.
If the customer only pays part of the amount required, the down payment request
will be cleared completely nevertheless. Later down payments must therefore be
assigned manually to the sales order and the corresponding sales order item.
You can view the down payments in the open items of accounts receivable under
the special G/L indicator A.
140
Milestone Billing with Down Payment Clearing
The billing plan for the sales order contains billing-relevant deadlines. As soon as
you take away the billing block, you can carry out billing.
In billing those payments already made by the customer should be cleared. This
happens because those payments already made are taken into the billing
document as items to be cleared. They are set as items, after the billing items to
which they refer, in the billing document. When printing ( Report RVADIN01 with
form RVINVOICE01) the customer receives for the down payment items the text
„payments made‟ printed out. The down payment item value corresponds to those
down payments made.
There is no billing. Billing amount – Down payment amount = the remaining
amount to be paid. The customer merely receives the information concerning
which amount he can transport during payment.
141
Milestone Billing with Down Payment Clearing
You can change proposed down payment for clearing manually. The reason for
this can be that part of the down payment should be proposed for further billing.
Calculation formula 48 in the pricing procedure for the condition type AZWR merely
checks that the amount cannot be increased.
The down payments assigned to a billing document for clearing cause the system
to offset all the completed payments against receivables in Financial Accounting
(FI).
The total payment of the final invoice is automatically posted in FI as a receivable,
and the allotted down payments are cleared directly (down payment clearing). The
transaction is finished with the incoming payment posting and the open items are
cleared. Postings made to the relevant general ledger account in Financial
Accounting reduce the down payments left to be cleared.
142
Milestone Billing with Down Payment Clearing
143
Milestone Billing with Down Payment Clearing
In the above example, the system had originally proposed 40,000 (item 11) and
20,000 (item 12). The down payment clearings were then manually reduced. The
customer is then asked to take the down payments ( 30000 + 10000) from the total
amount 60000. For the example there is 20000 left to pay. The remaining down
payments are then processed in the final invoice. ( see next slide)
144
145
Milestone Billing with Down Payment Clearing
146
Milestone Billing with Down Payment Clearing
147
Milestone Billing with Down Payment Clearing
In the above only those items still open are shown ( those down payments not yet
cleared) due to the overview given by the customer account. That is, both lines
21/1 and 21/2 each with 10000.
The customer is therefore asked to take the 20000 that have not yet been cleared
from the 90000 due and to pay 70000.
148
Installment Plans
Billing doc. 4713
Value: Rs 300
Payment Terms: R001
1st installment : Rs 100
2nd Installment: Rs 100
3rd Installment: Rs 100
Invoice 4713
Total amount Rs 300
1. Install.: due May 1 Rs 100
2. Install. : due June 1 Rs 100
3. Install.: due July 1 Rs 100
Accounting document
Company code: 1000
----------------------------
Customer
1.Inst. Rs 100
2. Inst. Rs 100
3. Inst. Rs 100
Revenues: Rs 300
149
Installment Plans
An installment plan allows the customer to pay in installments. Only one billing
document is created for all of the installment payments. The printed invoice is
created on the basis of this billing document and includes a list of individual
payment dates and exact amounts.
Each installment payment creates an accounts receivable line item posting in FI.
You must define installment payment terms in customizing.
The installments are defined by the payment terms, which are controlled by the
payment terms key. The following data is to be defined:
• The number of installments
• The payment dates
• The percentage of the billing value
150
Installment Plans
You can store the default payment terms key in the customer master record (on the
Billing Sales Area screen, field : payment terms).
You can overwrite the payment terms key in the sales order header or item ( menu
path Header or Item --> Business Data, field Payment terms)
You can use the payment terms key to print a suitable text on the order
confirmation.
151
Cash on Delivery
Purpose
The customer orders from you. Transportation of the goods is carried out by a
forwarding agency, for example, by post. The goods are delivered to the customer
with an invoice and the customer pays upon delivery.
Prerequisites
Triggering Cash on Delivery
You enter the forwarding agent as the payer in order entry and this ensures that the
forwarding agent is determined as a selection criterion for shipping.
Determining the forwarding agent from the payer can be set in Customizing for
partner determination. If, however, you want to use different determination of the
forwarding agent, e.g. via the sold-to party, then you need to create a new partner
type as forwarding agent for cash on delivery.
152
Cash on Delivery
Standard conditions for pricing
NAPG: Package fee (absolute amount; weight scale, group condition)
The forwarding agent demands this from the goods vendor and reimburses it
upon payment by the customer.
NANG : Cash on delivery fee ( absolute amount; weight scale, group condition)
The forwarding agent demands this from the goods vendor and reimburses it
upon payment by the customer.
NAUE : Bank transfer fee
The post office demands this from the customer upon payment.
Access Sequence:
Access sequence NANA for pricing with the payer in the access.
153
Cash on Delivery
Output
Invoice
Packaging slip
Payment slip
Process Flow
Order Entry
You trigger the cash on delivery transaction by entering the post office as the payer.
When you enter the order, the system then determines the same forwarding agent
from the selection criteria in shipping.
When you change the order, it is not possible to redetermine the forwarding agent
automatically. You must then enter the forwarding agent manually in addition to the
payer.
154
Retroactive Billing
Use
New pricing agreements that you make with your customer may affect billing documents that have already been processed and settled. If a new pricing agreement is effective before the pricing date of the billing documents, you can perform retroactive billing to call up a list of these documents and reevaluate them with the new price. You can then create additional billing documents to settle any differences.
Retroactive billing is a special billing function often used in scheduling agreement processing.
With the retroactive billing function, you can:
• Call up a list of documents affected by price changes
• Trigger the system to create the necessary retroactive billing documents directly from the list
• Create credit or debit memos directly
• Review any errors in a log
• Simulate the retroactive billing process for any document
155
How does Retroactive Billing Work?
The following graphic shows a simple example of retroactive billing.
156
How does Retroactive Billing Work?
In this example, the system calculates the difference between the net value of the
invoice ($100) and today‟s net value based on the new price ($90). It then creates
a credit memo with the net value of $10 to be credited to the customer.
Primary and Secondary Documents
The system calculates retroactive billing values for primary documents. It can use
secondary documents to help calculate this value.
Invoices are always primary documents.
Other billing documents, such as debit or credit memos can be primary or
secondary documents. This depends on the order reason entered in the billing
document.
157
How does Retroactive Billing Work?
Primary Documents
Primary documents are :
• Invoices
• Credit memos that refer to returns
• Credit and debit memos in which you have entered the relevant order reason.
You can also assign an order reason to a memo request which then passes it along
to the referenced credit or debit memo.
Secondary documents
Secondary documents are the following documents in which you have entered the
relevant order reason:
• Credit and debit memo requests
• Credit and debit memos
158
How does Retroactive Billing Work?
The system displays such a document only when it has been created with
reference to the invoice and when the currencies in both documents match.
If you create a credit or debit memo (or memo request) without reference to an
invoice, you will not be able to see in the retroactive billing list if the invoice has
already been billed retroactively.
When you create a credit or debit memo request which is relevant for retroactive
billing as a secondary document, the system will use it to calculate retroactive
billing for the referenced document.
The system does not take into account whether or not a request has been rejected,
partially billed or billed using another pricing procedure. Also, it does not take into
account any changes in the payer, sold-to party, sales organization, billing date or
material.
159
Order Reason in Retroactive Billing
Credit and debit memos and memo requests are not included in the retroactive
billing list. However, you may find it necessary in some cases to designate these
documents as relevant for retroactive billing. You do this by entering the relevant
order reason in the billing document.
Examples of order reasons include price changes, poor quality or ruined material.
Depending on how the order reason you entered is customized, the billing
document becomes relevant for retroactive billing.
160
Prerequisites
To make the credit and debit memos and memo requests relevant for retroactive
billing, you need to assign a order type to the order reason as follows:
• For primary documents, assign type 2
• For secondary documents, assign type 1
• For documents which are not relevant for retroactive billing, do not assign a type
You assign types to order reasons in Customizing for Sales and Distribution
• Sales Sales Documents Sales Document Header Define Order
Reasons
161
Define Order Reasons
162
Features
When you enter an order reason which has been assigned a type in Customizing,
the billing document becomes relevant for retroactive billing as follows:
Primary Document ( order reason is assigned type 2)
• If you enter an order reason with type 2 in a credit or debit memo request, the
system will use this billing document in retroactive billing as a primary document.
• The system will then calculate the retroactive billing amount for this billing
document just as for a standard invoice.
• “Poor quality” would be a typical order reason for this type, for example.
163
Example 1
164
Example 1
In this example, the customer was sent an invoice with a net value of $100. Because 3 pieces were of poor quality, the customer received a credit of $30.
The credit memo (no. 601) would normally not be included in the retroactive billing list. However, the order reason poor quality has been assigned type 2 in customizing, which means that the credit memo is a primary document relevant for retroactive billing. Therefore, the system calculates the difference between the net value ($30) and today‟s net value ($27) and creates a debit memo of $3 on the basis of the credit memo no. 601
Invoices are always primary documents. Therefore the system also calculates the difference between the net value of the invoice ($100) and the today‟s net value ($90) and creates credit memo no.2 602 ($10) on the basis of the invoice.
The credit and debit memos created by the system both have the order reason price too high, which has been assigned type 1 in customizing. Should there be a subsequent retroactive billing run, these billing documents will be relevant for retroactive billing as secondary documents.
165
Example 2
166
Example 2
If you enter an order reason with type 1 in a credit or debit memo or memo request,
the system will use this billing document in retroactive billing as a secondary
document.
“Price difference : price was too high” would be a typical order reason for this type,
for example.
This example continues the process of the previous example.
The credit and debit memos created by the system both have the order reason
price too high, which has been assigned type 1 in customizing. Therefore, they in
turn, become relevant for retroactive billing, but as secondary documents.
As in the first example, the system calculates the difference between the net value
of the invoice ($100) and today‟s net value ($85). It then takes this difference ($15)
and subtracts the net value of the secondary document, credit memo 602 ($10)
and creates credit memo no. 604 ($5) on the basis of the invoice.
167
Example 2
The system carries out the same procedure for credit memo no. 601. It calculates
the difference between the net value of the credit memo ($30) and today‟s net
value ($25.50). It then takes this difference ($4.50) subtracts the net value of the
secondary document, debit memo no. 603 ($3) and creates debit memo no. 605
($1.50) on the basis of credit memo no. 601.
Documents with other order reasons
• Although the system does not take documents with other order reasons into
account, it displays them in the list in another colour.
168
Retroactive Billing List
List containing billing documents relevant for retroactive billing.
• Documents with open values to be processed for price changes
• Documents that refer to these billing documents
• Documents that have already been created and processed for price adjustments.
The retroactive billing list consists of a header and a list.
The Header includes information such as :
• Payer
• Sales Organization
• Currency
• Ordering Party
169
Retroactive Billing List
The list consists of two parts:
Actual net value of the invoice (highlighted) i.e. the value that would be determined
for the item if you were to reevaluate the billing document.
A list of
• Billing document items with the original item value i.e. the value that has already
been billed.
• If retroactive billing has already taken place, billing document items created by
the retroactive billing with retroactive billing value i.e. the difference between the
actual and item values, plus/minus values from the relevant credit and debit
memos or memo requests in the list.
• Related document items that are not relevant to retroactive billing for information
purposes
Invoices, debit memos and debit memo requests are shown as positive values.
Credit memos and credit memo requests are shown as negative values,
indicated by a negative sign (-)
170
Retroactive Billing List
The system calculates a separate subtotal for each combination of currency, sold-
to party and material.
Note that you cannot directly reject primary documents or set them to complete in
order to remove them from the list. As a workaround, you can create a credit or
debit memo request with reference to the invoice for the retroactive billing
document. Then reject this document. The primary document will still appear in
the list but with an amount of zero. The system displays reasons for rejection in
the retroactive billing list.
The following billing documents or items do not appear in the retroactive billing list.
• Cancelled invoices or items
• Cancellation documents
• Proforma invoices
171
Retroactive Billing List
The following points should be noted:
• The system lists credit or debit memo requests with reference to invoices, instead
of credit or debit memos with reference to requests. If this were not the case, the
system would continue processing retroactive billing documents for the invoice
until the requests were actually billed.
• If you create a credit or debit memo (or memo request) without reference to an
invoice, you will not be able to see in the retroactive billing list if the invoice has
already been billed retroactively.
172
Processing Retroactive Billing Lists
The system does not automatically trigger the creation of a retroactive billing list
when you create, change or delete condition records. You must create the list
manually.
In retroactive billing, the system creates debit and credit memos with reference to
invoices only.
For consistent data in the retroactive billing list:
• Create credit and debit memos and memo requests with the same payer, sold-to
party, material and sales organization as the referenced invoice.
• Create credit and debit memo requests with the same currency as the referenced
invoice.
• Be aware that even though you create an overall pricing type for the list, the
system may include billing documents with a different pricing type. The pricing
type you enter for the list may also be different from the pricing type determined
for the credit and debit memos created by the system. Ideally, these two pricing
types should be the same.
173
Processing Retroactive Billing Lists
Make sure that you carefully maintain order reasons in customizing, in sales
documents, and in credit and debit memos for retroactive billing.
Make sure that the condition type PDIF is defined in the pricing procedure which is
used when creating credit or debit memos. The system will always post the
difference with the condition type PDIF.
While you are processing the list, the system blocks it for the client, payer and
sales organization. The system allows other users to call up the list for display, and
even simulate retroactive billing. However, when they try to perform retroactive
billing the system informs them that the list is being processed. To perform
retroactive billing, a user who is already in the list to display or simulate can exit,
and call the list up again, or simply choose Refresh.
174
Procedure for Retroactive Billing
In Billing choose Billing Document Retro-billing
Enter a payer, a sales organization, to and from dates, and pricing type B or C.
The system automatically proposes pricing type C. Besides these entries, you can
also enter a currency, sold-to party, or material to narrow your search.
Choose Enter
• The system creates a list, displaying documents and subtotals for each
combination of currency, sold-to party and material.
If you are working with this function for the first time you must set the billing types
for credit and debit memos and the order reasons for these documents.
Choose Settings Change, enter your data, and choose Save. Although the
system will propose these settings as default in future documents, you can change
them at any time.
175
Procedure for Retroactive Billing
Enter Payer
Enter sales organization
176
Procedure for Retroactive Billing
Select the document or documents that you want to bill retroactively and choose
Retro-billing.
Only items with open quantities can be selected. If you cannot select an item, this
means that it has already been processed.
To simulate the retroactive billing function, choose Simulate.
177
Result
The retroactive billing documents that you have selected are divided into two groups.
• Items that require credit memos
• Items that require debit memos
The system processes these groups separately, creating the necessary credit and debit memos for the retroactive billing document.
You can only work with the full retroactive billing amount. It is not possible to process partial amounts.
The system does not carry out a tolerance check on the net value. Also, it does not take into account different value added tax (VAT) amounts for one item. All conditions other than the retroactive billing amount are determined automatically.
The system doe not update the list automatically.
Choose Refresh to update the list. Processing large quantities of documents for retroactive billing may negatively affect system performance. Newly created documents may not be available immediately.
178
Result
The system splits credit and debit memos when:
• There are differences in the plus / minus signs of the items.
• The system creates credit and debit memos with positive amounts.
• The sales areas in the referenced invoices are different.
• The currencies in the referenced invoices are different.
• The sold-to parties in the referenced invoices are different.
• Review any errors that occur by choosing Log.
179
Billing Plan
Purpose
A billing plan is a schedule of individual billing dates for a single item in a sales
document. You can define a billing plan at header level, which is then valid for all
items assigned to it.
Depending on the kind of business process you are carrying out, the system can
automatically propose one of two different types of billing plan: periodic billing or
milestone billing.
180
Billing Plan
Periodic billing means billing a total amount for each individual billing date in the
plan. For example, if you are creating a rental contract, the system can propose a
schedule of monthly rental payments, according to the length and conditions of the
contract.
Milestone billing means distributing the total amount to be billed over multiple billing
dates in the billing plan. For example, you can use a billing plan for billing a make-
to-order item that is assigned to a project in the SAP Project System. When you
enter the project related make-to-order item in the sales order (or assembly order),
the system proposes a billing plan based on milestones defined for networks in the
project. As each milestone is successfully reached, the customer is billed either a
percentage of the project cost or simply a pre-defined amount.
181
Billing Plan
During sales order processing, the system determines from the item category
whether a billing plan is required and, if so which type of plan. The type of billing
plan that is determined at this point is set up in customizing and cannot be changed
in the sales document.
Billing plans for rental contracts and billing plans for project-related milestone billing
have different overview screens so that you can enter data relevant to your
processing. For example, for milestone billing, you must be able to enter data to
identify the individual milestones.
182
Billing Plan Functions
Billing plan processing includes the following functions:
• Automatic creation of billing plan dates
• Pricing
• Billing block
• Billing index
• Billing status
• Billing rule for milestone billing
• Fixed dates in milestone billing
• Document flow
• Creating with reference
• Exchange rate determination
183
Billing Plan Functions
Automatic creation of billing plan dates
In customizing for sales, you control how the system automatically creates the
schedule of dates in a billing plan. The system determines the schedule of
individual dates based on general date information, such as the start and end
dates. This general date information is copied either from contract header data or
from proposals in the billing plan type.
184
Billing Plan Functions
Pricing
Sales document items are billed as each billing date in the plan becomes due. The
system determines the amount to be billed either from the condition records that
are applicable to the item or from the values that are explicitly entered in the billing
plan for a particular billing date. In milestone billing, for example, you can specify a
percentage to be billed or an actual amount.
Billing block
A billing block can be set for each date in a billing plan. The block prevents
processing for a particular billing date but does not necessarily affect any of the
other dates in the plan. In milestone billing, the system automatically sets a billing
block for each date. This block remains in effect until the project system reports
back that the milestone in the corresponding network has been successfully
completed. At this point the system removes the block.
185
Billing Plan Functions
Billing Index
For every billing date in a plan, the system creates and updates a billing index. If a
billing date is blocked for billing, the system copies this information into the index.
Billing Status
The system assigns a billing status to each billing date in the plan. The status
indicates to what extent the billing has been processed for that particular date. After
billing has been carried out successfully, the billing status is automatically set to C.
This prevents a billed date from being billed again.
186
Billing Plan Functions
Billing rule for milestone billing
For every date in the milestone billing plan, you can specify a billing rule. The rule
determines how the billing amount for the particular date is calculated. For
example, you can specify whether the billing amount is a percentage of the total
amount or whether it is a fixed amount. The following figure shows an example of
how a billing value can be determined.
187
Billing Plan Functions
In addition, you can specify that the amount to be billed is a final settlement that
takes into account billing that has not yet been processed. For example, price
changes may take place after billing dates in the plan have already been
processed. The price differences can be taken into account during final settlement.
Final processing is not automatically proposed in the billing plan by the system; you
must enter it manually during processing.
Fixed dates in milestone billing
• You can control for each date in a billing plan, whether the date is fixed or
whether the system copies the date from the planned or actual milestone dates in
a project.
188
Billing Plan Functions
Document Flow
After a particular date in a billing plan is processed for billing, the system updates
the document flow for the corresponding sales document item. The following figure
shows an example of document flow for a billing plan.
189
Billing Plan Functions
The document flow for the sales document displays the following data:
• Creation date
• Billing date
• Billed value
Creating with reference
When you define a billing plan type in customizing for sales, you can enter the
number of an existing billing plan to serve as a reference during subsequent billing
plan creation. During sales order processing for items that require billing plans, the
system automatically proposes the reference plan and, if necessary, re-determines
the billing dates (based on the current date rules) for inclusion in the new billing
plan.
190
Billing Plan Functions
Exchange rate determination
In the billing plan with partial billing, you can store a certain exchange rate for each
date. The amount billed is the amount determined after using this exchange rate to
convert from the local currency into the document currency.
An exchange rate can also be stored at item level for the sales document (field:
Exchange rate for FI on the billing tab page). This fixed rate is valid for all dates in
the item billing plan for which no rate is specified in the billing plan. If an exchange
rate is entered both for the date in the billing plan and at item level in the exchange
rate field, then the system uses the rate specified for the date during billing.
If no exchange rate is entered for the date or at item level, then the system uses
the exchange rate used for invoice creation and it is forwarded to FI.
191
Billing Plan Functions
When using a header billing plan, all billing plans linked to this header billing plan
are automatically updated. If, for example, you enter an exchange rate for the first
date in the header billing plan, this is automatically copied to the corresponding
dates for the item billing plans.
192
How Billing Plans are Controlled
Billing plans are controlled in customizing for sales by the following elements:
• Billing Plan Type
• Date Description
• Date Category
• Proposed Date Category
• Proposed Date
• Assigning billing plan types to sales document items
193
How Billing Plans are Controlled
Billing Plan Type
The billing plan type defines the basic control data for the billing plan. For example,
the billing plan contains rules for date determination. These rules determine, for
example, the beginning and end dates for the schedule of billing dates. The billing
plan type also contains a date rule for determining the horizon for the billing plan.
The horizon calculates the last billing date in the billing plan, based on the current
date plus a specified time period( for example, today‟s date plus one year).
The billing plan type is displayed in the sales document but cannot be changed.
194
How Billing Plans are Controlled
Date Description
Date descriptions are defined to describe the various purposes for which billing
plans can be used. Depending on the date category you use, the system proposes
a date description for the billing dates in the billing plan. The descriptions are for
information purposes only and do not affect processing.
195
How Billing Plans are Controlled
Date Category
The date category defines data for each billing date that appears in the billing plan.
For example, the date category determines the following data:
Billing rule (determines whether the billing date is based on, for example, the
percentage of project completion or a monthly periodic payment for a service
contract, and so on).
Date description (specifies, for example, whether the billing date is for a rental
contract, maintenance contract and so on)
Billing block ( the billing date may be blocked, for example, if a project milestone
has not been confirmed).
Whether the date is fixed or not (in milestone, you may want the system to use the
actual date of the milestone, for example).
Billing type (proposes the type of billing document to be used during billing: invoice,
pro forma and so on).
196
How Billing Plans are Controlled
Proposed Date Category
For every billing plan type, you can assign a date category. During sales
processing, the system then automatically proposes the date category and its
corresponding data for each billing date in the plan.
The date category “Final settlement” is not proposed as part of the standard SAP
R/3 system and must be entered manually during processing.
Proposed Date
The date proposal function is used only for milestone billing. This function enables
you to create a standard billing plan as a reference. This reference can be used
during order processing. The dates can be used as the basis for an actual billing
plan and changed if required.
197
How Billing Plans are Controlled
Assigning Billing Plan Types to Sales Document Items
Billing plan types are controlled by item category. In customizing for sales, you can
specify that individual item categories are relevant for order-related billing by
means of a billing plan. You can also specify a billing plan type for each item
category.
198
Periodic Billing
Periodic billing can be used, for example, in rental contracts. The billing dates in a
periodic billing plan can be determined from the following sources:
• Control data in the billing plan
• Header data in the rental contract
• Manually entered dates
The following example shows an example of periodic billing.
The following dates are important for billing date determination:
• Start and end dates
• Period (monthly, quarterly, annually)
• Horizon
199
Periodic Billing
200
Periodic Billing
Start and end dates
Start and end dates define the duration of the billing plan and, whenever possible,
are copied from the start and end dates of the corresponding rental contract.
Depending on the configuration of your system, these dates may be indirectly
determined by the system. For example, the contract start date may be
determined automatically as soon as the installation date is entered.
Period (monthly, quarterly, annually)
The periodicity of the billing dates determines the frequency with which the billing
dates are created in the billing plan and, in addition, whether a billing date is
processed for billing on the first or last day of the month.
201
You use this field to activate
automatic creation of credit memo
dates in the billing plan
202
Periodic Billing
Horizon
In case no end date is entered, or the end date lies so far in the future that not all
billing dates can be established, then a rule for determining the horizon can be
entered. The horizon for periodic billing determines the last date of the billing plan.
The horizon is always determined by a rule that uses the current date as a
baseline. If the current date is updated during processing, the system automatically
extends the horizon and the schedule of billing dates into the future.
The determination of dates according to the current horizon must be triggered
manually via the following menu path.
• 1. Select Logistics Sales and Distribution Sales
• 2. Choose Outline agreement Contract Subsequent functions Horizontal
periodic billing
• Report RVFPLAN01 which supports this function can be scheduled to run at
regular intervals.
203
Credit Memo Date in the Billing Plan
Use
After cancellation of a contract, depending upon your agreement with the customer,
settlement periods that have already been billed can be re-credited automatically.
The most important criterion is that if the end date or „to-date‟ is changed, it comes
before the last billed date. It is unimportant whether the end date changed
because of a rule (e.g. contract end date) or whether it was entered manually.
Correction dates are created automatically if the field Corr is activated in the
document billing plan data. Activation of the field can be carried out manually or
automatically via customizing.
Deactivating the field removes the correction dates again.
204
Credit Memo Date in the Billing Plan
Example
The contract had a duration of four months and all dates were billed. After further
negotiations with the customer, the contract was cancelled on April 15 1998 and it
was agreed that the amount for the remaining period would be credited to the
customer.
As soon as the end date is changed, a corresponding correction date is set.
205
Credit Memo Date in the Billing Plan
206
Credit Memo Date in the Billing Plan
The value of a correction date cannot be changed. If you only want to reimburse a
certain amount to the customer, then you can only do this by fixing the end date.
Correction dates which have already been billed can no longer be changed.
The billing dates to which the correction dates refer cannot be cancelled.
207
Credit Memo Date in the Billing Plan
Prerequisites
You need to make the following settings in Customizing for billing plans:
Billing plan type for periodic billing
In the „Aut.cor.date‟ field, you activate the automatic creation of credit memo dates
in the billing plan.
Date category maintenance
In the billing type field, you maintain the proposal billing type for the credit memo
date in the billing plan.
In the billing block field you maintain a block indicator for credit memo in the billing
plan.
All fields represent a proposal for the billing plan and can be overwritten in the
billing plan.
You can configure authorizations for changing the billing block in the document
(activating and deactivating )using authorization object V_VBAK_AAT
208
Milestone Billing
Milestone billing is typically used for billing projects, such as plant engineering and
construction projects. Such projects include a series of milestones that mark the
completion of different stages of the work. In the SAP R/3 system, milestones are
defined in a network along with planned and actual dates for the completion of
work. The milestones are also assigned to the billing dates in the billing plan. Each
milestone-related billing date is blocked for processing until the Project System
confirms that the milestone is completed.
Delivery relevant order items for which a milestone billing applies are billed on the
basis of the requested delivery quantity and not on the total of the confirmed
quantities.
The following figure shows an example of milestone billing.
209
Milestone Billing
210
Milestone Billing
For each billing date in a milestone billing plan, you can specify whether the billing
date is :
• Fixed
• Always updated with the actual date of the milestone
• Updated with the actual date of the milestone, if the date is earlier than the
planned billing date for the date.
It is also possible to assign milestones to the dates of the billing plan during
milestone billing if no network plan has been opened.
In order to do this you must assign the milestone manually in billing plan
maintenance. To make this assignment, the Fixed date field of the proposed date
category of the billing plan type must not be blank. The additional fixed value of
Fixed date means that you cannot assign it to a milestone. Milestone assignment
is possible for all other values.
211
Milestone Billing
Integration between Sales and the Project System
The connection between the project and the sale document item is made in the
individual schedule lines of the item. Each schedule line can be assigned to a
network in a project.
To display the project-related data for a schedule line, proceed as follows:
• 1. In one of the overview screens of the sales document, select Item
Schedule lines
• 2. Mark the schedule line and select Procurement details.
212
Billing Plans at Header Level
You can define a billing plan at header level which is valid for all items assigned to
it. Data copied to the assigned items cannot be changed in the items.
213
Functions in Header Billing Plans
Automatically attaching item billing plans to the header billing plan
All items with the same billing plan type (controlled by the item category) refer to
the header billing plan. By marking the header billing plan on the item billing plan
screen, you can display the relevant item/ header billing plan assignment. If you
want to define billing plans for specific items, you can remove the assignment and
maintain the item billing plan separately.
You can remove or set an assignment with the assignment indicator. Once an item
has been partially billed, it can be removed from the header but no longer attached
to it.
Copying the header billing plan to item billing plans
You can copy global changes made at header level to item billing plans assigned to
that header. Dates which have already been billed cannot be changed. In periodic
billing, the system carries out pricing, determines billing document value and
determines document status at item level irrespective of the header.
214
Functions in Header Billing Plans
Dynamically determining totals and status at header level
Information displayed in the header billing plan is valid for all items which refer to
that header. In milestone billing, billing document value and status at header level
are determined dynamically from all assigned items. The document value at header
level is the sum of all assigned items.
215
Displays
In the sales order, you can branch to the header billing plan with Header
Contract Billing Plan
The header billing document field in the item billing plan (Item Contract Billing
plan ) indicates whether it has been assigned to a header billing plan.
There are two new fields in the Billing overview screen (Overview Billing)
The Billing relevance field indicates for each item whether the sales order is
relevant for an order related billing document and whether a billing plan exists (
billing relevance „I‟)
The Header billing plan field indicates whether the billing plan refers to the header
billing plan (Header Bill Plan “X”)
216
Header Billing Plans in Milestone Billing
The system copies the basis for the header billing plan from customizing. In
milestone billing, the following functions are carried out at item level:
Determining billing document value on a percentage basis.
Dates at header level are copied from all item billing plans assigned to that header.
When you make changes at header level (e.g. new billing dates or changes to
percentage rates), the related items are automatically changed accordingly. The
system does not allow you to make changes at item level.
Handling milestones
Dates generated in the header billing plan and milestones set in the header billing
plan (Edit Generate dates Manual milestones) are copied to the item billing
plans assigned to that header.
If you want to schedule milestones in an item separately from the header, you must
first remove the item from the header billing plan before milestones can be
assigned to it.
All manually set milestones will be deleted when you reassign this item to the
header billing plan. Header data will once again be valid for the item.
217
Header Billing Plans in Periodic Billing
In periodic billing, the following functions are carried out exclusively at item level:
• Pricing
• Determining status
• Determining date-from and date-to
For this reason, no billing document value or status appear in the header billing
plan.
Changes to validity period
Start and end dates establish the billing validity period and can be determined
automatically using a rule or entered manually. These dates are copied to the item
billing plans. If you change the rule or the manual validity period at header level,
the resulting dates will be copied to the item level.
218
Header Billing Plans in Periodic Billing
To maintain different dates at item level, proceed as follows:
• If you specify a validity period manually in the Date-from and Date-to fields in the
item billing plan, the system deletes the rule and uses the manual dates from
these two fields to determine the relevant billing dates. The dates which the
system determines at item level remain valid even if you make changes to the
header billing dates. If the manual dates from the Date-from and Date-to fields
are deleted, the system will again use the rule in the billing header to determine
billing dates.
219
Customizing for Billing Plan
The following are to be done in customizing:
IMG Sales and Distribution Billing Billing Plan
Define Billing Plan Types
Define Date Descriptions
Define and Assign Date Categories
Maintain Date Proposals for Billing Plan Types
Assign Billing Plan Types to Sales Document Types
Assign Billing Plan Types to Item Categories
Define Rules for Determining Dates
220
Define Billing Plan Types - Periodic Billing
The field In
advance is to be set
if the billing is to be
done in advance
e.g advance rental
Horizon specifies the last date for
periodic billing, up to which dates
should be set. It is always
determined from a rule which can
be entered in the billing plan type.
This field determines whether the
billing dates are automatically
determined or whether they
must be entered manually.
221
Define Billing Plan Types – Milestone Billing
Rule for origin of start date
of billing plan
222
Define Date Description
223
Define Date Descriptions
In this step, you define date descriptions. These are the textual descriptions for the
respective billing dates in the billing plan. The descriptions are used only for
differentiating between the billing dates and have no controlling function.
The date descriptions are entered for the date categories and are then found with
the billing plan dates in the order document and printed.
Example
In the billing plan, the distinction is made for example between billing dates for rent
or maintenance.
Actions
1. Enter an alphanumeric key with a maximum of 4 digits together with a language
ID and textual description for the date description that you want to create.
2. Enter the date description for the date categories for which you want to use the
description.
224
Define and Assign Date Categories
225
Define and Assign Date Categories
226
Assign Date Category Proposal for Billing Plan
227
Define and Assign Date Categories
In this step, you can assign one or more date categories to each billing plan type or
create new date categories.
The date category controls at billing date level,
• Whether the billing date is a fixed date,
• Whether and, if necessary which billing block the billing date has,
• With which billing type the billing date is to be billed,
The billing rule which specifies how the value to be billed for a date is to be
determined. Billing rule 2 of the standard system (Value based milestone billing)
specifies, for example, that the entire invoice value is distributed between the dates
and a part of the total value is billed for each date.
The date category also specifies the description for the billing date.
Since, you can have several date categories for a billing plan type, you must
specify, in a further step, a default date category for each billing plan type.
228
Maintain Date Proposals for Billing Plan Types
229
Maintain Date Proposals for Billing Plan Types
230
Maintain Date Proposals for Billing Plan Types
The date proposal specifies a sequence of dates which can be used during order
processing as a reference for date determination. The date proposal is only
relevant for the billing plan type Milestone billing (periodic billing = blank)
When you create a billing plan with milestone billing, the dates are copied
according to the reference, re-determined on the basis of the current rules, and
placed in the billing plan.
To maintain the date proposal for milestone billing, go to the detail screen of the
date proposal and select the function „Maintain date‟.
231
Assign Billing Plan Types to Sales Document Types
232
Assign Billing Plan Types to Item Categories
233
Assign Billing Plan Types to Item Categories
In this IMG activity, you assign a billing plan type and billing relevance „I‟ (relevant
for order-related billing / billing plan ) to the item categories for which you want to
create a billing plan. This assignment is necessary for creating a billing plan for the
relevant order items.
In the standard system, item category MVN is configured for periodic billing and
item category TAO is configured for milestone billing.
234
Define Rules for Determining Dates
235
Define Rules for Determining Dates
Enter a calendar ID in this field to
influence the date calculated by
the system during indirect date
determination
236
Define Rules for Determining Dates
A baseline date (for example, current date, beginning of contract) forms the basis
of every date determination rule. A period to be defined is added to this baseline
date.
You define the rules for date determination on the basis of the following dates:
• The possible baseline date is predefined by a fixed value range (for example,
current date, beginning of the contract) and cannot be changed.
• You can define the period in any way by specifying a number with a
corresponding time unit.
• If you use a calendar ID to define a rule, the system determines the next possible
workday starting from the baseline date. If you use a calendar ID, you may not
specify a period.