Contract Administration Guide - SAP Ariba EchoSign and set up an account for your organization....

December 2014

Contract Administration GuideAriba Contract Management™

Content

Enabling Electronic Signatures in Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4About Electronic Signatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Enabling DocuSign Electronic Signatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

About Setting Up DocuSign Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Setting Up DocuSign Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Assigning Electronic Signature Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6About Managing Your DocuSign Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Enabling Electronic Signatures with DocuSign. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Enabling EchoSign Electronic Signatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Enabling Electronic Signatures with EchoSign. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Enabling Paper Signatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Importing Legacy Contracts into Contract Workspaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9About Legacy Contract Import Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9About Legacy Contract Import Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Planning Legacy Contract Loads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10About Folders for Imported Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Legacy Contract Import ZIP File Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

ZIP File Structure Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Unicode Requirement for File Names in the ZIP File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12CSV Load File Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12About the ImportProjectsParameters.csv File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13About the Contracts.csv File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20About the ContractDocuments.csv File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28About the ContractTeams.csv File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Loading Legacy Contracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Example: Loading a Contract and Related Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Contract Workspace Export Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33About the Export Workspace Data Download Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33About the Workspace ZIP File and wsId Workspace Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33About the xsd Folder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34About the wsId.csv File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34About the wsID Folder for Project Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

About Files for Form Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36About the Plan Folder and Phase Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37tasks.xml File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2 © 2015 SAP SE or an SAP affiliate company. All rights reserved.Contract Administration Guide

Content

About the PermissionBitVec Element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Revision History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Contract Administration GuideContent © 2015 SAP SE or an SAP affiliate company. All rights reserved. 3

Enabling Electronic Signatures in Contracts

The Electronic Signature feature enables you to collect electronic signatures, initials, and other user-specified data for a contract stored in a PDF file.

About Electronic Signatures

Ariba provides Electronic Signature through integration with third-party vendors, DocuSign® and Adobe® EchoSign®. Task owners can manually complete signature tasks when paper signatures are used. Signature tasks allow you to send contractual documents for signing quickly and securely across the Internet.

For information on generating PDF documents and creating signature tasks, see the Ariba Contract Management Process Management Guide.

This is an out-of-the-box feature available to all customers. However, the method of enabling varies for different electronic service providers. DocuSign (Legacy) customers (who had configured to use DocuSign in releases prior to the Ariba Application 2014 March Release) must have their Designated Support Contact log a service request to disable or modify parameters related to DocuSign service. DocuSign, EchoSign and Manual Signature options are available out of box and the method of enablement is explained in Enabling EchoSign Electronic Signatures [page 7].

Enabling DocuSign Electronic Signatures

Enabling Electronic Signature with DocuSign involves two high-level steps: Contact DocuSign and set up an account for your organization; and add user accounts to the DocuSign account for task owners.

After you complete these steps, the users in your organization can begin creating Signature tasks on documents of types .pdf, xls, xlsx, txt, rtf, doc, docx, ppt, pptx, png, jpg, gif and .tif.

About Setting Up DocuSign Accounts

You must set up two kinds of DocuSign accounts: a single DocuSign administrator account, and one DocuSign user account for each Ariba task owner who will submit signatures tasks to DocuSign.

● Your organization has a single administrator account with DocuSign. You are responsible for setting up and managing this account, which includes account configuration and administration. Users with access to the administrator account can see documents submitted for signing.

● Each task owner that submits a signature task to DocuSign must have a user account associated with your company’s administrator account. This account must be registered to the same email account configured for the task owner on the Ariba server.



In addition, document signers set up separate user accounts with DocuSign. You do not have to set up accounts for document signers. If a signer does not have a DocuSign account, DocuSign sends an email to the signer that includes a link that enables the signer to create a new account and to sign the document.

Setting Up DocuSign Accounts

Setting up your DocuSign administrator and user accounts involves contacting DocuSign to establish an initial administrator account, activating that account, and then creating one user account for each intended user.

Procedure

1. Contact DocuSign and request an account with web service API access.

DocuSign creates your company’s account and sends you an email prompting you to activate your administrator account on the DocuSign website. The account’s login name is an email address of the user who has administrator access to the account. DocuSign provides you with values for UserID, password and DocuSign URL.

2. Log in to your DocuSign account and follow the instructions to activate it.3. Add user accounts associated with your administrator account for task owners (users who will submit

signature tasks). Each DocuSign user account must:

○ Be registered to the same email account configured for a corresponding task owner on the Ariba server.○ Have the following permissions:

Send EnvelopesSend On Behalf Of Rights (API)If the only task owner who will be submitting signature tasks to DocuSign is the same user configured for your DocuSign administrator account, you can skip this step.For information about adding user accounts, refer to the online help in your DocuSign account.

Results

NoteCustomers can continue to use the DocuSign (Legacy) feature. To disable DocuSign (Legacy), you must have your Designated Ariba Support contact submit a Service Request.

Contract Administration GuideEnabling Electronic Signatures in Contracts © 2015 SAP SE or an SAP affiliate company. All rights reserved. 5

Assigning Electronic Signature Permissions

Assign all of the users in your organization who need to sign documents to the Ariba Document Signer global user group.

See the Ariba Common Data Import and Administration Guide for more information on assigning users to groups.

About Managing Your DocuSign Account

DocuSign enables you to view an audit trail for documents in the DocuSign system, and create and view a report of documents submitted for signing.

● View an audit trail for documents in the DocuSign system. Ariba Spend Management polls DocuSign for information frequently for updates.

● Create and view a report of documents submitted for signing. This is referred to as an envelope report and includes the sender (task owner) and recipient (signer) email addresses and status information.

See the online help in your DocuSign account for instructions on performing the tasks listed above and information on other account management tasks and policies.

Enabling Electronic Signatures with DocuSign

After you create your DocuSign accounts, you need to enable electronic signatures.

Procedure

1. Go to Manage > Administration > Project Manager > Signature Providers.2. Navigate to the DocuSign area of the page and select Yes for the Enabled radio button.3. Enter User Id and Password for your DocuSign account.

NoteYou must have an account with DocuSign to obtain User Id and Password.

4. Select the Demo Account check box to set up a demo account.5. Click Test Connection.

After connecting successfully, you will be able to punch out to the DocuSign website when you submit the signature task.

6. Click Save.



Results

NoteCustomers can continue to use the DocuSign (Legacy) feature and must have your Designated Ariba Support contact submit a Service Request to disable DocuSign (Legacy). For more information about how to enable and configure DocuSign, refer the technical note, https://knowledge.ariba.com/go2/1,,152241,00.html at Ariba Knowledge site.

Enabling EchoSign Electronic Signatures

Enabling Electronic Signatures with EchoSign involves three steps: setting up an account, receiving and EchoSign API key for your account, and adding users to your account.

1. Contact EchoSign and set up an account for your organization. Request an EchoSign account to be used with the Ariba integration.

NoteYou must inform EchoSign that you are using Ariba integration for electronic signatures. Based on your request, EchoSign will move you to a particular channel that has settings preset that will get automatically inherited by your account.

2. Obtain the EchoSign API key for your account. You specify the key value in the Ariba configuration.The Adobe EchoSign API requires every customer to have a unique API key allowing them to integrate their solution to EchoSign. This enables the user working with Ariba solution to initiate transactions within EchoSign to get documents signed entirely from within the Ariba application. For information on how to obtain the API key refer to the following guide:https://www.echosign.adobe.com/content/dam/echosign/docs/pdfs/EchoSign%20API%20Guide_v2.pdf

3. Add user accounts to your EchoSign account for Ariba signature task owners.When an Ariba task owner submits a task to EchoSign, Ariba sends the task owner’s email address to EchoSign. This email address must match an email address associated with your company’s EchoSign account.Add user accounts to your company’s EchoSign account for signature task owners (users who will submit signature tasks). Note that each EchoSign account must be registered to the same email account configured for the task owner on the Ariba server. For information about adding user accounts, refer to the online help in your EchoSign account.

NoteYou can skip this step if the only task owner who will be submitting signature tasks to EchoSign is the user configured as your EchoSign Account Administrator (the first user created in your EchoSign account).

Contract Administration GuideEnabling Electronic Signatures in Contracts © 2015 SAP SE or an SAP affiliate company. All rights reserved. 7

http://help.sap.com/disclaimer?site=https://knowledge.ariba.com/go2/1,,152241,00.html

http://help.sap.com/disclaimer?site=https://www.echosign.adobe.com/content/dam/echosign/docs/pdfs/EchoSign%20API20Guide.pdfAPI%20key

http://help.sap.com/disclaimer?site=https://www.echosign.adobe.com/content/dam/echosign/docs/pdfs/EchoSign%20API20Guide.pdfAPI%20key

