Need technical Informations to SAP ICR (Interface Design)

[Former Member]

Dear Experts,

I am working on the introduction of SAP ICR in my client company.

Background:

I have read the ICR documentations for Assignment, Customizing and Handling of ICR, which were attached to the several SAP Notes belong to SAP ICR.

In this context a lot of technical questions coming up, where I can´t find less or even no documentation and now hoping that somebody could help me.

I´m standing now in front of following problem:

A SAP IS-U System shall be connected via RFC to SAP ICR. For this is to say, ICR is leading and dictate the interface. So IS-U had to follow this interface definiton. That means IS-U is not the problem.

For these purposes I had to define an interface in ICR (using BAdI) on which IS-U can connect.

Now my question is, if anybody out there could give me technical informations for this. How an interface in ICU could look like or what are the main fields in ICR tables I had to keep an eye of and are mandatory in an interface in ICR to which other ERP Systems like SAP IS-U can connect.

In general I´m very pleased for any kind of technical infromations to ISU, like table descriptions or programming entry points or any kind of dokumentation, which goes beyond the Customizing Steps and Userhandling of ICR.

Thanks in advance for any response and help

Thomas

[former_member572578 · Accepted solution]

Hello Thomas,

What IS-U tables are you trying to extract reconciliation relevant data from? Do you want the data selection program to call the IS-U system, read the relevant data and include it in the selection program run? Or would you like to start a program in the IS-U system pushing the data into the ICR system?

Best regards,

Ralph

[Former Member · Accepted solution]

HI Ralph,

Thanx for your answer, but as well as you I have no clue about IS-U.

As I mentioned IS-U is not the problem, because ICR dictate the interface, that means that I have to design an interface in ICR, as general as possible. Because IS-U is the first but not the only system which should be adopted to ICR over one (and only one) interface in ICR.

So in conclusion I need infos about ICR datafields, entrypoints and so on and how to design a good interface in ICR without knowing the concret system which should be adopted The reason is that its not clear at the moment what kind of systems should be connected to ICR.

So I had to design a general interface and how other systems connect to this interface is the problem of the systems which want to connect and not mine ; )

[Former Member · Accepted solution]

Sorry I forgot something ; )

In addition I need to say that its clear for me that I had to use Process 003 because the client is working with vendor and customers and as I know I can use Process 003 for G/L Accounts as well

[Former Member · Accepted solution]

Hi Ralph,

Concering to your question, that the data selection program call the IS-U system and read the relevant data and include it in the selection program run.

Yes thats the way I want to implement it over RFC. No need for any action in IS-U for me.

[former_member572578 · Accepted solution]

Hello Thomas,

The solution is quite simple really. All you need to do is specify the IS-U system as the sender sytem for one of the companies in FBIC032.

Example:

Company C1000

SEQNR 100 (you should group logical data sources by using the same SEQNR)

RFC Destination for Data Selection <IS-U System>

Data Source Documents of Current Process

This simply means that function module FB_ICRC_BS_DK_SEL_RFC will be called in the sender system. If you want to make sure that the program does not waste any time looking for open customer/vendor items in that system (provided that there are none) you should restrict the customer/vendor accounts on the selection screen of FBICS3 to accounts which do not exist. That way the program will simply "skip" this part. Toward the end of the processing the function module will call the BADI method CHANGE_DATA_TABLE_SENDER_SYS. Here you can implement any logic adding any document from any tables that you like. The data table snet back to the applicaiton has the structure FBICRC_S_SELECT_003. You can refer to CL_IM_FB_ICRC_001->CHANGE_DATA_TABLE_SENDER_SYS for an example implementation of the method for process 001.

When adding data to the reconciliation process you have to make sure that the following fields are filled so the data is usable within reconciliation:

Company

SEQNR (fixed value, e.g. 100)

Partner

Document Number

Customer Account (RCUST) for Receivables (just has to contain some value so the program knows it is a receivables item)

Vendor Account (RVEND) for Payables (just has to contain some value so the program knows it is a payables item)

Currency Key (RTCUR) which should be the transaction currency

Value in Transaction Currency (TSL) which should be the amount in transaction currency

All other fields are optional but might be useful for reconciliation purposes.

When including data in process 003 you have to remember that the program expects all currently open items to be transferred every time.

One sligh problem with this solution is that CHANGE_DATA_TABLE_SENDER_SYS was not designed for the purpose of adding completely unrelated data. Therefore the interface does not contain any selection restrictions. The main problem with that is that you do not know the key date for open items selection. Here are some suggestions which could help you resolve these issues:

Option #1

Depending on the current data you simply assume what the key date is in your BADI implementation (e.g. if the program runs between the 1st and 10th day of the month assume that you are still looking for open items for the previous month; after that data selection will be for the current month).

No additional effort

Option #2

Implement a mechanism which will determine the information you need. E.g. you could set up a customizing table in your IS-U system where you maintain the necessary selection parameters. Your BADI implementation reads the information from this table and uses the information for open item selection.

Little additional effort for creating the table and maintaining it

Option #3

You create a dummy company in FBIC032 and run data selection for this company each time before actually selecting data. For this company you set the flag Select Data Using BAdI in FBIC032. In this case the BADI method SUPPLY_OTHER_DATA will be called for this company. The interface for this method contains the selection restrictions. You could create and implement a RFC function module in your IS-U systems. This function module will be called and the selection restrictions will be stored in the IS-U system. Then you run FBICS3 for the "real" companies and read the selection information previously stored for the dummy company.

More additional effort than option #2 for creating the (still relatively simple) BADI implementation and the function module

Option #4

You do not try to use the standard selection logic at all and instead create a BADI implementation for SUPPLY_OTHER_DATA for all IS-U companies. In this case you are quite free in your implementation and do not have to make up for the selection restrictions not being passed to CHANGE_DATA_TABLE_SENDER_SYS. However, this implementation may be far more complex. Depending on the overall requirements regarding performance etc. you will have to reimplement large parts of the standard data selection process including paralllel processing and error handling.

Probably more effort than all of the other options

I hope this helps you in your efforts,

Ralph

[Former Member]

Hi Ralph,

Sorry for my late answer but I was ill the last week until now.

Nevertheless thank you for your detailed answeres.

It helped me very much.

But unfortunately this was not my last question.

So I will open a new thread and would be very pleased if you could help me out again ; )

Thank you in advance

Thomas