Self-Billing

PDF download from SAP Help Portal:

http://help.sap.com/saphelp_erp60_sp/helpdata/en/3c/dac353b677b44ce10000000a174cb4/content.htm
Created on April 14, 2015

The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.

Table of content

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 1 of 22

Table of content
1 Self-Billing
1.1 Self-Billing Complete Process
1.1.1 Procedure for Inbound Processing
1.1.1.1 Self-Billing Monitor
1.1.1.2 Processing Inbound Self-Billing Documents
1.1.1.2.1 Verification Step
1.1.1.2.2 Processing Step
1.1.1.2.2.1 Starting the Processing Step
1.1.1.2.3 Tolerance Limit for Value Differences
1.1.1.3 Automatic Posting in Case of Differences
1.1.1.3.1 Automatic Posting Settings in General Parameters
1.1.1.3.1.1 Setting the Order Reasons
1.1.1.3.2 Condition Types for Automatic Postings
1.1.1.3.3 Customizing Checklist for Automatic Postings
1.1.1.3.4 Optional Default Customizing Settings
1.1.1.3.5 Differentiation of Value-Only and Value/Quantity Differences
1.1.1.3.5.1 Example of Differentiation of Difference Type
1.2 EDI Settings for the SD Self-Billing Procedure
1.2.1 Setting Up the EDI Partner
1.2.2 Determination of EDI Sold-To Party
1.2.2.1 EDI-Relevant Settings for the Vendor
1.2.2.2 EDI-Relevant Settings for the Partner
1.2.2.3 EDI-Relevant Settings for the Unloading Point
1.2.3 Making the Settings for Mapping in the EDI Subsystem
1.2.3.1 Table of Settings for Mapping in EDI Subsystem
1.2.3.2 Monetary Values in SD Self-Billing
1.2.3.3 The +/- Sign in SD Self-Billing
1.2.4 Processing for Self-Billing or Retro-Billing
1.2.4.1 Table of ACTION Codes to Control Self-Billing/Retro-Billing
1.2.5 Number of Deliveries (IDocs) per Transmission Number
1.2.6 Transmitted Conditions, Reference Numbers and Date Information

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 2 of 22

1 Self-Billing
Purpose
The SD self-billing procedure allows the customer to send self-billing documents to the vendor, stating the deliveries and amounts that are settled and paid.
Self-billing documents are usually transmitted electronically per EDI. The receiving system, that is, the vendor system, then compares the self-billing documents
with the deliveries and their receivables. If the transmitted values do not match those in the vendor's internal invoice, the system automatically creates a clearing
document, that is, a further SD invoice (credit or debit advice) that clears the difference between the values. If the value of such a clearing posting exceeds a
specific tolerance limit, the system can create a new open item for the difference amount.

Integration
The self-billing procedure is an integral part of processes between customer and vendor. The OEM generally sends the self-billing document after receiving the
goods, that is, after posting goods receipt. The amounts contained are based on already agreed conditions.
The following diagram shows the process flow and the integration of self-billing in the logistical chain:
( )

Features
You can use this function to process both normal self-billing documents and retroactive price change.
You can work with various delivery procedures:
standard deliveries
deliveries with external delivery note number (for example, external service agent)
deliveries that refer to an external order number (ESA, MAIS Pick Up Sheet, delivery order)
JIT deliveries with invoice for day's collective delivery note.
The system processes and evaluates self-billing documents, always keeping the reference to the original transmission (transmission-oriented processing).
The system compares the amounts transmitted with those in the internal invoice.
The system automatically posts value differences with reference to the internal invoice, thus assigning the document flow to the original transaction.
In case of differences, you can set the system to aditionally create new open items, according to percentage or absolute tolerance limits at delivery or at
item level.
You can analyze transmissions in the reporting tool.

Self-Billing Complete Process

Purpose
The following puts the self-billing procedure in context as part of the process flow between customer and vendor. It provides an overview of the uses of this function
and the system settings required.

Note
The settings detailed here refer to an SD coupling between 2 clients or 2 SAP systems.

Prerequisites
Vendor (SD)
You have created a material with the corresponding views (for example, Sales and Distribution).
You have created the customer master in your system.
You have created an SD scheduling agreement or order for this customer for the appropriate material, and entered the customer material and the partner
description in this scheduling agreement or order.
You have created an SD delivery and an initial billing document.
You have fulfilled the prerequisites for receiving self-billing documents per EDI. See also Self-Billing Procedure With EDI .
You have made the Customizing settings for the self-billing procedure. See also Processing Inbound Self-Billing Documents .
Customer (MM)
You have created a material with all relevant views.
You have created the vendor master in your system. In the vendor master, you have flagged the indicators GR-based inv. verif. and AutoEvalGRSetmt
Del.
You have created an MM scheduling agreement or a purchase order. Make sure that the indicators GR-based inv. verif. and AutoEvalGRSetmt Del. are
flagged in the purchasing document item. Your MM scheduling agreement must contain at least one schedule line, at least one of which is issued.
You have fulfilled the prerequisites for sending self-billing documents per EDI.

Process Flow
1. The vendor creates a delivery with reference to the SD scheduling agreement/order in his system.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 3 of 22

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

The vendor creates a delivery with reference to the SD scheduling agreement/order in his system.
The vendor posts goods issue of the delivery.
The vendor creates an initial billing document, which he does not send to the customer.
The customer receives the materials and creates a goods receipt with reference to the delivery note number in the MM module.
The customer creates a self-billing document for the goods received, using the MM ERS functions. Make sure that you use the document selection LI .
The customer transmits the self-billing document to the vendor "per EDI" (in this case: ALE). The document must include a number that the system can use
to directly or indirectly determine an SD document number (for example, the SD delivery.)
The vendor system reads and checks the transmission, which can contain several IDocs and therefore several deliveries.
The vendor initiates processing of the transmission, in which the open value from the internal invoice is compared with the value in the self-billing document.
If the values match, an external reference number is updated in the billing (FI) document.
If the values do not match, the system automatically posts all differences, debit or credit, depending on the +/- sign. It assigns a reference number to all
documents that are assigned to the delivery. The reference number is used later to post receipt of payment. If you have set a tolerance check, the system
creates no open items unless the tolerance levels are exceeded. If the tolerance levels are exceeded, the system creates new open items. However, these
are not assigned a reference number. Unless tolerance checking is set, the system creates new open items for every clearing entry. To set the system to
create no new open items, you must activate a tolerance group, in which the tolerance check is explicitly switched off (that is, the Check limits field is not
flagged.)

1.1.1 Procedure for Inbound Processing

Use
The following sections describe the functions and processes that are relevant for the vendor, and the settings that the vendor must make in Customizing and in the
application.

Integration
The vendor receives the self-billing document, then processes it in the verification step and the processing step. The vendor then deals with any differences that
occur between transmitted and recorded data.

Features
Process flow of verification step
Start and process flow of processing step
Tolerance limit for value differences
Prerequisites for EDI
Self-Billing Monitor
Settings and procedures in case of differences.

1.1.1.1 Self-Billing Monitor

Use
The Self-Billing Monitor allows you to display, evaluate and edit the transmissions received from your customer.

Features
You can find the Self-Billing Monitor under
the Self-Billing Monitor you can

Logistics

Sales and

Distribution

Billing

Billing

Document

Self-Billing Procedure (Automotive)

. In

Display transmissions by specific selection criteria. You can select lists of transmissions
that have to be started manually
that are waiting to be processed (for example, waiting until the time period during which processing is permitted)
for which processing is delayed (for example, because of an error situation in the system job management)
that are currently being processed
for which processing ended with errors
for which processing ended without errors
that contain deactivated transmissions (for example, because the transmissions were transmitted double)
For more details on each criteria, see the field help in the application.
Display transmissions at delivery and material level showing the transmitted data and the corresponding data in your SAP system (for example, transmitted
values vs. open values)
Start transmissions manually from the list
Display error messages from verification and processing steps, and edit errors in the list
Display the quantity and value differences and any new open items that result from processing
Deactivate specific data records (IDocs) in the list of deliveries that cannot be processed due to unrectifiable errors that occurred in the verification step
Set the processing indicator in the list of transmissions, for those transmissions that ended without errors.

