• No results found

Sap Sd Billing

N/A
N/A
Protected

Academic year: 2021

Share "Sap Sd Billing"

Copied!
236
0
0

Loading.... (view fulltext now)

Full text

(1)

SAP SD ECC 5.0 - Billing

(2)

Billing Document Structure

Basic Functions in Billing

Billing Document Type

Copying Control

Billing Processing

Invoice List

The General Billing Interface

Down Payments for Sales Orders

Installment Plans

Retroactive Billing

Billing Plan

(3)

Billing Document

Definition : Umbrella term for invoices, credit memos, debit memos, pro forma invoices and cancellation documents.

Use: The billing document is created with reference to a preceding document, in order to create an invoice or a credit memo, for example.

Structure: All billing documents have the same structure. They are made up of a document header and any number of items.

(4)

Billing Document Structure

Header Item 1 Item 2 Item 3 Company Max Smith Smithsville J Miller Richville 5 Units type 0815 Rs 3000 4 Units type 0816 Rs 1000

(5)

Billing Document Structure

Header : The header contains the general data that is valid for the entire billing document. This includes:

• Customer number of the payer • Billing date

• Net value of the entire billing document • Document currency

• Terms of payment and incoterms

• Partner numbers, such as the identification number of the sold to party • Pricing Elements

(6)

Billing Document Structure

Items: The items contain the data relevant for each individual item. This includes:

• Material number • Billing quantity

• Net value of the individual item • Weight and volume

• Number of the reference document for the billing document (for example, the number of the delivery on which the billing document is based)

(7)

Billing Document Screens

The data in the billing document can be displayed on different screens. These screens are divided up as follows:

- Overview screens:

- Overviews with header and item data - Detail screens:

- Screens at header level with general data

(8)

Billing

Billing represents the final processing stage for a business transaction in sales and distribution. Information on billing is available at every stage of order processing and delivery processing.

Functions :

• Creation of invoices based on deliveries or services • Issue credit and debit memos

• Pro forma invoices

• Cancel billing transactions

• Comprehensive pricing functions • Issuing rebates

(9)

Basic Functions in Billing

Billing Types Number range Match codes Copying control Blocking reasons Displaying lists

(10)

The billing type controls the whole billing document.

The billing types are used to cover the full range of business transactions during billing processing.

The following is a list of billing types: • F2  Invoice

• F5  Pro forma invoice for sales order • F8  Pro forma invoice for delivery • G2  Credit memo

• L2  Debit memo • RE  Returns

• S1  Cancellation invoice

• S2  Cancellation credit memo • LR  Invoice list

• LG  Credit memo list

(11)

Billing Types

• IV  Intercompany billing (invoice)

• IG  Intercompany billing (credit memo) • BV  Cash sale

(12)

Define Billing Types

Number that determines how documents are to be numbered by the system. It indicates which number range is relevant for a document type

A classification for the different types of

documents that you can process.

(13)

Define Billing Types

To block automatic transfer of the billing

document to accounting, mark the field

A grouping that allows you to control certain features of transaction flow by

sales, shipping and billing documents

(14)

Define Billing Types

Indicates whether the system stores

information from billing documents of this type for the purposes of statistical analysis Used to differentiate the billing documents by requirements for invoice printing, billing document creation and forwarding to FI

(15)

Define Billing Types

The document type classifies accounting documents.

Indicator that causes the transaction figures to be reset for a

(16)

Define Billing Types

The indicator controls which partner functions of the billing document can be forwarded to financial accounting.

Classification that

distinguishes between invoice list types

(17)

Define Billing Types

If this field is set, the reference billing

document is not settled and the payment deadline date for the base billing document comes after the billing date for the credit memo, then field VALDT ( fixed value date) in the credit memo request is filled with the payment deadline date of the

baseline date of the base billing document.

(18)

Define Billing Types

Indicates whether the billing type is used

exclusively during rebate processing

Indicates whether billing documents of this type are relevant during rebate

(19)

Define Billing Types

Specifies the default

cancellation for this billing type

Identifies a copying routine. The routine checks that certain requirements are met when one document is copied into another

(20)

Define Billing Types

The reference number is a piece of additional

information forwarded from SD to FI

You can find the

allocation number under additional information in the (document) line item that is forwarded from SD to FI

(21)

Specific functions can be defined for each billing document type. This is done using control elements that are specified in tables.

The billing document type controls the following elements: • The number range for the document number

• The billing type that can be used to cancel the billing document. • The transfer status of the billing document is

- transferred to financial accounting - blocked from transfer

- not transferred

• The procedure for account assignment in financial accounting

The allowed output for a business transaction and the procedure for output • The partner functions allowed at header level

• The partner functions allowed at item level

(22)

Invoice

Definition:

A sales document used to bill a customer for goods delivery or service. Deliveries and services which are carried out on the basis of sales orders are invoiced to the customer.

If no complaints are made about the delivery, the business transaction is considered complete from the sales point of view.

When you create an invoice, you can refer to an order, a delivery, individual order or delivery item or even partial quantities within an order item or a delivery item. If you want to make sure that the goods are sent out before the invoice is created, you would create an invoice on the basis of the delivery.

If you want to receive money before you send the goods to the customer, you would create an invoice with reference to a sales order.

When you bill a customer for a service, you would probably refer to the sales order, since a service is usually based on an order, not a delivery.

(23)

Billing Type Proposal

In customizing for the item category, you can determine whether billing is to be carried out with reference to a delivery or an order.

The system proposes a relevant billing type from the underlying sales document type. For example, in delivery-related billing, a standard order ( order type OR) is invoiced using billing type F2.

(24)

Delivery-Related Invoices

You can use an invoice to refer to an order and a delivery simultaneously. For example, you create one invoice for goods ( the carpet) and service

