Same condition type used in MM , error?

Hi ,
I am (SD) using the same condition type which is used by MM and maintained different condition records in VK11. when I created STO , MM condition value is posting right , But with relevant to STO and Del , I create billing document , here The condition records what I maintained in vk11 are missing. I have check each and every step. where could be the error exists? cant we use the same condition type used by MM , though we maintained different acceess seq and condition records in VK11?
Thank you,
Kanna Palle.

Hi,
I copied the condition type and changed the name , but its already used by MM. Its a STO process .STO to DEL to IV Billing.I maintained condition records in vk11.In the combination of plant and material , I find different field name for material (but its still named as material and the data element is different from what MM material field). Its confusing I think.
Precisely , I created access seq for plant and material , they field names are z123 and zabc. when I maintained condition records in vk11 , condition record saved in ZAAA and ZBBB fields. now at the time of Billing document , system throws an error saying, * condition record is missing * The system checks z123 and zabc for condition records , which are not there becos they are in the fields ZAAA and ZBBB.
At the time of Acc Seq creation , I tried to pick the same field which it shows in billing document.but that is not available in SD , its available only in ALLOWED FIELDS in MM. Pls Throw some light on this.
Thanks,
Kanna Palle.
Any updates on this Pls?

Similar Messages

Restrict same condition type in pricing procedure

Is there a way to restrict the condition type so that there can only be one occurrence of the same condition type in a order item?
Example:
System reads condition type ZXXX from system, then a user adds the same condition type on the same order item. I would like the system to then give a error message saying ZXXX can only occur once.
Kind regards

Hi,
As this is manual condition and the user are inputing it by themselves then you won't like to change the way the manual changes are maintained/allowed.
What you want that is user have given it once then they should not be able to input is again in the same sales order item. For this you should take help of requirement. Preapre logic that before the condition system check if there is existing condition of this type in this sales order item.
Hope it helps ..

Same condition type on header and item level = printing problem

Hi
I have a customer using some condition types on both item level and header level in quotations, orders, invoices ...
In the pricing procedures it is customized (V_T683S-DRUKZ) that the conditions must be printed on header level (that is at the bottom of the documents).
My job is to make the Smartform to print the documents, and I want it of course to be as close to SAP standard as possible.
SAP standard will print these conditions on header level even if the conditions are at item level, but my customer wants the conditions created on header level to be printed on header level and conditions created on item level to be printed on item level.
I'm no pricing expert, so my question is:
Will it be fair if I tell the customer that using the same condition types on header and item level is bad practices - or at least bad karma?
Best regards
Thomas Madsen Nielsen

Hi Shiva Ram and Madhu
I have no problem understanding header vs. item conditions, so I really don't see anything in oss note 876617, that is relevant in this case.
Madhu - I do not agree that everything is fine. My issue is that I want to stick as closely to SAP standard customizing as possible. In SAP standard customizing of a condition type you can use the flag V_T683S-DRUKZ to determine if the condition should be printed on header OR item level - you can not choose both header AND item level.
I have a SAP standard smartform using two functions modules for reading header and item conditions. RV_PRICE_PRINT_ITEM and RV_PRICE_PRINT_HEAD. These function modules are based on the DRUKZ customizing flag and a condition marked for printing on header level will be supplied by RV_PRICE_PRINT_HEAD even when the condition is on item level.
My point is: SAP standard customizing does not support printing of same condition on both header and item level. I can of course write tons of code to work around this problem, but that would be bad practices

Condition type used for invoice list

Hello Gurus,
following condition type used for invoice list, why do they exit in invoice list:
RL00 MW15. LR00 RD01