Note
A transmission for which the processing indicator has been set is no longer displayed in the counter for the category Processing ended w/o errors the next
time you call up the Self-Billing Monitor.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 4 of 22

1.1.1.2 Processing Inbound Self-Billing Documents

Use
The customer transmits self-billing documents to the vendor via an EDI subsystem. The documents are read, assigned to an internal delivery and then processed.

Prerequisites
You have made the settings required for EDI processing. See also EDI Settings for the SD Self-Billing Procedure .
You have made the settings for the self-billing procedure in the Self-Billing Monitor (
Logistics
Sales and Distribution
Document Self-Billing Procedure (Automotive)
):
Under

Settings

Maintain General Parameters

Billing

Billing

, you have set the general parameters:

if required, the time delay for the transmission number (this is normally only used for test purposes, where the external transmission number is created from
the date)
if required, the permitted time period during which processing can be started (for example, only during the night, to maintain system performance)
the order reasons, document types and item categories for automatic postings or open items
Under

Settings

Maintain EDI Partner

, you have set the processing parameters for the EDI partner

assignment and verification of the external transmission number

how processing is started (manually, automatically, "closed")
How the transmission is ended (when target number of IDocs reached, or when processing started). See also: Starting the Processing Step .
Under

Settings

Maintain Tolerance Groups

, you have defined tolerance groups for creating new open items.

You can create a tolerance group with a blank key, so that this group is used as a default whenever the Tolerance group field is left blank in the sold-to party
parameters. In this way, a check is always carried out with the parameters you specified.
Under

Settings

Maintain Sold-To Party Parameters

,, you have set the processing parameters for the sold-to party

You have entered a tolerance group, if required.

If you do not enter a tolerance group, the system creates a new open item for every difference. If you enter a tolerance group with active tolerance limits, the
system only creates a new open item if the tolerance limit is exceeded.
If you have created a tolerance group with a blank key, this tolerance group is used if you do not enter another one. This tolerance group becomes the default
tolerance group, and a tolerance check is always carried out. SAP recommends that you use this procedure.
( ) If you set "Don't check" for all fields in a tolerance group, no open items are created.
You have specified which number(s) are transmitted in order to determine a sales document, to which to assign the transmission.
If you select several options for this "number for sales document determination", the system searches for one after the other. The search terminates when a
corresponding document is found. Make sure that at least one option is specified.
You have specified which number serves as the main reference number for posting. This number is then the assignment number for the item in FI.
Under

Settings

Set Tolerance Check

, you have entered tolerance limits for your tolerance groups and activated the limits by choosing Check limits .

( ) If you do not want the system to create any open items automatically, create a tolerance group in which all checks are deactivated. The system will never
create new open items where this tolerance group is used.

Features
Inbound transmissions must initially be split into individual IDocs by the EDI subsystem , each IDoc representing a delivery. These IDocs are transferred to the
SAP system to be processed further:
Verification step
Receipt of the first IDoc triggers creation of a transmission in the SAP system. All subsequent IDocs are added to this transmission, until a specific target quantity
of IDocs is reached, or the transmission is closed (see also Starting the Processing Step ). In this way, the separate IDocs of the self-billing document are
grouped together again in the vendor's SAP system.
The system then checks the data received, by assigning the number transmitted by the customer to a sales document (delivery or delivery confirmation) in the
SAP system. The verification step comprises of this reading and assignment of data.
Processing step
In this second step, the system compares the quantity and value transmitted for the delivery to the quantity and value contained in the internal invoice in the SAP
system. For differences in value, the system automatically creates clearing entries. You can use the tolerance limit to set the system only to create new open
items from a certain difference amount upwards. If a new open item is created, its value is equal to the value of the clearing entry.

1.1.1.2.1 Verification Step

Use
In the verification step, the system reads the customer transmission, verifies the data and uses it to determine the corresponding data in the SAP system.

Integration

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 5 of 22

Data that has been read and set as without errors in the verification step is ready to proceed to the processing step. There, the system compares the quantities
and values in the self-billing document with the quantities and values in the current billing document. The system always updates the reference number in the
current SD and FI billing documents. In the case of value differences, the system automatically carries out clearing postings.

Features
The system reads the individual IDocs received from the EDI subsystem. The first IDoc creates a transmission.
The system checks that all the mandatory fields are filled in the IDoc. Mandatory fields are fields such as quantity and value, plus the EDI partner, the
inbound parameters for the EDI partner and the number for delivery determination. See also EDI Settings for the SD Self-Billing Procedure .
The system assigns the number transmitted for delivery determination to a delivery in the SAP system.

Note
The number for delivery determination might be the delivery number from the supplier's own system, or any number with which the delivery can be uniquely
identified (for example, an ESA delivery number). You make these settings in the Self-Billing Monitor under
Settings
Maintain Sold-To Party Parameters
.
If the system finds no corresponding SAP delivery, the verification step reports an error in delivery determination.
If the system finds a corresponding SAP delivery, it assigns the material transmitted (the customer material number) to a material in this delivery.
The system determines the customer name in the SAP system.
The system determines the transaction currency (from the initial billing document for the delivery) in the SAP system.
The system determines how the processing step is started. The processing step can be started either automatically, or manually via the Self-Billing Monitor.
You make these settings in the Self-Billing Monitor under
Settings
Maintain EDI Partner
. See also: Starting the Processing Step .

Result
When the transmission is ended or the processing step is started, the next inbound IDoc automatically causes a new transmission for the EDI partner to be
created. This and any subsequent IDocs remain in the verification step until the transmission is again ended, or the processing step is started for the
transmission.
In the Self-Billing Monitor a counter indicates, whether errors have occurred during the verification step (such as no delivery being found in the SAP system, or a
similar assignment error). By double-clicking on this number, you can display the long text of the error message.

Note
If you double-click on the long text, the system will display detailed information on the cause of the problem and how to deal with it.
Either:
The cause of the error can be removed by editing the transmitted data. In this case, you select the error message, then choose Change data .
The error cannot be corrected by editing. In this case, you can deactivate the original data (the IDoc) in the list of deliveries, so that it is excluded from the
processing step.

1.1.1.2.2 Processing Step

Use
Following the verification step, the processing step compares the transmitted data and incoming self-billing documents with the internal invoices in the vendor
system.
The processing step can be started automatically or manually. This depends on your Customizing settings and is established already in the verification step. See
also: Starting the Processing Step .

Features
The system compares the quantity transmitted with the quantity in the delivery.
The system compares the value transmitted with the value in the billing item.
The system checks the tolerance limit. The user can define a tolerance limit either for the whole delivery or for specific items. If the variance of the values
exceeds the tolerance limit, the system creates a new open item directly from the clearing entry. For any variance that is lower than the tolerance limit, the
system simply makes a clearing entry. Automatic clearing entries and open items always have the same value, but opposite +/- signs (debit/credit.)
IDocs, to which the same delivery number can be assigned, are grouped together during processing, so that the internal invoice amount still matches the
transmitted amount. However, this is only the case if you set it in the Self-Billing Monitor under
Settings
Maintain Sold-To Party Parameters
by
flagging the Group deliveries indicator.
If the same material occurs several times in a delivery, they are always grouped in self-billing (both in value and quantity).

Result
After the verification step, the situation between the billing document and the automatic clearing entries on the one hand, and the transmitted data on the other
hand, is always balanced. All of the documents contain the reference number transmitted by the customer.
New open items never have a reference number. The system displays a row of question marks ( ?_?_? ) in the Reference number field, so that, when it is
displayed in the debitors item list in FI, the user can easily see that this is an automatically created open item from self-billing.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 6 of 22

1.1.1.2.2.1 Starting the Processing Step

Use
Processing of the transmission (that is, the matching process) can be started either manually or automatically.

