Configuring a Multi-ERP Realm

With multi-ERP support organizations can integrate multiple SAP Ariba sites in a way that allows enterprise-wide data to be shared throughout the organization while site-specific and transactional data remains separate.

Each site can be associated with a separate enterprise resource planning (ERP) system. The level of integration between sites varies depending on the type of configuration implemented. The most basic level of integration provides cross-site reporting. More complex levels of integration also involve partial or full data sharing between sites.

Highly integrated multi-ERP configurations offer the following benefits:

• Cost-effective administration across ERP systems
• Shared data, configuration settings, approval rules, and customization settings
• Shared contracts
• Cross-site reporting (available for all multi-ERP configurations)
• Invoice reassignment capability on invoices from Ariba Network (available for all multi-ERP configurations)
• Shared catalog content
• Suite integration, including contract management integration

The deployment process for multi-ERP configurations involves multiple points of coordination between SAP Ariba and the customer.

There are three specific deployment requirements that sites must meet in a multi-ERP configuration.

1. All child sites must use the same Ariba Network buyer account. This means that all sites use the same account configuration settings, such as transaction rules and catalog validation preferences.
2. Each child site must have its own business application system ID defined in the Ariba Network buyer account.
3. Each site must have its own web address and site name.

SAP Ariba representatives must work closely with customer administrators to deploy single- and multi-variant configurations.

The following table lists the basic steps required for integrating multiple sites into single- and multi-variant configuration.

Data Replication is the process of storing data in more than one site or node. It is useful in improving the availability of data.

It is copying data from a database from one server to another server so that all the users can share the same data without any inconsistency.

Data is replicated by type of object rather than by individual object. For example, all cross-variant user data in the parent site (for example, SharedUser.csv data) is replicated to child sites. You cannot specifically exclude data about individual users.

In multi-variant configurations, only data that belongs to cross-variant data classes—that is, data classes that are not specific to one ERP variant—is replicated from the parent site to the child sites. This includes, for example, cross-variant supplier organization data and cross-variant user data. Variant-specific data classes have a specific ERP shape and are loaded only into child sites.

In single-variant configurations, cross-variant and variant-specific data are replicated.

Cross-variant user data (for example, the data in SharedUser.csv) is replicated from the parent site to all single- and multi-variant child sites.

In single-variant configurations, cross-variant user data (for example, the data in SharedUser.csv) is replicated from the parent site to the child site. Variant-specific user data (for example, the data in User.csv, which holds user accounting data) can either be replicated or not. Child sites can either subscribe to or unsubscribe from this data. By default, single-variant child sites do not subscribe to variant-specific user data, and you load the data into each child site. This allows you to associate different accounting entities to cross-site users in each child site. If you prefer to have all variant-specific user data replicated in a single-variant configuration, make sure an SAP Ariba representative sets the replication settings accordingly.

In multi-variant configurations, cross-variant user data is replicated. After replication, you load variant-specific data into the child site.

In both single- and multi-variant configurations, group data loaded into the parent site is replicated to the child sites. You can modify group membership in each child site. Group membership and child group changes made in a child site do not affect other child sites or the parent site. Approval queues are replicated from the parent site and cannot be deactivated in child sites.

If you import user-related data using the simplified Import User Data (Consolidated File) data import task, then both cross-variant and variant-specific data are available in the UserConsolidated.csv file. The ImportCtrl field in the CSV files enables you to specify which data to load into the parent site and which data to load into child sites.

Cross-variant supplier data is the data in the SupplierOrganizations.csv and SupplierIDs.csv files. Variant-specific supplier data is the data in the Supplier.csv and SupplierLocation.csv files.

However, if you import supplier-related data using the simplified Import Supplier Data (Consolidated File) data import task, then both cross-variant and variant-specific data are available in the SupplierConsolidated.csv file. The ImportCtrl field in the CSV files enables you to specify which data to load into the parent site and which data to load into child sites.

Accounting data is variant-specific. In single-variant configurations, it can be loaded into the parent site and replicated. In multi-variant configurations, it must be loaded into the child sites.

The set of accounting files to import depends on the variant of each child's site.

You can associate cross-site users with different accounting units in each child site, even in single-variant configurations.

In single- and multi-variant configurations, catalog content (items, kits, supplemental attribute definitions, and catalog hierarchy) resides in the parent site. It is not replicated to the child sites. Instead, the child sites subscribe to the catalog data in the parent site.

Child sites can subscribe to catalogs that are active and searchable.

Child sites inherit the system commodity code set and unit of measure from the parent site. You can load additional commodity codes and units of measure into the child sites.

You cannot load catalog content into child sites.

Catalog content depends on the following data in order to function properly:

• Type
• Catalog Hierarchy
• Common Supplier (Suppler Organizations.csv, SupplierDs.csv)
• Commodity Code
• Commodity Code Map
• Unit Of Measure
• Unit Of Measure Map
• Currency
• Currency Map

Strings and enumerations are periodically replicated from the parent site to all child sites.

You cannot upload strings or enumerations to child sites except in the disconnected configuration.

The following list describes replication behavior for approval processes:

• Child sites inherit approval processes and their activation settings from the parent site. In multi-variant configurations, child sites do not inherit approval processes that include variant-specific approval rules.
• In child sites, the names of inherited approval processes have the prefix Inherited.
• Changes made to approval processes in the parent site are replicated to child sites, with the exception of changes to activation settings.
• Approval processes in Draft state in the parent site are not replicated to child sites.
• You cannot modify or move an approval rule in an inherited approval process from within the child site.
• You can, however, add approval rules to an inherited approval process.
• You can disable inherited edit rules and filter rules. You can also copy them and edit the copies.
• If you make changes to an inherited approval process in the child site, those changes are not overwritten by subsequent changes in the parent site. Instead, changes to the approval process in the parent site are merged into the approval process in the child site.
• You can create approval processes in child sites. If you activate an approval process created in the child site, the corresponding inherited approval process is deactivated.
• The CSV supporting file for approval processes (such as approver lookup tables) are replicated only if they are referenced by an approval process in the parent site.