Enabling Electronic Signatures with EchoSign

After you create your EchoSign account and add users, you need to enable electronic signatures.

Procedure

1. Go to Manage > Administration > Project Manager > Signature Providers.2. Navigate to the EchoSign area of the page and select Yes for the Enabled radio button.3. Enter the API Key obtained from Adobe EchoSign in the text box.4. Click Test Connection.5. After connecting successfully, you will be able to punch out to the EchoSign website when you submit the

signature task.6. Click Save.

Next Steps

Next Steps

Grant internal users the ability to sign documents in signature tasks by assigning them to the Document Signer group. For instructions, see the Ariba Common Data Import and Administration Guide.

Enabling Paper Signatures

You can also enable permissions to allow users to provide manual signatures for tasks.

1. Go to Manage > Administration > Project Manager > Signature Providers.2. Select the check box next to Allow task owners to manually complete signature tasks.3. Click Save.



Importing Legacy Contracts into Contract Workspaces

You can use the legacy contract import feature to load existing contracts or legacy contracts from any other contract repository to Ariba Contract Management. This enables you to keep a record of previous contracts and provide a starting point for future contracts.

To upload legacy contracts into Ariba Contract Management, you must provide information about existing contracts in a CSV format. Because of the wide variety of possible current formatting of legacy contracts, Ariba does not supply a tool to explicitly format your existing contracts, nor does it provide more than general instructions on converting the specific formats of your contracts to the required format.

Before you import legacy contracts, you must already have created one or more project templates in Contract Management that accurately model your business flow. Those templates must contain all necessary fields and any necessary tasks.

About Legacy Contract Import Functions

The legacy contract import operation can create contract workspaces with some or all of the attribute fields specified, add documents to contract workspaces (optional), add multiple versions of a contract (optional), and specify team members for contract workspaces (optional)

The template used to create the contract workspaces is specified by the TemplateName parameter of the ImportProjectsParameters.csv file, described in About the ImportProjectsParameters.csv File [page 13].

The legacy contract import operation is an additive operation. Information from the import is appended to the information already in the template specified in the TemplateName parameter. For example, if the template specifies three team members and the bulk import specifies two more team members (different from those already in the template), the final contract contains five team members.

About Legacy Contract Import Restrictions

Some operations cannot or should not be performed using legacy contract import, including adding tasks, updating workspaces you are currently working on, or editing of contract workspaces, among others.

● You cannot add tasks to a contract workspace using the legacy contract import operation, but you can create the workspaces using a project template that contains tasks. You also cannot add multiple versions of documents.

● Do not attempt to use the legacy contract import feature to update contract workspaces you are currently working on in Ariba Contract Management.

● Do not use this feature to reload contract workspaces that are already loaded in Ariba Contract Management.

Contract Administration GuideImporting Legacy Contracts into Contract Workspaces © 2015 SAP SE or an SAP affiliate company. All rights reserved. 9

● Never use this feature to edit contract workspaces. This feature is not intended to perform mass edit functions, and attempting to use it for editing might cause unintended duplicate workspaces with mismatched data. To edit multiple contract workspaces, you can use the Project Mass Edit feature as described in the .

● You cannot import assembled contract documents (Main Agreement or Contract Addendum documents) using this feature. Documents loaded using legacy contract import cannot use any of the special features provided by assembled contract documents, such as the Clause Library.

● You cannot create a link between a contract workspace and a compliance contract as part of a legacy contract import. If your Ariba Contract Management is integrated with Ariba procurement or invoice solutions, you can manually link a contract workspace with a compliance contract after the workspace is imported.You cannot import load contract terms or pricing terms files using this feature. You can create a contract terms file in a contract workspace after the import. If you load a Microsoft Excel file that meets the format requirements for a pricing terms file, you can edit its attributes to use it as a pricing terms file after the import.

● If a legacy contract import operation fails and you want to reuse your ZIP file to retry the import operation, view the log file to determine which contracts loaded successfully. Remove entries for these contracts from the ZIP file before retrying the import operation.

● The maximum size for the input ZIP file is 100 megabytes. If the contracts you want to load do not fit in a ZIP file that is smaller than 100 megabytes, divide the contracts you want to load and create multiple ZIP files.

Planning Legacy Contract Loads

The number and scope of legacy contracts can vary from one company to another, so it is important to plan before attempting a bulk upload of legacy contracts.

Keep the following considerations in mind when planning legacy contract loads:

● Ariba recommends that you do not put more than 1000 contract workspaces in any one folder in Ariba Contract Management. Folders that contain more than 1000 contracts can affect Ariba Contract Management performance and cause application errors. For more information, see About the Contracts.csv File [page 20].

● Load contract workspaces in small batches to ensure you are getting the expected result. It is easier to discover and correct an error early in the loading process than it is to fix numerous contract workspaces after they have been loaded.

● Loading legacy contract workspaces is a time-consuming process. For example, an upload of 7500 contract workspaces with no added documents or team members through a moderately complicated template takes approximately 16 hours. Because of the time involved, be sure you verify all data before loading it.

● Ariba Contract Management evaluates each entry in the load attributes file (Contracts.csv) one line at a time. For each line, Ariba Contract Management creates one contract workspace and then the information specified for documents and team members is used to populate the workspace. If the load fails on any line of the Contracts.csv file during the contract workspace creation, the bulk load fails and terminates. If the load fails during the document or team members population portion of the load, an error is logged, and the load continues.All lines loaded before a failing upload are retained. For example, if you are loading 10 contract workspaces, and the load fails on line seven, the first six contract workspaces will have already been loaded into the system when the load fails. If you fix the incorrect line (seven) and re-run the load, the first six (existing) contract workspaces will be updated. If you do not retry the load, those six contract workspaces remain in the system.

● Ariba recommends that you load all legacy contract workspaces in published status, because when you amend a workspace the version number changes only if it is published.



● Contract import supports only the English decimal separator for amounts in contracts. For example, to specify the amount for forty dollars, enter 40.00.

● If you are loading autorenewal contracts, set the Expiration Date to the next expiration date (a date in the future) if possible. The system only updates contract status and expiration dates when a system automated task runs; this task runs once per day. If you have an autorenewal contract workspace, the system automated task can increment the Expiration Date as needed, but it can only increment the Expiration Date by one renewal interval each time it runs. Similarly, the system automated task can decrement the number of remaining renewals as needed, but it can only decrement the number of remaining renewals by one each time it runs.

About Folders for Imported Contracts

Legacy contract import operations place contract workspaces in folders as specified parameters in the ImportProjectsParameters.csv file.

Specific parameters in ImportProjectsParameters.csvthat determine the folders where contract workspaces are placed include:

● RootParentId● TopFolderName● FolderFieldName● FolderFieldPattern● FolderFormat

These parameters are described in About the ImportProjectsParameters.csv File [page 13]. You can use these settings is to distribute imported workspaces across a nested tree of folders within the root folder, so that no folder has too many workspaces in it.

Legacy Contract Import ZIP File Contents

A legacy contract import ZIP file must contain the ImportProjectsParameters.csv file, the Contracts.csv file, and all documents to be included in the loaded workspace. In addition you may want or need to include ContractDocuments.csv and ContractTeams.csv filec depending on your needs.

The following table lists the files that must be included, or are optional, and describes any requirements about the placement of the files within the ZIP file:

Table 1:

File Name Comments

ImportProjectsParameters.csv

All archive ZIP files must contain this file, at the top level of the ZIP file.

See About the ImportProjectsParameters.csv File [page 13].


File Name Comments

Contracts.csv All archive ZIP files must contain this file at the top level of the ZIP file.

See About the Contracts.csv File [page 20].

ContractDocuments.csv Include this file if you want to import any documents into the workspaces you are loading. It must be at the top level of the ZIP file.

See About the ContractDocuments.csv File [page 28].

ContractTeams.csv Include this file if you want to add team members to the workspaces you are loading in excess of the members defined by the template defined in the ImportProjectsParameters.csv file. It must be at the top level of the ZIP file.

See About the ContractTeams.csv File [page 29].

Documents to be included in the loaded workspaces

All documents referenced in the ContractDocuments.csv must be included in the archive ZIP. These documents may be nested in folders in the ZIP file.

ZIP File Structure Requirements

Do not nest any configuration CSV files inside the ZIP file.

All configuration CSV files must be at the top level of the archive ZIP and the only subdirectories within the ZIP file should be the documents referenced by the ContractDocuments.csv file. If, for example, you create the ZIP archive by highlighting a folder containing the CSV files (instead of the files themselves) and creating the ZIP, the load fails.

Unicode Requirement for File Names in the ZIP File

If you are creating a ZIP file that contains file names with non-ASCII characters, the ZIP utility must store the file names using UTF-8 (Unicode) format.

