Configuring Common Settings

A purchasing unit (also called procurement unit) is an SAP Ariba concept that lets you separate spend activities by entities such as departments, business units, purchasing organizations, cost centers, divisions, and so on.

You can make the purchasing unit object specific to the SAP Ariba solution, or you can map purchasing units to objects defined in your Enterprise Resource Planning (ERP) system. For example, in an SAP Ariba system configured as a PeopleSoft variant, purchasing units can represent PeopleSoft business units.

Here are some features that purchase units can offer:

• Assign approvable documents (approvables) to a purchasing unit (usually the requester’s). For example, when a user from PU_111 submits a purchase requisition, the purchasing unit field on the requisition displays PU_111.
• Filter purchasing units in the user interface to place constraints on the menu selections available in approvables. For example, when users create requisitions, the Supplier options include only the suppliers mapped to the users’ purchasing unit and parent purchasing units.
• Send approval requests only to approvers relevant for specific purchasing units.
• Restrict the search results, report output, and manage operations (such as Manage Contracts or Manage Invoice Reconciliations) displayed to users based on specific purchasing units.
• Purchasing unit filtering for contracts supports selection of the best contract terms during requisitioning or invoicing within a business hierarchy and enhanced selection of parent agreements during sub agreement creation.
• Import receiving tolerances specific to purchasing units.
• Purchasing unit-specific branding on purchase orders (contact SAP Ariba Customer Support to configure).

There are two types of associations you can make between users and purchasing units: mapping users to purchasing units they belong to, and configuring users to have group responsibilities.

• Map users to the purchasing units they belong to in the file User.csv. Each user belongs to one purchasing unit. This mapping determines which purchasing unit is listed in approvables created by the users.
• Configure users to have group responsibilities that span multiple purchasing units in the file ResponsibleUser.csv. Users can act on approvables from any purchasing units for which they are responsible users. Configuring responsible users affects approval flows and can affect the visibility of data in search and manage operations and in reports.

Various types of data can be mapped to purchasing units. This data includes suppliers and accounting entities such as cost centers or business units.

Differentiating sets of data, and associating users with purchasing units can affect which data users can see in choosers, search results, and reports.

The type of ERP you use (PeopleSoft, SAP, or Generic) determines which data you can map to purchasing units.

When enabled, the visibility control feature is a key part of purchasing unit implementation.

Visibility control places visibility constraints on search results, user pick lists, and reporting. The data users see is based on the purchasing unit and responsible user assignments. Depending on the type of data, users can see data in their own purchasing unit or the purchasing unit they are responsible for. Users can also see data for purchasing units that are either up or down the purchasing unit hierarchy.

Visibility control extends the "responsible user" concept in approval flows. Approvables are routed only to approvers in the relevant purchasing unit.

Depending on the purchasing unit features you want to use, there are different steps you must take to implement purchasing units fully.

These steps include:

• Having SAP Ariba Customer Support enable the visibility control feature.
• Having SAP Ariba Customer Support enable filtering of contracts during contract creation.
• Importing purchasing unit data through the PurchasingUnit.csv file using the Import Purchasing Units data import task.
• Assigning users to purchasing units in the User.csv tile and running the Import Users data import task.
• Assigning user to be responsible for specific purchasing units on behalf of their groups.
• Mapping purchasing units to the appropriate accounting entity from your ERP system (for example, cost center or business unit).
• Differentiating sets of data by purchasing unit (for example, suppliers), by mapping and importing the data to purchasing units using the CSV files that have field for purchasing unit information.
• Updating the approver lookup tables RequisitionLimit.csv and ExpenseLimit.csv if you have approval rules based on requisition limits or expense limits that you want to take purchasing units into account.
• Having SAP Ariba Customer Support configure purchase order branding to have purchase orders branded by purchasing unit.
• Setting up and importing the file ReceivingTolerancesByPU.csv to configure receiving tolerances specific to purchasing units.

Account default settings grant the ability to default Accounting and Ship To information to a User's Profile and commodity code.

These settings help limit the actions a user has to take by eliminating the need to populate information manually each time they add an item to their shopping cart and check out. Instead, the information is already prepopulated for them.

Account default settings are configured through the Import User Data (Consolidated File). This file should be populated with the master data elements defaulted to each User.

