The ZSITCATPRI has composit key of:
MANDT, VKORG, MTPOS, KSCHL, PSTYV, KOBED. So the condition Type is part of the primary key.
The records in ZSITCATPRI table has KOBED=000 (no requirement), 002 or 022 (standard SAP requirement, I see them in the SAPStandardExit.checkRequirement(), I don't need to worry about these requirement, right?). Should I code for 000 in the switch statement in checkRequirement(), thinking return simply false?
I am not sure how to run the field catalog transaction code /SAPCND/CTFC, we seem unable to directly run it? With double checking, we are certain that ZZPSTYV is added to the communication structure (Item), but ZZKSCHL and ZZKOBED are not yet, but my middleware colleague is working on adding these fields to the communication structure now.
Your previous posting asked "Now, what is immediately apparent here is that these routines must be coded and available. I am not convinced that all the preparation work has been done by your colleagues.
In particular, I am interested by this Z table as one of the key fields is Condition Type. I don't know how they can provide this in the communication structure as the communication structure is at pricing document level, whereas Condition Type is at pricing step level." Looking at the key structure of the ZSITCATPRI table, do you still think our design would pose problems?
also, I noticed that the switch statements in the determinRelevantAttributesForRequirement() method has case 701 for both header and item, why 701?