Copy control - Order to Invoice

User wants a field to copy over from sales order header to the header field of credit memo and debit memo when they are created with reference to an order.
They also want that field to copy over to the invoice irrespective of whether the invoice is created with reference to order or delivery.
I was able to do the first part by making changes in the routine used in copy control of sales order to sales order. However I'm not able to do that 2nd part as this field is not passed on to the delivery doc. Any suggestions?

Hi Carrie
simple now that you have clarified
In the copy control settings for billing, delivery to billing ( LF to F2) select "a" for the refrence number field - this will automtaically move the customer PO number as required by you at the time of billing
please test in develoment once and then move to production
cheers
nandu
note: you may get multiple answers now for this

Similar Messages

Problem Copy control Order to Invoice

Hi All,
I maintained a copy control from order to invoice and in the item category the pricing type is maintained as 'G'(Copy pricing elements unchanged and redetermine taxes). But when I create invoice the condition value for pallet discount is getting recalculated.
There is a requirement for this condition type in the pricing procedure that when the order quantity is greater than the pallet quantity maintained through material master then only the discount should be affected.But when I change the pallet quantity to less than the order quantity,after the order is created and then invoice the order the condition value is going through the requirement and the value is getting changed .
Can anyone tell me why it is recalculating when the invoice is created, it should not reprice the order, but just carry over current pricing to the billing
All useful answers will be rewarded.
Thanks,
Ranjan

