Sales billing

-
  • Billing
    • Billing methods 
  • Self billing
  • Configuration
    • Copying control
  • Determination
    • Profit Center Determination in Billing Area
    • Account Determination
  • Collective billing
  • Payments in Sales and Billing Documents
  • Mass complaint processing 
  • Retroactive Billing 
  • Billing Plan
  • Down Payments for Sales Orders
  • Installment Plan
  • Invoice split 
  • Cash on delivery 
  • FAQ
    • How to set up the Billing relevance?
    • How to transfer batch items in the billing documents and should we do it?
    • 1444964 - Invoice split for pro forma invoices
    • 1532865 - FAQ: Profit center in billing document
    • 1481238 - How are different exchange rates (Price, FI postings and Conditions) determined in billing documents
    • 371764 - VAT registration number: Destination country
    • 11162 - Invoice split criteria in billing document
    • 2451236 - Invoice split due to different partner address
    • 1561427 - Billing document split
    • How are different exchange rates (Price, FI postings and Conditions) determined in billing documents?
    • 1590601 - Stock transfer order intercompany: how to copy price from PO to intercompany billing
    • 1822569 - VF07: display/print the output of archived invoice
    • 2921478 - Reference number is truncated during invoice creation
    • How to realize partial quantity billing for delivery with batch split items?
    • 372772 - FAQ: How is the cost determined in the billing document?

Billing

Billing methods 

  • an individual billing document per sales document
    • Copy control: field VBRK/VBRP. In this field, you choose data transport routine 3.
  • a collective billing document for several sales documents
    • the header data that appears in the billing document must match
    • the specified split conditions do not apply
  • several billing documents for one or more sales documents
    • In Customizing for copying control, you can specify requirements for splitting to prevent sales orders or deliveries from being combined into a collective billing document.
  • billing Document Requests
    • BDRs that contain data from external sources are referred to as external billing document requests (EBDRs). EBDRs serve to transform and persist billing data that your system has received from an external source. BDRs are structured very similarly to billing documents but contain some specialized fields that do not appear in billing documents.
    • Unlike billing documents, however, billing document requests are not relevant for output and cannot be posted to financial accounting.

Self billing

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.

You can use this function to process both normal self-billing documents and retroactive price change.

Delivery procedures
  1. standard deliveries
  2. deliveries with external delivery note number (for example, external service agent)
  3. deliveries that refer to an external order number (ESA, MAIS Pick Up Sheet, delivery order)
  4. JIT deliveries with invoice for day's collective delivery note.

Process Flow

  1. The vendor creates a delivery with reference to the SD scheduling agreement/order in his system.
  2. The vendor posts goods issue of the delivery.
  3. The vendor creates an initial billing document, which he does not send to the customer.
  4. The customer receives the materials and creates a goods receipt with reference to the delivery note number in the MM module.
  5. 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 .
  6. The customer transmits the self-billing document to the vendor "per EDI" 
    • 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.)
  7. The vendor system reads and checks the transmission, which can contain several IDocs and therefore several deliveries.
  8. 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.)
In the Self-Billing Monitor (transactionVSB1N), some header records contain more than one material item. If some of the material items are assigned incorrectly or not at all to internal SD documents (for example, deliveries), it is still possible to carry on processing because you can separate the faulty material items from the correct ones, and assign them to a new header record for further processing.

Settings

  • Under Settings Maintain General Parameters 
    • the order reasons, document types and item categories for automatic postings or open items
  • Under Settings Maintain 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).
  • Under Settings Maintain Tolerance Groups
  • Under Settings Maintain Sold-To Party Parameters
    • 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.
    • You have specified which number(s) are transmitted in order to determine a sales document, to which to assign the transmission.
    • 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 .

Processing

#Verification step: 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.

Data that has been read and set as withouterrors 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.
  1. The system reads the individual IDocs received from the EDI subsystem. The first IDoc creates a transmission.
  2. The system checks that all the mandatory fields are filled in the IDoc
  3. The system assigns the number transmitted for delivery determination to a delivery in the SAP system ( Settings  Maintain Sold-To Party Parameters )
  4. If the system finds a corresponding SAP delivery, it assigns the material transmitted (the customer material number) to a material in this delivery.
  5. The system determines the customer name in the SAP system.
  6. The system determines the transaction currency (from the initial billing document for the delivery) in the SAP system.
  7. The system determines how the processing step is started. The processing step can be started either automatically, or manually via the Self-Billing Monitor.
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.

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.


#Processing Step: the processing step compares the transmitted data and incoming self-billing documents with the internal invoices in the vendor system.
  • 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.
    • Two different IDocs may for example arrive for one delivery if your customer separately posted a delivery for two pallets in the system, thereby transmitting the credit advice in two IDocs for this delivery.
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.

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. After processing, the processing status changes to either processed with errors (C) or processedwithouterrors (D).

Tolerance Limit for Value Differences

  • 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.
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. This condition type will be used to post all difference values, both for difference clearing entries or for automatic new open items. 

Automatic Posting in Case of Differences

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.

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 can tell by the order reason that a request document comes from the automatic routines of the SD self-billing procedure.


  • Delivery-related billing types in the order types used
  • Sales document types: 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”.
    • 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

Differentiation of Value-Only and Value/Quantity Differences

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.

EDI Settings for the SD Self-Billing Procedure

A ratio of 1 IDoc to 1 delivery note is intended for the IDoc GSVERF01 and SD inbound processing for self-billing.

This means that the EDI subsystem has to split up the data so that one IDoc contains the data for one delivery. The IDoc GSVERF01 is not designed to contain the whole transmission.

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.

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 .

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

Enter the partner description in the customer master for the goods recipient.
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).
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.)
  • New transmission number: E1EDK02-BELNR, E1EDK02-QUALF = 074
  • Vendor number: E1EDKA1-PARTN,E1EDKA1-PARVW = LF
  • Self-billing document number: E1EDK02-BELNR, E1EDK02-QUALF = 073
  • Self-billing type key: E1EDK01-ACTION
  • Delivery note number: E1EDK02-BELNR: 
    • 012 (general delivery note)
    • 061 (special delivery note)
    • 062 (ESA order)
    • 063 (ext. delivery note number (ESA))
    • 081 (collective daily delivery note for sequenced JIT calls)
    • 082 (SD summarized JIT calls)
  • Transaction/posting key: E1EDK01-ACTION
  • Delivery quantity: E1EDP01-MENGE No qualifier / ID
  • Total price / value: E1EDP26-BETRG, E1EDP26-QUALF = 003
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. 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.
 
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”).

Processing for Self-Billing or Retro-Billing

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

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.
  • 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 .
2999500 - SBWAP - Errors during direct Invoice determination
The delivery confirmation process (DELCON) from the Automotive JIT processing is used.
Credit memos related to those delivery confirmations are processed by the SD Selfbilling (SBWAP).