Features
Manual start of processing
You start processing manually from the Self-Billing Monitor. You access the list of transmissions designated for manual processing, and select the
transmission that you want to process. You can only ever manually start processing for one transmission at time.
Automatic start of processing
You have various options for starting processing automatically:
Start automatically without checking for incorrect records (only the IDocs without verification step errors are processed)
Start automatically if all records correct
You can also specify what triggers the automatic start:
Automatic start when target number of IDocs reached
Here, the total number of IDocs included in the transmission must be transmitted by the EDI subsystem to SAP inbound processing. The system tracks the
number of IDocs transmitted and starts processing when the target number is reached. In this case, no delay time is required.
The EDI sub-system must set the target number of IDocs in the last IDoc to be created, in the segment/field E1EDS01/SUMME, with qualifier 028. See also EDISettings for the SD Self-Billing Procedure .
Automatic start when transmission is ended

Recommendation
Here, the IDoc transmission is ended by the automatic start of processing. The automatic start is triggered when the delay time has run out. Is it assumed that
all IDocs for a transmission have been received by the end of the delay time.
For example, if a transmission is created at 6pm and the delay time is 6 hours, then the first IDoc (the IDoc that created the transmission) schedules a job for
the verification step at 12am. That is, at 12am the transmission is ended and processing is started (change from status A to B). Once a transmission has
changed from status A to B, the next inbound IDoc creates a new transmission.
SAP recommends to only use the option with time delay if the option with the target number is technically not possible.
However, you can still specify a period of time during which processing is permitted for automatic and for manual processing. You do this in the Self-Billing
Monitor, under
Settings
Maintain General Parameters
. This enables you to plan processing for a time at which system performance is less critical (for
example, between 12am and 6am). If you do this, scheduled jobs are put to the next possible date/time.

Activities
1. If required, enter a permitted time period for start of processing under
Settings
Maintain General Parameters
.
2. Specify whether processing is manual or automatic under
Settings
Maintain EDI Partner
.
3. In case of automatic processing, set whether the start of processing ends the transmission, or whether the system starts processing when the target number
of IDocs is reached.
4. If you have set automatic processing and that the system starts processing when the target number of IDocs is reached, you must make the corresponding
settings in the EDI sub-system.
5.

( )
Check with the person responsible for the EDI subsystem if the IDoc counter data can be delivered. It suffices if the data is written into the last IDoc that the
subsystem sends to the SAP system.
6. If you have set automatic start of processing and that start of processing ends the transmission, you must also specify a delay time.
7. If you have set manual start of processing, go to the Self-Billing Monitor and access the list of transmissions for manual start, then select the transmissions
to be processed. Choose Start processing step . If you are currently within the permitted time period, the transmission is processed immediately in the
background. Otherwise, a time is planned for starting within the permitted time period.

Result
After processing, the processing status changes to either processed with errors (C) or processed without errors (D).
If errors occur during processing, this is indicated by an entry in the list of deliveries. A on a green background = OK, B or blank on a red background = error.
This gives you detailed information on the errors and, where appropriate, a solution suggestion.

Note
If any IDocs still show errors from the verification step at the start of the processing step, they are not put through the processing step.
This is indicated by a number greater than 0 in the NoErrors (number of errors) field and a 0 in the Pro (processing progress) field - zero here signifying that
the transmission has been through the verification step but not the processing step.

1.1.1.2.3 Tolerance Limit for Value Differences

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 7 of 22

1.1.1.2.3 Tolerance Limit for Value Differences

Use
You can use the tolerance level to set a percentage or absolute tolerated difference between the transmitted value and the open value. If the difference exceeds
the tolerance limit, a new open item is created. The system compares the value transmitted with the value that is still open in the internal invoice for the delivery.
You can set tolerance limits at delivery and/or item level (material.) If the tolerance limit is not violated, no new open item is created.
If you have not set a tolerance limit, or set up the system not to carry out a tolerance check, the system creates a new open item for every difference.

Features
Various tolerance groups can be defined and one can be assigned to the customer
Absolute and/or percentage values can be set in the tolerance group
Tolerance limits can be set at delivery and/or delivery item (material) level
Tolerance groups can be assigned per sold-to-party. For each sold-to party, you can define a separate tolerance group with separate tolerance limits
A new open item is posted if the tolerance limit is exceeded. This new open item contains the order reason, that is, the reason for which the item was
created.

Activities
1. Starting from the Self-Billing Monitor (
Logistics
Sales andDistribution Billing BillingDocument Self-Billing Procedure (Automotive)
), choose
Settings
Maintain General Parameters
and enter the SD billing document types (for CMR or DMR) and item categories to be used for automatic
postings.
2. Under
Settings
Maintain Tolerance Groups
, create a tolerance group by choosing New Entries . Enter a name and description for the tolerance
group.
3. Choose Save .
4. Under
Settings
Set Tolerance Check
, define the absolute and/or percentage tolerance limits for your tolerance group, by choosing Percent. or
Abs. Tolerances .
5. Choose New Entries , and enter the following data:
Enter a sales organization and your tolerance group.
Specify the upper and lower tolerance limits per delivery and/or material, and select Check Limit .
Save your entries.
6. Under
Settings
Maintain EDI Partner Parameters
, assign the tolerance group to your sold-to party and save.
7. Under
Settings
Maintain Sold-To Party Parameters
, specify the SD condition type you want to use to post automatic value differences and new
open items. SD revenue account determination uses this information to decide which account to make a posting to.

1.1.1.3 Automatic Posting in Case of Differences

Purpose
In the case of value-only or value-/quantity differences the system automatically creates additional postings so that the receivables correspond to the delivery item
that was transmitted in the self-billing document.

Prerequisites
You must have specified the document types and order reasons and, if required, item categories, that the system is to use for automatic postings. See also
Automatic Posting Settings in General Parameters .
You must have made the appropriate settings in Customizing for Sales and Distribution. See Customizing Checklist for Automatic Postings .

Process Flow
Technically speaking, the automatic postings are created via normal SD documents in the background. Firstly, the system creates a credit or debit memo request
(technically via an SD order document). This is then immediately converted into an SD billing document, that is, a credit or debit memo.
( ) The system ignores any billing blocks that are set for the document type. Conversion to billing document occurs immediately regardless of billing blocks.
The system differentiates between postings that are relevant only for value and postings that are relevant for both value and quantity. Certain SD settings enable
the system to process the value-only postings (for example, item categories or order reasons) correctly.
See Differentiation of Value-Only and Value/Quantity Differences .

Result
The system automatically creates clearing postings and new open items for differences, according to the settings you have made in Customizing for self-billing
and for Sales and Distribution.

1.1.1.3.1 Automatic Posting Settings in General Parameters

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 8 of 22

Purpose
In order to enable automatic posting in case of differences, you must set the document types and order reasons for the different types of posting and difference.
You can also specify item categories.

Process Flow
Starting from the Self-Billing Monitor, under

Settings

Maintain General Parameters,

you find the screen section Settings for automatic postings .

You must set a document type and order reason for each combination of criteria.
You can also specify an item category. If you do so, the system directly uses the item category specified here, ignoring the item category determination that would
normally take place for the credit or debit memo request. Otherwise, you must adjust the standard item category determination accordingly.
The document types and item categories that you set here always refer to the request document that corresponds to the transaction, in the list of SD order types
available in the system .

1.1.1.3.1.1 Setting the Order Reasons

Purpose
The system can tell by the order reason that a request document comes from the automatic routines of the SD self-billing procedure.
The order reason also controls whether and how the billing item is relevant for retro-billing.
When processing a self-billing document, the system checks that the order reasons are correctly set. If they are not, the system terminates processing with an
error message in the log.

Prerequisites
You have either:
copied from client 000 SAP's order reasons delivered specially for the SD self-billing procedure
defined your own order reasons for SD self-billing, making sure to set the Usage of order reason for retro-billing as shown in the table below.

Process Flow
You set the order reasons in the general parameters, under Settings Maintain General Parameters in the Self-Billing Monitor.
These are the suggested settings, using the example order reasons from client 000:
Transaction in General Parameters

Order reason

Description of order reason

Usage of order reason for retro-billing*

Automatic posting in case of value