WinZip utility versions 11.2 and later support the option Store Unicode filenames in Zip files and enable this option by default. SecureZIP versions 11 and later support the option Store file names and comments in UTF-8 format, but do not enable this option by default.

CSV Load File Formats

In addition to setting up a template that properly accepts all fields and documents imported from pre-existing contracts through the legacy contract import, you must create or modify some files that must also be loaded in specific order.



The files that require modification and strict load ordering include:

● Contracts.csv● ContractId● ContractTeams.csv

The following graphic shows you which files affect various areas of a legacy contract, as well as which parts of a workspace come from the template used for the loadd:

About the ImportProjectsParameters.csv File

The archive ZIP file must contain an ImportProjectsParameters.csv file with a specific set of columns in a specific order.

The following table list the necessary columns that ImportProjectsParameters.csv must contain in the specific order they must appear:

Table 2:

Column in ImportProjectsParameters.csv Function

WorkspaceLookupKey Specifies the workspace field the import will use to uniquely identify each workspace you are loading.

Each value of WorkspaceLookupKey must be a valid contract identifier, such as Title or ContractId. The default value is ContractId.

TemplateName Specifies the name of the template to use when loading the content of the ZIP file into a contract workspace. The template must:

● Exist in the target Contract Management instance.● Be published and active.● Not have any access control enabled that would restrict the

user loading the contracts from accessing the template before field values are evaluated.Ariba also recommends that you use a template with no conditions or questions. There is no mechanism to provide answers to template questions.



AttributesFileLocation Specifies the location of the Contracts.csv file within the ZIP file you are loading. The path is relative to the top level of the ZIP file.

DocumentsFileLocation Specifies the location of the ContractDocuments.csv file within the ZIP file you are loading. The path is relative to the top level of the ZIP file.

TeamsFileLocation Specifies the location of the ContractTeams.csv file within the ZIP file you are loading. The path is relative to the top level of the ZIP file.

RootParentId Controls the top level, or parent, folder in which the system places all imported workspaces.

By default, this parameter is left blank. If this parameter is blank, the system creates all workspaces in the default folder Contract Workspaces.

If you want to put all contract workspaces in a single directory, regardless of project type, set the RootParentID to an InternalID string.

TopFolderName Controls the title of the folder placed inside the RootParentID directory, which contains all the imported workspaces.

If this parameter is missing or blank, then the parameter is used as the folder name under the RootParentID in the path of the newly created project.

FolderFieldName Controls the name of the field which uniquely identifies each individual workspace being loaded.

Ariba recommend that you use the value ContractId for this parameter.




FolderFieldPattern FolderFieldPattern has a recommended value of "([1-9][0-9]*)".

Specifies how the system recognizes workspaces to be collected into the same tree of folders. The value of this parameter must conform to the syntax of regular expressions supported by the Java Pattern class in the java.util.regex package. Documentation on regular expression syntax can be found on the Pattern page under http://download.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html. The pattern needs to define a capture group, delimited by parentheses. The recommended value captures the first contiguous series of one or more digits in the field value, ignoring leading zeroes. If the field is unique because of a numeric value embedded in it, this is an appropriate pattern, and it works well for the default ContractId values.

If you change FolderFieldName to a different field that generates its uniqueness in a different way, you might have to change the pattern to match. For example, if the field value has a unique numeric substring but it is not the first numeric string in the field value, you must change the pattern to skip earlier numeric strings and recognize the correct numeric string in some way. The varying string might not be numeric (any Unicode characters can be used) and you could change the pattern to match a series of characters instead.

FolderFormat FolderFormat has a recommended value of "{0} to {1}".

This format is used to generate folder names that are used to subdivide the range of unique values recognized by FolderFieldPattern into a tree of folders where each folder only holds variation in one character. The depth of folders will match the length of the unique string, one level for each character. In generating the parameters to substitute into {0} and {1}, the characters that are below in the folder tree and to the right in the string will be replaced by '0' in {0} and by '9' in {1}, to represent the low and high character values in the range. This assumes that the variation is through numeric digits from '0' to '9', but in fact the variation can include any Unicode characters, regardless of how the folder names are generated.

The main reason to change this value is to make it blank to make sure it uses the built in localization for non-English default languages.

If FolderFormat is null or blank then it defaults to a localized version of this value in the current user session's locale.



SendEmailNotificationAfterProjectCreate

Controls whether email is sent after each project is created during the bulk load. The default value is False (do not send project create notifications during legacy contract imports).

If the value is True, Ariba Spend Management sends a project status change message to all active team members created from the project template except members of the Project Owner group. Notifications are not sent to team members added from the ContractTeams.csv file (these team members are added after the project is created).

If you set this value to True and import a large number of contracts, Ariba Contract Management will send a large number of email notifications, which might cause delays for other email notifications.

Example

The following is an example of an ImportProjectsParameters.csv file:

workspaceLookupKey,TemplateName,AttributesFileLocation,DocumentsFileLocation,TeamsFileLocation,RootParentId,TopFolderName,FolderFieldName,FolderFieldPattern,FolderFormat,SendEmailNotificationAfterProjectCreate

"ContractId","Simple Purchase Agreement","Contracts.csv","ContractDocuments.csv","ContractTeams.csv","","ImportedWorkspaces","ContractId","([1-9][0-9]*)","{0} to {1}","False"

About the ImportProjectsParameters.csv File

The archive ZIP file must contain an ImportProjectsParameters.csv file with a specific set of columns in a specific order.

The following table list the necessary columns that ImportProjectsParameters.csv must contain in the specific order they must appear:

Table 3:


WorkspaceLookupKey Specifies the workspace field the import will use to uniquely identify each workspace you are loading.

Each value of WorkspaceLookupKey must be a valid contract identifier, such as Title or ContractId. The default value is ContractId.




TemplateName Specifies the name of the template to use when loading the content of the ZIP file into a contract workspace. The template must:

● Exist in the target Contract Management instance.● Be published and active.● Not have any access control enabled that would restrict the

user loading the contracts from accessing the template before field values are evaluated.Ariba also recommends that you use a template with no conditions or questions. There is no mechanism to provide answers to template questions.

AttributesFileLocation Specifies the location of the Contracts.csv file within the ZIP file you are loading. The path is relative to the top level of the ZIP file.

DocumentsFileLocation Specifies the location of the ContractDocuments.csv file within the ZIP file you are loading. The path is relative to the top level of the ZIP file.

TeamsFileLocation Specifies the location of the ContractTeams.csv file within the ZIP file you are loading. The path is relative to the top level of the ZIP file.

RootParentId Controls the top level, or parent, folder in which the system places all imported workspaces.

By default, this parameter is left blank. If this parameter is blank, the system creates all workspaces in the default folder Contract Workspaces.

If you want to put all contract workspaces in a single directory, regardless of project type, set the RootParentID to an InternalID string.

TopFolderName Controls the title of the folder placed inside the RootParentID directory, which contains all the imported workspaces.

If this parameter is missing or blank, then the parameter is used as the folder name under the RootParentID in the path of the newly created project.

FolderFieldName Controls the name of the field which uniquely identifies each individual workspace being loaded.

Ariba recommend that you use the value ContractId for this parameter.



FolderFieldPattern FolderFieldPattern has a recommended value of "([1-9][0-9]*)".

Specifies how the system recognizes workspaces to be collected into the same tree of folders. The value of this parameter must conform to the syntax of regular expressions supported by the Java Pattern class in the java.util.regex package. Documentation on regular expression syntax can be found on the Pattern page under http://download.oracle.com/javase/1.4.2/docs/api/java/util/regex/Pattern.html. The pattern needs to define a capture group, delimited by parentheses. The recommended value captures the first contiguous series of one or more digits in the field value, ignoring leading zeroes. If the field is unique because of a numeric value embedded in it, this is an appropriate pattern, and it works well for the default ContractId values.

If you change FolderFieldName to a different field that generates its uniqueness in a different way, you might have to change the pattern to match. For example, if the field value has a unique numeric substring but it is not the first numeric string in the field value, you must change the pattern to skip earlier numeric strings and recognize the correct numeric string in some way. The varying string might not be numeric (any Unicode characters can be used) and you could change the pattern to match a series of characters instead.

FolderFormat FolderFormat has a recommended value of "{0} to {1}".

This format is used to generate folder names that are used to subdivide the range of unique values recognized by FolderFieldPattern into a tree of folders where each folder only holds variation in one character. The depth of folders will match the length of the unique string, one level for each character. In generating the parameters to substitute into {0} and {1}, the characters that are below in the folder tree and to the right in the string will be replaced by '0' in {0} and by '9' in {1}, to represent the low and high character values in the range. This assumes that the variation is through numeric digits from '0' to '9', but in fact the variation can include any Unicode characters, regardless of how the folder names are generated.