hi,
Refer to OSS note 24832:
14.05.2008 Page 1 of 10
Note 24832 - Pricing rules / TVCPF
Note Language: English Version: 27 Validity: Valid from 18.05.2004
Summary
Symptom
Depending on the situation, the system should redetermine conditions or
not. For this, a differentiated control is required, for example:
1. When you create sales orders or billing documents, the condition types
are partially redetermined although you want to copy the values from
the reference document.
2. During other transactions, however, you want to redetermine the
condition types instead of copying them.
3. The 'New pricing' function on the item condition screen
redetermines all new conditions, that means it works with pricing
category 'B'. This is undesirable to a certain extent.
4. The same applies to the 'New pricing' function for the entire sales
order.
The following text will explain some examples for the use of the pricing
type implemented for this purpose (KNPRS):
Example 1 **********************************
You want to copy condition type 'VPRS' from the sales order into the
billing document. You are using pricing type 'G'. However, as a consequence
the value of the VPRS condition in the billing document differs from the
value of the goods issue posting.
Example 2 **********************************
You want to copy condition type 'PI01' (price for intercompany billing)
from the sales order into the billing document. You are using pricing type
'G'.
Example 3 **********************************
The costs 'VPRS' are to be redetermined when copying a credit memo request
from a billing document. This is required if you defined the credit memo
item in such a way that no costs are to be determined. Since the pricing
requirements are no longer checked when copying, you have to proceed as
described above to eliminate the VPRS.
Example 4 **********************************
The 'New pricing' function on the item condition screen is to keep the
manual condition, this means the function should behave like pricing
category 'C'.
Example 5 **********************************
The 'New pricing' function for the entire sales order is to keep the
14.05.2008 Page 2 of 10
Note 24832 - Pricing rules / TVCPF
manual conditions, this means the function should behave like pricing
category 'C'.
Example 6 **********************************
Billing is to be carried out using pricing type 'G'. However, condition
types with condition category 'S' and 'T' (standard price or moving costs)
are also to be redetermined. In the standard system this pricing type
copies those condition types from the sales order.
More Terms
KNPRS, TVCPF, TVCPA
Cause and Prerequisites
The pricing type controls which condition types are redetermined or which
are copied unchanged (however, the items are always revaluated). Below,
you will find a description of the pricing type characteris
Note that the specified standard pricing type characteristics
partly do not exist in older releases, or that the standard
pricing type characteristics may be different in the
individual releases. Therefore, the given consulting note
should not be considered to be exhaustive. It merely serves to
explain the principle of how a pricing type is structured and
how its characteristics can be influenced. The exact
characteristic of a pricing type in the release being used can
be seen directly in the source code of Form routine
KONDITIONSVORSTEP in Main program SAPLV61A.
o 'A' (Copy price components and redetermine scales):
No condition types are redetermined. Only the scaled prices are
adapted due to a changed basis.
o 'B' (Complete new pricing):
Completely new pricing (as if you created a new item), manual
conditions are lost.
Restriction: Condition types which are not determined via condition
technique (for example, condition type 'VPRS' or condition types
with KNTYP = 'G' which are determined using formulas) are NOT
redetermined even if you do not change them manually.
o 'C' (Copy manual pricing elements and redetermine the
others):
Completely new pricing, manual ones are copied.
Caution: Here you have to make sure that all condition types that
can possibly be changed manually have T685A-KMANU = 'C' (Manual
entry has priority) in Customizing. Otherwise, it is possible that
the conditions are displayed twice (automatically and manually) and
that both are active.
o 'D' (Copy pricing elements unchanged):
14.05.2008 Page 3 of 10
Note 24832 - Pricing rules / TVCPF
As in pricing type 'A' but the prices are fixed (no scales are
read). Condition base value and value are redetermined.
o 'E' (Adopt price components and fix values):
As in pricing type 'D' but neither condition base value nor value
are redetermined.
o 'F' (Copy pricing elements, turn value and fix):
Only used within the program.
o 'G' (Copy pricing elements unchanged and redetermine
taxes):
a) The following condition types are redetermined:
- Condition class KOAID = 'D' (Taxes)
- Condition class KOAID = 'C' (Volume-based rebate)
- Condition category KNTYP = 'I' (Intercompany billing
conditions)
- Condition category KNTYP = 'R' (Invoice list conditions)
- Condition category KNTYP = 'L' (Always new when copying)
- Condition category KNTYP = 'G' (Cost conditions)
- Condition category KNTYP = 'E' (Cash discount conditions)
All remaining condition types are dealt with like pricing type 'D'.
In particular, with pricing type 'G', the system does not only
redetermine the taxes but also the cost conditions and the
intercompany billing conditions.
o 'H' (Redetermine freight conditions):
The following condition types are redetermined:
- Condition type KNTYP = 'B' (Delivery costs)
- Condition type KNTYP = 'F' (Freight conditions)
- Condition type KNTYP = 'L' (Always new when copying)
o 'I' (Redetermine rebate conditions):
Rebate conditions and scales are redetermined.
o 'J' (Redetermine confirmed purchase net price/value):
Condition types with condition category KNTYP = 'D' (Confirmed
purchase net price/value) are redetermined.
o 'K' (Adopt price components and costs. Redetermine
14.05.2008 Page 4 of 10
Note 24832 - Pricing rules / TVCPF
taxes):
The following condition types are redetermined:
- Condition class KOAID = 'D' (Taxes)
- Condition class KOAID = 'C' (Rebate)
- Condition category KNTYP = 'R' (Invoice list conditions)
- Condition category KNTYP = 'I' (Price for intercompany billing)
- Condition category KNTYP = 'E' (Volume-based rebate)
o 'M' (Copy pricing elements, turn value):
No conditions are redetermined; during copying, the condition
values are multiplied with -1.
o 'N' (Transfer pricing components unchanged, new cost):
Condition types with condition category KNTYP = 'G' (Cost) are
redetermined.
Please note that this pricing type has NO effect on the invoice
since here the goods issue value from the delivery is usually
directly transferred to pricing. Redetermination of the settlement
price by subsequently reading the material valuation segment when
executing pricing type "N" would result in the fact that the goods
issue value information were irretrievably lost.
This standard behavior can be changed by a modification only. If
required, please contact your local consultant or SAP Remote
Consulting.
o 'O' (Redetermine variant conditions):
Condition types with condition category KNTYP = 'O' (Variants) are
redetermined.
o 'P' (Revaluation only):
The system does not redetermine any conditions; only the
revaluation occurs.
o 'Q' (Redetermine calculation conditions):
Condition types with condition category KNTYP = 'Q' (Costing) are
redetermined.
o 'U' (Redetermine precious metal conditions):
Condition types with condition category KNTYP = 'U'
(Discount/surcharge for precious metals) are redetermined.
Solution
There are two options to change the standard behavior:
14.05.2008 Page 5 of 10
Note 24832 - Pricing rules / TVCPF
1. Set up a new pricing type (for example, 'X') and allocate the pricing
type in the document flow (copying control in the IMG, Customizing
depending on the source and target document type via Transactions
VTAA, VTAF, VTLA, VTLF and VTFF).
2. Change the pricing type used in the standard system.
Procedure
For both purposes, USEREXIT_PRICING_RULE is used in Program RV61AFZA. This
is called after the setup of internal table STEU which defines the behavior
of pricing types.
Example 1 ******************************
Picing type 'X' is to be set in a way that condition 'VPRS' (which has
condition category 'G') is not redetermined during the billing. Otherwise
it behaves as pricing type 'G'.
Up to Release 4.0B, USEREXIT_PRICING_RULE can be implemented as follows:
FORM USEREXIT_PRICING_RULE
STEU-KNPRS = 'X'.
STEU-KNTYP = 'LRIE......'.
IF KOMK-KNUMA IS INITIAL.
STEU-KOAID = 'CD........'.
ELSE.
STEU-KOAID = 'D.........'.
ENDIF.
STEU-MAUEB = ' '.
APPEND STEU.
ENDFORM.
In order to ensure that pricing type 'X' acts exactly like pricing type
'G', the FORM routine USEREXIT_PRICING_COPY in Program RV61AFZA is to be
used in releases lower than Release 4.0A (if you create a document with
reference to another document, this is called: copying control; here, the
MODE is the pricing type):
FORM USEREXIT_PRICING_COPY.
IF MODE CA 'X'.
IF KONV-KSTEU NA 'CEF'.
KONV-KSTEU = 'D'.
ENDIF.
ENDIF.
ENDFORM.
In this case, you should note that the billing document contains a special
rule concerning cost condition 'VPRS'. If the goods issue for the delivery
note to be billed is posted, the value of the goods issue is copied into
condition 'VPRS'. This is hard-coded. You can prevent this by setting the
field TKOMP-WAVWR to zero in include LV60AFZZ,
USEREXIT_PRICING_PREPARE_TKOMP.
In higher releases, pricing type 'K' is also available, which copies the
VPRS of the order to the billing document and does not redetermine it
unless there is no goods issue posting (otherwise, the above-mentioned
special rule applies.)
14.05.2008 Page 6 of 10
Note 24832 - Pricing rules / TVCPF
Example 2 *********************************
Pricing type 'Y' is to be set in a way that this works as pricing type 'G'
but without redetermining the intercompany billing conditions 'PI01' and
'PI02'. They have condition category 'I'.
Changes in program RV61AFZA:
FORM USEREXIT_PRICING_RULE.
STEU-KNPRS = 'Y'.
STEU-KNTYP = 'GLRE.......'.
IF KOMK-KNUMA IS INITIAL.
STEU-KOAID = 'CD........'.
ELSE.
STEU-KOAID = 'D.........'.
ENDIF.
APPEND STEU.
ENDFORM.
In order to ensure that pricing type 'Y' acts exactly like pricing type
'G', the FORM routine USEREXIT_PRICING_COPY in Program RV61AFZA is to be
used:
FORM USEREXIT_PRICING_COPY.
IF MODE CA 'Y'.
IF KONV-KSTEU NA 'CEF'.
KONV-KSTEU = 'D'.
ENDIF.
CLEAR: KONV-SAKN1.
ENDIF.
ENDFORM.
EXAMPLE 3 *********************************
Pricing type 'Z' is to be set in the same way as pricing type 'D', but this
time the costs are to be redetermined. Up to Release 4.5B, you can
implement USEREXIT_PRICING_RULE as follows (as of Release 4.6A, pricing
type 'N' is available for this procedure):
FORM USEREXIT_PRICING_RULE.
STEU-KNPRS = 'Z'.
STEU-KNTYP = 'G.........'.
STEU-KOAID = '..........'.
STEU-MAUEB = ' '.
APPEND STEU.
ENDFORM.
In order to ensure that pricing type 'Z' acts exactly like pricing type
'D', the FORM routine USEREXIT_PRICING_COPY in Program RV61AFZA is to be
used:
FORM USEREXIT_PRICING_COPY.
IF MODE CA 'Z'.
IF KONV-KSTEU NA 'CEF'
KONV-KSTEU = 'D'.
ENDIF.
ENDIF.
14.05.2008 Page 7 of 10
Note 24832 - Pricing rules / TVCPF
ENDFORM.
Note: To correct the problem, you should define your own pricing types. In
some cases, it may be required to change existing pricing types. This is
required if you want to influence the reaction to certain field changes in
the sales order (see Note 26115 for this). This also allows you to
influence the 'New pricing' function in the sales order and billing
document. This function uses pricing type 'B'.
EXAMPLE 4 *********************************
The 'New pricing' function is meant to keep the manual changes. By default,
pricing type B' is called. As of Release 4.5A, however, you have the option
to store another pricing type for this purpose in Customizing of the
pricing procedure (Transaction V/08).
In USEREXIT_CHANGE_PRICING_RULE of program MV61AFZA, you can
replace pricing type 'B' with another pricing type, for
example, 'C' up to Release 4.0B.
FORM USEREXIT_CHANGE_PRICING_RULE USING PRICING_RULE.
IF PRICING_RULE = 'B'.
PRICING_RULE = 'C'.
ENDIF.
ENDFORM.
EXAMPLE 5 **********************************
The 'New pricing' function is to be set for the entire sales order in a way
that manual changes are kept. In the standard system, pricing type 'B' is
called. As of Release 4.5A, however, you have the option to store another
pricing type for this purpose in Customizing of the pricing procedure
(Transaction V/08).
Up to Release 4.0B, a solution is only possible by means of a modification
in program MV45AF0F:
FORM FCODE_KONB.
PERFORM PREISFINDUNG_GESAMT USING CHARB. <<<<<<<<<< delete
PERFORM PREISFINDUNG_GESAMT USING CHARC. <<<<<<<<<< insert
ENDFORM.
FV45PF0P has to be changed in the same way:
FORM PREISFINDUNG_NEU.
Aufruf neue Preisfindung
PERFORM PREISFINDUNG USING CHARB. <<<<<<<<<< delete
PERFORM PREISFINDUNG USING CHARC. <<<<<<<<<< insert
geänderte Informationen in Beleg übernehmen
PERFORM VBAP_BEARBEITEN.
PERFORM VBAP_BEARBEITEN_ENDE.
ENDFORM.
14.05.2008 Page 8 of 10
Note 24832 - Pricing rules / TVCPF
EXAMPLE 6 *********************************
Pricing type 'X' is to be set so that it functions like pricing type 'G',
but also redetermines condition categories 'S' and 'T'.
Change in Program RV61AFZA:
FORM USEREXIT_PRICING_RULE
STEU-KNPRS = 'X'.
STEU-KNTYP = 'GLRIEST...'.
IF KOMK-KNUMA IS INITIAL.
STEU-KOAID = 'CD........'.
ELSE.
STEU-KOAID = 'D.........'.
ENDIF.
STEU-MAUEB = ' '.
APPEND STEU.
ENDFORM.
To ensure that pricing type 'X' behaves exactly like pricing type 'G', use
FORM routine USEREXIT_PRICING_COPY in Program RV61AFZA:
FORM USEREXIT_PRICING_COPY.
IF MODE CA 'X'.
IF KONV-KSTEU NA 'CEF'.
KONV-KSTEU = 'D'.
ENDIF.
ENDIF.
ENDFORM.
Additional information ***********************
You can display the standard behavior of the pricing types in FORM routine
KONDITIONSVORSTEP (up to Release 3.1I in Include LV61AF0K, as of Release
4.0A in Include LV61AA12). There, for each pricing type, a line exists in
internal Table STEU. The fields have the following meaning:
o KNPRS
This is the pricing type used.
o KNTYP
This field contains a positive list of the pricing categories (up
to 10 values can be entered).
o KOAID
This field contains a positive list of the condition classes (up to
10 values can be entered).
o MAUEB
This field specifies whether manual changes should be copied.
o STFKZ
This field contains a positive list of the scale indicators (up to
14.05.2008 Page 9 of 10
Note 24832 - Pricing rules / TVCPF
5 values can be entered).
o NOTYP
This field contains a negative list of the condition categories (up
to 5 values can be entered).
o KDUPL
This field contains a positive list of the structure conditions (up
to 3 values can be entered).
o NOKDUPL
This field contains a negative list of the structure conditions (up
to 3 values can be entered).
o KFKIV
This field specifies whether intercompany billings should be
redetermined ('.' or 'X' can be entered).
o KVARC
This field specifies whether variant conditions should be
redetermined ('.' or 'X' can be entered).
o PRSQU
This field specifies whether the price source should be taken into
account ('.' or SPACE can be entered).
Note that most condition attributes (fields of the XKOMV structure) can
also have the value SPACE. To use the above 'CA' or 'NA' statements in the
IF statements also in these cases as required, you can fill the fields of
the STEU line with a corresponding number of '.' characters. These values
are mainly checked in FORM routine XKOMV_AUFBAUEN_PRUEFEN (up to Release
3.1I in Include LV61AF0X, as of Release 4.0A in Include LV61AA65).
Header Data
Release Status: Released for Customer
Released on: 18.05.2004 13:18:36
Priority: Recommendations/additional info
Category: Consulting
Main Component SD-BF-PR Pricing
The note is not release-dependent.
14.05.2008 Page 10 of 10
Note 24832 - Pricing rules / TVCPF
Support Packages
Support Packages Release Package Name
DIMP 471 SAPKIPME06
Related Notes
Number Short Text
1009170 Date of services rendered in the credit memo process
992808 Pricing type 'T': Redetermine tax conditions only
547570 FAQ: VPRS in pricing
410907 Allowed pricing types BAPISDLS-PRICING III
195094 Manual prices during intercompany billing
117347 Pricing type K modified for condition category L
114756 Customer hierarchy determination for pricing
102961 New pricing type for milestone billing plans
45326 No prices for customer-specific pricing type
26115 Conditions not updated during field change
Award opints if useful.
Regards,
Raghu.
Edited by: Raghuram Saripalli on May 14, 2008 11:12 AM

