Ariba Buyer Data Load Guide

Ariba

Buyer

Data Load Guide

Release: 9r2

Document Version: 1

Release Date: June 2014

This documentation, as well as the Ariba software and/or services described in it, contain proprietary information. They are provided under a license or other

agreement containing restrictions on use and disclosure and are also protected by copyright, patent and/or other intellectual property laws. Except as permitted

by such agreement, no part of the document may be reproduced or transmitted in any form by any means, electronic, mechanical or otherwise, without the

prior written permission of Ariba, Inc.

Ariba, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in the documentation. The information contained in the

documentation is subject to change without notice.

Ariba, the Ariba logo, AribaLIVE, SupplyWatch, Ariba.com, Ariba.com Network and Ariba Spend Management. Find it. Get it. Keep it. and PO-Flip are

registered trademarks of Ariba, Inc. Ariba Procure-to-Pay, Ariba Buyer, Ariba eForms, Ariba PunchOut, Ariba Services Procurement, Ariba Travel and

Expense, Ariba Procure-to-Order, Ariba Procurement Content, Ariba Sourcing, Ariba Savings and Pipeline Tracking, Ariba Category Management, Ariba

Category Playbooks, Ariba StartSourcing, Ariba Spend Visibility, Ariba Analysis, Ariba Data Enrichment, Ariba Contract Management, Ariba Contract

Compliance, Ariba Electronic Signatures, Ariba StartContracts, Ariba Invoice Management, Ariba Payment Management, Ariba Working Capital

Management, Ariba Settlement, Ariba Supplier Information and Performance Management, Ariba Supplier Information Management, Ariba Discovery, Ariba

Invoice Automation, Ariba PO Automation, Ariba Express Content, Ariba Ready, and Ariba LIVE are trademarks or service marks of Ariba, Inc. All other

brand or product names may be trademarks or registered trademarks of their respective companies or organizations in the United States and/or other countries.

Ariba Sourcing solutions (On Demand and software) are protected by one or more of the following patents, including without limitation: U.S. Patent Nos.

6,199,050; 6,216,114; 6,223,167; 6,230,146; 6,230,147; 6,285,989; 6,408,283; 6,499,018; 6,564,192; 6,871,191; 6,952,682; 7,010,511; 7,072,061; 7,130,815;

7,146,331; 7,152,043;7,225,152; 7,277,878; 7,249,085; 7,283,979; 7,283,980; 7,296,001; 7,346,574; 7,383,206; 7,395,238; 7,401,035; 7,407,035; 7,444,299;

7,483,852; 7,499,876; 7,536,362; 7,558,746; 7,558,752; 7,571,137; 7,599,878; 7,634,439; 7,657,461; and 7,693,747. Patents pending.

Other Ariba product solutions are protected by one or more of the following patents:

U.S. Patent Nos. 6,199,050, 6,216,114, 6,223,167, 6,230,146, 6,230,147, 6,285,989, 6,408,283, 6,499,018, 6,564,192, 6,584,451, 6,606,603, 6,714,939,

6,871,191, 6,952,682, 7,010,511, 7,047,318, 7,072,061, 7,084,998; 7,117,165; 7,225,145; 7,324,936; and 7,536,362. Patents pending.

Certain Ariba products may include third party software or other intellectual property licensed from a third party. For information regarding software or other

intellectual property licensed from a third party, go to http://www.ariba.com/copyrights.cfm.

Ariba Buyer Data Load Guide iii

Revision History

The following table provides a brief history of the updates to this guide. Ariba updates the technical

documentation for its On-Premise solutions if

• software changes delivered in service packs or hot fixes require a documentation update to correctly

reflect the new or changed functionality;

• the existing content is incorrect or user feedback indicated that important content is missing.

Ariba reserves the right to update its technical documentation without prior notification. Most

documentation updates will be made available in the same week as the software service packs are released,

but critical documentation updates may be released at any time.

Version Month/Year of

Update

Updated Chapter/Section Short Description of Change

1 June 2014 n/a GA version

Revision History

iv Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide v

Table of Contents

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Chapter 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Using the Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

How the Data Dictionary is Organized. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Understanding Adapter Source Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Defining the Adapter Source for an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Exporting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Editing Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 2 Ariba Buyer Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Introduction to Ariba Buyer Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Adding New Ariba Buyer Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

UserPull Integration Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Buyer User Task in Ariba Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Viewing Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Adding or Modifying Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Copying Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Deleting Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Organic User Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

User Profile Changes on Initial Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

User Profile Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 3 Supplier Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Introduction to Supplier Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Supplier Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Supplier Organizations and IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Common Suppliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

IDs and Common Suppliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

How Supplier Data is Created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Supplier Data Integration Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

SupplierPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

SupplierLocationSupplementPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

SupplierSupplementPull Integration Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Supplier Export Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Supplier Creation During Catalog Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Assigning IDs to New Suppliers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Linking New Suppliers and Common Suppliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Supplier Profile Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

vi Ariba Buyer Data Load Guide

Table of Contents

Supplier Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Creating a Common Supplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Linking a Partitioned Supplier to Another Common Supplier . . . . . . . . . . . . . . . . . . . . . 30

Creating Common Suppliers in Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Adjusting Organization IDs During Catalog PunchOut . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Verifying Supplier Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Rebuilding the Catalog Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Introduction to Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Addresses in the Object Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Ariba Buyer Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Integration Events for Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

AddressPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

SharedUserShipToAddressMapPull Integration Event. . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Billing Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 5 Accounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Introduction to Accounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Accounting Entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Default Accounting Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Line Item Split Accounting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Accounting Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

AccountingCombinationPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

AccountingCombinationGroupPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Metadata XML for Accounting Combinations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

AccountPull Integration Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Accounting Entity Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Accounting Entities in the Default Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Parameters for Line Item Split Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

SplitAccountingTypePull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

SplitAccountingType Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

AccountTypePull Integration Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

AccountType Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Account Types for Catalog Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Account Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Default Accounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Defaulting Shipping Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Defaulting from the Requester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Export Events and Import Translation Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapter 6 Partitioned Commodity Codes . . . . . . . . . . . . . . . . . . . . . . . . 53

Introduction to Partitioned Commodity Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

PartitionedCommodityCodePull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Considerations for Oracle Financials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Commodity Code Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

ClassificationCodeMapPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

CommodityExportMapPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

How to Default Additional Accounting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Default Accounting Information Based on Line Item Amount . . . . . . . . . . . . . . . . . . . . 57

Ariba Buyer Data Load Guide vii

Table of Contents

Export Events and Import Translation Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Commodity Code Exchange Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Commodity Codes for PunchOut Items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapter 7 Purchasing Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Introduction to Purchasing Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Integration Events for Purchasing Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

ProcurementUnitPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

UserPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

ResponsibleUserPull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Purchasing Unit Responsibilities and Approvable Documents . . . . . . . . . . . . . . . . . . . . 64

Purchasing Unit Responsibilities and Approval Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Visibility Control Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Parameters for Visibility Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

“Query All” Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Search Constraints for Approvable Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Search Constraints for Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Report Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Approval Flow Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Export Events and Import Translation Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

viii Ariba Buyer Data Load Guide

Table of Contents

Ariba Buyer Data Load Guide 9

Chapter 1 Introduction

This document describes how to load data that is common to all Ariba Buyer features. It does not provide

information on loading data for specific Ariba Buyer features, or for loading data that is common to Ariba

Spend Management applications.

For information on loading data that is common to Ariba Spend Management applications, see the Ariba

Spend Management Data Load Guide.

For information on loading data for specific Ariba Buyer features, see the following documents:

In this document, the descriptions of data integrations use comma-separated value (CSV) data files as

examples of data sources, even for Ariba Buyer integrations that typically pull data from Enterprise

Resource Planning (ERP) systems.

Using the Data Dictionary

The Data Dictionary is a Microsoft Excel workbook that contains detailed descriptions of the integration

events and comma-separated value (CSV) files in Ariba Buyer. You will need to refer to the Data Dictionary

when entering data in CSV files and running integration events.

 To download the Data Dictionary:

1 Log in to Ariba Buyer using your administrator username and password.

2 In Ariba Administrator, choose Server Manager > Data Import/Export.

3 On the Data Import/Export page, select a partition. This selection determines the content of the Data

Dictionary to be downloaded.

4 On the Data Import/Export page, click Download Data Dictionary.

5 When the File Download dialog box appears, click Save to save the Data Dictionary to your local hard

drive.

How the Data Dictionary is Organized

Except for the last worksheet, each worksheet in the Data Dictionary describes a particular integration event.

Integration events are grouped together alphabetically by type as follows:

For this feature... See this document...

Ariba Procurement Solution Ariba Buyer Procurement Implementation Guide

Ariba Payment Ariba Payment Implementation Guide

Ariba Travel and Expense Ariba Travel & Expense Implementation Guide

Ariba Contracts Solution Ariba Contract Compliance Implementation Guide

Ariba Invoice Ariba Invoice Implementation Guide

Understanding Adapter Source Values Chapter 1 Introduction

10 Ariba Buyer Data Load Guide

1 Batch integration events, which import multiple CSV files from a ZIP file by running multiple data

import tasks, appear first.

2 Header-detail integration events, which import header data from one CSV file and detail data from

another CSV file, appear next. For example, Import Group to Child Group Mapping imports header data

(groups) from the file

GroupParentGroup.csv and detail data (group and child group mappings) from the

file

GroupChildGroupMap.csv.

Note: Some integration events, such as Import Requisitions, have detail-detail files.

3 Simple integration events, which import data from a single CSV file, appear after header-detail data

import tasks. For example, Import Account Types imports data from the file

AccountType.csv.

The last worksheet, which is named

Indexes, is an index of all the data import tasks in Ariba Buyer.

Integration events are listed in alphabetical order.

Each data import task name on the

Indexes worksheet is a link to the worksheet that describes that data

import task. You can click the arrow on the toolbar at the bottom of the screen to quickly navigate to the

Indexes worksheet.

Understanding Adapter Source Values

When you create, edit, or delete a data object such as a user or group, your changes are saved to the database.

Depending on the adapter source value for the object, your changes may be overwritten or deleted the next

time you run integration events.

Defining the Adapter Source for an Object

When you create an object in Ariba Administrator (that is from a user interface page in Ariba Administrator,

not by running an integration event), you must specify an adapter source for the object using the

Defined by

field. Values in the

Defined by list use the following syntax:

partition:topicName_CSV

where source file is the file listed in the message configuration table for a particular event. For example:

An adapter source of ManuallyMaintained indicates that the object is managed manually and will not be

affected by data imported into the Ariba Spend Management system from an external system.

Ariba Buyer Data Load Guide 11

Chapter 1 Introduction Understanding Adapter Source Values

Exporting Objects

When running a data export task in Ariba Administrator, you must select an adapter source value or All. If

you select an adapter source value, only objects that have that adapter source are exported. If you select

All,

all objects are exported, regardless of their adapter source.

Editing Objects

You can view, but not modify, the adapter source value when editing an object in Ariba Administrator.

For more information about managing adapter source values and source of truth-related parameters, see the

Ariba Spend Management Channels Guide.

Adapter Source Description

All Export all objects.

Not ManuallyMaintained Export only those objects whose source of truth is an external system.

ManuallyMaintained Export only those objects that are maintained in Ariba Administrator.

Understanding Adapter Source Values Chapter 1 Introduction

12 Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide 13

Chapter 2 Ariba Buyer Users

• “Introduction to Ariba Buyer Users” on page 13

• “UserPull Integration Event” on page 13

• “Organic User Growth” on page 17

• “User Profile Changes on Initial Login” on page 19

• “User Profile Validation” on page 19

Introduction to Ariba Buyer Users

Each user has some information, such as the user’s name, that is shared by all Ariba Spend Management

applications. Each user can also have additional application-specific data.

In the object model, user data is represented by the following objects:

• A shared user, which represents the data shared by all Ariba Spend Management applications. A shared

user is an object of type

ariba.user.core.User.

• An Ariba Buyer user, which stores user data specific to Ariba Buyer. This object is of type

ariba.common.core.User.

Shared user data is not partitioned, and is shared by all Ariba Spend Management applications. Ariba Buyer

user data is specific to one partition, and can include information such as partition-specific accounting

information.

This chapter describes how to load and maintain Ariba Buyer users. For information on shared users, see the

“Shared Users and Organizations” chapter in the Ariba Spend Management Data Load Guide.

Adding New Ariba Buyer Users

When you set up your configuration, you must define user accounts for your users. You can add users in the

following ways:

• With integration events, adding new users and profile data to your data source for users. For information,

see “UserPull Integration Event” on page 13.

• From Ariba Administrator, using the Buyer Users task in the User Manager workspace. For more

information, see “Buyer User Task in Ariba Administrator” on page 15.

• With organic user growth, which lets users create user profile information dynamically, from the user

interface. For information, see “Organic User Growth” on page 17.

UserPull Integration Event

You use the UserPull integration event to read a data source that defines profile data for Ariba Buyer users.