The main reason to change this value is to make it blank to make sure it uses the built in localization for non-English default languages.

If FolderFormat is null or blank then it defaults to a localized version of this value in the current user session's locale.




SendEmailNotificationAfterProjectCreate

Controls whether email is sent after each project is created during the bulk load. The default value is False (do not send project create notifications during legacy contract imports).

If the value is True, Ariba Spend Management sends a project status change message to all active team members created from the project template except members of the Project Owner group. Notifications are not sent to team members added from the ContractTeams.csv file (these team members are added after the project is created).

If you set this value to True and import a large number of contracts, Ariba Contract Management will send a large number of email notifications, which might cause delays for other email notifications.

Example

The following is an example of an ImportProjectsParameters.csv file:

workspaceLookupKey,TemplateName,AttributesFileLocation,DocumentsFileLocation,TeamsFileLocation,RootParentId,TopFolderName,FolderFieldName,FolderFieldPattern,FolderFormat,SendEmailNotificationAfterProjectCreate

"ContractId","Simple Purchase Agreement","Contracts.csv","ContractDocuments.csv","ContractTeams.csv","","ImportedWorkspaces","ContractId","([1-9][0-9]*)","{0} to {1}","False"


About the Contracts.csv File

The Contracts.csv file specifies all contracts that are to be imported into Ariba Contract Management, as well as their individual attributes. Contracts are loaded from Contracts.csv file one line at a time, sequentially. Never include undefined attribute field names.

Required fields must appear at the beginning of the Contracts.csv file, and must appear in a specific order. The following table lists the fields that are mandatory in the Contracts.csv file depending on whether you are uploading with or without multiple contract versions:

Table 4:

Contract Versions Required Fields and Field Order

Without multiple contract versions

Owner [page 22]

Title [page 23]

ContractId [page 23]

HierarchicalType [page 24]

With multiple contract versions

Owner [page 22]

Document Version [page 22]

AdjacentVersion [page 22]

Title [page 23]

ContractId [page 23]

HierarchicalType [page 24]

Whether or not you are uploading multiple versions of a contract, the Contracts.csv file can also contain any number of fields you want to specify in the contract workspace. All fields listed in the Contracts.csv file must exist in the project template specified in the ImportProjectsParameters.csv file. Adding a field to the Contracts.csv file that does not exist in the project template will cause the legacy contract import to fail.

Optional fields you can specify include, but are not limited to the following:

● AgreementDate● Amount● AutoRenewInterval and MaxAutoRenewalsAllowed (valid only if the ExpirationTermType is

AutoRenew)● BaseLanguage (see BaseLanguage [page 24])● Client (Departement)● Commodity● EffectiveDate● ExpirationDate and ExpiringEmailRecipients (see ExpirationDate and ExpiringEmailRecipients [page

25])● ExpirationTermType (see ExpirationTermType [page 26])● ParentAgreement (see ParentAgreement [page 27])● NoticePeriod and NoticeEmailRecipients (see NoticePeriod and NoticeEmailRecipients [page 26])● Region



● Status (see Status [page 24])● Supplier (see Supplier [page 26])

Field Value Formats

Any column in the Contracts.csv file must correspond to a valid field in Ariba Contract Management for the contract workspace and the template being applied to it.

Dates

Dates specified in fields such as EffectiveDate or ExpirationDate can be in any supported format, but must match the format specified in the system.

Multiple Values for Vector Fields

If a field can contain multiple values (it is a vector field), you can specify multiple values using the following syntax where each value is enclosed by square brackets:

[value1][value2]

Domain-Value Pairs

Some field values are specified using domain-value pairs, where you must specify the domain in which the value is defined. One example is commodity codes. In most cases, you will be using commodity code values defined by the United Nations Standard Products and Services Code (UNSPSC).

When specifying a domain-value pair, use the following syntax where the domain and value are separated by a colon:

domain:value

For example:

unspsc:10

To specify multiple commodity codes, use the domain-value pair syntax with the syntax shown in Multiple Values for Vector Fields [page 21]. For example:

[unspsc:10][unspsc:20]


Users

Specify users by using their unique ID, such as dreid.

Business Contacts and Business Contact Groups

You can specify business contacts and business contact groups for some fields, such as ExpiringEmailRecipients and NoticeEmailRecipients.

To specify a business contact, use the following syntax, where the contact’s email address is preceded by a colon:

:[email protected]

To specify a business contact group, use the following syntax, where the unique ID of the business group is preceded by a colon:

:businessContactGroup

Owner

The Owner field in Contracts.csv specifies the owner of the contract workspace. The owner must be a valid user in the system and have the appropriate permissions already granted.

Document Version

The DocumentVersion field is required only if you are loading multiple versions of the same contract. This field specifies the version number of a contract. The values for this field must be natural numbers (1,2,3...). Negative numbers, zero, and any numbers with decimal points are not allowed.

If you are loading only one version of each contract, you can omit the DocumentVersion column from Contracts.csv. If you include DocumentVersion it must be the second column (after Owner) and AdjacentVersion must also be present.

AdjacentVersion

The AdjacentVersion field is required only if you are loading multiple versions of the same contract. This field specifies which contract version that particular version is adjacent to.

The version could be either a previous or subsequent version, but the contract referenced must be valid, and are loaded in a previous line of the Contracts.csv file. The format for the AdjacentVersion field must match whatever is defined in the WorkspaceLookupKey parameter in the ImportProjectsParameters.csv file. By default, this is ContractId.



If you are loading only one version of each contract, you can omit the AdjacentVersion column from Contracts.csv. If you include AdjacentVersion it must be the third column (after Owner and DocumentVersion) and DocumentVersion must also be present.

The following is an example of a Contracts.csv file used to load two versions of a contract, by first loading the past version of contract1 and then loading the current version:

Owner,DocumentVersion,AdjacentVersion,Title,ContractId,HierarchicalType

molson,1,,"contract1",WS001_1,StandAlone

molson,2,WS001_1,"contract1",WS001_2,StandAlone

Notice the third line of the Contracts.csv file refers to the ContractId in the second line. Notice also that the first line does not contain a value for AdjacentVersion, because there is no previously loaded contract (that is, no previous line in the Contracts.csv file) to refer to.

Title

The Title field specifies the title of the contract workspace.

The Title can contain up to 254 characters and cannot contain any of the following special characters:

\ / : ? “ < > |

NoteIn addition, do not end the title with a period (.). Doing so would cause a DFS synchronization error if you attempted to open a document in that workspace.

ContractId

The ContractId specifies a contract identification number. This number is different from the InternalID generated for each contract workspace by the Contract Management system, and can be any string you choose provided it is unique. The ContractId is used when a company specific naming or identification scheme is needed.

If you specified a value other than ContractId as the WorkspaceLookupKey in the ImportProjectParameters.csv file, you can leave this field blank and the system generates a contract ID for you. However, if you are using ContractId as the WorkspaceLookupKey, you must specify a value in this field.

NoteEach contract must have a unique ContractId. Different versions of the same contract can either share a ContractId, or can all be unique. Ariba recommends that you assign a unique ContractId to each version of a particular contract, as it provides more options during the legacy contract import. Additionally, if you use a particular ContractId during one legacy contract import, you cannot use it in a subsequent import.


HierarchicalType

The HierarchicalType field specifies whether the contract is a standalone agreement, master agreement or a subagreement.

HierarchicalType must be one of the following:

● MasterAgreement● SubAgreement● StandAlone

Optional Fields

Optional fields the Contracts.csv can contain include BaseLanguage, ContractStatus, ExpirationDate, ExpiringEmailRecipients, ExpirationTermType, NoticePeriod, NoticeEmailRecipients, Status, and Supplier.

BaseLanguage

If you do not include a BaseLanguage field, the system uses English. Projects do not inherit their base language from the template. The BaseLanguage field is case-sensitive. To obtain a list of valid values for the BaseLanguage field, use the Base Language (CSV) export data task.

ContractStatus and Status

The ContractStatus column specifies the state of the contract (such as Published) and the Status column specifies the status of the project. If you specify both ContractStatus and Status, the Status value must be valid for the ContractStatus value. If you specify only ContractStatus, the appropriate project Status is set for you.

Valid ContractStatus values:

● Published● Expired● OnHold● DraftAmendment● Draft● Pending● Publishing● Created● Closed



● NotCreated

The default ContractStatus is Draft.

Valid Status values:

● Active● Completed● Not Created

The default Status is Active.

Valid ContractStatus and Status pairs:

ContractStatus Status

Published Active

Expired Active

OnHold Active

DraftAmendment Active

Draft Active

Pending Active

Publishing Active