VBI

SBWAP: difference clearance (value)

Automatic posting in case of quantity/value QBI

SBWAP: difference clearance

difference

(quantity/value)

difference

New open item in case of value difference

VOI

SBWAP: new open item (value)

New open item in case of quantity

QOI

SBWAP: new open item (quantity/value)

difference

*Usages of order reason for retro-billing1 = Request or credit/debit memo is for self-billingThis processing type is assigned to the order
reasons used for transactions that are relevant to value only. In the retro-billing process, documents with these order reasons are included in
calculating the total value, but no new price determination is carried out. 2 = Credit/debit memo is for retro-billing in case of price changeThis
processing type is assigned to the order reasons used for transactions that are relevant to value and quantity. In the retro-billing process, a
new price determination is carried out for documents with these order reasons. A new price determination is always carried out for billing
documents (the initial billing document in self-billing) in retro-billing.
( ) You must ensure that the self-billing order reasons are not used for any other normal postings, if you want to use the order reasons to identify documents
from automatic SD self-billing. The verification step checks if the settings in the order reason are correct.

1.1.1.3.2 Condition Types for Automatic Postings

Purpose
The condition types used to post difference values in credit/debit self-billing documents are, like all condition types, linked with revenue account determination in
Financial Accounting. Therefore, they are important for determining the account to which values are posted.

Prerequisites
You must do one or both of the following:
use the suitable condition type available as standard in the SAP system, PDIF . This is contained in the standard pricing procedure RVAA01 .

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 9 of 22

define your own condition type(s). You must make sure that the condition type is the last price-relevant condition in the pricing procedure. Otherwise the
system will not use the correct value in the automatically created documents.

Process Flow
You set the condition type used to post difference values per sold-to party under

Settings

Maintain Sold-To Party Parameters

in the Self-Billing Monitor.

This condition type will be used to post all difference values, both for difference clearing entries or for automatic new open items. The system uses the condition
type to determine the account, to which the values are posted.
Example
Document

Condition

Value

Revenue acct

Name

Initial billing doc.

Price

+100.-

800000

Inland revenue

Initial billing doc.

10% discount

-10.-

800020

Sales deduction discounts

-5.-

800099

Costs/revenues from differences

in SD self-billing

Automatic differences determined PDIF

in processing

10 pieces of material costing 10 dollars per piece are delivered to a customer. The customer also gets a 10% discount. The net item value is therefore 90 dollars.
In the self-billing document, 10 pieces are shown with a net value of 85 dollars.
Since value determination in the self-billing procedure does not depend on the individual price components but on the net values, the difference amount cannot be
split up into the condition types used in the initial billing document. Therefore, the difference amounts are posted with a special condition type. This ensures that
separate revenue accounts can be used for all differences from self-billing. The same applies for clearing postings and new open items.

1.1.1.3.3 Customizing Checklist for Automatic Postings

Purpose
You must make certain settings for copying control and item category assignment in Customizing for Sales and Distribution, so that the system can create
documents in SD for automatic postings from self-billing. The following overview shows which settings you should check/make.

Checklist
Customizing setting to be checked
Delivery-related billing types in the order types used

Location in Customizing
Sales and Distribution
Sales Document Header

Notes
Sales

Sales Documents

Define Sales Document

Types

Here, you must check which delivery-related billing types

you use. For example, deliveries for a customer's LZ
scheduling agreements are settled using the self-billing
procedure. The delivery-related billing type could be defined
as F2 in the order type LZ.
This billing type creates the 'initial' invoice. All further
documents created in the SD self-billing procedure refer
back to this initial invoice for the delivery.
Copying control must also be set so that documents can be
created automatically: see below.

Sales document types

As above

As an option, 2 new order types (G2WT and L2WT) are

available to enable automatic postings relevant exclusively
to value (as opposed to quantity and value). The main
purpose of the document types is to control item category
determination so that the system determines categories
that are defined as "value items".
Check which order-related billing types are used per sales
document type (here: for credit or debit memo request).
If you are proceeding as recommend by SAP, you should
make the following assignments:
Sales doc. type Order-rel. billing doc.
G2 G2
G2WT G2
L2 L2
L2WT L2
( ) If you have assigned item categories directly in the
application, under General Parameters, you do not need
the document types G2WT and L2WT. You can simply
use the standard document types G2 and L2, because you
directly specify the correct item categories for value
postings.

Copying Control: Billing Document Sales Document

(Header)

Sales and
Documents
Documents

Distribution

Billing

Billing

Maintain Copy Control for Sales

Copying Control: Billing Document to

Sales Document

Here, you check that copying control exists for the billing
type for the initial billing document to the credit/debit memo
requests. The example shows the assignments that
should be made if you use the new credit and debit memo
requests for F1 and F2 billing documents:
Example:
G2 -> L2
(F2 -> G2WT)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 10 of 22

F2 -> L2
(F2 -> L2WT)
F1 -> G2
(F1 -> G2WT)
and so on.
It is not necessary to make these settings unless you use
G2WT and L2WT.
Copying Control: Billing Document Sales Document

As above

Here, you check that copying control exists and is correctly

(Item)

set for item categories from the initial billing document to

item categories for the sales document types for request
documents. If the new, exclusively value-based debit/credit
memo requests are to be created for an item from the
initial billing document, you must set that, that the new
value item categories G2WT and L2WT are used in the
target document for the combination of document type and
item category in the initial self-billing document.
Example:
Source Target
F2 / LZN G2WT / G2WT
F2 / LZN L2WT / L2WT
F2 / TAN G2WT / G2WT
and so on.
You must make the settings for all item categories (from
the source documents) that you use.
If you use G2 and L2, you must make the appropriate
setting for G2 and L2 as target document type. You need
the item categories G2WT and L2WT.

Copying Control: Sales Document Billing Document

Sales and
Documents

Distribution
Billing
Billing
Maintain Copying Control for Billing

Here, you set that the order types G2(G2WT) or L2(L2WT)

(the document types of the request documents) can be

Documents

Copying Control: Sales Document to

billed with billing types G2/L2.

Billing Document

Example:
Tgt bill. type Srce order type
G2 G2WT
L2 L2WT
For each combination, only the necessary entries for the
item categories G2WT and L2WT are shipped as standard.
The target item category is ____ (blank) so that it is
adopted directly from the appropriate request document.
These settings are not required if you do not use the new
document types G2WT and L2WT.

1.1.1.3.4 Optional Default Customizing Settings

Use
SAP has shipped special Customizing settings in client 000. These settings are not automatically copied to other clients on installation or Release update. You
can choose to copy the settings to your client using the Customizing client comparison function.

Features
Sales document types
Credit memo request for transactions relevant only to value: G2WT
Debit memo request for transactions relevant only to value: L2WT
Item categories for value-only items
G2WT for credit memos
L2WT for debit memos
Item category assignment

Order type

Item category group

Item usage

ItemCat-HgLvlItm

Item category

G2WT

NORM

G2WT

L2WT

NORM

L2WT

Copying control billing document to sales document

Source

Target

Transaction

Document type

Item category

Document type

Item category

Value credit memo

F2

LZN

G2WT

G2WT

Value debit memo

F2

LZN

L2WT

L2WT

Value credit memo

F2

TAN

G2WT

G2WT

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 11 of 22

Value debit memo

F2

TAN

L2WT

L2WT

Value credit memo

F1

LZN

G2WT

G2WT

Value debit memo

F1

LZN

L2WT

L2WT

Value credit memo

F1

TAN

G2WT

G2WT

Value debit memo

F1

TAN

L2WT

L2WT

Copying control sales document to billing document

Source

Target

Transaction

Document type

Item category

Document type

Value credit memo

G2WT

G2WT

G2

Value debit memo

L2WT

L2WT

L2

Item category

(that is, including copying control at the level of the item categories G2WT and L2WT.)

1.1.1.3.5 Differentiation of Value-Only and Value/Quantity