Condition records not copied from order to invoice

Hi,
I created an order and it has contion types for Frieght cost and packing cost...for both condition rocrds were found and triggered in order but whn cheked in invoice...records are not copied to invocie level..and when checked in analysis it says "access not made" for both the conditions...
Fields combination for these are shipping point and material frieght group for both condition types...
i checked the validity dates for both conditions and are still in validity dats.
Can anyone advice me is there some thing else i need to check and why condition records are not copied to invoice.
Thanks in advance
Balu

Hi Sumanth,
Copy controls are fine...it is actually delivery related billing scenarios..and in delivery to billing copy contrls in header in determine export dat feild it is set to "B :Redetermine the export data" and at tiem level the pricing type is set to "C:Copy manual pricing elements and redetermine the others"
Kindly let me know if the settings are fine or the problem is woth these settings
Regards
Balaji

Header text to get copied from order to Invoice

Hi,
we are creating an Invoice(through transaction VF01) giving the delivery document number and document type (Invoice F2).
we are maintaining Header text in Order through which the above mentioned delivery document number is created and this header text should get copied in the Invoice.
For this, I went into Transaction VOTXN, from there selected billing header, from here kept a break point for the routine BEDINGUNG_PRUEFEN_001 through which the text will get copied.
Now, when I'm creating the Invoice this routine is getting executed, but still the text is not getting copied.
Any pointers on this would be of great help.
Thanks and Regards,
Vamsee Priya.