Created Active

Closed Completed

NotCreated Not Created

ExpirationDate and ExpiringEmailRecipients

The ExpirationDate field specifies the expiration date for the contract. This value is not used if the expiration term type is Perpetual.

The ExpiringEmailRecipients field is only valid if the ExpirationDate field is present. This field specifies who will receive expiration email notifications in addition to the project owners.

To specify business contacts or business contact groups for this field, use the syntax specified in Business Contacts and Business Contact Groups [page 22]. To specify multiple values for this field, use the syntax described in Multiple Values for Vector Fields [page 21].


ExpirationTermType

Specifies the expiration term type.

Valid ExpirationTermType values are:

● Fixed● AutoRenew● Perpetual

If you do not include an ExpirationTermType field, the system uses Fixed.

NoticePeriod and NoticeEmailRecipients

The NoticePeriod field specifies the number of days before the expiration date when the project enters the notice period. The system calculates the first day of the notice period, or the notice date, by subtracting this value from the expiration date. This value is not used if the expiration term type is Perpetual.

The NoticeEmailRecipients field is only valid if the NoticePeriod field is present. This field specifies who will receive notice email notifications in addition to the project owners.

To specify business contacts or business contact groups for this field, use the syntax specified in Business Contacts and Business Contact Groups [page 22]. To specify multiple values for this field, use the syntax described in Multiple Values for Vector Fields [page 21].

Supplier

The Supplier field specifies the supplier or suppliers involved in the contract.

Specify this field using domain-value pair syntax described in Domain-Value Pairs [page 21].

The domain can be any supported method of identifying suppliers. Two commonly used domains are:

● The Ariba supplier system ID (buyersystemid). For example:buyersystemid:sid509

● Dun and Bradstreet’s D-U-N-S® (duns), a nine digit ID. For example:duns:110011811

Valid domain values are dependent on your system configuration. To view supplier domain values, navigate to Ariba Administrator. Click User Manager > Organizations. Search for the organization you are interested in. Click the organization’s name to view its details. On the Organization IDs tab, you can view its corresponding ID values. For example, to indicate the supplier ServerTech in a Contracts.csv file, you can use duns:700000073, buyersystemid:sid502, or internalsystemid:1002.



Master and Subagreement Hierarchies

You can load contracts as master and subagreements with specific parent-child relationships. There is no nesting limit, but Ariba recommends that you do not create hierarchies with more than two levels. Ariba also recommends that load a parent agreement before any child agreements.

To specify hierarchical relationships, add the following fields to the Contracts.csv file:

● HierarchicalType [page 24]● ParentAgreement [page 27]

Do not specify hierarchical relationships that create a loop where a contract directly or indirectly references itself as a parent. Ariba Spend Management returns an error when a user selects View Agreement Hierarchy for a contract that references itself as a parent.

The contract’s hierarchical type is shown in the Contract Attributes area of a contract workspace.

ParentAgreement

The ParentAgreement field specifies a valid ContractId (if the WorkSpaceLookupKey parameter is ContractId) of a contract.

The contractID referenced in the ParentAgreement field, loaded in a previous line of Contracts.csv, must be valid, and must have the HierarchicalType field set to either MasterAgreement or SubAgreement. If the contract being loaded is a standalone agreement, this field is not used.

For example, the following Contracts.csv file shows four contracts being loaded:

Owner,DocumentVersion,AdjacentVersion,Title,ContractId,HierarchicalType,ParentAgreementmolson,1,,"contract1",WS001_1,MasterAgreement,,molson,2,WS001_1,"contract1",WS001_2,MasterAgreement,,rwhite,2,,"contract2",WS002_2,SubAgreement,"WS001_2"rwhite,1,WS002_2,"contract2",WS002_1,SubAgreement,"WS001_1"

The first contract (WS001_1) is version 1 of a Master Agreement. The second (WS001_2) is the second version of the first contract, and as such is also a Master Agreement. Notice that neither of the first two contracts have a value for the ParentAgreement field. The third contract (WS002_2) is the second version of Contract2, and is a subagreement of the second version of Contract1 (WS001_2). The fourth contract (WS001_2) is the first version of Contract2 and is a subagreement of the first version of Contract1 (WS001_1). Notice that the parent agreements are always loaded before any subagreements to avoid failing the load due to nonexistent references.

In general, you should load all versions for the Master Agreements with one legacy contract import, then load the subagreements later. At the least, make sure all Master Agreements are specified before their subagreements in Contracts.csv.


About the ContractDocuments.csv File

The ContractDocuments.csv file specifies any documents that are to be included with contracts loaded during the legacy contract import. Loading documents for a contract is optional, but if you do it, you must load them during the same bulk upload that you use to load the contract with.

The ContractDocuments.csv file must contain the following fields, in order, at the beginning:

● Workspace [page 28]● File [page 28]● Title [page 28]

A sample ContractDocuments.csv file might appear like this:

Workspace,File,Title,Folder,Status

"WS001_1","sampleContract.doc","MyContract.doc","Contract Documents","Published"

Workspace

The Workspace field specifies the contract workspace you are adding documents to. The type of identification for this field is specified by the WorkspaceLookupKey parameter in the ImportProjectsParameters.csv.

By default the WorkspaceLookupKey parameter is set to ContractId, so each entry in the Workspace column in ContractTeams.csv must be a valid, unique ContractId.

File

The File field in ContractDocuments.csv specifies the relative location of the document to be loaded. The location is relative to the root of the ZIP file.

Title

The Title field specified in the ContractDocuments.csv file is the Title defined for documents within a contract workspace, not the title of the workspace itself. Document titles must contain the file extensions. For example, the title for SupportingDocumentA.doc must include the .doc extension.

If you do not specify the file extension in the Title field, the documents that are loaded will not be usable. For example, if you upload a PDF file without .pdf at the end of the Title field, the resultant file in the workspace will appear as a text file, and cannot be opened or viewed.

Additionally, you can specify any other predefined fields for documents in the contract workspace. These include, but are not limited to, the following:

● Folder



Specifies where the document is to be placed in the documents area of the contract workspace. If Folder is left blank for a document, the document is placed at the root directory for the contract workspace

● StatusSpecifies the status of the document.

● OwnerSpecifies the user ID of the project owner,.

NoteThe Folder field specifies where the document is to be placed in the documents area of the contract workspace. If Folder is left blank for a document, the document is placed at the root directory for the contract workspace.

All fields must contain valid values, or the import will fail.

About the ContractTeams.csv File

The ContractTeams.csv file specifies the team members or groups assigned to particular contract workspaces during the legacy contract import.

Loading specific team members for a contract is optional, but if you do, you must load them with the same legacy contract import that you use to load the contract. If you do not want to load team members, do not include the ContractTeams.csv file in the ZIP archive, and remove the filename from the TeamsFileLocation key in the ImportProjectsParameters.csv file.

The ContractTeams.csv file must contain the following fields, in order:

● Workspace [page 29]● ProjectGroup [page 29]● Member [page 30]

Workspace

The Workspace field specifies the contract workspace you are defining the team for. The type of identification for this field is specified by the WorkspaceLookupKey parameter in the ImportProjectsParameters.csv.

By default the WorkspaceLookupKey parameter is set to ContractId, so each entry in the Workspace column in ContractTeams.csv must be a valid, unique ContractId.

ProjectGroup

The ProjectGroup field specifies which group users are assigned to. ProjectGroup, in combination with Member, defines groups for a given contract workspace.

For example, to define the following groups, the ContractTeams.csv file would appear as follows.


Workspace,ProjectGroup,Member"WS001_1","Project Owner","molson""WS001_1","Legal","bhayes""WS001_1","Legal","bwaterfield""WS001_1”,"Client","dshula""WS001_1","Tax","aagassi""WS001_1","Sourcing Management","Sourcing Management""WS001_1","Contract Management","Contract Management""WS001_1","Contract Management","dshula""WS001_1","Legacy Contract Review Team","

If the ProjectGroup specified in the ContractTeams.csv file does not exist (that is, it is not defined by the template), it will be created during the import. If a project group specified in the ContractTeams.csv file already exists in the template, the user is added to that group. You can use bulk import to define project groups with no members. If a ProjectGroup is specified in a row of ContractTeams.csv without a corresponding value for Member, the group is created normally without any users defined in it.

Member

The Member field specifies which users or groups are assigned to the corresponding ProjectGroup. The value of Member in ContractTeams.csv can be either a valid user or a valid Group.

Bulk import cannot create users. If a user specified in Member does not exist, that line of ContractTeams.csv is skipped, that user is not loaded, and an error is logged.



Loading Legacy Contracts

You import legacy contracts into contract workspaces in Ariba Administrator.

Procedure