The Import User Data (Consolidated File) imports data from a single CSV file, UserConsolidated.csv, and contains both enterprise and ERP-specific data consolidated from multiple CSV files used by multiple data import tasks. It allows you to import all user-group mapping related data using a single CSV file instead of several different files.

Accounting can be defaulted on Requisitions in the following ways:

• Who is purchasing the Item – User’s Cost Center (On-Behalf Of).
• What is being purchased – Typically General Ledger (GL) Account. (Defaults can be defined per a combination of commodity code / dollar amount).

If there is overlap with the default from the user’s profile, the commodity-based values take precedence.

On a requisition or non-PO invoice associated to a contract - If there is overlap with the default from the user’s profile or commodity code, the values on the contract take precedence.

An invoice exception represents a single discrepancy between the data on the supplier invoice and the order, contract, or receipt data in SAP Ariba Buying and Invoicing.

Invoice exceptions may occur due to a variety of issues such as missing receipts and mismatched quantities or prices.

SAP Ariba Buying and Invoicing include a set of preloaded invoice exception types (IETs) and related validation data.

Exception tolerances and the group assigned to handle the exceptions are configurable and controlled by the customer.

Invoice exceptions can either be managed via a CSV file upload or via the UI. If using the CSV file upload, two files must be configured: InvoiceExceptionType.csv and InvoiceExceptionTypeValidation.csv.

Members of the Invoicing Administration, Invoice Manager, Payment Administrator, Payment Manager, Procurement Manager, and Customer Administrator groups can manage invoice exceptions by using the Invoice Exception Types task in the Procure-to-Pay Manager workspace in Ariba Administrator or via CSV file transfer.

As a best practice, manage invoice exceptions either through the Invoice Exception Types task or through the UI, not both.

There are two ways to create and/or maintain invoice exception types.

1. Customer Administrator User Interface
2. CSV files

It's recommended that you maintain receiving types through either the UI or the CSV files and then stick with that method.

Click the play button below to view a recording on how to create invoice exception types.

Click the play button below to view a recording on general information fields for invoice exception types.

Click the play button below to view a recording on how to modify an invoice exception.

The following CSV files are used to manage invoice exception types:

• InvoiceExceptionType.csv: This file is used to define the invoice exception types.
• InvoiceExceptionTypeValidation.csv: This file defines exactly which fields to compare, what tolerances to allow for each type of invoice exception, and which Group is responsible for resolving the exception.
• InvoiceExceptionTypeCCCOverride.csv: This file is used to define the invoice exception overrides by Commodity Codes.
• InvoiceExceptionTypeSupplierOverride.csv: This file is used to define the invoice exception overrides by Supplier.
• InvoiceExceptionTypeOverrideValidation.csv: Defines which override driver to assign to an invoice exception, and specifies the override tolerance values, auto-rejection/auto-acceptance settings, and the groups responsible to resolve invoice exception triggered by the override.

Before deleting any invoice exception types, it’s recommended that you export your invoice exception type data to CSV files by running the following invoice Exception Data Export Tasks:

• Export Invoice Exception Types
• Export Invoice Exception Type Validation Data
• Export Invoice Exception Overrides by Common Commodity Code
• Export Invoice Exception Overrides by Supplier
• Export Invoice Exception Type Override Validation Data

Click the play button below to view a recording on how to delete invoice exception types.

Tolerance operations determine whether either or both tolerances must be satisfied in order for the invoice to be considered within tolerance (that is, for no exception to be thrown).

The operation determines what is required for the invoice to be WITHIN TOLERANCE, not what is required to trigger an exception.

The Invoice Exception Type Override feature allows you to define tolerances at the supplier level and the commodity code level for each invoice exception type.

Invoice Exception Type Overrides allows for more efficient reconciliation and exception handling, where, for example, a greater tolerance is more suitable for some suppliers, while for other, a more narrow tolerances is desired.

Creating the Invoice Exception Type Override and applying it is a two-step process:

1. Create available exception type overrides by suppliers or commodity code. You can create these overrides on the Invoice Exception Types page for any invoice exception type.
2. Apply the override to the invoice exception type and specify the absolute and percentage tolerances, and whether to automatically reject invoices that trigger exceptions.