(25)

Order-Related Invoices

If you want to invoice a customer for services rendered, normally you create an invoice with reference to the sales order because deliveries are not usually created for services, such as laying a carpet.

(26)

Cancellation

To cancel a billing document, a cancellation document must be created. The

system copies data from the reference document into the cancellation and offsets the entry in Accounting.

The reference document of the billing document (for example, the delivery for the cancelled invoice) can now be billed again.

Credit memos can be cancelled with billing document type S2 in the standard system.

We do not need to make an entry in copying control for cancellations. The parameters to be changed ( for example, assignment number and reference number) are stored per billing type directly in the cancellation area of the screen. We also have the option of canceling individual items in a billing document.

(27)

Credit and Debit Memos

Credit memo:A sales document created on the basis of a customer complaint. This reduces receivables in Financial Accounting.

Debit memo:A sales document created on the basis of a customer complaint. This increases receivables in Financial Accounting.

Use: We need to create credit memos for various reasons (for example, because of defective goods or because we have overcharged a customer)

Similarly, we may need to create a debit memo, if , for example, we have not charged the customer enough.

(28)

Creating a Credit Memo / Debit Memo

Credit and debit memos may be created either with reference to credit or debit

memo requests ( sales documents) or directly with reference to a billing document ( if the company does not require a release procedure in the case of complaints)

We can create credit and debit memo requests:

• Without reference to a previous business transaction • With reference to an order

We can control in customizing whether the system is to set a billing block

automatically for a credit or debit memo request. The employee responsible can: • Release the credit or debit memo request after review. The employee

responsible can decide the amount or quantity to be credited or debited.

(29)

Releasing or Rejecting Credit Memo Requests

We can release a credit memo request or return by removing the billing block. If the complaint has not yet been justified you can enter a reason for rejection for each item.

The value of these items will not be copied into the billing document. Using the reasons for rejection allows you to control whether the item: • Is copied into the credit memo with a zero value

• Appears in the credit memo at all

(30)

Workflow for Credit Memo Requests

Credit memo requests are usually blocked for billing (that is, credit) upon creation until the employee responsible releases this block.

Within the company, we can make the definition of the point at which the check is carried out and the employee responsible dependent upon the value of the credit memo request.

If the value of the credit memo request is below a certain minimum limit, then it can be released automatically by the system.

The workflow within the framework of credit memo processing now guarantees that the employee responsible is automatically determined and informed when a credit memo request is created, depending on the value involved.

The employee responsible can either reject, release, or process the credit memo request.

(31)

Invoice Correction Process Flow

The invoice correction request represents a combination of credit and debit memo requests.

On the one side, credit is granted fully for the incorrect billing item while it is simultaneously debited ( automatically created as a debit memo item). The difference created represents the final full amount to be credited.

The invoice correction request must be created with reference to the corresponding billing document ( no reference to order or enquiry).

When creating an invoice correction request, the items are automatically duplicated ( this means that for every item in the billing document, a second item is created). The resulting item categories must have +/- values.

First all credit memo items are listed, followed by all debit memo items. The reference to the corresponding billing document is created when you specify the preceding document and the preceding item.

(32)

Invoice Correction Process Flow

The credit memo item cannot be changed. The corresponding debit memo item, however, can be updated according to new characteristics ( e.g. new pricing, change in quantity).

We can delete the credit and debit memos in pairs ( unchanged pairs of items can be deleted all at once in this way).

(33)

Quantity Difference

Quantity difference is used when a customer complaint is being processed due to a certain amount of damaged or sub-standard goods.

The system corrects the quantity to be billed via the debit memo item.

If other item pairs arise from the relevant billing document and these item pairs are unchanged, they can be deleted in one step, using the Delete unchanged items function.

(34)

Price Difference

Price difference is used when a customer complaint is being processed for incorrect pricing of goods.

(35)

Returns

We create return for goods sent back from a dissatisfied customer. Returns are processed in the same way as credit memo requests.

The credit memo is billed with reference to the order, which means it refers to the return request document, not to the return delivery.

(36)

Pro Forma Invoices

Definition:

An invoice that is created on paper for exported goods to provide the customs authorities with evidence of the cost of the goods.

When you deal in export, you may need to print pro forma invoices. They are used to give the importer or the responsible authorities in the import country details

about forthcoming shipments.

A pro forma invoice appears exactly the same as a customer invoice. The

difference is that this invoice does not need to be paid. Therefore, the system does not forward data to Financial Accounting (FI). No statistical data is created on the basis of pro forma invoices.

You can create as many pro forma invoices as required, since the billing status in the reference document is not updated.

In copying control, the field Quantity / value pos./ neg. is not available for entry in order to avoid the possibility of a pro forma invoice updating the quantity that has already been billed in the reference document.

(37)

Billing Process

Each billing document requires a reference document ( exception: billing external transactions). This may be :

• Sales document • Outbound delivery • Billing document

When billing explicitly, you must enter the number of the reference document as the transaction to be billed.

You must always refer to an existing document when creating a billing document. Data will then be copied from the reference document to the billing document. For delivery-based billing, the quantities to be billed, for example can be taken from the delivery; the prices, however, are taken from the underlying order.

The reference document is displayed as the source at header level in the copying control table.

(38)

Data Flow

You can, to a certain extent influence the data flow from reference documents to billing documents. This is done using:

• Billing types ( for example, for texts, partners)

• Copying control: the control options are as follows: At header level:

- Foreign trade data - Allocation number - Reference number

- Item number assignment At item value:

- Quantity - Pricing

You can also use data transfer routines to influence the data flow to meet your individual requirements. For example, terms of payment can be copied from the customer master instead of the preceding sales document.

(39)

Data Flow

