SAP ECC to HANA Migration Prerequisites for Ariba B&I

[Saksham_11]

Hi All,

Our client is planning to migrate from SAP ECC (Oracle DB) to SAP S/4 HANA (Latest Version).

They are using Ariba B&I for the complete PR to Invoice Process.

We need to know what are the prerequisites, and activities to be performed for the Ariba Integration.

Also , if any cutover strategy needs to be prepared before go-live, as there may be some transactions processed after HANA migration (i.e. Invoice Integrated in ECC but paid after migration activity in SAP S/4 HANA)

[shashank_naik · Accepted solution]

Depending on the integration. Assuming, you are currently using Ariba CIG to integrate with ECC and will continue to use it. There are minimal changes on the Ariba B&I side - including system ID changes to repoint from ECC to S4HANA.

New CIG Project will be created referring to existing Project (ECC) to connect to new S4HANA system and setup custom routing / custom fields as required.

As for the data migration, POs, GRs and Invoices with Open Qty needs to be recreated as new documents in Ariba (with pending Qty) and integrated with S4HANA.

[Saksham_11 · Accepted solution]

Thanks for the information.

Yes, we are using CIG

Just to verify, we need to clear/ Pay the invoice documents as well before switching the ECC to HANA?

Ariba will start the process with new, documents and newly integrated master data from the sap s/4 hana system?

[VictorSevilla · Accepted solution]

Hi Saksham,

Based on my experience, it depends how you are migrating the master data from ECC to S4 HANA.

Regarding master data:

Scenario 1 - Master data remains with same values (E.g. Material Groups)

In this scenario, the impact is so low. You create new CIG project and master data will remain in Ariba B&I. When you schedule master data export program, values exported to Ariba will be the same and impact is reduced (E.g. catalogs, unspsc mapping, etc. is not impacted).

Scenario 2 - Master data is changed during migration (new taxonomy, clean trash data and duplicates, etc.)

In this case, the scenario is a little bit complex. Master data need to be analyzed deeper to know impacts, define new mappings, etc. to ensure that transactional and master data integrate properly.

Regarding open FI documents, my recommendation is to try to close as much as possible. For documents that cannot be close, you will have different scenario to analyze (PO invoiced without receiving, PO partial received and fully invoiced, etc.) and you need to define different strategies for each one.

I hope that it will be helpful.

BR,

Victor.

[romitkanugo · Accepted solution]

Dear Shashank and Victor,

Thanks for the information.

Please let us know if we can use custom routing for documents that cannot be closed before migration based on the system ID.

Thanks.