Hi Yanhui
Now that all the attributes are being passed in the communication structure, you can code your routine without worrying about SELECT statements.
Your routine simply has to give a boolean true or false output. In ABAP this is achieved by the value of field SY-SUBRC - this return code is checked, 0 = true, anything else = false.
The first thing to do is to program the
determineRelevantAttributesForRequirement
method. Not all communication structure attributes are provided to the user exits. So, work out the ones you need.
These may be named differently in the field catalog to the field names you gave above.
Ask your colleagues for the names, or check in CRM - go to the field catalog transaction /SAPCND/CTFC . Often a 'ZZ' is prefixed to the field name to avoid conflict with future SAP standard fields. I'll assume that this has happened from now in this post.
So, your
determineRelevantAttributesForRequirement
method would look something like this:
public String[] determineRelevantAttributesForRequirement(
boolean headerAttributes, int reqNo) {
// String of relevant attribute names to return
String[] relevantAttributes = new String[0];
// Header?
if (headerAttributes) {
// KOMK fields
switch (reqNo) {
case 701:
// Nothing needed at header level
break;
}
}
// Item
else {
// KOMP fields
switch (reqNo) {
case 701:
relevantAttributes = new String[]{ "ZZKSCHL", "ZZKOBED", "ZZPSTYV" };
break;
}
}
// Return the determined string of attributes
return relevantAttributes;
}
And then you will be able to access these attributes in your new routine.
You need to register your new routine also. It is number 900. This is done in method
getRequirementNumbers
:
public int[] getRequirementNumbers() {
return new int[] { 900 };
}
Now you can code the actual requirement. This is done in method
checkRequirement
. A switch takes place depending on the requirement number.
public boolean checkRequirement(IConditionFindingManagerUserExit item,
IStep step, int reqNo) {
switch (reqNo) {
case 900: //This is our special requirement
// *** Logic will go here, see below
default:
throw new FormulaNotImplementedException(item, "requirement", reqNo);
}
}
Now you need to code the actual logic.
Your ABAP requirement has an X_VALID field that is used to keep track of the true/false status.
In the same way, you can declare this at the start:
boolean x_valid = false;
And return it at the end as the result:
return x_valid;
In the middle, we need to add the custom logic. Now, one of the things they do in the ABAP is that if a different pricing routine is specified in table ZSITCATPRI field KOBED, then they perform that routine to get the true/false.
So, you could do the same thing - get the KOBED value from the communication structure as an integer:
int kobed = Integer.parseInt(item.getItemAttributeValue("ZZKOBED").getValue());
Remember I am assuming KOBED has a ZZ prefix in the field catalog.
And then we can call that routine (we are calling the same method we are in, but with another requirement number, not 900):
x_valid = checkRequirement(item, step, kobed);
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.
Is their design fixed? You may end up being forced to read this Z table from within the pricing routine. This is possible but should be avoided. I am sorry, but your work is not easy due to the ABAP design.
Good Luck
Dom
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.