Other than in the "normal" delivery based process (based on standard SD deliveries where customer sends SD delivery number in the credit memo), finding the right document in the DELCON based process is directly depending on a 100% match on the material item level. This means that even if on document header level there is a match between reference number sent in the credit memo and external number in the delivery confirmation the error 251 "Delivery could not be determined" occurs.
This happens as there is at least one matching error on material item level.
To solve this situation, SAP provides note 750872 allowing to directly fill in the SD delivery confirmation number (together with Qualifier 009) in the error editing of error 251.
This opens the possibility to bypass the document search and directly "provoke" a material match error in the correct delivery confirmation.

520994 - Errors from self-billing procedure cannot be edited
In table VSBEER, the entries that control whether a message can be edited are missing.

1783335 - VSB1- Delivery confirmation is discarded
If a single entry is there in Delivery confirmation table (DELCONHD) and the billing date is +- 30 days , then it is not getting processed.

1605859 - FAQ: Processing step in SD self-billing procedure

1. Question: What actions are carried out during the processing step in the SD self-billing procedure?
Answer: As part of the processing step, the system compares the quantities and values of the customer with the quantities from the delivery and the values from the billing document. The system also executes the tolerance checks and if there are differences that exceed the tolerance limit, the system creates corresponding clearing postings (new open items).

2. Question: Which function module is responsible for the processing step in the SD self-billing procedure?

Answer: In the SD self-billing procedure, the function module SD_SBWAP_MAINSTEP is responsible for the processing step.

3. Question: Can the processing step be repeated?

Answer: If the processing step was terminated due to a processing error, the step can be repeated. If the processing step was completed without errors, you can no longer execute the processing step again. Created postings can also no longer be reversed.

4. Question: What should I do if a transmission contains incorrect records that also hinder processing of subsequent records that have no errors?

Answer: On the screen "List of Deliveries", you can manually deactivate the incorrect records. These deactivated records are then no longer taken into account during the processing step and processing of subsequent records without errors is then possible.

5. Question: What should I do if I want to remove a transmission (for example, one that was received or created by mistake) from the system?

Answer: On the screen "List of Deliveries" of the credit memo monitor, you can manually deactivate all records. The transmission can then be processed. It ends in the status "Processing Finished w/o Errors"; however, it does not actually execute processing or create postings. An explicit deletion of the transmission is not provided for in the ERP system.

1590760 - FAQ: Verification step in the SD self-billing procedure
1. Question: What actions are carried out during the verification step in the SD self-billing procedure?

Answer: For the verification step, the system processes the received IDocs, groups the IDocs together in transmissions, checks the IDoc data, and finds the reference documents (sales documents, deliveries, billing documents). Transferred data is still not processed in the verification step.

2. Question: Which function module is responsible for the verification step in the SD self-billing procedure?

Answer: In the SD self-billing procedure, the function module SD_SBWAP_PRESTEP is responsible for the verification step.

3. Question: Can the verification step be repeated?

Answer: If the verification step ends with an error, the verification step can be repeated after the incorrect data is corrected. You can start the verification step again directly from the credit memo monitor (transaction VSB1, "Check" pushbutton). Alternatively, you can start the verification step using transaction VSBSMS.

4. Question: When can I find the long text of errors from the verification step, and how can I then correct the incorrect data?

Answer: In the credit memo monitor (transaction VSB1), you can see the numbers of error messages from the verification step on the display screen for the list of deliveries. You can double-click on this number to display the long text of error messages. On this display screen, you can also correct incorrect data by choosing "Process Errors".

1585263 - FAQ: Completed billing documents in SD self-billing proc.
1. Question: When is a billing document in the SD self-billing procedure considered as completed?

Answer: A billing document in the SD self-billing procedure is considered as completed if the following applies for the billing document:
  • An entry exists in the table VSBPBD and the indicator VSBPBD-OPEN_ITEM was not set, or
  • No entry exists in the table VSBPBD and the subsequent accounting document was cleared completely or in part, or
  • No entry exists in the table VSBPBD, the subsequent accounting document was not cleared and the billing document date is before the changeover date of the self-billing procedure (T665B-SWBWAP_ACTIVE).

2. Question: How is a credit advice for the billing document that was already completed processed?

Answer: A credit advice for a billing document that was already completed is processed as if this billing document no longer has any open items. For billing documents that were mistakenly completed too early (for example, due to clearing the accounting document), completely new open items may be created as a result, instead of open items being cleared.

3. Question: Can you use a BAdI to influence the decision made by the system of whether a billing document is considered as open or completed?

Answer: If no entry exists in the table VSBPBD for the billing document, the subsequent accounting document was not cleared and no changeover date was maintained for the credit advice, or the billing document date is before the changeover date, you can use BADI_SBWAP, method OPEN_ITEM_DECIDE to decide whether the billing document should be considered as open or completed by the SD self-billing procedure.

4. Question: Where can I find the description of the logic for using the table VSBPBD?

Answer: The description of the logic for the table VSBPBD is in Note 511958 (chapter 2).

5. Question: Is there a report to set billing documents that were mistakenly completed back to the open status?

Answer: Note 511958 provides a report to set mistakenly closed billing documents back to the open status. Note that the report ZZMAINTAIN_OPEN_ITEM is not a standard SAP report; it is considered as a modification.
Execute this report where possible only after you consult with SAP Development.

Configuration

Copying control

  • Which documents may be used as the basis for the billing document?
  • Which data is to be copied to the billing document from the reference document?
  • Should the order quantity or delivery quantity be invoiced?
  • According to which requirements is a sales document to be billed?
  • Should pricing be carried out again or should prices be copied from the sales order?

Determination

Account Determination

The condition technique is also used in account determination in order to allocate the correct GL account to the account key, as assigned in the pricing procedure.

IMG -> SD -> Basic Function -> Account Assignment -> Revenue account determination -> Check master data relevant for account assignment.

Through check master data relevant for account assignment, one has the opportunity to create account assignment grouping criteria. This grouping criteria provides the system with an extra variable in determining the required account number. For ex, by selecting check master data relevant for account assignment in materials: account assignment groups, one can specify whether a material should be classified as a trading item, service item, finished product etc. After the creation of these we should make sure they are assigned to the material master record. The same is true for customer account groups (domestic revenues, foreign revenues etc).

As account determination follows the condition technique, it is understood that there may be a need to change the condition table that is used in the access sequence to find the correct condition record (that is, the correct account number).

IMG -> SD -> Basic Function -> Account Assignment -> Revenue account determination -> Define dependencies of revenue account determination (field catalogs, condition tables)

After ensuring your condition tables exist as required, ensure that the access sequence and condition types are maintained as required too.