Example : Delivery –related billing

Order Outbound Delivery Invoice

For example: Payer, Item no., Pricing, texts

For example: ship-to party, amount, texts

(40)

Copying Control

Target Billing type Source Delivery Type

F2 LF

F2 LF TAN Header

Target Source Source Billing Type Delivery Type Item Category

(41)

Copying Control

The system administrator can define how data is transferred in the billing process in the copying control table. Controls are determined for:

• The header ( target: billing type, source: sales document type)

• The item (target: billing type, source: sales document type, item category) The following controls are found at header level:

• Reference document: which documents may be used as reference for billing? • Determination of foreign trade data, allocation numbers, reference numbers, and

(42)

Copying Control at Item Level

The following controls are found at item level:

• Billing quantity: which quantity should be invoiced – the order or delivery quantity ?

• Pricing and exchange rate. Should pricing, for example, be carried out again or should prices from the order be copied over, and at what exchange rate?

• Updating the quantity and value in the reference document

• Where should the conditions in the billing document be carried over from ( for example, copying over shipment costs from the shipment cost document)?

Customizing: Billing -> Billing documents->Maintain copying control for billing documents

(43)

Copying Requirements

Using requirements in copying control, you can specify how a sales document is to be billed with regard to requirements.

You define the copying requirements in copying control. Controlling is carried out in SD Customizing by Billing  Billing Documents  Maintain copying control for

billing documents, Navigation Header and Item, Field Copying requirement

If you want to define a copying requirement as a data transfer routine, enter this in filed VBRK/VBRP. In this way, you can determine whether terms of payment are to be copied from the customer master record instead of the sales document.

With requirements in copying control you can, for example, specify whether goods issue has to be posted before billing can be carried out.

(44)
(45)
(46)

Copying Control

Identifies a copying routine. The routine checks that

certain requirements are met when one document is

(47)

Copying Control

Identifies a routine that checks that certain

requirements are met during the transfer of data from

billing document item fields during copying

(48)

Copying Control

Specifies which quantity the system copies from the source document into the target billing document.

(49)

Billing Quantity

Delivery and order quantities are referenced in billing. You can also take into account the quantity already billed ( depending on the area for which the relevant billing type is used).

This makes it possible, for example, to create an order-related billing document for quantities already delivered.

(50)

Billing Quantity Indicator

When you create an invoice for a standard sales order item, for example, the quantity that the system copies into the invoice is the delivery quantity less the quantity already invoiced. If you create a pro forma invoice, the system copies in the order quantity.

Indicator uses:

• A  Order-related billing • B  Delivery related billing

• C and D  Pro-forma invoices

• E, F and I  Third party business transaction • G and H  Batches

• Note: Make sure that control of the amount to be billed is directly related to the item category billing relevance.

(51)

Billing Quantity

Billing document Billing quantity

Based on an order Order quantity minus quantity (e.g. standard order) already billed

Quantity already delivered minus quantity already billed

Based on a credit Order quantity minus quantity

memo request already billed

Based on a delivery Quantity already delivered minus (e.g. billing types quantity already billed

F1 and F2)

Pro forma invoice F5 Order quantity Pro forma invoice F8 Delivery quantity

(52)

Copying Control

Indicates whether, during copying, the quantity or value in the target document has a negative effect, positive effect or no effect at all on the quantity still to be completed in the source document.

(53)

Pos./neg. Quantity

Use

The system uses this indicator to determine how the quantity in the source

document is affected. For example, if you create a quotation item for 100 pieces, copy the quotation into a sales order and create a sales order item for 80 pieces, the copying has a positive effect on the quotation. In effect, you have added 80 pieces to the quotation quantity that is now considered complete. 20 pieces in the quotation remain to be completed.

If you do not make an entry in this field, or set indicator 0, the source document is not blocked, which allows you to create several target documents at once ( for example when using EDI and frequent contract releases).

While the source document ( such as quotation or quantity contract ) is being

processed, it is blocked. For instance, if you are working on a quantity contract, no one can create a release order for that contract.

(54)

Pos./neg. Quantity

In sales documents, for example, you can expect the following results: • Quotation  Sales order : Positive

• Contract  Return : Negative

• Sales order  Sales order : No effect

In billing documents, for example, you can expect the following results: • Delivery  Invoice : Positive

(55)

Pricing in the Billing Document

When a sales document is created, the system automatically carries out pricing. During billing you have the option to copy the prices from the sales document to the billing document or to have the system carry out pricing again. You can also trigger pricing manually.

(56)

Copying Control

Specifies how the system treats pricing data when copying documents.

(57)

Pricing Types

At the time of billing, the following possible pricing types may be set for the items:

A: The pricing elements are copied from the reference document and updated according to a scale.

B: Carry out new pricing

C: The manual pricing elements are copied, and pricing is carried out again for the others.

D: The pricing elements are copied unchanged from the reference document. E: Copy pricing elements and values unchanged

F: Only used within the program

G: The pricing elements are copied unchanged from the reference document. The tax conditions are re-determined.

H: The pricing elements are copied unchanged from the reference document. The freight is re-determined.

(58)
(59)

Copying Control

(60)

Pricing Exchange Rate

Options in Pricing Exchange Rate are : A  Copy from sales order

B  Price exchange rate = Accounting rate

C  Exchange rate determination according to billing date D  Exchange rate determination according to pricing date E  Exchange rate determination according to current date

F  Exchange rate determination according to date of services rendered

(61)

Copying Control

This field controls from where and in what sequence the conditions from the reference documents are copied to the billing

(62)

Price Source

Price Source Description

Blank  Order

A  Purchase Order

B  Purchase order / delivery

C  Not used

D  Delivery

E  Delivery / order

F  Shipment costs

(63)

Billing Processing

