Payment Terms by Material in SAP SD

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

The condition records has a higher priority than the Customer Master.
4.6x

• Transaction VK32
• Search for the All fields List Box and Choose Terms of payment
• The PayT field columns will appear next to the Material

3.0x

• Transaction V-51
• Positon your cursor on the Material and click Additi.SD data
• Search for the field Payment terms

Tcodes To Configure The SAP SD Sales Tax Determination

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

Sales Tax Determination
OBQ1 - Maintain/Create Condition Type

• Double click on the Condition Type for more control

OBQ3 - Tax Pricing Procedures
OBQ2 - Tax Access Sequences
OBBG - Assign Tax Country to calculation procedure
OVK3 - Define the Customer Tax category
OVK4 - Define the Material Tax category
OVK1 - Define Tax determaintion rules

• Define the links between the Tax Country and Tax conditions type

OVK6 - Assign delivery plants for Tax determination (locally which Tax country category to use)
VK13 - Maintain Tax Condition Rate (e.g. 1%, 2% etc...) by Tax Country
SM31 - Table View V_T001 - Maintain default country, currency for Company Code.
Material and Customer Tax Master Maintenance must be equal
e.g. 0 = tax 1 = no tax both Material and Customer master must be 1 and 1
Search for the Tax Classification field
MM02 - Sales Organization data
XD02 - Tick Billing

Steps To Setup Collective Billing in SAP SD

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


Collective Billing
Configuration steps:-

• transaction VD02 - Change Customers - tick Billing and filled in the Customer Code, Sales org., Distr.channel and Division then hit enter.
• Look for field name Inv.list sched. - you must filled in the Factory Calendar that you are currently using.
• You can simulate the collective billing in transaction VF04 - Process Billing Due List.

During simulation, if the billings cannot be combine, the system will give you this message,
Different header fields $000000001 $000000002 Combination criteria in the billing xxxxxxxxxxxx123 xxxxxxxxxxxx125

Criteria to satisfy for collective billings:-

• Billing document type is the same.
• Reference document type is the same.
• Item category in the reference document is the same.

The system combines into one billing document all transactions for the same customer and same billing data. If the header data and the header partners for the specified deliveries or sales orders are identical and if the requirements for splitting do not apply, one billing document is created for all the deliveries or sales orders.
The following illustrates an example. The system determines that deliveries 1 and 2 had the same bill-to party, and therefore combines the deliveries in one billing document.
Delivery Order 1 - |
-----------> Invoice
Delivery Order 2 - |

Create a Collective Billing Spiltting rule in SAP SD

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


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.

To create a discount on payer level on billing type LR in SAP SD

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


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.

Configuring Intercompany Billing in SAP SD

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


How to configure Inter Company Billing

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 inter-company 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 code’s 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).

What Is Meant By Billing Document Type? in SAP SD

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



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.

San

Release Billing Documents to Accounting in SAP SD

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




By: Mike
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.

Explain What Is Credit Memo in SAP SD

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



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.

Explain What and How To Configure Debit Memo in SAP SD

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


Debit Memo Request:-
Step 1: Sales Document Type
IMG > Sales and Distribution > Sales > Sales Documents >
Sales Document Header:
1. Sales Document Type:DR is the sales document type for Debit Memo Request. To create new sales order type, always copy as with reference to similar sales order. If possible use standard sales order.
2. Define Number Ranges For Sales Documents: Maintain number range with discussion with core team.
3. Assign Sales Area To Sales Document Types:
A. Combine sales organizations / Combine distribution channels / Combine divisions: Ensure to maintain these, else Sales Order creation will give error.
B. Assign sales order types permitted for sales areas: Assign only required Sales Order Types to required Sales Area. This will minimize selection of Sales Order Type as per sales area.
Sales Document Item:
1. Define Item Categories: If possible use Standard Item Category. Incase if required to create new, copy as from standard & maintain New.
2. Assign Item Categories: If possible, use standard. Formula for deriving item category: Sales Document Type + Item Category Group + Usage + Higher Level Item Category = Item Category
Step 2:
IMG > Sales and Distribution > Billing >
1. Define Billing Types: L2 is standard Billing Type for Debit Memo. If possible use Standard Billing Type. In case if required to create new, copy as from standard & maintain New.
2. Define Number Range For Billing Documents: Ensure to maintain number range.
3. Maintain Copying Control For Billing Documents: Maintain relevant copy controls such as Sales Order to Billing.
Note: Ensure that Copy Control settings are done
Sales Order to Billing (OR --> F1): VTFA