Maintain the Text ID @ Sales Documnet Header level and add it to your Text Procedure. Also ensure you assign the access sequence to your Text ID in your procedure.
Access Seuquence should have VBBK and the text ID number and check All Languages and use Requirement 1.
Then in the Delivery Header Text Procudure add this text ID and assign the same access sequence as above.
This will copy the Text ID from Sales Order to Delivery Order Header.
You can configure the output for packing slipduring the delivery process and in the output program read this Text ID and print it.
Note" Copy Controls do not copy text from preceeding documents to succeeding documents. Only the Access Sequences used in the Text Procedure will do that with the help of the reuqirement assigned in the same.
Thanks and Hope this helps.
Sai

Copy Control Invoice - Debit Memo

Dear All,
I have some typical problem when i creating the debit memo request with reference to Invoice.
I have BOM Material in the Invoice i.e. with 2 sub items
M001 TAQ
S001 ZCRD
S002 ZCRD
i set the copy control to from Invoice to Sales document -- Item category
If it is TAQ copy as L2W
And ZCRD as L2W also
But when i try to create the Debit memo request it is copying TAQ as L2w but not ZCRD as L2W it is copying same as ZCRD..
Where ZCRD is is relevant for delivery so i didnu2019t want this item category to be copied can any one suggest why it is doing that???
Thanks
Sundhu