During billing processing, you create, change and delete billing documents. You can create billing documents:

• With reference to a sales document • With reference to a delivery order

• With reference to external transactions

You can refer to an entire document, individual items or partial quantities of items. You can create billing documents in the following ways:

• By having the system process a billing due list automatically as a background task

• By processing manually from a worklist • By creating a billing document explicitly

(64)

Processing Billing Due Lists

You will not usually bill transactions individually. You are far more likely to carry out periodic collective billing runs ( by goods issue posting, for example).

If you are working with the billing due list, enter the selection criteria ( such as sold-to party, billing date, and destination country). The system uses the selection

criteria as a basis for combining the transactions to be billed.

When selecting, you can also decide whether the billing due list should only contain documents that are order-related, delivery-related, or both.

After saving, you can display the log to determine which billing documents were created from a billing due list and whether any errors occurred.

You can process the billing due list in simulation mode. The system displays the billing documents without saving the documents. Transactions containing errors are indicated with the corresponding processing status.

(65)
(66)

Creating Invoices on Specific Dates

You can process invoices periodically. All deliveries due for billing on a certain date can be combined into one collective invoice.

To do this, you must first :

• Maintain Individual billing dates in the factory calendar using special rules

• Enter the factory calendar in the customer master record of the payer ( Invoicing

Dates on the Billing document screen).

• When you enter a document, the system copies the next invoice date from the factory calendar to the appropriate document as the billing document.

(67)

Billing in the Background

You may decide to create invoices using a background job because it is practical and efficient. You can run the background job automatically in the following ways: • Periodically ( for example, every Monday at 2 a.m.)

• At a specific time ( for example, June 19 at 8p.m.)

The system can divide the billing due list into multiple background jobs and start them simultaneously. In this way, you can make better use of your hardware by operating more than one processor.

If you do not require a log or a detailed list, SAP recommends that you do not select these options in the selection screen. This will improve performance considerably.

(68)
(69)

Cancellation of Collective Billing Run

The system contains functions to enable you to cancel the collective billing run. This cancels all the billing documents in a collective run. The cancelled billing documents are combined under a collective processing number in collective processing type S and can be displayed under billing document  Log.

You can then bill the preceding documents for the cancelled billing document again.

Only users with the correct authorization can cancel collective runs. In order to cancel the collective billing run, choose :

Billing  Information system  Billing document  Log of collective run 

(70)
(71)

Transaction Codes in Billing Document

VF01  Create billing document VF02  Change billing document VF03  Display billing document

VF07  Display from archive billing document VF11  Cancel billing document

VF04  Process billing due list

VF06  Creating background jobs for billing VFRB  Retrobilling

(72)

Methods in Billing

The following methods may be used in billing:

• One individual billing document per sales document

• A collective billing document for several sales documents

(73)
(74)

Individual Billing Documents

Settings for Individual Billing Documents

Copying control is carried out in SD Customizing via Billing> Billing Documents ->Maintain copying control for billing documents, Navigation Item, field:

VBRK/VBRP. In this field you select data transfer routine 3

(75)
(76)

Collective Billing Documents

It is possible to include both order-related and delivery-related items in the same billing document.

The following prerequisites must be met for collective billing document: • The header data appearing in the billing document must agree.

• The split conditions specified do not apply.

• The system behaves differently for the functions Billing Due List and Create Billing Document.

(77)
(78)

Invoice Split

In customizing for copy control, you can specify requirements for splitting to prevent sales orders or deliveries being combined into a collective billing document.

As a rule, the system combines into one billing document all transactions for the same customer, default billing date and sales organization.

If data from the related reference documents differs in the header fields of the billing document, the system will automatically split the invoice.

An order contains terms of payment at header as well as item level. These are stored at header level in the billing document. However, if there are different terms of payment in the reference documents, an invoice split will always be made.

If data from the related reference documents differs in the item fields of the billing document the system does not split the invoice.

(79)

Invoice Split

The order basis is stored at the header level in the order and at item level in the billing document. The system does not split the invoice. If you require an invoice split, you must first define the appropriate splitting requirements in Customizing for copying control.

Copying control depends on the following criteria:

• Reference document type (i.e. type of order, delivery or billing document on which the sales document is based)

• Billing document type

(80)

Item-Dependent Invoice Split

The system administrator can also define additional split requirements in Customizing for copying control to prevent the system from combining sales documents in a billing document.

Example: Separation based on material group or profit center.

Field VBRK-ZUKRI is used in the billing header to store these additional split criteria.

(81)

Performing a Split Analysis

You can use split analysis to review why the system has split a billing document. It compares two billing documents and lists the fields which have differing contents. You can call up the Split analysis function with the following transactions:

Billing document -> Change or display Billing document -> Billing due list

To display the split analysis for one of these screens, proceed as follows: Enter the number of the billing document that you wish to compare.

Choose Environment -> Split Analysis

Enter the number of the second billing document which you wish to compare to the first in the dialog box.

Enter the billing document number and choose Continue.

The system displays the split analysis log. It is made up of three parts. The first shows the header partners and header fields which are different in the two

documents while the second and third columns show the respective values for these fields.

(82)
(83)

Invoice List

The invoice list lets you create, at specified time intervals or on specific dates, a list of billing documents (invoices, credit and debit memos) to send to a particular

payer.

The billing documents in the invoice list can be single or collective documents ( collective invoices combine items from more than one delivery).

The standard version of the SAP R/3 system includes two types of invoice lists: • For invoices and debit memos  LR

• For credit memos  LG

If you wish you can process invoices, debit memos and credit memos at the same time. The system automatically creates a separate invoice list for credit memos.

(84)

Invoice List

(85)

Invoice List

A payer may be the head office of a buying group, which pays all the invoices for goods that are shipped to individual members.

