What is the difference between credit memo request and credit note and can we see the credit

note in the system? Credit memo request will be created when you have to pay to the customer. (excess bill or damages or change in the price). Credit memo request is a Sales document type (VA01), based on this you will create credit memo (VF01). While creating the credit memo you will get a block which will be removed by an authorised person set. The credit memo can be seen with transaction VF03 and credit memo request with VA03. Credit memo request is a sales document used in complaints processing to request a credit memo for a customer. If the price calculated for the customer is too high, for example, because the wrong scale prices were used or a discount was forgotten, you can create a credit memo request. The credit memo request is blocked for further processing so that it can be checked. If the request is approved, you can remove the block. The system uses the credit memo request to create a credit memo. You can use credit memos in Sales and Distribution (SD) for assigning credit memo requests to the open invoices and in Financial Accounting (FI) for assigning credit memos and payments to the open invoices and carry out clearing with them. If you use both Financial Accounting (FI) and Sales and Distribution (SD), there is a 1:1 relationship between the credit memo request and the credit memo item posted in Financial Accounting (FI). As soon as you bill the credit memo request together with other sales orders, or distribute the items of one credit memo request to several billing documents, the assignment is no longer valid and the system will not process it. For credit memos, credit memo requests, and payments, you have the following assignment options:

Assignment to a single invoice Assignment of a partial amount to an invoice

Assignment to several invoices

When you post credit memos, the payment programmed processes them automatically. If the credit memo is specifically related to a particular open invoice item, the payment program automatically attempts to offset the credit memo against the open item. If it is not possible to completely offset the credit memo against an invoice, you can post a debit memo to the vendor, who is to reimburse the amount. Then you can apply a multilevel dunning program. Credit Memo Based On Return Delivery I have sales return scenario where I want to make credit memo based on return delivery. What are the steps and settings for copy control for creating credit memo in VF01 with return delivery Vl01n Credit memo in Return always refers to the Return order NOT to the Return delivery. So create the Credit memo with reference to the Return order, there will be no error, but before that ensure that you have released the block from the Return order. First copy billing type from G2 (T-code VOFA) and that copied billing Type maintain in sales document type (T-code VOV8) in for delivery related billing.

Posted byDoeat2:10 PM0 comments Release Billing Documents to Accounting

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

Posted byDoeat2:10 PM0 comments Configuring Intercompany Billing

How to configure Inter Company Billing by: Mamta Singh INTERCOMPANY BILLING Business case: - Customer orders goods to company code/Sales organization A (Eg.4211/4211). Sales org 4211 will accept and punch the order in the system with sold to party as end customer code in the system. Company code/sales org B (Eg.4436) will deliver the goods to end customer and raise an inter-company billing on 4211 with reference to delivery. This can happen only after 4211 raises invoice to his end customer to whom the material has been delivered by 4436. SPRO Customization required:1. Assign plant of delivering company code (Eg.SI81) to sales org/distribution channel combination of ordering company code (Eg.4211/RT) 2. Maintain intercom any billing type as IV for sales document type OR 3. Assign Organizational Units By Plant (Eg.SI81/4211/RT/11) 4.Define Internal Customer Number By Sales Organization (Eg.4436 will create

customer master for 4211 company code and that number will be maintained in this relationship:-4211/231) 5. Automatic posting to vendor account (Optional) 6. Maintain pricing procedure determination for 4211/RT/A/1/RVAA01-For customer sales and billing Maintain pricing procedure determination for 4436/RT/A/1/ICAA01-For intercompany billing Master data to be maintained:1. Create end customer master in company code/sales org 4211/RT/11 2. Create customer master for 4211 company code/sales org in 4436/RT/11 3. Maintain PR00 as price for end customer-Active in RVAA01 4. Maintain PI01 as price which has to be paid to 4436-Statistical in RVAA01 5. Maintain IV01 as inter-company Price-Active in ICAA01 Process:1. Create OR with sold to party as end customer. 2. Plant to be selected is delivering plant belonging to different company code. With this selection system will treat this order as inter-company sales. 3. Pricing procedure is RVAA01 4. With reference to this order delivery will be created from the delivering plant and post the goods issue for this delivery. 5. Ordering sales org will create billing document F2 with reference to delivery for end customer. 6. Delivering sales org will create inter-company billing IV with reference to delivery document. A company arranges direct delivery of the goods to the customer from the stocks of another company belonging to the same corporate group. To put in simple terms, Company code A orders goods through its sales organization A from Plant B belonging to Company code B. It is imperative that both Plants A & B should have the material. In other words, the material is created for both the Plants A & B + their respective storage locations.