Hi,
Please go through the below document
When you work with invoice lists, you need to be familiar with the following concepts:
Prerequisites for invoice lists
Relationship to Pricing
Structure of an Invoice List
Changing header and item data
Integration with financial accounting (FI)
Prerequisites
You can only process invoice lists if the following prerequisite data is defined by your system administrator in Customizing for Sales:
Condition type RL00 (factoring discount) must be maintained and, if required, also the condition type MW15.
An invoice list type must be assigned to each billing type that you want to process in invoice lists. The standard version of the SAP R/3 System includes two types of invoice lists: LR for invoices and debit memos, LG for credit memos.
Copying requirements must be defined (for example, the payer, terms of payment and other fields that must be identical in the documents to be included in the invoice list)
In addition, before you process an invoice list, you must maintain the following master data:
A customer calendar must be defined, specifying the time intervals or dates on which invoice lists are to be processed.
The customer calendar must be entered in the Billing Sales Area view of the customer master record.
Pricing condition records for the condition type RL00 and, if necessary, (e.g. in Germany) the condition type MW15 must be maintained.
Output condition records for condition types LR00 and RD01 must be created.
Relationship to Pricing
The system processes factoring discounts in invoice lists in exactly the same way as other kinds of pricing elements. The data for the factoring discount is stored in condition records. Controlling during document processing is carried out via condition types, pricing procedures and access sequences. This control data is defined in Customizing for Sales by your system administrator.
For further information, see Conditions and Pricing.
Structure of an Invoice List
An invoice list represents an individual billing document. It consists of a document header and document items. Each item represents a billing document that you have included in the invoice list. The header contains an overview of summary information, such as the net value of all documents in the invoice list, the value of the factoring discount, details of taxes, and so on. It also contains information on partners and output.
Changing Header and Item Data
You can change some of the header data - for example, the billing date - when you process the invoice list. You can change an item - either an individual or collective invoice - and display document details. However, you cannot change any data in individual billing documents once they are part of an invoice list.
It is possible, however, to make certain global changes to output in all items in an invoice list.
For further information on output, see Communication in Sales and Distribution Processing.
Integration With Financial Accounting (FI)
The documents that you want to combine within an invoice list must already have been billed and forwarded to Financial Accounting. Here the billing documents intended for an invoice list are blocked for normal dunning transactions.
The dunning block on FI documents is lifted as soon as you create an invoice list and transfer it to FI . The system then calculates the new dunning date for the invoice on the basis of the invoice list date.
In addition, the system enters invoice list numbers in the FI documents as reference numbers. Invoice list numbers can then be entered for incoming payments.
When you save the invoice list, the system automatically creates an accounting document for the factoring discount and possible taxes and posts it to the corresponding G/L account in FI.
Regards,
Murthy

Condition Types used in a particular country

Hi Experts,
I am trying to pull a report of changes made to the condition types using VK13. Before doing this, I would like to know what are the condition types used for a particular country. How can I find out the condition types used for a particular country. Please advise.

Hi Murukan,
As above said we will not maintain condition record for country,until we select the country in our access sequence.
You know the changes made to condition type by the table CDHDR and CDPOS
go to SE16N give the table CDHDR there in TCODE filed give VK12 you will get all changed information regarding that and get the
value in filed CDHDR - OBJECTID pass the same into CDOPS - OBJECTID you can get specific record information.
Check and revert
Regards
Ram

The same condition type calculates different amount !

Hi there,
On the print out of an invoice (VF03) I have realized that two different rows at the end of the invoice with the same description (Min Freight Charge) display 2x different amount of freight, once I check the condition type, on the header level, I see the same condition type (ZS..) with two different amount. Can anybody explain how can the same condition type (Min Freight Charge) be found calculating 2x different amounts
Thanks
Kami

Hi,
Check your pricing procedure at SPRO-> sales and distribution -> Basic functions -> Pricing control ->Define and assign pricing procedures ->maintain pricing procedures.
There might be two condition types used to calculate the frieght value. Each might be assigned with different routines under Alternative formula for condition base value column. I assume only one frieght condition type is needed to calculate the final value with reference to another condition type. Check the settings.
Regards

Condition type used for scrap

hi,
what is the condition type used for scrap in Standard SAP.?Assured points
Best regards,
R.Srinivasan

