Need technical Informations to SAP ICR (Interface Design)
I am working on the introduction of SAP ICR in my client company.
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
Ralph Stadter replied
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.
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:
SEQNR (fixed value, e.g. 100)
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:
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
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
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
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,