IMG -> SD -> Basic fncs -> Account Assignment -> Revenue account determination >> Define access sequences and account determination types. [Account determination types = KOFI (5 condition tables - 1, 2, 3, 4, 5; KOFK]

Now, create the account determination procedure.

IMG -> SD -> Basic fncs -> Account Assignment >> Revenue account determination >> Define and assign account determination procedures [std = KOFI00 - KOFI, KOFK]

The account determination procedure is then assigned to a billing type.

The column described as "CaAc" represents the cash allocation key, which causes the system to post directly into a GL account for cash entry, rather than into a receivables account. [EVV-cash clearing]

Finally, the assignment of the account key is the actual process of assigning the account key to each condition type (in the revenue account procedure), as done in the pricing procedure maintenance.
  • ERL - sales revenues
  • ERS - sales deductions
  • ERF - freight revenue
  • ERB - rebate sales deductions [ERU - accruals]
  • MWS - taxes on sales/purchases
  • PPC - cash payment, 
  • PPS - check payment, 
  • PPG - voucher

All that remains is the assignment of the GL accounts to the condition table, as specified in the access sequence.

Fields = (application - [sd/purchasing/recon account/cash settlement], condition type, chart of accounts, sales org, customer account assignment group, account assignment group for material, account key, G/L account

Profit Center Determination in Billing Area

Profit center (as well as cost center) may be determined in SD area before released to CO area when billing is released to accounting. Depending on the settings/integration SD has with CO the value for Profit Center field must be passed, it is made available from SD to CO via account item structure XACCIT-PRCTR when billing document is released to accounting. From SD perspective the role on that field is which profit center has to be determined.

There are some different ways from which profit center is taken to billing document, depending on the settings on the system precedence (ascending order) occurs then value is determined. It is important to remind that copy routine and user-exits might change the determination result.
  • Conventional business process:

The profit center is transferred from the sales document item (field VBAP-PRCTR) to the billing item (field VBRP-PRCTR).

        1. Common determination types:
          1. a) With sales documents:
            1. From the material master (table MARC-PRCTR)
            2. Via a substitution*
            3. By manual entry**
            4. From account assignment**
          2. b) Without sales documents:
            1. From the material master (table MARC, field MAEPV-PRCTR)
            2. By "external" specification ***
            3. Via a substitution*

*   e.g: Transactions OKEL, OKEM from CO-OM area
**  e.g: Transaction: VA01/02 > GoTo > Item
*** e.g: When executing GN_INVOICE_CREATE through structure field KOMFKGN-PRCTR. However if there is substitution customized then KOMFKGN-PRCTR_NEW is then determined.  

  • Special case:

If the profit center of the billing document (field VBAP-PCTRF) is already determined in the sales document item, this profit center is transferred to the external billing item.

  • Cross Company case:

Redetermination is always carried out using a substitution (OKEL/OKEM transactions).Check reasons in SAP Help and note 106875 if you want to know how to change that behavior.


Collective billing

As per standard config. the criteria for collective billing are If your sales order has:
  • same Payer
  • same Billing Type
  • same Terms of Payments
  • same Billing Date
  • same Incoterms

So, if the invoice is getting split on the bases of Ship-to party region, which not standard.
Also, check your copying control config in tcode VTFL.


Payments in Sales and Billing Documents

Electronic Payment Processing Using the SAP Digital Payments Add-On

  • Sales order: -> Card registration
  • Sales order: -> Authorization
  • Delivery: -> Check for 

Payment Processing Using the Sales and Distribution (SD) Component

Mass complaint processing 

Define complaints reasons and specify for each reason which follow-up actions, such as creating a credit memo or return, are performed by the system. We can define two follow-up actions for each complaints reason.

Using the BADI BADI_CMP_PROCESSING you can override the settings in Customizing Define Complaints Reasons (entries in table CMP_REASON).

Retroactive Billing 

New pricing agreements that you make with your customers 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.

Note: Retroactive billing is a special billing function often used in scheduling agreement processing.

Billing Plan

  • Periodic billing means billing a total amount for each individual billing date in the plan. 
  • Milestone billing means distributing the total amount to be billed over multiple billing dates in the billing plan.

Functions

  • Automatic creation of billing plan dates
    • The system determines the schedule of individual dates based on general date information, such as the start and end dates.
  • Pricing
    • Sales document items are billed as each billing date in the plan becomes due.
    • In milestone billing, we can specify a percentage to be billed or an actual amount.
  • Billing block
    • The block prevents processing for a particular billing date
    • In down payment processing with milestone billing plans, a delivery block can be set in the date category. 
  • Billing status
    • The status indicates to what extent the billing has been processed for that particular date. 
  • Billing rule for milestone billing
    • whether the billing amount is a percentage of the total amount or whether it is a fixed amount
  • Fixed dates in milestone billing
    •  whether the date is fixed or whether the system copies the date from the planned or actual milestone dates
  • Creating with reference
    • the system automatically proposes the reference plan 
  • Exchange rate determination 
    • Store a certain exchange rate for each date. 

Billing plan control

  • Billing Plan Type
  • Date Description (for information purposes)
  • Date Category
    • Billing rule/Date description//Billing block/Whether the date is fixed or not / Billing type (proposes the type of billing document to be used during billing: invoice, pro forma, and so on)/ Delivery block 
  • Proposed Date Category
  • Proposed Date
  • Assigning billing plan types to sales document items

Down Payments for Sales Orders

Down Payment Processing Using Milestone Billing Plans

Process
  1. A down payment agreement is created as a deadline (billing date) in the billing plan. This enables you to agree on as many down payments as are required for different dates
    • %, billing type FAZ
  2. A down payment request is created and sent to the customer when the deadline (billing date) is reached. 
    • When transferring to financial accounting, a down payment request is created as a noted item in the down payment request account. 
  3. When an incoming down payment is posted in financial accounting, the system requests that the down payment is assigned to one of the available down payment requests.
    • It means, when the customer makes the payment, the incoming payment is posted to financial accounting with reference to the down payment request. 
  4. For partial invoices (that is, during milestone billing) and for the final invoice, the down payments that have been made are added to the respective invoice as down payment items for clearing.
Customizing
  1. Settings for the Billing Plan:
    • Settings for the Billing Plan (TAO)
    • For the down payment request, copying requirement 20 must be entered in copying control at item level. In the standard system, order type TA for copying control is set up according to billing type FAZ for item category TAO.
    • For down payment clearing, copying requirement 23 must be entered in copying control at item level. In the standard system, order type TA for copying control is set up according to billing type F2 for item category TAO.
  2. Maintaining a Pricing Procedure with Condition Type AZWR
    • ..include AZWR before output tax, Enter condition 2 (item with pricing) and the calculation formula 48 
    • Maintain the printing indicator
  3. Financial Accounting Settings

