Condition type PBXX problem

Hi
We have entered a purchase order, where the condition type PBXX is assigned a condition value even though there has been no manual entry.
The analysis of the pricing tells me the following information:
"Condition type PBXX - Message 207 - Condition has been found (without condition record)"
Is there any way we can trace where the condition type PBXX picks up the price from?
Is there anyone who has a clue on why the PBXX has been assigned a price at all?
Regards,
Lars

Hi
You can find it out
Go to condition tab > click on taxex > analysis it will shows all the condition values click on PBXX or PB00 below that you an see the condition maintained doubble click ont he same it will take you to the condition.
Regards

Similar Messages

Condition Type PBXX

Hi,
I created a PO in our production system. Following are the condition types which gets picked based on the process
1. When i create a material and a inforecord in the PO the condition type which is used in J3AP
2. When i create a material and not create an inforecord in the PO the condition type which is used is J3AX
There are instances in my PO where either of the above two condition types are not picked i get this condition type PBXX, any reason as to why this is happenning.
Thanks & Regards
Shabeen Buhary

Hi
As you mentioned
J3AP
J3AX
PBXX
these three condition are maintain in your pricing procedure
1)please check which is required condition and which is manual condition
2) while creating Po which purchasing organization you are using check this it my different for different PO
3) check you vendor master record and check which schema group you have assign in vendor master record purchasing tab
4) check access sequence also for theses condition
5) check condition record for theses condition for material ,vendor and plant combination ,you may have different combination
Regards
Kailas ugale

PO condition type related problem

hi,
when we create a PO then the data of condition type is coppyed from last PO. Can we put the restriction on a perticular condition type to prevent the copy of data for that perticular condition type from the last PO.
please help and explain in delails.
regards,
Aniruddha

HI,
If you do not want to get FRC1 only from last PO, you just maintain the Inforecord and maintain the values except FRC1 conditions. And your pricing procedure , spro-mm-purchasing-conditioins-price determination procedure-Define calculation schema, choose your pricing procedure and click control data , where in FRC1 condition type , you can see a check box M(Manual) , just select and save it.
Now if you create PO the price will be copied from inforecord automatically except FRC1, so you can enter the value by clicking the conditon tab in item detail screen in PO.
regards,
abi

Condition Types PB00 & PBXX

As we know, in Purchase orders, Condition type PB00 flows from Outline agreements/inforecord/Condition records etc, while condition type PBXX is to be maintained manually.Also PBXX if maintained supersedes PB00 i.e is considesed for Gross/Net price calculations.
The requirements at a client's place is as follows:
For most of the regularly procured materials, contracts are maintained. Hence generally the P.O. price will be automatically determined as PB00. However there are cases where P.O is placed at a price which is different from generally agreed price maintained in contracts. In such cases price is to be entered manually as PBXX in P.O.,but the defaulted price should also remain i.e the p.o.should show both PB00 & PBXX so that Purchase Manager's attention is drawn to such cases
The issue is while standard Gross/Net/Tax calculations are taken care of ,subtotals in the pricing schema are going wrong. To illustrate...
Step   Counter   condition type      Description            from      To
10        1               PB00            Gross Price
10        2               PBXX            Gross Price
20        1               R000             Discount                   10       10
                                                  Subtotal (Net price)    10       20
The subtotal(Net price) which is the base for some of the further condition types in the schema , calculated as sum of PB00 & PBXX minus Discount. It should be PB00 minus discount if PBXX (manual price is not maintained) & PBXX minus discount if the same is maintained.
Will appreciate your inputs
Thanks

Dear,
The difference between pricing conditions PB00 and PBXX is :
PB00- automatic pricing - can be used for automatic pricing determination
PBXX- manual pricing - used for manual pricing.
When you maintain the pricing condition for the PO, the system will look at the available condition records (for PB00) and make the automatic pricing determination. In case, such condition records were not defined, then it is mandatory that you have to maintain manually the pricing condition where PBXX will be automatically defaulted in replacement for PB00.
Regards,
Syed Hussain.

Condition type PB00 and PBXX

Dear Gurus,
When system pick condition type PB00 and when it picks PBXX ?
I have made one scheduling agreement having 20 line items. For some line items it has picked condition type PB00 and for rest it has picked PBXX. Why system is picking PB00 for some line items and PBXX for rest ?