Did you check Item category assignment?
Sub items in BOM have different item category group (in material master record) and it appears you did not properly assign it.

Copy control for Return Process

HI every one,
I am Doing the Return Cycle Process but i am not sure how to maintain the Copy Control because i am new to return process
Billing Type : ZF2, Item category :ZTAN,Return Order : ZRE, Item category : ZREN, Billing Type : ZG2 (Credit Note)
give me how to maintain the Copy Control in VTFA,VTLA,VTFL
Guideme
Regards,
Anu
Edited by: Anuradha_SD on Sep 14, 2011 12:50 PM

HI
Let us talk about the Copy control VTAF
I maintained the Copy Control Order Type ZRE,
Target SalesDocTyp ZRE                    Source Bill. Type ZF2
                   Sales Return - JICPL                     Invoice - JICPL
DataT 052 Billing doc.header        Copying requirements 021 Billing header
DataT 103 Bill.bus.header data            Copy item number (TICK)
DataT 003 Bill.header partner
Target SalesDocTyp ZRE                    Source Bill. Type ZF2
                   Sales Return - JICPL                      Invoice - JICPL
ItemCat Proposal   G2N                    Item Category      ZREN
                   Request                                   Return Items -JICPL
                                    Copying requirements 303 Always an item
DataT 153 Item from bill.doc.
                                                           Pos./neg. quantity