Differences
Purpose
For automatic postings in case of differences in self-billing, the system differentiates between value-only and value-and-quantity differences. This differentiation is
not only important information for the person responsible, it also affects the statistics update in the system, in particular the Logistics Information System (that is,
the Sales Information System) and CO-PA (statistics on revenue values and sales quantities.)
For example, differentiation between value-only and value/quantity differences means that automatic postings created for value differences do not cause an
increase in billed quantities in the Sales Information System. Differences in quantity, however, are updated to the information system.
For this purpose, SAP has shipped as standard two new document types (optional) and two new item categories (always needed), both called G2WT and L2WT.

Prerequisites
The ACTION codes must be set correctly. See Table of ACTION Codes to Control Self-Billing/Retro-Billing .
The item category set for value-only differences in the General Parameters must be an item category that has been defined as a "value item" in
Customizing for Sales and Distribution. You do this by setting the value A (value item) in the Item type field. See also Automatic Posting Settings in
General Parameters .
The item category determination for the two new "value" document types, G2WT and L2WT, must be set so that the two new item categories G2WT and
L2WT are found and used in all possible cases.

Note
If you use the standard document types G2 and L2, the document types must be set for the request documents under
You have two alternatives

Settings

General Parameters

1. You set G2/L2 for both quantity-only and quantity/value postings. In this case, item categories are necessary, so you must enter the item categories for
value-only transactions (G2WT and L2WT) in the item category assignment, so that they are allowed for the document types G2 and L2.
2. You set G2/L2 and G2WT/L2WT respectively. In this case, the system finds the correct item categories via item category determination.
You must set the system so that when a G2WT or L2WT request document is created for an initial billing document, the value-only item categories are set
and used for all possible item categories in the target document.

Process Flow
For an example of the settings required and the process flow, see Example of Differentiation of Difference Type .

1.1.1.3.5.1 Example of Differentiation of Difference Type

This example shows how the system can differentiate between differences in value only and differences in quantity and value between an internal invoice and a
self-billing document.
It does so using item category assignment.
Starting point
Doc. type of order (scheduling agreement) LZ
Item category LZN
Doc. type of delivery: LF
Doc. type of delivery-related initial invoice: F2
( ) The initial invoice is the invoice used to settle the LF delivery for the LZ scheduling agreement.
Order item category for value-only items (in self-billing doc.) G2WT
( ) New item categories for value-only items:

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 12 of 22

SAP has shipped two new SD item categories as examples for value-only items in credit/debit memos: G2WT and L2WT (based on the standard item categories
G2N and L2N.) The most important parameters in these item categories are:
Item type: A (value item)
Billing relevance: Order-related billing document.
Item category assignment
Since the two order document types G2WT and L2WT are new, settings must be made for them in Customizing for item category assignment (see also
Customizing Checklist for Automatic Postings .)
The following entries have been made as an example:
Sales doc. type

Item category group

G2WT

NORM

Item usage

ItemCat-HgLvlItm

Item category
G2WT

L2WT

NORM

L2WT

If a credit or debit memo request is created with document type G2WT or L2WT and the corresponding material is controlled by item category group NORM, the
system automatically determines the new item category for a value-only item.
If you have detailed differentiations (such as further item category groups) you must also make the approriate entries and assign the item categories G2WT and
L2WT for these. You must set all item category determinations so that the document types G2WT and L2WT all lead to item categories G2WT and L2WT.

1.2 EDI Settings for the SD Self-Billing Procedure

Use
The Automotive enhancement to the SD self-billing procedure can only work if the transmitted data is correctly adopted from the EDI subsystem into the IDoc
(basic type GSVERF01) and from there into inbound processing in the SAP system.
The following chapters describe all the required settings in the EDI and IDoc environment, and in the context of SD documents.

Activities
You make the settings for the EDI/IDoc environment under

Tools

Business Communication

IDoc

IDoc Basis

IDoc.

The basic EDI settings for the Automotive enhancement to SD self-billing are:
Logical message

SBWAP

Process code for this logical message

SBAP

IDoc type

GSVERF01

( ) this IDoc GSVERF01 and the SD self-billing inbound processing are designed for a ratio of 1 IDoc to 1 delivery note .
This means that the EDI subsystem has to split up the data so that one IDoc contains the data of one delivery. The IDoc GSVERF01 is not designed to contain
the whole transmission.

1.2.1 Setting Up the EDI Partner

Purpose
Technically speaking, the EDI partner is the partner entered in the control record of the IDoc being used (type GSVERF01.)
From a business management point of view, the EDI partner is the sender of the transmission. This sender may represent several sold-to parties or goods
recipients in your SAP system. That is, the EDI partner might be correspond to exactly one customer entered in the SD customer master, however, the EDI
partner might represent several partners entered in the SD customer master. For example, Car Inc. sends you self-billing documents. In your system, you have
several customer master records for Car Inc ., to represent the fact that you deliver to several different plants within the company. The customer master record
that represents Car Inc. may not be used as a whole in SD documents but only for the single receiving plants. However, Car Inc. can still be your EDI partner.
The EDI subsystem must be able to identify the EDI partner and enter it in the control record of the IDoc. This partner number is always accompanied by a
partner type and sometimes also by a partner role.

Process Flow
You set the partner profile in EDI Basis and the inbound parameters in the application.
Under

Tools

Business Communication

IDoc

Partner Profile

, you create the partner profile with the following data:

Partner number: 999999999 (number from the customer master that represents the EDI partner)
Partner type: KU (customer)

Note
Partner type LS (logical system) can also be used for test purposes.
Partner function: AG (sold-to party) , RG (payer) or blank

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 13 of 22

Message type: SBWAP

Message code: (usually) blank
Message function: (usually) blank
Test: (usually) blank
Process code: SBAP
Syntax check: X
Processing by function module: Background (recommended)

Note
Immediately can also be used, but strictly for test purposes: this setting could bring a productive system to a standstill, because the processing of each
IDoc would be sent to a dialog process of the application server.
Under
Logistics
Sales and Distribution Billing
Billing Document
Self-Billing (Automotive)
Settings
for the EDI partner specific to the SD self-billing procedure. See also: Processing Inbound Self-Billing Documents .

Maintain EDI partner

, you make settings

1.2.2 Determination of EDI Sold-To Party

Use
The system must determine the EDI sold-to party for any self-billing document transmitted, in order to carry out all further steps in processing the data. It uses the
transmitted vendor number to do this. The sender can send partner description and/or unloading point, as additional information to allow more precise
determination. The purpose of this is to determine the SD sold-to party using the transmitted data.

Integration
The settings made in table T661W are the same as those used for processes other than SD self-billing, for example, inbound delivery schedules.

Prerequisites
The sender must transmit a vendor number.
The sold-to party must be entered in the table T661W in Customizing for Sales and Distribution, under
Sales
Sales
Documents
Scheduling
Agreements with Delivery
Schedules
Control EDI Inbound Processing Execute Sold-To Party Assignment for Release Orders
.
You must make the required system and IDoc settings for the sold-to party (Basis IDoc settings and SD self-billing settings) as described below.

Features
The system determines the sold-to party for the EDI transmission. It takes the information from the EDI transmission:
vendor number (mandatory)
partner description (optional)
unloading point (optional)
and uses this information to look for an entry in the table T661W. If a suitable entry is found, the system takes the sold-to party to be used for further processing of
the transmission.

Activities
You carry out the following to enable determination of sold-to party:
EDI-Relevant Settings for the Vendor (mandatory)
EDI-Relevant Settings for the Partner Description
EDI-Relevant Settings for the Unloading Point .
Application-specific settings for the sold-to party inbound parameters. See also Processing Inbound Self-Billing Documents .

1.2.2.1 EDI-Relevant Settings for the Vendor

Use
These settings enable the system to determine the sold-to party for a self-billing document transmitted per EDI.

Prerequisites
The sender transmits the vendor number used to refer to you as vendor in the sender system (vendor number at sender.)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 14 of 22