Dear Srinivasan
Follow the below process:-
1) Go to V/06, either copy the standard or create a new by naming ZTCS and maintain the following:-
- Cond. class::::::::::A
- Calculat.type::::::::A
- Access seq.::::::::::K004
- Manual entries:::::::D
- Item Condition:::::::X
- Text DetPrc::::::::::04
2) Again in V/06, create one more condition type (say ZECT) for Edu.Cess on TCS for which the same values can be maintained as like ZTCS
3) Go to OV34, create an Account key for TCS, say ZTC and ZET for Edu.Cess
4) Go to VK11, input the condition type ZTCS and maintain the required TCS percentage (the combination which you can maintain is for Sales Org / Dis.Channel / Material or as per the requirement demands you). Similarly, you have to maintain the required percentage for Edu.Cess also in VK11
5) Now go to V/08, create a new pricing procedure exclusively for scrap sales and maintain these two condition types there with respective Account Keys
thanks
G. Lakshmipathi

Same condition type different value fields

same condition type is used for
1. sale of product
2.scrap sales
3.spares sales
condition typr (pr00) should be assigned to three diff value fields
(revenue ,scrap revenue &spares revenue) ,because they should not be summed up (need separate value)

Hi,
Can u sum up what is ur exact question/problem?

Condition types used in cin

i have some confusion on cin
what are condition types used in cin with details
and where will assign TAXINJ and TAX INN please give me full details with example if any documents available please send to [email protected]
advanced thanks

<b>TAXINN:</b>
JEXP IN: A/R BED %
JEXQ IN A/R BED
JEAP IN A/R AED %
JEAQ IN A/R AED Qty
JESP IN A/R SED %
JESQ IN A/R SED Qty
JASS IN A/R Assessable Va
JIN1 IN A/R CST
JIN2 IN A/R LST
JLST IN A/R LST
JMAN IN Manual excise
JMOD IN A/R BED ..............................
Regards,
Rajesh Banka
Reward points if helpful.

To change vendor no for condition types using BAPI_PO_CHANGE

Hii,
how to change vendor no for certain condition types using BAPI_PO_CHANGE.
Is it possible .
Any parameter is there.
Plz help urgent
Title edited by: Alvaro Tejada Galindo on Jun 12, 2008 5:23 PM

Hi,
   It is possible.
wa_pocond-vendor_no = wa_konv-lifnr.
wa_pocondx-vendor_no = 'X'.
   wa_pocond-condition_no = wa_konv-knumv.
    wa_pocond-itm_number = wa_konv-kposn.
    wa_pocond-cond_type = wa_konv-kschl.
    wa_pocondx-condition_no = wa_konv-knumv.
    wa_pocondx-itm_number = wa_konv-kposn.
    wa_pocondx-cond_type = 'X'.
    wa_pocondx-change_id = 'U'.
    APPEND wa_pocondx TO it_pocondx.
    CALL FUNCTION 'BAPI_PO_CHANGE'
      EXPORTING
        purchaseorder                = wa_konv-ebeln
      POHEADER                     =
      POHEADERX                    =
      POADDRVENDOR                 =
      TESTRUN                      =
      MEMORY_UNCOMPLETE            =
      MEMORY_COMPLETE              =
      POEXPIMPHEADER               =
      POEXPIMPHEADERX              =
      VERSIONS                     =
      NO_MESSAGING                 =
      NO_MESSAGE_REQ               =
      NO_AUTHORITY                 =
      NO_PRICE_FROM_PO             =
    IMPORTING
      EXPHEADER                    =
      EXPPOEXPIMPHEADER            =
     TABLES
       return                       = it_return
       poitem                       = it_poitem
       poitemx                      = it_poitemx
      POADDRDELIVERY               =
      POSCHEDULE                   =
      POSCHEDULEX                  =
      POACCOUNT                    =
      POACCOUNTPROFITSEGMENT       =
      POACCOUNTX                   =
      POCONDHEADER                 =
      POCONDHEADERX                =
       pocond                       = it_pocond
       pocondx                      = it_pocondx
      POLIMITS                     =
      POCONTRACTLIMITS             =
      POSERVICES                   =
      POSRVACCESSVALUES            =
      POSERVICESTEXT               =
      EXTENSIONIN                  =
      EXTENSIONOUT                 =
      POEXPIMPITEM                 =
      POEXPIMPITEMX                =
      POTEXTHEADER                 =
      POTEXTITEM                   =
      ALLVERSIONS                  =
      POPARTNER                    =
      POCOMPONENTS                 =
      POCOMPONENTSX                =
      POSHIPPING                   =
      POSHIPPINGX                  =
      POSHIPPINGEXP                =
      POHISTORY                    =
      POHISTORY_TOTALS             =
      POCONFIRMATION               =
    COMMIT WORK AND WAIT.

