Billing types
Note: Billing documents are created by FM RV_INVOICE_CREATE to which data is passed by header and item structures. SDBILLDL is the program
to generate billing docs
Invoice split: refer Invoice split : http://www.saptechsolutions.com/pdf/SDBillingDocumentConsolidationAndSplit.pdf
Invoice split Enhancement:
Requirement:
For some customers, billing documents should be combined if created from same plant on the same date , while for other customers , seperate
billing document should be generated for each shipment.
Solution:
1. Create a new flag field in customer master. This field will differentiate both kind of customers.
2. Add this field in KNA1 table and structure KUAGV inside the include KUAGVZ. This will make the field to be read by the data transfer routines in
copy controls.
3. Create a custom data transfer routine and add the sales order number field to this routine in ZUKRI field (combination criteria). Based on the
flag field, we need to implement logic wether to fill sales order number in ZUKRI (to make the document to split) or not to pass the sales order
number to ZUKRI field
Outbound idocs can be triggered by 3 ways
1. change pointers
2. output types
3. abap programs
Idocs through output type
In the output condition record we give the partner type and partner number
we choose transmission medium as 6. this will be the starting point to trigger an idoc.
Based on partner number relevant partner profile is called in we20
partner profile contains outbound parameters and inbound parameters
for outbound idoc we have to fill the outbound parameters with message type and basic type
message type contains the output type and process code which is linked to FM which will process
the idoc
Message type: it is the type of document being sent. example: Orders
Basic type: it is linked to a message type. this contains the structure of the idoc which has segments and sub segments
Eg orders01, orders05
process code: each message type can have multiple process codes linked to it for multiple output types
this will define how the idoc gets processed
eg: orde for inbound and SD10, Me10 for outbound
ments and sub segments
SD uses material BOM
Two types of material BOM
pricing at header level
pricing at item level
To create BOM, go to CS01, enter the header material, pplant and bom usage - 5 for SD, go inside and give the components a
when u enter the main item in the sales order, bom will show the sub components
Pricing at header level
Item category of main item - TAQ -> relevant for pricing, relevant for picking , item cat grp - ERLA
Item category of Sub item - TAE ->not relevant for pricing, not relevant for picking- item cat grp - NORM + higher level item ca
Pricing at Item level
Item category of main item - TAP -> not relevant for pricing, not relevant for picking , item cat grp - LUFM
Item category of Sub item - TAN ->relevant for pricing, relevant for picking- item cat grp - NORM + higher level item category
Sales document types:
Delivery group field in sales order shipping tab can be leveraged to combine the delivery of multiple line items in a sales orde
In that case all the schedule line delivery dates will be changed to the last schedule line delivery date.
Important fields in copy controls:
after goods are delivered to customer by hte vendor. This can be controlled by a copying routine which will alow billing only if open quanitiy is present, which will happ
if vendor invoice verification document is created in our system.
Data Transfer routines: This routine is mainly responisble for which fields in the source document are to be copied to target document and which fields are to be redet
We can also control the invoice split criteria here.
Output determination in SD
Output type related enhancements:
Requirement: In the sales order a new flag field is added which can be edited by user. If the flag is checked while creating or c
confirmation copy has to be sent to sales admin instead of to the customer.
Changes required:
Structure KOMB (field catalog related) for field catalog is enhanced with this new field
In userexit USEREXIT_KOMKBV1_FILL, logic to pull the field from sales order is implemented
Then add the field in the field catalog t code V/86
Then create a new condition table B901 with only this field in t code v/57
From V/48 add the new condition table at top of the access sequence
Access sequence is assigned to condition type
In vv11 we can add the internal partner to whom the output type should be mailed by creating him as a customer record and
Requirement: The customer has defined a special order type that is used to ship sample products.
For these orders, billing output is to be suppressed. The billing type associated with these orders is the standard F2 which is
billing output is already generated.
Within this routine, we need to examine the sales order type associated with the invoice. As the order type is not included in t
structures used for billing output. Therefore, a user exit will be coded to provide it.
communication structure KOMKBV3 is enhanced with the new field of order type
Under include RVCOMFZZ in userexit USEREXIT_KOMKBV3_FILL, logic to pull the sales order type is implemented.
Then requirement routine is to be implemented from VOFM. We can enhance existing standard requirement routine 62 and c
In output determination procedure, assign this routine to your output types as below.
Note: When a VOFM routine is moved to a system, a special generation progam has to be run by basis team which is RV80HGE
key.
Configuration of AC and TOR (OVZG, OVZH,OVZI, OVZ3)
1 Activate AC and TOR at requirement class level. OVZG
2 Define a requirement type and assign requirement class to req. type OVZH
3 Setup determination rule for TOR OVZI
4 Activate AC and TOR at schedule line category level MM03-
5 Define checking group in Mat master MRP
OVZ33
6 Define scope of check OPJJ
Backward and forward scheduling:
delivery date and subtracts ship time and pick/pack time, loading time to
arrive at Material availability Date
carried out to determine the date on which the stock will be delivered
and schedule lines are determined accordingly.
Back order processing
backorders. If some other stock is released, we can process these
backorders to allocate stock on them with V_RA t code.
Rescheduling is process of releasing stock from low priority
customers and assigning it to high priority customers by V_V2
req class : 041
req type : 041
Requirement type determined from 1. startegy group/ MRP group/ Mat type/ Item
Cat + MRP type/ Item cat
CP for AC
delivery. Noand CNfield
check for to
nodeactivate
check. availability check. Accumulation field to
control incosistencies in ATP
outward moments to be considered and which stock to be considered. Also
RLT ( replenishment lead time can be deactivated from here)
material.
RLT is present in In MM03 - MRP3
Rebate activation: Payer, sales org and billing doc type
CONFIG
In sales order pricing procedure add the rebate condition types.. standard rebate conditions types are B001, B002 to B005
BO01 - Group rebate, BO02 - Material rebate, B003 - Customer rebate B004 - Heirarchy rebates; B005 - Independent rebates
These condition types have condition category C, this setting controls the condition record maintenance to be not in VK11 bu
inside the Rebate agreement itself.
Also the requirement type in pric. proc is 24, which makes sure rebate condition types are only triggered in billing doc
Now need to link these rebate condition types to the settlement agreement, for which make the below settings :
Group the rebate condition types that need to be coming in a agreement by defining a condition type group and assigning
our rebate condition types to this CT group.
While assigning rebate CTs to CT group, we also need to assign the condition tables one after the other. This will bring the
condition tables into the rebate agreement, where we can maintain the values/ percentage of rebate.
Condition type group is assigned to CT group catergory which is blank (settlement for rebates) while defining it.
Now condition type group is linked to rebate agreement types
If we need any specific settings related to payment cycle, methods, settlement document types, we can create a new rebate
agreement type
Inside the agreement type important fiels are CT group and verification level, which controls the level of display of rebates in
reports..we can view at individual document level, payer level, material level etc
Creation of settlement agreement
Create a rebate agreement in VBO1 t code with one of below agreement types
001 Group rebate, 002 Material rebate, 003 Customer rebate, 004 Heirarchy rebates and 005 independent rebates
While creating it, we can maintain the customer, validityperiod , rebate condition records and the material for settlement
For posting manual accruals or final/ partial settlement, all can be done from VBO2 by entering the settlement agreement
This will create a CMR for which CN can posted and accounted.
Account assignment for rebates
In pricing procedure, both account key and accrual fields are maintained for rebates
In Standard, account key is ERU and accrual key is ERB
ERU account key is linked to two G/L accts in VKOA : a rebate accrual g/l and provisional rebate expense g/l
ERB accrual key is linked to actual rebate expense g/l
customer g/l... during the final/ partial settlement rebate g/l is debited and prov expense g/l is credited while actual rebate e
customer account is credited based on accrual key
SPECIAL NOTES
Create settlement type: important field is condition group type field
Under condition group type we create rebate condition types just like pricing condition types i.e. create condition tables, assi
Assign condition types to condition group type, condition type t code VBO1
Then a settlement agreement is created with validity period and when it can be settled.. there are three types of settlement :
We should put requirement 24 for rebate conditions and accrual account should be inserted in pricing procedure
There is a t code to generate rebates on already issued invoices : RV15B002
VBOX table is linked to rebates
ss sequence to condition types