DataT 104 Bill.bus.item data                               Pricing type         D
DataT 004 Bill.item partner         X Update document flow
bl.pl 0                                                    Campaign Deter.
Target SalesDocTyp ZRE                   Source Bill. Type ZF2
                   Sales Return - JICPL                     Invoice - JICPL
SchdLneCatProposal DN                    Sched.Line Cat.    CP
                   Return - JICPL                           MRP -JICPL
                                    Copying requirements 303 Always an item
DataT 002 Partner item
Like that i maintained but at the time of Return order with reference to Billing Document its not working means
if i take Second time Same billing Document Number system is showing same qty because i have already refered previously
why system is showing same qty why it is not reduced
guide me
Regards
Anu

PricingExchRate type in copy control

Hi all,
i have set up the PricingExchRate type 'E' -> Exchange rate determination according to current date
for copy control delivery to invoice.
Reason is because order could be done a few days ahead of invoicing. And invoice have to be done will the current day exchange rate rather that the order.
But when i have set that, the amount in the invoice is still the same as the order when i create it even though the exchange rate is different in TCURR table.
any ideas where else i need to change?
thanks
dyl

Dear dyl
Go to OBA7, select the document type RV and see whether any value is maintained for "Ex.rate type for forgn crncy docs" under the tab "Default Values".
Please note that If no exchange rate is specified in the document header when entering documents in foreign currencies, the system will automatically select a rate from the currency translation rate table. The system then converts all amounts in the document's line items using this exchange rate.
The system uses the average rate as a default value as long as no other exchange rate type is entered here.
If you do not want to use the average rate (rate type M) as the default value for the document type selected, enter the rate type you want to use (bank buying rate, bank selling rate, group exchange rate, ...) here.
thanks
G. Lakshmipathi

Copy Control Question from FI guy regarding Cr Memo via VA01

Good Morning SD guys-
I need your help as my SD counterpart couldn't help me. I have an enhancement where the business would like to have automatic clearing for invoice and credit memo's via F.13. To do this, I need to understand Copy Control.
Here are the requirements/ current configuration:
Assignment field is the Sales order #
Reference field is the Purchase order #
When I view the Credit Memo under the Document flow (users create credit memo with reference to invoice via VA01): the item category is G2N. The Copy Control does not mirror what I see above. It is blank for Assignment field and reference field.
The Copy Control mirrors F2 (Invoice) LF (Delivery). Our SD consultant couldn't explain to me why this is. Is this correct? Shouldn't Copy Control mirror to that Target Sales Doc type which in this case is RK (Invoice Correct. Req CR)?
If anyone could answer why it isn't logical to me, I would appreciate it.
I don't understand this and I don't see where, other than Document flow the original invoice number is to make this automatic clearing happen.
Thank you.

Hello AMS
In both cases - LF to F2 or equivalent Z- doc types- (VTFL) and CR to G2 or equivalent Z- doc types (VTFA), the header copy control setting should be:
B Sales order number for Assignment Number
and
A Purchase order number for Reference number
However for cancellation type of billing documents, the config from the document type (V) takes precedence.
Also note that reference number and the assignment number can be entered automatically in the billing document by
copying from the sales order
or
automatically determined by the system - I am guessing user exits or some FI config.

Copy control error even though copy control maintained

Hi Friends,
I have searched in several forums to know the reason for this issue but I have not found anything similar to that. Could anyone please throw some light on it
1. When I create invoice (ZXYZ) from delivery (ZABC) SAP gives warning message as Delivery type ZABC cannot be invoiced with billing type F2. I have checked copy control header and item in VTFL (I donu2019t need to check the copy control configuration in VTAF as the initial order is Purchase order not sales order) and everything is correct. There is no copy control configuration between ZABC and F2, but with ZABC and ZXYZ. Not sure why system seeking for F2 when there is correct invoice type ZXYZ. Why is it so? If I enter ZXYZ manually in VF01 system creates it, but it should be derived automatically.
2. Another question is how does SAP know the correct invoice type when there is copy control entries? For example delivery type LF has copy control configuration for invoice types F1, F2, F8 etc. how does system know which invoice type among F1, F2, F8 be taken? If I have a standard order and delivery types for many sales organizations but different invoice types for them. I would configure this delivery type with many invoice types. Then how does system know which invoice type should be taken? We assign sales order type to sales area but not deliveries and invoices so how does it work?
In few threads issues like item category XXXX cannot be invoiced with F2 but i couldnt find similar issue which I have faced.
Any inputs?