1. Make sure that you have already created the project templates that you will use to create the imported contracts.

2. Assemble a ZIP file containing information about the contracts to load. See Legacy Contract Import ZIP File Contents [page 11].

3. In Ariba Administrator, choose Project Manager > Import Legacy Contracts.4. Click Browse and navigate to the location of the ZIP file.5. Click OK.6. Click Import.7. Check the status of the operation by choosing Project Manager > Import Legacy Contracts Status.

Example: Loading a Contract and Related Documents

The following example shows how you can upload a pre-existing contract with attached documents into Ariba Contract Management.

NoteThis example assumes you have already created a project template and that this template contains all the necessary fields. In the following example, the project template My Legacy Load Template is used.

You have a pre-existing contract with the Apex Corporation for 560,000 USD being run by Max Olson. The contract is for automotive seals, was effective on June 18, 2010 for a year, and only pertains to your operations in Europe. There are three important documents associated with this contract: Agreement.doc, Scope.txt, and Prices.xls. To load this contract into Ariba Contract Management:

1. Create an ImportProjectsParameters.csv file that includes the name of the project template to use to create the contract workspaces:WorkspaceLookupKey,TemplateName,AttributesFileLocation,DocumentsFileLocation,TeamsFileLocation,RootParentId,TopFolderName,FolderFieldName,FolderFieldPattern,FolderFormat,SendEmailNotificationAfterCreateContractId,My Legacy Load Template,Contracts.csv,ContractDocuments.csv,,,Imported,ContractId,([1-9][0-9]*),{0} to {1},false

2. Create a Contracts.csv file that specifies attribute field values for the contract workspace to be created. For example:Owner,Title,ContractId,HierarchicalType,Supplier,Amount,Commodity,Region,EffectiveDate,ExpirationDate


molson,"Apex Seals 2010 to 2011",LC5001,StandAlone,buyersystemid:sid509,560000,unspc:2140000,EMEA,06/18/2010,06/18/2011

3. Create a ContractDocuments.csv file. For example:Workspace,File,Title,Folder,StatusLC5001,"contract_docs/Prices.xls",Prices,Pricing,"Draft"LC5001,"contract_docs/Agreement.doc","Apex Agreement Document","Contract Documents","Published"LC5001,"contract_docs/Scope.txt",Scope.txt,,"Published”Notice that this ContractDocuments.csv file places the Prices.xls file in the Pricing folder and the Agreement.doc file in the Contracts Documents folder of the contract workspace. These folders do not need to exist in the template. If they do not exist, the import operation creates them.

4. Create a ZIP file that contains the CSV files and the contract documents.Make sure the documents listed in the ContractDocuments.csv file are in the directories you specified. Also make sure the project template you specified in the TemplateName field is published.

5. Log into Ariba Contract Management and load the import ZIP file in the Import Legacy Contracts workspace of Ariba Administrator to view it.



Contract Workspace Export Data

The Export Workspace Data service is used with the Ariba Data Transfer Tool provided in the Ariba Integration Toolkit (ITK). The output of the Export Workspace Data service is only for archival purposes. Ariba reserves the right to change the contents of this output without notification.

For information about configuring and using the Ariba Data Transfer Tool, see the Ariba Integration Toolkit Guide.

About the Export Workspace Data Download Directory

The download directory contains the data downloaded by the Export Workspace Data event.

When the Export Workspace Data event completes, the download directory contains the following items:

● ContractWorkspaces directory. The ContractWorkspaces directory has subdirectories that store ZIP files for up to 100 workspaces per subdirectory. The directory structure is as follows:ContractWorkspaces/yyyy/mmm/CWxxxx/CWnnXX/Where:yyyy is the year the workspace was created.mmm is the three-letter abbreviation for the month the workspace was createdCWxxxx is a literal stringCWnnxx is a folder name where nn are the first two digits of the numeric portion of the internal workspace ID for the workspace files stored in the folder and xx is a literal string.For example, workspaces CW1999 and CW2004 are created in January 2013. The file paths for the ZIP files are as follows:ContractWorkspaces/2013/Jan/CWXXXX/CW19XX/CW1999.zipContractWorkspaces/2013/Jan/CWXXXX/CW20XX/CW2004.zip

● index.csv file. This file maps workspace IDs to the location of the ZIP file for that workspace in the download directory.

● skippedworkspaces.txt. This file contains the IDs of any workspaces that match the workspace filter specified in the ITK options file that the ITK could not export. If this file is present and contains data, have your Designated Support Contact log a service request with Ariba.

About the Workspace ZIP File and wsId Workspace Folders

Within each workspace ZIP file, there is one folder per exported workspace. The folder name is the wsId, where wsId is the internal workspace ID, such as CW1234.

Each workspace folder contains the following items:

● wsId folder. This folder contains the workspace contents.

Contract Administration GuideContract Workspace Export Data © 2015 SAP SE or an SAP affiliate company. All rights reserved. 33

● Metadata about the workspace and exported data. This includes:

○ config folder. This folder contains any CSV files used for approval rules or team member rules.○ xsd folder. This folder contains XSD files that define the XML output files. See About the xsd Folder [page

34] for more information.○ wsId.csv file. This file contains a map of files for project documents. Use this file to locate project

documents in the export data. See About the wsId.csv File [page 34] for more information.

About the xsd Folder

The xsd folder contains XSD files that define the XML output schema files.

Schema files include:

● AuditHistory.xsd: Schema for audit history entries.● CommonTypes.xsd: Schema for data types used in multiple schemas.● ContractRequest.xsd: Schema for procurement contract requests.● ContractWorkspace.xsd: Schema for procurement contract workspaces.● FolderItem.xsd: Schema for documents.● InternalContractWorkspace.xsd: Schema for internal contract workspaces.● MessageBoard.xsd: Schema for message boards.● Plan.xsd: Schema for phases.● SalesContractRequest.xsd: Schema for sales contract requests.● SalesContractWorkspace.xsd: Schema for procurement contract workspaces.● Task.xsd: Schema for tasks.● Team.xsd: Schema for project team information.● WorkspaceTypes.xsd: Schema for● WSFolder.xsd: Schema for folders.

About the wsId.csv File

A wsId.csv file (where wsId is the internal workspace ID, such as CW1234.csv) maps the internal document IDs with the document titles and location of the document files relative to the folder that contains the workspace contents.

If the workspace contains assembled contract documents (Main Agreement or Contract Addendum documents), the wsId.csv file includes entries for the clauses used in the assembled contract documents.

For example:

"InternalId","Title","Location" "Doc23172","Main Agreement.doc","CW3819/WS23171/Doc23172.doc""Doc23174","Warranty Clause.doc","CW3819/WS23171/Doc23172_Folder/WS23173/Doc23174.doc" "Doc23176","Site Clause.doc","CW3819/WS23171/Doc23172_Folder/WS23175/Doc23176.doc



About the wsID Folder for Project Contents

A wsId folder (where wsId is the internal workspace ID, such as CW1234) is a workspace project folder.

The wsId folder contains the following items:

● MessageBoard folder. This folder contains:

○ messageboard.xml. This file contains metadata about the messages, including a NoteThread element for each message thread and a NoteThread.NotesBlob.ExportedFilename element that contains the name of the exported file (nb_Id.htm) that contains the message contents.

○ nb_Id.htm files, where Id is the internal message ID. Each nb_Id.htm file is the contents of one message.

● Plan folder. This folder contains information about phases (plans) and tasks. For more information, see About the Plan Folder and Phase Folders [page 37].

● docId_Folder folders, where docId is an internal document ID, such as Doc1234. A docId_Folder folder contains the contents of a document folder in a project—any documents in the folder and any subfolders—and an ws.xml file. The ws.xml file contains metadata about the folder, including the owner, creation date, and access controls. The ws.xml file also includes a PermissionBitVec element, which specifies the access controls for the document. For more information about the PermissionBitVec element, see About the PermissionBitVec Element [page 42].

● announcements.xml. This file is a placeholder for project announcements. Each announcement is also a message board note; open the MessageBoard folder to view announcements.

● audithistory.xml. This file contains audit history entries (information displayed under the History tab in a project).

● docId.extension, where docId is an internal document ID and extension is the file extension. The contents of docId. Examples: Doc1234.txt, Doc4567.xls.

● FI_docId_extension.xml, where docId is an internal document ID and extension is the file extension. For example: FI_Doc1234_txt.xml. Header data about docId, including the Title. FI_docId_extension.xml also includes a PermissionBitVec element, which specifies the access controls for the document. For more information about the PermissionBitVec element, see About the PermissionBitVec Element [page 42].

● team.xml. The team.xmlfile contains information about project groups, including members and roles.● ws.xml. The ws.xml file contains information about the project, including contract header fields, the