Hi,
If you create an Info Record manually or automatically the gross price is entered or adopted is assigned to condition type PB00.
When PO is created with reference to a contract or a quotation a vendor`s gross price for a material is adopted from the Info Record condition. (or where appropriate from PO price history) as default value for condition type PB00.
If no valid info. record condition exists and no order price history can be found, the R/3 system is not able to suggest a price and requires the manual entry of price and a manual entry of net price. The manually entered price is assigned to the condition type PBXX.
These two condition type for the gross price must be available in the calculation schema assigned to the standard PO. In the standard system these are the condition type PO00 and PBXX. An access sequence is assigned to PB00 so that the price determination process can be carried out for this condition type. No access sequence is assigned to PBXX . PB00 must come before PBXX in the calculation schema. You can also use your own comparable condition type in place of PB00 and PBXX.
At the time a PO is created, is the system finds a condition record belonging to PB00 with valid condition, PBXX is irrelevant. PBXX is taken into account only if requirement 6 is fulfilled. Requirement 6 checks the condition exclusion indicator (KOMP-KZNEP).
Hope this lengthy answer clears your doubt(s)!!
Reetesh

Unable to manually change the amount for condition type PB00

Hi Gurus,
My client is using ECC5.0.
Here when I try to change the amount for condition type PB00 using transaction ME22N, I am not able to change the value. I donu2019t get any error, but as soon as I change the value and press Enter the system replaces my entered value with the original value.
Confusing part is that I am able to change the amount of condition price PB00 manually using transaction ME22. I donu2019t have any such problems there.
Also I am able to manually change the amount of condition type PBXX using ME22N.
Only in the case of PB00, if I use ME22N to manually update the amount I am not able to change it.
Kindly help me, to find a reason as to why this could be happening, and correcting if possible?
Thanks in advance,
Imran

Hello Imram,
The purpose of maintaining 2 condition types ie PB00 and PBXX in a pricing procedure is that PB00 is automatic gross price determination and PBXX is manually giving gross price.
If you go to T.Code : M/06 and check the condition types, you can see that PB00 will be having an access sequence but not PBXX.
So if you have to manually give the gross price, you have to use PBXX.
Regards

CONDITION TYPE AND MATERIAL

Hi,
Is there any relation between material and condition type(at item detail level) in PO?
I am making one PO, when i use material 40 (stock) condition type PB00 gets populated automaticaly and in case of material 29708 (account assignment PO), condition type PBXX gets populated. How and where this is controlled?
Regards,
Satyendra

hi,
PB00 is having the access sequence as gross price hence
when u have created inforecord,contract or scheduling aggrement the values will be copied from there only.
for PBXX u need to maitain the value manualy because it is not having the access sequence.
regards,
sujit

Related to condition types and access sequence

Dear all,
i want to know abt one scenario, m using a pricing procedure with my service PO: ZVSTOT, in this Procedure, 12 condition types are there, during searching i found tat 3- 4 condition are are using different different access sequence, so i want to know tat in what procedure, we do it, what is use of it.?
plz reply me.

Hi Nisha,
Prcing procedure configured in your service PO PO: ZVSTOT, Based on this pricing procedure system adopted the condition type in PO.
Please go through this below link to better understanding the MM-Pricing procedure
http://it.toolbox.com/wiki/index.php/Pricing_Determination_Process_-_MM
http://www.sap-img.com/materials/steps-for-mm-pricing-procedures.htm
CONDITIONS OR PRICING PROCEDURE or PRICE DETERMINATION PROCESS
We deal with the Pricing Procedure for vendors.
PB00 Gross Price (info record, contract, scheduled Agreement)
PBXX Gross Price (PO)
FRA1 Freight
RA00 Discount on net
RA01 Discount on Gross
ZA00 Surcharge on net
SKT0 Surcharge / discount
ZPB0 Rebates
MWVS Input Tax
MWAS Output Tax
BASB Base Amount
RM0000 Calculation Schema or Pricing Procedure
(PB00 & PBXX)
RM0002 Calculation Schema or Pricing Procedure
(PB00)
PB00 --> AB00
Copy the Standard one and create new one (ours)
RM0000 contains all the condition types
Pricing Procedure (PP)
We define the pricing procedure to define condition supplement for the material price. The condition supplement specifies the discount, surcharge, freight etc that we want a system every time to access material price condition records.
The total value of the material is calculated or based on all addition and subtraction i.e. discounts, surcharge, tax freight etc
Condition Table
It is a table, which defines the structure of condition record key.
Condition Record
It is a data record used to store conditions or condition supplements, i.e. condition like, discount, freight, and surcharge, Tax etc.
Condition Type
It is used for different functions. In Pricing the condition types leads you to differentiate different types of discounts, in output determination, batch determination, difference between two output types, such as delivery note or order confirmation, between different strategy types
Access Sequence
It specifies the order in which system searches or access the condition records from condition table
Difference between PB00 & PBXX
1. Condition maintained in PB00 is time dependent whereas PBXX is time independent.
2. Condition type PB00 u2013 used for IR, RFQ, Contract, Schedule Agreement
Condition type PBXX u2013 used for PO.
Calculation Schema
The main function of calculation schema is to provide framework of steps for the price determination process to specify the discounts, surcharge, freight rebate etc.
It also determines the sequence of conditions that are to be followed and in which sequence.
Schema Group Vendor
The main function of it is to identify or to pick the right process and conditions for a particular vendor.
Schema Group Purchasing Organization
Key that determines which calculation schema (pricing procedure) is to be used in purchasing documents assigned to the relevant purchasing organization.
Schema Group
It allows to group together the purchasing organizations, which uses the same calculation schema.
Steps: -
1. Create Access sequence
2. Create condition types
3. Create pricing procedure or calculation schema
4. Link pricing procedure & access sequence to condition type
5. Create schema group for vendor
6. Create schema group for purchase organization
7. Assign schema group vendor-to-vendor master record in purchasing data view
8. Assign schema group purchase organization to our purchase organization
9. In inforecord purchase organization data enter condition types and pricing or calculation procedure
CUSTOMIZE SETTINGS: -
SPRO > IMG>MM>PUR>Conditions -->Define price determination Process
1. Define access sequence
2. Define Condition type
3. Define cal. Schema
4. Define schema group
o Schema group vendor
o Schema group purchasing group
5. Assignment of schema group to PUR org
6. Define schema determination à determine cal schema for standard PO.
With Thanks,
Thiru

PO BAPI Problem in condition types

Hi,
I am facing a strange problem in creation of PO through "BAPI_PO_CREATE1".
In the Item condition internal table, I am passing the condition types.
The PO is getting created successfully.
Eg. I pass conditions and their values as follows:
PB00 : 1000
ZB00 : 1000
FRB1 : 1000
The PO is created successfully and we can check the prices updated properly.
Now,
When I create a second PO with the same values, the prices are taken from the last PO and the prices from
my code(which are passed through BAPI) are added to the last value.
If I run the program with the same values as above, the PO is created with the values 2000.
Third time it is 3000 and so.
The value from the last PO is coming into the new PO.
Please advise me if anything missing.
My code is below::
================
*& Report ZTEST_PO
REPORT ZTEST_PO.
data : HEADER like BAPIMEPOHEADER .
data : HEADERX like BAPIMEPOHEADERX .
data : POITEM like BAPIMEPOITEM occurs 0 with header line.
data : POITEMX like BAPIMEPOITEMX occurs 0 with header line.
data : POSCHEDULE like BAPIMEPOSCHEDULE occurs 0 with header line.
data : POSCHEDULEX like BAPIMEPOSCHEDULX occurs 0 with header line.
DATA : RET LIKE BAPIRET2 OCCURS 0 WITH HEADER LINE.
DATA : ret1 like bapiret2.
Data PO like BAPIMEPOHEADER-PO_NUMBER.
data : pocond like BAPIMEPOCOND occurs 0 with header line.
data : pocondx like BAPIMEPOCONDX occurs 0 with header line.
*pocond-CONDITION_NO = '00000'.
pocond-itm_number = '000010'.
pocond-COND_ST_NO = '001'                                   .
*pocond-COND_COUNT = '1'.
pocond-COND_TYPE = 'PB00'.
pocond-COND_value = '500'.
pocond-CURRENCY = 'EUR'.
pocond-CURRENCY_ISO = 'EUR'.
pocond-CHANGE_ID = 'I'.
APPEND POCOND.
**pocond-CONDITION_NO = '00000'.
*pocond-itm_number = '000010'.
*pocond-COND_ST_NO = '10'                                   .
*pocond-COND_COUNT = '2'.
*pocond-COND_TYPE = 'PBXX'.
*pocond-COND_value = '555'.
*pocond-CURRENCY = 'EUR'.
*pocond-CURRENCY_ISO = 'EUR'.
*pocond-CHANGE_ID = 'U'.
*APPEND POCOND.
**pocond-CONDITION_NO = '00000'.
*pocond-itm_number = '000010'.
*pocond-COND_ST_NO = '20'                                   .
*pocond-COND_COUNT = 0.
*pocond-COND_TYPE = 'ZB00'.
*pocond-COND_value = '666'.
*pocond-CURRENCY = 'EUR'.
*pocond-CHANGE_ID = 'U'.
*APPEND POCOND.
**pocond-CONDITION_NO = '00000'.
*pocond-itm_number = '000010'.
*pocond-COND_ST_NO = '30'                                   .
*pocond-COND_COUNT = 0.
*pocond-COND_TYPE = 'FRB1'.
*pocond-COND_value = '777'.
*pocond-CURRENCY = 'EUR'.
*pocond-CHANGE_ID = 'U'.
*APPEND POCOND.
*pocondx-CONDITION_NO = '00000'.
POCONDX-ITM_NUMBER = '000010'.
POCONDX-COND_ST_NO = '000'.
*POCONDX-CONDITION_NOX = 'X'.
*POCONDX-COND_ST_NOX = 'X'.
POCONDX-ITM_NUMBERX = 'X'.
*POCONDX-COND_COUNT = 'X'.
POCONDX-COND_TYPE = 'X'.
POCONDX-COND_value = 'X'.
pocondX-CURRENCY = 'X'.
*pocondX-CURRENCY_ISO = 'X'.
pocondX-CHANGE_ID = 'X'.
APPEND POCONDX.
HEADER-COMP_CODE = 'TF01'.
HEADER-DOC_TYPE = 'DMPO'.
HEADER-VENDOR = '0000000317'.
HEADER-LANGU = 'EN'.
HEADER-PURCH_ORG = '1001'.
HEADER-PUR_GROUP = '110'.
HEADER-CURRENCY = 'EUR'.
HEADER-DOC_DATE = '22.10.2007'.
HEADER-REF_1 = '999999999999'.
HEADERX-VENDOR = 'X'.
HEADERX-PURCH_ORG = 'X'.
HEADERX-PUR_GROUP = 'X'.
HEADERX-REF_1 = 'X'.
POITEM-PO_ITEM = '00010'.
POITEM-MATERIAL = '00042199730L'.
POITEM-PLANT = '1000'.
POITEM-STGE_LOC = '1030'.
POITEM-MATL_GROUP = '01'.
POITEM-QUANTITY = '10'.
POITEM-PRICE_UNIT = 500.
poitem-calctype = 'C'.
append POITEM.
POITEMX-PO_ITEM = '00010'.
POITEMX-MATERIAL = 'X'.
POITEMX-PLANT = 'X'.
POITEMX-QUANTITY = 'X'.
POITEMX-PRICE_UNIT = 'X'.
append POITEMX.
POSCHEDULE-PO_ITEM = '00010'.
POSCHEDULE-DELIVERY_DATE = '30.10.2007'.
append POSCHEDULE.
POSCHEDULEX-PO_ITEM = '00010'.
POSCHEDULEX-PO_ITEMX = 'X'.
POSCHEDULEX-DELIVERY_DATE = 'X'.
append POSCHEDULEX.
CALL FUNCTION 'BAPI_PO_CREATE1'
EXPORTING
    poheader                     = HEADER
    POHEADERX                    = HEADERX
POADDRVENDOR                 =
TESTRUN                      =
MEMORY_UNCOMPLETE            =
MEMORY_COMPLETE              =
POEXPIMPHEADER               =
POEXPIMPHEADERX              =
VERSIONS                     =
NO_MESSAGING                 =
NO_MESSAGE_REQ               =
NO_AUTHORITY                 =
NO_PRICE_FROM_PO             =
IMPORTING
   EXPPURCHASEORDER             = PO
EXPHEADER                    =
EXPPOEXPIMPHEADER            =
TABLES
   RETURN                       = RET
   POITEM                       = POITEM
   POITEMX                      = POITEMX
POADDRDELIVERY               =
   POSCHEDULE                   = POSCHEDULE
   POSCHEDULEX                  = POSCHEDULEX
POACCOUNT                    =
POACCOUNTPROFITSEGMENT       =
POACCOUNTX                   =
   POCONDHEADER                 = POCOND
   POCONDHEADERX                = POCONDX
    POCOND                       = POCOND
    POCONDX                      = POCONDX
POLIMITS                     =
POCONTRACTLIMITS             =
POSERVICES                   =
POSRVACCESSVALUES            =
POSERVICESTEXT               =
EXTENSIONIN                  =
EXTENSIONOUT                 =
POEXPIMPITEM                 =
POEXPIMPITEMX                =
POTEXTHEADER                 =
POTEXTITEM                   =
ALLVERSIONS                  =
POPARTNER                    =
POCOMPONENTS                 =
POCOMPONENTSX                =
POSHIPPING                   =
POSHIPPINGX                  =
POSHIPPINGEXP                =
NFMETALLITMS                 =
if RET-type NE 'E'.
      CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
        EXPORTING
          WAIT   = 'X'
        IMPORTING
          RETURN = ret1.
write : ' PO Created : ', PO   .
    ELSE.
      CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'
        IMPORTING
          RETURN = ret1.
    ENDIF.
================

Any input??

Condition type PB00 and PBXX, coming in the same PO Item

Hi,
In the PO (created with reference to Outline Agreement), condition types PB00 and PBXX are coming in the same line item.
In the PO output, the PB00 value is also showing up and PBXX value is also showing up. User entered PBXX value as 350000 dollars which is right, however system is picking 1.2 million dollar of PB00 from outline agreement which is not intended here. As a result of that the output going to Vendor is exceeding more than 1.2 million dollar instead of 350,000 dollars. I cannot change or delete any othe condition types.THis is a production problem.
Has anyone faced this problem. I appreciate your reply in advance.
Thanks,

Well, thanks Saurav and Prabhakaran, however the problem still stays.
The contract is created for services (1 lot), so the dollar amount can vary depending upon the service rendered by the consultant.
That mean user will only enter the service amount.
Saurav, system should not copy down PB00, it should come by itself when user enters the specific amount. And it comes from contract. PBXX should only appear if there is no PB00 maintained in the contract. This is not the case. The service amount is maintained in the contract. Also, I don't think that PBXX and PB00 should come in one line item together as normal system behaviour & as a normal business process too. Moreover, it is not happeniing in the other two line items - line item 20 and line item 30 are fine. The pricing analysis shows both the conditions as found - PB00 and PBXX, so I could not take any clue from analysis too.
Prabhakaran, system is only behaving incorrectly for line item 10. It is behaving as expected (good ) for other line items and other PO's. So, we cannot touch the pricing procedure as that will affect other line items.
Regards

Problem with pricing condition type in case of proforma invoicing

Hello All,
the problem is related to a pricing condition type in case of proforma invoice where the details are as follows -
Name of Condition Type - ZADC - Add 10% on Cost                                         Access seq.   Z038 Diff
                                                                                Plus/minus    A Positive
Cond. class - A Discount or surcharge
Calculat.type - A Percentage
Cond.category - Blank
Manual entries      D Not possible to process manually
Amount / Percent - Checked
Item Condition - checked
Scale Basis - Quantity
Currency Conversion - Checked
Quantity Conversion - Checked
This condition type has been kept as statistical in the pricing procedure. Still in the proforma invoice the condition type is not getting reflected automatically , whenever I am updating with " carry out new pricing " option the condition type is getting populated.In case of other commercial invoices this very condition type is getting populated automatically without any updates.Along with this point to be noted is that the Condition type in which the actual costi is captured has been kept active.
What more needs to be configured or what are the changes to be done to populate the condition type automatically as statistical during the time of proforma invoicing?
Thanks & Regards
Priyanka Mitra

Hi,
Kindly do the pricing analysis and check whether you have the following error such as
Inactive condition type because of subsequent price,
Regards,
Ravi

Problem in Sales Order with specific condition type.

Hello Experts,
I'm facing a problem in sales order creation for a specific condition type.
the actual scenario is as below,
We have created a new condition type for special discount.This condtion type is applicable only for specific sales channels.Also the discount percentage has to fetched from a custom table.
To achieve this I've written a user exit "RV64A999"
In the FM, i've calculated the subtotal and fetched the discount percentage and calculated the discount amount. After implementing this, the SO were been created properly. for all the line items the discount amount was getting calculated properly.
But then I added a condition at the top of code in exit that the calculation for the new condition type should happen only for selected sales channels.
But after adding this condition in code, i'm facing problem. Now when I create/ change any SO, the discount amounts are getting calculated incorrectly. I'm getting discount amount even if the line item subtotal amount is zero (0).
Any help or pointers reagrding this issue will be very helpful and highly appreciated.

Hi ..
Check your config. again or debug the routine code with your ABAPer and find the problem area.
-Maharshi

Problem of DIFF (Rounding Off) Condition Type in Sales Pricing Procedure

Hi All,
This problem is related to Sales Order. The system is not picking up a condition type in the pricing procedure.
For example when I am raising a sales Order where the Trade Price is being calculated with the help of a Alternative Calculation Type , Subtotal 1 , X in the the Print column and Posting Key ERL are assigned to it.Here in the end the condition type DIFF is not getting populated in the pricing though it is maintained in the pricing procedure. When I am checking in the pricing analysis the error message and its detailed description which is shown as follows -
DIFF 011 Condition ignored (requirement 013 not fulfilled)
The requirement 1. was assigned to this condition in the pricing procedure. This requirement was not met in the preliminary condition step, and so the condition was excluded from further processing.
You can use Additional information to display the requirements used.
Now considering the above scenario please suggest to attain my requirement.
Thanks & Regards
Priyanka

Dear Priyanka,
The "reqt" field in the pricing procedure basically tells d system that the routine mentioned in this field is a sort of prerequisite without fullfilling of which the associated condition type will not get xecuted.
In ur case u have selected "1" which is for condition types A001, B001 etc used in "material listing / xclusion" function.
For condition type DIFF, the correct value is "13" i.e "Rounding as per T001R".
So just replace "1" with "13", things will b fine.
Please close the thread if answered.
regards
Param

Problem in Copying Pricing Condition Type

Hi All,
This problem is regarding copying pricing condition type in Sales Order. The problem is given below with an example -
Qty of Material A - 10 PC.
Condi Type   Amount Currency   Per UOM Condition value Currency
ZP06             100         INR          1     PC      1000.00             INR
ZP07                2         INR          1      PC         20.00             INR
ZP08               98        INR          1      PC        980.00             INR      Statistical
ZP01               98        INR          1      PC        980.00             INR      Mandatory with ERL A/c Key Active
The condition types ZP06 & ZP07 have access sequence maintained for them and ZP08 has been derived deducting ZP07 from ZP06.
I want the above mentioned scenario where the values of Condition Type ZP08 which is a Statistical Condi Type will be copied exactly & entirely to condition type ZP01 where It will remain active alongwith posting key ERL.
I have tried copying it by 100 % copy but the value is getting changed as 100% instead of 98 INR.
Considering the above scenario please suggest some soluitons.
Thanks & Regards
Priyanka

Hi Tarpan,
First of all thanks for checking my post.
In the problem I am not looking for the value of ZP08 to be maintained manually.I want the system to copy the exact details of ZP08 to ZP01 entirely where the condition type ZP01 will remain active alongwith the posting key ERL.
I have tried copying the condition type ZP08 by using 100% copy of condition type but in ZP01 the resultant value becomes 100% in place of 98 INR.
Please suggest some solutions.
Thanks & Regards
Priyanka

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 PBXX problem

Similar Messages

Maybe you are looking for