1 why system seeking for F2 when there is correct invoice type ZXYZ. Why is it so? If I enter ZXYZ manually in VF01 system creates it, but it should be derived automatically.
It can happen because of 2 reasons -
a. in VOV8, for your sales doc type, in field "Delivery related billing" = F2
b. in VOV8, for your sales doc type, in field "Delivery related billing" = BLANK. but you have made your order type a copy of OR. The the background system is choosing F2
In this field "Del related billing" give ZXYZ and default value in VF01 shall be the same
2 how does SAP know the correct invoice type when there is copy control entries
It is coming from VOV8.
in VF01 you give a document number (order # or delivery #), based on that it goes to the sales document type in VOV8 and chooses the billing type.
You can manually change billing type in VF01, it shall work provided you have done necessary settings in copy control.
To configure if user can bill with order or with delivery, this is controlled in Item category of sales document type, field "Billing Relevance"
There are 2 parts -
part 1 - Which billing type shall be choosen, or manually entered
part 2 - This shall work only if relevant settings are done in Copy control.
+If I have a standard order and delivery types for many sales organizations but different invoice types for them. I would configure this delivery type with many invoice types. Then how does system know which invoice type should be taken?
We assign sales order type to sales area but not deliveries and invoices so how does it work?+
For both delivery (in VL01N) and for invoice (in VF01) you have the option to manually choose the document type (change from default to what you want)
Generally, if you have a different business process (E.g. Rush order) you give specific sales doc type and associated delivery type and billing type in VOV8
But if business process is same and Sales area is different, then you do not change the billing type or delivery type; for reports you can select on the basis of particular sales area or other criterion like sales org.
Having too many document types could be a disadvantage by causing errors and increased manual work (by choosing correct document type etc.)
So, please think how to configure minimum entities in SAP to satisfy your business requirements.
Edited by: Typewriter on Aug 13, 2011 3:24 PM

Item determination from copy control

while copying return order from invoice. the item category is put as G2N in copy control whereas in item category determination the same is put as ZREN.
While creating return order WRT invoice the item category shows ZREN. Pls help to understand the use of item category proposal in copy control.
Regards,
Kanchan

Hi,
the item category is put as G2N in copy control whereas in item category determination the same is put as ZREN.
This two item categories are one from source document and other is for target document
G2N is from source document and ZREN system should propose it in target document so according to this business transaction can behave.
kapil

Invoice To Service Order - Copy Control

Hi All,
I have a business requirement where in as soon as invoice is generated for sold product, a service order should be created for installation and demo. I am using copy control option and for target trnsaction type i have checked the option complete reference without any routine. To copy certain fields i believe i need to write a routine but With options 'Copy Item number' and 'Complet reference' do i get item level details without mentioning in routine program.
Kindly guide how to creae follow from invoice using copy control.
Many Thanks in Advance !!
Regards,
Abhishek Sandhir

Hi Abhishek
I have few queries just to understand the process you are following
1. You are creating your sales order/ invoice in CRM or ECC?
2. Do you want serial number / Component/Ibase information on the service order? If yes then do you have this information on your sales order.
Regards
Naresh

Copy control invoice - order - KDMAT will not be there

Hi Experts!
we create customer orders (in this case credit notes) with reference to an invoice.
the problem is that the field vbap-kdmat is empty in the copy control and so it could not be filled into the new order.
in VTAF we use the copy requirement 153 Item from bill.doc.
in the PO tab of the invoice the customer material is filled (manually)
We don't have set up information in VD51 but we fill the customer material with some information and this should be copied into the returns.
does anyone have an idea how to get the copy control working?
I tried to change the 153 to 151 where the source says:
vbap-kdmat = cvbap-kdmat.
but without the value in vbap (it is empty while executing this code) the field will remain empty.
Thank you in advance
Regards
Daniel Hermann

hi
billing level PO tab customer material number comes through order , here table also VBAP, so actually this PO tab all fields are display mode only ,
when enter the sale order item PO tab level enter the customer material number , then pass to same billing level ,
when billing level you enter manually this data fet at VBAP table only ,
so you assign the copy routine 151 then on kdmat copy billing to credit memo order OR we maintain same kdmat in main order its copy to billing then also copy credit memo also
do this
regards
sankar

Copy control Returns order to invoice or sales order

Hi all,
we are using Sold-to's with a variety of partners and partner types of which all are not being used in the sales order.
Unfortunately when we create a returns order in refernce to either the original sales order or the invoice, we are bing presented with pop ups showing all partners. i.e the original invoice does not have a special partner we use (ZF) but when we create the returns order we are being asked to pick this partner or if there is only one it is populating the partners.
We do not wish this to happen we wish only for the original partners to be copied, i.e. no additions and no requests for us to pick one if there is more than one.
Can anbody advise on copy control settings to manage this we have tried various options but none have worked.

Hello Greenbum
1) You can use your own copy routine in the header ( Copying Control: Billing Document to Sales Document) where for Copying requirements for partner data VBPA- the bottommost Data Transfer routine- you may copy and modify routine FV45C001.
If the above does not work
1) Assign a Partner Determination Procedure with only requisite Partner functions to the 'Return' Order.
2) In the procedure, populate the 'Origin' filed for all the partner functions with X, Y or Z and devise user exit for partner determination- EXIT_SAPLV09A_003.
Let me know how it goes.

