Describe Condition types

Hi,
I want to clear one thing about TAX Code creation through FTXP..
When we insert values in following condition types...
VAT - Set Off
VAT - Non Deduct
During Purchasing process, which condition type we use for insert and for which one use in Accounting purpose...
please clear...

Please clear that what is the use of Statistics checkbox here...
By marking the statistics field in the Tax procedure against the condition type ,the system will perform the transactions for statistical purpose but not for using the same in calculation.(This indicator causes a surchage or discount to be set in the document statistically (that is, without altering the value).
Also How can we determine that where we use VAT - Set Off or VAT - Non Deduct??
Determination of VAT setoff (JVRD) or Non-deductible (JVRN) is done by Tax codes used, For setoff you need to do GL assignment in OB40.

Similar Messages

How to find out the condition type of the tax code in the PO document

Hi friends,
My questions is how to find out the condition type of the tax code in the PO document.
When you use me23n to display one PO document. In the invoice tab, there is one text field named 'tax code' whose value could be T1, T2, J1, J2 and so on. Beside the text field, there is one button named taxes. When you click the button taxes, it will show you the condition type of the tax code. For example, if the tax code is 'T1', then its condition type 'mwcn'.
I want to use the information on the PO to find out the value 'mwcn' of the tax code 'T1'. Could anybody help to describe the logic?it looks like the value is saved in the table konp. But I don't know the logic. Please describe. Thank you.

Hi,
Hope you have asked for select query..
select single knumh from a003 into wa_knumh
where mwskz = wa_itpotab-mwskz
and kappl = 'TX'
and aland = 'IN'.
select single kbetr from konp into wa_kbetr
where knumh = wa_knumh.
cheers,
Dep

Condition Type VPRS not appearing on some billing items

Hi,
I have a discrepancy between COPA and postings on the FI account. In COPA in transaction ke4i I have assigned the SD condition type VPRS - Internal price to the COPA value field VRPRS u2013 Stock Value.
The problem arises when the outbound delivery is split on several batches. In this case the condition type VPRS does not appear on the invoice for the split billing item and the amount 0 is loaded into to the COPA filed VRPRS for this billing item instead of value that should appear in the VPRS field. And this causes discrepancies between COPA and FI.
Do you know how to solve this problem? Is it possible to make the condition type VPRS always appear on the invoice, also in case when the delivery is sent in many batches?
Best regards,
Marcin

Hi
Welcome to the confusing world of Invoice *** batch split.. The situation you are facing is due to incorrect customization of your position types in SD during billing of the batch split. Plz check note 77414
You can grossly summarize it as below -
When you have batch split - the line items in Out bound delivery and biling can be divided into 2 types HPOS and UPOS i.e. Main Line items and Sub line items.. The note describes of 3 situations.. Your SD consultant will have to decide which situation you fall in... based on that config changes have to be made in SD....
If your billing is done at HPOS level (Main Item) and not at Item splits level or Vice Versa - Then T codes VOV7 and VTFL, you have to make settings accordingly in the fields "Biling Relevance" and "Cost"..
Also, the item category of HPOS and UPOS has to be different - One has to be relevant for billing/Cost and the other not
Apart from VOV7 and VTFL, check your settings in T code 0184.. Your Item catg has to be assigned against :
Delivery Type / usage Type= CHSP/ Item category Group = "Norm"
To correct the invoices already posted, cancel them and repost after making the config changes...
Regards
Ajay M

Condition type manually removed in back-end

Hi!
I am creating a purchase order in SRM. The order is created with a foreign supplier. When replicated to back-end and looked at in ME23N the condition GRWR is 0 when it should be the same amount as the Gross price. When doing an analysis of the Pricing we can see that the condition type GRWR has been removed manually.
The exact message is:
GRWR 008 Condition record exists (removed manually)
When PO is created directly in SAPECC, the condition GRWR is taken into account and populated with value. The condition itself is set up for combination of Incoterms only. The order created from SRM and the order from SAPECC are both using the same calculation schema RM0000.
Any suggestions?
Have I missed a setting in SRM?
Sincerely
Anders Öhrling

Hi,
we have exactly the same issue as you described. Did you find a solution for this problem?
Regards
Stefan

Condition type restriction

Hello Sap Guru's,
In the scenario, how to restrict condition type for manual entries to a particular user?
Regards,
JP

Hi Ashish,
Version 5 of the note 105621 is the earliest still visible one, from the year 2000... which is even before SDN itself
Much of the note is occupied with how to create a custom authorization object to be able to add own code to the exits for doing "whatever" to the condition types.
The later note transfers these exits to BADI's, and keeps the authorization concept previously implemented, albeit it still describes using manual profiles in the reference to the older note - where PFCG roles are the prefered weapon of choice now-a-days.
Yes, I understand that you wanted to "simplify" that part of the blog to concentrate on the general possibility of adding logic based on the condition type.
I think many developers, when faced with the requirement of using an IF statement and not having any understandable authorization concept to work with, have reached out for the bluntest tool in the box to use: sy-uname. But for others this only makes it worse and even less understandable what is going on.
It always reminds me of [this scene|http://www.corbisimages.com/images/42-20041107.jpg?size=67&uid=2597837E-FED2-4E85-AE4C-CECF92B67B45] when I see such things... as do the new sy-unames of Amit and his clones...
Thanks for your patience with my rant and following up on the topic, so that others who use the search can see the full picture and the different (better) options (techniques).
A merry christmas and may all your authority-checks return sy-subrc = 0 in the new year 2010
Julius

Influence of condition type "never" on the rest of the page

Hi all,
I have a question concerning the 'never'-Condition Type of a process.
I thought when setting this attribute, this process doesn't influence my page. But it isn't that way (as described below). Is this a bug, or when does it influence the page?
Here's the whole process of creating the page and the - for me - unexpected behavior:
I created page 1000 with a tabular form with table DEMO_CUSTOMERS, using all available columns and allowed just update as operation.
The Primary key_type is sequence!
For getting a second tabular form on my page I created an additional page (page 12), but here I decided just to select 4 columns (PRODUCT_ID, PRODUCT_NAME, PRODUCT_DESCRIPTION and PRODUCT_AVAIL) from table DEMO_PRODUCT_INFO - the rest as done before.
Now I copied the just created region from page 12 to page 1000 (nothing else). On my original page 1000 I set the ApplyMRU-Process on Condition Type 'never'.
Running this page I get the error:
failed to parse SQL query:
ORA-01785: ORDER BY item must be the number of a SELECT-list expression
If I delete the ApplyMRU-Process (which is set on Condition Type 'never') the two tabular forms are displayed one below the other. I've done so on page 2000 in my test-workspace (after copying page 1000).
If you'd like to have a look, I recreated the whole thing as described above on http://apex.oracle.com/pls/apex (WORKSPACE: ub_test USER: test PWD: test) Application 47200.
Besides: I know that there shouldn't be two tabular forms on one page and that I can't expect the automatically generated processes to work, but ...
Regards Uli

Jari,
i still think this is a bug, obviously the condition of the Process isn't used.
brgds,
Peter
get Syntax Highlighting for the Application Builder: http://apex.oracle.com/pls/apex/f?p=APEX_DEVELOPER_ADDON:ABOUT:0:::::
Blog: http://www.oracle-and-apex.com
ApexLib: http://apexlib.oracleapex.info
BuilderPlugin: http://builderplugin.oracleapex.info
Work: http://www.click-click.at and http://www.wirsindapex.at

Not allow to add condition type, if it already existing

How to setting, if I want to control that not allow to add same condition type, if it already existing in the transaction.
For example,
PR00    100.00 USD/MT
ZDIS       10.00 USD/MT
ZDIS         8.00 USD/MT (Not allow to enter or add condition type)
Thanks!!
Edited by:
Edited by: Kitta on Jan 29, 2008 3:17 PM

Create A routine function for same .
I am given here the code also
Write the following codes given below in include file.
*& Include           ZXVVAU05
Written for restriction in VA02 for Condition type duplication
DATA:   BEGIN OF tXKOMV OCCURS 50.
        INCLUDE STRUCTURE KOMV.
DATA:   END   OF tXKOMV.
data : tab_name(40) type c ,
       ld_len type i , ld_len1 type i .
field-symbols : <tab> type any.
tab_name = '(SAPMV45A)XKOMV[]'.
assign (tab_name) to <tab>.
txkomv[] = <tab>.
describe table txkomv lines ld_len .
sort txkomv by kposn KSCHL .
delete adjacent duplicates from txkomv comparing kposn KSCHL .
describe table txkomv lines ld_len1 .
if ld_len1 ne ld_len .
refresh txkomv .
message e002(zmm) with ' Please remove duplicate condition in item price' .
endif .
4. Save and activate.
This has to be done thru Abap person ,Hope this will solve the problem of yours as it has mine.
regards
Manu Kapoor

Automatic determination of Condition type value

Hi Friends,
I have one requirement here as described below.
In pricing procdure, I have defined 3 condition types for 3 types of taxes i.e. GST, HST and PST as per client requirement. The value of each condition type is fixed i.e. GST=5% of Gross, HST=7% of Gross, and PST=11% gross. These condition types are not applicable always in the PO. My requirement is when user selects any condition type, then system should calculate the condition type amount and value automatically.
Ex. Suppose the purchase price of a material is 100 USD. In the PO, if user selects GST condition type, then 5% should be determined automaticall in the condition type amount and condition type should be calculated accordingly i.e. 5 USD. One important thing is to note that these condition types will be selected by user as per their requirement and the corresponding % of the condition type should be determined automatically.
Please advice.
Thanks & regards
Satya

Hi Satya,
You can achieve this using access sequence.
1. Create one Access Seq or use Existing seq in your system
transaction code OLME
Purchasing --> condition --> Define Price determination proces --> Define Access Seq
2. Transaction M/06 (Condition Type)
Select your condition code (say ZGST) and click onthe detail view.
Assign the Access Seq to this Condtion
In the Manual Entries Field Assign 'C' for manual entry priority.
save the entries.
3. MEK1 - Create Condition Records
Depending upon your access sequence priorties, define the condtion 'ZGST' with its rate applicable.
similarly maintain the other condition code.
After that create Purchase order. In condtion tab, whenever you enter either of these condition system will take the rate from condition records.
Hope it solve ur issue.
Regards,
S Anand

Manual Condition type in Sales Order

Hi,
i need to enter a manual condition type in sales order which should come in % and the value should not come or it should come as zero, Is there any way to make that manual condition value as Zero in sales order.
Ragu

Raghu,
Pls check the OSS notes 392668, that will solve your problem.
The same pasted here for your reference. However, I advise you to download it and then read due to inconsistent formatting here.
Reward if this helps.
When you create documents in which the standard pricing is used to determine condition records as well as to calculate a pricing result, the display and entry of manual entries is not clear in the relevant condition screen (screen 6201 in the SAPLV69A or SAPMV61A programs for releases prior to 4.6A).
This note explains the interaction of manual entries with the attributes maintained in the pricing procedure and in Customizing of the condition type.
Other terms
KAUTO, V/06, V/08, KAEND fields, KOZGF, PRICING_CHECK, LV61AU08, XKOMV_ERGAENZEN_MANUELLE, LV61AA53, manual entries, MANU
Reason and Prerequisites
In the pricing Customizing, the following fields affect the manual entry of complete condition lines or individual condition rates:
Description        Technical name              Maintenance transaction in SD
Access sequence    KOZGF                  V/06 and V/07
'Manu'            KAUTO                  V/08
Depending on the characteristic of the mentioned fields, the pricing condition screen appears as follows:
KAUTO   | KOZGF    | Condition record existing on DB? | Result
Initial | Initial   | -                                | (1)
Initial | Existing | No                              | (2)
Initial | Existing | Yes                              | (3)
Set     | Initial   | -                                | (2)
Set     | Existing | No                              | (2)
Set     | Existing | Yes                              | (4)
Result (1)
A condition line is set for the relevant condition type [KSCHL]. The 'Condition rate' field [KBETR] does not contain a value, but is ready for input. The displayed line serves as an input help or a template for the manual entry.
Result (2)
No relevant condition line is set on the pricing condition screen, in other words, the condition type is missing.
If you enter the condition type manually without entering a condition rate in the same processing step, you get a 'template line' as described in (1).
Result (3)
A suitable condition record that exists on the database is set with amount (= normal, automatic determination).
Both the 'Condition origin' indicator [KHERK] and the 'Condition control' indicator [KSTEU] are set to 'A'.
If you create another line with this condition type and enter a condition rate not equal to zero, a line is set with this condition rate.
The 'Condition origin' indicator [KHERK] as well as the 'Condition control' indicator [KSTEU] has characteristic 'C'.
If, on the other hand, you create another line and enter a condition rate of zero (or do not enter any condition rate) and the condition record that exists on the database has a scale, the system sets the condition rate according to the achieved scale level. If zero is to be set as the condition rate even if scales exist, then use modification Note 179354. If no scale is maintained, then the system always sets zero as the condition rate.
In these cases, the 'Condition origin' indicator [KHERK] has characteristic 'C', the 'Condition control' indicator [KSTEU] characteristic 'A'.
Result (4)
No relevant condition line is set on the condition screen, even though a condition record suitable for the access sequence exists on the database. The pricing analysis displays the message "Manual condition (Condition record exists)". If you enter the condition type manually without entering a condition rate in the same processing step, the record that exists on the database is set. If a condition record has a scale, the system sets the condition rate of the first scale level independently of the achieved scale level.
In this case, the 'Condition origin' indicator [KHERK] has characteristic 'C', the 'Condition control' indicator [KSTEU] has characteristic 'A'.
Thus, the setting variant leading to result (4) serves to suppress the setting of automatically found condition records into a pricing result. However, you can add the maintained record to the already determined pricing result by entering the relevant condition key.

Condition Type Formula--G

Hello All,
What is the calculation type Formula used for? how is it used?
plz explain with some examples?
Thanks,
Viren.

Dear Viren,
The fallowing scenerios you need to use Alternative calculation type.
When the condition type need to calculate the value other than the standard procedure you need to maintain Alternative calculation type.
Example :-1
VAT Rounding
Use
When you present a customer in Slovakia with an invoice in a foreign currency, the system rounds down the koruna VAT amounts, but not in the foreign currency. When you carry out pricing in Sales and Distribution (SD), SAP R/3 automatically does this for you.
Activities
Customizing
For each of the VAT condition types used in the pricing procedure, set the rounding rule to rounding down. You do so in Customizing for SD, by choosing Basic Functions --> Pricing --> Pricing Control --> Define Condition Types --> Maintain Condition Types. In the Rounding Rule field, enter B (Round Down).
In the pricing procedure itself, assign a rounding rule to each VAT condition type. You do so in Customizing for SD, by choosing Basic Functions --> Pricing --> Pricing Control --> Define and Assign Pricing Procedures --> Maintain Pricing Procedures. In the VAT condition types, enter 174 in the AltCTy (Condition Formula for Alternative Calculation Type) field. This rounding rule instructs the system to round these amounts as described above.
Example 2 :-
Other Taxes
Definition
In certain exceptional circumstances it may be necessary to record alternatives to the standard calculation of taxes for an employee.
The Other taxes (Infotype 0235) record may be used for any tax authority.
Tax types
All tax types except withholding tax are displayed and may be adjusted for the particular authority. You may either alter the calculation of the tax by changing the formula used, or exempt an employee entirely from a tax.
Any change you make here will override the standard calculation of the tax.
I hope it will help you,
Regards,
Murali.

Condition type field when Define Pricing Procedure Determination

Hello Gurus,
there is a condition type field when Define Pricing Procedure Determination. what does it mean ?
Many thanks,
Frank Zhang

Here is are the details of various fields while configuring pricing procedure.
A. STEP
This indicates the number of step-in the procedure.
B. COUNTER
This is used to show a second ministep
C. CONDITION TYPE
This is the most important component in the pricing procedure. The rates are picked up from this element, on the basis of the properties described.
D. DESCRIPTION
This forms the description of the condition type.
E. FROM
This is used to define the progression of the calculation and range of subtotals
F. TO
This is used to define the progression of the calculation and range of subtotals
G. MANUAL
This function enables to allow the condition type to be entered manually also apart from automatic pickup.
H. MANDATORY
This function identifies the conditions that are mandatory in the pricing procedure. The sales price is a mandatory condition type.
I. STATISTICS
This can be used to represent the cost price of the material sold, generally used for study statistical impacts of price
J. PRINT
The activation of this function will enable the printing of the values and conditions to the document.
K. SUBTOTAL
A key is assigned from the drop down menu; this can be used by the system in other area like Sis for reporting purpose also
L. REQUIRMENT KEY
This function is used to assign a requirement to the condition type. This requirement can be used to exclude the system from accessing the condition type and trying to determine the value. This can be used to specify that the condition type should only be accessed if the customer has a low risk credit.
M. ALTERNATE CALCULATION TYPE
This function allows you use a formula as an alternative in finding the value of the condition type, instead of standard condition technique. this can be used to calculate complex tax structures.
N. ALTERNATE CONDITION BASE VALUE.
The alternative condition base value is a formula assigned to a condition type in order to promote an alternative base value for the calculation of a value.
O. ACCOUNTS KEY
The account keys form part of account determination. These keys are used here to define the posting of the revenue generated to respective account heads& to subsequent assignment to GL accounts.
PR00- ERL
K007/KA00- ERS.
KF00- ERFu2026u2026u2026u2026.& so On.
P. ACCRUAL KEY.
The accrual keys form part of account determination. These keys are used here to define the posting of the revenue generated to respective account heads& to subsequent assignment to GL accounts and payment to respective parties.
Kalpesh

SAP CIN SD Condition Type Classification link to Account Determination

Hi,
one last Question according to Account Determination. I am facing the problem not to see the link between Condition Type Classification and the Excise Account Assignment Table in Customizing (Logistics u2013 General -> Tax on Goods Movements -> India -> Account Determination -> Specify G/L Accounts per Excise Transaction).
In Pricing Procedure i use the Account Key EXD, but i do not link that one to any Accounts. But i Calculate for example JEXP + JEXQ to JEXT.
I classify JEXP as A/R BED Percentage
I classify JEXQ as A/R BED Quantity Basedt
I classify JEXT as A/R BED Total
In Pricing Procedure i do not assign JEXT to any Accounting Key and thus even not to any account. But it is linked somehow to 'G/L account RG23A BED account' inside the Excise Account Assignment Table in Customizing. Is anybody able to describe how? Is it in another table where just defined: Classification A/R BED Total -> G/L account RG23A BED account. If yes, wich transaction code or which Customizing Path do i need to go to.
Please, need help for my understanding.
Best Regards,
Conrad

Hi
In Pricing Procedure i do not assign JEXT to any Accounting Key and thus even not to any account. But it is linked somehow to 'G/L account RG23A BED account' inside the Excise Account Assignment Table in Customizing. Is anybody able to describe how? Is it in another table where just defined:
These entries are entered manually by FI consultants.System picks these accounts whenever a relevant transaction is executed.
Regards,
Phani Prasad

How to prevent consecutive entries of same condition type in a sales order

Hi,
My client is using manual condition type for the basic price "ZBPR". Now system allowing multiple entry against this condition type in the pricing screen during order creation i.e in the first line if we put Condition Type "ZBPR" and putting some value as amount, then again if I put "ZBPR" as condition type and give some other value as amount then system is allowing this and doing all the subsequent calculation.This is not acceptable by the client.
The functional person regarding this is saying this can be done by using routine.Can some body tell me which routine should I take for this if that is possible by routine and the required code.Also say if there is other way to solve this.
Thanks,
Manas.

Hi ,
u can do it thru VOFM(tcode)--->Menu -> Formulas>condition value , but in this case u need to derive the value of this condition type by using ur own logic.
Re: vofm-routine
Regards
prabhu

How to restrict duplicate condition type in sales order

Hi All
Is there any standard method to restrict user for adding a particular discount condition type more than once in sales order. condition type is manual and its records are also being maitained manually.
Else would I will have to create userexit at sales order level or a routine in pricing procedure. I doubt on creating a rotuine in pricingprocedure because in pricing procedure there is already a restirction to add similar condition type more than once.
Thanks

create a routine and add this routine to the discount condition type only.

Creation of New Condition Type

Hello SAP Folks,
I have one issue related to pricing. See the case is i have to produce an extra cost in the Sales Order which is actually depended
upon the net price. This condition type is percentage based and calculation works in the following way:
Let the new condition type be Z123 and Net price be PR00.
So for year variation 1-2 year, the condition type Z123 will be 1.5 times of PR00
2-3 year, the condition type Z123 will be 2.0 times of PR00
3-5 year, the condition type Z123 will be 3.0 times of PR00
Can anyone throw light on how to configure this condition type ???
Regards,
Sarthak

Hi,
For Z123 Condition type make (V/06)
Cond. class A Discount or surcharge
Calculat.type A Percentage
Plus/minus A Positive
and all other settings are same as Discount condition Type
For making Z123 customize an Discont Condition Type (EX:K004,)
Then while creating the condition record give the percentage as 150% 1-2 yearin valid from and to date,
give the percentage as 200% 2-3 yearin valid from and to date, give the percentage as 300% 3-4 yearin valid from and to date, and save the record. (VK11)
In the pricing procedure For step z123 condition type from which you want the % that is step of PR00 should be mentioned in the FROM and TO column.(V/08)
This will result as per your requirement

Describe Condition types

Similar Messages

Maybe you are looking for