template used to create the project, answers to any template questions, and any notification profiles used in tasks. This file also includes a PermissionBitVec element, which specifies the access controls for the project. For more information about the PermissionBitVec element, see About the PermissionBitVec Element [page 42].


About Files for Form Documents

For each form document in a project, the export data contains two files: docId_txt.xml, which contains metadata about the form and field names and field values for header and line items; and docId.txt which is an empty file used as a placeholder.

About docId_txt.xml Header Fields

Header fields are presented in FolderItem.Item.DForm.DForm.cus_headerFieldName elements, where headerFieldName is the header field name with spaces and special characters removed.

For example, the header field Client Name with the value Bob Posey would be presented in the following element:

<cus_ClientName>Bob Posey</cus_ClientName>

About docId_txt.xml Line Item Fields

Each line item field is presented in a FolderItem.Item.DForm.ariba_FormDetails.DFormDetails element, where FolderIterm.Item.DForm.ariba_FormDetails.DFormDetails.LineNumber indicates the line number. Each field in a line item is presented in a FolderItem.Item.DForm.ariba_FormDetails.DFormDetails.DFormFieldElement, which contains the field name and value.

The following listing is an excerpt from a docId_txt.xml file with a line item 1. This line item has that has the field name Pet Name with the value Spot and the field name Breed with the value Poodle. Ellipses (...) indicate text that was removed for readability.

<FolderItem> <Item> ... <DForm> <ariba_FormDetails> <DFormDetails ...> <LineNumber>1</LineNumber> <DFormFieldElement fieldname="cus_PetName">Spot</DFormFieldElement> <DFormFieldElement fieldname="cus_Breed">Poodle</DFormFieldElement> </DFormDetails> ...



About File for Contract Terms Documents

If Ariba Contract Management is integrated with Ariba procurement or invoice solutions, a procurement contract workspace can contain the files used for contract compliance.

Files used for contract compliance include:

● A contract terms link document, which links the contract workspace with a compliance contract request or compliance contract. The link document is not a file and the corresponding docId.txt file is empty. The corresponding FI_docId_txt.xml file contains metadata about the link. The significant fields include:

○ FolderItem.Item.ContractTerms.ManagedObject.ManagedCXML.ExternalId: The ID of the associated compliance contract or compliance contract request.

○ FolderItem.Item.ContractTerms.ManagedObject.ManagedCXML.Status: The status of the of the contract terms, such as Composing or Published.

● A contract terms Excel document, also referred to as pricing terms document. The corresponding docId.xls file contains the Excel representation of the pricing terms. This Excel file includes the tabs Contract Header, Contract Item Information (line items), Accounting, and Header Attributes.

About the Plan Folder and Phase Folders

The Plan folder in the workspace folder contains information about the project plan. The project plan is a container for tasks that are not contained in a phase.

The Plan folder contains the following items:

● plan.xml. This file contains metadata about the project plan. Data such as the creation and due dates are for tasks that are not contained in a phase and are not to be interpreted as relevant to the entire project.

● tasks.xml. This file contains information about any tasks that are not contained in a phase. For more information, see tasks.xml File [page 37].

● phase folders, where phase is based on a phase name (title). Each phase folder contains a plan.xml and tasks.xml file for a phase in the parent folder (in the Plan folder, there is a phase folder for each phase at the top level of a project). The plan.xml file contains data about the phase, such as the title, begin date and due date. The tasks.xml file contains information about the tasks in the phase.

tasks.xml File

A tasks.xml file contains a Tasks element, which has two child elements: Task and DocumentTask.

● Task elements. Each Task element contains information about a To Do task that is not associated with a document.

● DocumentTask elements. Each DocumentTask element contains information about a document task (review, approval, negotiation, or signature task), notification task, or a To Do task that is associated with a document. If a document task has multiple rounds, there is a DocumentTask element for each round.


About Task Elements

A Tasks.Task element describes a To Do task that has no associated document. A Tasks.Task element contains child elements with general information about the task, such as Title and Owner elements.

The significant child elements of a Tasks.Task element are:

● AltStatus: Status as shown in the user interface. This is determined by the internal status (Status element) and the task type. Valid values: Approved, Reviewed, Signed, Notified, In Approval, In Review, Signing, Notifying, Denied, Withdrawn, Cancelled.

● Owner: The task owner.● Required: Indicates if the task is required.● Status: Internal status of the task. Valid values: InActive, Active, Completed, Scheduled.● Type: Specifies the task type (ToDo).● Title: The task title.

DocumentTask Elements

A Tasks.DocumentTask element describes document tasks (review, approval, negotiation, signature tasks) and notification tasks. A Tasks.DocumentTask element contains child elements with general information about a document task, such as Title and Owner elements.

The significant child elements of a Tasks.DocumentTask element are:

● AltStatus: Status as shown in the user interface. This is determined by the internal status (Status element) and the task type. Valid values: Approved, Reviewed, Signed, Notified, In Approval, In Review, Signing, Notifying, Denied, Withdrawn, Cancelled.

● ApprovalRuleFlowType: Type of approval flow (Serial, Parallel, or Custom).● Approvers: All approvers for the task.● Comments: Contains all comments for the task. The Comments.WSComment.Text element contains the text

of the comment. If a comment has multiple threads, there is a Comments.WSComment.Comments.WSComment element for each comment in the thread.

● DocumentId: ID of the document associated with this task.● ObsoletedCopy._LocalId: Used when there are multiple task rounds. For more information, see Document

Tasks with Multiple Rounds [page 39].● Owner: The task owner.● Required: Indicates if the task is required.● Status: Internal status of the task. Valid values: InActive, Active, Completed, Scheduled.● TaskApprovable: Information about the approval flow. For more information, see Determining an Approval

Flow (Approvable Elements) [page 39].● Type: Specifies the task type. For more information, see Determining the Task Type [page 39].● Title: The task title.



Determining the Task Type

The Tasks.DocumentTask.Type element indicates the task type (Approval, Review, Notify, Signature, or Todo). A negotiation task has a Tasks.DocumentTask.Type element with a Review value and a Tasks.DocumentTask.Operation element with a Negotiate value.

Document Tasks with Multiple Rounds

If a document task has multiple rounds, there is a DocumentTask element for each round. In addition, all rounds with a previous round will have a DocumentTask.ObsoletedCopy._LocalId element that contains the DocumentTask._LocalId of the previous round.

Determining an Approval Flow (Approvable Elements)

Each Tasks.DocumentTask.TaskApprovable.Approvable element represents an approval flow. You can use Approvable child elements to determine the order of the nodes in the approval flow and the state of each node in the flow.

The significant child elements of a Tasks.DocumentTask.TaskApprovable.Approvable are:

● ApprovalRequests: A set of ApprovalRequest elements, where each ApprovalRequest represents one node in the approval flow.Use the ApprovalRequest.Status element to determine if a user is the current approver (ActiveButNoActionYet), or is not yet active (NotYetActive; there are predecessor nodes that have not completed the approval), or has approved the document (Approved), or denied the document (Denied).Each ApprovalRequest element also has a ApprovalRequestUID, which is used to identify the node in the graph.

● ApprovalGraph: A set of Edge elements, where each Edge element defines a connector (edge) between nodes in the approval graph.

Each Edge element has the following structure:

<Edge> <FromApprovalRequestUID>uid</FromApprovalRequestID> <ToApprovalRequestUID>uid</ToApprovalRequestID> </Edge>

Where each uid refers to a node using an ApprovalRequestUID value. For example, the following edge represents an edge from the node (ApprovalRequest) with ApprovalRequestUID 2 to the node with ApprovalRequestUID 3:

<Edge> <FromApprovalRequestUID>2</FromApprovalRequestID> <ToApprovalRequestUID>3</ToApprovalRequestID> </Edge>


Edges can be evaluated as follows:

● The initial node or nodes in an approval flow are the nodes that are not listed in a ToApprovalRequestUID in any edge.

● The last node or nodes in an approval flow are the node that are not listed in a FromApprovalRequestUID in any edge.

● If a node is not listed as a ToApprovalRequestUID in any edge and is not listed as a FromApprovalRequestUID in any edge, it is both the first and last node in the approval flow. This occurs if:

○ A node is parallel to the entire flow.○ There is only one node in the approval flow. The ApprovalGraph element will be empty (it will not contain

any Edge elements).○ The approval flow contains only parallel nodes. The ApprovalGraph element will be empty.

For example, a task has the following approval flow:

The ApprovalRequestUID values are as follows:

● ApprovalRequestUID 1: Chad Noll (cnoll)● ApprovalRequestUID 2: Archie Rooney (arooney)● ApprovalRequestUID 3: Andre Munoz (amunoz)

The ApprovalGraph element contains the following Edge element:

<ApprovalGraph> <Edge> <FromApprovalRequestUID>2</FromApprovalRequestUID> <ToApprovalRequestUID>3</ToApprovalRequestUID> </Edge> </ApprovalGraph>

The Edge element represents the edge from Archie Rooney to Andre Munoz. Note that:

● There is no edge that contains the ApprovalRequestUID for Chad Noll (1). The node for Chad Noll is parallel to the entire approval graph; there are no nodes before Chad Noll and no nodes after Chad Noll.

● The ApprovalRequestUID for Archie Rooney (2) is not specified as the ToApprovalRequestUID in any edge. Archie Rooney is one of the initial nodes in the approval flow.

● The ApprovalRequestUID for Andre Munoz (3) is not specified as the FromApprovalRequestUID in any edge. Andre Munoz is one of the last nodes in the approval flow.

The following listing is an excerpt from a tasks.xml file with information for this approval flow. Ellipses (...) indicate text that was removed for readability.

<Tasks xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Task.xsd"> <DocumentTask> ... <TaskApprovable><Approvable> ...



<ApprovalRequests vector="true"> <ApprovalRequest> <Approver> ... <UniqueName>cnoll</UniqueName> </Approver> <State>ActiveButNoActionYet</State> ... <ApprovalRequestUID>1</ApprovalRequestUID> </ApprovalRequest> <ApprovalRequest> <Approver> ... <UniqueName>arooney</UniqueName> </Approver> <State>ActiveButNoActionYet</State> ... <ApprovalRequestUID>2</ApprovalRequestUID> </ApprovalRequest> <ApprovalRequest> <Approver> ... <UniqueName>amunoz</UniqueName> </Approver> <State>NotYetActive</State> ... <ApprovalRequestUID>3</ApprovalRequestUID> </ApprovalRequest> </ApprovalRequests> <ApprovalGraph> <Edge> <FromApprovalRequestUID>2</FromApprovalRequestUID> <ToApprovalRequestUID>3</ToApprovalRequestUID> </Edge> </ApprovalGraph> </Approvable></TaskApprovable></DocumentTask></Tasks>

Additional DocumentTask Elements

Most of the DocumentTask elements are self-explanatory and indicate the value of fields displayed in the user interface. For example, the ReviewerCanEdit element indicates if the Reviewer Can Edit option is enabled for the task.

Additional DocumentTask elements include:

● _LocalId: Internal ID of the task round. If this value is present in the ObsoletedCopy._LocalId of another DocumentTask element, then this is a predecessor of another task round and is not the current round. For more information, see Document Tasks with Multiple Rounds [page 39].

● Alert: Configured alert value.● AllowNoApproversFromRules: If false, do not allow the task to be submitted if there are no approvers in

the approval flow.● Approvers: A set of all the approvers for the task round. Use the

Tasks.DocumentTask.TaskApprovable.Approvable.ApprovalRequests to view information about approvers.

● DocumentMinorVersion: If non-zero, a user has made changes to the current document version (the user chose to change the document and continue working using the existing version number).

● DocumentVersion: The document version, as shown in the user interface.


● DueDateOffset: The due date for the task, relative to the current date.● NotificationSchedules: Present for notification tasks only. Contains a NotificationSchedule child

element for the current notification round and additional NotificationSchedule child elements for any previous rounds that were not completed.

● ProcessId: For internal use only.● ShouldHideDocument: True for notification tasks only. Notification tasks do not have associated documents.

About the PermissionBitVec Element

The PermissionBitVec element is the integer value of the 64-bit permission bit vector that indicates the access control options for a document or workspace.

To determine which access controls are enabled, convert the PermissionBitVec value as an unsigned 64-bit integer to a binary value and use the following table to determine the access controls that correspond to the bits that are set. For example, the PermissionBitVec value 6 (bits 1 and 2 are set) indicates that the Private to Team Members and Draft Access Restricted controls are enabled.

Table 5:

Bit Number

Decimal Value Access Control Name Description

0 1 Owner Only Visible only to the owner or editors of this object.

1 2 Private To Team Members Visible only to members of a project team in the project containing the document.

2 4 Draft Access Restricted While in Draft, this document is visible only to users who can access draft documents. After it is published, this document becomes visible to all users.

3 8 Private To Internal Users Visible only to users who are internal to the company.

4 16 Private to Sourcing Pro Users Visible only to users who have access to Ariba Sourcing Professional.

5 32 Private to Contract Management Basic Users

Visible only to users who have access to Ariba Contract Management.

6 64 Private to Sourcing Users Visible only to users who have access to Sourcing.

9 512 Classified Visible only to users who are members of the Classified Access group.

40 1099511627776 To view Supplier/Customer reports

Visible to Ariba Supplier Management Basic, Ariba Sourcing Basic, and Ariba Contract Management users.

41 2199023255552 Private to Supplier Green Information

Visible only to users who have access to Spend Visibility Supplier Green Information.



Bit Number

Decimal Value Access Control Name Description

42 4398046511104 Private to Supplier Risk Information

Visible only to users who have access to Spend Visibility Supplier Risk Information.

43 8796093022208 Private to Internal Contract Users Visible only to users who have access to Internal Contracts.

44 17592186044416 To view system benchmark report Visible only to customer support admin

45 35184372088832 To view system usage report Visible only to customer support admin

46 70368744177664 View Budget Analysis Visible only to users who are members of the Budget Report User group.

47 140737488355328 Private to Supplier Management Users

Visible only to users who have access to Ariba Supplier Management.

48 281474976710656 Private to Spend Visibility Visible only to users who have access to Spend Visibility.

49 562949953421312 Private to Contract Management Pro Users

Visible only to users who have access to Ariba Contract Management Professional.

50 1125899906842620 Private to SSP Users Visible only to users who have access to Procurement.

51 2251799813685250 Private to P2P Reports Users Visible only to users who have access to Ariba Procure To Pay.

52 4503599627370500 Private to Invoice Reports Users Visible only to users who have access to Invoice Reports.

53 9007199254740990 Private to T&E Reports Users Visible only to users who have access to Ariba Travel and Expense.

54 18014398509482000 Private to Supplier Management Pro Users

Visible only to users who have access to Ariba Supplier Management Professional.

55 36028797018964000 Private to Spend Visibility Opportunity Analysts

Visible only to users who are Spend Visibility Opportunity Analysts.

56 72057594037927900 Private to Sales Contract Users Visible only to users who have access to Sales Contracts.

57 144115188075856000 Legal Information Visible only to users who are members of the Legal group.

58 288230376151712000 Finance Information Visible only to users who are members of the Finance group.

59 576460752303423000

Private to Content Only Reports Users

Visible only to users who have access to Procurement Content

60 1152921504606850000

Private to Global Catalog Reports Users

Visible only to users who have access to Catalog Reports

61 2305843009213690000

Private to Procurement Contract Users

Visible only to users who have access to Procurement Contracts

62 4611686018427390000

Private to Spend Visibility Supplier Diversity Analyst

Visible only to users who have access to Spend Visibility Supplier Diversity Information.


Revision History

The following table provides a brief history of the updates to this guide. Ariba updates the technical documentation for its On Demand 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.

To provide feedback on this guide or any Help@Ariba resources, click the Submit Feedback link on any Help@Ariba page.

Table 6:

Document Version

Month/Year of Update

Updated Chapter/Section

Short Description of Change

1 December 2014 n/a Updated format.

Importing Legacy Contracts

Added ContractStatus information.


Revision History

Important Disclaimers and Legal Information

Coding SamplesAny software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP intentionally or by SAP's gross negligence.

AccessibilityThe information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however, does not apply in cases of wilful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations of SAP.

Gender-Neutral LanguageAs far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as "sales person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun does not exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.

Internet HyperlinksThe SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does not warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any damages caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for transparency (see: http://help.sap.com/disclaimer).

Contract Administration GuideImportant Disclaimers and Legal Information © 2015 SAP SE or an SAP affiliate company. All rights reserved. 45

http://help.sap.com/disclaimer/

www.ariba.com

Copyright © 1996–2015 Ariba, Inc. All rights reserved.This documentation, as well as the Ariba solutions, 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 and Ariba products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Ariba, Inc. in the United States and other countries. Please see http://www.ariba.com/legal/trademarks for additional trademark information and notices.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; 7,693,747; 8,364,577; and 8,392,317. 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; 7,536,362; 8,364,577; and 8,392,317. 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.

http://www.ariba.com

http://www.ariba.com/legal/trademarks

http://www.ariba.com/copyrights.cfm

Contract Administration Guide - SAP Ariba EchoSign and set up an account for your organization....

Documents

Transcript of Contract Administration Guide - SAP Ariba EchoSign and set up an account for your organization....