Complaint wth ref. to invoice in CRM - Copy control not taken into account!

Hi all,
We are facing problems when replicating return orders (business object Complaint) with reference to invoices in ERP.
The copy control in ERP is not taken into account. Does anyone know if it is possible to check the copy control when replicating the complaint to ERP with reference to the invoice?
The return order is being replicated correctly and the link to the invoice is shown (so, the flow is correct).
But:
1.- The manual pricing conditions in the invoice in ERP are not being copied in the return order.
2.- Some data as the 'Incoterms' is being redetermined from the customer master data and is not being copied from the invoice.
3.- Data related to material is also being redetermined when the order is replicated
The copy control is not being taken into account and we can replicate return orders from CRM to ERP with reference to invoices for which the copy control is not maintained in ERP...
Please help...
Thanks in advance!
Yolanda

Try something like this, in place of ls_input_field_names-fieldname = 'ZZDEP2PVNDPGM'..
ls_input_field_names-objectname = 'ORDERADM_H'.
ls_input_field_names-ref_handle = '100'.
insert ls_input_field_names into table lt_input_field_names.
Edited by: Kevin Alcock on Aug 10, 2009 4:03 PM

Diferente Control Account in A/P Credit Memo copied from A/P Invoice

I have a strange situation in SBO2007. An A/P Invoice for Vendor X was created duplicating an A/P Invoice from Vendor B. The new Invoice was created with a differente Control Account from the assign in BP Master Data of Vendor X. The Invoice waas copied to a A/P Credit Memo but it used the right control account these time. Now I have an Invoice and a Credit Memo that reconcile each other but with different control accounts.. What is the best way to correct or undo these situation ?

Hi,
This problem is solved in B1 2007A SP01 PL12. To prevent this issue, you upgrade your current B1 version to the PL.
The existing problem in the db can be solved by SAP Support. Log a message to SAP support to obtain the solution.
Prior to uprade and log message, check this note 1463211:
Incorrect Control Account when duplicating invoice
Symptom
Create an AP Invoice for a Business Partner(BP1). Duplicate this invoice to another Business Partner(BP2) who has different control account. The journal entry of the duplicated invoice posts the amount to control account of BP1 instead of BP2.
Behavior is reproducible for AR Invoice as well.
Other terms
Control Account, Payables Control Account, Receivables Control Account, Journal Entry, Incorrect Control Account, Duplicate Invoice, JE, SAP Business One
Reason and Prerequisites
Application error
Solution
SAP intends to provide a patch or patches in order to solve the problem described.
The section Reference to Related Notes below will list the specific patches once they become available.
The corresponding Info file of the patches in SAP Service Marketplace will also show the SAP Note number.
Be aware that these references can only be set at patch release date.
SAP will deliver patches only for selected releases at its own discretion, based on the business impact and the complexity of the implementation.
In order to detect whether this issue affect your DB, please run the
following query :
SELECTt1.BaseRef as 'DocNum', t1.transid, t1.shortname [BP code], t1.account [account.jdt1], t0.debpayacct [BP control acct],
CASE
WHEN t1.transtype = '13' THEN 'A/R Invoice'
WHEN t1.transtype = '18' THEN 'A/P Invoice'
WHEN t1.transtype = '14' THEN 'Credit Memo'
WHEN t1.transtype = '15' THEN 'A/P Credit Memo'
WHEN t1.transtype = '204' THEN 'A/P Down Payment'
WHEN t1.transtype = '203' THEN 'A/R Down Payment'
ELSE 'Others'
END
FROM jdt1 t1
inner join ocrd t0 on t1.shortname = t0.cardcode
WHERE t1.account <> t1.shortname and t1.account <> t0.debpayacct
AND TransType in (13, 18, 14, 15, 204, 203)
If the above query retrieves results, please log a support message
via the Service Marketplace referring to this note including all
relevant information.
Apply the solution of the note to solve your problem.
JimM

Copy control - Order to Invoice

Similar Messages

Maybe you are looking for