Sales Organizations and Plants are uniquely assigned to Company codes. It is not possible to assign either a plant or a sales organization to more than one company code. Sales organizations and plants assigned to each other need not belong to the same company code. In other terms, a plant belonging to Company code A & assigned to Sales Organization A can also be assigned to Sales Organization B of Company Code B. This enables cross company sales. PARTIES INVOLVED 1) End Customer 2) Ordering Company code 3) Supplying Company Code. End customer: Customer who orders goods from the ordering company code. Ordering Company Code: Which orders goods from Plant belonging to Supplying Company code through its sales organization and bills the end customer. Supplying Company Code: Supplies goods from its plant to the end customer specified by the ordering company code and bill the ordering company code. CONFIGURATION SETTINGS Assign Delivery Plant of the supplying company code to Sales Org + Distribution channel of the Ordering company code in the Enterprise Structure. DEFINE ORDER TYPES FOR INTERCOMPNY BILLING: Menu path: IMG/ SD/Billing/Intercompany Billing/Define Order Types for Intercompany billing Assign Organizational units by Plant: Menu Path: IMG/ SD/Billing/Intercompany Billing/Assign Organizational units by Plant.

Define Internal Customer Number By Sales Organization: Menu Path: IMG/ SD / Billing/ Intercompany Billing/ Define Internal Customer Number By Sales Organization: Creating / Showing Ordering Sales Organization as Internal Customer for Supplying Company code: Transaction Code: XD01 The ordering sales organization is represented as Internal customer of Supplying company code. We need to create customer master in Account Group Sold to Party and maintain minimum required financial & Sales Area data. This internal customer number has to be assigned to the ordering sales organization. Hence, the system automatically picks up this Internal customer number whenever there is Intercompany billing. PRICING: We need to maintain two pricing procedures RVAA01 & ICAA01. Pricing procedure RVAA01 represents condition type PR00 & any other discounts or surcharges that are meant for end customer. We assign Pricing procedure RVAA01 to combination of Sales area (Of Ordering company code) + Customer Pricing Procedure + Document Pricing Procedure of Sales document type. This pricing Procedure (RVAA01) is determined both at Sales Order level & Billing processing for the end customer. We maintain PR00 condition type to represent the ordering company codes price to the end customer. Condition records for PR00 are maintained using organizational elements of Ordering company code, end customer & the Material. Eg: Sales Org. of Ordering company code + End customer + Material.

We also need to maintain PI01 condition type to represent costs to Ordering company code (in other words revenue to supplying company code). It is statistical condition type & meant for information purpose only. Condition records for PI01 are created with the following key combination: Ordering sales Org + Supplying Plant + Material Pricing Procedure ICAA01is determined at Intercompany billing processing level. Pricing Procedure ICAA01 Pricing Procedure for Inter company billing is assigned to the combination of: 1) Sales Area (of supplying company code) + Document pricing Procedure of Billing document type IV + Customer Pricing Procedure of the Internal customer. Pricing Procedure ICAA01 has condition type IV01 that represents revenues for Supplying company code in the intercompany billing. PR00 condition type also appears in Intercompany billing document. It is for information purposes only and does not have bearing on the value of the document. PI01 represented under pricing procedure RVAA01 is reference condition type for IV01 and the same is defined in the condition type IV01. Due to this these two condition types represent same value. The condition type IV01 in intercompany billing document represents revenue to the Supplying Company. But its corresponding condition type PI01 in the billing document to the end customer is shown as a statistical item meant for information purposes. Condition Type VPRS in the intercompany-billing document indicates cost to the supplying company code. The use of two different condition types in Intercompany billing is necessary to ensure that data is transmitted correctly to the financial statement (Component CO-PA).