The group payer takes responsibility for paying the invoice lists and the collecting payment from the individual members. In return for these services, the group payer usually earns a factoring discount.

Prerequisites for invoice lists

If you have agreed upon a factoring discount, condition type RL00 ( factoring discount) must be maintained and if required also the condition type MW15.

An invoice list type must be assigned to each billing type that you want to process in invoice lists.

Copying requirements must be defined ( for example, the payer, terms of payment and other fields that must be identical in the documents to be included in the

(86)

Invoice List

In addition, before you process an invoice list, you must maintain the following master data.

• A customer calendar must be defined, specifying the time intervals or dates on which invoice lists are to be created. This factory calendar is to be entered in the payer customer master record. ( Billing screen, Invoice list schedule field)

• Maintain condition records for condition type RL00 for the payer.

• Create output condition records for condition types LR00 and RD01. ( you can determine whether invoice papers are to be sent to the customer upon invoice creation or only when the invoice list has been created).

(87)

Changing Header and Item Data in Invoice List

You can change some of the header data – for example, the billing date - when you process the invoice list.

You can change an item – either an individual or collective invoice – and display document details.

However, you cannot change any data in individual billing documents once they are part of an invoice list.

(88)

Creating an Invoice List

To create an invoice list 1) Select the Billing screen

Depending on the number of billing documents that you want to include, you can choose one of two ways to create the invoice list. You can either

• Select invoice list Create and enter each billing document separately

• Create a list of all billing documents that are relevant for the invoice list. You can then process the work list for invoice lists.

This procedure shows you how to create the work list. 2) Select Invoice List  Edit Work List

3) Enter your selection criteria and press ENTER

The system displays a list of billing documents that meet your selection criteria.

4) Select the billing documents that you want to include in the invoice list and select Invoice List  Save

(89)

Creating an Invoice List

You can also simulate creation of invoice lists via the work list for invoice lists. This is useful as a test option. The simulation also allows you to carry a split analysis, which show you why billing documents are written to different invoice lists (e.g. due to different payers)

(90)
(91)
(92)

Transaction Codes in Invoice List

VF21  Create invoice list VF22  Change invoice list VF23  Display invoice list

VF27  Display from archive invoice list VF26  Cancel invoice list

(93)

Customizing for Invoice List

Assign Invoice List Type To Each Billing Type Maintain Conditions for Invoice Lists

(94)
(95)

Maintain Conditions for Invoice Lists

Create Condition Tables Maintain access sequences Maintain pricing procedures Define condition types

(96)
(97)
(98)
(99)
(100)

Maintain Output for Invoice Lists

Maintain output condition tables for billing documents Maintain access sequences

Maintain output determination procedures Output types

Two new output determination procedures have been created for determining output in invoice lists:

• V30000 - Invoice list output

(101)
(102)
(103)
(104)
(105)

General Billing Interface

Using the general billing interface, you can invoice external documents in the SAP R/3 system ( that is, order and deliveries not created in the R/3 system).

To do this, you must first:

• Prepare the data in a sequential file of specified format

• Specify a minimum number of required fields to be filled from the data records. • Specify the remaining fields required for billing either through the data records for

the sequential file or through the R/3 system ( optional fields) Examples:

Required fields : Customer master, sales organization, … Optional fields : Material master, price components, …

(106)

General Billing Interface

External reference numbers can be entered in the interface ( such as external

delivery numbers or external order numbers). When you create a billing document, the system records document flow using these reference numbers

You may decide to work with a CpD customer master record instead of taking data (such as an address) from a customer master.

Pricing elements and /or VAT amounts can be transferred. Alternatively, you can carry out new pricing in billing, entirely or only for taxes.

(107)

Working with the General Billing Interface

The communication structure of the general billing interface distinguishes the following fields during the transfer of data from an external system.

Required fields which must be transferred.

Optional fields, which may be transferred, or fields which are determined from available master data in the system during the billing document run.

(108)

Extracting Data from an External System

Billing data from an external system must be prepared in a sequential file which must fulfill the following requirements:

Sequential file structure

Record

1st main record (Billing data)

Data : Indicator A in first position

Structure as of 2nd position analogue communication structure KOMFKGN

1st – nth secondary record (Pricing element)

Data : Indicator B in first position

Structure as of 2nd position analogue communication structure KOMFKGN

The client in the secondary record (MANDT) must correspond to the client in the main record (MANDT)

(109)

Extracting Data from an External System

The document condition record in the secondary record (KNUMV) must correspond to the document number of reference document in the main record (VGBEL)

The condition item number (KPOSN) must correspond to the item number of the reference business transaction item in the main record (VGPOS)

Sorting main records in the sequential file according to: • Sales Organization : VKORG

• Distribution Channel : VTWEG • Sold to party : KUNAG

• Document number of the reference document: VGBEL • Item number of the reference item : VGPOS

(110)

Extracting Data from an External System

Processing errors:

You can carry out a check run with sample report RVAFSS00 to display faulty

records in the sequential file before final billing. All errors are displayed in error log. After correcting the faulty records in the sequential file, you must restart the billing procedure. The system ignores records which have already been billed and

creates billing document for records which have been corrected. Optionally, a list of new billing documents is presented with the error log.

(111)

Communication Structures

Use

Sample report RVAFSS00 supplies communication structures XKOMFGN and XKOMFKKO with data from the sequential file and initiates the billing process. The following fields in the sequential file‟s main record must be maintained. Field Name Field Length Field Description

MANDT  3  Client

AUART  4  Sales document type

VKORG  4  Sales organization

VTWEG  2  Distribution channel

SPART  2  Division

FKDAT  8  Billing data

KUNAG  10  Sold-to party

WERKS  4  Plant or