For each Ariba Buyer user in the data source, the integration event links the Ariba Buyer user to an existing

shared user, and then stores the Ariba Buyer-specific data for that user.

UserPull Integration Event Chapter 2 Ariba Buyer Users

14 Ariba Buyer Data Load Guide

Ariba Buyer provides an implementation of the integration event that pulls profile data from a CSV file, and

alternative implementations that pull the same information from either PeopleSoft HRMS or PeopleSoft

Financials.

This section describes the CSV implementations. For information on the PeopleSoft implementation, see the

Ariba Buyer PeopleSoft Integration Guide.

In the default Ariba Buyer configuration, the UserPull integration event reads data from the following file:

config/variants/variant/partitions/partition/data/User.csv

For detailed information about the columns in this file, consult the Data Dictionary. For more information

see “Using the Data Dictionary” on page 9.

In the default Ariba Buyer configuration, the UserPull integration event runs a trigger action after each

successful integration pull. This trigger action assigns a set of default permissions, such as

CreateRequisition, to all Ariba Buyer users. The CreateRequisition permission specifies which users are

authorized to create requisitions. In the default Ariba Buyer configuration, this permission is assigned to all

Ariba Buyer users, but not to supplier users who punch in to Ariba Buyer.

The UserPull integration event is a header-detail event that can accept a detail file. The default location of

that file is:

config/variants/vcsv/partitions/pcsv/data/PCardMap.csv

This file associates the buyer user with the PCards that he or she owns. The Buyer user object has a PCards

field that holds a list of PCard objects. It is assumed that the PCard objects referenced by the PCardMap.csv

(if any) already exist. You can run this event with an empty PCardMap.csv file if you don't use any PCards.

Ariba Buyer Data Load Guide 15

Chapter 2 Ariba Buyer Users Buyer User Task in Ariba Administrator

Buyer User Task in Ariba Administrator

You use the Buyer Users task Ariba Administrator to manage Ariba Buyer users.

Viewing Users

 To view users:

1 In Ariba Administrator, choose User Manager > Buyer Users and click List All to display all users, or enter

search criteria and then click

Search or press the Enter key.

By default, only active users are displayed. The following table describes the columns on the Buyer Users

page.

2 To display details about an Ariba Buyer user, click the relevant User ID.

The following table describes the type of information displayed on each tab on the View Details page.

3 Click Done to return to the previous page.

Column Description

User ID The user’s system ID.

Name The user’s display name.

Business Email Address The user’s business email address.

Supervisor The display name of the user’s supervisor.

Partition The partition in which the user exists.

Tab Description

General The user’s adapter source (Defined By field), type, user ID, display name,

preferred language, preferred currency, and other general user information.

PCards The PCards currently assigned to the user.

Ship To Addresses The user’s Ship To address (one per partition).

Billing Addresses The user’s billing address (one per partition).

Shared User General Info The user’s adapter source (Defined By field), type, user ID, display name,

business email, preferred language, preferred currency, and other general user

information.

Shared User Groups The groups that are directly assigned to the shared user associated with this Ariba

Buyer user.

Shared User Roles The roles that are directly assigned to the shared user associated with this Ariba

Buyer user.

Shared User Permissions The permissions that are directly assigned to the shared user associated with this

Ariba Buyer user.

Shared User All Permissions The permissions that are assigned, both directly and indirectly, to the shared user

associated with this Ariba Buyer user.

Buyer User Task in Ariba Administrator Chapter 2 Ariba Buyer Users

16 Ariba Buyer Data Load Guide

Adding or Modifying Users

 To add or modify a Buyer user:

1 Choose User Manager > Buyer Users and click Create New to add a new Ariba Buyer user, or click the

checkbox to select the user you want to modify and click

Edit.

2 On the General tab, enter or modify general user information. The following table describes the fields on

the General tab.

3 On the PCard tab, click Add/Remove to add or remove a PCard assignment for this user.

4 On the Ship To Addresses tab, click Add/Remove to add or remove a ship to address for this user.

You can assign only one Ship To address to a user per partition. If you try to select more than one address

in the chooser, all addresses are removed.

5 On the Billing Addresses tab, click Add/Remove to add or remove a billing address for this user.

You can assign only one Billing address to a user per partition. If you try to select more than one address

in the chooser, all addresses are removed.

6 On the PCard tab, click Add/Remove to display the available purchasing cards and add or remove a PCard

assignment for this user.

The remaining tabs provide information about the shared user associated with this Ariba Buyer user, and

are for viewing only. To modify the profile of a shared user, use the

User Manager > Users task.

7 Click Save to save your changes, or Cancel to return to the previous page without saving your changes.

Copying Users

You can create a new Ariba Buyer user based on an existing user.

 To create a new Ariba Buyer user based on an existing user:

1 Choose User Manager > Buyer Users.

2 Display and select the user you want to copy.

3 Click Copy. The Create User page appears, already populated with the details for the user you copied.

4 Edit user details as described in “Adding or Modifying Users” on page 16, and then click Save.

Field Description

Partition The partition in which the user exists. You cannot modify this field in edit mode.

Defined By The adapter source for the object. See “Understanding Adapter Source Values” on

page 10. You cannot modify this field in edit mode.

User The shared user with which this Ariba Buyer user is associated.

Deliver-To Address The address for this user.

Ariba Buyer Data Load Guide 17

Chapter 2 Ariba Buyer Users Organic User Growth

Deleting Users

 To delete a user:

1 Choose User Manager > Buyer Users and click List All to display all users, or enter search criteria and then

click

Search or press the Enter key.

2 Click the checkbox to select the user you want to delete, and then click Delete.

Organic User Growth

Organic user growth lets you add new Ariba Buyer users dynamically, without requiring a data source. With

organic growth, you do not need to define the profile information for an Ariba Buyer user in the

User.csv

file. Instead, you define the user name, and then ask the user to set up the initial profile information from the

user interface.

You can use organic growth for all Ariba Buyer users, or to add new Ariba Buyer users after loading your

original users from a data source. Note that Ariba Upstream Platform users can always grow organically

without the need to change any parameters.

 To configure organic user growth:

1 Set the parameter Application.Authentication.OrganicGrowth to true.

2 Set the parameter Application.Authentication.ModifyUserProfileOnInitialLogon to true.

For more information, see “User Profile Changes on Initial Login” on page 19.

3 Set the parameter Application.Base.Data.DefaultOrganicUserLocale to name the locale for new users.

 To add a new user with organic user growth:

1 Add the new user to your authentication source, such as passwd.txt.

2 Reload the password information, if necessary.

If you are using a real-time password adapter, such as the NT Domain Login adapter, you do not need to

explicitly reload the password information. If you are using

passwd.txt and the CryptDBPassword

Adapter, you do have to reload.

3 Invite the user to log in.

If you have a configuration with multiple password adapters, the user must log in using a URL that

specifies the password adapter to use for authentication. For example:

https://myserver:444/Buyer/Main/ad/webjumper?passwordAdapter=PwordAdapter1

For complete information about arguments to the login URL, see the Ariba Buyer Configuration Guide.

4 Ariba Buyer uses the user name to look up an associated shared user.

Each newly “grown” Ariba Buyer user is linked to an existing shared user. If the shared user does not

already exist, it is created as part of the organic growth process.

At this point, the user can log in, but does not yet have user profile information set. When the user first logs

in, Ariba Buyer guides the user through the user preferences to create an updated profile and submit it for

approval.

Organic User Growth Chapter 2 Ariba Buyer Users

18 Ariba Buyer Data Load Guide

Users added with organic user growth cannot log in and use the full functionality of Ariba Buyer until they

have created a profile and had it approved.

Ariba Buyer Data Load Guide 19

Chapter 2 Ariba Buyer Users User Profile Changes on Initial Login

User Profile Changes on Initial Login

If you are expecting Ariba Buyer users to supply some information dynamically, you can choose whether to

require new users to specify any missing or incomplete information before they can perform other tasks.

To require new users to specify missing information, set the parameter

Application.Authentication.ModifyUserProfileonInitialLogin in config/Parameters.table to true. When

this parameter is set to

true, each new user must complete the user profile before accessing the full

functionality of Ariba Buyer.

User Profile Validation

As with any approvable document in Ariba Buyer, a User Profile Update request is validated when the

document is submitted for approval. A user’s profile can become invalid at any time, even if the profile

information itself has not changed. For example, if one user leaves the company, the user profiles for that

user’s direct reports become invalid, because the supervisor field is no longer valid.

To help ensure that profiles remain valid, you can require user profile validation each time a user logs on.

User profile validation involves the following checks:

• Does this user have a current User Profile?

• Is this user’s Supervisor valid?

• Is this user’s ShipTo address valid?

• Is this user’s email address set?

To determine whether the ShipTo and email addresses are valid, the user profile validation tests the validity

conditions defined for each field, within the UserValidation group. For more information on validity

conditions, see the Ariba Spend Management Customization Guide.

 To enable and configure user profile validation:

1 Set the parameter Application.Authentication.ValidateUser to either Notify or Force.

• If you choose

Notify, the user sees a dialog box listing the error, but can continue on normally.

• If you choose

Force, the user can still log in, but must submit a profile update before continuing with

other tasks.

• The default setting is

Off.

2 Check the validity conditions associated with EmailAddress and ShipTo fields, in the group

UserValidation.

To change the logic for validation, you change the validity condition for that field in the context of the

UserValidation group. For information on how the ShipTo field is populated, see “Addresses” on page 37.

User Profile Validation Chapter 2 Ariba Buyer Users

20 Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide 21

Chapter 3 Supplier Data

This chapter describes how to load supplier data in Ariba Buyer. It includes the following sections:

• “Introduction to Supplier Data” on page 21

• “How Supplier Data is Created” on page 23

• “Supplier Data Integration Events” on page 24

• “Supplier Creation During Catalog Load” on page 26

• “Supplier Profile Synchronization” on page 28

• “Supplier Administration” on page 29

Introduction to Supplier Data

A supplier is an organization that provides goods or services.

In Ariba Buyer, supplier data is essential to the process of creating requisitions and sending orders. For

example, Ariba Buyer uses supplier data in the following ways:

• Every item in the catalog must have an associated supplier. The supplier object must exist in Ariba Buyer.

• Every order that is sent from Ariba Buyer must be sent to a specific supplier. To send an order, Ariba

Buyer must have contact information for that supplier.

• If the user chooses a non-catalog item in Ariba Buyer, a purchasing manager or other administrator must

designated a suggested supplier for that item by choosing from the list of available suppliers.

Supplier Profiles

Each supplier has an associated profile. A supplier profile includes contact information (telephone number,

email address, and so on), as well as application-specific information.

For example, a supplier profile in Ariba Buyer includes information such as the supplier’s preferred method

for receiving orders, preferred payment method, and preferred billing address.

Supplier Organizations and IDs

Each supplier belongs to an external organization that uniquely identifies that supplier. Each external

organization has an associated system ID and organization ID.

Suppliers who have accounts on Ariba Network (Ariba Network) also have Ariba Network IDs, which are

stored as part of the supplier profile information. When sending an order to Ariba Network, Ariba Buyer

sends the D-U-N-S ID (if there is one) and otherwise the Ariba Network ID.

For more information on supplier organizations and organization IDs, see the Ariba Spend Management

Data Load Guide.

Introduction to Supplier Data Chapter 3 Supplier Data

22 Ariba Buyer Data Load Guide

Common Suppliers

In Ariba Buyer, suppliers are partitioned objects. Each partition has its own set of suppliers. Sometimes the

suppliers in different partitions must logically be linked together. For example, you might have a supplier

with a European branch and an American branch. Although you represent those suppliers in both partitions,

you typically want to treat the supplier as a single entity when negotiating pricing and bulk agreements.

Ariba Buyer defines a CommonSupplier object to act as an umbrella to link together suppliers in different

partitions that represent the same real-world supplier. Common suppliers are not partitioned. Every

partitioned supplier must be grouped under exactly one common supplier. Common suppliers do not have to

have any associated partitioned suppliers, however. For example, a common supplier might represent

supplier users from Ariba Sourcing.

The following diagram shows the relationship between a common supplier, a partitioned supplier, and a

supplier location in Ariba Buyer:

In this diagram, the supplier “Acme” exists in two partitions: European HQ and North American HQ. The

two partitioned suppliers are linked together under a single common supplier.

Supplier Location

Name: Acme, Inc.

Location: Vermont

(North American HQ)

Supplier Location

Name: Acme, Inc.

Location: Maine

(North American HQ)

Partitioned Supplier

Name: Acme, Inc.

Partition = North American HQ

Partitioned Supplier

Name: Acme, Inc.

Partition = European HQ

Common Supplier

Name: Acme, Inc.

(unpartitioned)

Ariba Buyer Data Load Guide 23

Chapter 3 Supplier Data How Supplier Data is Created

IDs and Common Suppliers

Ariba Buyer uses the supplier’s organization ID to determine which partitioned suppliers to group together