Procedure
1. Enter the vendor number at sender in the customer master:
-> in the Account at customer field in the Sales area data: Orders view
-> in the Account at customer field in the Company code data: Correspondence view.
2. When mapping the IDoc GSVERF01, enter the vendor number at sender as follows:
-> in the segment E1EDKA1
-> for partner usage "LF" PARVW = LF
-> in segment field PARTN = 0000012345 (example)
( ) With numbers that consist exclusively of numerical values, zeros may be inserted before the number, as shown above. If this is the case, the
number must be entered with these extras zeros in the Account at customer fields and in the table T661W (see also: Determination of EDI Sold-To Party .)

1.2.2.2 EDI-Relevant Settings for the Partner

Use
You make these settings if you want the system to use the partner description transmitted in a self-billing document to determine the sold-to party for the self-billing
document. A partner description can contain any type of data and is often a reference to the plant to which the goods were delivered.
These settings are optional. The only mandatory settings for sold-to party determination are the EDI-Relevant Settings for the Vendor .

Prerequisites
The sender transmits a partner description in the self-billing documents.

Procedure
1. Enter the partner description in the customer master for the goods recipient.
2. When mapping the IDoc GSVERF01, enter the partner description as follows:
-> in the segment E1EDKA1
-> for partner usage "WK" PARVW = WK
-> in segment field PARTN = 0001 (example).

1.2.2.3 EDI-Relevant Settings for the Unloading Point

Use
You make these settings if you want the system to use the unloading point transmitted in a self-billing document to determine the sold-to party for the self-billing
document.
These settings are optional. The only mandatory settings for sold-to party determination are the EDI-Relevant Settings for the Vendor .

Prerequisites
The sender transmits an unloading point in the self-billing documents.

Procedure
1. Enter the unloading point in the Unloading point field in the Shipping data section of the SD scheduling agreement.
2. When mapping the IDoc GSVERF01, enter the unloading point as follows:
-> in the segment E1EDKA1
-> for partner usage "AB" PARVW = AB
-> in segment field PARTN = A00012 (example).

1.2.3 Making the Settings for Mapping in the EDI Subsystem

Purpose
The EDI subsystem must process the transmission so that the IDoc is created correctly in the SAP system.

Prerequisites
Each IDoc should only contain the data of one delivery. Both the GSVERF01 IDoc and the inbound processing are designed for one delivery note per
IDoc .

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 15 of 22

Process Flow
The EDI subsystem must give the transmissions to the ERP interface in such a form that one delivery is referred to per IDoc.
The examples that follow are based on the German standard VDA 4908 for self-billing documents. Other standards, like the ANSI 820, work in a similar manner.
You should regard the information as an example, and adapt it to your situation.
Standard VDA 4908
Record type 821

Unique data record for the transmission as a whole (external transmission number)

Record type 822

Contains the data for a self-billing document. Can occur one or n times.

Record type 823

Contains the data for a delivery note. Can occur one or n times in a record with record
type 822.

Record type 824

Contains the data for a delivery note item. Can occur one or n times in a record with
record type 823.

In the case of this common German standard, VDA 4908, the EDI subsystem must split up the transmissions so that one IDoc is created per record of type 823
(that is, per record that represents a delivery note.)
The basic data (e.g. transmission number, self-billing document number and date) contained in the record types 821 and 822, which are above 823 (the delivery)
in the VDA 4908 hierarchy, must be written redundantly in the appropriate fields and segments in each IDoc.
For an example of the actual mapping settings to be made for the SD self-billing procedure, see Table of Settings for Mapping in EDI Subsystem .

1.2.3.1 Table of Settings for Mapping in EDI Subsystem

This table shows which data from the transmission has to be transmitted by the EDI subsystem to the various segments and fields of the IDoc GSVERF01.
Where the content and significance of an IDoc field is qualified by an "ID" or "Qualifier", the field plus qualifier should always be regarded as a unit.
For the purpose of the example, the table uses the record types, fields and descriptions of a common German standard, VDA 4908. Other standards, like the
ANSI 820, work in a similar manner. You should regard the information as an example, and adapt it to your situation.
Record type / Field from VDA

VDA description

4908

Target segment and field in

IDoc Segment/Qualifier lD or

GSVERF01

Identification

Comment

821

821

821

821

821

821 // 05

Old transmission number

E1EDK02-BELNR

E1EDK02-QUALF = 077

Predecessor of current
transmission, no function directly
based on this at present.

821 // 06

New transmission number

E1EDK02-BELNR

E1EDK02-QUALF = 074

Per EDI partner and external

transmission number, the system
checks to see that the
transmission number has not
been used twice.See also: the field
help in the transaction under
Settings
Maintain EDI
partner

821 // 07

Transmission date

E1EDK02-DATUM

E1EDK02-QUALF = 074

The date entries that correspond to

the transmission numbers.
Transmission numbers and date
are stored in the same segment
E1EDK02, and qualifiers 074 and
077 respectively.

821 // 04

Vendor number

E1EDKA1-PARTN

E1EDKA1-PARVW = LF

The vendor number that refers to

you in the self-billing document
creator's system. It is only
possible to determine the sold-to
party if an entry has been made in
this field.

822

822

822

822

822

822 // 03

Self-billing document number

E1EDK02-BELNR

E1EDK02-QUALF = 073

The number assigned to the selfbilling document by its creator.

For test purposes, if you are
directly linking MM/SD, the MM
document number is written in
E1EDK 01 -BELNR (without
qualifier logic).

822 // 05

Payment-due date

E1EDK03-DATUM

E1EDK03-IDDAT = 028

The significance of this date can be

agreed between partners. Here it is
shown for information purposes
only. For test purposes, if you are
directly linking MM/SD, the
baseline payment date of the
settlement document (self-billing
document) is used here.

822 // 12

Currency

E1EDK01-CURCY

No qualifier / ID

The currency of the sent data must

be the same as the currency used
internally for the initial transaction.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 16 of 22

Exception: EURO. For Euro as

currency, one partner can use
Euros and the other use a
participating currency.
822 // 14

Self-billing type key

0 convert to
1 convert to

E1EDK01-ACTION
005
006

2 convert to

007

No qualifier / ID

The self-billing type key and its

ACTION code controls further
processing, along with the posting
key 824. See Table of ACTION
Codes to Control SelfBilling/Retro-Billing .

822 // 16

Accounts payable number (BMW) E1EDK02-BELNR

E1EDK02-QUALF = 076

Special reference number for

inbound payments at BMW

823

823

823

823

823

823 // 03

Delivery note number

E1EDK02-BELNR

E1EDK02-QUALF =

This number serves mainly to

012 (general delivery note)

061 (special delivery note)

determine the transaction in the

recipient system. Which sort of

062 (ESA order)

063 (ext. delivery note number
(ESA))

transaction is used for a certain

sold-to party can be set in the
Inbound Parameters for the Sold-

081 (collective daily delivery note

for sequenced JIT calls)
082 (SD summarized JIT calls)

To Party .
See below for more information on
sales document determination.

E1EDKA1-PARVW = WK

Customer plant to which was

delivered. This is the partner

823 // 04

Customer plant

E1EDKA1-PARTN

description used in Determination

of EDI Sold-To Party .
823 // 13

Unloading point

E1EDKA1-PARTN

E1EDKA1-PARVW = AB

Unloading point in customer plant.

This is the unloading point used in
Determination of EDI Sold-To

824

824

824

824

824

824 // 03

Transaction/posting key
01 (Goods receipt)

E1EDK01-ACTION
091

No qualifier / ID

ACTION codes from 822 // 12 and

824 // 03 control the type of

02 (Correction goods receipt)

03 (Return delivery)
04 (Consignment material)

092
093
094

processing and automatic posting.

See Table of ACTION Codes to
Control Self-Billing/Retro-Billing .

05 (Damages in transport)
99 (Misc.)

095
099

Qualifier 096 triggers a purely

value-based clearing invoice.

"indirect"

096

Customer's supplier reference

number

E1EDP19-IDTNR

Party .

824 // 04

E1EDP19-QUALF = 001
Note:

Number of the material as used in

the system of the creator of the

If qualifier 002 were used, the

goods issue (of the customer from
system would identify the material the point of view of the supplier).
number at supplier (as used in
that SAP system.)