(112)

Communication Structures

Field Name Field Length Field Description

PSTYV  4  Item category

KWMENG  8  Cumulative order quantity

The following fields do not have to be maintained but it is recommended that you do so as it gives information on document flow.

VGBEL 10 Document no. of the reference document

VGPOS 6 Item number

If you are also transferring pricing elements, you must maintain the following fields in the sequential file‟s secondary record:

Field name Field length Field description

MANDT  3  Client in main record

KNUMV  10  VGBEL in main record

KPOSN  6  VGPOS in main record

KSCHL  4  Condition type

(113)

Communication Structures

All the fields in both communication structures KOMFKGN and KOMFKKO are optional. You may fill them with data from the system as necessary during the billing run ( the payer field, for example).

Once the communication structures have been maintained, the system initiates billing with function module GN_INVOICE_CREATE

(114)

Text Transfer

Texts (header and item) can be transferred in the general billing interface. You can use the test report RVAFSS01 to write text information in a flat file.

The report RVAFSSS00 imports a flat file and completes the interface tables for the program N_INVOICE_CREATE depending on the record type. This program is

then called up.

Record type Interface table Purpose

A  XKOMFKGN  Item data

B  XKOMFKKO  Condition data

(115)

Text Transfer

The interface table has the structure XKOMFKTX

Component Component type

MANDT  MANDT VGBEL  VGBEL VGPOS  VGPOS TDOBJECT  TDOBJECT TDID  TDID TDSPRAS  SPRAS TDFORMAT  TDFORMAT TDLINE  TDLINE

(116)

Text Transfer

Texts are only transferred into the billing document if the following are completed: VGBEL or VGBEL/VGPOS

TDOBJECT ( as a rule TDOBJECT = „VBBK‟ or „VBBP‟) TDID

If only VGBEL is complete, this is a header text. If VGBEL/VGPOS is complete, this is an item text.

(117)

Reading the Material Master

If the NO_MARA field in the main record of the sequential file is marked, the

material master will not be read. In this case, the following additional fields in the main record must also be maintained.

Field name Field length Field description

VRKME  3  Sales unit

WAERK  5  Currency

ARKTX  40  Material-short text TAXM1  1  Material-tax indicator

(118)

Customizing

The following parameters should be taken into consideration: • Billing Document Type

• Use billing document type FX for billing external transactions or create your own. • Control of Document Flow

• If you wish to take into account secondary records copied to the sequential file, maintain one of the following pricing types in Customizing under „Copying control for billing documents‟:

Pricing type Description

D  Copy pricing elements unchanged

G  Copy pricing elements unchanged, re-determine tax

C  Copy manual pricing element unchanged, re-determine all others

You may also copy a scale quantity (XKOMFGEN-SMENG) from the interface with pricing type B (new pricing)

(119)

Customizing

Condition types

Condition types that are transferred into secondary records must be set up so that the manual value has priority (manual entry = C).

Pricing procedure

To prevent the material master from being read, make sure that no conditions which initiate reading of the material master are set in the pricing procedure ( for instance, costs – VPRS).

Copying control

Copy control 013 in copying control for billing documents at item category level ensures that the customer master block is observed and that records having a billing quantity of 0 are ignored.

Item category

Item categories used in external business transactions must be relevant for pricing and billing.

(120)

Function Module Parameter

Function module GN_INVOICE-CREATE is the main component of the general billing interface.

The system immediately initiates posting when you enter A and B in import parameter WITH_POSTING. Among other things, this function module returns values from the following tables:

Table number Table name

XVBFS  Error logs

XVBSS  Collective processing number XVBRK  Billing documents

XVBRP  Billing items

(121)

Processing one-time customers

Use

You must work with a CpD customer master record if customer master data (such as an address) can not be used.

If you are using a data extract in the billing interface to transfer CpD customer data, address data must exist in this data extract. Maintain the following fields in the

main record of the sequential file.

Field name Field length Field description

Land1  3  Country key

Name1  35  Name 1

PSTLZ  10  Zip code

(122)

Processing one-time customers

Address data transferred to the file is assigned to the partner functions (except for SP) described in the following fields.

Field name Partner function – Example

CPD_PARVW1  BP (Bill-to party)

CPD_PARVW2  PY (Payer)

CPD_PARVW3  SH (Ship-to party) CPD_PARVW4

Exception:

Partner function SP ( Sold-to party) must be a CpD customer and is always transferred with the transferred CpD address data.

(123)

Processing one-time customers

In addition to required fields, the following fields in table structure KOMFKGN are available for CpD customer processing.

Field name Field length Field description

ANRED  15  Form of address

NAME2  35  Name 2

ORT02  35  District

STRAS  35  Street and house number

REGIO  3  Region

You can add additional fields to table structure SADR in INCLUDE structure KOMFKZZ if the fields in table structure KOMFKGN are not sufficient for processing CpD customers.

(124)

Down Payments for Sales Orders

Purpose

Normally, down payment agreements are made for producing and delivering goods to customers in the capital goods, or plant engineering and construction industries. Down payments are payments made before completion of the product, with no interest. They represent short or medium term outside capital procurement and therefore improve the company‟s liquidity situation.

(125)

Down Payments for Sales Orders

Features

Down payments form part of the agreement with the customer and are saved in the sales order.

A down payment agreement is created as a deadline in the billing plan. This

enables you to carry on as many down payments as required for different dates. The date for the down payment yet to be created is specified in the deadline, and the system uses payment conditions to assign a due date to the down payment, The value of the agreed down payment can be entered either as a fixed amount or as a percentage of the value of the item.

If a down payment agreement is assigned to one item with a billing plan, the down payment agreement is contained as a deadline in this billing plan.