Down Payment Processing Using Document Conditions

Process
  1. Create a sales order and store the down payment agreement as a document condition in the sales order
  2. The down payment made is transferred to the SD billing document as a down payment to be cleared.
  3. -> to post the incoming payment directly to financial accounting (transaction F-29)
  4. Delivery Processing – Depending on the process, the system creates a delivery
  5. Post Goods Issue
  6. Billing – Down payment clearing is carried out in the billing document. The system does not generate a down payment clearing line. Instead, it sets a down payment value that is to be cleared in the document condition AZWB. Order-related or delivery-related billing can be carried out.
  7. Down payment clearing
  8. In the customer line item report via transaction code FBL5N, select the Cleared items radial button and the Normal items tickbox.
Customizing
  • The business function SD_01 under ENTERPRISE_BUSINESS_FUNCTIONS is activated via T-code: SFW5.
  • Condition types: 
    • AZWA for debit down payments
    • AZWB for billing
    • AZDI for rounding differentials balance.

Installment Plan

The installment plan allows customers to pay in installments. With the installment plan, the system creates one invoice for all installments. On the basis of this billing document print an invoice listing all the installments with the relevant payment dates and amounts to be paid by those dates. For each installment, the system creates a customer line item in financial accounting.

The installments are defined by the payment terms, which are controlled by the payment terms key. Your system administrator can define the following data for this key: a number of installments, payment dates, a percentage of the billing value.

Invoice split 

With the invoice list functionality, you can create, at specified time intervals or on specific dates, a list of billing documents (invoices, credit memos, or debit memos) to send to a particular payer.
  • Invoice list: This type is used for invoices and debit memos.
  • Credit memo list: This type is used for credit memos.
Create Invoice Lists - VF21 and VF24.

Prerequisites

  • 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:LR for invoices and debit memos, LG for credit memos.
  • Copying requirements must be defined
  • A customer calendar must be defined, specifying the time intervals or dates on which invoice lists are to be processed.
  • Output condition records for condition types LR00 and RD01 must be created.


Cash on delivery 

A customer orders from you. Transportation of the goods is carried out by a forwarding agency,\ by postal service or UPS. The goods are delivered to the customer with an invoice and the customer pays upon delivery.

Process steps:
  1. During order entry, you enter the forwarding agent as the payer. 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
  2. Set conditions:
    • NAPG: Package fee: The forwarding agent requests this from the supplier of the goods and reimburses it upon payment by the customer.
    • NANG: Cash on delivery fee: The forwarding agent demands this from the supplier of the goods and reimburses it upon payment by the customer.
    • NAUE: Bank transfer fee: The postal service requests this from the customer upon payment.
  3. Worklist for deliveries by selecting the forwarding agent, this is identified as a cash on delivery transaction.
  4. Billing must be created for cash on delivery.

Blocking reasons

The following blocks are possible:
  • Block a customer for billing (master data)
  • Automatically block individual sales documents for billing ( sales doc.type)
  • Block individual items of a sales document manually for billing.

How to set up the Billing relevance?

Note: if it is sub items, then we have to clarify the dependencies.

  • A: Relevant for delivery-related billing
  • ...
  • L: Relevant for pro forma - no zero quantities
    • This enables us to prevent items with a zero quantity from being added to the pro forma invoice.
  • M: Relevant for delivery-related billing - no zero quantities (including main batch item)
    • This enables us to prevent items with a zero quantity from being added to the billing document, even if the main batch item is involved.
  • N: Relevant for pro forma - no zero quantities (including main batch item)
    • This enables us to prevent items with a zero quantity from being added to the pro forma invoice, even if the main batch item is involved.
  • O: Relevant for delivery-related partial quantity billing - no zero quantities
    • Use this indicator if we want to select items and partial quantities in billing. The O indicator also enables us to prevent items with a zero quantity from being added to the partial quantity billing document.
  • P: Relevant for delivery-related billing (CSFG) - no batch split items
    • The foundation is a business transaction with a cross-system flow of goods (CSFG). The P indicator enables us to prevent batch split items from being added to the billing document.
  • Q: Relevant for delivery-related CRM billing
    • We use this indicator if we want to use CRM billing to bill the items that have been delivered and posted as goods issues in the ERP system.
  • R: Relevant for delivery-related CRM billing - no zero quantities we use this indicator if we want to use CRM billing to bill the items that have been delivered and posted as goods issues in the ERP system. This also enables us to prevent items with a zero quantity from being added to the billing document in CRM.
  • T: Relevant for delivery-related CRM billing for the creation of intercompany billing. We use this indicator if we want to use CRM billing to bill the items that have been delivered and posted as goods issues in the ERP system to create the intercompany billing.
  • U: Relevant for delivery-related CRM billing for creation of intercompany billing - no zero quantities
    • We use this indicator if we want to use CRM billing to bill the items that have been delivered and posted as goods issues in the ERP system to create the intercompany billing. This also enables us to prevent items with a zero quantity from being added to the intercompany billing in CRM.
  • V: Relevant for delivery-related CRM billing for creation of intercompany billing of stock transport orders
    • We use this indicator if we want to use CRM billing to bill the items for stock transport orders that have been delivered and posted as goods issues in the ERP system to create the intercompany billing.
  • W: Relevant for delivery-related CRM billing for creation of  intercompany billing of stock transport orders - no zero quantities
    • We use this indicator if we want to use CRM billing to bill the items for stock transport orders that have been delivered and posted as goods issues in the ERP system to create the intercompany billing. This also enables us to prevent items with a zero quantity from being added to the intercompany billing in CRM.
Notes:
  • if we change the billing relevance for the item cat. after Go Live, then we need to run a report to correct previously created documents. For that, we use instructions from the SAP note 319866 - Correction report billing relevance after Customizing changes.

How to transfer batch items in the billing documents and should we do it?

In the delivery document, there is a batch split, that is more batch items are created for one main item.
When creating the billing document for the delivery, the system can handle the batch items in different ways.

For the situations described below (1-3), make the following field settings for the batch main item (HPOS) and batch subitems (UPOS):
  • Item category (table TVAP)
  • Billing relevance FKREL (from the item category, table TVAP)
  • Billing quantity FKMGK (from the copying control, table TVCPF)
  • Invoiced quantity FKIMG (from the billing document, table VBRP)
  • Cost VPRS
Depending on customizing setting, the following possibilities exist:

Solution 1 - The main item is billed, the batch items are just displayed
The item category of main item and batch items can be the same, for example, TAN.
  • Transaction VOV7: the item category must have Billing relevance TVAP-FKREL = A - Delivery-related billing document.
  • Transaction VTFL at item level: the Billing quantity V_TVCPFLP-FKMGK = G - Cumulative batch quantity minus invoiced quantity.