Monthly purchase value,depending on condition type used.

Can we search for PO,depending on condition type used in the PO.eg. we are using a condition ZENT for entry tax and
the requirement is to search the po containing that ZENT condition.In dynamic selection mode there is condition group in
purchase order detail,but it is not selecting the required PO.please guide.

Hi,
This requirement is not possible in std SAP Report.
You need to develop a Z report with the help of ABAPers.
Give proper logic for them for creating this req.
Regards,
Rahul

Same Condition type with different G/L Accounts

Dear All,
Our customer wants to maintain different set of G/L accounts with the same condition types in case of Service tax.
We have three different condition types for Service taxes.
JSV4 - Service tax
JES4 - ECS on Service tax
JSE5 - SECS on Service tax
We have Two different Services
1. R & D Services
2. IT Services
For these two services, service tax condition types are common but we need different G/L Accounts for different Services.
How to achieve this?
Regards,
Mullairaja

Create two tax codes in FTXP, one for R&D Service and another one for IT Services.
Now go to OB40, select the required Transaction, say for example MWS and assign these tax codes with the required G/L Account there.
Finally, in VK11, for tax condition type, assign these tax codes and save.
Now do one sales cycle for each scenario and update the forum.
thanks
G. Lakshmipathi

Standard Condition type used for Manual freight at item level

Hello Gurus
Can you please tell me the standard condition type used for entering freight manually at header as well as item level.
Warm Regards
Prashant Joshi.

Prashanth,
The freight Conditions that we use in Sales are two types
HD00 - Header Level, wherein we have no access sequence
KF00 - Item level, Wherein we have access sequence KF00 - Freight
But you want the condition types to be maintained manually, then you need item details screen of the respective condition type HD00/KF00 using Tcode V/06.
Inside that Manual entry as "C". Similarly you need to maintain or activate "Manual" Indicator in pricing procedure. Then you can enter the freight Manually.
Note:
The difference In applying at the header level and item level is if you enter freight value at the header level it is applicable to all items in the item level. But if you want to apply freight we can give freight to each item or selective item.
Regards
Sathya

How to stop this multiple entry against same condition type in pricing

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 ZBPR 00 , in the second line system allowing to put another value against same ZBPR say for example 2000 & doing all subsequent calculations on the basis of 3000 .which is not at all acceptable by my client .Please suggest how to stop this multiple entry against same condition type

You have to make the condition type as Mandatory and not manual.
If you are entering many condition records of the ZPR0 then the latest entry will be taken for further processing for subtotal rebate and total price.
For all the other entered condition records will have yellow traffic signal which is not active.
you can assign a routine with the help pf your abaper...
In the Transaction VOFM define a requirement such that
you condition type takes value only one at the time of order entry.
regards,
Amlan Sarkar

NAVM / NAVS condition type Use

Hi Experts,
If i am using NAVM/ NAVS condition type in Purchase Pricing Procedure.
While creating PO with these condition typeu2019s price is not added to net price.
But when I post Goods receipt for PO, condition type value hits the inventory.
Can any one tell me what is happening in the background, so that it is not included in net price but it hits inventory during GR.
Any Input is highly appreciated.
Thanks and Regards,
Selvakumar.M

Hi
Actually the Coindition types should get added to the net price, Please check the calculation of net price in your pricing Procedure.
If the Net price is calculated before the Application of taxes then these may be getting added as the effective price but not to the net price.Please check the same
The Functionality of NAVM/ NAVS is working, as per required.
Thanks & Regards
Kishore

Same condition type used in MM , error?

Similar Messages

Maybe you are looking for