under a given common supplier. The following diagram illustrates a configuration with two partitions: A and

B. The suppliers in partition A use D-U-N-S IDs, and the suppliers in partition B use internal IDs. The

common supplier includes both IDs.

The IDs determine which partitioned suppliers are grouped under the common supplier. If you want to

change the association between partitioned supplier and common supplier, you can change the IDs using

Ariba Administrator. For more information, see “Linking a Partitioned Supplier to Another Common

Supplier” on page 30.

Supplier IDs are created by the integration event that loads supplier data. For example, for suppliers read in

from an ERP system, the supplier ID is created by the integration event that loads the supplier, using the

supplier’s ERP system ID. For more information on how supplier IDs are assigned, see “Creating a Common

Supplier” on page 29.

How Supplier Data is Created

In a typical Ariba Buyer configuration, each partition has a set of suppliers, which is read from an ERP

system or comma-separated value (CSV) file through an integration event. Suppliers used for Ariba Network

are defined in Supplier Direct partition.

To create supplier data, you can use the following methods:

• Load data through integration events. You typically use this technique for data read into a partition, either

from an ERP system or from a CSV file. For more information, see “Supplier Data Integration Events” on

page 24.

• Create a supplier during catalog load. You use this technique when a catalog synchronized with Ariba

Network includes a supplier not yet defined in Ariba Buyer. For more information, see “Supplier Creation

During Catalog Load” on page 26.

• Enter data manually, from the Supplier Manager in Ariba Administrator. You typically do this only

temporarily, or for error recovery. For information, see “Supplier Administration” on page 29.

Partitioned Supplier

Name: Acme, Inc.

Partition = B

Internal Supplier ID: ZYX

Partitioned Supplier

Name: Acme, Inc.

Partition = A

DUNS ID: 123

Common Supplier

Name: Acme, Inc.

Internal Supplier ID: ZYX

DUNS ID: 123

(unpartitioned)

Supplier Data Integration Events Chapter 3 Supplier Data

24 Ariba Buyer Data Load Guide

Supplier Data Integration Events

In a typical Ariba Buyer configuration, you read basic supplier data from an ERP system, and then

supplement that data with additional Ariba Buyer-specific information, such as data about the supplier’s

preferred ordering methods and rules for purchasing card use.

In the default configuration, Ariba Buyer loads supplier information with three integration events, one that

reads data typically found in an ERP system and others that reads data typically used only in Ariba Buyer.

The integration events used in the default configuration are as follows:

• The SupplierPull integration event, which loads a list of supplier names and supplier location names,

either from an ERP system or from a CSV file.

• The SupplierLocationSupplementPull integration event, which loads Ariba Buyer-specific information,

such as data about the supplier’s preferred ordering methods.

• The SupplierSupplementPull integration event, which associates payment models with suppliers or

supplier locations.

There are also corresponding export events:

• SupplierExport

• SupplierSupplementExport

• SupplierLocationSupplementExport

Export events allow you to export data to CSV files, through the Ariba File Channel.

This section describes the integration events for loading and exporting supplier data.

SupplierPull Integration Event

Ariba Buyer represent suppliers with two related objects:

• A supplier, which is a company, such as Acme Corporation.

• A supplier location, which is a physical location for a company.

The SupplierPull integration event reads from two data sources: one that defines a list of suppliers, and one

that defines supplier location information for each of those suppliers.

Supplier Data Source

In the default configuration, the SupplierPull integration event for the Ariba File Channel reads supplier data

from the following file:

config/variants/variant/partitions/partition/data/Supplier.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Ariba Buyer Data Load Guide 25

Chapter 3 Supplier Data Supplier Data Integration Events

Supplier Location Data Source

The supplier location data source provides a list of supplier locations for each supplier. For every supplier in

your list of suppliers, you must have one or more entries in the supplier locations list. Each entry includes an

address and the name of a contact person at that location. To have entries for several different contacts, you

include multiple lines for each location.

Each supplier location has a unique name, a Customer ID (which links the location to a supplier), and a

Contact ID. The contact ID identifies a specific individual within the supplier location. Usually you have one

line in the supplier locations list for each supplier location, each with the same Customer ID and different

unique names. If you also have different contacts within the same location, you can use the contact ID to

differentiate between the locations.

In the default configuration, the SupplierPull integration event for the Ariba File Channel reads supplier

location data from the following file:

config/variants/variant/partitions/partition/data/SupplierLocation.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

If more than one supplier location exists for a given supplier, Ariba Buyer uses the trigger

SetSupplierLocationOnSupplierChange to choose a supplier location for each requisition. In the default

configuration, this trigger calls the action implementation

SetSupplierLocation.java, which implements the

following logic:

• Look through the supplier locations, in order. If any supplier location has a preferred order method

defined, then use that location and stop looking.

• If no location has a preferred order method defined, then look at the ZIP codes of the supplier locations

and the requester and pick the supplier location that appears to be closest, based on ZIP codes.

You can customize this logic by subclassing the trigger implementation with a custom Java class. For more

information on triggers, see the Ariba Spend Management Customization Guide.

Ariba Buyer provides several ways to validate supplier location information, to ensure that Ariba Buyer does

not try to send orders to invalid locations. For information on validating supplier locations, see “Validation at

Submission” on page 35.

Important: Each supplier location must have a unique Ariba Network ID. Supplier locations with duplicate

Ariba Network IDs are not permitted.

SupplierLocationSupplementPull Integration Event

The SupplierLocationSupplementPull integration event loads information about each supplier location,

including its preferences for ordering methods and purchasing card usage. This information supplements the

supplier location information defined by the SupplierPull integration event.

In the default configuration, the SupplierLocationSupplementPull integration event reads supplemental

supplier location data from the following file:

config/variants/variant/partitions/partition/data/SupplierLocationSupplement.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Supplier Creation During Catalog Load Chapter 3 Supplier Data

26 Ariba Buyer Data Load Guide

SupplierSupplementPull Integration Event

A payment model determines how payment transactions are handled. Ariba Buyer provides the following

payment models:

• ANPay—Specifies that payment requests are sent to Ariba Network (Ariba Network), which makes the

payment.

•ExternalPay—Specifies that payment requests are handled in an external system, such as an ERP system.

You can optionally associate a payment model with a specific supplier or supplier location using the

SupplierSupplementPull integration event, which reads from the following file:

config/variants/variant/partitions/partition/data/SupplierSupplement.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

If you do not associate a payment model with a supplier location, the supplier location uses the payment

model associated with the supplier. If you do not associate a payment model with a supplier, the supplier

uses the default payment model configured for your system.

Supplier Export Events

The default configuration supplies three export events—SupplierExport, SupplierSupplementExport, and

SupplierLocationSupplementExport—which write supplier data to CSV files. In the default configuration,

these export integration event write to the following files:

config/variants/Plain/partitions/None/data/Supplier_Export.csv

config/variants/Plain/partitions/None/data/SupplierLocation_Export.csv

config/variants/Plain/partitions/None/data/SupplierLocationSupplement_Export.csv

For more information on export events, see the Ariba Spend Management Channels Guide.

Supplier Creation During Catalog Load

When you synchronize Ariba Buyer with Ariba Network to download new catalogs, Ariba Buyer checks

each incoming catalog to make sure the suppliers in the catalog are defined in Ariba Buyer. If a catalog

includes a supplier not yet defined in Ariba Buyer, the catalog load process requests a copy of the supplier

profile for that supplier from Ariba Network.

Your catalog administrator must make sure the supplier is defined in Ariba Buyer before the catalog load

process can continue. The process is as follows:

1 The AribaNetworkFullSubscriptionSync scheduled task runs, either manually or on a schedule, to receive

catalog updates from Ariba Network.

For more information on this scheduled task, see the Ariba Buyer Catalog Administration Guide.

2 If a catalog on Ariba Network references a supplier that is not defined in your Ariba Buyer configuration,

Ariba Buyer requests the supplier profile for that supplier from Ariba Network.

3 Ariba Buyer sends Notification 59, “Notification of Unknown Supplier,” to users who have the

permission to users who have the permission

SupplierManager.

Ariba Buyer Data Load Guide 27

Chapter 3 Supplier Data Supplier Creation During Catalog Load

4 If Ariba Network included a profile for the new supplier, the notification message includes that supplier

profile as an attachment.

5 The Supplier Manager reviews the suggested supplier profile.

6 The Supplier Manager performs the following tasks in Ariba Administrator:

a The Supplier Manager chooses Server Manager > Config Files and uploads the attached supplier profile

into the following file:

config/variants/Plain/partitions/supplierdirect/data/NewSupplier.xml

Suppliers for catalog items from Ariba Network are loaded into the Supplier Direct partition. Using

Supplier Direct means that the supplier profile is not overwritten by an integration event, as might be

the case in other partitions.

b The Supplier Manager chooses Server Manager > Integration Events and runs the integration event

SupplierXMLPull from the Supplier Direct partition.

This integration event reads the XML file

NewSupplier.xml, and adds the new supplier to the Supplier

Direct partition.

7 The scheduled task UpdateSupplierPendingItems runs. This scheduled task checks all pending unknown

suppliers. If the supplier now exists in Ariba Buyer, the scheduled task updates the pending catalog

tracker item, so that the catalog update can continue successfully.

If the Supplier Manager does not add the supplier within the time limit specified by

System.Procure.PendingUnknownSupplierOverdueLimitInDays, the UpdateSupplierPendingItems task sends

Notification 60, “Notification of Overdue Unknown Supplier Resolution,” as a reminder.

In the default configuration, catalog items are restricted by Ariba Buyer partition. Users can see only catalog

items for suppliers defined in the partition where they are logged in. Suppliers in the Supplier Direct

partition are visible to users in all partitions.

To set up your configuration so that catalog items from suppliers in the Supplier Direct partition are not

visible to users in other partitions, set the

System.Procure.ExcludeSupplierDirectCatalogItems parameter to

true.

For more information on the visibility of catalog items by Ariba Buyer partition, see the Ariba Buyer

Catalog Administration Guide.

Assigning IDs to New Suppliers

Whenever a supplier is loaded into Ariba Buyer, the supplier load process assigns a unique identifier (an

organization ID) for that supplier. The process for choosing the ID depends on how the supplier is created:

• When you load suppliers from an integration event, the suppliers are created within a partition. The

partition determines the naming convention for the unique ID. For example, in a PeopleSoft partition,

suppliers might have IDs of the form

{partition-psoft, 543231}. The domain portion of the name

(

partition-psoft) is defined in the integration event that loads the suppliers.

• When you load suppliers from Ariba Network, the IDs are defined by Ariba Network and are included in

the cXML document that is downloaded.

• When you add suppliers manually from Ariba Administrator, the supplier is created in the partition in

which you are currently logged in, and you must define an ID that is acceptable for that partition.

Supplier Profile Synchronization Chapter 3 Supplier Data

28 Ariba Buyer Data Load Guide

The following diagram illustrates supplier data read from different data sources, with different ID domains

in each partition. The common supplier shares the IDs from the different partitions.

Linking New Suppliers and Common Suppliers

Whenever you add a new supplier, Ariba Buyer checks the organization ID of that supplier, to see if it

matches an existing common supplier. If the common supplier already exists, Ariba Buyer links the new

supplier to the existing common supplier. If the common supplier does not yet exist, Ariba Buyer creates one

as follows:

• If you are loading supplier data from an integration event, Ariba Buyer always creates a new common

supplier and links the new supplier to the new common supplier.

• If you are creating a supplier manually from Ariba Administrator, you create both a common supplier and

a partitioned supplier.

Supplier Profile Synchronization

Many suppliers maintain supplier profile information on Ariba Network. Ariba Buyer includes scheduled

tasks that you can use to load initial profile information from Ariba Network, and to update supplier

information if the supplier changes a profile.

To download supplier profile information from Ariba Network, use the following scheduled tasks:

• AribaNetworkOrganizationSync, which checks your Ariba Buyer configuration for suppliers that have

Ariba Network IDs or D-U-N-S IDs, and asks Ariba Network to send current profile information for those

suppliers.

• CommonSupplierSyncUsingSupplierLocationID, which is similar to AribaNetworkOrganizationSync,

but designed for situations where a supplier has different Ariba Network IDS for different supplier

locations.

Supplier

part-psoft 709

ID list

Supplier Location

psoft partition

Supplier

partition-sap: 102

ID list

Supplier Location

sap partition

Common Supplier

DUNS: 123456

InternalSupplierId: 5

partion-sap: 102

partition-psoft: 709

Supplier

DUNS: 123456

InternalSupplierId; 5

ID list

Supplier Location

supplierdirect

ERP Partition Suppliers SupplierDirect Suppliers

Ariba Buyer Data Load Guide 29

Chapter 3 Supplier Data Supplier Administration

• GetPendingAribaNetworkOrganizationSync, which polls Ariba Network for changes that have been made