Down payment agreement can be used only for order-related billing and not for delivery-related billing.

(126)

Customizing for Down Payment Processing

Settings for the billing plan

To activate the billing plan function, maintain the materials, for which you wish to process down payments, with item category group 0005 (milestone billing). This gives the item category TAO via item category determination. The item category TAO calls up the billing plan function.

You need to implement the following activities in the billing plan for down payments:

• Maintain the deadline type. This determines the billing rule (percentage or value down payment) for the down payment request.

• The system assigns billing type FAZ ( payment request) defined in the standard system with billing category P. ( For the billing type FAZ there is the cancellation billing document type FAS in the system).

• Maintaining deadline proposal. Use down payments that are due for the proposed deadlines.

(127)

Maintaining a pricing procedure with the condition type

AZWR

In the standard system, the condition type AZWR is delivered for the down payment value already provided but which has not been calculated. You must include this condition type in the relevant pricing procedure before output tax.

Enter condition 2 (item with pricing) and the calculation formula 48 (down payment clearing value must not be bigger than the item value) for the condition type AZWR. Before the condition AZWR you can create a subtotal with the base value

calculation formula 2 ( net value). If the condition AZWR is changed manually, you can get information on the original proposal from the subtotal.

Maintain the printing indicator.

The pricing procedure cannot be marked as a transaction-specific pricing procedure ( field Spec. proc.)

The condition type AZWR has the calculation type B (fixed amount) and the condition category E (down payment request / clearing).

(128)

Maintaining the Billing Document

In the standard system there is the billing type FAZ ( down payment request) and for canceling the billing type FAS.

Controlling the down payment is done using the billing category P of the billing

type. A billing type becomes a down payment request when the billing category P is assigned.

You have to maintain blocking reason 02 (complete confirmation missing) for the billing documents and assign it to billing type FAZ.

Copying control:

Copying requirement 20 must be entered in copying control at item level for the down payment request. In the standard system the order type OR for copying control is set up according to the billing type FAZ for the item category TAO. Copying control 23 must be entered in copying control at item level for down

payment clearing. In the standard system the order OR for copying control is set up according to the billing type F2 for the item category TAO.

(129)

Down Payment Request

(130)

Financial Account Settings for Down Payment

A prerequisite for down payment processing is that the account is assigned to the underlying sales account. To do this, change the field status settings in

customizing as follows:

Set reconciliation accounts (transaction OBXR)

For the received down payments and down payment requests from the G/L accounts you have selected, you should assign the field status definition G031. Maintain accounting configuration (transaction OBXB)

For the down payments (posting key ANZ in the standard system) and the output tax clearing (posting key MVA in the standard system), you must maintain the posting key.

You must also carry out a G/L account number assignment for the tax account.

Maintain the posting key (transaction OB41)

(131)

Financial Account Settings for Down Payment

Maintain the field status definition (transaction OB14)

For field status variant 0001, field status group G031, set the sales order as an optional field.

(132)

Down Payment Agreements in the Sales Order

Control for Down Payment Agreement is carried out via the billing rule: • Billing rule 4 : Down payment for percentage milestone billing

• Billing rule 5: Down payment for value milestone billing,

For percentage milestone billing, the percentage share of the down payment is not included in the overall calculation of the individual milestone billing documents.

The percentage specified for the down payment is always based on the total sum of the individual milestone billing documents.

As soon as you take away the billing block and save the sales order, a billing index is created for the individual dates.

(133)
(134)

Down Payment Request

A down payment request is sent to the customer in time for the deadline. The

request can be generated by the system from the billing due list, or you can enter it manually. The down payment request is posted as such to Financial Accounting. Billing type FAZ is used for creating the down payment request.

Tax is determined and displayed automatically when the down payment request is created.

The down payment request in FI is created automatically from the down payment request in SD.

You can view the down payment requests created in SD and FI via the document flow in the sales order.

(135)

Down Payment Request

When transferring into FI (financial accounting) a down payment requirement is created as a noted item in „down payment requirement‟ account in financial

accounting. The account „down payment requirement‟ has no effect on the balance sheet or the profit and loss account.

You can see the created down payment requests in the document flow for the sales order.

You can print out the down payment requirement and send it. To print out you do not need an extra printing program or form. You just use RVADIN01 which is set up for billing documents in the standard system with the form RVINVOICE01. The following information is also given for down payment requests:

• „Down payment request‟ appears in the billing header. • The total is labeled as „payment to be made‟.

(136)
(137)
(138)

Down Payment Processing in SD/FI

The down payment request (SD) is automatically posted in Financial Accounting (FI) as a down payment request ( posted as a noted item). The item has special General Ledger (G/L) indicator F, which ensures that posting is statistical. Posting is made to a different reconciliation account, which allows you to differentiate down payment requests from other receivables.

When posting an incoming payment for a down payment, the incoming payment is assigned to the down payment request. The down paid amount is also account assigned for the sales order. The item has special G/L indicator A.

When processing partial / final invoices, the down payments made are transferred as down payments to be cleared. Within FI, the down payments are deducted from the special reconciliation account and entered in the standard reconciliation

account. The down payments for clearing then appear as open items for the customer and reduce the total of receivables.

(139)

Payments Made

The customer makes the payment. The incoming payment is posted in financial accounting with reference to the payment request. In this transaction the down payment request is labeled as cleared. The clearing can also be seen in the sales order document flow.

The noted items in the customer account which were generated by the down payment requests become cleared posts.

The payment request is determined by assigning the down payment request to the sales order item.

If the customer only pays part of the amount required, the down payment request will be cleared completely nevertheless. Later down payments must therefore be assigned manually to the sales order and the corresponding sales order item.

You can view the down payments in the open items of accounts receivable under the special G/L indicator A.

(140)

