cancel
Showing results for 
Search instead for 
Did you mean: 

duplicate R/3 custom requirement in IPC -- zzkschl and logic in ipc

Former Member
0 Kudos
162

Dom,

My middleware colleague told me that he will implement the Badi: CRM_COND_COM_BADI to fill the fields in the communication structure for ipc to use. Your previous response has:

-> You can't provide KSCHL in the communication structure as that is at item level. There is n condition types to 1 item.

what do you suggest to solve this?

I am trying to understand where to duplicate the logic that is in the R/3 routine 900. My wild guess is that the Badi "duplicate" the logic -- finding the "more_req-nr (in the R3 routine 900 that I posted earlier)" to fill the ZZKOBED in the communicaton structure, so ZZKSCHL does not need to be in the communication structure, unless the KOBED is also on the condition type level? Is KOBED on the item level or per condition type?

in checkRequirement(), case 000 returns false (no requirement), case 900 would need to check ZZKOBED to make recursive call to itself.

Does this wild guess make some sense? please help steer me to the right direction.

Thank you very much,

Yanhui

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Yanhui

I'm thinking that this problem is perhaps too difficult to solve via forum posts!

If (as I suspect) the table is reasonably small (ie < 100 entries) and reasonably stable (ie changes < twice per year) then maybe it would be better to code the table contents into the Java routine.

What do you think?

Cheers

Dom

Former Member
0 Kudos

Dom,

The custom table ZSITCATPRI is a user maintainable table, dynamically modified at maybe irregular time intervals. That means it would be hard to code the table contents into the Java routine -- developers may not even know when this z table is modified, let alone the frequency of the table changes/code modifications.

With my colleague's help, I've realized what you have been hinting us -- The condition type can't be filled in the communication structure. My colleague told me that the condition type is not avaialbe to the BADI before pricing is called, so it is impossible to "duplicate" the logic of the R3 custom routine 900 in CRM_COND_COM_BADI to get the KOBED for theIPC to simply check it to make recursive calls to checkRequirement() -- my invalid guess in my last post.

Can we make RFC calls from IPC? We are thinking that we can duplicate the select statements in the R3 routine as RFC functional modules in CRM, then checkRequirement() in the IPC can call the RFC assuming IPC has the condition type values?

I was not sure if you would see this response, so I also posted a new topic asking help with calling RFC from IPC. Hope you or someone else can help us.

Thanks,

Yanhui