Each transfer type corresponds to a transfer function (see the separate documentation on the transfer type).
Transfer Time
You can perform billing document transfer at any time after billing. To do this, you must schedule the corresponding transfer functions (programs) to be run in SAP background processing. Billing documents can be edited up to the point at which transfer takes place.
Customizing Settings
y Accounting method for company code; IMG path: SAP Media p Media Sales and Distribution p Periodical Sales and Distribution p Revenue Deferral p General Settings p Definition of Accounting Method for Each Company Code. The definition of the accounting method (for each company code) is a basic setting for revenue deferral. o o In the German accounting method, revenue is only deferrable after billing document transfer. In the Anglo-American accounting method, revenue becomes deferrable once the service (delivery) has been performed regardless of billing document transfer.
Transfer technique. Transfer can be performed using two different techniques: o o Via batch input (by creating and reading batch input sessions) Via the FI/CO interface by direct posting to financials (the FI/CO interface is the standard interface with financials in the SAP R/3 System. If you use the FI/CO interface for data transfer, you can define (summarize) the field list for the FI documents.
IMG paths: SAP Media p General Settings p Activation of FI Interface for Transfer (IS-M/SD) SAP Media p Media Sales and Distribution p Periodical Sales and Distribution p Billing p Transfer of Billing Documents to Financial Accounting p Define FI Document Summarization (for FI/CO Interface).
All the required settings for transferring billing documents to Financial Accounting (define document types for Financial Accounting, maintain document types for billing, assign VAT codes, convert payment methods for collective billing document transfer, define account for VAT differences, define limit amounts for data medium exchange, define posting periods for fiscal year); IMG path: SAP Media p Media Sales and Distribution p Periodical Sales and Distribution p Billing p Transfer of Billing Documents to Financial Accounting. All the necessary settings for transferring revenue to Financial Accounting; IMG path: SAP Media p Media Sales and Distribution p Periodical Sales and Distribution p Revenue Deferral p Data Transfer to Financial Accounting p
The assignment of G/L accounts must be maintained in Customizing for revenue account determination. The first G/L account field (SAKN1) contains the revenue account and the second G/L account field (SAKN2) contains the revenue deferral account. IMG path: SAP Media p Basic Functions p Account Assignment p Account Assignment in Media Sales and Distribution p Revenue Account Determination p Assignment of G/L Accounts.
Revenue Deferral
Revenue deferral takes place during billing document transfer to Financial Accounting or during amortization of orders with a liability account. During revenue deferral, the revenue is first updated in a revenue deferral account and only posted on the due dates. The following types of revenue deferral are possible: y Period-related revenue deferral Revenue for unlimited subscriptions for which billing is performed in advance is deferred to the posting periods. For example, the revenue from a year's subscription is deferred to twelve monthly posting periods. The deferred revenue is posted periodically, e.g. at the end of the month, from the revenue deferral account to the real revenue account. y Revenue deferral per issue Revenue for unlimited subscriptions for which billing is performed in advance is deferred to all the issues in the billing period. For example, the revenue from a year's subscription is deferred to twelve copies. The deferred revenue is posted periodically, e.g. at the end of the month, from the revenue deferral account to the real revenue account. y Service-related revenue deferral with liability account Revenue deferral does not take place during billing document transfer. This revenue deferral type is only relevant for subscriptions with a liability account (renewal or delivery subscriptions). Service-related revenue deferral with a liability account is processed differently according to the accounting method. The revenue is normally deferred at the amortization time of the issue delivered. Exception: If you are using the German accounting method, revenue deferral only takes place at the amortization time if the billing document has been created and transferred. This means revenue deferral is possible at the following times: o o After billing document transfer when using the German accounting method Independently of billing document transfer when using the Anglo-American accounting method
Accounts
Costs and revenue can be posted to the following accounts: y y y y Customer accounts receivable General ledger (for example, a cash clearing account) Revenue Sales deductions
The system automatically posts the amounts to the appropriate accounts by means of Account determination.
Business Area
The system posts these costs and revenue according to the business area. The business area can be equivalent to the: y y Sales area (if the accounts are to be posted according to sales) Plant/division (if the accounts are to be posted according to products)
The reference number can contain the number of the customer business transaction. This number can be used as search criteria for changing or displaying the document. You can print the reference number instead of the accounting document number in all business correspondence. The assignment number provides additional information in the customer line item of the accounting document. The account line items are sorted and displayed according to the assignment number. Any subsequent documents, which relate to the invoice, such as a cancellation document, credit or debit memo, etc., will have the same reference and/or assignment number. In this way the system can view these documents as belonging to a single business transaction. In Customizing for Sales, you can choose from the following to be used as a reference number and an assignment number: y A: Customer purchase order number
y y y y y
B: Sales order number C: Delivery number D: external delivery number E: current billing document number F: External delivery number if available or, if not, the delivery number (used mainly in the component supply industry)
The reference number and the assignment number can be entered as follows: y manually in a sales order Choose Goto p Header p Accounting: Reference field. y automatically in a billing document: o o copied from the sales order automatically determined by the system
Now, you can use the billing type to determine whether 'negative adjustment' is to be carried out for certain billing types. When maintaining the billing type you can set the following in the negative adjustment field: y No entry: no negative adjustment y A: Credit memos/cancellations with ref. to an invoice - negative if the postings are within the same posting period. y B: Credit memos/cancellations with ref. to an invoice - always negative.
The fields VALDT and REBZG are not completed for cleared base value billing documents.
y y
When maintaining the billing type, you can use an indicator to determine whether the customer is copied from business partner payer or sold-to party into field customer in Financial Accounting. The following settings can be made: y No entry: Customer (KUNNR) is payer, branch (FILKD) is sold-to party. The branch is only filled if there are different customer numbers for partner functions sold-to party and payer. y A Customer (KUNNR) is the sold-to party, branch is empty y B Customer (KUNNR) is the payer, branch is empty
s there a way to run VFK3 in background? When I execute the transaction the "execute in background" option is greyed-out. If you would like to run it in background,you have to use the program RVFAKSPE instead of SDBLBDDL. There had been a change of the program used in transaction VFX3 for release 4.5B and afterwards. You can see this in the System -> Status screen. The program used in releases up to 4.5B is RVFAKSPE, in releases after 4.6A it is SDBLBDDL. Report SDBLBDDL can't be used for processing in the background, it is not designed to run as a batch job. You can still process the release to accounting in background processing by creating background jobs for program RVFAKSPE, which is still available. Is there any T.code for finding the billing document was not released to accounting? Please use Tcode VFX3 You can find the same against the following: Sales organization* Mandatory Created by Created on SD document Billing type Billing category While entering the billing document in vf01, you got the following information, how to make it?
The accounting document has not yet been created Message no. VF062 Go to release for accounting. However if it does not create automatically there will be a problem posting to Finance. I would then suggest that you use t code VFX3 to release the billing document to Finance. There is a log in both VF02 and VFX3 that will show what the error is. First thing to do is re-checking the config for revenue account determination. This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc). This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger. The integration is controlled both in SD and in FI. In SD there is a awesome area of configuration called the pricing procedures. The pricing procedure determines the final price quoted to the customer for a particular product. This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition types'. This condition technique is used in a number of areas of SAP. For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys). You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example: - ERF freight revenues - ERL revenues - ERS sales deductions - EVV cash settlement - MWS sales tax Now we start getting to the integration by mapping the account keys to GL accounts. But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet! So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in again. Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )
We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys". The chart of accounts part is standard in all account determinations, so let us look at the rest. This access sequence allows us to specify different GL accounts for different Sales Organisations. Also check the customer master record for account assignment group.
4. Account determination
Now the sales order process is completed. Let's take a closer look at it from the accounting perspective.
The document flow ties together all the documents of the sales process. Put the cursor on the line and click on 'Display document' to open the document.
Accounting documents are created at the goods issue and billing. The text 'not cleared' beside accounting document means that the invoice is not paid. The integration points are following: Sales order: the profit center is determined and copied to the following documents Goods issue: posting to inventory and inventory change accounts. Invoice: posting to revenue account, accounts receivable and tax accounts
The profit center is defined at sales order level. Depending on the system settings the profit center comes either from the material master (View: Sales:General/Plant) according to delivering plant (transaction MM03) or from the Sales order substitution rules defined in profit center accounting (transaction 0KEL). With these rules the profit center can be defined for example according to sales organisation, product or customer characterics. If no profit center is found and COPA is active, the dummy profit center is used. If COPA is not active, the profit center is left empty and you will get an error situation in billing.
A list of created accounting documents is shown. Click on the Accounting document. In this example the goods issue posting looks like this.
The stock posting goes to a balance sheet account and the offsetting posting to inventory change (P&L account). The posting is created automatically at goods issue and the system has to find somewhere all the necessary information for the posting. The accounts used are determined in MM automatic account determination. The account assignments of the offsetting posting depend on the settings. If the account is not defined as a cost element the posting goes to the profit center from the material master. If the account is a cost element, a cost object becomes mandatory. Usually the system looks for it in the CO automatic account assigment table OKB9. In this example the cost assignment is a profitability segmentand the posting rules are defined in COPA IMG.
In the invoice you can find accounting information from several places. There is a direct link to accounting documents. The Accounting button lists all the accountig documents created. From the Environment menu you find Account determination Analysis, which lets you analyze how the account determination is made. On both header and item level you will also find lots of accounting relevant data.
Account assignments The inventory account is a balance sheet account. In Profit center customizing you can define wether you transfer the material stock balance to Profit Center Accounting periodically or online. The profit center always comes from the material master according to the delivering plant (tr. MM03, Sales: General/Plant). The account assigments of the offsetting posting depend on how the account is defined. If the inventory change account is not defined as a cost element, the posting goes to a profit center. Here the profit center is copied from the sales order. It can come from a substitution rule or from the material master. If the account is defined as a cost element, it requires a cost assignment, which can be a cost center, order or profitability segment. As the good issue posting is an automatic posting, the system has to find the assignment automatically. It looks for the assignment in CO automatic account assignment table OKB9. You can also define Automatic assignment to a COPA profitability segment (COPA-IMG: PA transfer structures, tr. KEI2), which is the case here. . Accounts The accounts are defined in MM customizing under Valuation and account assignment. MM account determination is not a 'straight forward -task. SAP has has made Wizard to assist in this. Here I will only show you how to find the configurations for our example.
Start the 'Configure automatic postings under 'Account determination without the Wizard'. If you get a pop up for missing account grouping code, press cancel. CLick the 'Simulation' button.
Enter the plant (1200), material number (R-1180) and movement type 601 Goods issue Delivery. Press enter and then click the Account Assignments button.
On the simulation screen the system combines all the relevant information and shows the accounts it has determined.
The MM account determination is based on transaction technique. In inventory postings there is alwaus the transaction Inventory Posting (BSX). It defines the inventory account, which here is 310000. The system finds this account according to the transaction and valuation class of the material. The transaction for offsetting posting is GBB 'Offsetting entry for inventory'. This transaction has an extra specifications called Account Modification key, which has a different meaning depending on the procedure. The system finds this account according to the transaction, account modification key and valuations class. If you are interested on how the account determination works, SAP Press has published a book about SAP Account determination. In book reviews you find my review of this book.
The accounting document created at SD billing contains typically following three lines: - Customer posting in accounts reveivable and simultaneously posting to reconciliation account in general ledger - Sales revenue posting - Tax posting There can also be other accounts like discounts. Let's study the origin of these postings.
Customer line / reconciliation account The first row in the posting is the customer line. It shows the customer number and makes an open item posting to accounts receivable. At the same time it makes a posting in general ledger to a reconciliation account. Double click the customer line and you can see the reconciliation account. The main rule is, that the reconliliation account comes from the paying customer's master data. For special cases, it is possible to use an alternative reconciliation account. Settings for that can be found in FI and SD customizing. The reconciliation account is a balance sheet account and has no other account assignments. However, you can transfer the posting to a profit center. This does not happen automatically. At period end you must first Calculate Balance Sheet Readjustment in FI closing (tr. F.5D9 and then transfer the postings in profit center accounting (tr. 1KEK). Revenue posting The setting for revenue account are defined in SD customizing.
In spite of the title 'revenue account determination', this is where the settings for all other accounts are made as well. Select option Assign G/L accounts. SD account determination is based on condition techniques. The system reads the conditions sequentially searching for a match. In this IDES case it will find the match on the second level in condition CustomerAccountGroup/AccountKey.
Click on the second row.The table looks baffling, but is really is not that complicated.
In the first column you have the appilication. It is always V, which comes from the german word for sales. Next you have a condition type. There are two alternatives. You choose KOFI, if the posting goes to accounts that in CO are revenue elements (cost element types 11 and 12) and the account assighment is profitablity segment (COPA) or profit center. This is usually the case for revenues and discounts. KOFIK is used if you want to post to an account that is a cost element (type 01) and the account assignment is cost center. In the third column you give the name of your Chart of Accounts. In the fourth column enter the name of the Sales Organisation. In the fift column you give the Account assginment group of the paying customer. Next comes the Account assignment key. This is defined in SD customizing and is in SD pricing assigned to SD conditions like sales price. You don't anywhere define the company code in whose accounting the entry is made. This is determined indirectly via the sales organisation, which is assigned to the company code. The Account assignment groups for customers and materials are defined in SD IMG / Account assignment/costing customizing under 'Check masterdata relevant for account assignment'. Tax posting The tax account determination is not done in SD. The account is taken from FI tax account definitions. The tax account is a balance sheet account and has no account assigments.
You can find this function in Customizing in the Tools Analysis section and in the application menu under Tools Analyze Value Flows. Functions Values in billing documents are assigned to condition types in SD, accounts in FI and value fields in CO-PA. This function shows you a list of the values posted in CO-PA value fields, along with those posted in FI (profit and loss accounts) and SD (condition types). It also shows any differences between the values in CO-PA and SD (Delta CO-PA/SD) and between SD and FI (Delta SD/FI). If there is a difference, you can drill down to the respective billing documents. Statistical condition types (that do not lead to accrual postings) are marked as such and are included in the SD value. This makes it possible to compare the SD value with the CO-PA value. Since these condition types do not lead to FI postings, their values are not taken into account in the comparison between SD and FI. The delta between SD and FI therefore may not be the same as the actual difference between the SD and FI values. List Structure The list is arranged in blocks, each of which contains logically related, hierarchically structured information. Each block typically contains a value field, the condition types assigned to it, and the profit and loss accounts linked to these condition types. If two condition types post to the same account, they appear together with the corresponding value fields and accounts in one block. At the top of this block, you see a separate total for all the values in that block. Accounts that receive postings from more than one condition type are listed separately again at the end of the block. Wherever possible, the system lists a CO-PA value, an SD value and an FI value for each value field, condition type, or account. The goods issue posting for a billing document is assigned to the condition type of the category G (such as condition type VPRS). Condition types of this category are specially marked as such. At the account level below condition types of the category G, you can see the accounts of the goods issue postings, and any categories of billing documents that do not require a goods issue are shown without an FI value. Under Additional condition types you can find the following values: * Condition types that are not assigned to a value field (the corresponding accounts appear under Additional accounts) * Non-statistical conditions that are not posted to an account with cost element type 11 or 12 are not transferred to CO-PA. Under Goods issue, you can see goods issue postings for which the billing document does not contain a condition type of the category G.
For the purposes of reconciliation, two values are shown. These principally cause discrepancies between CO-PA and FI. If you restrict the billing date in the selection screen (for example, to a period),then the following values are displayed: * Goods issue in earlier periods: These are the goods issue values for billing documents that have a billing date falling within the selection interval but for which goods issue precedes the selection interval. These values were therefore posted in CO-PA in the current period but were posted in FI in an earlier period. * Nonbilled goods issue: This applies to goods issue values that, firstly, have a goods issue date falling within the selection interval, but, secondly, that were not billing at the end of the interval (or were not billed at all). These values were therefore posted in FI but not until later in CO-PA, if at all. +/- Signs The signs of the SD values are changed to match those of the CO-PA values so that you can easily compare the values directly with one another. The values for these SD condition types consequently need to have their signs reversed again before they can be compared with the FI values. Any change in sign is shown at each level of the hierarchy with a "+" or "-". In some Customizing constellations it may not be possible to compare two hierarchical levels that lie below the same level.