Milestone Billing with Down Payment Clearing

The billing plan for the sales order contains billing-relevant deadlines. As soon as you take away the billing block, you can carry out billing.

In billing those payments already made by the customer should be cleared. This happens because those payments already made are taken into the billing

document as items to be cleared. They are set as items, after the billing items to which they refer, in the billing document. When printing ( Report RVADIN01 with form RVINVOICE01) the customer receives for the down payment items the text „payments made‟ printed out. The down payment item value corresponds to those down payments made.

There is no billing. Billing amount – Down payment amount = the remaining amount to be paid. The customer merely receives the information concerning which amount he can transport during payment.

(141)

Milestone Billing with Down Payment Clearing

You can change proposed down payment for clearing manually. The reason for this can be that part of the down payment should be proposed for further billing. Calculation formula 48 in the pricing procedure for the condition type AZWR merely checks that the amount cannot be increased.

The down payments assigned to a billing document for clearing cause the system to offset all the completed payments against receivables in Financial Accounting (FI).

The total payment of the final invoice is automatically posted in FI as a receivable, and the allotted down payments are cleared directly (down payment clearing). The transaction is finished with the incoming payment posting and the open items are cleared. Postings made to the relevant general ledger account in Financial

(142)
(143)

Milestone Billing with Down Payment Clearing

In the above example, the system had originally proposed 40,000 (item 11) and 20,000 (item 12). The down payment clearings were then manually reduced. The customer is then asked to take the down payments ( 30000 + 10000) from the total amount 60000. For the example there is 20000 left to pay. The remaining down payments are then processed in the final invoice. ( see next slide)

(144)
(145)
(146)
(147)

Milestone Billing with Down Payment Clearing

In the above only those items still open are shown ( those down payments not yet cleared) due to the overview given by the customer account. That is, both lines 21/1 and 21/2 each with 10000.

The customer is therefore asked to take the 20000 that have not yet been cleared from the 90000 due and to pay 70000.

(148)

Installment Plans

Billing doc. 4713 Value: Rs 300 Payment Terms: R001 1st installment : Rs 100 2nd Installment: Rs 100 3rd Installment: Rs 100 Invoice 4713 Total amount Rs 300

1. Install.: due May 1 Rs 100 2. Install. : due June 1 Rs 100

Accounting document Company code: 1000 ---Customer 1.Inst. Rs 100 2. Inst. Rs 100 3. Inst. Rs 100 Revenues: Rs 300

(149)

Installment Plans

An installment plan allows the customer to pay in installments. Only one billing document is created for all of the installment payments. The printed invoice is created on the basis of this billing document and includes a list of individual payment dates and exact amounts.

Each installment payment creates an accounts receivable line item posting in FI. You must define installment payment terms in customizing.

The installments are defined by the payment terms, which are controlled by the payment terms key. The following data is to be defined:

• The number of installments • The payment dates

(150)

Installment Plans

You can store the default payment terms key in the customer master record (on the

Billing Sales Area screen, field : payment terms).

You can overwrite the payment terms key in the sales order header or item ( menu path Header or Item --> Business Data, field Payment terms)

You can use the payment terms key to print a suitable text on the order confirmation.

(151)

Cash on Delivery

Purpose

The customer orders from you. Transportation of the goods is carried out by a forwarding agency, for example, by post. The goods are delivered to the customer with an invoice and the customer pays upon delivery.

Prerequisites

Triggering Cash on Delivery

You enter the forwarding agent as the payer in order entry and this ensures that the forwarding agent is determined as a selection criterion for shipping.

Determining the forwarding agent from the payer can be set in Customizing for partner determination. If, however, you want to use different determination of the forwarding agent, e.g. via the sold-to party, then you need to create a new partner type as forwarding agent for cash on delivery.

(152)

Cash on Delivery

Standard conditions for pricing

NAPG: Package fee (absolute amount; weight scale, group condition)

The forwarding agent demands this from the goods vendor and reimburses it upon payment by the customer.

NANG : Cash on delivery fee ( absolute amount; weight scale, group condition) The forwarding agent demands this from the goods vendor and reimburses it upon payment by the customer.

NAUE : Bank transfer fee

The post office demands this from the customer upon payment.

Access Sequence:

(153)

Cash on Delivery

Output Invoice Packaging slip Payment slip Process Flow Order Entry

You trigger the cash on delivery transaction by entering the post office as the payer. When you enter the order, the system then determines the same forwarding agent from the selection criteria in shipping.

When you change the order, it is not possible to redetermine the forwarding agent automatically. You must then enter the forwarding agent manually in addition to the payer.

References

Related documents

• SPM buoy complete with PLEM, anchor piles, mooring cables and chain and hoses Installation of sheet piles for protection of the beach at the pipeline landfalls and their

Best to st malo ferry tickets to break from weymouth at this in brittany ferries weymouth, shop and guernsey or perhaps browse the city a week.. Suggests spare capacity but the st

Finally, in order to always respect the power factor restriction (0.9 leading to 0.9 lagging according to the Connection Agreement), the reactive power

(It is quite small but don’t worry it’s there). They have the choice of picking a home win, draw or away win and their predictions are tallied and are displayed like the

The results showed that the specimen groups with the highest calcium alginate concentrations (including the control specimens with embedded alginate beads but no bacteria) resulted

Keeps all official records of Board activities (minutes of proceedings, resolutions, etc.), including those of Board Committees, as directed by the Board; ensures they are

Drawing on a rich administrative dataset of 401(k) plans containing information on plan borrowing and loan defaults, we demonstrate that retirement account loans are quite common,

annum in Edinburgh annum in Edinburgh Referral sources: Referral sources: Hospital Discharges Hospital Discharges - - MDTs MDTs Community Rehabilitation Service