Posted byDoeat2:09 PM0 comments What Is Meant By Billing Document Type?

1. What's the difference between document type and billing document type? 2. What's the use of the field 'document type' during definiation of billing type? What's the effect if leave it blank / assign it with a document type?

3. Where can I define how the system number the billing documents, in both case using internal and external number range intervals? 1. In SAP all sales transactions are representred by documents. Document type is a generic term applicable to delivery / sales / inquiry / billing etc. e.g. if someone says "check in shipping / delivery if document type is correct or not" it means you need to check the document types relevent for shipping/delivery processing. Document type controls and links the process flow. In billing process the documents used have distinct document types . 2. The billing document type defines how the document would behave in the process chain. If you try saving the document you will come to know why it is necessary. You cannot create a document type without giving it a name. If you give it a name then you can use it afterwards. 3. In the billing document type definition (VOFA) itself you assign the number ranges to be used for the document type. Whereas it is defined through VN01. In internal numbers system maintains the counter and generates document number internally when document is save. Current counter you can see in VN01 itself. Whereas in external number ranges you can give the document number at the time of creation itself provided it falls in the assigned number range and is not yet used.

Posted byDoeat2:09 PM0 comments Difference between Credit memo and subsequent debits/credits
Subsequent Debits/Credits are used in cases where the quantity is in the original invoice is to remain the same. For eg. PO 10 - $10 Gr 10 - $10 LIV 10 - $11 (Logistics Invoice Verification) The vendor invoice is more than that in the Purchase Order. In order to correct, the Vendor may send in another invoice for the Increased amount or a credit memo for the increased amount.

If you approve of the price increase, post the subsequent invoice received as a Subsequent Debit/Credit Invoice. If it is a credit memo that has been received, then post the credit memo as Subsequent Debit/Credit. This would retain the quantity but reduce the amount. Subsequent Debit/Credit is for the case when the credit is not for the full amount eg. if the Vendor decided to credit only the $1 overcharged. Credit memo is for the credit of the full amount and value.

Posted byDoeat2:08 PM0 comments To create a discount on payer level on billing type LR

Tested in 4.6x This will not have any affect on the sold-to-party price. If you want a payer based discount on invoice list only. This is what you will need to do: 1. Check out the pricing procedure RVAA01 and condition type RL00. This pricing procedure is for Germany and the discount is factoring discount. But it is payer based discount. IMG - Sales and Distribution -> Billing -> Billing documents -> Maintain conditions for invoice lists -> Maintan pricing procedures 2. RL00 uses access sequence RL00 and condition table 7 which is sales organization/distribution channel/divison/customer (payer). If that fits your needs, use it. Otherwise, do the usual create condition table,

access sequence and condition type configuration. 3. In the appropriate place in your pricing procedure, add in condition type RL00(or one you created). Be careful to copy the requirement routine and condition base value assignments from pricing procedure RVAA01.

Posted byDoeat2:07 PM0 comments Create a Collective Billing Spiltting rule

4.6x VTFL - Check copy control rules Target Source e.g. Select F2 - Invoice LF Delivery Click Item e.g. Double click on Tan - Standard Item Check Data VBRK/VBRP - Copy rule number in use e.g. 900 VOFM - Creating a splitting rule Click Data Transafer -> Billing documents Copy the standard 1 - Inv.split (sample) to a e.g. 900 series number range A new splitting rule 900 will be created, follows by a program FV60C900. In program FV60C900, SAP has a standard internal table called ZUK where you can define fields that must be compared and be equal before a billing may be combined. However, total characters allowed is 40 will be store on the billing header table VBRK. e.g. Program FV60C900 DATA: BEGIN OF ZUK, MODUL(3) VALUE '900', BUPLA LIKE VBRK-BUPLA, "Business place

LIFNR LIKE LFA1-LIFNR, "Consignor (Vendor Consignment) MWSKZ LIKE VBRP-MWSKZ, "Tax code END OF ZUK. ZUK-BUPLA = VBRK-BUPLA. ZUK-LIFNR = LFA1-LIFNR. ZUK-MWSKZ = VBRP-MWSKZ