The customer material must be

maintained in the corresponding
order or SD scheduling
agreements, and be contained in
the delivery.

824 // 05

Delivery quantity

E1EDP01-MENGE

No qualifier / ID

Separate decimals with points.

See below for details.

824 // 06

Unit of measure

E1EDP01-MENEE

No qualifier / ID

It must be possible to use this

ISO-Code to find a unit of
measure in the SAP system units
of measure table. The unit of
measure must either be the base
or the sales unit of measure for
the material.

824 // 09

Total price / value

E1EDP26-BETRG

E1EDP26-QUALF = 003

Net value of delivery note item

(with +/- sign according to +/- sign
key.) The net item value is the
only transmitted value that is
included in the process.

824 // 10

+/- sign key

The total price from 824 // 09 must

_: positive (or)
1: positive
2: negative

have the correct +/- sign from 824

// 10. See also The +/- Sign in SD
Self-Billing .

824 // 11

Percentage cash discount

This information cannot at present

be included.

824 // 12

Cash discount amount

E1EDP26-BETRG

824 // 14

Sales tax amount

E1EDP04-MWSBT

E1EDP26-QUALF = 007

Net value of delivery note item

(with +/- sign according to +/- sign
key.)
Tax value of the item, used
together with the net value to
calculate the gross value in the
Reporting Tool.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 17 of 22

Percentage sales tax

E1EDP04-MSATZ

825

825

825

(825 // 03)

(Key for surcharge/reduction)

E1ED P 05-KSCHL(or. E1ED K

05, if at header level)

825

825
Type of transmitted condition (4figure field)
Technical information: is stored
in VSBCON-KONART_T.

825 // 05

+/- sign key

1 = positive
2 = negative

E1EDP05-ALCKZ(or E1EDK05)

Must be converted to +/- sign.

Technical information: is stored
in VSBCON-SIGN_T.

825 // 04

Surcharge/reduction amount

E1EDP05-KOBETR(or E1EDK05)

Condition value (total value of

item for corresponding condition
type.)
Technical information: is stored
in VSBCON-KWERT_T (in
transaction currency) or in
VSBCON-KWERTRL_T (in
displayed currency).

E1EDP05-KTEXT (or E1EDK05)

Text for condition type.

Technical information: is stored
in VSBCON-KTEXT_T.

E1EDP05-KRATE(or E1EDK05)

Condition amount.
Technical information: is stored
in VSBCON-KBETR_T (in
transaction currency) or in
VSBCON-KBETRRL-T (in
displayed currency).

E1EDP05-KPERC(or E1EDK05)

Percentage condition, alternative

to condition amount.
Technical information: is stored
in VSBCON-KPERC_T.

E1EDP05-UPRBS (or E1EDK05)

Condition price unit (Example:

$100 / 10 pieces, where 10 is the
price unit.)
Technical information: is stored
in VSBCON-KPEIN_T.

E1EDP05-MEAUN (or E1EDK05)

Unit of measure for transmitted

condition amount and for price
unit.
Technical information: is stored
in VSBCON-KMEISO_T.

( )
Decimal points
If values with decimal places are transmitted to an IDoc segment field, they must be separated by a point. For example:
+/- sign

Transmitted value

In IDoc Segment Field

positive

100,24

100.24

negative

50,78

-50.78

1.2.3.2 Monetary Values in SD Self-Billing

Definition
The system uses exclusively the net value of the delivery note item for processing. All other transmitted values are ignored for self-billing processing.
The only other significant monetary value transmitted is the value-added tax amount .

Use
Effect on EDI settings
The net value of the delivery note item must be transferred to the IDoc segment/field E1EDP26-BETRG with qualifier 003 .
The value-added tax amount is adopted from E1EDP04-MWSBT and stored internally.
Effect on processing/display in the Self-Billing Monitor
The Self-Billing Monitor displays values based on the net value of the delivery note item.
The Self-Billing Monitor displays the gross amount (value inc. tax), which is dynamically calculated from the net item value and the value-added tax amount.
( ) No values transmitted at delivery note header level are used in the SD self-billing processing. All such header values as are displayed in the Self-Billing
Monitor and lists are calculated from the values at delivery note item level.

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 18 of 22

1.2.3.3 The +/- Sign in SD Self-Billing

Definition
The values for SD self-billing, item net value and item value-added tax, can be transmitted either as positive or negative values.

Use
This determines the type of processing as follows:
Positive value: The recipient of the self-billing document receives money from the sender
Negative value: The recipient of the self-billing document is debited by the amount transmitted ("debit memo").
You must therefore make sure that these values are transferred to the corresponding IDoc field with the correct +/- sign. The GSVERF01 IDoc has no specific
+ /- sign field . The +/- sign is always read together with the value fields (such as E1EDP26-BETRG.)
The +/- sign for the standard VDA 4908 (as used in the Table of Settings for Mapping in EDI Subsystem example):
As a rule, VDA 4908 value fields all refer to a specific +/- sign field, that contains the appropriate +/- sign key. Therefore, a value always has to be processed
along with its +/- sign information.
+ + sign (VDA +/- sign key 1)
=> the value is transferred to the IDoc segment field with no further editing
- - sign (VDA +/- sign key 2)
=> the value is transferred with preset minus sign to the appropriate IDoc segment field
Example:
Transmitted values

Data as written in IDoc

Net value of item: 100,20 ($)

E1EDP26-BETRG -100.20

+/- sign: 2 (negative)

E1EDP26-QUALF 003

Note
Make sure that all monetary values are saved with the correct +/- sign as the monitor also displays other monetary values such as value-added tax and
condition rates.

1.2.4 Processing for Self-Billing or Retro-Billing

Purpose
The system can interpret transmissions in various ways. How it does so depends among other things on how you set the ACTION codes at header and item level
and which type of processing is linked to each setting.
These settings are fundamental to the implementation of SD self-billing with EDI.
This process explains the possible types of processing in detail. For details of the actual combinations of mapping settings that are linked to these processing
types, see Table of ACTION Codes to Control Self-Billing/Retro-Billing .

Process Flow
The following are the various types of processing possible, numbered with reference to their listing in the table mentioned above.
1. Normal processing with quantity/value This is the standard type of processing, where a customer displays deliveries from a vendor using self-billing
documents. The vendor receives money.The system determines the corresponding SD document (delivery/current invoice or delivery confirmation if working
with the JIT call procedure), compares it with the transmitted data, and creates new invoice documents if required for value or value and quantity
differences.Depending on whether there is a difference only in value or also in quantity and value, the system automatically proceeds as follows: Value
difference When the quantity is correct, but the value is not, the system automatically creates a credit or a debit advice, depending on the +/- sign of the
difference. The value of this credit or debit memo position plus the value of the present billing item is then exactly the same as the value transmitted by the
customer. See also The +/- Sign in SD Self-Billing .In these purely value-relevant documents, the system always leaves the original transaction quantity
unchanged.You should make the appropriate settings to make sure that this quantity is set as not relevant for information system update, such as to the
Sales Information System, Business Warehouse or CO-PA. You do this by defining the relevant item categories and/or document types as "value items" in
Customizing. See also Differentiation of Value-Only and Value/Quantity Differences . Value and quantity difference When both value and quantity are
incorrect (the quantity difference usually causing the value difference), the system automatically creates a document for the difference amount, but in this
case the quantity for the document is the difference quantity.In this case, you should make sure that the quantity is set as relevant for information system
update, such as to the Sales Information System, Business Warehouse or CO-PA. Usually, you can simply use the original item categories for this
purpose. Normally, no extra Customizing settings are required.
2. Value-based clearing invoice without accessing SD Retro-Billing This type of processing assumes that the transmission explicitly states that it is a
clearing invoice, by referring to a transaction that has already been settled.If you know that the transmissions from this sender always deal exclusively with
value changes, then you should use this type of processing if:- you do not want quantities to be changed in your internal statistics update (SIS, CO-PA)
3.

( )
This might be the case if you know that quantity-relevant transactions, such as return deliveries, are never processing in self-billing.
- you are only using the automatic posting to bring the values into the system, so that they can be automatically cleared in FI on payment- you do not want to

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 19 of 22

use retro-billing functions to check that the values transmitted are correct
4. Value-based clearing invoice with accessing SD Retro-Billing As above, except that the invoices, which are already in the document flow for the
original delivery, are recalculated simulatively using the retro-billing functions. The system thus determines whether the amount transmitted agrees with the
amount calculated simulatively in your system.This processing type is advantageous if you have set the system to create new open items automatically
when a certain tolerance limit is exceeded. The tolerance check takes into account all postings with their +/- signs, so that no new open items are created
unnecessarily. For example, if both you and your customer have changed a price retrospectively, the amount becomes the same and the debit amount is
not interpreted as a difference.
5. Transaction not relevant for processing Certain combinations of ACTION codes are not supported. You should check such data and edit it manually if
necessary.It is technically possible to edit the ACTION codes in the Self-Billing Monitor, so that the transmission can be processed. However, you must
ensure that the processing type that results from this editing is the correct one.
1. Deactivation by system If you receive data that you definitively do not want to process, you can set the header ACTION code 007.The data record (IDoc)
is adopted into the transmission, but is immediately deactivated for further processing. This means that it can never into the processing step.

Caution
This setting, once made, cannot be manually undone.

( )

For example, in the case of VDA 4908 (as used in the Table of Settings for Mapping in EDI Subsystem ), you could set that the self-billing document type 2
(non-valuated goods receipt) is always converted into ACTION code 007, since this data is generally purely informative.

1.2.4.1 Table of ACTION Codes to Control Self-Billing/RetroBilling

The processing logic, that is, whether the system interprets a transmission as self or retro-billing, depends on the ACTION codes in the IDoc at header and item
level.
In the case of the standard VDA4908 (as used in the example: Table of Settings for Mapping in EDI Subsystem ), this information is taken from self-billing
document level and delivery item level:
VDA4908
822//14

self-billing document type key (self-billing document level)

824//03

operation key (item of delivery note level)

Here the self-billing document type key must be converted to the ACTION code at IDoc header level, the operation key to the ACTION code at IDoc item level.
See also: Table of Settings for Mapping in EDI Subsystem .
Together with the +/- sign, the ACTION codes determine whether the system interprets the transmission as self or retro-billing. The following table shows which
combinations of ACTION codes (at header and item level) and +/- sign lead to which type of processing.
ACTION- Code, header

ACTION- Code, item

+/- sign

Description

Type of processing

005

091

Standard self-billing doc.:

Recipient receives displayed

1.) Standard processing with