Solution 2 - The main item is just displayed, the batch items are billed.
The item category of main item and batch items can be the same, for example, TAN.
  • Transaction VOV7: the item category must have Billing relevance TVAP-FKREL = A - Delivery-related billing document.
  • Transaction VTFL at item level: the Billing quantity V_TVCPFLP-FKMGK = B - Delivery quantity less invoiced quantity.
Solution 3 - Only the main item is billed.
The batch item must have a different item category, for example, ZTAN
Transaction 0184: setup item category ZTAN as a batch sub-item category of TAN

Transaction VOV7:
  • The item category of the main item must have Billing relevance TVAP-FKREL = A - Delivery-related billing document.
  • The item category of the batch item must have Billing relevance TVAP-FKREL blank - Not relevant for billing.
  • Transaction VTFL at item level: the Billing quantity V_TVCPFLP-FKMGK = G - Cumulative batch quantity minus invoiced quantity.

 


FAQ

1444964 - Invoice split for pro forma invoices

This problem can only be corrected by a modification. Contact your SAP consultant in this regard. Also refer to the attached SAP Note 170183.

The following method is a possible solution:
1) In the copying control for billing documents, check which data transfer routine you use for your action; for example:

LF - F2 / TAN in the field "Data VBRK/VBRP".

2) Create an RV60C6XX data transport routine using transaction VOFM (Requirements & Formulas) or enhance the subroutine you already use as described in the attached proposed solution.

3) Store this subroutine in the copying control for billing documents for your process.

Explanation:
As a result, the system will transfer the currency information from the sold-to party and not from the reference document.

1532865 - FAQ: Profit center in billing document

You must differentiate between the following business transactions for the transfer of the profit center to the billing document.
1. Basic determination:
a) With sales documents:
The determination of the profit center is carried out in the sales document item according to the following rules (in ascending order):
 1) From the material master (table MARC)
 2) Via a substitution
 3) By manual entry
 4) From a "real" account assignment (profitability segment, cost center, and so on)

b) Without sales documents:
The transfer of the profit center is carried out in the document item according to the following rules (in ascending order):
 1) From the material master (table MARC, field MAEPV-PRCTR)
 2) By "external" specification
 3) Via a substitution

Example of a process without sales documents:
Billing is carried out using the external billing interface (function module GN_INVOICE_CREATE).
Here an "external" specification is the transfer via the communication structure (field KOMFKGN-PRCTR).
However, a substitution is triggered by the communication structure with the field KOMFKGN-PRCTR_NEW.


2. Conventional business process
The profit center is transferred from the sales document item (field VBAP-PRCTR) to the billing item (field VBRP-PRCTR).


3. Cross-company code business process:
The profit center is transferred from the sales document item (field VBAP-PRCTR) to the intercompany billing item (field VBRP-PRCTR) since the company codes of the document item and document header match in this case.
The profit center is always deleted for the external billing document and a new profit center (the profit center of the billing document) is determined since the company codes of the document item and document header differ in this case.
Redetermination is carried out using a substitution. Therefore, you must maintain and activate a substitution rule in Customizing for the profit center invoice (transaction 0KEL and 0KEM).

This concept ensures that a profit center that can be posted to in the company code of the document header is available for a document item.

Special case:
If the profit center of the billing document (field VBAP-PCTRF) is already determined in the sales document item, this profit center is transferred to the external billing item.


4. Customer-specific adjustment:
If you want to transfer the profit center in the billing document differently from the concept described, you use transaction VOFM (Requirements & Formulas) to create a data transport routine RV60C6XX or you enhance the routine already in use as described in the attached solution proposal.

1481238 - How are different exchange rates (Price, FI postings and Conditions) determined in billing documents

In the billing document there are three different exchange rates

  1. Exchange Rate for Price Determination (field VBRP-KURSK).
  2. Exchange rate for FI Postings (field VBRK-KURRF).
  3. Exchange rate for Condition Currency (field KONV-KKURS).

Detailed explanation:

1. Exchange Rate for Price Determination (field VBRP-KURSK):

VBRP-KURSK.png

  • It is about conversion of Local Currency and Document Currency for Price determination.
  • The determination of this exchange rate depends on the setting of "PricingExchRate type(TVCPFLP-PFKUR)" in customizing Copy Control transaction VTFL or VTFA. The possible options are:
    • A Copy from sales order
    • B Price exchange rate = Accouting 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 Exch.rate determination accord.to date of services rendered


2. Exchange rate for FI postings (field VBRK-KURRF):

VBRK-KURRF.png

  • It is about conversion of Local Currency and Document Currency for Financial(FI) postings.
  • Customer invoice
    If there is a manual entry in the sales order field VBKD-KURRF (Goto -> Header -> Accounting), then it is copied into VBRK-KURRF. Otherwise VBRK-KURRF is determined during invoice creation from the currency tables (Transactions: OB08, OB07 and OB22) according to the billing date.  It is supposed that manual entry has higher priority. If there is no exchange rate type set in customer master (KNVV-KURST), then by default exchange rate 'M' is taken.
  • Intercompany billing
    VBRK-KURRF is always redetermined.
    It is because sales order and intercompany invoice could have different local currency, so it doesn't make sense to copy the exchange rate. 

3. Exchange rate for Condition Currency (field KOMV-KKURS):

KOMV-KKURS.png

  • It is about conversion of Condition Currency and Local Currency at price condition level.
  • Generally, the system always uses pricing date to determine the exchange rate for the conversion of the condition currency to the local currency. 
  • While for the copied conditions, a new exchange rate determination doesn’t happen. If you expect KOMV-KKURS to be determined based on pricing date(KOMK-PRSDT) for copied conditions during billing creation, please check note 97487. As for the Intercompany Billing scenario, please check note 367149.
  • If you expect KOMV-KKURS to be determined based on billing date, please check note 92613. 

For more information about the Exchange Rate Type used in the determination of KURRF or KURSK, please check note 22781.

371764 - VAT registration number: Destination country

The system does not determine the VAT registration number of the partner at all or determines it incorrectly. Among other things, the following may be the case:
  1. The system determines the tax concerning a partner function (for example, 'PY') of the ultimate consignee and this partner function does not have a VAT registration number in the country of the ship-to party but in a different country of the EU.
  2. Intercompany billing is involved. The intercompany billing customer has a VAT registration number in a country of the EU but not in the country of the ultimate consignee as a ship-to party - in particular, if this country is NOT a country of the EU.
  3. For invoices with several items that have a different ship-to party each and thus have different destination countries, a billing split occurs due to the destination country-specific VAT registration number.
The VAT registration number is determined from the country of the customer in his/her master data first. In addition, the system may determine the VAT registration number concerning the above 'Destination country' field which is the same as the country of the ultimate consignee as a ship-to party. This is the standard system response.