since the last sync (with either AribaNetworkOrganizationSync or

CommonSupplierSyncUsingSupplierLocationID), and downloads those updates.

In the default configuration, none of these tasks is scheduled to run on a regular basis. Typically an

administrator runs these tasks on demand, as appropriate, to download profile information for all Ariba

Network suppliers.

The synchronization tasks recognize two parameters:

• A performance-tuning parameter, which determines the batch size of updates. You can adjust this

parameter to adjust the balance between network traffic (smaller batch size).

• A Boolean parameter that specifies which suppliers are updated. By default, the tasks update supplier

profile information for any supplier who has either an Ariba Network ID or a D-U-N-S number. If you

maintain some supplier information from ERP systems, and want to update only the information for

suppliers who have Ariba Network IDs, you can set this parameter.

For complete information on the available parameters, see the Ariba Buyer Configuration Reference Guide.

Supplier Administration

In general, you administer supplier information from the Supplier Manager in Ariba Administrator. You use

the Supplier Manager to manage your supplier configuration. You can use the Supplier Manager to link and

unlink suppliers, and adjust other supplier profile data.

You can also use the Supplier Manager to load and edit the information for a supplier. If you edit values for

a supplier that originated from an integration event, Ariba Administrator warns you that your changes are

overwritten the next time you run that integration event. To make changes to a supplier that originated from

an integration event, you must make your changes in original data source (ERP system or CSV file), and

then rerun the integration event.

This section summarizes some of the common tasks you can perform from Ariba Administrator. It also

describes common tasks performed outside of Ariba Administrator.

Creating a Common Supplier

Although common suppliers are usually created indirectly, as part of creating a supplier, you can also use

Ariba Administrator to create a new common supplier.

 To add a common supplier:

1 In Ariba Administrator, choose Supplier Manager > Suppliers.

2 On the Suppliers page, click Create New.

3 Choose an adapter source and enter a unique name and name. You can also optionally enter a corporate

URL or catalog URL.

Note: If you support PunchOut with this supplier, make sure to enter the PunchOut URL in the catalog

URL field.

4 In the Organization IDs section, click Create New.

Supplier Administration Chapter 3 Supplier Data

30 Ariba Buyer Data Load Guide

5 Choose a domain, and then type the organization ID for that domain in the Value text box.

6 In the Partitioned Suppliers section, click Create New to create a new partitioned supplier, or choose Relink

from another Common Supplier

to associate an existing partitioned supplier with this new common supplier.

You must add at least one partition-specific supplier to each common supplier. If there are no linked

partitioned suppliers, catalog items for that supplier cannot be displayed to users.

For more information on adding suppliers through Ariba Administrator, see the Ariba Administrator online

help.

Linking a Partitioned Supplier to Another Common Supplier

You can merge two common suppliers by moving the partitioned suppliers from one common supplier to

another common supplier in Ariba Buyer. Before you do this, you must make sure that the IDs for the

partitioned suppliers are in different domains. For example, if you have a partitioned supplier with a

D-U-N-S ID and try to link it to a common supplier that already has a D-U-N-S ID, Ariba Administrator

reports an error and prevents the merge.

 To link a partitioned supplier to another common supplier:

1 In Ariba Administrator, choose Supplier Manager > Suppliers.

2 On the Suppliers page, search for the common supplier to which you want to move the partitioned

supplier, choose that common supplier, and then click

Edit.

3 On the Suppliers - Edit Common Supplier page, click Relink from another Common Supplier.

4 On the Suppliers- Choose Partitioned Supplier to Relink page, search for the partitioned supplier you

want to move to the common supplier, and then click

Select.

5 On the Confirm Partitioned Supplier to Relink page, click OK.

The Supplier Manager checks for any “siblings” with the same ID. If it finds a sibling, the move

automatically includes all suppliers with matching IDs.

6 On the Suppliers - Edit Common Supplier page, click Save.

After a relink, you typically have a common supplier with no associated suppliers. In this case, Ariba

Administrator removes the “empty” common supplier from the common supplier list.

For more information, see the Ariba Administrator online help.

Creating Common Suppliers in Bulk

If you need to make a configuration change that involves a large number of additions to suppliers and

common suppliers, you can use the following integration events:

• SupplierOrganizationPull

• CommonSupplierIDMapPull

Both integration events load common suppliers. but they differ as follows:

• CommonSupplierIDMapPull always attempts to create a new common supplier and allocates an

internally generated system ID. It does not modify existing common suppliers.

Ariba Buyer Data Load Guide 31

Chapter 3 Supplier Data Supplier Administration

• SupplierOrganizationPull lets you assign your own system ID. You must take care to ensure that each

system ID is unique. It also looks up and modifies existing common suppliers based on system ID.

The rest of this section describes how to use CommonSupplierIDMapPull to manage mappings between

suppliers and common suppliers. For information on SupplierOrganizationPull, see the Ariba Spend

Management Data Load Guide.

CommonSupplierIDMapPull Integration Event

If you manage your suppliers outside of Ariba Buyer, and load them into Ariba Buyer with integration

events, you can use an integration event called CommonSupplierIDMapPull to help manage the mapping

between suppliers and common suppliers.

Note: If you manage your suppliers entirely within Ariba Buyer, you use the Supplier Manager in Ariba

Administrator as your primary tool for adjusting supplier/common supplier mappings.

The CommonSupplierIDMapPull integration event defines a mapping between partitioned suppliers and

common suppliers. You use this integration event to “bulk load” the supplier matching process across

partitions by specifying a set of supplier organization IDs that must be joined together under a single

common supplier. For example, you might choose to use this integration event if you load suppliers from

different ERP systems and need to make sure those suppliers are linked together under the same common

supplier.

The CommonSupplierIDMapPull integration event is appropriate only for situations where you are loading a

large number of new suppliers and want to make sure the links between those suppliers and their common

suppliers are set up properly. For situations where you want to adjust a few existing links, use the Supplier

Manager instead.

The CommonSupplierIDMapPull integration event reads two CSV files: one that defines a set of common

suppliers and another that defines which suppliers must be mapped to those common suppliers. It uses a join

token to indicate which suppliers must be linked together under a given common supplier. The join token is

used only temporarily by this integration event, and isn’t used anywhere else in your configuration. You can

use any join tokens you like, as long as they are distinct from one another.

There is one implementation of the CommonSupplierIDMapPull integration event, which reads mapping

information from the following CSV files:

config/variants/Plain/partitions/None/data/CommonSupplierIDMap.csv

config/variants/Plain/partitions/None/data/CommonSupplierIDMapHeader.csv

The default configuration also includes integration events that use Ariba File Channel to export the data in

your common supplier map into CSV files. The export events associated with the common supplier ID map

are as follows:

• CommonSupplierIDMapHeaderExport, which exports the header file.

• CommonSupplierIDMapExport, which exports the detail file.

For more information on export events, see the Ariba Spend Management Channels Guide.

Supplier Administration Chapter 3 Supplier Data

32 Ariba Buyer Data Load Guide

 To set up and run the CommonSupplierIDMapPull integration event:

1 Create a CSV file called CommonSupplierIDMapHeader.csv. Include a SystemID column in the file, and insert

the system ID for each supplier organization. (System IDs for common suppliers are defined in the file

SupplierOrganizations.csv, which you can get using the Export Supplier Organizations data export task.)

The

CommonSupplierIDMapHeader.csv file lists a set of common suppliers you want to define. Typically,

these are the suppliers who have multiple IDs in different ERP systems. For example:

JoinToken,Name,SystemID

1,John Woodman,sid201

2,Schafer Office.sid202

3,Computer Electronics Supply,sid203

4,JCN Technologies,sid204

5,Mantell Office Maintenance (MOM),sid205

2 Set up a CSV file called CommonSupplierIDMap.csv.

This file specifies which IDs match the join tokens in the header file. It includes one line for each ID you

want to map. For example, if you want common suppliers to have a

DUNS number, and a PeopleSoft vendor

number, you can create a file with this format:

JoinToken,Domain,Value

1,DUNS,0000001000

1,partition-psoft,MFG:0000111111

2,DUNS,0000000001

2,partition-psoft,MFG:0000222222

3,partition-psoft,MFG:0000333333

3,DUNS,0000000002

4,partition-psoft,MFG:0000444444

4,DUNS,0000000100

5,DUNS,0000000300

5,partition-psoft,MFG:0000555555

3 In Ariba Administrator, run the CommonSupplierIDMap integration event.

This integration event reads the mapping files and creates the necessary common suppliers using the IDs

defined in your mapping file. Ariba Buyer creates one common supplier for each

JoinToken in the header

file.

4 In Ariba Administrator, run the SupplierPull integration event and the SupplierLocationSupplementPull

integration event to read the list of suppliers.

The SupplierPull integration event checks the IDs to see which IDs match the common suppliers you

defined.

Reactivating Deleted Common Suppliers

If you delete common suppliers in Ariba Administrator, you can reactivate them by rerunning the

CommonSupplierIDMap integration event, but you must first modify the data source.

 To reactivate deleted common suppliers:

1 Create a CSV file that is like CommonSupplierIDMapHeader.csv, but add the SystemID column to it.

2 Insert the SystemID for each common supplier you want to reactivate.

3 Edit the Message Configuration file to have Operation=Update.

4 Run the pull using your new CSV file as input.

Ariba Buyer Data Load Guide 33

Chapter 3 Supplier Data Supplier Administration

Adjusting Organization IDs During Catalog PunchOut

Ariba Buyer catalog item PunchOut is the process of allowing users to order items from a Web-based

catalog. When a user chooses an item from a PunchOut catalog, Ariba Buyer exchanges cXML messages

with the supplier website, obtains information about the desired item, and adds a new line item to the

purchase requisition.

When the user chooses a PunchOut item, Ariba Buyer uses the organization ID to match the catalog’s

supplier to an appropriate common supplier and partitioned supplier in your configuration. In some cases,

Ariba Buyer might not be able to locate a correct partitioned supplier with the given ID. If this occurs:

1 The PunchOut line item is added to the requisition, but without a supplier. The line item is marked as

invalid (red).

2 Ariba Buyer sends Notification 59, “Notification of Unknown Supplier,” to users who have the

permission

SupplierManager.

3 The Supplier Manager resolves the issue, typically by adding a D-U-N-S ID to the appropriate partitioned

supplier.

4 The requisition line item remains marked as invalid until the scheduled task UpdateSupplierPendingItems

runs.

This task looks for unknown suppliers. If it finds the missing supplier, it updates all pending requisition

line items with the correct supplier information.

5 The user can successfully submit the requisition.

Verifying Supplier Locations

If there are mistakes in the data for a supplier location, such as faulty contact information, those mistakes

typically lead to errors when Ariba Buyer tries to send an order to that location. In general, it is preferable to

detect such errors early in the process, instead of waiting until the order is sent. Ariba Buyer provides a

validity check that tests supplier location information to make sure that:

• The email address is not empty.

• The fax number is not empty and parses correctly.

• The preferred ordering method is not empty and parses correctly.

The validity check tests only the syntax of the entries, without actually testing to see if the data is valid. For

example, if the specified email address looks fine, but is in fact no longer valid, the validity check does not

report an error.

In the default configuration, Ariba Buyer calls the validity check in two places: from a scheduled task that

runs periodically to make sure that all supplier locations in your configuration are complete, and from a

condition that tests each supplier location on a requisition when the user first submits that requisition.

The rest of this section describes how the check is enabled in those two places. In the default configuration,

which is the recommended configuration, the check is enabled in both places.

SupplierLocationCheck Scheduled Task

The SupplierLocationCheck scheduled task checks all supplier location information in your configuration

on a regular basis, making sure every supplier location has appropriate contact information.

Supplier Administration Chapter 3 Supplier Data

34 Ariba Buyer Data Load Guide

Although supplier configuration information is partitioned, the SupplierLocationCheck scheduled task is not.

Each time it runs, the

SupplierLocationCheck scheduled task checks the supplier profile information for

every partition in your configuration. If there are errors, it sends Notification 16, “Notification of Invalid

Supplier Locations,” to users who have the permission

SupplierLocationCheckEmail.

To avoid memory leaks, the maximum number of entries that the emailed error list can contain is controlled

by the

System.Procure.SupplierLocationProblems parameter. The default value is 100. Once exceeded, a

message will indicate that no more supplier location problems will be reported. All invalid supplier locations

are written to the server log.

You set the schedule for the

SupplierLocationCheck task in the global scheduled task configuration file:

config/variants/Plain/partitions/None/ScheduledTasks.table

Ariba Buyer Data Load Guide 35

Chapter 3 Supplier Data Supplier Administration

The SupplierLocationCheck scheduled task takes no parameters, so the configuration file entry typically sets

a schedule. For example:

SupplierLocationCheck = {

ScheduledTaskClassName = "ariba.procure.server.SupplierLocationCheck";

Schedules = {

Schedule1 = {

DayOfWeek = Weekday;

Hour = 4;

};

Validation at Submission

In the default configuration, Ariba Buyer attaches a validity condition to the supplier location. The condition

is evaluated whenever a requisition is submitted. Therefore, when the user submits a requisition, Ariba

Buyer validates the supplier location before submitting the requisition.

You can use the parameter

Application.Procure.SubmitSupplierLocationCondition to disable or modify

this validity check. This parameter names a Java class that implements the condition. If this parameter is

missing, or set to the empty string, no validation occurs.

Rebuilding the Catalog Index

To improve search performance and reduce the size of queries, Ariba Buyer indexes the partitions where a

supplier is available and requests those partitions each time the user does a catalog search.

If you add a new supplier to an existing common supplier, you must rebuild the catalog index, either with the

Index Builder task in Ariba Administrator or the

ReindexSearchIndex task.

For more information, see the Ariba Buyer Catalog Administration Guide.

Supplier Administration Chapter 3 Supplier Data

36 Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide 37

Chapter 4 Addresses

This chapter describes how to define your address data, used for shipping and billing addresses in Ariba

Buyer. It includes the following sections:

• “Introduction to Addresses” on page 37

• “Integration Events for Addresses” on page 37

• “Billing Addresses” on page 39

Introduction to Addresses

Every Ariba Buyer configuration defines a standard set of addresses, used both for shipping addresses and

billing addresses.

Addresses are shared by all Ariba Spend Management applications. When you create an address in an Ariba

Buyer application, that address is also available to other Ariba Spend Management applications.

The common address data (the postal address) is shared across Ariba Spend Management applications, but

each application can also store additional address data that is not shared by other applications.

Addresses in the Object Model

In the object model, the locations for user data are represented by the following objects:

• A shared address, which defines data that is shared across Ariba Spend Management applications. A

shared address is of type

ariba.basic.core.Address.

• In Ariba Buyer, an Ariba Buyer address, which extends a shared address with additional

application-specific data. An Ariba Buyer address is of type

ariba.common.core.Address.

Ariba Buyer Address

The Ariba Buyer address (ariba.common.core.Address class) is a subclass of the shared address

(

ariba.basic.core.Address). The fields in the shared address (the superclass) are non-partitioned, and are

available to all Ariba Spend Management applications. The fields in the Ariba Buyer address (the subclass)

are partitioned and are available only within a specific Ariba Buyer partition.

In Ariba Buyer, you typically read addresses from an Enterprise Resource Planning (ERP) system, and use

those addresses to generate orders sent back to that ERP system. For example, if your ERP system requires a

MailStop field, that field is read from the original data source, stored on the (partitioned) address, and

included on any orders sent to that ERP system.

Integration Events for Addresses

Loading addresses into Ariba Buyer involves the following integration events:

Integration Events for Addresses Chapter 4 Addresses

38 Ariba Buyer Data Load Guide

• AddressPull

• SharedUserShipToAddressMapPull

AddressPull Integration Event

In Ariba Buyer, you use the AddressPull integration event to define the set of standard addresses for your

corporation.

The AddressPull integration event loads partitioned addresses, of type

ariba.common.core.Address, and

associates each with an existing shared address. If the shared address does not exist, the AddressPull

integration event creates the shared address as well.

Ariba Buyer provides two implementations of this integration event: one that reads from an ERP system, and

one that reads from a CSV file. Most Ariba Buyer configurations read address data from an ERP system.

The AddressPull integration event reads a data source that includes the fields of a shared address, as well as

any additional data to be included in the Ariba Buyer address.

In the default configuration, the AddressPull integration event reads from the following file:

config/variants/variant/partitions/partition/data/Address.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

For information on how to include special characters, such as line returns, in a CSV file, see the

configuration reference guide for your Ariba Spend Management application.

AddressExport Integration Event

In Ariba Buyer, you can use an AddressExport integration event to export addresses from your configuration

to a CSV file. The AddressExport integration event uses the Ariba File Channel to export data from a

partition.

In the default configuration, the AddressExport integration event writes to the following file:

config/variants/variant/partitions/partition/data/Address_Export.csv

For more information on export events, see the Ariba Spend Management Channels Guide.

Ariba Buyer Data Load Guide 39

Chapter 4 Addresses Billing Addresses

SharedUserShipToAddressMapPull Integration Event

In Ariba Buyer, you use the SharedUserShipToAddressMapPull integration event to associate shipping

addresses with users. This integration event must run after your SharedUserPull integration event and after

your AddressPull integration event.

In the default configuration, the SharedUserShipToAddressMapPull integration event reads mapping

information from the following file:

config/variants/variant/partitions/partition/data/SharedUserShipToAddressMap.csv

For example:

config/variants/vcsv/partitions/pcsv/data/SharedUserShipToAddressMap.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Billing Addresses

When a user creates a purchase requisition in Ariba Buyer, that requisition has an associated billing address.

Ariba Buyer defines a default billing address for each user, as part of that user’s User Profile data. Whenever

a user creates a requisition, Ariba Buyer uses a trigger to copy that billing address onto each line item on the

requisition.

If a user wants to change the billing address for a line item, he or she can override the default by choosing

another billing address from the address chooser.

If a user does not have a valid billing address defined, Ariba Buyer uses the default billing address for that

user’s partition, as defined by the parameter

Application.Base.Data.DefaultBillToAddress. This parameter

names the unique name of a billing address.

In the following example, the default billing address is the one that has the

UniqueName of 15, in the

AddressPull integration event:

DefaultBillToAddress = 15;

Billing Addresses Chapter 4 Addresses

40 Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide 41

Chapter 5 Accounting Information

This chapter describes how to define accounting information, associate it with users, and enable the optional

features for split line item accounting or account combinations in Ariba Buyer. It also describes the

defaulting mechanism for copying accounting information from users onto line items.

This chapter includes the following sections:

• “Introduction to Accounting Information” on page 41

• “Accounting Combinations” on page 43

• “AccountPull Integration Event” on page 45

• “Parameters for Line Item Split Accounting” on page 46

• “SplitAccountingTypePull Integration Event” on page 47

• “AccountTypePull Integration Event” on page 47

• “Account Validation” on page 48

• “Default Accounting Information” on page 48

• “Export Events and Import Translation Events” on page 51

Introduction to Accounting Information

In Ariba Buyer, items on purchase requisitions and expense reports typically require accounting

information, so that your company’s accounting department can classify the charges appropriately.

The specific accounting information required varies from one company to the next and from one partition to

the next, usually based on the accounting structures used by the underlying ERP system.

Accounting Entities

Ariba Buyer defines a generic accounting entity, which is a piece of accounting information. Examples of

accounting entities include Project, Cost Center, Account, and SubAccount.

In a typical configuration, each partition defines its own set of accounting entities. The accounting fields are

not extrinsics—they are specific instances of the generic “accounting entity.”

For information on setting up accounting entities, see “AccountPull Integration Event” on page 45.

Introduction to Accounting Information Chapter 5 Accounting Information

42 Ariba Buyer Data Load Guide

Default Accounting Information

Most accounting information is defaulted, so that users rarely have to set accounting information from the

user interface. For example, when a user creates a purchase requisition and chooses items to order, the

accounting information comes from the following sources:

• The user’s default accounting information, which is set up in the User Profile. Ariba Buyer uses the user’s

default accounting information to set the defaults for the requisition.

• The accounting information associated with the product, if any, which is based on the commodity code.

When a user chooses such an item from the catalog, the accounting information is set by default.

You define default values for each user as part of the UserPull integration event. For example, if you are

using Project and Cost Center, each user has an associated default Project and Cost Center code. For

information on the UserPull integration event, see the Ariba Spend Management Channels Guide.

Line Item Split Accounting

As part of your Ariba Buyer configuration, you can choose whether to allow split accounting for line items.

For example, you might choose to allow two departments to cooperatively buy a large piece of equipment,

sharing both its cost and its use. Ariba Buyer supports three types of split accounting:

• By percent

• By amount

• By quantity

As part of your configuration, you can specify which of those three you support for each partition. In

general, the decision about which split types to support depends on the underlying ERP system—you must

configure Ariba Buyer to support only the accounting split types that are valid in your ERP system.

For example, to allow users to split the cost of a particular line item and have one cost center pay for 60

percent and another cost center pay for 40 percent, then you must define an accounting split type that lets

users split items by percent.

To configure line item split accounting, you must do the following:

• Configure the split accounting parameters. For more information, see “Parameters for Line Item Split

Accounting” on page 46.

• Set up the SplitAccountingTypePull integration event. For more information, see

“SplitAccountingTypePull Integration Event” on page 47.

Line item split accounting is an optional feature.

Ariba Buyer Data Load Guide 43

Chapter 5 Accounting Information Accounting Combinations

Accounting Combinations

You can set up accounting combinations to accommodate your Oracle Financials configuration. Accounting

combinations are a way for an organization to enforce restrictions on combinations of accounting

information. For example, your company might have restrictions that specify which project codes are valid

in various cost centers.

The default configuration includes an example of accounting combinations, which is most often used in

Oracle configurations.

To configure accounting combinations, you must do the following:

• Configure the accounting combination parameters. For more information, see “Default Accounting

Information” on page 48.

• Set up the AccountingCombinationPull integration event. For more information, see “Default Accounting

Information” on page 48

• Include a metadata XML property on the fields you want to have validated. For more information, see

“Metadata XML for Accounting Combinations” on page 44.

Accounting combinations are an optional component of your Ariba Buyer configuration.

AccountingCombinationPull Integration Event

The AccountingCombinationPull integration event lists every valid combination of accounting entities, for

your corporation’s accounting entities. The AccountingCombinationPull integration event loads data into a

partition.

Ariba Buyer supplies implementations that read from ERP systems and from a CSV file. Typically, you use

this integration event only to support existing account combination validation in an ERP system. It’s unusual

to create a standalone version that reads from a CSV file. A typical configuration either turns off accounting

combination altogether, or reads the underlying data from an ERP system.

The accounting combination data must specify every valid pair of accounting entities.

The following example illustrates a configuration with two regions,

EastCoast and WestCoast and four cost

centers. There are only two cost centers (

2311 and 2312) that are valid in the EastCoast and two (4000 and

4100) that are valid in the WestCoast.

EastCoast,2311

EastCoast,2312

WestCoast,4000

WestCoast,4100

Accounting Combinations Chapter 5 Accounting Information

44 Ariba Buyer Data Load Guide

AccountingCombinationGroupPull Integration Event

The AccountingCombinationGroupPull integration event defines “groups” for accounting combinations.

Each group defines a full set of accounting combinations, which is enforced in the user interface. Multiple

groups are “ANDed” together, allowing for pair-wise validation. This feature is especially useful if certain

accounting fields do not actually depend on each other, and it can significantly reduce the number of entries

in accounting choosers.

For performance reasons, Ariba recommends you do not define more than five accounting combination

groups.

Metadata XML for Accounting Combinations

When you enable accounting combination validation, Ariba Buyer checks the accounting combinations in

the user interface, as the user sets up accounting information.

For example, if a user chooses

EastCoast as the region, Ariba Buyer offers only the cost centers that are valid

in that region. If the user creates a combination that’s invalid, Ariba Buyer reports the error in the user

interface, and asks the user to make corrections.

You define which fields trigger the validation by adding the

accountingCombination property to the metadata

XML for that field. The value of this property is an accounting entity in the AccountingCombinationPull

integration event. For example:

<field name="SubAccount"

respectable="true"

nullAllowed="true">

<properties

label="@aml.csv.OracleCoreExt/UserProfileDetailsSubAccountLabel"

rank="100"

nameTableClass="ariba.csv.common.OracleAccountingNameTable"

accountingCombination="SubAccount"

titleField="SubAccountDescription"

chooserField="SubAccountDescription"

allowNullValue="true"

metaDataIntegration="Reference"/>

</field>

In the default configuration, Ariba Buyer provides an implementation of accounting combinations for Oracle

that provides account combination validation on Oracle accounting fields. For the metadata XML

configuration associated with this implementation, see the file

OracleCoreExt.aml.

Ariba Buyer Data Load Guide 45

Chapter 5 Accounting Information AccountPull Integration Event

AccountPull Integration Event

Ariba Buyer represents accounting information with a generic accounting object, which is used in every

partition. An accounting object is a collection of individual accounting entities, and each partition usually

has a different collection of accounting entities.

For each partition in your configuration, you define one or more accounting entities. You use the same

integration event, the AccountPull integration event, to populate the data for each accounting entity. The

AccountPull integration event loads data into a partition.

Ariba Buyer supplies implementations of this integration event that read from ERP systems and from a CSV

file. Most configurations read accounting information from an ERP system.

Accounting Entity Fields

In the default configuration, the AccountPull integration event from a data file in the config directory under

your Server installation directory. For example, if one of your accounting entities is Department, and you are

reading accounting information from a CSV file, you would put your data in a file such as the following:

config/variants/variant/partitions/partition/data/Account.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Accounting Entities in the Default Configuration

The default configuration defines ERP system-specific accounting information for each supported ERP

system. You can either use these default values directly in your configuration, or make customizations to suit

your own accounting structures.

By default, CSV configurations use Oracle accounting structures, but read the data from a CSV file instead

of from Oracle. The default CSV configuration includes files such as

Company.csv and Product.csv, which

provide a default set of accounting data, read from a CSV file. Most corporations modify this default

accounting information to use their own preferred accounting entities.

Oracle Configurations

The following accounting entities are provided for Oracle configurations:

Oracle-11-ShipTo (corresponds to the user’s inventory organization)

Oracle-11-Department (formerly CostCenter)

Oracle-11-Company

Oracle-11-Location (formerly Region)

Oracle-11-SubAccount

Oracle-11-Product

Oracle-11-InventoryOrg

Parameters for Line Item Split Accounting Chapter 5 Accounting Information

46 Ariba Buyer Data Load Guide

PeopleSoft Configurations

The following accounting entities are provided for PeopleSoft configurations:

SAP Configurations

The following accounting entities are provided for SAP configurations:

Parameters for Line Item Split Accounting

To configure line item split accounting, you must set up the following parameters in the

config/Parameters.table file:

Because the split accounting parameters are partition-specific, you must make these changes for each

partition in your configuration.

Peoplesoft-BusinessUnit

Peoplesoft-GLBusinessUnit

Peoplesoft-DeliverToSetId

Peoplesoft-DeliverTo

Peoplesoft-ShipToSetId

Peoplesoft-ShipTo

Peoplesoft-DeptSetId

Peoplesoft-Dept

SAP-ShipTo

SAP-CostCenter

SAP-PurchaseOrg

SAP-CompanyCode

SAP-PurchaseGroup

SAP-Plant

Parameter Description

Application.Approvable.

AllowSplitAccounting

This parameter is a Boolean that enables or disables split accounting.

Application.Approvable.

MaxAccountingSplits

This is a performance tuning parameter that specifies the maximum number of

splits allowed for a given line item. In the default configuration, this parameter is

set to 99. When you set this parameter, keep in mind that:

SAP has a limit of 99 splits. If you are integrating with SAP, you must choose a

value less than 99.

Electronic Data Interchange (EDI) has a limit of 25 splits. If you are sending orders

to a supplier with EDI, you must choose a value less than 25.

Ariba Buyer Data Load Guide 47

Chapter 5 Accounting Information SplitAccountingTypePull Integration Event

SplitAccountingTypePull Integration Event

You use the SplitAccountingTypePull integration event to configure Ariba Buyer to specify the details of

your split accounting support. The SplitAccountingTypePull integration event reads partitioned data.

SplitAccountingType Fields

Ariba Buyer supplies one implementation of this integration event, which reads from a CSV file. A typical

configuration always reads split accounting data from a CSV file.

In the default configuration, this integration event reads data from the following file:

config/variants/variant/partitions/partition/data/SplitAccountingType.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Ariba Buyer requires that you define these three standard split types:

_Amount, _Percentage, and _Quantity.

You can adjust the properties for any of these split types, but you must make sure that all three are defined.

AccountTypePull Integration Event

An account type (sometimes called an account category) is a way of grouping accounts. Common examples

of account types are Expense, Revenues, and Capital.

You define the set of account types for your configuration with the AccountTypePull integration event.

The AccountTypePull integration event reads global data, shared among all partitions.

The default configuration supplies one version of this integration event, which reads from a CSV file.

AccountType Fields

In the default configuration, the AccountTypePull integration event reads from the following file:

config/variants/Plain/partitions/None/data/AccountType.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Account Types for Catalog Items

Account types are associated with catalog items, and are part of the required information for a catalog item.

The account types for catalog items are defaulted from the commodity code. For example, you can specify

that all items with the commodity code “EQUIP” have the account type Capital.

Some catalog items can potentially have multiple account types (for example, Expense or Capital), and the

user must choose which is appropriate.

Account Validation Chapter 5 Accounting Information

48 Ariba Buyer Data Load Guide

Account Validation

To disable account validation, set the validity condition on your accounting fields to

ariba.common.core.condition.ActiveClusterRoot and the name table to

ariba.common.core.nametable.NamedObjectNameTable. For example:

<!DOCTYPE extension SYSTEM "../../../../ariba/base/meta/core/extensions.dtd">

<validity clusterType="ariba.approvable.core.LineItemCollection

<condition

implementation="ariba.common.core.condition.ActiveClusterRoot"/>

</validity>

</inField>

....

</inClassVariant>

</inClass>

</inModule>

</extension>

Default Accounting Information

When a user copies a line item, or an approvable document, Ariba Buyer uses trigger events to copy

appropriate default information onto the new line items.

This section describes how Ariba Buyer uses these triggers to default accounting information. It assumes

you are familiar with how to use triggers, as described in the Ariba Spend Management Customization

Guide.

Defaulting Shipping Address

The trigger action PropagateDefaultShipping copies default shipping information from the header of a

purchase requisition onto each line item of the requisition. If the user makes changes to the shipping

information, this trigger propagates those changes to the individual line items. It uses a group to decide

which fields are copied, In the default configuration, that group is the

ShippingFields group.

The following example shows the

PropagateDefaultShippingOnChange trigger, as it is defined in the default

configuration:

<trigger name="PropagateDefaultShippingOnChange"

event="DefaultShippingChanged"

respectUserData="false">

<action implementation=

Ariba Buyer Data Load Guide 49

Chapter 5 Accounting Information Default Accounting Information

"ariba.procure.core.action.PropagateDefaultShipping">

</action>

</trigger>

If you add extrinsics to the header of a purchase requisition, and want changes to those extrinsics to be

copied onto individual line items, do the following:

• Add the extrinsics to the

ShippingFields group.

• Set

respectable=true on the fields you want to have copied. This attribute tells Ariba Buyer to keep track

of when a field has changed. For more information, see the Ariba Spend Management Customization

Guide.

Defaulting from the Requester

In the default configuration, Ariba Buyer associates two triggers with ProcureLineItem:

• DefaultProcureLineItemFromApprovable, which copies accounting information from the requisition

header onto individual line items

•

DefaultProcureLineItemFromRequester, which copies the user’s default accounting information onto

individual line items

These triggers copy default accounting information from the Requester’s default profile onto the individual

line items of a requisition. If a user changes the Requester field on a purchase requisition, the default

accounting information for the new user is copied onto each line item of the requisition. This change is done

with two trigger actions:

• The first copies data from

User onto the defaultLineItem field of the LineItemCollection.

• Then, for each line item added to the collection, the DefaultFromApprovable trigger event is fired to

initiate defaulting from the approvable onto the line item.

The fields that are copied in this situation are defined by the

ObjectDefaulting group. In the default

configuration, the

ObjectDefaulting group includes the following fields:

•

User.ShipTo

• User

• DeliverTo

• ProcureLineItem.ShipTo

• ProcureLineItem.DeliverTo

• ProcureLineItem.NeedBy

It also includes all the variant-specific fields for each Accounting object.

If there is additional accounting information that you would like to have copied onto the line item, add

extrinsics to the

ObjectDefaulting group. If there are fields in the default configuration that you prefer not

have copied, remove those fields from the

ObjectDefaulting group.

Default Accounting Information Chapter 5 Accounting Information

50 Ariba Buyer Data Load Guide

The following example shows an excerpt of the metadata XML file in the default configuration that defines

the defaulting behavior for requisitions:

<class name="ariba.procure.core.ProcureLineItem"

prefix="pli"

super="ariba.approvable.core.LineItem">

.....

<trigger name="DefaultProcureLineItemFromApprovable"

event="DefaultFromApprovable"

respectUserData="true">

</action>

<parameter name="SourcePath"

value="DefaultProcureLineItem.Accountings.SplitAccountings"/>

</action>

</trigger>

<trigger name="DefaultProcureLineItemFromRequester"

event="DefaultFromRequester"

respectUserData="true">

</action>

</action>

</trigger>

Ariba Buyer Data Load Guide 51

Chapter 5 Accounting Information Export Events and Import Translation Events

Export Events and Import Translation Events

In addition to the import translation events for accounting information, Ariba Buyer defines corresponding

export events. The export events write your data to CSV files, using the Ariba File Channel to export the

data.

For more information on export events, see the Ariba Spend Management Channels Guide. For more

information on import translation events, see the Ariba Spend Management Data Load Guide.

Export Events and Import Translation Events Chapter 5 Accounting Information

52 Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide 53

Chapter 6 Partitioned Commodity Codes

This chapter describes how to define partitioned commodity codes, map shared commodity codes to

partitioned commodity codes, map product codes on incoming catalog data to commodity codes, and

configure the exchange of commodity codes between Ariba Buyer and other Ariba Spend Management

applications. It includes the following sections:

• “Introduction to Partitioned Commodity Codes” on page 53

• “Domains” on page 54

• “PartitionedCommodityCodePull Integration Event” on page 54

• “Commodity Code Mappings” on page 55

• “Export Events and Import Translation Events” on page 58

• “Commodity Code Exchange Configuration” on page 58

• “Commodity Codes for PunchOut Items” on page 58

This chapter assumes you are already familiar with the information in the “Product Classification Codes”

chapter in the Ariba Spend Management Data Load Guide.

Introduction to Partitioned Commodity Codes

For classifying goods and services, Ariba Buyer application configurations use commodity codes, which are

a type of classification code.

In the object model, commodity codes are represented with the following classes:

•

ariba.basic.core.CommodityCode

• ariba.common.core.PartitionedCommodityCode

Shared commodity codes, of type ariba.basic.core.CommodityCode, are common data, used by all Ariba

Spend Management applications.

Partitioned commodity codes, of type,

ariba.common.core.PartitionedCommodityCode, are used only in

Ariba Buyer. If you have a partition that uses Enterprise Resource Planning (ERP) system-specific codes,

you represent those ERP system codes with partitioned commodity codes.

Most Ariba Buyer configurations use both commodity codes and partitioned commodity codes, with

mapping files to translate between the different classification systems.

This chapter describes how to configure partitioned commodity codes. For information on shared

commodity codes, see the Ariba Spend Management Data Load Guide.

Domains Chapter 6 Partitioned Commodity Codes

54 Ariba Buyer Data Load Guide

Domains

Each commodity code is defined with a domain and value pair where:

• domain is the classification system, such as United Nations Standard Products and Services Code

(UNSPSC)

• value is the code within that domain

Each Ariba Buyer configuration chooses one domain to be the system domain. For your system domain you

can choose a proprietary set of codes or you can choose an external standard such as UNSPSC. If most of

your suppliers use the same external standard, it is usually simplest to choose that as system domain.

For information on configuring and modifying the system domain, see the Ariba Spend Management Data

Load Guide.

PartitionedCommodityCodePull Integration Event

The PartitionedCommodityCodePull integration event defines a list of partition-specific commodity code

names. Typically, you use this integration event if you integrate with an ERP system that defines its own set

of commodity codes.

In the default configuration, the comma-separated value (CSV) implementation reads from the following

file:

config/variants/var/partitions/partition/data/PartitionedCommodityCode.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Considerations for Oracle Financials

If you are pulling commodity codes from Oracle Financials, some commodity codes might have a colon (:)

at the end of the code. This occurs because Oracle Financials has two levels (segments) of commodity codes,

which are concatenated with a colon, so when the second segment is null, only a colon appears at the end of

the first segment.

Ariba Buyer Data Load Guide 55

Chapter 6 Partitioned Commodity Codes Commodity Code Mappings

Commodity Code Mappings

To support multiple classification code systems, Ariba Buyer provides a flexible mapping mechanism you

can use to translate between naming conventions in different domains. Ariba Buyer uses the following

integration events to translate between codes in different domains:

• ClassificationCodeMapPull

• CommodityExportMapPull

ClassificationCodeMapPull Integration Event

When catalog items come in from suppliers with the supplier’s product codes, Ariba Buyer maps the

supplier’s codes into codes in your system domain using a commodity code map. The catalog items then go

into the product catalog, tagged with your system domain codes.

You define commodity code maps with the ClassificationCodeMapPull integration event.

You do not need to define actual

CommodityCode objects to represent supplier product codes. Instead, Ariba

Buyer uses a commodity code map to map a supplier’s product codes to commodity codes in your system

domain.

For complete information on the ClassificationCodeMapPull integration event, see the Ariba Spend

Management Data Load Guide.

CommodityExportMapPull Integration Event

When a user chooses an item to order, Ariba Buyer can potentially map the commodity code into a

partitioned commodity code before pushing the order to an ERP system. You define this mapping with the

CommodityExportMapPull integration event.

The CommodityExportMapPull integration event defines a mapping from shared commodity codes to

partitioned commodity codes. This integration event also defines default accounting information based on

commodity codes. When a user orders a catalog item, Ariba Buyer defaults any accounting fields listed in

this file, so that the user does not have to supply those values. Ariba Buyer can also default to shipping and

delivery addresses based on commodity code.

This integration event loads partitioned data. You typically have one implementation of this integration event

for each partition, which defaults accounting data appropriate for that partition.

In the default configuration, this integration event reads mapping information from the following file:

config/variants/variant/partitions/partition/data/CommodityExportMap.csv

For detailed information about the columns in this file, see the Data Dictionary. For more information see

“Using the Data Dictionary” on page 9.

Commodity Code Mappings Chapter 6 Partitioned Commodity Codes

56 Ariba Buyer Data Load Guide

How to Default Additional Accounting Data

You can default different accounting information by adding additional fields to the CommodityExportMap.csv

file.

For example, consider the following

CommodityExportMap.csv file, which shows accounting information for

an SAP configuration:

CommonIdDomain,CommonId,MaterialGroup,AccountType,CompanyCode,GeneralLedger,Asset,WBSElement,Inte

rnalOrder,ItemCategory,AccountCategory

ccc,Batteries,00706,CostCenter,3000,0000410000,,,,," ",K

ccc,Batteries,00706,CostCenter,1000,0000400000,,,,," ",K

ccc,Computer Server,01203,Asset,3000,,000000001005,,," ",A

ccc,Computer Server,01203,InternalOrder,3000,0000404000,,,000000100015," ",F

ccc,Computer Server,01203,WBSElement,3000,0000404000,,3-1200/31,," ",P

This file maps commodity codes to material groups (an SAP-specific term), and specifies default accounting

information for several additional accounting fields based on the commodity code and account type.

This example does two kinds of defaulting:

• Default Accounting Information by Company Code. In an SAP configuration, each user has a

company code, which is set in the user preferences. In this example, two sets of accounting information

are defined for the commodity code

Batteries:

ccc,Batteries,00706,CostCenter,3000,0000410000,,,,," ",K

ccc,Batteries,00706,CostCenter,1000,0000400000,,,,," ",K

When a user orders batteries, Ariba Buyer selects the line that matches the user’s preferred company code.

For example, if a user has the company code

3000, Ariba Buyer selects general ledger item 0000410000. If

a user changes the default company code to

1000 in the Title field and selects a batteries item, Ariba Buyer

selects general ledger item

0000400000.

• Default Accounting Information by Account Type and Account Assignment. The material group

01203 (commodity code Computer Server) has three different AccountType values:

ccc,Computer Server,01203,Asset,3000,,000000001005,,," ",A

ccc,Computer Server,01203,InternalOrder,3000,0000404000,,,000000100015," ",F

ccc,Computer Server,01203,WBSElement,3000,0000404000,,3-1200/31,," ",P

In the Ariba Buyer user interface, the Account Assignment field corresponds to AccountCategory, and the

Account Type field corresponds to

AccountType. If a user chooses “A (Asset)” in the Account Assignment

field and “Asset” in the Account Type field, Ariba Buyer chooses

000000001005 for the Asset number

default value. Similarly, if a user selects “F (Order)” and “Internal Order,” Ariba Buyer chooses

000000100015 for the Internal Order number default value.

For the material group

00706 (commodity code Batteries), there is only a cost center assignment:

ccc,Batteries,00706,CostCenter,3000,0000410000,,,,," ",K

ccc,Batteries,00706,CostCenter,1000,0000400000,,,,," ",K

In this case, if a user chooses “Asset” in the Account Assignment field, Ariba Buyer does not choose a

default Asset value because one is not defined in the file.

Ariba Buyer Data Load Guide 57

Chapter 6 Partitioned Commodity Codes Commodity Code Mappings

For each accounting field you add to the CommodityExportMap.csv file, you must perform the following tasks:

1 Make appropriate changes to the underlying integration event logic, so that it interprets the new fields.

For information on writing or modifying integration events, see the Ariba Spend Management Channels

Guide.

2 Add the new field or fields to the ObjectDefaulting group.

Ariba Buyer uses this group from the

CopyFields action to decide which fields to copy when defaulting

from the requisition onto line items. For example:

</groupClassVariant>

</groupClass>

</groupClassVariant>

</groupClass>

</group>

For more information on defaulting of accounting fields, see Chapter 5, “Accounting Information.”

Note: For ad hoc items, the default configuration defaults accounting information with the trigger action

ariba.procure.core.action.SetAccountingFromCommodityCode. This trigger sets accounting information on

an ad hoc

ReqLineItem from the PartitionedCommodityCode integration event by reading the

CommodityExportMap.csv file and using an entry that corresponds to that commodity code.

Default Accounting Information Based on Line Item Amount

The following optional columns let you specify default accounting information for line items on requisitions

and non-purchase order invoices based on the line item amount:

•

MinAmt and MaxAmt specify a line item amount range. Whenever the line item amount falls within the

specified range, the accounting information from the corresponding row in

CommodityExportMap.csv is

selected.

•

CurrForMinAndMaxAmt specifies the currency for the amounts in the MinAmt and MaxAmt columns.

Consider the following example:

UTF8

CommonIdDomain,CommonId,PurchasingUnit,AccountType,Account,SubAccount,Project,Product,ShipTo,Deli

verTo,MinAmt,MaxAmt,CurrForMinAndMaxAmt

unspsc,432118,All,Expense,7520,,,,US017,Arnold Davis,,,

unspsc,432118,All,Lease,7520,,,,US017,Arnold Davis,150,300,USD

unspsc,432118,All,Capital,7520,,,,US017,Arnold Davis,301,400,USD

In this example, commodity code 432118 is mapped to three account types: Capital, Lease, and Expense.

When a line item amount is between $301 and $400, Capital is selected as the account type and the other

accounting information is set from the corresponding row. Similarly, when a line item amount is between

$150 and $300, Lease is selected as the account type. If a line item amount does not fall in any specified

range, the account type is set to Expense and the other accounting information is set from the corresponding

row.

Export Events and Import Translation Events Chapter 6 Partitioned Commodity Codes

58 Ariba Buyer Data Load Guide

Export Events and Import Translation Events

In addition to the import translation events for commodity codes, Ariba Buyer defines corresponding export

events. The export events write your data to CSV files, using the Ariba File Channel to export the data.

For more information on export events, see the Ariba Spend Management Channels Guide. For more

information on import translation events, see the Ariba Spend Management Data Load Guide.

Commodity Code Exchange Configuration

To configure the exchange of commodity codes between Ariba Buyer and other Ariba Spend Management

applications, use the following parameters in the Ariba Buyer

config/Parameters.table:

•

Application.ClassificationCodes.ASMSharedDomainList

• Application.ClassificationCodes.SystemAllNodeUniqueName

The Application.ClassificationCodes.ASMSharedDomainList parameter specifies the commodity code

domains that are included when sending values to other applications. By default, this parameter is set to

ASMSharedDomainList =("unspsc"). To send additional domains, add the domain names to the

comma-separated list of values.

The

Application.ClassificationCodes.SystemAllNodeUniqueName parameter is required for configurations

that integrate Ariba Buyer with other Ariba Spend Management applications. It defines a top-level node for

the classification code hierarchy. The value is the unique name of a classification code in the domain you

have specified as your system commodity code domain, with the parameter

SystemCommodityCodeDomainName.

The classification code you specify as

SystemAllNodeUniqueName must be defined as the parent of all

top-level system commodity codes in the

CommodityCode.csv file. For more information on this parameter

and the

CommodityCode.csv file, see the “Product Classification Codes” chapter in the Ariba Spend

Management Data Load Guide.

Commodity Codes for PunchOut Items

A catalog in Ariba Buyer can include PunchOut items, where the catalog information is set up at the supplier

site and is outside the control of Ariba Buyer administrators. When commodity code information is defined

at the supplier, the commodity code is not necessarily valid in your Ariba Buyer configuration.

When the user chooses a PunchOut item, Ariba Buyer checks the commodity code:

• If a PunchOut item has a valid commodity code, Ariba Buyer maps that incoming commodity code to a

commodity code.

• If the code has not yet been mapped, it is not a valid Ariba Buyer commodity code. Ariba Buyer lets the

user select that item anyway, and maps the invalid code to the special commodity code

NONMAPPEDCOMMODITY.

Note: Mapping to 00000000 is no longer supported.

Ariba Buyer Data Load Guide 59

Chapter 6 Partitioned Commodity Codes Commodity Codes for PunchOut Items

In the default configuration, Ariba Buyer handles this special commodity code value in the following ways:

• With the condition

ariba.procure.core.condition.NonMappedCommonCommodityCode, which reports

whether a given line item has the special commodity code

NONMAPPEDCOMMODITY.

• With the base

Commodity approval rule, which inserts an appropriate approver at the beginning of the

approval flow and maps the invalid commodity code for error notification. This approver cannot edit the

commodity code within the Ariba Buyer user interface, but you can customize Ariba Buyer to add a

condition that allows editing based on the user’s role.

• With Notification 49 (Notification of Import Mapping Failure). When the

MappingLog log listener detects

error messages pertaining to PunchOut items with commodity codes that are not mapped correctly, it

sends this notification message to users who have the

CatalogManager permission.

To enable the notification, you turn on the

MappingLog log listener in the System.Logging section of the

config/Parameters.table file. You can set parameters in this log listener’s definition to customize the

subject of the notification message as well as the permission of the users to whom this notification is sent.

By default, the notification is sent to users with the

CatalogManager permission.

The Catalog Manager can use Ariba Administrator to change the commodity code to something

appropriate for your configuration, and add it to the mapping so that the error does not occur again.

Commodity Codes for PunchOut Items Chapter 6 Partitioned Commodity Codes

60 Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide 61

Chapter 7 Purchasing Units

• “Introduction to Purchasing Units” on page 61

• “Integration Events for Purchasing Units” on page 61

• “Visibility Control Configuration” on page 65

• “Export Events and Import Translation Events” on page 67

Introduction to Purchasing Units

A purchasing unit is an Ariba Buyer concept that lets you keep different sets of data distinct from one

another. Purchasing units are sometime called procurement units.

You define what a purchasing unit should be, and you can segment data on many levels. You can make the

purchasing unit object specific to Ariba Buyer, or you can map purchasing units to objects defined in your

Enterprise Resource Planning (ERP) system. For example, in a PeopleSoft partition, you can configure units

to represent business units.

Purchasing units are hierarchical. The

All purchasing unit is the parent of all purchasing units, even if it is

not explicitly specified in your CSV files.

Integration Events for Purchasing Units

Loading purchasing units into Ariba Buyer involves the following integration events:

• ProcurementUnitPull

• UserPull

• ResponsibleUserPull

For detailed descriptions of the CSV files read by these integration events, see the Data Dictionary. For more

information see “Using the Data Dictionary” on page 9.

For each variant, the following objects can serve as purchasing units:

Variant Objects

Generic Company, BusinessUnit, CostCenter, Region

SAP CostCenter, PurchaseOrg, CompanyCode, PurchaseGroup

PeopleSoft SetID, BusinessUnit, GLBusinessUnit, Department

CSV CostCenter, Company, Region

Oracle CostCenter, Company, Region, InventoryOrganization

Integration Events for Purchasing Units Chapter 7 Purchasing Units

62 Ariba Buyer Data Load Guide

ProcurementUnitPull Integration Event

The ProcurementUnitPull integration event defines purchasing units. It reads data from the following CSV

file:

config/variants/variant/partitions/partition/data/PurchasingUnit.csv

PeopleSoft Configuration

The following procedure describes how to configure purchasing units to represent PeopleSoft business units.

If you do not want purchasing units to represent business units, you must manually maintain the

PurchasingUnit.csv file.

 To configure purchasing units to represent PeopleSoft business units:

1 Export business units from your BusinessUnit.csv file into the PurchasingUnit.csv file. In the following

PurchasingUnit.csv file example, purchasing units represent business units:

UTF8

Parent,Level,EMPLID,Name,Description

All,,AUS01,AUS01,AUSTRALIA OPERATIONS

All,,BLG01,BLG01,BELGIUM OPERATIONS

2 Add the PurchasingUnit field to the BusinessUnit.csv file. For example:

UTF8

BUSINESS_UNIT,BUSINESS_UNIT_GL,DESCR,SHIPTOTAB_SETID,SUPPLIERTAB_SETID,CONTRACTTAB_SETID,BUSINE

SS_UNIT_AM,ALLOW_MC_REQ,DELIVERTOTAB_SETID,COMMCODETAB_SETID,SETID_BILL_LOCATION_,ALLOW_MC_PO,C

URRENCY_CD,PurchasingUnit

AUS01,AUS01,AUSTRALIA OPERATIONS,SHARE,SHARE,SHARE,AUS01,Y,SHARE,SHARE,SHARE:AUS01,Y,AUD,AUS01

BLG01,BLG01,BELGIUM OPERATIONS,SHARE,SHARE,SHARE,BLG01,Y,SHARE,SHARE,SHARE:BLG01,Y,EUR,BLG01

SAP Configuration

The following procedure describes how to configure purchasing units to represent SAP purchasing

organizations. If you do not want purchasing units to represent purchasing organizations, you must manually

maintain the

PurchasingUnit.csv file.

 To configure purchasing units to represent SAP purchasing organizations:

1 Export purchasing organizations from your PurchaseOrg.csv file into the PurchasingUnit.csv file. In the

following

PurchasingUnit.csv file example, purchasing units represent SAP purchasing organizations:

UTF8

Parent,Level,UniqueName,Name,Description

All,,1,Einkaufsorg. 0001,Einkaufsorg. 0001

All,,1,Zentraleinkauf EU,Zentraleinkauf EU

All,,1000,IDES Deutschland,IDES Deutschland

2 Add the PurchasingUnit field to the PurchaseOrg.csv file. For example:

UTF8

EKORG,EKOTX,BUKRS,PurchasingUnit

1,Einkaufsorg. 0001,1,1

1,Zentraleinkauf EU,1

1000,IDES Deutschland,1000,1000

Ariba Buyer Data Load Guide 63

Chapter 7 Purchasing Units Integration Events for Purchasing Units

UserPull Integration Event

You assign users to purchasing units in the file User.csv. For information on defining users and User.csv, see

Chapter 2, “Ariba Buyer Users.”

ResponsibleUserPull Integration Event

Purchasing unit responsibilities limit the approvable documents a user can see and approve. You make users

responsible for specific purchasing units through their group assignments.

You use the ResponsibleUserPull integration event to make users responsible for specific purchasing units

through their group assignments.

Before you can make a user responsible for a purchasing unit as a member of a particular group, you must

assign the user to that group, as well as to the Commodity Code Manager group. For information on

assigning users to groups, see the Ariba Spend Management Data Load Guide.

The ResponsibleUserPull integration event reads data from the following CSV files:

config/variants/variant/partitions/partition/data/ResponsibleUser.csv

config/variants/variant/partitions/partition/data/User.csv

Following is an example of ResponsibleUser.csv:

UTF8

Group,EMPLID,PasswordAdapter,PurchasingUnit

Commodity Code Manager,ghalas,PasswordAdapter1,DEU01

Expense Administrator,cnoll,PasswordAdapter1,DEU01

Invoice Agent,bsanders,PasswordAdapter1,US003

In this example:

• User ghalas is responsible for purchasing unit DEU01 as a member of the Commodity Code Manager

group.

• User cnoll is responsible for purchasing unit DEU01 as a member of the Invoice Agent group.

Integration Events for Purchasing Units Chapter 7 Purchasing Units

64 Ariba Buyer Data Load Guide

Purchasing Unit Responsibilities and Approvable Documents

Purchasing unit responsibilities affect the approvable documents a user can see as follows:

• For certain types of approvable documents, the list of available documents is limited to the list of

responsible users. For example, if user Chad Noll is responsible for purchasing unit US002 as a member

of the Payment Administrator group, he can only see payment transactions that belong to purchasing unit

US002 on the Payments page.

• Ariba Buyer treats users who have no purchasing unit responsibilities as global users. Global users can

see approvable documents for all purchasing units.

• For approvable documents that span purchasing units, if the purchasing unit is unique (for example, all

orders on an invoice belong to the same purchasing unit), the approvable document belongs to that

purchasing unit. Otherwise, it belongs to no purchasing unit.

• In general, if a user has no purchasing unit responsibilities, or if an approvable document belongs to no

purchasing unit, the user can see all approvable documents and the approvable document can be seen by

all users.

Searching and reporting capabilities are not limited by purchasing unit unless the Visibility Control feature

is enabled. For more information, see “Visibility Control Configuration” on page 65.

Purchasing Unit Responsibilities and Approval Flow

Purchasing unit responsibilities affect the approval flow of approvable documents as follows:

• For each group you associate with a purchasing unit in

ResponsibleUser.csv, Ariba Buyer generates a

private group that contains only those users who are responsible for that purchasing unit.

• Whenever a group is added to the approval flow, Ariba Buyer checks to see if any of the users who belong

to that group are responsible for the approvable document’s purchasing unit. Ariba Buyer replaces the

group with the private group, if it exists. If none of the users in the group are associated with the

purchasing unit, or if the approvable document does not have a purchasing unit, Ariba Buyer uses the

regular group.

• On the approval diagram, a private group appears with the same name as the original group. However, the

details of the group include an additional field named

Context that shows the purchasing unit associated

with the private group.

• Users who have no purchasing unit responsibilities are not added to the approval flow of approvable

documents for a given purchasing unit if another user exists who has responsibility for that purchasing

unit.

Some approval flow behavior is different when the Visibility Control feature is enabled. For more

information, see “Approval Flow Constraints” on page 67.

Ariba Buyer Data Load Guide 65

Chapter 7 Purchasing Units Visibility Control Configuration

Visibility Control Configuration

The Visibility Control feature extends the approvable document and approval flow limits provided by the

ResponsibleUserPull integration event. It also adds constraints on searching (on search pages and in

choosers) and reporting.

Parameters for Visibility Control

You use the following parameters to configure the Visibility Control feature:

•

Application.Approvable.OrganizationalVisibilityPartitioning, which specifies whether the Visibility

Control feature is enabled. The default value is

false.

•

Application.Analysis.BuyerReportingVisibilityControl, which specifies whether the Visibility Control

feature is enabled for reporting. You configure this parameter in Analysis for Ariba Buyer. The default

value is

false.

•

Application.Approvable.Defaulting.

“Query All” Groups

Most users can run queries only over their own approvable documents and those of their subordinates.

However, members of “query all” groups can query all approvable documents of a certain type, regardless of

the requester.

A query all group is a group that contains one or more of the query all permissions. For example, in the

default configuration the Invoice Administrator group is a query all group because it includes the

QueryAllInvoice permission. Users who have the QueryAllInvoice permission can query all the invoices and

invoice reconciliation documents in the system.

Search Constraints for Approvable Documents

For a user who is a member of a query all group, the Visibility Control feature limits queries to approvable

documents that belong to purchasing units the user is responsible for (according to the file

ResponsibleUser.csv). The search constraint is hierarchical—that is, users can also query approvable

documents that belong to “child” purchasing units.

When assigning users to query all groups, be sure to note the following:

• Users can query their own approvable documents, even if those documents belong to purchasing units

they are not responsible for.

• Users cannot query their subordinates’ approvable documents if those documents belong to purchasing

units they are not responsible for.

• Users that are not responsible for any purchasing units cannot query any approvable documents that

belong to other users.

• Only users that are responsible for the

All purchasing unit can query approvable documents that do not

belong to any purchasing unit.

Visibility Control Configuration Chapter 7 Purchasing Units

66 Ariba Buyer Data Load Guide

For example, suppose user Mike Ditka is responsible for purchasing unit US001 as a member of the Invoice

Manager group and is responsible for purchasing units US002 and US003 as a member of the Invoice Entry

Agent group. When the Visibility Control feature is enabled, he can only query invoice-related approvable

documents in purchasing units US001, US002, and US003 (and their “child” purchasing units, if any).

Search Constraints for Users

For a user who is a member of a query all group, the Visibility Control feature provides the following search

constraints for users:

• Users can query other users in:

• Their own purchasing unit and any purchasing unit they are responsible for.

• The “child” purchasing units of their own purchasing unit and of any purchasing units they are

responsible for.

For example, the usernames available in the On Behalf Of chooser are filtered based on the purchasing

unit associated with each user in

User.csv.

• Users who are responsible for the

All purchasing unit can query all users.

• Users can query all users that do not belong to any purchasing unit.

PeopleSoft Considerations

Other objects, such as suppliers, are filtered based on the PeopleSoft SetID. (When the Visibility Control

feature is not enabled, users are also filtered based on the PeopleSoft SetID.)

For example, suppose user Jack Thornton is associated with SetID

EGVL1. When he creates an approvable

document, the document defaults to SetID

EGVL1 and the fields and choosers are filtered based on SetID

EGVL1. If Jack changes the SetID of the approvable document, field and chooser filtering changes to use the

new SetID.

SAP Considerations

Other objects, such as suppliers, are filtered based on the SAP company code. (When the Visibility Control

feature is not enabled, users are also filtered based on the company code.)

For example, suppose user Alex Agassi is associated with SAP company code 3000. When he creates an

approvable document, the document defaults to company code 3000 and the fields and choosers are filtered

based on company code 3000. If Alex changes the company code of the approvable document, field and

chooser filtering changes to use the new company code.

Ariba Buyer Data Load Guide 67

Chapter 7 Purchasing Units Export Events and Import Translation Events

Report Constraints

In reports, facts represent approvable documents and dimensions represent non-approvable objects, such as

users.

When the Visibility Control feature is enabled for reporting, the same constraints that apply to searches for

approvable documents also apply to facts with one exception: users cannot query their own approvable

documents if those documents belong to purchasing units they are not responsible for.

The User dimension is filtered in same way as the On Behalf Of chooser, with one limitation: the search

constraint is flat.

Approval Flow Constraints

The Visibility Control feature affects the approval flow of approvable documents as follows:

• If an approvable document is assigned to a purchasing unit that has no responsible user, or if an

approvable document does not have a purchasing unit, Ariba Buyer sends it to users who are responsible

for the

All purchasing unit for the appropriate group.

• Users responsible for the

All purchasing unit are not added to the approval flow of approvable documents

for a given purchasing unit if another user exists who has responsibility for that purchasing unit.

• Any group specified in the

ResponsibleUser.csv file has an All private group, even if there are no users in

that group. This behavior prevents approvable documents from being visible to the wrong users.

For example, suppose User2 is responsible for purchasing units

All and B as a member of the Invoice

Manager group. In this case, User2 would be added to the approval flow for:

• All invoice-related approvable documents that do not have a purchasing unit, and

• All invoice-related approvable documents that belong to purchasing unit B.

Export Events and Import Translation Events

In addition to the import translation events for purchasing units, Ariba Buyer defines corresponding export

events. The export events write your data to CSV files, using the Ariba File Channel to export the data.

For more information on export events, see the Ariba Spend Management Channels Guide. For more

information on importing translations see the Ariba Spend Management Data Load Guide.

Export Events and Import Translation Events Chapter 7 Purchasing Units

68 Ariba Buyer Data Load Guide

Ariba Buyer Data Load Guide 69

account category 47

account type 47

account validation 48

Account.csv file

field descriptions 45

accounting combinations

about 43

configuring 43

metadata XML 44

accounting entities

about 41

Oracle configurations 45

PeopleSoft configurations 46

SAP configurations 46

accounting information

about 41

default settings 42

defaulting from requester 48

line item split accounting 42

max accounting splits 46

accounting integration events

AccountingCombinationPull 43

AccountPull 45

AccountType 47

AccountTypePull 47

accounting object 45

accounting parameters

AllowSplitAccounting 46

MaxAccountingSplits 46

AccountingCombinationPull integration event 43, 44

AccountPull integration event 45

AccountType integration event 47

AccountTypePull integration event 47

Adapter source values 10

adding

common suppliers 29

users 13

address

partitioned 37

shared address 37

address integration events

AddressExport 38

AddressPull 38

SharedUserAddressMap 39

Address_Export.csv file 38

addresses

about 37

billing 39

AddressExport integration event 38

AddressPull integration event 38

AllowSplitAccounting parameter 46

application authentication parameters

ModifyUserProfileOnInitialLogin 19

ModifyUserProfileOnInitialLogon 17

OrganicGrowth 17

application base data parameters

DefaultBillToAddress 39

DefaultOrganicUserLocale 17

Application.Approvable.AllowSplitAccounting

parameter 46

Ariba Buyer

address 37

configuring organic user growth 17

partitioned commodity codes 53

supplier data 21

users 13

Ariba Buyer Administrator

using the Supplier Manager 29

Ariba Network IDs 21

Ariba SN

loading suppliers 27, 28

suppliers 21

ariba.basic.core.Address type 37

ariba.basic.core.CommodityCode class 53

ariba.common.core.address object 37

ariba.common.core.PartitionedCommodityCode class

ariba.common.core.User object 13

ariba.procure.core.action.SetAccountingFromCommodi

tyCode trigger action 57

ariba.user.core.User object 13

AribaNetworkFullSubscriptionSync scheduled task 26

AribaNetworkOrganizationSync scheduled task 28

ASMSharedDomainList parameter 58

assigning

supplier IDs 27

billing address 39

bulk loading

common suppliers 30

Index

70 Ariba Buyer Data Load Guide

Index

catalog index, rebuilding 35

Catalog item PunchOut 33

catalog load, adding suppliers 26

classes

ariba.basic.core.CommodityCode 53

ariba.common.core.PartitionedCommodityCode 53

classification code domains 58

classification codes