quantity/value

amount for the first time, for the

corresponding delivery. The
transaction is relevant for quantity
and value.
005

091

Debit advice that is relevant either

1.) Standard processing with

for value-only or for value and

quantity, depending on the billing
document.

quantity/value

The transaction is supported,

although it is really a clearing
entry, from a business
management point of view.
Better:
006 / 092 or 006 / 093
005

092

+/-

Goods receipt correction (VDA

1.) Standard processing with

4908):
a.) With a - sign, this is actually a
clearing entry and should be

quantity/value

transmitted as 006 / 092.

b.) With a + sign, it could be that a
quantity that was subsequently
entered for a delivery is being
billed. This is then transmitted like
005 / 091.
005

093

+/-

094
095
096

These combinations are not

4.) Transaction not relevant for

supported.

processing

099
006

006

091

092

+/-

(+)/-

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

This combination is not supported. 4.) Transaction not relevant for

A normal goods receipt should be
transmitted with 005/091.

processing

All three of these combinations

1.) Standard processing with

Page 20 of 22

093
095

(GR correction, return delivery,

transport damages) are regarded

quantity/value

as quantity-relevant corrections to
an already-processed goods
receipt, and are treated as a
normal advice.
006

094 (consignment)

+/-

This combination is not supported. 4.) Transaction not relevant for

006

096

+/-

Clearing invoice, for example due 2.) Value-based clearing invoice

processing

to retroactive price change.

006

099

+/-

without accessing SD RetroBilling

Clearing invoice, for example due 3.) Value-based clearing invoice

to retroactive price change.
with accessing SD Retro-Billing

For more information on the different types of processing, see Processing for Self-Billing or Retro-Billing .

1.2.5 Number of Deliveries (IDocs) per Transmission Number

Use
A self-billing transmission must be split up by the EDI subsystem so that one GSVERF01 IDoc is created per delivery record (VDA record type 823 ( as used in
the Table of Settings for Mapping in EDI Subsystem ).)
However, the system later processes and displays the transmission as one unit.

Prerequisites
The sender of the transmission assigns an external transmission number (in the standard VDA 4908 as used in the Table of Settings for Mapping in EDI
Subsystem , this is the record type 821)
Use of external transmission numbers must be indicated in the EDI Partner Parameters , under Settings in the Self-Billing Monitor.
The external transmission number must be entered in each IDoc created in the E1EDK02-BELNR segment/field with qualifier 074 .

Features
Inbound processing sees that the sender (partner number in the IDoc control record) and the external transmission numbers are the same, and so recognizes that
these individual IDocs logically belong together.
You can set the start of processing so that the system closes a transmission and begins processing the data when all IDocs for a transmission have been
received. You do this in the Self-Billing Monitor, under
Settings
Maintain EDI Partner Parameters
.
However, this can only work if the EDI subsystem has a counter that shows how many IDocs belong to a particular transmission. The number of IDocs created for
a transmission (for an external transmission number) must then be transferred to the IDoc segment field E1EDS01-SUMME with E1EDS01-SUMID = 028 . It is
sufficient if the EDI subsystem enters this in the last IDoc transmitted.
These prerequisites must be fulfilled in order to directly link the verification and processing steps, as described in Processing Inbound Self-Billing Documents .
Alternatively, you can use a fixed offset to schedule the processing step after the first IDoc created the transmission.

1.2.6 Transmitted Conditions, Reference Numbers and Date

Information
Purpose
In the Self-Billing Monitor's list of deliveries and list of material items, the user can call up data on conditions and reference numbers and also display dates.
This process explains, from which IDoc segments the system takes this data to display in the Self-Billing Monitor.

Process Flow
1. Conditions
Condition information for the document header must be set in the appropriate fields in the segment E1EDK05 .
Condition information on each material item should be in segment E1EDP05 .
These fields are detailed in the Table of Settings for Mapping in EDI Subsystem under 825 .
1. Reference numbers
Usually, several reference numbers are transmitted, for various purposes. The IDoc provides various segments and fields for this.
The significance of the reference number is always dependent on a "qualifier" field. You must ensure in mapping that the reference number adopted in a field
does in fact agree with the text for the qualifier. The system takes the following reference numbers from the IDoc into the list of reference numbers transmitted:
All numbers from the IDoc segment/field (IDoc header level)
E1EDK02-BELNR , with the qualifier entry from the same segment/field, E1EDK02-QUALF
E1EDK01-BELNR (no qualifier entry)

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 21 of 22

All numbers from the IDoc segment/field (IDoc item level)

- E1EDP02-BELNR , with the qualifier entry from the same segment/field, E1EDP02-QUALF .

Note
How certain reference numbers are used subsequently in processing is set under
Settings
Maintain Sold-To Party Parameters
, in the Self-Billing
Monitor. Here you set, for example, which reference number is used for delivery determination, or which reference number is entered as the "main reference"
in the Financial Accounting item.
Date information
In a similar way to the reference numbers, date information can be saved for display later.
Again, the significance of the date information depends on a field (IDDAT), which describes the significance of the data. This identifier field has the same
significance as the qualifier fields.
The system takes the following date information from the IDoc into the list of date information transmitted:
All dates from the IDoc segment/field (IDoc header level)
E1EDK03-DATUM , with the IDDAT entry from the same segment/field, E1EDK03-IDDAT
All dates from the IDoc segment/field (IDoc item level)
- E1EDP03-DATUM , with the IDDAT entry from the same segment/field, E1EDP03-IDDAT .

PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.

Page 22 of 22