In some cases, however, it is required to determine the VAT registration number for a country different from the destination country of the ultimate consignee.

A prerequisite is that you do not enter a tax destination country in the sales order manually. Otherwise, the global 'Destination country' field is overridden.

A user exit is offered. There you have the option to set the 'Destination country' field in such a way that the VAT registration number is determined with the desired country. In addition, a program change is made.

*$*$----------------------------------------------------------------$*$*
*$ Correction Inst.         0020751258 0000166531                     $*
*$--------------------------------------------------------------------$*
*$ Valid for       :                                                  $*
*$ Software Component   S4CORE                                        $*
*$  Release 100          All Support Package Levels                   $*
*$  Release 101          All Support Package Levels                   $*
*$  Release 102          All Support Package Levels                   $*
*$  Release 103          All Support Package Levels                   $*
*$--------------------------------------------------------------------$*
*$ Changes/Objects Not Contained in Standard SAP System               $*
*$*$----------------------------------------------------------------$*$*
*&--------------------------------------------------------------------*
*& Object          REPS RV60AFZZ
*& Object Header   PROG RV60AFZZ
*&--------------------------------------------------------------------*
*& FORM USEREXIT_EMPFANGSLAND_SETZEN
*&--------------------------------------------------------------------*
*>>>> START OF INSERTION <<<<
FORM USEREXIT_EMPFANGSLAND_SETZEN.

* For intercompany invoice, the country of the internal customer as
* Payer is used.

* IF TVFK-VBTYP CA VBTYP_FKIV.
*   LOOP AT AVBPAK WHERE PARVW = 'RG'.
*     EMPFANGSLAND = AVBPAK-LAND1.
*   ENDLOOP.
* ENDIF.

ENDFORM.                    " userexit_empfangsland_setzen
*>>>> END OF INSERTION <<<<<<
...
*&--------------------------------------------------------------------*

11162 - Invoice split criteria in billing document