In what situation do we use a debit memo request and a debit memo?
Debit memo is used in below scenarios:
1) When you have charged the customer less then actual due to reason like selection of wrong scales or you have not checked the actual Market price.
2) When there is an over delivery and customer agrees to pay for it.
Debit memo request is an order type which is referred to create a debit memo there can be release procedure in-between depending on the business process.
Also note that our FI counter parts can create standalone DEBIT MEMOS.
There are a lot of scenarios we create debit memo request and debit memo against a customer. I am giving a couple of scenarios:
In repair processing the material has come back to our premises, we repaired the same and send it back to the customer. The charge for repair and the parts consumed has to be billed to the customer. We normally use resource related billing in such cases, through RRB we generate a debit memo request and followed by a debit memo.
We have sold one equipment (material) to a customer, it is having some issue, the customer wants an immediate replacement. We send the replacement immediately, expecting the customer to return back the faulty one. But the customer is not returning back the equipment. After many follow-up, we create a debit memo request and debit him with a debit memo.

Procedures to switched off ATP at delivery

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.

Procedures to switched off ATP at delivery
The simpliest way is to use tranaction OVZK and mark availability check off column for all the delivery item categories you are
using.
or
Another way is to use transaction OVZ9. For all the MRP checking group you are using, and checking rule B, de-select
in the Receipts/Issues section, sales, deliveries, and reservations.

Additional fields in worklist for VL06O - List Outbound Delivery in SAP SD

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.

Additional fields in worklist for VL06O - List Outbound Delivery
4.6x
There are no more configuration to include a new field. Any additional field in table LIPOVZ will be reflected in the worklist.
To add a field in the worklist, you must insert the field in customer specific table :-
LIPOVZ - Customer modification division for Table LIPOV
SE12 - Database Table - LIPOVZ
Click Display -> Change
You can delete away the Component DUMMY.
e.g. to insert the Batch Number in the worklist
Component Component Type
CHARG CHARG_D
After this, you have to execute program BALVBUFDEL (note 122975) to reset the ALV buffer.
Table you can use for VL06O
LIKP - SD Document: Delivery Header Data
LIPS - SD document: Delivery: Item data
VBUP - Sales Document: Item Status
Once completed, you should be able to see the new fields in Settings -> Layout -> Change

Post goods issue must be done on current period - VA02

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.

Post goods issue must be done on current period - VA02

• Go to VA02
• click Edit -> Actual GI date
• Change the date to current period. (Check transaction MMRV for the period)

Adding additional fields to Delivery Due List in SAP SD

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.


Question : Subject : Adding additional fields to Delivery Due List
I would like to add additional fields to the Delivery Due List - Transaction VL04. These fields do not exist in the list of additional fields in the IMG so I assume I will need to have a user exit written or something... Has anyone had any experience in adding fields to the delivery due list that do not exist in the IMG? Your help is greatly appreciated.

Answer : Subject : Adding additional fields to Delivery Due List
USE T-CODE VOL1.CREATE A DISPLAY VARIANT AND ADD FIELDS & SEQUENCE NUMBER.

Answer : Subject : Adding additional fields to Delivery Due List
Check OSS, at least note 198137.

Answer : Subject : Adding additional fields to Delivery Due List
Thank you... but as I stated in my question, The fields I need do not exist in the list of addtional fields in the IMG. I need to add fields from KNA1 and display them in the existing Delivery Due List.

Answer : Subject : Adding additional fields to Delivery Due List
additional fields need to be added to structure VBVFI. SAP provides an include in the structure to do so or you can create an append, depending on how your basis folks see life

Answer : Subject : Adding additional fields to Delivery Due List
Thank you. I forgot to mention, we are release 3.1I. Do you think this 4.X note would be applicable?
Kind Regards,

Answer : Subject : Adding additional fields to Delivery Due List
I found note 415716. Thank you for your help.
Kind Regards,

SAP Spools Configuration for Sales/Distribution

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.


SAP Spools Configuration for Sales/Distribution
SAP Printers outputs

• Create/Change the shipping loading point (VV22) and (OVX7)
• Create/Change the billing output (VV32)

Sales Document Output Control

• transaction /NVV12
• Input the Output type e.g. BA00 - Order Confirmation then hit enter
• Input the Sales document type e.g. OR - Standard Order and click Execute
• Under the Output Conditions Section, you must know which Sales grp. you used. Look at the Tim Column. Option 4 indicates an immediate printout once the user save its data.
• To check which SAP printer the sales document print to, tick the desired Sales grp. and click Communication button.

Delivery Output Type Default in SAP SD

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.


Delivery Output Type Default
You can specify a default printer for your delivery note. If you maintain the loading point for printers, it will overwrites the default output type when the user enter the loading point.
Maintain the output type by loading point

• VV21 / VV22 - Create or Change the output type by loading point

Maintian the output type default by shippint point
4.6x

• VP01SHP - Shipping -> Delivery Note

3.0x

VP01 - Shipping -> Delivery Note

Difference between Credit memo and subsequent debits/credits in SAP SD

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



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.