No update trigger from order based invoices to customs documents

Dear all,
I need your help with the following problem:
In our feeder system we use an invoice type which could be used for deliveries and also for orders.
If I create an delivery based invoice in the feeder system a customs document is created in GTS.
If I cancel this delivery based invoice an update triggers the GTS system and the customs document will also be canceled. This process works quite nice.
Now I create an order based invoice (the same invoice type as delivery based) and a customs document is created in GTS - fine.
But,
If I cancel this order based invoice no update triggers the GTS system. The customs document will not be canceled. That`s wrong.
I have no idea what could be the error. All position types are available and what I mentioned before the invoice type is the same.
Can anybody help me? Thanks in advance.
Andreas

Hi Andreas,
Please go through the following notes, might be a progam error
885838 Empty log during customs document synchronization
885668 Synchronization check deletes data in simulation mode
931335 Table /SAPSLL/CDSYNC not deleted during document deletion
Regards,
Prarit

Similar Messages

User-exit after updating PO from Order response ?

Hi All,
We are looking for a user-exit after the Purchase order is updated from an order response.
With this user-exit we would like to trigger a WF to the user to carry out transaction YE22N, with the WF the user(PO creator) can execute and update the PO.
Any feedback, tips would be helpfull and for sure points reward.
Thanks & Regards,
Nameeth

Hi Anand,
Sorry for the confusion., try to explain here.
During the updation of PO from inbound ORDSP IDoc, we have a transaction YE22N to confirm if the changes in ORDSP is accepted or not.
So we would like to automate this so that after the PO is update/saved from ORDSP IDoc, then we can trigger a workflow to send email to the PO creator.
If its still confusing then, "I would like to know if there is a user-exit or if Workflow can be triggered after updating PO" ?
Regards,
Nameeth

Net value is not reflecting from order to Invoice

Hi,
I need some clarification here: I can able to see the Net value in the sales order but the same thing is not reflecting in to the invoice.
What could be the reason and Error message is : Pricing error in ITEM 000010 in Invoice.
Your suggestions are most welcome.

Dear,
there may be the incomplete in the order. one condition is missing in the sales order.
This is because of condition record of particular condition is not maintained at the time of sales order.
you can update the pricing in the order if Invoice is not generated . If invoice is generated you can update in invoice itself.
If your query wiill be resolved then reward me.
Regards,
Narasimha

Sales order based Invoice Report

Hi Friends
Is there any standard report where i can see the invoice list based on sales order
Regards
Shambhu Sarkar

Dear Shambhu Sarkar
You cannot see sale order reference in despatch sales report with the TCodes suggested already. You have to develop a zee report from Tables VBFA and VBRP.
From VBRP, you can take the preceding document (sale order) reference against billing document and from VBRP, you can take datas like material code, quantity despatched, net value, tax etc.,
thanks
G. Lakshmipathi

Copy Text from Order to Invoice

Hi All,
We are trying to copy the line text from the order line item to the invoice. But we are facing a problem that the header text is getting copied to the invoice correctly but the line text is not copied in to the invoice.
The data is not getting copied to BEA_BDI from CRM_ORDERI whereas the data gets copied from CRM_ORDERI to BEA_BLI.
Can someone help with this
Regards
Rekha Dadwal

Hi
The item text was getting determined using the current determination procedure till May. In May we did a support pack upgrade and this functionality stopped working.
<b>The procedure followed is as follows</b>
Text Object      BEA_BDI
Description      Texts for Billing Item (BE)
Text Det.Proc.   ZBDI0002
Dscrptn Proc.    Billing Item Text
Text Type        0001
Description      Sales text
Sequence        0010
Changes         Display
Transfer Type   Copy
Access Sequence ZBDI0001
Desc. Access    Text Type 0001
Text Object      BEA_BDI
Description      Texts for Billing Item (BEA
Access Sequence ZBDI0001
Desc. Access     Text Type 0001
Sequence         0100
Ref. Object     BEA_DLI
Ref. Object     Texts for Billing Due List
Ref. Text Type 0001
Ref. Text Type Sales text
Regards
Rekha Dadwal

Copy price conditions from order to invoice

Dear experts,
I have a problem I can't solve myself !
When we create an invoice from an order, the conditions are copied using a predefined pricing procedure in customizing ... Now, I think I have a strange problem ... When the conditions are copied from the order to the invoice, the inactive conditions are not copied (which seems normal) ... Now, I would like one inactive pricing condition (ZPRO) to copied always, because this one is mandatorry on invoice and otherwise I get an error while copying ... Is there a userexit where I can force this ? And how do I implement this ?
Thanks in advance for the answers ...
Greetz,
Kurt.

Hi,
Try this.
GO to the VTFA transaction..
Give the source sales document type and target billing type..
Press item button..Choose the item category..
In the pricing type give "D" (Copy pricing elements unchanged)...And check again..
This might work..
Thanks,
Naren

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

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

Excise invoice price is updating with sales order how to change

Dear All,
I am following TAXINN tax procedure.
when any misstake happens in price i have to cancell all the process. from excise invoice to sales document.
even if i am updating the billing invoice and again creating the excise invoice its taking the price from sales order price.
How can i update the price in excise invoice with billing document not with sales document.
Thanks with Regards
Subrat

Actually when we are canceling the excise invoice and updating the billing document with new price and again creating the excise invoice its taking the old price not the updated price.
this is what the problem is .
how system will concider the updated price for excise invoice.
Thanks with Reagrds
Subrat

Sales order value based invoicing

Hi ,
Present setting is that Invoicing is done based on the quantity, is it possible that I can do the invoicing based on sales order value.
2) How to control that Invoicing value and quantity should not exceed the sales order quantity and value.
Regards

Hi
most of conditions used in sales pricing get copied directly from order to invoice, only freight and delivery charges are aded up while generation of invoice.
So functionally if you can estimate freight or delivery charge value in sales order ,you can always maintian routine to be triggered in pricing procedure while invoice generation to indicate whether invoice freight value is exceeding either the individual freight value for sales order or compare total sale order value with total invoice value.
You can set error message if value exceeds than allowed condition value and so the transaction will not be saved.
Alternatively Condition types AMIZ,AMIW can also be used to have a control through estimation.
Create appropriate pricing routines with the help of ABAP developer and apply to condition value. Use statistical condition types for control of conditions.and I think what you are trying to achieve can be done.
Regards
Mandar

Update order user status based on a custom check box value in web ui

Hi Experts,
I have a requirement to Update the user status based on a custom check box value in web ui.
This is needed at the followup for a SR, the component is BT116H_SRVO, Details View.
I created a value node with 4 checkboxes, based on the check box value, the corresponding user status
need to be updated.
How can I reach to the order save functionality of SAP in EH_ONSAVE method, so that syatem can capture my check box value, along with other screen fields, and append the status parameter in Order maintain?
or do I have to call order maintain in even handler for checkbox, which will affect performance .....
Pls help.
Regards,
Lakshmi

Hi,
In your event handler you can use bol entity corresponding to status BTStatusH and change the user status.
Best regards,
Caíque Escaler

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

Price change in order and invoice

Hai Experts.
The current sales prices shall be included in the SD document while creating sales quotations and TA orders.
The same shall be communicated to the customer (quotation resp. order confirmation) and accepted by customer.
Since the item categories are set in such a way that a new pricing is generated. The prices which are valid at the time of billing shall be calculated.
The preferred item categories of the delivery transaction shall be set as pricing type. C = take the manual price component which is incidentally newly established
The price variance shall be calculated as a credit note, which eventually is considered as additional expenditure.
The different prices in the order confirmation and commercial invoice can not be controlled by the processor of the order with the help of feasible expenditure.
while creating order (TA,SO) there should be an option in Additional data B ask for Yes or No.
Yes means the prices changes are allowed.
No means the prices changes should not allow.
How can i do this. what is the process for stoping price changes from order to invoice.
please suggest me
thank you very much.
Varma

Hello
for stopping price changes from order to invoice.
In your billing related copying control (Tcode VTFA- Order related billing & Tcode VTFL -Delv related Billing), in item maintain Pricing type as D - Copy pricing elements unchanged
If in any case you want to change the price after applying above config change, then simply click Update buttomn in condition tab of Item data and as your requirement choose either of the following:
- B - Carry out new pricing for total new pricing
- C - Copy manual pricing elements and redetermine the others for copying manual condition type & chaging other
- G - Copy pricing elements unchanged and redetermine taxes for tax condition type changes
Thanks & Regards
JP

Diff between GR based invoice verification and PO based invoiceverification

Dear Friends
Can any body pl clarify the difference between the GR based I V and
PO based I V and how to configure the above.
regards
rk

Hi,
Gr Based Invoice Verification : In this a separate invoice item is created for each delivered partial quantity.If we make the allocation with the purchase order system then propose more than one invoice item as a default if more than one partial delivery has been posted for the po item.
If we make the allocation using delivery note the system proposes exactly the po items from this goods receipt, plus the the quanties posted.
using gr based we can assign each invoice item uniquely to a good receipts item. Good receipt and invoices matched in po history
In Gr based invoice qty should not be greater than actual delivered qty.
Purchase Order Based Invoice Verification : In this system generates one invoice item in the item list for each po item. The system provides quantity to settle in as difference between total d livered qty and thee total invoice qty.
If we make allocation using delivery note the system determines the relevant po items with their total qty to settle-in the same way as if there was a reference of purchase order.The system will not propose qty relevant in delivery note.
If there are several good receipt the purchase order history will not tell you which invoice came from which vendor.
Br,
Tushar Patankar

Difference between Goods receipt based IV / Purchase order based IV ?

Hallow all !!!
Can anybody please explain the difference between GR based invoice verification and Purchase Order based invoice verification in brief ?
Thanks in advance !

Hi,
PO-based invoice verification
In PO-based invoice verification, items are settled with reference to the purchase order. Settlement can be carried out with respect to all items, irrespective of whether or not deliveries have yet been received.
GR-based invoice verification
In GR-based invoice verification you can effect settlement with regard to each GRs relating to a purchase order separately. In the PO history, each invoice item can be assigned to precisely one GRs.
for more follow the links
http://www.sap-hefte.de/download/dateien/1067/083_leseprobe.pdf
http://www.finance.utoronto.ca/fast/qrg/purch/ir/pocreate.htm
Regards,
Biju K
Edited by: Bijay Kumar Barik on Apr 16, 2008 8:41 AM
Edited by: Bijay Kumar Barik on Apr 16, 2008 2:23 PM

No update trigger from order based invoices to customs documents

Similar Messages

Maybe you are looking for