The invoice split may have been carried out for the following reasons
  1. Explicit setting in Customizing for the copying control for billing documents
    • In the copying control for billing documents (table TVCPF),
    • - Sales document to billing document (transaction VTFA)
    • - Delivery document to billing document (transaction VTFL)
    • data transport routine '003' (single invoice) was entered in the 'VBRK/VBRP Data' input field (up to Rel.2.2.: ‘Data transport’) in the 'Item' view and therefore an invoice split was created deliberately.
  2. Different partners in the billing header
    • One or more header partners in the billing documents generated are different, which leads to an invoice split.
    • In partner processing, an invoice split also occurs if, for the partner functions of the billing header (in the standard system, these are SP, BP and PY), the entries in the partner table (table VBPA) of the reference document and the billing document also differ in only one field (!).
  3. Different values in the billing header fields
  4. In a data transfer routine, the same billing date is set for all documents (for example, by VBRK-FKDAT = SY-DATUM). This works when you bill using transaction VF01 ('Create Billing Document’): a single billing document is generated.
    • In VF06 ('Creating Background Jobs for Billing’), the variant with parameterization is used to avoid an unwanted split due to the billing date.
However, if you use transaction VF04 ('Maintain Billing Due list') or, in the background, transaction VF06 ('Creating Background Jobs for Billing’), several billing documents may be created.

To avoid a split due to different header fields - apart from the fields listed above - you have the option of using customer-specific data transport routines in the copying control of the relevant document types, which initialize (or equate) the corresponding fields.. However, the information contained in these fields is then lost in the billing document.

2451236 - Invoice split due to different partner address

  • Run VF01, insert the documents to bill, Execute.
    • The Billing Document Overview screen shows more billing documents.
    • Here it is possible to push button Split analysis to see the cause of the split.
  • Run VF04, Execute, select the documents to bill, perform the billing.
    • More billing documents are created.
    • Run VF03 to display one billing document, then by menu Environment > Split analysis it is possible to see the cause of the split.
  • Run VF06 and schedule the job.
    • Once the billing job finished, more billing documents are created.
    • Run VF03 to display one billing document, then by menu Environment > Split analysis it is possible to see the cause of the split.

The split analysis shows that the split occured due to different partner data (address).


This split is justified as the entries in VBPA table have to be identical. Otherwise the split occurs.

It can be seen from table VBPA that the address of the PY has been manually changed, as it has address indicator 'E'. If an address gets entered manually then the system generates an address number starting with 9xxxxxxxxx.

The system does not check whether the manual addresses are identical or not, it just simply checks the address numbers itself. Since it is not identical a split happens.

In order to avoid splits, such manual changes should not be done as with each change a new address number is assigned which later on leads to the split.

1561427 - Billing document split

The following known causes produce billing split.

Cause 1.

  • The resulting invoices have different header partners or different header fields in VBRK.
  • The split analysis shows what are the different fields, partners.
  • Notice that a partner is considered different whenever one or more fields of table VBPA is different.

Cause 2.
In case of collective processing, the system performs the userexit EXIT_SAPLV60P_010, if active. If the internal table CT_VKDFIF is sorted in the userexit EXIT_SAPLV60P_010, billing split can occur. Program logic:

  1. before execution of userexit, internal table V60P_INPUT_VKDFIF is sorted by Sold-to Party, Sales Organization, Billing Type (and other fields, see SAP note 111813). So the lines of V60P_INPUT_VKDFIF with same combination of Sold-to Party, Sales Organization, Billing Type are placed near.
  2. internal table V60P_INPUT_VKDFIF is passed to userexit EXIT_SAPLV60P_010 as CT_VKDFIF.
  3. after the execution of userexit, there is a LOOP at V60P_INPUT_VKDFIF, and at every change of Sold-to Party or Sales Organization or Billing Type, the system performs the billing creation.
  4. if CT_VKDFIF is sorted differently inside the userexit, then lines with same Sold-to Party, Sales Organization, Billing Type are not more placed near. As consequence split can occur. In this case split analysis does not help.

Cause 3.
In case of collective processing, the system never groups more than 1000 documents in one billing document. If more than 1000 documents with same combination of Sold-to Party, Sales Organization, Billing Type are billed together, there is a split. Example:

  • 1200 deliveries with same Sold-to Party, Sales Organization, Billing Type are selected for collective billing.
  • Simulation shows 3 billing documents. The split analysis shows different header data, for example different VBRK-ZUKRI (or other header data or header partner).
  • Run the collective processing: 6 billing documents are created !

The system performs a preliminary split after 1000 deliveries. Then in every "package" of deliveries there will be further split due to different VBRK-ZUKRI (or other header data or header partner). In this case split analysis does not help.

Cause 4.
The userexit USEREXIT_NEWROLE_XVBPAK_AVBPAK in program RV60AFZD has been wrongly implemented.

  • The userexit USEREXIT_NEWROLE_XVBPAK_AVBPAK in program RV60AFZD has been designed to add header partners using form XVBPAK_ROLE_ADD.
  • In this form the additional partner is appended to internal table XVBPAK, then XVBPAK is sorted.
  • If the partner is added to XVBPAK in a different way, then a split can occur. In this case split analysis does not help.

Cause 5.
Field(s) of internal table XVBRK are changed in userexit USEREXIT_PRICING_PREPARE_TKOMK and/or USEREXIT_PRICING_PREPARE_TKOMP in program RV60AFZZ.

  • Example:
       loop at xvbrk.                  
         xvbrk-FFFFF = 'XXXXXXXX'.
         modify xvbrk index sy-tabix.  
       endloop.

  • These userexits are performed after the form XVBRK_BEARBEITEN, where the system checks if split is necessary.
  • So, at next execution of XVBRK_BEARBEITEN, the system will compare current VBRK line with already appended XVBRK lines, changed by userexit, and they will be different. 
  • Result: all the VBRK records will be equal (with field set by userexit), but split occurred. In this case split analysis does not help.

Resolution

Please run the Split analysis, as explained under Reproducing the Issue.

  • If there are different Header fields, apart from the below ones (that do not cause the split - table VBRK), or different header partners, then the split is justified:

VBRK-KNUMV (Number of the Document Condition)
VBRK-NETWR (Net Value in Document Currency) 
VBRK-MWSBK (Tax amount in document currency)
VBRK-VBELN (Billing Document)
VBRK-RFBSK (Status for Transfer to Accounting)
VBRK-ERNAM (Name of Person Responsible for Creating the Object)
VBRK-AEDAT (Date of Last Change)
VBRK-ERDAT (Date on which the record was created)
VBRK-ERZET (Entry time)

Read note 11162 for more details.

  • If split analysis does not show possible causes, and the billing documents have been created by collective processing: 
    • Check if userexit EXIT_SAPLV60P_010 is implemented. If so check Cause 2;
    • Check if more than 1000 documents with same combination of Sold-to Party, Sales Organization, Billing Type have been billed together. See SAP note 111813;
  • If split analysis does not show possible causes, and the billing documents are created online, then probably it is due to Cause 4 or Cause 5. Review the implementation of the userexits.

How are different exchange rates (Price, FI postings and Conditions) determined in billing documents?

In the billing document there are three different exchange rates

  1. Exchange Rate for Price Determination (field VBRP-KURSK).
  2. Exchange rate for FI Postings (field VBRK-KURRF).
  3. Exchange rate for Condition Currency (field KONV-KKURS).

Detailed explanation:

1. Exchange Rate for Price Determination (field VBRP-KURSK):

VBRP-KURSK.png

  • It is about conversion of Local Currency and Document Currency for Price determination.
  • The determination of this exchange rate depends on the setting of "PricingExchRate type(TVCPFLP-PFKUR)" in customizing Copy Control transaction VTFL or VTFA. The possible options are:
    • A Copy from sales order
    • B Price exchange rate = Accouting 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 Exch.rate determination accord.to date of services rendered


2. Exchange rate for FI postings (field VBRK-KURRF):

VBRK-KURRF.png

  • It is about conversion of Local Currency and Document Currency for Financial(FI) postings.
  • Customer invoice
    If there is a manual entry in the sales order field VBKD-KURRF (Goto -> Header -> Accounting), then it is copied into VBRK-KURRF. Otherwise VBRK-KURRF is determined during invoice creation from the currency tables (Transactions: OB08, OB07 and OB22) according to the billing date.  It is supposed that manual entry has higher priority. If there is no exchange rate type set in customer master (KNVV-KURST), then by default exchange rate 'M' is taken.
  • Intercompany billing
    VBRK-KURRF is always redetermined.
    It is because sales order and intercompany invoice could have different local currency, so it doesn't make sense to copy the exchange rate. 

3. Exchange rate for Condition Currency (field KOMV-KKURS):

KOMV-KKURS.png

  • It is about conversion of Condition Currency and Local Currency at price condition level.
  • Generally, the system always uses pricing date to determine the exchange rate for the conversion of the condition currency to the local currency. 
  • While for the copied conditions, a new exchange rate determination doesn’t happen. If you expect KOMV-KKURS to be determined based on pricing date(KOMK-PRSDT) for copied conditions during billing creation, please check note 97487. As for the Intercompany Billing scenario, please check note 367149.
  • If you expect KOMV-KKURS to be determined based on billing date, please check note 92613. 

For more information about the Exchange Rate Type used in the determination of KURRF or KURSK, please check note 22781.

1590601 - Stock transfer order intercompany: how to copy price from PO to intercompany billing

The system copies the price from purchase order into intercompany billing only if customizing is correct. The subsequent settings are necessary:
  • The same condition type, for example PB00, must be defined both in SD and in MM. It must be present in MM pricing procedure of the purchase order and in SD pricing procedure of the intercompany billing
  • In customizing copy control replenishment delivery > intercompany billing (transaction VTFL) the field Price source (TVCPF-PRSQU) must be 'A' or 'B' This functionality is not supported for MM scheduling agreement.

1822569 - VF07: display/print the output of archived invoice

2921478 - Reference number is truncated during invoice creation

"Customer purchase order number"(VBKD-BSTKD) will also copied into VBRK-BSTNK_VF field which is 35 character long. You may consider using the value in this field to fulfill your business requirement. But this field is not transferred to accounting. If your want to get the value of "Customer purchase order number"(VBKD-BSTKD) in FI side, you may consider write a customer report, to get billing document VBRK-BSTNK_VF. Or, for the further, if you do not use accounting document header text, you can put the customer purchase order number into BKPF-BKTXT. You can achieve it using the EXIT_SAPLV60B_001 by populating XACCHD-BKTXT with VBRK-BSTNK_VF.

How to realize partial quantity billing for delivery with batch split items?

Normally you could make use of billing relevance ‘K’  Delivery-related invoices for partial quantity in the customizing setting of item category to realize partial billing for delivery items.

First of all, you may refer to note 77414 about the supported scenarios for delivery-related billing of items with batch split.

For those 3 possible situations when bill delivery with batch items, let’s think about the possibility of partial billing. According to note 482506, billing at
batch main item CANNOT have partial billing quantity.

Situation 1:
- The batch main-item cannot have partial quantity.
- The batch sub-items can only have quantity zero.
Situation 2:
- The batch main-item can only have quantity zero.
- The batch sub-items can have partial quantity.

Situation 3:
- The batch main-item cannot have partial quantity.
- The batch sub-items are missing.
Therefore only for situation 2:

2. Display of the batch main item Billing of the batch subitem
It would be possible to realize partial billing at batch sub-item:
Ensure the billing relevance is set to ‘K’ in item category



Item copying control should have Billing quantity ‘B’ Delivery quantity less invoiced quantity instead of ‘G’ Cumulative batch quantity minus invoiced quantity:



Both delivery batch main item & sub-item have item category ZTAX:


In VF01 selection list screen, adjust the billing quantity to 2 for batch sub-item:



Now it is possible to do partial quantity billing for delivery batch split item!

During delivery-related billing of a partial quantity of a delivery, in some cases the prorated billing value is set and in other cases the full billing value is set (VPRS)?

There are various business processes with the billing of a partial quantity of the delivery:
  • Delivery-related invoices for partial quantity
  • Billing document for proof of delivery (POD)
For a) Delivery-related invoices for partial quantity
With this business process, the following is intended:
  1. The planned distribution of the delivery quantity over partial invoices
  2. After the first invoice for a partial quantity, further invoices with partial quantities
  3. Overall, invoicing of total delivery quantity
This is enabled using an item category with one of the following billing relevances:
  1.  "K Delivery-related invoices for partial quantity"
  2.  "O Deliv.-related invoices for part. quant. - no zero quantities"
Example: A business process with a partial quantity billing of the delivery quantity that is processed via the selection of the billing document item
In this case, a prorated billing value is set for each billing document with a partial quantity of the total delivery quantity. Following the last partial quantity billing document, the entire billing value is distributed.

For b) Billing document for proof of delivery (POD)
With this business process, the following is intended:
  1. Posting of goods issue for delivery with the entire delivery quantity
  2. Final completion of delivery billing after the first invoice
Example: 
  • A business process with a quantity confirmed by the customer that differs from (is normally less than) the delivery quantity. In this case, the entire billing value is set for the single billing document. Refer also to SAP Note 372772.

372772 - FAQ: How is the cost determined in the billing document?

When creating a billing document, the system can basically determine the goods clearing value from different sources. The possible source documents are listed below according to their priority.
The goods clearing value is always taken from the document with the highest priority.
  1. Vendor invoice (invoice receipt in the MM module)
  2. (Valuated) goods receipt for the purchase order (in the MM module)
  3. Purchase order (in the MM module)
  4. Goods issue for delivery (in the LE module)
  5. Valuation segment in the material master (segment MBEW)
(1)
The first three sources are important for third-party order processing (pure third-party business transaction and individual purchase order); the last two sources are important for delivery-related billing (4) and order-related billing (5).
(2)
In delivery-related billing, the goods clearing value is generally transferred from the goods issue of the delivery. If this value is not available (in case of a billing document BEFORE goods issue, for example), the cost is used.
  • from the valuation segment in the material master (segment MBEW) or
  • -from the sales document 
(3)
In delivery-related billing, the system recognizes third-party order processing only if the billing quantity indicator in the copying control for billing documents is set to 'E' or 'F'. Only then does it read the required documents to be able to extract the goods clearing value from invoice receipt, goods receipt, or purchase order. If the copying control has a different setting for billing documents, only the goods receipt of the delivery or the valuation segment in the material master (segment MBEW) is used as a source.

Solution approaches for quantity differences between billing document and source
Determination of the goods clearing value becomes problematic if the quantity invoiced to the customer, for example, does not correspond to the quantity in the source (the vendor invoice, for example).

After you implement SAP Notes 372760 and 371844, approach 2) ("best-estimated value") is implemented when you create billing documents.
The system response is then as follows:

1. If you create a billing document, the goods clearing value is scaled with the different quantities in the vendor invoices and customer billing documents.
If the customer is billed for five pieces, there is first a vendor invoice for three pieces, then the value from the vendor invoice is projected at five pieces; in other words, multiplied by 5/3.

2. If the quantity flow is not cleared at the end of the business transaction, this approach does not result in the correct result.
You must post-process the costs.
To locate and correct third-party business transactions with a quantity flow that was not cleared, choose the SAP menu path
"Logistics -> Sales and Distribution -> Billing -> Information System -> Worklists" and choose the function "Monitoring Quantity Flow in Third-Party Business Transactions".
Two further options have been added here:
a) If you select the function "VPRS updates", the cost of the billing documents is recalculated according to approach 1) if necessary, which ensures that the total costs are set in the invoices.
b) If you select the TEST function, the system issues only the new and old values without updating the change on the database. (If you want carry out the update, execute the function without this selection).

3. In addition, the report SDVPRSUPDATE provides a general correction report that you can use to postprocess (correct) billing documents with incorrect costs.


VSB1N Self-Billing Proc. Inbound Monitor

VSBTRM Transmission: Self-Billing Procedure w. Autom. Postings


#1 Function IDOC_INPUT_SBWAP
  • CALL FUNCTION 'SD_SBWAP_PRESTEP_LOOP'
  • CALL FUNCTION 'SD_SBWAP_PRESTEP'
  • CALL FUNCTION 'SD_SBWAP_TRM_GET_FROM_DB'
    • VSBPER has to be read before check whether any data is present
  • Establish VSBHDR & VSBITM
    • VSBHDR-PRCTYP
      • 005 Credit memo display /ERS method
      • 006 Retroactive price change/clearing invoice
      • 007 Non-Valuated Goods Receipt (No Processing, Display Only)
  • Fill VSBTRM
    • TRMSTAT
      • A Processing Not Yet Started
      • B Processing in Progress
      • C Processing Finished With Errors
      • D Processing Finished w/o Errors
      • E Processing Scheduled
  • Split: VSBGRH Based on regrouping information in tables VSBGRH and VSBGRI
    • 'External' document split
  • Determine delivery
    • If reference for delivery determination in the header is not filled, all possible references are used; VSBREF
    • LVEDSBWAPF0D/ DELIVERY_DETERMINE_BY_REF
      • Only some references might be used for delivery determination
        • 012 DELIVERY_GENERAL   
        • 009 INVOICE_DIRECT 
        • 061 DELIVERY_DIRECT
        • 062 DELIVERY_VIA_EDL
        • 063 DELIVERY_VIA_LIFEX
        • 081 DELIVERY_TAGESSAMMEL_LFSN
          • get material from the item level
          • DLCN01_READ_DELCON_FOR_SBWAP
            • delconhd & delconco // 6157903. VBELN 0800037090
            • Check for cancellation of FX invoice
        • 082 DELIVERY_MENGENABRUF
    • Determine data of the delivery and invoice
      • CALL FUNCTION 'SD_DATA_FROM_DELBILDOC'


The following statuses prevent the verification step from being executed:
  • 1 - the transfer does not exist
  • 2 - the processing indicator has been set for the transfer
  • 3 - the transfer has been completely processed without errors
  • 5 - the transfer does not contain entries with errors
  • 6 - the transfer does not contain active IDocs

Job SDSBWAPSMS_*

CALL FUNCTION 'SD_SBWAP_MAINSTEP'




Comments

Post a Comment