Ariba® Payment™

Implementation Guide

Release: 9r2
Document Version: 1
Release Date: June 2014
Copyright © 1996–2014 Ariba, Inc. All rights reserved.

This documentation, as well as the Ariba software and/or services described in it, contain proprietary information. They are provided under a license or other
agreement containing restrictions on use and disclosure and are also protected by copyright, patent and/or other intellectual property laws. Except as permitted
by such agreement, no part of the document may be reproduced or transmitted in any form by any means, electronic, mechanical or otherwise, without the
prior written permission of Ariba, Inc.

Ariba, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in the documentation. The information contained in the
documentation is subject to change without notice.

Ariba, the Ariba logo, AribaLIVE, SupplyWatch, Ariba.com, Ariba.com Network and Ariba Spend Management. Find it. Get it. Keep it. and PO-Flip are
registered trademarks of Ariba, Inc. Ariba Procure-to-Pay, Ariba Buyer, Ariba eForms, Ariba PunchOut, Ariba Services Procurement, Ariba Travel and
Expense, Ariba Procure-to-Order, Ariba Procurement Content, Ariba Sourcing, Ariba Savings and Pipeline Tracking, Ariba Category Management, Ariba
Category Playbooks, Ariba StartSourcing, Ariba Spend Visibility, Ariba Analysis, Ariba Data Enrichment, Ariba Contract Management, Ariba Contract
Compliance, Ariba Electronic Signatures, Ariba StartContracts, Ariba Invoice Management, Ariba Payment Management, Ariba Working Capital
Management, Ariba Settlement, Ariba Supplier Information and Performance Management, Ariba Supplier Information Management, Ariba Discovery, Ariba
Invoice Automation, Ariba PO Automation, Ariba Express Content, Ariba Ready, and Ariba LIVE are trademarks or service marks of Ariba, Inc. All other
brand or product names may be trademarks or registered trademarks of their respective companies or organizations in the United States and/or other countries.

Ariba Sourcing solutions (On Demand and software) are protected by one or more of the following patents, including without limitation: U.S. Patent Nos.
6,199,050; 6,216,114; 6,223,167; 6,230,146; 6,230,147; 6,285,989; 6,408,283; 6,499,018; 6,564,192; 6,871,191; 6,952,682; 7,010,511; 7,072,061; 7,130,815;
7,146,331; 7,152,043;7,225,152; 7,277,878; 7,249,085; 7,283,979; 7,283,980; 7,296,001; 7,346,574; 7,383,206; 7,395,238; 7,401,035; 7,407,035; 7,444,299;
7,483,852; 7,499,876; 7,536,362; 7,558,746; 7,558,752; 7,571,137; 7,599,878; 7,634,439; 7,657,461; and 7,693,747. Patents pending.

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

U.S. Patent Nos. 6,199,050, 6,216,114, 6,223,167, 6,230,146, 6,230,147, 6,285,989, 6,408,283, 6,499,018, 6,564,192, 6,584,451, 6,606,603, 6,714,939,
6,871,191, 6,952,682, 7,010,511, 7,047,318, 7,072,061, 7,084,998; 7,117,165; 7,225,145; 7,324,936; and 7,536,362. Patents pending.

Certain Ariba products may include third party software or other intellectual property licensed from a third party. For information regarding software or other
intellectual property licensed from a third party, go to http://www.ariba.com/copyrights.cfm.
Revision History

The following table provides a brief history of the updates to this guide. Ariba updates the technical
documentation for its On-Premise solutions if
• software changes delivered in service packs or hot fixes require a documentation update to correctly
reflect the new or changed functionality;
• the existing content is incorrect or user feedback indicated that important content is missing.

Ariba reserves the right to update its technical documentation without prior notification. Most
documentation updates will be made available in the same week as the software service packs are released,
but critical documentation updates may be released at any time.

Version Month/Year of Updated Chapter/Section Short Description of Change

Update
1 June 2014 n/a GA version

Ariba Payment Implementation Guide iii

 Revision History

iv Ariba Payment Implementation Guide

Table of Contents

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

Chapter 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
About Ariba Payment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Payment Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Completed Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Payment Requests for Credit Memos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Approvable Documents for Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
How to Use This Document. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Payment Models and Payment Send. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Payment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Bank Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Payment Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Local and AN Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Remittance Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Groups, Roles, and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Reference Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 2 Enabling Ariba Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Installing Ariba Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Site Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Approval Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Payment Functionality on AN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Preparing Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Loading Your Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Migrating Existing Payment Requests to Ariba Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Chapter 3 Payment Models and Payment Send . . . . . . . . . . . . . . . . . . . . 17

Approvable Documents for Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
About Payment Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
AribaPay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
ExternalPay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Payment Models, Suppliers, and Supplier Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Payment Models in Ariba Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Payment Model Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Send Method Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
AribaPay Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
ExternalPay Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Validation Customization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Payment Status Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Payment Request Export Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Ariba Payment Implementation Guide v

Table of Contents

Chapter 4 Payment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

About Payment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Integration Events for Payment Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
PaymentMethodTypePull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
PaymentMethodTypeLanguagePull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
PaymentMethodTypeExport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Payment Methods in Ariba Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Chapter 5 Bank Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

About Bank Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Integration Events For Bank Account Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
BankAccountTypePull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
BankIDTypePull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
BankAccountIDTypePull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Integration Events for Choosing Bank Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
SupplierPaymentBankLocationPull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
BuyerPaymentBankLocationPull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Supplier Sync From AN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Integration Events for Remittance Locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
RemittanceLocationPull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
SupplierLocationRemittanceInformationPull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Bank Information in Ariba Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Chapter 6 Payment Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

About Payment Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Payment Terms, Suppliers, and Supplier Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Payment Terms and Other Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Payment Terms in the Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Integration Events for Payment Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
PaymentTermsPull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
PaymentTermsLanguagePull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Payment Terms in Ariba Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
How Payment Terms Are Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Triggers for Defaulting Payment Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Payment Terms Defaulters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
ERP Integration Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chapter 7 Local and AN Payments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

About Local and AN Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Payment Schedules and Discounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Payment Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Payment Discount Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Line Types for Discounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Payment Aggregation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Default Payment Aggregator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Configuring the Payment Aggregator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Customizing the Payment Aggregator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Payment Disbursement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuration File Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vi Ariba Payment Implementation Guide

 Table of Contents

Scheduled Tasks for Processing Local Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

ProcessingPaymentRequests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
ProcessPaidPaymentTransactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Chapter 8 Remittance Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

About Remittance Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Remittance Pull. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Remittance Post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Pulling Remittance Advice from an ERP System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
IncrementalRemittanceImport Scheduled Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Pulling Remittance Advice from AN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Pulling Remittance Advice in a CSV Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
RemittanceCSVImportLoader ScheduledTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
RemittancePull Integration Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
IntegrationPostLoadPaymentTransaction Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Currency Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapter 9 Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Ariba Administrator Workspaces and Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Log Message Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Common Administration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Adding or Modifying Payment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Adding or Modifying Payment Methods for Supplier Locations . . . . . . . . . . . . . . . . . . . 63
Modifying Payment Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Adding or Modifying Remittance Locations for Supplier Locations . . . . . . . . . . . . . . . . 64
Adding or Modifying Payment Models for Suppliers . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Adding or Modifying Payment Models for Supplier Locations . . . . . . . . . . . . . . . . . . . . 65
Adding or Modifying Bank Payment Locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Appendix A Groups, Roles, and Permissions . . . . . . . . . . . . . . . . . . . . . . 69

Required Permissions for Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
EditPayment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
ForceCancelPaymentTransaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
ForcePayPaymentTransaction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
ForceSendPayment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
P2PAdminAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
PayablePushErrorEmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
PaymentAdministrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
PaymentManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
PaymentSendingEmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
QueryAllPayment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
RemoveApprovalRequestPayment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Default Roles for Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Payment Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Payment Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Payment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Default Groups for Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Payment Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Payment Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Payment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Ariba Payment Implementation Guide vii

Table of Contents

Appendix B Email Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . 73

About Email Notification Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Notification of Payment Send Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Notification of Remittance Load Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Appendix C Scheduled Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

About Scheduled Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Partitioned Scheduled Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
CXMLPaymentProposalLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
CXMLPaymentRemittanceLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
CXMLProcessUndeliveredPayloads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
DisbursementCreator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
IncrementalRemittanceImport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
PaymentAggregator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
PostProcessSettlementEnablement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
ProcessPaidPaymentTransactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
ProcessPendingPaymentRequests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
ProcessSkippedPaymentRequests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
RemittanceCSVImportLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
ResendFailedPaymentRequests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
ResendFailedPaymentTransactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

viii Ariba Payment Implementation Guide

Chapter 1 Introduction

• “About Ariba Payment” on page 9

• “How to Use This Document” on page 11
• “Reference Information” on page 12

About Ariba Payment

Settlement is the final stage of the payment process. Settlement consists of scheduling payments, applying
discounts, sending the payment to the designated supplier, and ensuring payment has been received. Ariba
Payment is a module of Ariba Buyer that automates the settlement process. Ariba Payment helps you
process payments more efficiently, capture supplier discounts more effectively, and reduce the overhead
involved in paper processing.

This section introduces the business processes of payment and describes how Ariba Payment automates
those processes. It does not describe basic user interaction. For information working with Ariba Payment
from a user’s perspective, see the Ariba Invoice and Payment User Guide.

Payment Process
In a paper-based process, settlement consists of writing checks, sending those checks to suppliers, and then
waiting for the supplier to return confirmation that the payment was received. Ariba Payment automates the
manual process, helping to reduce paper handling and data entry, maximize supplier discounts, reduce
errors, and forecast expected payments more accurately.

Payment and settlement professionals who are responsible for the business processes of settlement, such as
payment scheduling and managing supplier relationships, use Ariba Payment. In the user interface, the
features for accessing settlement functionality are accessible only to authorized business process experts.
Other users have no visibility into electronic payment documents.

Payment managers have visibility into pending payments, and are able to see upcoming payments, review
scheduling, and sort or classify upcoming payments. These users have immediate access to payment
scheduling information, allowing more accurate payment forecasting and scheduling. Administrators
reviewing invoice reconciliations can navigate quickly to see the payment requests associated with any
invoice reconciliation.

Completed Payments
After a payment has been made, the details of the completed payment transaction are visible in the user
interface. Payment managers can access payment transactions to review details of payments, or to void
(cancel) a payment that has been made. Your company can also share payment details with suppliers
electronically, helping to reduce vendor inquiries and streamline relationships with your suppliers.

Ariba Payment Implementation Guide 9

About Ariba Payment Chapter 1 Introduction

Payment Requests for Credit Memos

Most payment requests represent amounts due to a supplier, such as for an unpaid invoice. Ariba Payment
also provides support for payment requests associated with credit memos. A credit memo is an invoice that
represents a refund owed to your company by the supplier. For example, if your company purchased
equipment that was later returned, the supplier might issue first an invoice and then (after the return) a credit
memo, representing the amount due to be refunded to you.

Ariba Payment creates credit payment requests to represent credit memos. These credit payment requests are
visible to your payment managers from the user interface, and used when scheduling payments and
determining appropriate payment amounts.

Approvable Documents for Payment

Ariba Payment represents payments with the following approvable document types:
• Payment requests, which represent upcoming payments
• Payment transactions, which represent payments that have been made

Each payment request document represents an expected payment. In the default configuration, no approvals
are required for payment requests. When a payment request is created, it enters the workflow, where the next
step depends on the payment model that is in effect. For example, if payment is to be made on an ERP
system, the payment request is sent immediately to that ERP system. However, if payment is to be made in
Ariba Payment, users can edit the payment request until it reaches its scheduled payment date.

When a payment is created, the organization creating the payment creates and returns remittance advice,
with details of the payments that have been made. For example, a remittance advice statement might list all
invoices included in a payment, including the payment method used, bank information, discount amount,
and amount paid.

When a payment is made in Ariba Payment, Ariba Payment creates payment transaction documents and
posts remittance advice to AN.

When a payment is made on an external system, such as an ERP system, Ariba Payment pulls remittance
advice from the external system, uses the remittance advice to create payment transaction documents, and
then posts the remittance advice to AN.

For example, suppose that payment request PAY12 is sent to an ERP system. The ERP system creates a
payment that includes PAY12, and then posts remittance advice, that lists PAY12, to Ariba Payment. Ariba
Payment then creates a payment transaction document reflecting the payment that has been made.

10 Ariba Payment Implementation Guide

Chapter 1 Introduction How to Use This Document

How to Use This Document

This document describes how to set up the integration events, configuration settings, and optional features
used in Ariba Payment. It assumes you are already familiar with the overall process of configuring Ariba
Payment, as described in the Ariba Buyer Configuration Guide.

Configuring Ariba Payment involves the following major components:

• Payment models and payment send
• Payment methods
• Bank information
• Payment terms
• Direct and AN payments
• Remittance advice
• Groups, roles, and permissions

This section describes where to find information on each of these major components.

Payment Models and Payment Send

To set up your configuration, you must specify:
• A preferred payment model for each partition, which specifies whether that partition handles payments
within Ariba Payment or sends them to an external system.
• Configuration settings for sending payment requests or payment confirmations, depending on the
payment model you have chosen.

For information, see Chapter 3, “Payment Models and Payment Send.”

Payment Methods
To set up your configuration for electronic payment, you define the set of payment methods you support,
using the PaymentMethodTypePull integration event. The payment method types you define with this
integration event are the payment method types available to users in the chooser in the user interface.

For information, see Chapter 4, “Payment Methods.”

Bank Information
Bank account information defines basic parameters for identifying a bank account to be used for electronic
funds transfer. You define bank information by running integration events.

For more information, see Chapter 5, “Bank Information.”

Ariba Payment Implementation Guide 11

Reference Information Chapter 1 Introduction

Payment Terms
Payment terms specify the time period in which a supplier requests payment and any discounts that supplier
chooses to make available for early payment. You define a set of supported payment terms with an
integration event, and then use the supplier pull integration events to associate one of those existing payment
term definitions with each supplier (or supplier location).

For more information, see “Payment Terms” on page 37.

Local and AN Payments

If you are using the Local payment model or the AN payment model, you must configure functionality for
payment scheduling, payment discount selection, and payment aggregation.

For more information, see “Local and AN Payments” on page 43.

Remittance Advice
Remittance advice is an electronic document that provides details about a payment that has been made, such
as the payment method used, the invoices covered, and the amount of the payment. You can configure your
system to pull remittance advice from AN or from an ERP system, or load remittance advice from CSV files.

For more information, see “Remittance Advice” on page 51.

Groups, Roles, and Permissions

The default configuration provides a sample configuration file that defines a typical set of roles for
payments. This sample configuration defines roles for payment administrators and managers, where an
administrator is a user responsible for system administration issues and a manager is a user responsible for
business process issues.

You do not have to use the sample groups and roles, but you must make sure that at least one user has each of
the required administrative permissions.

For more information, see Appendix A, “Groups, Roles, and Permissions.”

Reference Information
When setting up Ariba Payment, you will need to refer to the following documents:
• The Data Dictionary, which is a Microsoft Excel workbook that contains descriptions of integration
events and comma-separated value (CSV) file columns.
• The Parametersdoc, which is an HTML document that contains descriptions of the
config/Parameters.table parameters.

• The Javadoc (API documentation)

These documents are available on the administration documentation page on Help@Ariba. You can also
download the Data Dictionary from Ariba Administrator.

12 Ariba Payment Implementation Guide

Chapter 2 Enabling Ariba Payment

• “Installing Ariba Payment” on page 13

• “Preparing Data Sources” on page 14
• “Loading Your Data” on page 15
• “Migrating Existing Payment Requests to Ariba Payment” on page 16

Installing Ariba Payment

You install Ariba Payment from the Ariba Buyer installation program, by selecting the Ariba Payment
module. You can install Ariba Payment as part of your initial installation or you can purchase it as an
additional feature to be added to an existing configuration.

The installation process copies all required files and sets appropriate default values for parameters and
configuration settings. However, to fully enable Ariba Payment in your configuration, you must supply data
files with your own data and run all required integration events and scheduled tasks.

Site Profile
After installing Ariba Payment, make sure Ariba Settlement is selected in the site profile.

 To modify the site profile:

1 In Ariba Administrator, choose Server Manager > Site Profile.

2 In the FEATURES section, select Ariba Settlement.

3 Click OK to save your changes, or click Cancel to return to the previous page without saving your changes.

Approval Rules
The default approval rules for Ariba Payment are loaded during installation:
• JavaScript Payment Rule (JavaScriptPayment.rul)
• JavaScript Payment Transaction Rules (JavaScriptPaymentTransaction.rul)

These rule sets do not require any approvals. For information on customizing approval rules, see the Ariba
Spend Management Approval Rules Guide.

Ariba Payment Implementation Guide 13

Preparing Data Sources Chapter 2 Enabling Ariba Payment

Payment Functionality on AN
If you plan to use the AN payment model to create payments on AN, you must make sure that the
functionality is correctly enabled on AN. For you and your suppliers to exchange payments through AN, the
following must be specified on AN:
• Your company’s profile must have payment and settlement functionality enabled.
• Suppliers who want to participate in electronic payment must be enabled for payment on AN, and must
configure their payment preferences on AN, including preferred payment methods, bank account
information, and contact information.

For more information on how to configure AN to support payment and settlement functionality, see the
Ariba Network Account Management Guide.

Preparing Data Sources

To fully enable Ariba Payment, you run integration events that load data. Before you run those events, you
must be sure that the data in the data sources is correct.

If you are installing Ariba Payment as a new installation, you can do either of the following:
• Enable Ariba Payment with the sample data, to see the default configuration, and then later update to your
own data.
• Update all CSV files to define your own data, and then load your custom data.

If you are installing Ariba Payment as a new installation, the default groups, roles, and permissions for Ariba
Payment are loaded during installation. If you are migrating from a previous version, new groups, roles and
permissions are not loaded because of potential naming conflicts. For more information, see the Ariba Buyer
Migration Guide.

14 Ariba Payment Implementation Guide

Chapter 2 Enabling Ariba Payment Loading Your Data

Loading Your Data

This section describes how to fully enable Ariba Payment. It assumes that you have updated your CSV files,
as described in the previous section.

 To fully enable Ariba Payment:

1 Update your mapping files and run the appropriate integration events to assign Ariba Payment groups,
roles, and permissions to users. You might need to run some or all of these integration events, depending
on how you map permissions to users.

Integration Event Name Display Name

GroupRoleMapPull Import Group/Role Relationships

GroupPermissionMapPull Import Group Permission Map

RolePermissionMapPull Import Role Permission Map

GroupSharedUserMapPull Import Group/User Relationships

SharedUserRoleMapPull Import User/Role Relationships

SharedUserPermissionMapPull Import User Permissions

For more information on these integration events, see the Ariba Spend Management Data Load Guide.
For descriptions of the Ariba Payment groups, roles, and permissions, see Appendix A, “Groups, Roles,
and Permissions.”
2 In partition None, run the following integration events, in this order:

Integration Event Name Display Name Where to Find

Information
PaymentMethodTypePull Import Payment Method Types Page 27

BankAccountTypePull Import Bank Account Types Page 29

BankAccountIDTypePull Import Bank Account Number Types Page 31

BankIDTypePull Import Bank Identifier Types Page 30

If you have a multilingual configuration, run the associated language integration events to load
translations:

Where to Find
Integration Event Name Display Name Information
PaymentMethodTypeLanguagePull Import Payment Method Type Translations Page 28

BankAccountTypeLanguagePull Import Bank Account Type Translations Page 30

BankIDTypeLanguagePull Import Bank Identifier Type Translations Page 30

BankAccountIDTypeLanguagePull Import Bank Account Number Type Page 31

Translations

Ariba Payment Implementation Guide 15

Migrating Existing Payment Requests to Ariba Payment Chapter 2 Enabling Ariba Payment

3 In each partition where you are enabling Ariba Payment, run the following integration events, in this
order:

Where to Find
Integration Event Name Display Name Information
PaymentTermsPull Import Payment Terms Page 39

SupplierPull Import Suppliers Ariba Buyer Data Load

Guide

SupplierLocationSupplementPull Import Supplier Location Contacts Ariba Buyer Data Load

Guide

SupplierSupplementPull Import Supplier Supplement Data Ariba Buyer Data Load

Guide

BuyerPaymentBankLocationPull Import Buyer Bank Payment Locations Page 32

SupplierPaymentBankLocationPull Import Supplier Bank Payment Page 32

Locations

RemittanceLocationPull Import Remittance Locations Page 34

SupplierLocationRemittanceInformationPull Import Supplier Location Remittance Page 35

Information

If you have a multilingual configuration, run the PaymentTermsLanguagePull integration event (display
name “Import Payment Term Translations”) to load translations for payment terms.
4 In partition None, run the following scheduled tasks, in this order, to pull supplier profile information
from AN:

Scheduled Task Name Display Name

AribaNetworkOrganizationSync Synchronize ASN Supplier Profile Information

CommonSupplierSyncUsingSupplierLocationID Synchronize ASN Supplier Account ID and Profile

Information

For information on these scheduled tasks, see the Ariba Buyer Configuration Guide.

Migrating Existing Payment Requests to Ariba Payment

After you have enabled Ariba Payment, you must run the PostProcessSettlementEnablement scheduled task
(display name “Performs post processing tasks after enabling settlement”). This task converts any existing
payment requests in your configuration to the Ariba Payment object model.

This task applies only to payment requests that currently have the status of Processing, and that were created
before you enabled Ariba Payment.

For more information, see “PostProcessSettlementEnablement” on page 80.

16 Ariba Payment Implementation Guide

Chapter 3 Payment Models and Payment Send

• “Approvable Documents for Payments” on page 17

• “About Payment Models” on page 18
• “Payment Model Configuration” on page 20
• “Send Method Configuration” on page 20
• “AribaPay Configuration” on page 22
• “ExternalPay Configuration” on page 24
• “Validation Customization” on page 25
• “Payment Status Integration” on page 25
• “Payment Request Export Events” on page 26

Approvable Documents for Payments

Ariba Payment represents payments with the following approvable document types:
• Payment requests, which represent upcoming payments
• Payment transactions, which represent payments that have been made

Each payment request document represents an expected payment. In the default configuration, no approvals
are required for payment requests. When a payment request is created, it enters the workflow, where the next
step depends on the payment model that is in effect. For example, if payment is to be made on an ERP
system, the payment request is sent immediately to that ERP system. However, if payment is to be made in
Ariba Payment, users can edit the payment request until it reaches its scheduled payment date.

When a payment is created, the organization creating the payment creates and returns remittance advice,
with details of the payments that have been made. For example, a remittance advice statement might list all
invoices included in a payment, including the payment method used, bank information, discount amount,
and amount paid.

When a payment is made in Ariba Payment, Ariba Payment creates payment transaction documents and
posts remittance advice to AN. When a payment is made on an external system, such as an ERP system,
Ariba Payment pulls remittance advice from the external system, uses the remittance advice to create
payment transaction documents, and then posts the remittance advice to AN.

For example, suppose that payment request PAY12 is sent to an ERP system. The ERP system creates a
payment that includes PAY12, and then posts remittance advice, that lists PAY12, to Ariba Payment. Ariba
Payment then creates a payment transaction document reflecting the payment that has been made.

For information on payment workflow and how users work with payments, see the Ariba Invoice and
Payment User Guide.

Ariba Payment Implementation Guide 17

About Payment Models Chapter 3 Payment Models and Payment Send

About Payment Models

A payment model describes how payment requests are converted into payments, and how the details of the
payment are exchanged. Ariba Payment supports payment models to create payment either within your
Ariba configuration or on an external system. The supported payment models are as follows:
• AribaPay
• ExternalPay

For each partition in your configuration, you use the Application.Settlement.PaymentModel parameter to
specify whether that partition uses AribaPay or ExternalPay.

AribaPay
If you handle payment within Ariba Settlement, either as direct payments or by sending payment requests to
AN, choose AribaPay. When you specify AribaPay, Ariba Payment further determines whether to send the
payment request to AN, or handle it directly within Ariba Payment:
• AN—Ariba Payment sends a payment request to AN, which creates the payment. AN payment is the
preferred payment model for suppliers who are enabled for electronic payment.
• Local—Ariba Payment creates the payment with a technique of your choice. such as cutting a physical
check or pushing data to a database table. Ariba Payment handles traditional payment functionality such
as payment scheduling, discount selection, and payment disbursement.

Ariba Payment sends the payment to AN if the following conditions are met:
• The selected remittance location matches a remittance location in the supplier’s payment profile, as
synced from AN. For information on supplier profile sync, see “Supplier Sync From AN” on page 33.
• The selected payment method is supported by the remittance location and by the payment provider on
AN.

If AN payment is available, the payment request scheduling screen shows AN and Local as options. The user
can choose Local from the menu to override the choice of AN. However, if AN payment is not available, Local
is the only choice available.

AN Configuration
If you plan to send payment requests to AN, you must make sure that the functionality is correctly enabled
on AN. For you and your suppliers to exchange payments through AN, the following must be specified on
AN:
• Your company’s profile must have payment and settlement functionality enabled.
• Suppliers who want to participate in electronic payment must be enabled for payment on AN, and must
configure their payment preferences on AN, including preferred payment methods, bank account
information, and contact information.

For more information on how to configure AN to support payment and settlement functionality, see the
Ariba Network Account Management Guide.

AN Payment Model Limitations

When sending payment requests to AN, be aware of the following limitations:

18 Ariba Payment Implementation Guide

Chapter 3 Payment Models and Payment Send About Payment Models

• Invoices that use AN payment are not exported to the “OK-to-Pay” file. Without this information, your
ERP system does not have visibility to these invoices. For more information, see “Payment Request
Export Events” on page 26.
• Remittance information is not sent back to your ERP system for payments made in AN. Without this
information, your ERP system does not have visibility to these payments.

ExternalPay
If you handle payments on any other external system, choose the ExternalPay payment model. When the
payment model is ExternalPay, payment is made on an external system, such as an ERP system. Ariba
Payment pulls back payment details with integration events. This model is appropriate for configurations
that are already using an ERP system for electronic payment.

Payment Models, Suppliers, and Supplier Locations

You can optionally associate a payment model with a specific supplier or supplier location. In the default
configuration, the following integration events associate payment models with suppliers and supplier
locations:
• The SupplierSupplementPull event associates payment models with suppliers
• The SupplierLocationSupplementPull event associates payment models with supplier locations

If you do not associate a payment model with a supplier location, the supplier location uses the payment
model associated with the supplier. If you do not associate a payment model with a supplier, the supplier
uses the payment model configured for the partition.

For information on supplier integration events, see the Ariba Buyer Data Load Guide.

Payment Models in Ariba Administrator

Users who have the PaymentAdministrator or PaymentManager permission can add or modify the payment
model associated with a supplier or supplier location by using the Supplier Payment Information task in the
Procure-to-Pay Manager workspace in Ariba Administrator. For example:

For more information, see Chapter 9, “Administration.”

Ariba Payment Implementation Guide 19

Payment Model Configuration Chapter 3 Payment Models and Payment Send

Payment Model Configuration

You must specify a preferred payment model for each partition in configuration, which specifies whether
that partition handles payments within Ariba Payment or sends them to an external system.

Use the Application.Settlement.PaymentModel parameter to specify the preferred payment model for a
partition. Valid values are AribaPay or ExternalPay.

For SAP, Oracle, and PeopleSoft partitions in the default configuration, this parameter is set to ExternalPay.
For CSV partitions, it is set to AribaPay. There is no default value.

When you specify AribaPay, Ariba Payment further determines whether to send the payment request to AN,
or handle it directly within Ariba Payment (local payment). The
Application.Settlement.LocalPaymentModelSupported parameter specifies whether the local payment model
is supported. In the default configuration, this parameter is set to true. There is no default value.

Send Method Configuration

The configuration settings for payment send describe how to format the data on a payment request document
and transmit it to external systems. For example, if the payment request is being sent to AN, it is formatted
as a cXML document and is sent to AN over the cXML channel.

Different payment models require different combinations of send methods. To define your send methods,
you use the following parameters:
• System.Settlement.PaymentRequestSendMethods, which specifies all the payment request send methods
available in your configuration for sending payment requests to external systems.
• Application.Settlement.PaymentRequestSendMethods, which specifies the payment request send methods
for a partition.

To send remittance advice to AN, Ariba Payment uses a send method defined in the following parameters:
• System.Settlement.PaymentTransactionSendMethods, which specifies all the send methods available in
your configuration for sending payment transactions to external systems.
• Application.Settlement.PaymentTransactionSendMethods, which specifies the payment transaction send
methods for a partition.

This method would not otherwise be used, because payment transactions are not sent to external systems.
For more information on sending remittance advice to AN, see “Remittance Post” on page 51.

20 Ariba Payment Implementation Guide

Chapter 3 Payment Models and Payment Send Send Method Configuration

Following is an example of System.Settlement.PaymentRequestSendMethods:

System = {
Settlement = {
PaymentRequestSendMethods = {
AribaNetwork = {
ACSNSendMethod = true;
ContactName = "UserSender";
ERPSendMethod = false;
Formatter = "ariba.payment.DummyPaymentFormatter”;
PaymentMethod = "ariba.payment.AribaNetworkPaymentRequestMethod"";
Sender = "ariba.payment.cxml.AribaNetworkCXMLPaymentProposalSender";
UsesAsynchronousPush = "false";
UsesDirectIntegration = "false";
};
};
};
};

System.Settlement.PaymentTransactionSendMethods is similar, but for payment transactions instead of

payment requests. For example:

System = {
Settlement = {
PaymentTransactionSendMethods = {
AribaNetwork = {
ACSNSendMethod = true;
ContactName = "UserSender";
ERPSendMethod = false;
Formatter = ariba.payment.DummyPaymentTransactionFormatter;
PaymentMethod = “ariba.payment.AribaNetworkPaymentTransactionMethod";
Sender = "ariba.payment.cxml.AribaNetworkCXMLPaymentRemittanceSender";
};
Silent = {
ContactName = "UserSender";
ACSNSendMethod = false;
ERPSendMethod = false;
PaymentMethod = ariba.payment.DummyPaymentTransactionMethod;
Formatter = ariba.payment.DummyPaymentTransactionFormatter;
Sender = ariba.payment.AribaPaymentTransactionSilentSender;
};
};
};
};

The definition of each send method includes the following set of parameters, which define the Java classes
making up the send method.

Parameter Description
ACSNSendMethod A Boolean value that indicates whether the method involves a transmission to AN.

ContactName Not used in this release.

ERPSendMethod A Boolean value that indicates whether the method sends to an ERP system.

Formatter Names the Java class used to format the information for transmission. The role of a
formatter is to manipulate the data to fit it to the schema of the ERP system.
PaymentMethod Names the Java class that implements the logic of which payment requests or
transactions are sent.
Sender Names the Java class used to perform the actual transmission.

Ariba Payment Implementation Guide 21

AribaPay Configuration Chapter 3 Payment Models and Payment Send

Parameter Description
UsesAsynchronousPush (Payment request send methods only) A Boolean value that indicates whether the
transmission is asynchronous or synchronous. When there is a status pull after the push,
the transmission is asynchronous and this parameter should be set to true. Otherwise, it
should be set to false.
UsesDirectIntegration (Payment request send methods only) A Boolean value that indicates whether the
recipient uses direct integration. The Ariba Web Services Channel uses direct
integration. The Ariba File Channel uses indirect integration. In direct integration, data is
pushed and the response is received immediately.

Following is an example of Application.Settlement.PaymentRequestSendMethods, which names one of the

send methods defined in System.Settlement.PaymentRequestSendMethods:

Application = {...
Settlement = {
PaymentRequestSendMethods="AribaNetwork";

Next is an example of Application.Settlement.PaymentTransactionSendMethods, which names a payment

transaction send method specified in System.Settlement.PaymentTransactionSendMethods:

Application = {...
Settlement = {
PaymentTransactionSendMethods="AribaNetwork";

AribaPay Configuration
This section describes configuration settings for AribaPay. These settings are appropriate for payments
either directly within Ariba Payment or on AN.

 To configure AribaPay:
1 Set Application.Settlement.PaymentModel to AribaPay:

2 In System.Settlement.PaymentRequestSendMethods, define two methods: one that does nothing, and one
that sends to AN. Typical entries are:
System = {
Settlement = {
PaymentRequestSendMethods = {
Silent = {
ACSNSendMethod = false;
ContactName = "PaymentTransaction.SupplierRemitToAddress.Name";
ERPSendMethod = false;
PaymentMethod = “ariba.payment.DummyPaymentMethod"";
Formatter = "ariba.payment.DummyPaymentFormatter";
Sender = "ariba.payment.AribaPaymentSilentSender";
UsesAsynchronousPush = "false";
UsesDirectIntegration = "false";
};
AribaNetwork = {
ERPSendMethod = false;
ContactName = "UserSender";
ACSNSendMethod = true;
PaymentMethod = “ariba.payment.AribaNetworkPaymentRequestMethod";
Formatter = "ariba.payment.DummyPaymentFormatter";
Sender ="ariba.payment.cxml.AribaNetworkCXMLPaymentProposalSender";

22 Ariba Payment Implementation Guide

Chapter 3 Payment Models and Payment Send AribaPay Configuration

UseAsynchronousPush = “false”;
UsesDirectIntegration = "false";
};
};
};
};

The AribaNetwork method sends payment requests to AN. The Sender is

AribaNetworkCXMLPaymentProposalSender, which sends a cXML document of type
PaymentRequestProposal to AN. The Formatter class is set to DummyPaymentFormatter because the
formatting is handled by the cXML channel.
The Silent method is used for Ariba direct payment. With direct payment, the payment request is not sent
anywhere because the payment is directly in Ariba Payment. The payment request send method for Ariba
direct payment is a dummy method, which does not send the payment request anywhere.
3 In Application.Settlement, set the preferred send method to AribaNetwork, to match the send method
defined in System.Settlement. For example:
Application = {...
Settlement = {
PaymentRequestSendMethods="AribaNetwork";

4 In System.Settlement.PaymentTransactionSendMethods, define payment transaction send methods, which

are similar to the payment request methods. For example:
System = {
Settlement = {
PaymentTransactionSendMethods = {
Silent = {
ACSNSendMethod = false;
ContactName = "UserSender;
ERPSendMethod = false;
PaymentMethod = ariba.payment.DummyPaymentTransactionMethod";
Formatter = "ariba.payment.DummyPaymentTransactionFormatter";
Sender = "ariba.payment.AribaPaymentTransactionSilentSender";
};
AribaNetwork = {
ERPSendMethod = false;
ContactName = "UserSender";
ACSNSendMethod = true;
PaymentMethod= "ariba.payment.AribaNetworkPaymentTransactionMethod";
Formatter = "ariba.payment.DummyPaymentTransactionFormatter";
Sender = "ariba.payment.cxml.AribaNetworkCXMLPaymentRemittanceSender";
};
};
};
};

5 In Application.Settlement.PaymentTransactionSendMethod, set the payment transaction method to

AribaNetwork. For example:
Application = {...
Settlement = {
PaymentTransactionSendMethod="AribaNetwork";

Ariba Payment Implementation Guide 23

ExternalPay Configuration Chapter 3 Payment Models and Payment Send

ExternalPay Configuration
This section describes configuration settings for ExternalPay. These settings are appropriate for partitions
that send payments to an ERP system.

 To configure ExternalPay:
1 Set Application.Settlement.PaymentModel to ExternalPay:

2 In System.Settlement.PaymentRequestSendMethods, define the available send methods. Typical entries are:

System = {
Settlement = {
PaymentRequestSendMethods = {
OraclePaymentERP = {
ACSNSendMethod = false;
ContactName = "UserSender";
ERPSendMethod = true;
Formatter = "ariba.oracle.server.OracleInvoiceFormatter";
PaymentMethod = "ariba.payment.AribaERPPaymentMethod";
Sender = ariba.payment.AribaPaymentQueueSender;
UsesAsynchronousPush = "true";
UsesDirectIntegration = "false";
}
PSPaymentERP = {
ACSNSendMethod = false;
ContactName = "UserSender";
ERPSendMethod = true;
Formatter = "ariba.peoplesoft.server.PsoftInvoiceFormatter";
PaymentMethod = "ariba.payment.AribaERPPaymentMethod";
Sender = ariba.payment.AribaPaymentQueueSender;
UsesAsynchronousPush = "true";
UsesDirectIntegration = "false";
}
SAPPaymentERP = {
ACSNSendMethod = false;
ContactName = "UserSender";
ERPSendMethod = true;
Formatter = "ariba.sap.server.SAPInvoiceFormatter";
PaymentMethod = "ariba.payment.AribaERPPaymentMethod";
Sender = ariba.payment.AribaPaymentQueueSender;
UsesAsynchronousPush = "true";
UsesDirectIntegration = "false";
}
SAPPaymentERPDirect = {
ACSNSendMethod = false;
ContactName = "UserSender";
ERPSendMethod = true;
Formatter = "ariba.sap.server.SAPInvoiceFormatter";
PaymentMethod = "ariba.payment.AribaERPPaymentMethod";
Sender = ariba.payment.AribaPaymentQueueSender;
UsesAsynchronousPush = "false";
UsesDirectIntegration = "true";
}
}
};
};

24 Ariba Payment Implementation Guide

Chapter 3 Payment Models and Payment Send Validation Customization

3 In Application.Settlement.PaymentRequestSendMethods, set the preferred send method to match a send

method defined in System.Settlement.PaymentRequestSendMethods. For example:
Application = {...
Settlement = {
PaymentRequestSendMethods="SAPPaymentERP";

Validation Customization
Before sending a payment request to AN, or scheduling it for payment, Ariba Payment validates the fields
that are in the PaymentRequestValidationGroup group. If any of the fields in this group are invalid (as defined
by the validity conditions specified on those fields in the metadata XML file), the payment request is not sent
to AN or scheduled with the ProcessPendingPaymentRequests scheduled task (display name “Process
Pending Payment Requests”).

If there are errors, Ariba Payment writes a log message to the log category payment/debug, indicating that the
request was not scheduled because it contained invalid fields. A payment administrator must modify the
request to fix the invalid fields before the payment can be successfully scheduled.

You can modify the fields that are validated by changing the fields defined in
PaymentRequestValidationGroup.

Payment Status Integration

You transfer payment status data from an ERP system to CSV files, and then run integration events to import
the CSV files into Ariba Payment through the Ariba File Channel.

The following integration events load payment status data from Oracle, PeopleSoft, and SAP systems into
Ariba Payment:
• PaymentIDImport (display name “Import Payment ID”
• PaymentErrorImport (display name “Import Payment Error”)

For ERP integration details, see the Ariba Buyer ERP integration guide for your ERP system:
• Ariba Buyer Oracle Financials Integration Guide
• Ariba Buyer PeopleSoft Integration Guide
• Ariba Buyer SAP Integration Guide

Ariba Payment Implementation Guide 25

Payment Request Export Events Chapter 3 Payment Models and Payment Send

Payment Request Export Events

You can export payment requests—also referred to as “OK-to-Pay” invoice data—by running the following
integration events in Ariba Administrator:

Variant Integration Event Name Display Name

PeopleSoft PaymentExport Export Payment Requests

Oracle PaymentCombinedFormatExport Export Payment Requests in 3 File Format

SAP (Ariba File Channel) PaymentFileExport Export Payment File

These integration events export payment requests that use the External System payment model only.

For more information on these integration events, see the Ariba Buyer ERP integration guide for your ERP
system:
• Ariba Buyer PeopleSoft Integration Guide
• Ariba Buyer SAP Integration Guide
• Ariba Buyer Oracle Financials Integration Guide

26 Ariba Payment Implementation Guide

Chapter 4 Payment Methods

• “About Payment Methods” on page 27

• “Integration Events for Payment Methods” on page 27
• “Payment Methods in Ariba Administrator” on page 28

About Payment Methods

A payment method defines how a buying organization makes a payment to a supplier. Typical payment
methods include check, Automatic Clearing House (ACH) electronic transfer, wire transfer, and credit card
(purchasing card).

When a payment request is created, Ariba Payment sets a default payment method. Users viewing payments
can see and possibly modify the payment method from the user interface.

Integration Events for Payment Methods

This section describes the integration events for payment methods. For descriptions of the columns in the
CSV files read by these integration events, see the Data Dictionary.

PaymentMethodTypePull
To set up your configuration for electronic payment, you define the set of payment methods you support by
using the PaymentMethodTypePull integration event (display name “Import Payment Method Types”). The
payment method types you define with this integration event are the payment method types available to users
in the chooser in the user interface.

The default configuration supplies one implementation of this integration event, which uses the Ariba File
Channel and reads from the following CSV file:

config/variants/Plain/parititions/None/data/PaymentMethodType.csv

The default configuration defines no standard payment method types. You must define your preferred
payment methods by adding entries to the PaymentMethodType.csv file.

Following is an example of PaymentMethodType.csv:

Cp1252
"UniqueName","Name","Description","Rank","Electronic","ClearancePeriod"
"check","Check","Payment by check","1","false","15"
"ach","ACH","Payment via ACH","2","true","3"
"wire","WIRE","Payment via wire","3","true","3"
"creditCard","Credit Card","Payment via credit card","4","true","5"

Ariba Payment Implementation Guide 27

Payment Methods in Ariba Administrator Chapter 4 Payment Methods

PaymentMethodTypeLanguagePull
In a multilingual configuration, you can use the PaymentMethodTypeLanguagePull integration event
(display name “Import Payment Method Type Translations”) to load translations for payment method names
and descriptions.

For information on how to pull data in multiple languages, see the Ariba Spend Management Data Load
Guide.

PaymentMethodTypeExport
You use the PaymentMethodTypeExport integration event (display name “Export Payment Method Types”)
to export payment methods from your configuration to a CSV file.

For some payment methods, such as ACH, your suppliers must edit their supplier preferences on AN to
indicate support for the given payment method. For information on how suppliers edit preferences on AN,
see the AN documentation.

Payment Methods in Ariba Administrator

Users who have the PaymentAdministrator or PaymentManager permission can manage payment methods by
using the Payment Methods task in the Procure-to-Pay Manager workspace in Ariba Administrator.

For more information, see Chapter 9, “Administration.”

28 Ariba Payment Implementation Guide

Chapter 5 Bank Information

• “About Bank Information” on page 29

• “Integration Events For Bank Account Information” on page 29
• “Integration Events for Choosing Bank Accounts” on page 32
• “Supplier Sync From AN” on page 33
• “Integration Events for Remittance Locations” on page 34
• “Bank Information in Ariba Administrator” on page 36

About Bank Information

You must define bank information for buyer and supplier bank accounts that are available for electronic
funds transfers. Bank information includes:
• Bank names and addresses
• Bank account types
• Bank account number types
• Bank identifier types

Integration Events For Bank Account Information

Bank account information defines basic parameters for identifying a bank account to be used for electronic
funds transfer. For example, the bank account integration events define the naming schemes used for bank
IDs and bank account IDs.

This section describes the integration events that load bank identification information. For descriptions of
the columns in the CSV files read by these integration events, see the Data Dictionary.

BankAccountTypePull
You use the BankAccountTypePull integration event (display name “Import Bank Account Types”) to define
all supported types of bank accounts, such as checking accounts and savings accounts.

The default configuration supplies one implementation of the BankAccountTypePull integration event,
which reads from the following CSV file:

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

The default configuration defines no standard bank account types. You define your preferred account types
by adding entries to BankAccountType.csv.

Ariba Payment Implementation Guide 29

Integration Events For Bank Account Information Chapter 5 Bank Information

The following lines are from a typical BankAccountType.csv file:

Cp1250
"UniqueName","Name","Description"
"checking","Checking Account","Checking Account"
"savings","Savings Account","Savings Account"

BankAccountTypeLanguagePull
In a multilingual configuration, you can use the BankAccountTypeLanguagePull integration event (display
name “Import Bank Account Type Translations”) to load translations for bank account type names and
descriptions.

For more information on how to pull data in multiple languages, see the Ariba Spend Management Data
Load Guide.

BankAccountTypeExport
You use the BankAccountTypeExport integration event (display name “Export Bank Account Types”) to
export bank account types from your configuration to a CSV file.

BankIDTypePull
You use the BankIDTypePull integration event (display name “Import Bank Identifier Types”) to define bank
ID types, such as Society for Worldwide Interbank Financial Telecommunication (S.W.I.F.T) and American
Bankers Association (ABA).

The default configuration supplies one implementation of the BankIDType integration event, which uses the
Ariba File Channel to read from the following CSV file:

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

The default configuration defines no standard bank ID types. You define your preferred bank ID types by
adding entries to BankIDType.csv.

The following lines are from a typical BankIDType.csv file:

Cp1252
"UniqueName","Name","Description"
"ABA","ABA Routing number","American Banking Association routing number"
"SWIFT","S.W.I.F.T","Society for Worldwide Interbank Financial Telecommunications s.c."

BankIDTypeLanguagePull
In a multilingual configuration, you can use the BankIDTypeLanguagePull integration event (display name
“Import Bank Identifier Type Translations”) to load translations for bank ID type names.

For more information on how to pull data in multiple languages, see the Ariba Spend Management Data
Load Guide.

30 Ariba Payment Implementation Guide

Chapter 5 Bank Information Integration Events For Bank Account Information

BankIDTypeExport
You use the BankIDTypeExport integration event (display name “Export Bank Identifier Types”) to export
bank ID types from your configuration to a CSV file.

BankAccountIDTypePull
You use the BankAccountIDTypePull integration event (display name “Import Bank Account Number
Types”) to define bank account ID types, such as National or International Bank Account Number (IBAN).

The default configuration supplies one implementation of the BankAccountIDType integration event, which
uses the Ariba File Channel to read from the following CSV files:

ariba/variants/Plain/partitions/None/data/BankAccountIDType.csv
config/variants/Plain/parititions/None/data/BankAccountIDType.csv

The following lines are from a typical BankAccountIDType.csv file:

Cp1252
"UniqueName","Name","Description"
"national","National","National"
"IBAN","IBAN","International Bank Account Number"

BankAccountIDTypeLanguagePull
In a multilingual configuration, you can use the BankAccountIDTypeLanguagePull integration event
(display name “Import Bank Account Number Type Translations”) to load translations for bank account ID
type names.

For more information on how to pull data in multiple languages, see the Ariba Spend Management Data
Load Guide.

BankAccountIDTypeExport
You use the BankAccountIDTypeExport integration event (display name “Export Bank Account Types”) to
export bank account ID types from your configuration to a CSV file.

Ariba Payment Implementation Guide 31

Integration Events for Choosing Bank Accounts Chapter 5 Bank Information

Integration Events for Choosing Bank Accounts

You use integration events to define information about specific bank accounts that are available for use in
electronic transfers. The accounts defined by these integration events are visible in a chooser on payment
request approvable documents. The default value is chosen with a trigger fired when the field is created and
uses the action ariba.payment.core.action.SetBuyerPaymentBankLocation to choose a default value. If you
require custom logic for choosing the default bank for the BuyerBankLocation field, you can create a custom
trigger action for this field. For information on custom triggers, see the Ariba Spend Management
Customization Guide.

After the initial value is chosen, a payment manager who is editing the payment request document can make
changes by selecting a different account from the chooser.

For descriptions of the columns in the CSV files read by these integration events, see the Data Dictionary.

SupplierPaymentBankLocationPull
You use the SupplierPaymentBankLocation integration event (display name “Import Supplier Bank Payment
Locations”) to define the details of supplier bank accounts. The default configuration supplies one
implementation of the SupplierPaymentBankLocationPull event, which uses the Ariba File Channel and
reads from the following CSV file:

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

The following lines are from a typical SupplierPaymentBankLocation.csv file:

Cp1252
"UniqueName","SupplierUniqueName","Name","BankName","BankIDType","BankID","BankAccountIDType","Ba
nkAccountID","BankAccountType",AddressUniqueName,Street,City,State,PostalCode,CountryUniqueName
"SupplierBankLocation-1",11,"JCN West Coast Payments Check Processing Center","Wells Fargo
Bank","abaRoutingNumber","123456788","bankAccountID","123-a","checking","BL-1","123 Easy St","San
Francisco","CA","92302","US"

SupplierPaymentBankLocationExport
You use the SupplierPaymentBankLocationExport integration event (display name “Export Supplier Bank
Payment Locations”) to export the details of supplier bank accounts from your configuration to a CSV file.

BuyerPaymentBankLocationPull
You use the BuyerPaymentBankLocationPull integration event (display name “Import Buyer Bank Payment
Locations”) to define the details of the buying company’s bank accounts. The default configuration supplies
one implementation of the BuyerPaymentBankLocationPull event, which uses the Ariba File Channel and
reads from the following file:

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

The fields are identical to those in SupplierPaymentBankLocation.csv, except that the SupplierUniqueName
field is not used.

32 Ariba Payment Implementation Guide

Chapter 5 Bank Information Supplier Sync From AN

BuyerPaymentBankLocationExport
You use the BuyerPaymentBankLocationExport integration event (display name “Export Buyer Bank
Payment Locations”) to export the details of buyer bank accounts from your configuration to a CSV file.

Supplier Sync From AN

The information in this section is required if you handle payments within Ariba, either by creating the
payments on Ariba Payment or by sending them to AN. If you send all payments to an external system such
as an ERP system, this section does not apply.

To obtain information about suppliers, including profile settings about the payment methods that each
supplier location supports, Ariba Payment downloads supplier profile information from AN. Suppliers
manage their own supplier profile information on AN and Ariba Payment pulls that updated information
with scheduled tasks.

The scheduled tasks for downloading supplier profile information are as follows:
• AribaNetworkOrganizationSync (display name “Synchronize ASN Supplier Profile Updates”), which
pulls current profile information for all suppliers in your configuration that have Ariba Network IDs or
D-U-N-S IDs.
• CommonSupplierSyncUsingSupplierLocationID (display name “Synchronize ASN Supplier Account ID
and Profile Information”), which is similar to AribaNetworkOrganizationSync, but designed for situations
where a supplier has different AN IDs for different supplier locations.
• GetPendingAribaNetworkOrganizationSync (display name “Synchronize ASN Supplier Profile
Updates”), which polls AN for changes made since the last sync (with either
AribaNetworkOrganizationSync or CommonSupplierSyncUsingSupplierLocationID), and downloads
those updates.

Typically you use AribaNetworkOrganizationSync or CommonSupplierSyncUsingSupplierLocationID to

sync the initial set of supplier information and then use GetPendingAribaNetworkOrganizationSync on a
regular basis to maintain the information through updates.

The supplier profile information pulled from AN does not include supplier bank information. For security
reasons, you must load your bank information from integration events, as described in “Integration Events
For Bank Account Information” on page 29.

For information on how to configure and use these scheduled tasks for downloading profile information
from AN, see the chapter about suppliers in the Ariba Buyer Data Load Guide.

Ariba Payment Implementation Guide 33

Integration Events for Remittance Locations Chapter 5 Bank Information

Integration Events for Remittance Locations

This section describes integration events that you use to supplement the supplier profile data pulled from
AN.

When sending a payment to a given supplier location, Ariba Payment sends it to the remittance location
associated with that supplier location. Suppliers define remittance locations on AN, as part of their supplier
profile information, to indicate the address to which payment is sent.

To prevent suppliers from adding additional remittance addresses and receiving payments to those addresses
fraudulently, Ariba Payment defines a master list of valid remittance locations, and uses that list to verify the
remittance locations defined by the suppliers on AN.

The list loaded from Ariba Payment is considered the master list. In the user interface, the remittance
address chooser shows only the valid addresses pulled from the master list. Ariba Payment sends payment to
AN only if the remittance address selected from the chooser matches a remittance address read from AN.

The default configuration includes a trigger on the remittance location field that potentially updates the
remittance location field whenever the supplier location field changes. The trigger is defined as follows:

<trigger name="SetRemittanceLocationOnSupplierLocationChange" event="FieldChange"

field="SupplierLocation">
<action implementation="ariba.payment.core.action.SetRemittanceLocation"> <parameter
name="Target" outputField="RemittanceLocation"/>
<parameter name="Source" inputField="SupplierLocation"/>
</action>
</trigger>

For descriptions of the columns in the CSV files read by these integration events, see the Data Dictionary.

RemittanceLocationPull
You use the RemittanceLocationPull integration event to define the valid list of remittance locations in your
configuration. This list is used to verify remittance addresses specified by suppliers in their AN profiles.

The RemittanceLocationPull integration event is a header-details event, in which the header file
(RemittanceLocation.csv) defines a list of remittance locations and the details file
(RemittanceLocationDetails.csv) provides details on each specific location.

The default configuration supplies one implementation of this event, which reads partitioned data.

The file RemittanceLocation.csv defines a list of remittance locations, each with a unique name. The default
configuration reads the header file from the following location:

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

34 Ariba Payment Implementation Guide

Chapter 5 Bank Information Integration Events for Remittance Locations

The following lines are from a typical RemittanceLocation.csv file:

Cp1252
UniqueName,AddressUniqueName,Name,Lines,City,State,PostalCode,CountryUniqueName
RL1,RA1,"Austin","3450 Industrial Park Road","Austin","TX","78701","US"
RL2,RA2,"Sacramento","1400 Global Parkway","Sacramento","CA","95801","US"
RL3,RA3,"San Francisco Dist","3000 Airport Boulevard","San Francisco","CA","94128","US"

The file RemittanceLocationDetails.csv defines the details of a specific remittance location. The following
lines are from a typical RemittanceLocationDetails.csv file:

Cp1252
Parent.UniqueName,PaymentMethod,BankInfo,RemittancePCardNumber
RL1,check,SupplierBankLocation-1,
RL1,ach,SupplierBankLocation-2,
RL1,creditCard,SupplierBankLocation-2,"2222222222111111"
RL2,ach,SupplierBankLocation-3,

SupplierLocationRemittanceInformationPull
You use the SupplierLocationRemittanceInformationPull integration event to associate remittance locations
with supplier locations.

The SupplierLocationRemittanceInformationPull is a header-details event that reads from the following

files:

SLRemittanceInformation.csv
SLRemittanceInformationDetails.csv

The file SLRemittanceInformation.csv defines a list of remittance locations, each with a unique name. The
default configuration reads the header file from the following location:

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

The following lines are from a typical SLRemittanceInformation.csv file:

Cp1252
UniqueName,ContactID,ANPayEnabled
14,63,true
15,14,true
36,34,false

The details file SLRemittanceInformationDetails.csv defines the remittance address information for a
supplier location. The default configuration reads the details file from the following location:

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

The following lines are from a typical SLRemittanceInformationDetails.csv file:

Cp1252
Parent.UniqueName,Parent.ContactID,RemittanceLocation
14,63,RL1
14,63,RL2

Ariba Payment Implementation Guide 35

Bank Information in Ariba Administrator Chapter 5 Bank Information

Bank Information in Ariba Administrator

Users who have the PaymentAdministrator or PaymentManager permission can use the following tasks in the
Procure-to-Pay Manager workspace to manage bank information:
• Payment Bank Locations—use this task to view, add, modify, and delete supplier and buyer payment bank
locations.
• Supplier Payment Information—use this task to view, add, and modify remittance locations associated
with supplier locations.

For more information, see Chapter 9, “Administration.”

36 Ariba Payment Implementation Guide

Chapter 6 Payment Terms

• “About Payment Terms” on page 37

• “Integration Events for Payment Terms” on page 39
• “Payment Terms in Ariba Administrator” on page 40
• “How Payment Terms Are Set” on page 40

About Payment Terms

Payment terms are agreements between your company and your suppliers, specifying the details of when
payment must be made. Payment terms typically specify the number of days within which payment must be
made and include any discounts that are available for early payment.

Payment terms specify when a supplier must be paid for an invoice and define any discounts that are
available for early payment. For example, a supplier might offer a 5 percent discount if the invoice is paid in
15 days. Payment terms are typically standardized across your company under names such as Net 30 or Net
45.

The default configuration sets payment terms with triggers, setting some objects on creation and others in
response to related field change. For example, payment terms are set on contracts and purchase orders when
those objects are created, copying the initial payment terms from the supplier object.

After the payment terms have been set, they are updated with triggers if a related field changes in such a way
that the payment terms change. For example, if a payment manager changes the supplier field on an invoice,
a trigger is fired to determine if the payment terms need to be updated as well.

For information on how the payment terms field is used during the payment process, see “Local and AN
Payments” on page 43.

Payment Terms, Suppliers, and Supplier Locations

To define payment terms, you run an integration event that defines your standard set of payment terms. After
you have defined a set of payment terms, you associate appropriate payment terms with each supplier or
supplier location.

In the default configuration, the following integration events associate payment terms with suppliers and
supplier locations:
• The SupplierPull event associates payment terms with suppliers
• The SupplierLocationSupplementPull event associates payment terms with supplier locations

For information on supplier integration events, see the Ariba Buyer Data Load Guide.

Ariba Payment Implementation Guide 37

About Payment Terms Chapter 6 Payment Terms

Payment Terms and Other Objects

Depending on the ERP system that you use, payment terms might also be associated with other objects, such
as Operating Unit (Oracle) or Business Unit (PeopleSoft).

For more information, see the integration guide for your ERP system:
• Ariba Buyer Oracle Financials Integration Guide
• Ariba Buyer PeopleSoft Integration Guide
• Ariba Buyer SAP Integration Guide.

Payment Terms in the Object Model

Payment terms originate with the supplier, and must eventually be set on the payment request. In the object
model, payment terms are defined on the following objects:
• Suppliers (or supplier locations). Payment terms represent agreements with specific suppliers, and the
payment terms used for payments to a specific supplier are stored with that supplier, as part of the
SupplierPull integration event.
• Purchase orders and contracts. Invoices can be created from purchase orders or contracts. Payment terms
are stored with both orders and contracts.
• Invoice reconciliations. Ariba Payment sets the payment terms for an invoice from the purchase order or
contract.

Ariba Payment uses triggers to set and update the payment terms field as appropriate. For example, if a
payment manager editing an invoice reconciliation changes the supplier, a trigger updates the payment terms
field based on that change.

The default configuration provides sample logic for setting or updating payment terms. You can customize
your configuration by changing the logic of the trigger action. For more information on the triggers, see
“Triggers for Defaulting Payment Terms” on page 40.

When evaluating payment terms, you can configure which line item types are considered. In the default
configuration, only actual line items are considered, and not additional charges such as tax or freight fees.
For example, if the payment terms offer a discount based on when the net amount is paid, Ariba Payment
includes only standard line items when calculating the net amount. For more information on line item
categories, see “Line Types for Discounts” on page 46.

Note that AN invoices can be loaded into Ariba Buyer containing payment terms that do not match any
terms defined in Ariba Settlement. In this case, Ariba Buyer displays the payment terms on the invoice,
using the structure of the payment terms as the display name. For example, the payment terms 2/10, net 30
display as ((0%/30)(2%/10))*. An asterisk on the payment term field indicates a payment term not defined in
Ariba Settlement.

38 Ariba Payment Implementation Guide

Chapter 6 Payment Terms Integration Events for Payment Terms

Integration Events for Payment Terms

This section describes the integration events for payment terms. For descriptions of the columns in the CSV
files read by these integration events, see the Data Dictionary.

PaymentTermsPull
You define payment terms using the PaymentTermsPull integration event (display name “Import Payment
Terms”). The PaymentTermsPull integration event loads partitioned data.

The default configuration provides one implementation of the PaymentTermsPull integration event. This is a
header-details integration event, which reads data from the following CSV files:

config/variants/variant/partitions/partition/data/PaymentTerms.csv
config/variants/variant/partitions/partition/data/PaymentTermSteps.csv
config/variants/variant/partitions/partition/data/PaymentTermStepDetails.csv

The header file (PaymentTerms.csv) defines the set of payment terms you support, and the details files
(PaymentTermSteps.csv and PaymentTermStepDetails.csv) specify the details of each of those payment terms.

The following example shows lines from a typical PaymentTerms.csv file:

Cp1252
"UniqueName","Name","Description"
PT1,"Net 45, 2%/30, 3%/20","Net amount due in 45 days, 2% discount if paid in 30 days, 3% discount
if paid in 20 days"
PT2,"Net 30, 2%/20","Net amount due in 30 days, 2% discount if paid in 20 days"
PT3,"Net 30, 200/20","Net amount due in 30 days, $200 discount if paid in 20 days"

The following example shows lines from a typical PaymentTermSteps.csv file:

Cp1252
"Parent.UniqueName","InstallmentPercent","StepJoinToken"
PT1,1,PT1-1
PT2,1,PT2-1
PT3,1,PT3-1

The following example shows lines from a typical PaymentTermStepDetails.csv file:

Cp1252
"Parent.StepJoinToken","DiscountType","Discount","PayInDays"
PT1-1,"percent",0,45
PT1-1,"percent",2,30
PT1-1,"percent",3,20
PT2-1,"percent",0,30
PT2-1,"percent",2,20
PT3-1,"amount",0,30
PT3-1,"amount",200,20

The following example shows lines from a typical PaymentTerms.csv file:

CP1252
“UniqueName”,”Name”,”Description”
PT1,"Net 45, 2%/30, 3%/20","Net amount due in 45 days, 2% discount if paid in 30 days, 3% discount
if paid in 20 days"
PT2,"Net 30, 2%/20","Net amount due in 30 days, 2% discount if paid in 20 days"
PT3,"Net 30, 200/20","Net amount due in 30 days, $200 discount if paid in 20 days"

Ariba Payment Implementation Guide 39

Payment Terms in Ariba Administrator Chapter 6 Payment Terms

PaymentTermsExport
You can use the PaymentTermsExport integration event (display name “Export Payment Terms”) to export
payment terms from your configuration to CSV files.

PaymentTermsLanguagePull
In a multilingual configuration, you can use the PaymentTermsLanguagePull integration event (display
name “Import Payment Term Translations”) to load translations for payment term names and descriptions.

For information on how to pull information in multiple languages, see the Ariba Spend Management Data
Load Guide.

Payment Terms in Ariba Administrator

Users who have the PaymentAdministrator or PaymentManager permission can manage payment methods by
using the Payment Terms task in the Procure-to-Pay Manager workspace in Ariba Administrator.

For more information, see Chapter 9, “Administration.”

How Payment Terms Are Set

Ariba Payment sets (and updates) payment terms with triggers. The triggers update the payment terms fields
on purchase orders and invoice reconciliations in response to changes in supplier location or other related
fields.

This section describes the triggers used in the default configuration. For information on how to substitute a
custom trigger action, see the Ariba Spend Management Customization Guide.

Note: If there are no payment terms set on a payment request, the payment is due immediately and no
discounts are available.

Triggers for Defaulting Payment Terms

The default configuration uses trigger events to set payment terms on various objects, as the data changes.
These triggers are used in Contracts.aml, Ordering.aml, and Invoicing.aml, to update purchase orders,
contracts, and invoice reconciliations as appropriate. For example, in Invoicing.aml, the trigger events
update the payment terms field on an invoice reconciliation if a payment manager changes the supplier or
order associated with that invoice.

The trigger events that set payment terms are as follows:

This trigger... Is fired when...

SetPaymentTermsOnSupplierChange The Supplier field is changed.

SetPaymentTermsOnSupplierLocationChange The SupplierLocation field is changed.

40 Ariba Payment Implementation Guide

Chapter 6 Payment Terms How Payment Terms Are Set

This trigger... Is fired when...

SetPaymentTermsOnMAChange The MasterAgreement field is changed.

SetPaymentTermsOnOrderChange The Order field is changed.

In the default configuration, these trigger events all use the action
ariba.procure.core.action.SetPaymentTerms. A sample trigger is as follows:

<trigger name="SetPaymentTermsOnSupplierChange"
event="FieldChange"
field="Supplier">
<action implementation="ariba.procure.core.action.SetPaymentTerms">
<parameter name="Target"
outputField="PaymentTerms"/>
<parameter name="Source"
inputField="Supplier"/>
</action>
</trigger>

The SetPaymentTerms action calls a Java class, called a payment terms defaulter, which implements the logic
of setting the payment terms. The next section describes how to configure and customize the payment terms
defaulter.

Payment Terms Defaulters

The SetPaymentTerms action calls a Java class to set the payment terms. The name of the Java class is
specified with the Application.Procure.PaymentTermsDefaulter parameter.

The default configuration provides two implementations:

• ariba.payment.core.AribaPaymentTermsDefaulter, which implements the standard logic in the default
configuration.
• ariba.sap.common.SAPPaymentTermsDefaulter, which is used in SAP configurations.

If you require additional logic or flexibility beyond what is available in the default configuration, you can
write a custom Java implementation, and supply the name of that implementation in
config/Parameters.table.

Parameter Application.Procure.PaymentTermsDefaulter

API to implement ariba.common.core.PaymentTermsDefaulter

This section describes the default implementations. For information on how to implement a custom payment
terms defaulter, see the Javadoc.

AribaPaymentTermsDefaulter
The class ariba.payment.core.AribaPaymentTermsDefaulter is the default for most configurations. It looks
for payment terms by searching in the following order:
• Purchase order
• Contract (if the order is associated with a contract)

Ariba Payment Implementation Guide 41

How Payment Terms Are Set Chapter 6 Payment Terms

• Supplier location
• Supplier
• Default payment terms, as specified with the partition-specific parameter
Application.Procure.DefaultPaymentTerms. The value of this parameter must be the unique name of a
payment term defined in the partition, such as PT1.

For example, the following is a possible scenario for an invoice:

• Ariba Payment first looks on the purchase order for the payment term.
• If there is no payment term on the purchase order, Ariba Payment checks the supplier location.
• If there is no payment term associated with the supplier location, Ariba Payment checks the supplier.
• Finally, if there is no payment term associated with the supplier, Ariba Payment uses the default payment
terms for the partition, as specified with Application.Procure.DefaultPaymentTerms.

ERP Integration Considerations

When Ariba Buyer sends a purchase order to an ERP system, the payment terms are not included on the
outgoing order. Instead, the ERP system chooses its own payment terms, using logic defined on the ERP
system. If you have chosen payment terms in Ariba Payment that match the terms used on your ERP system,
the default payment terms chosen on the ERP system are usually the same as those chosen in Ariba Buyer.
In some situations they can differ, which leads to an exception during invoice reconciliation.

Ariba Payment is configured so that the rules for setting payment terms match the logic for setting payment
terms on the ERP system, as closely as possible. The goal is for both systems to choose the same payment
terms. However, it is possible for the ERP system to choose different terms.

If you load an invoice that includes payment terms set by the ERP system, the invoice reconciliation process
validates the payment terms to make sure that they are the same. If the payment terms do not match, Ariba
Invoice generates the PaymentTermException during invoice reconciliation. For information on the invoice
reconciliation process, and how to reconcile exceptions, see the Ariba Invoice Implementation Guide.

By adjusting the sample payment terms defaulting logic in ERP system to more closely match the logic used
on your ERP system, you can often prevent such errors. For information about payment terms specific to
each ERP system, see the integration guide for your ERP system:
• Ariba Buyer Oracle Financials Integration Guide
• Ariba Buyer PeopleSoft Integration Guide
• Ariba Buyer SAP Integration Guide

42 Ariba Payment Implementation Guide

Chapter 7 Local and AN Payments

• “About Local and AN Payments” on page 43

• “Payment Schedules and Discounts” on page 43
• “Payment Aggregation” on page 47
• “Payment Disbursement” on page 49
• “Scheduled Tasks for Processing Local Payments” on page 50

About Local and AN Payments

Ariba Payment provides two AribaPay payment models:
• Local—A payment that is created in Ariba Payment and then sent directly to the supplier, either as an
electronic document or through a system such as a check writer.
• AN—A payment request that is sent to AN, where the payment is made.

With either AribaPay payment model, Ariba Payment provides basic payment handling functionality such as
payment scheduling and discount selection. With direct (Local) payment, Ariba Payment also handles
payment aggregation and disbursement.

Ariba Payment provides default Java classes for the following components:
• A payment scheduler, which sets payment terms and expected dates.
• A payment discount selector, which chooses any available discounts.
• A payment aggregator, which creates payment transaction documents, potentially aggregating several
related payment requests onto a single transaction.
• A payment disburser, which pushes approved payments. The default configuration pushes payments to a
database staging table, and then marks those payments as Paid.

This chapter describes how each of these steps is implemented in the default configuration and describes
how to replace or modify the default implementations with custom Java implementations.

Payment Schedules and Discounts

When the payment model for a payment request is AribaPay, the workflow fires two workflow actions, one
that calls a payment scheduler, and one that calls a payment discount selector:
• The payment scheduler reads the data on a payment request and sets the expected payment schedule for
that request.
• The payment discount selector selects any discounts that are available, given the specified payment terms
and payment dates.

Ariba Payment Implementation Guide 43

Payment Schedules and Discounts Chapter 7 Local and AN Payments

These two classes are always called in succession, because the available discounts depend on the payment
schedule. For example, if a payment is scheduled to be made within 30 days, the payment discount selector
can determine what discounts are still available.

The payment scheduler and discount selector are called twice for each payment request: once when the
request is first created, and again when the original invoice reconciliation is fully approved. The payment
request is initially created at the same time that the invoice reconciliation is created, so that the approximate
payment information is available for payment forecasting even before the invoice reconciliation is approved.

These classes are called for both direct payments and AN payments.

Payment Scheduler
The payment scheduler reads a payment request object, checks the payment terms, and executes logic to
choose expected payment dates based on the data on the payment request.

The payment scheduler is a Java class. The default configuration supplies a standard implementation of the
payment scheduler, which implements basic payment scheduling. If you want to customize the scheduling
logic, you can replace the default implementation with a custom Java class.

Default Payment Scheduler

The default implementation of the payment scheduler, ariba.payment.AribaPaymentScheduler, reads a date
from the payment request and sets the payment schedule based on that date. The default implementation uses
the ApprovedDate on the invoice reconciliation, and adds to that a configurable number of days of “padding.”

For each payment term on a payment request, the default scheduler does the following:
1 Finds the date field specified by the PaymentTermsEffectiveDateField group. In the default configuration,
the date field is InvoiceReconciliation.ApprovedDate:
<group name="PaymentTermsEffectiveDateField">
<groupClass name="ariba.invoicing.core.InvoiceReconciliation">
<groupField name="ApprovedDate"/>
</groupClass>
</group>

2 Adds the number of skip days (“padding”) specified by the

Application.Settlement.PaymentTermsEffectiveDateSkipDays parameter.
3 Sets the payment due date to that date.

44 Ariba Payment Implementation Guide

Chapter 7 Local and AN Payments Payment Schedules and Discounts

Configuration of AribaPaymentScheduler
You can tailor the default configuration by changing the date field or by changing the number of days of
padding.
• To change the field, create a metadata XML extension file such as the following:
<inGroup name="PaymentTermsEffectiveDateField">
<inGroupClass name="ariba.invoicing.core.InvoiceReconciliation">
<remove>
<groupField name="ApprovedDate"/>
</remove>
<groupField name="SomeOtherDate"/>
</inGroupClass >
</inGroup >

This extension removes the field used in the default configuration and replaces it with a different field. For
example, you might calculate the effective date from the goods received date, the invoice created data, or
the invoice approved date.
If there is more than one field in this group, the one with the lowest Rank is used.
• To change the number of skip days (“padding”), set the
Application.Settlement.PaymentTermsEffectiveDateSkipDays parameter. In the default configuration,
this parameter is set to 0.

Custom Payment Scheduler in Java

If the default payment scheduler does not fit your needs, you can replace it with a custom Java
implementation specified in config/Parameters.table.

 To implement a custom payment scheduler class:

1 Write a Java implementation, either by subclassing ariba.payment.AribaPaymentScheduler or by
implementing ariba.payment.core.PaymentScheduler.
2 Specify the name of your class as the value of the Application.Settlement.PaymentScheduler parameter.

For more information on PaymentScheduler and AribaPaymentScheduler, see the Javadoc.

Payment Discount Selector

The payment discount selector determines what discounts are available, based on the specified payment
schedules and dates. The payment discount selector is called just after the payment scheduler, whenever the
scheduler is called.

The payment discount selector determines what discounts apply and sets the discount field of the payment
schedule accordingly. For example, the payment discount selector can choose the payment schedule with the
maximum discount, or compare dates and payment schedules to choose the best discount available at the
specified time.

The payment discount selector is a Java class. The default configuration supplies a default discount selector
that provides several possible modes for choosing discounts. If you require more sophisticated discounting
logic, you can replace the default implementation with a custom Java class.

Ariba Payment Implementation Guide 45

Payment Schedules and Discounts Chapter 7 Local and AN Payments

Default Implementation
The default implementation of the payment discount selector is
ariba.payment.AribaPaymentDiscountSelector. This class defines three modes for choosing a discount
schedule. You specify your preferred mode by setting the
Application.Settlement.PaymentDiscountSelectionPolicy parameter. The possible values for this
parameter are as follows:
• TakeDiscountNone, which selects the payment schedule corresponding to the net term, with no discounts
applied.
• TakeDiscountMaximum, which selects the payment schedule that offers the largest discount.
• TakeDiscountApplicable, which selects a payment schedule based on the transaction date, using the best
discount that is available for the given transaction date.

Custom Discount Selector

If the default discount selector does not fit your needs, you can replace it with a custom Java
implementation.

 To implement a custom discount selector class:

1 Write a Java implementation, either by subclassing AribaPaymentDiscountSelector or by implementing
ariba.payment.core.PaymentDiscountSelector.

2 Specify the name of your class as the value of the Application.Settlement.PaymentDiscountSelector

parameter.

For more information on how to implement the PaymentDiscountSelector API, see the Javadoc.

Line Types for Discounts

Each line item on an invoice has an associated line type category, which identifies the kind of data being
stored on that line item. The default configuration defines several standard line item categories, such as:
• 1, for all line items, including non-catalog, catalog, and PunchOut
• 2, for tax-related charges

For a complete list of the standard line type categories, see the Ariba Invoice Implementation Guide.

In the default configuration, only line items of category 1 are considered when calculating discounts and
evaluating payment terms. For example, if the payment terms offer a discount based on when the net amount
is paid, Ariba Payment uses only standard line items (and not tax charges, freight charges, or other line item
categories) to calculate the net amount.

To include additional line type categories in discount calculations, set the

Application.Settlement.PaymentTermsLineTypeCategories parameter. The value of this parameter is a
vector of line item category types. In the default configuration, the value is:

PaymentTermsLineTypeCategories = ("1");

To add additional line item categories, add additional line item category numbers to the vector. For example:

PaymentTermsLineTypeCategories = ("1", "3");

46 Ariba Payment Implementation Guide

Chapter 7 Local and AN Payments Payment Aggregation

Payment Aggregation
When the payment model is Local, Ariba Settlement handles payment aggregation, using the
PaymentAggregator scheduled task (display name “Payment Request Aggregator”). If the payment model is
AN, the payment request is sent to AN and any payment aggregation is handled by AN.

The PaymentAggregator scheduled task queries for all payment requests with the status of Scheduled, and
creates associated payment transactions for those requests.

In the default configuration, the payment aggregator groups together payment requests if they have the same
supplier location and the same payment method. You can configure that behavior by specifying different
fields to group or you can replace the payment aggregator altogether with a custom Java class of your own.

Default Payment Aggregator

The payment aggregator runs as the PaymentAggregator scheduled task. In the default configuration, the
PaymentAggregator scheduled task groups together any payment requests that have the same supplier
location and same payment method type.

In the default configuration, this scheduled task runs once a day.

Credit Memo Handling

A credit memo is a payment request that represents an amount due to be credited. Suppliers can potentially
issue credit memos for a variety of reasons, such as shipments lost in transit, price corrections, changes in
freight charges, service contract changes, or returned items.

In the default configuration, the payment aggregator recognizes credit memos and aggregates them against
payments, as appropriate. The aggregator uses as much of the credit as possible, but never lets the net to go
below $0.

For example, if you have a payment request for -$100 and one for $40, the aggregator does the following:
• Creates a payment transaction for $0 that includes -$40 from the first payment request and $40 from the
second
• Creates a separate payment request for $-60 to reflect the balance

Tax Accrual Payment Requests

Payment request documents can also be used to keep track of tax accrual amounts, which record tax
payments your company must make to the government. Tax accrual payment requests are not visible in the
user interface, are not sent to AN, and are not picked up by the payment aggregator. If you need to use tax
accrual payment requests, you can create custom Java code to pick them up and do any appropriate back-end
processing.

For more information on tax accrual documents, see the Ariba Invoice Implementation Guide.

Ariba Payment Implementation Guide 47

Payment Aggregation Chapter 7 Local and AN Payments

Configuring the Payment Aggregator

The default scheduled task configuration file entry for the payment aggregator is as follows:

PaymentAggregator = {
ScheduledTaskClassName = ariba.payment.AggregatePaymentsTask;
AggregationFieldsGroup = "PaymentAggregationGroup";
PaymentAggregatorClass = "ariba.payment.AribaPaymentAggregator";
Schedules = { ...};
};

The AggregationFieldsGroup parameter specifies the name of a group. The fields in that group determine
which requests can be aggregated. The default configuration uses the group PaymentAggregationGroup, which
includes the following fields:

<group name="PaymentAggregationGroup">
<groupClass name="ariba.payment.core.Payment">
<groupField name="RemittanceLocation">
<properties rank="100"/>
</groupField>
<groupField name="PaymentMethodType">
<properties rank="90"/>
</groupField>
</groupClass>
</group>

If all fields defined in the group have the same value, the payment requests are aggregated. When multiple
fields are specified, as in this example, the Rank property determines the order of aggregation.

You can add and remove fields from this group, or change the rank of existing fields to change the order in
which they are aggregated.

Customizing the Payment Aggregator

To modify the logic used in aggregating payments, you can create a custom Java class, and use that custom
class as input to the payment aggregator scheduled task.

You supply the Java class that does payment aggregation with the PaymentAggregatorClass parameter to the
scheduled task. In the default configuration, this parameter is set as follows:

PaymentAggregator = {
ScheduledTaskClassName = ariba.payment.AggregatePaymentsTask;
AggregationFieldsGroup = "PaymentAggregationGroup";
PaymentAggregatorClass = "ariba.payment.AribaPaymentAggregator";
Schedules = { ...};
};

To create a custom payment aggregator, you can do either of the following:

• Subclass AribaPaymentAggregator and override the canAggregate method. From this method, you can
replace the logic of which payment requests are aggregated.
• Implement ariba.payment.core.PaymentAggregator, which is an abstract class, If you implement your
own class, you can provide custom logic for selecting which payment requests are to be scheduled.

For details on AribaPaymentAggregator and PaymentAggregator, see the Javadoc.

48 Ariba Payment Implementation Guide

Chapter 7 Local and AN Payments Payment Disbursement

Payment Disbursement
When the payment model is Local, Ariba Settlement handles payment aggregation, using the
DisbursementCreator scheduled task. This task applies only with the Local payment model.

The DisbursementCreator scheduled task (display name “Payment Disbursement Creator”) processes
payment transaction documents and then writes the data in them to a database staging table,
DisbursementData, where it can be pushed to your G/L.

When the data is in the staging table, Ariba Payment does not process it further. You must implement the
payment yourself, using any technique appropriate for your configuration. For example, you could write the
data to a flat file, or send it to a check printer.

In the default configuration, the DisbursementCreator task does not run on a regular schedule. Because this
task can potentially affect your G/L, by pushing payments, it is typically best to have an administrative user
run the task manually. If you prefer to run it on a schedule, you must enter the schedule in the
ScheduledTasks.table file.

Configuration File Entry

The DisbursementCreator scheduled task reads data from a payment transaction object and writes it to
database columns. It always writes the following fields:

ProcessedID
PaidAmounts.NetAmount
PaidAmounts.GrossAmount
PaidAmounts.DiscountAmount
PaidAmounts.AdjustmentAmount

In the scheduled task configuration file, you can define additional optional fields to include in the data push.
The scheduled tasks takes two parameters: one that lists the data to be pushed and another that lists the
columns into which the data is to be stored. For example:

DisbursementCreator = {
ScheduledTaskClassName = ariba.payment.DisbursementCreator;
ColumnNames =
"PaymentTransactionId,PaymentDate,PaymentNumber,PaymentMethodType,SupplierName,SupplierBankName,S
upplierBankID,SupplierBankIDType,SupplierBankAccountID,SupplierBankAccountType,SupplierBankInfoSt
reetAddress,SupplierBankInfoAddressCity,SupplierBankInfoAddressState,SupplierBankInfoAddressCount
ry,SupplierRemitToStreetAddress,SupplierRemitToAddressCity,SupplierRemitToAddressState,SupplierRe
mitToAddressCountry";
Columns =
"UniqueName,PaymentDate,PaymentNumber,PaymentMethodType.UniqueName,SupplierLocation.Name,Supplier
BankInfo.BankName,SupplierBankInfo.BankID,SupplierBankInfo.BankIDType.UniqueName,SupplierBankInfo
.BankAccountID,SupplierBankInfo.BankAccountType.UniqueName,SupplierBankInfo.BankAddress.Lines,Sup
plierBankInfo.BankAddress.City,SupplierBankInfo.BankAddress.State,SupplierBankInfo.BankAddress.Co
untry.UniqueName,SupplierRemitToAddress.Lines,SupplierRemitToAddress.City,SupplierRemitToAddress.
State,SupplierRemitToAddress.Country.UniqueName";
}

The ColumnNames parameter specifies a list of column names in the database. (All columns are created as
VARCHAR.) The Columns parameter defines the fields of the payment transaction object that are used to
populate those columns. In both cases, the value is a comma-separated list of column names.

Ariba Payment Implementation Guide 49

Scheduled Tasks for Processing Local Payments Chapter 7 Local and AN Payments

In the Columns parameter, each value is the name of a field on PaymentTransaction, defined with dot notation.
In the previous example, the first field is as follows:

ColumnNames="PaymentTransactionId"
Columns="UniqueName"

In this case, the value of the UniqueName is written to the database column PaymentTransactionId.

Note: If you edit the Columns parameter to change or remove any columns, you must ask your database
administrator to remove the database table DisbursementData manually. The next time the task runs, it
recreates the table with the correct columns.

Each time the task runs, it sets the ProcessedID field on the payment transaction, to indicate which payments
have been pushed. Subsequent runs of the scheduled task ignore any payment transaction that have already
been pushed.

Scheduled Tasks for Processing Local Payments

This section describes other scheduled tasks that are used for processing local payments. These scheduled
tasks are used only in the Local payment model, and do not apply if payment is handled externally.

ProcessingPaymentRequests
The ProcessPendingPaymentRequests scheduled task (display name “Process Pending Payment Requests”)
queries for all payment requests that have reached the scheduled payment date. The status of any request that
has passed its scheduled date is changed from Scheduling to Scheduled.

Before processing a payment request, the ProcessPendingPaymentRequests task validates all fields specified
in the group PaymentRequestValidationGroup. If any fields in this group are invalid, the payment request is
not scheduled. In this case, ProcessPendingPaymentRequests writes a log message to the log category
payment/debug, indicating that the request was not scheduled because it contained invalid fields. A payment
administrator must modify the request to fix the invalid fields before the payment can be successfully
scheduled.

This scheduled task takes no parameters.

ProcessPaidPaymentTransactions
The ProcessPaidPaymentTransactions scheduled task (display name “Process Paid Payment Transactions”)
moves payment requests from Paid to Cleared.

The payment’s status transitions from Paid to Cleared after a specified number of days. The number of days
to wait between Paid and Cleared depends on the payment method, and is specified in the
PaymentMethodPull integration event. For more information about PaymentMethodPull, see “Integration
Events for Payment Methods” on page 27.

In the default configuration, this task runs once a day. It takes no parameters and requires no configuration.

50 Ariba Payment Implementation Guide

Chapter 8 Remittance Advice

• “About Remittance Advice” on page 51

• “Pulling Remittance Advice from an ERP System” on page 52
• “Pulling Remittance Advice from AN” on page 53
• “Pulling Remittance Advice in a CSV Partition” on page 53
• “IntegrationPostLoadPaymentTransaction Trigger” on page 58

About Remittance Advice

Remittance advice is an electronic document that provides details about a payment that has been made, such
as the payment method used, the invoices covered, and the amount of the payment.

Remittance advice is created when the payment is made and provides detailed information about the
payments.

Remittance Pull
If payment was made in AN or on an ERP system, Ariba Payment loads remittance advice into Ariba
Payment and uses it to create payment transaction documents.

When remittance information is pulled from an ERP system, the remittance pull can create new documents
to reflect differences between the ERP payments and the payment requests in Ariba Payment. For example,
if the remittance advice indicates that the original invoice was underpaid, Ariba Payment creates a new
payment transaction or updates a payment request with a new transaction. Similarly, if the remittance advice
indicates that a payment was canceled on the ERP system, Ariba Payment creates a new payment request to
handle the canceled amount.

When new payment requests are created during remittance pull to handle partial payments or cancelled
payments, the new requests have the same name as the original parent request, with a suffix. For example, if
the original payment request is PAY123, a request created to track partial payment might be PAY123-1.

Remittance Post
When a payment is handled within Ariba Payment (direct payment), Ariba Payment sends (posts) the
remittance advice to AN.

To send remittance advice to AN, Ariba Payment uses a send method defined in
System.Settlement.PaymentTransactionSendMethods. In the default configuration, the remittance send
method uses ariba.payment.cxml.AribaNetworkCXMLPaymentRemittanceSender to send cXML documents
over the cXML channel. To be able to send remittance advice to AN, you must make sure that this send
method is correctly configured. For more information about send methods, see “AribaPay Configuration” on
page 22.

Ariba Payment Implementation Guide 51

Pulling Remittance Advice from an ERP System Chapter 8 Remittance Advice

Note: If the supplier on a payment request does not contain credentials for AN, the remittance advice is not
sent to AN.

Pulling Remittance Advice from an ERP System

You transfer remittance advice from your Oracle or PeopleSoft system into CSV files, and then run the
RemittanceImport integration event (display name “Import Remittance”) to import the CSV files into Ariba
Payment through the Ariba File Channel.

For SAP configurations that use the Ariba File Channel, you transfer remittance advice from your SAP
system into CSV files, and then run the RemittanceFileImport integration event (display name “Import
Remittance Transaction Data”) to import the CSV files into Ariba Payment.

For SAP configurations that use the Ariba Web Services Channel, the RemittanceImport integration event
pulls remittance data in Ariba Payment.

For more information, see the Ariba Buyer ERP integration guide for your ERP system:
• Ariba Buyer PeopleSoft Integration Guide
• Ariba Buyer SAP Integration Guide
• Ariba Buyer Oracle Financials Integration Guide

IncrementalRemittanceImport Scheduled Task

The IncrementalRemittanceImport scheduled task (display name “Incremental Remittance Import”)
incrementally loads remittance advice from an SAP system.

Following is a sample definition for IncrementalRemittanceImport:

IncrementalRemittanceImport = {
ScheduledTaskClassName = "ariba.integration.core.IncrementalIntegrationEventTask";
DefaultStartDate = "20080901000000";
LoggingName = "IncrementalRemittanceImport";
Variant = @variant@;
Partition = @partition@;
Event = RemittanceImport;
};

The parameters specific to this scheduled task are as follows:

• DefaultStartDate, which specifies the start date for the incremental import.
• LoggingName, which specifies the logging name.
• Variant, which specifies the name of the variant.
• Partition, which specifies the name of the partition.
• Event, which specifies the name of the integration event that imports that remittance data.

52 Ariba Payment Implementation Guide

Chapter 8 Remittance Advice Pulling Remittance Advice from AN

Pulling Remittance Advice from AN

If your configuration sends payment requests to AN, you use the CXMLPaymentRemittanceLoader
scheduled task (display name “Payment Remittance Loader (cXML)”) to retrieve remittance advice from
AN. This scheduled task retrieves payment remittance advice (documents with cXML document type
PaymentRemittance) from AN.

Following is a sample definition for CXMLPaymentRemittanceLoader:

CXMLPaymentRemittanceLoader = {
ScheduledTaskClassName = "ariba.payment.cxml.CXMLPaymentRemittanceLoader";
MaxMessages="10";
MaxRequests="1";
Schedules = { Schedule1 = { DayOfWeek = Everyday; Hour = 4;};};
};

The MaxMessages and MaxRequests parameters are used for performance tuning:
• MaxMessages specifies the maximum number of cXML documents that can be retrieved during each get
pending transaction.
• MaxRequests specifies the maximum number of times to repeat the get pending transaction while tying to
empty the AN pending queue.

In the default configuration, the scheduled task entry for the CXMLPaymentRemittanceLoader is in the
global scheduled task configuration file, config/variants/Plain/partitions/None/ScheduledTasks.table. If
you want different parameters for different partitions, move the entry to partition-specific scheduled task
files.

Pulling Remittance Advice in a CSV Partition

If you have a CSV partition, you can load remittance advice with the RemittanceCSVImportLoader
scheduled task (display name “Payment Remittance Loader (CSV)”). This task searches in a specified
directory for new remittance files. If it finds new files, it calls an associated integration event to read the file.

To set up your configuration, you define the parameters for this scheduled task to specify where to find
remittance data files and what format to expect in the data files.

RemittanceCSVImportLoader ScheduledTask
The RemittanceCSVImportLoader scheduled task runs in a CSV partition. The following example shows a
typical configuration file entry for this task:

RemittanceCSVImportLoader = {
Adapter = RemittancePull;
FailedToProcessFolder = "transactionData/remittance/errors";
IncomingFolder = "transactionData/remittance/incoming";
ProcessedFolder = "transactionData/remittance/processed";
ScheduledTaskClassName = ariba.payment.RemittanceCSVImportLoader;
Schedules = { Schedule1 = { DayOfWeek = Weekday; Hour = 0;};};
};

Ariba Payment Implementation Guide 53

Pulling Remittance Advice in a CSV Partition Chapter 8 Remittance Advice

The remittance loader looks in the specified IncomingFolder for incoming remittance data files. If there are
any new data files in that directory, the remittance loader calls the integration event specified in Adapter for
each new data file.

The parameters specific to this scheduled task are as follows:

• Adapter, which names the integration event that is called to process the incoming data. For more
information, see “RemittancePull Integration Event” on page 54.
• IncomingFolder, which defines where the remittance loader looks for new statement files.
• ProcessedFolder, which defines where the remittance loader moves statement files after they have been
loaded.
• FailedToProcessFolder, which defines where the remittance loader moves statement files if there were
errors loading those files. For more information on error handling, see “Scheduled Task Error Handling”
on page 54.

Scheduled Task Error Handling

If the RemitanceCSVImportLoader scheduled task cannot successfully read an incoming CSV file, it moves
that CSV file into the directory specified as the FailedToProcessFolder, and sends the Notification of
Remittance Load Failure message to users who have the PaymentManager permission. The notification
message lists each of the files that failed. The administrator must correct each error.

 To correct remittance import errors:

1 Review the log file, looking for errors logged to the payment log category.

2 Determine the cause of the error.

3 Fix the data errors.

4 Move the input file back into the incoming folder.

5 Re-run the scheduled task.

RemittancePull Integration Event

The RemittancePull integration event is always run from the RemittanceCSVImportLoader scheduled task.
You never run it directly.

The RemittancePull integration event is a header-details event. It reads the list of payment documents from
the header file and the details about each payment from the details file. Following is the message
configuration entry for RemittancePull in the default configuration:

RemittancePull = {
ApplicationHints = {
Parameters = {
Feature = ( AribaP2PBasic, AribaP2PProfessional, AribaSettlement );
Visible = true;
};
};
Channel = {};
LoggingName = Remittance_CSV;
MessageParameters = {
Request = {
Parameters = {

54 Ariba Payment Implementation Guide

Chapter 8 Remittance Advice Pulling Remittance Advice in a CSV Partition

Details = (
{
DetailFileName = "";
JoinFields = ( "LookupID = LookupID" );
ParentField = LineItems;
}
);
EventSource = "pcsv:Remittance.csv";
HeaderFileName = "";
Operation = Load;
};
SchemaName = ariba.integration.HeaderDetailSchema;
};
};
TopicName = RemittancePull;
};

The header file can have any name, but the details file must be of the form headernameDetails, such as
RemittanceDetails.csv. The header file and detail file are joined by the field LookupID. You can find sample
files with correctly formatted data in the following directory:

sample/invoicing/remittanceimport/Remittance.csv

Both files must reside in the directory specified by the IncomingFolder parameter in the
RemitanceCSVImportLoader scheduled task. In the default configuration, the directory is
transactionData/remittance/incoming.

Header File Fields

The fields in the header file are as follows:

Field Description
LookupID The ID used to look up the payment approvable document. The ID can be a
concatenation of several IDs to make it unique in the ERP system. This value
is used primarily to pull remittance information from the ERP system.
SupplierLocation The location of the supplier to whom the payment is made.
SupplierLocationContactID The contact ID of the supplier to whom the payment is made.

PaymentNumber The payment number. For example, this value would be a check number if the
payment method is check.

ExternalProcessedState The status of the payment transaction, as reported by the ERP system. The
valid values are:

0, which indicates paid.

1, which indicates canceled.

GrossAmountDefaultCurrency The gross amount default currency, for example, USD.

GrossAmount The gross amount.

DiscountAmountDefaultCurrency The discount amount default currency, for example, USD.

DiscountAmount The discount amount.

AdjustmentAmountDefaultCurrency The adjustment amount default currency, for example, USD.

AdjustmentAmount The adjustment amount.

Ariba Payment Implementation Guide 55

Pulling Remittance Advice in a CSV Partition Chapter 8 Remittance Advice

Field Description
NetAmountDefaultCurrency The net amount default currency, for example, USD.

NetAmount The net amount.

CreatedDate The date the payment transaction was created, for example, 1-1-2003.

PaymentDate The payment date, for example, 1-1-2003.

CanceledDate The date the payment transaction was canceled, for example, 1-1-2003.

PaymentMethodType The payment method type used. The value must match a UniqueName
specified in the PaymentMethodType.csv file, such as check.

BuyerBankAddressName The name of the buyer’s bank.

BuyerBankAddressStreet The street address of the buyer’s bank.

BuyerBankAddressCity The city of the buyer’s bank.

BuyerBankAddressState The state of the buyer’s bank.

BuyerBankAddressPostalCode The ZIP or postal code of the buyer’s bank.

BuyerBankAddressCountry The country of the buyer’s bank.

BuyerBankName The name of the buyer’s bank.

BuyerBankID The buyer’s bank ID.

BuyerBankIDType The buyer’s bank ID type. The value must match a UniqueName specified in
the BankIDType.csv file, for example, ABA.

BuyerBankAccountID The buyer’s bank account ID.

BuyerBankAccountIDType The buyer’s bank account ID type. The value must match a UniqueName
specified in the BankAccountIDType.csv file, such as national.
BuyerBankAccountType The buyer’s bank account type. The value match a UniqueName specified in
the BankAccountType.csv file, such as checking.
SupplierBankAddressName The name of the supplier’s bank.
SupplierBankAddressStreet The street address of the supplier’s bank.

SupplierBankAddressCity The city of the supplier’s bank.

SupplierBankAddressState The state of the supplier’s bank.

SupplierBankAddressPostalCode The ZIP or postal code of the supplier’s bank.

SupplierBankAddressCountry The country of the supplier’s bank.

SupplierBankName The name of the supplier’s bank.

SupplierBankID The supplier’s bank ID.

SupplierBankIDType The supplier’s bank ID type. The value must match a UniqueName specified
in the BankIDType.csv file, such as ABA.

SupplierBankAccountID The supplier’s bank account ID.

SupplierBankAccountIDType The supplier’s bank account ID type. The value must match a UniqueName
specified in the BankAccountIDType.csv file, such as national.

SupplierBankAccountType The supplier’s bank account type. The value must match a UniqueName
specified in the BankAccountType.csv file, such as checking.

56 Ariba Payment Implementation Guide

Chapter 8 Remittance Advice Pulling Remittance Advice in a CSV Partition

The following example shows lines from a typical header file:

"PMT-1001","36","34","CHK1234","0","USD","1000","USD","200","USD","100","USD","700","1-1-2003","1
-1-2003","","Check","Wells Fargo Bank","123 First St","San Francisco","CA","94353","US","Wells
Fargo Bank","123456789","ABA","12345","national","checking","Bank Of America","123 Second
St","Hollywood","CA","90210","US","Bank Of
America","987654321","ABA","54321","national","checking"
"PMT-1002","36","34","ACH1234","0","USD","2000","USD","400","USD","200","USD","1400","1-1-2003","
1-1-2003","","ACH","Wells Fargo Bank","123 First St","San Francisco","CA","94353","US","Wells
Fargo Bank","123456789","ABA","12345","national","checking","Bank Of America","123 Second
St","Hollywood","CA","90210","US","Bank Of
America","987654321","ABA","54321","national","checking"

Details File Fields

The fields in the detail file are as follows:

Field Description
LookupID The ID used to look up the payment approvable document. The
ID can be a concatenation of several IDs to make it unique in
an ERP system. This value is used primarily to pull remittance
information from an ERP system.

This lookup ID must match a lookup ID defined in the

Remittance.csv header file.

NumberInCollection The collection number.

PayableDate The date of the invoice, for example, 1-1-2002.

PayableReferenceNumber The reference number for the invoice, for example, IR-1.

PayableType In this release, this field must be set to 1, which specifies

invoice.

ExternalPayableReferenceNumber The invoice reference number from the ERP system, for
example, ERP-INV-1.
SupplierPayableReferenceNumber The invoice number known to the supplier, for example,
SUP-INV-1.

SecondaryPayableReferenceNumber The reference number of the associated purchase order, for

example, PO-1.

SecondaryPayableType In this release, this field must be set to 2, which specifies a

purchase order.
ExternalSecondaryPayableReferenceNumber The purchase order reference number from the ERP system, for
example, ERP-PO-1.

GrossAmountDefaultCurrency The gross amount default currency, for example, USD.

GrossAmount The gross amount.

DiscountAmountDefaultCurrency The discount amount default currency, for example, USD.

DiscountAmount The discount amount.

AdjustmentAmountDefaultCurrency The adjustment amount default currency, for example, USD.

AdjustmentAmount The adjustment amount.

Ariba Payment Implementation Guide 57

IntegrationPostLoadPaymentTransaction Trigger Chapter 8 Remittance Advice

Field Description
NetAmountDefaultCurrency The net amount default currency, for example, USD.

NetAmount The net amount.

The following example shows lines from a typical details file:

"PMT-1001","1","1-1-2002","IR-1","1","ERP-INV-1","SUP-INV-1","PO-1","2","ERP-PO-1","USD","600","U
SD","100","USD","50","USD","450"
"PMT-1001","2","1-1-2002","IR-2","1","ERP-INV-2","SUP-INV-2","PO-2","2","ERP-PO-2","USD","400","U
SD","100","USD","50","USD","250"
"PMT-1002","1","1-1-2002","IR-3","1","ERP-INV-3","SUP-INV-3","PO-3","2","ERP-PO-3","USD","1600","
USD","100","USD","50","USD","1450"
"PMT-1002","2","1-1-2002","IR-4","1","ERP-INV-4","SUP-INV-4","PO-4","2","ERP-PO-4","USD","1400","
USD","100","USD","50","USD","1250"

IntegrationPostLoadPaymentTransaction Trigger
After Ariba Payment pulls remittance advice from an external system, it fires the trigger action
ariba.payment.core.IntegrationPostLoadPaymentTransaction. This trigger updates associated payment
transaction documents to reflect the information on the remittance advice. The trigger can potentially create
new payment request documents if there is a discrepancy between the remittance invoice and the original
payment request.
• If the remittance advice indicates partial payment, the trigger creates new payment request documents to
track the outstanding amount that is still to be paid.
• If the remittance advice indicates that the payment was approximately correct, or overpaid, the trigger
updates the payment transaction document to reflect the payment that was made.
• If the remittance advice indicates that the payment was canceled, the trigger updates the status in Ariba
Payment to indicate that the payment has been canceled, and creates a new payment request to reflect the
unpaid balance.

Currency Considerations
In typical business practices, the same currency is used for invoice and payment. For situations where the
currencies do differ, the IntegrationPostLoadPaymentTransaction trigger action uses a method called
processPaymentInDifferentCurrency to convert the amounts on the invoice reconciliation to the payment
currency before determining whether the invoice has been correctly paid.

The method signature is as follows:

protected void processPaymentInDifferentCurrency (

PaymentTransaction payment,
InvoiceReconciliation ir,
PaymentAmounts paidAmounts)

The default implementation looks at the paidAmounts parameter (which contains the amounts on the invoice
reconciliation), converts them to the currency used on the payment, and then sets the amounts on the invoice
to the converted value.

58 Ariba Payment Implementation Guide

Chapter 8 Remittance Advice IntegrationPostLoadPaymentTransaction Trigger

For example, typical logic to convert the gross amount is:

Currency payableCurrency = ir.getReportingCurrency();

Date paymentDate = payment.getPaymentDate();

Money gross = paidAmounts.getGrossAmount();

BigDecimal convertedGross = gross.convertAmount(payableCurrency, paymentDate);
gross.setAmount(convertedGross);

If you require custom logic for this situation, you can create your own trigger action implementation that
subclasses IntegrationPostLoadPaymentTransaction and overrides the processPaymentInDifferentCurrency
method.

For detailed information on the API, see the Javadoc.

Ariba Payment Implementation Guide 59

IntegrationPostLoadPaymentTransaction Trigger Chapter 8 Remittance Advice

60 Ariba Payment Implementation Guide

Chapter 9 Administration

• “Ariba Administrator Workspaces and Tasks” on page 61

• “Log Message Categories” on page 62
• “Common Administration Tasks” on page 62

Ariba Administrator Workspaces and Tasks

The following table describes the workspaces and tasks in Ariba Administrator for managing payment data,
modifying payment-related parameters, and running payment-related scheduled tasks. The Required
Permission column shows the permissions that can access each task.

Workspace and Task Use this task to ... Required Permission

Server Manager One of the following:
• SiteAdmin.ConfigurationFiles
• SiteAdmin.AdminClient
• ScheduledTasks
• IntegrationEvents
• ParametersEditor
• SiteAdmin.LogFilesAndSettings
• UserSessions

Parameters View and edit parameters. One of the following:

• ParametersEditor
• SiteAdmin.ConfigurationFiles
Data Import/Export Run integration events. One of the following:
• IntegrationEvents
• SiteAdmin.AdminClient
Scheduled Tasks Run scheduled tasks. One of the following:
• ScheduledTasks
• SiteAdmin.AdminClient
Log Settings Change logging levels for individual log One of the following:
categories. • SiteAdmin.LogFilesAndSettings
• SiteAdmin.ConfigurationFiles
Log Files View log messages in the main log file. One of the following:
• SiteAdmin.LogFilesAndSettings
• SiteAdmin.AdminClient
Customization Manager One of the following:
• RuleEditor
• SiteAdmin.TemplateEditor
• SiteAdmin.ClassEditor
Rule Editor View, add, modify, and delete approval RuleEditor
rules.

Procure-to-Pay Manager P2PAdminAccess

Ariba Payment Implementation Guide 61

Log Message Categories Chapter 9 Administration

Workspace and Task Use this task to ... Required Permission

Payment Methods View, add, modify, and delete payment One of the following:
methods. • PaymentAdministrator
• PaymentManager
Payment Terms View, modify, and delete payment terms. One of the following:
• PaymentAdministrator
• PaymentManager
Payment Bank Locations View, add, modify, and delete payment One of the following:
bank locations. • PaymentAdministrator
• PaymentManager
Supplier Payment View supplier payment information, add One of the following:
Information and modify remittance locations for • PaymentAdministrator
supplier locations, and add and modify • PaymentManager
payment methods for remittance locations.

Log Message Categories

Ariba Payment writes log messages to log message categories. To help diagnose problems with payments,
consider turning on debugging for one or more of the following categories:

Category Description
aribanetwork Log messages for status updates sent to AN.
application.procurement.payment Debugging and diagnostic messages related to payment approvables.
application.paymentTerms Log messages specific to payment terms.

Common Administration Tasks

This section describes how to perform some common administration tasks in Ariba Administrator.

Adding or Modifying Payment Methods

You use the Payment Methods task in the Procure-to-Pay Manager workspace to add and modify payment
methods.

For more information on payment methods, see Chapter 4, “Payment Methods.”

62 Ariba Payment Implementation Guide

Chapter 9 Administration Common Administration Tasks

 To add or modify a payment method:

1 Click Create New to create a new payment method, or select the payment method you want to modify and
click Edit.
2 Enter or modify information about the payment method on the Add Payment Method or Edit Payment
Method page. The following table describes the fields on those pages.

Field Description
Payment Method Name The unique internal identifier of the payment method. You cannot modify this field in
edit mode.

Description The user-visible description for the payment method.

Clearance The number of days after which a payment made with this payment method is considered
cleared.

Electronic Payment Whether this is an electronic payment method.

Preferred Whether this is the preferred payment method.

Payment Method Type The AN canonical payment method that corresponds to the payment method. Choose
other for third-party financing payment methods.

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

Adding or Modifying Payment Methods for Supplier Locations

You use the Supplier Payment Information task in the Procure-to-Pay Manager workspace to add and modify
payment models for supplier locations.

For more information on payment methods, see Chapter 4, “Payment Methods.”

 To add or modify a payment method for a supplier:

1 Click the triangle icon next to a supplier name, and then click Payment Info for the supplier location. The
Remittance Locations page appears.
2 Click Edit next to the remittance location. The Add Remittance Locations page appears.

3 Click Add to add a payment method, or click Edit to modify a payment method. The Review Details for
Payment Method page appears.
4 Choose or modify the payment method.

5 Choose or modify the bank information. The bank information you choose must match the bank
information configured for the supplier on AN.
If no bank information exists in the chooser, you have not created any supplier bank locations.
If you choose a credit card as the payment method, the Bank Information menu changes to Buyer PCard
Number and you can select a ghosted purchasing card number:

6 Click OK to save your changes, or Cancel to return to the previous page without saving your changes.

Ariba Payment Implementation Guide 63

Common Administration Tasks Chapter 9 Administration

Modifying Payment Terms

You use the Payment Terms task in the Procure-to-Pay Manager workspace to modify payment terms.

For more information on payment terms, see Chapter 6, “Payment Terms.”

 To modify a payment term:

1 Select the payment term you want to modify and click Edit. You can edit the following general
information:
• ID - The unique internal identifier for the payment term.
• Title - The display name of the payment term.
• Description - The user-visible description of the payment term.
2 Click Save to save your changes, or Cancel to return to the previous page without saving your changes.

Adding or Modifying Remittance Locations for Supplier Locations

You use the Supplier Payment Information task in the Procure-to-Pay Manager workspace to add and modify
remittance locations for supplier locations.

For more information on remittance locations, see Chapter 5, “Bank Information.”

 To add or modify a remittance location for a supplier location:

1 Click the triangle icon next to the supplier name, and then click Payment Info for the supplier location. The
Remittance Locations page appears.
2 Click Create New to create a remittance location, or click Edit to modify a remittance location. You can add
or modify the name and address information for the remittance location. You can also add or edit the
payment method associated with a remittance location. For more information, see “Adding or Modifying
Payment Methods for Supplier Locations” on page 63.

Note: When a supplier uses the AN payment model, the remittance location for the supplier must match
the remittance location configured in AN for that supplier. If the values do not match, validation errors
occur in the user interface.

3 Click OK to save your changes, or Cancel to return to the previous page without saving your changes.

Adding or Modifying Payment Models for Suppliers

You use the Supplier Payment Information task in the Procure-to-Pay Manager workspace to add and modify
payment models for suppliers.

For more information on payment models, see Chapter 3, “Payment Models and Payment Send.”

 To add or modify a payment model for a supplier:

1 Click Edit next to the supplier name.

2 Choose or modify the payment model in the Payment Model menu.

• Default—The payment model defaults to the payment model configured for the partition.
• External System—Payment requests are handled in an external system, such as an ERP system.

64 Ariba Payment Implementation Guide

Chapter 9 Administration Common Administration Tasks

• Local—Ariba Payment creates the payment with a technique of your choice. such as cutting a physical
check or pushing data to a database table. Ariba Payment handles traditional payment functionality
such as payment scheduling, discount selection, and payment disbursement.
• AN—Payment requests are sent to AN, which makes the payment.
3 Click Save to save your changes, or Cancel to return to the previous page without saving your changes.

Adding or Modifying Payment Models for Supplier Locations

You use the Supplier Payment Information task in the Procure-to-Pay Manager workspace to add and modify
payment models for supplier locations.

For more information on payment models, see Chapter 3, “Payment Models and Payment Send.”

 To add or modify a payment model for a supplier location:

1 Click the triangle icon next to the supplier name, and then click Payment Info for the supplier location.

2 In the Payment Info section, choose or modify the payment model in the Payment Model menu.
• Default—The payment model defaults to the payment model configured for the supplier. If a payment
model is not associated with the supplier, the payment model configured for the partition is used.
• External System—Payment requests are handled in an external system, such as an ERP system.
• Local—Ariba Payment creates the payment with a technique of your choice. such as cutting a physical
check or pushing data to a database table. Ariba Payment handles traditional payment functionality
such as payment scheduling, discount selection, and payment disbursement.
• AN—Payment requests are sent to AN, which makes the payment.
3 Click Save to save your changes, or Cancel to return to the previous page without saving your changes.

Adding or Modifying Bank Payment Locations

You use the Payment Bank Locations task in the Procure-to-Pay Manager workspace to add and modify
bank payment locations.

For more information on bank payment locations, see Chapter 5, “Bank Information.”

Ariba Payment Implementation Guide 65

Common Administration Tasks Chapter 9 Administration

 To add or modify a bank payment location:

1 Click Create New to create bank information, or select the payment bank location you want to modify and
click Edit.
2 Enter or modify information on the Create Payment Bank Location or Edit the Selected Payment Bank
Location Information page. For example:

In this example, the highlighted fields indicate values that must match values configured in AN for the
supplier when the supplier uses the AN payment model. If these values do not match, validation errors
occur in the user interface.
The following table describes the fields on the Create Payment Bank Location or Edit the Selected
Payment Bank Location Information pages.

Field Description
Name The name of the bank account.

Buyer Location? Check this box if the bank information is for a buyer bank. Clear this box if the bank
information is for a supplier bank.

Bank Name The name of the bank where the account resides. For a supplier bank location, this value
must match the bank name configured for the supplier on AN.

Street The street of the bank address.

City The city of the bank address.

State The state of the bank address.

Postal Code The postal code of the bank address.

Country The country of the bank address.

Bank ID The bank identifier.

Bank ID Type The bank identifier type, such as Society for Worldwide Interbank Financial
Telecommunication (S.W.I.F.T) and American Bankers Association (ABA).

Bank Account ID The bank account identifier. For a supplier bank location, this value must match the bank
account identifier configured for the supplier on AN.

66 Ariba Payment Implementation Guide

Chapter 9 Administration Common Administration Tasks

Field Description
Bank Account ID Type The bank account identifier type, such as National or International Bank Account Number
(IBAN).

Bank Account Type The bank account type, such as checking account or savings account. For a supplier bank
location, this value must match the bank account type configured for the supplier on AN.

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

Ariba Payment Implementation Guide 67

Common Administration Tasks Chapter 9 Administration

68 Ariba Payment Implementation Guide

Appendix A Groups, Roles, and Permissions

• “Required Permissions for Payment” on page 69

• “Default Roles for Payment” on page 71
• “Default Groups for Payment” on page 72

Required Permissions for Payment

This section describes the permissions required in Ariba Settlement.

EditPayment
Users who have this permission can make post-submission edits to payment request documents and add
approval requests to the approval flow for payment request documents. In the default configuration, this
permission is assigned to the following roles:
• Executive Approver
• Payment Manager

Note: You can edit payment request documents that are in the Scheduling status only. If your system is
configured to make payments through an ERP system, you cannot edit payment request documents.

ForceCancelPaymentTransaction
This permission is used for authorization. In the default configuration, this permission is assigned to the
Payment Administrator role. Users who have this permission are able to use the Force Cancel command in the
user interface to manually change the status of an payment transaction from Canceling to Canceled.

ForcePayPaymentTransaction
This permission is used for authorization. In the default configuration, this permission is assigned to the
Payment Administrator role. Users who have this permission are able to use the Force Pay command in the
user interface to manually change the status of an payment transaction from Paying to Paid.

ForceSendPayment
This permission is used for authorization. Users who have this permission are able to use the Force Send
command in the user interface to change the status of a payment request from Sending (or Failed Sending) to
Sent. For example, if a payment request was sent, but for technical reasons the status is not changing, users
with this permission can force the status to Sent. In the default configuration, this permission is assigned to
the Payment Administrator role.

Ariba Payment Implementation Guide 69

Required Permissions for Payment Appendix A Groups, Roles, and Permissions

P2PAdminAccess
Users who have this permission can access the Procure-to-Pay Manager workspace in Ariba Administrator.

PayablePushErrorEmail
Users who have this permission receive the Notification of Payment Send Failure message when a payment
send operation fails and the status of the payment document remains in Sending.

PaymentAdministrator
This permission is used for administering payment-related tasks. Users who have this permission can access
the Payment Methods, Payment Terms, Payment Bank Locations, and Supplier Payment Information tasks
in the Procure-to-Pay Manager workspace in Ariba Administrator.

Note: Users must have the P2PAdminAccess permission to access the Procure-to-Pay Manager workspace.

In the default configuration, this permission is assigned to the Payment Administrator role.

PaymentManager
This permission is used for authorization and notifications related to payments, in Ariba Settlement and
Ariba Invoice. Payment managers are users who are authorized for system administration and error handling
for payment approvable documents. Users who have this permission:
• Receive the Notification of Remittance Load Failure message when the scheduled task
RemittanceCSVImportLoader fails to load a data file successfully.
• Can access the Invoice Exception Types, Payment Methods, Procurement Line Types, Payment Terms,
Payment Bank Locations, and Supplier Payment Information tasks in the Procure-to-Pay Manager
workspace in Ariba Administrator.

Note: Users must have the P2PAdminAccess permission to access the Procure-to-Pay Manager workspace.

This permission is assigned to the Payment Manager role in the default configuration.

PaymentSendingEmail
This permission is used for notifications. In the default configuration, this permission is assigned to the
Payment Administrator role. Users who have this permission receive the Notification of Payment Send
Failure message if a payment request or payment transaction cannot successfully be sent to its intended
destination.

70 Ariba Payment Implementation Guide

Appendix A Groups, Roles, and Permissions Default Roles for Payment

QueryAllPayment
Users who have this permission can query all the payment request documents in the system. They can also
see the Payment tab for invoice reconciliation (IR) documents. In the default configuration, this permission
is assigned to the following roles:
• Invoice Administrator
• Invoice Agent
• Invoice Manager
• Payment Administrator
• Payment Manager
• Purchasing Manager
• Receiving Manager
• Tax Manager

RemoveApprovalRequestPayment
Users who have this permission can remove approval requests from the approval flow for payment request
documents. In the default configuration, this permission is assigned to the following roles:
• Executive Approver
• Payment Administrator

Default Roles for Payment

This section describes the roles provided in the default configuration for payment.

Payment Agent
This role contains the following permissions for business users who work with payments in Ariba
Settlement:
• DashboardAuthorized
• EditPayment
• ModifyCommentsAndAttachments
• PaymentSendingEmail
• P2PDashboardAuthorized
• QueryAllInvoice
• QueryAllPayment

Ariba Payment Implementation Guide 71

Default Groups for Payment Appendix A Groups, Roles, and Permissions

Payment Administrator
This role contains the following permissions for administrators who handle issues with payments in Ariba
Settlement:
• ForceCancelPaymentTransaction
• ForcePayPaymentTransaction
• ForceSendPayment
• P2PAdminAccess
• PaymentAdministrator
• PaymentManager
• PaymentSendingEmail
• QueryAllPayment
• RemoveApprovalRequestPayment

Payment Manager
A role that contains the following permissions for business process experts who handle payments in Ariba
Settlement:
• DashboardAuthorized
• EditPayment
• ModifyCommentsAndAttachments
• P2PAdminAccess
• P2PDashboardAuthorized
• PaymentManager
• QueryAllPayment

Default Groups for Payment

This section describes the groups provided in the default configuration for Ariba Settlement.

Payment Agent
This group contains the Payment Agent role.

Payment Administrator
This group contains the Payment Administrator role.

Payment Manager
This group contains the Payment Manager role.

72 Ariba Payment Implementation Guide

Appendix B Email Notification Messages

This appendix describes Ariba Payment-related notification messages. For information on notification
messages that are common to all Ariba Buyer modules, see the Ariba Buyer Configuration Guide.

About Email Notification Messages

Users receive notification messages when they are involved with an approvable document, or when they
have special permissions. The following table describes the labels used in this chapter to describe the
recipients of notification messages.

Label Description
preparer A user who prepares and submits a request.

requester The same user as the preparer, unless the preparer submits a request on behalf of another
user. In that case, the user who submits the request is the preparer, and the other user is the
requester.

watcher A user who has been assigned to observe a request. Watchers receive the same notification
messages as preparers.

approver A user who has been assigned to approve or deny a request.

delegate A user to whom an approver has delegated approval authority. Delegates receive the same
notification messages as approvers.

Ariba Payment Implementation Guide 73

Notification of Payment Send Failure Appendix B Email Notification Messages

Notification of Payment Send Failure

ID - title could not be sent

Cause:
When Ariba Settlement is unable to send a payment request or payment transaction using the designated
payment send method, it sends this notification message to users who have the PaymentSendingEmail
permission.

Action:
You can take the following actions:
• Edit the payment document and save the changes. When an approver saves changes to the payment
document, Ariba Settlement retries the payment push. Only users with the PaymentAdministrator
permission can edit payment request documents at this point.
• Use the Force Send (payment request) or Force Pay (payment transaction) command to manually change
the status to Sent. The Force* commands change the status manually, but makes no other changes. These
commands are appropriate only if you are sure that the payment document was sent in some other way.
The Force Send command is available only to users with the ForceSendPayment permission. The Force Pay
command is available only to users with the ForcePayPaymentTransaction permission.

74 Ariba Payment Implementation Guide

Appendix B Email Notification Messages Notification of Remittance Load Failure

Notification of Remittance Load Failure

Remittance CSV import failed

Cause:
The scheduled task RemittanceCSVImportLoader sends this notification message to users who have the
PaymentManager permission whenever it is unable to load a file of remittance information successfully.

For example:

Remittance csv import loader scheduled task failed to load the following files.

{IncomingFolder}/filename.xls
{IncomingFolder}/filename.xls

These files have been moved to the transactionData/remittance/errors directory. Please look at the
system log files for detailed information about the cause of failure.

Action:
Correct the data errors and move the file back into the appropriate directory for incoming remittance data,
where RemittanceCSVImportLoader can pick it up and retry.

Ariba Payment Implementation Guide 75

Notification of Remittance Load Failure Appendix B Email Notification Messages

76 Ariba Payment Implementation Guide

Appendix C Scheduled Tasks

• “About Scheduled Tasks” on page 77

• “Partitioned Scheduled Tasks” on page 77
• “Partitioned Scheduled Tasks” on page 77

About Scheduled Tasks

Ariba Settlement includes a number of invoicing-related scheduled tasks. Scheduled tasks are processes that
run on a regular basis, in the background. Most scheduled tasks are configured to run on a regular schedule,
such as once every weekday starting at midnight. If you do not want to wait for a scheduled task to run at its
regularly scheduled time, you can run it manually from Ariba Administrator.

This appendix contains Ariba Payment-related scheduled tasks. For scheduled task that are common to all
modules, see the Ariba Buyer Configuration Guide. For information on creating custom scheduled tasks, see
the Ariba Spend Management API Guide.

Partitioned Scheduled Tasks

This section describes the tasks that can operate on partitioned data. In a typical configuration, you define
the scheduled tasks for a partition in a file such as
config/variants/variant/partitions/partition/ScheduledTasks.table.

CXMLPaymentProposalLoader
CXMLPaymentProposalLoader = {
ScheduledTaskClassName = "ariba.cxml.base.client.GetPendingServiceImpl";
MessageType="CopyRequest.PaymentProposalRequest";
MaxMessages="10";
MaxRequests="1";
};

The CXMLPaymentProposalLoader scheduled task (display name “Payment Proposal Loader (cXML)”)
pulls PaymentProposalRequests between Ariba Buyer and AN, to update invoice reconciliation documents
and their associated payment request documents.

Ariba Payment Implementation Guide 77

Partitioned Scheduled Tasks Appendix C Scheduled Tasks

CXMLPaymentRemittanceLoader
CXMLPaymentRemittanceLoader = {
ScheduledTaskClassName = "ariba.payment.cxml.CXMLPaymentRemittanceLoader";
MaxMessages="10";
MaxRequests="1";
Schedules = { Schedule1 = { DayOfWeek = Everyday; Hour = 4;};};
};

The CXMLPaymentRemittanceLoader scheduled task (display name “Payment Remittance Loader

(cXML)”) retrieves payment remittance information (cXML PaymentRemittance documents) from AN.

This task recognizes the following parameters:

• MaxMessages, which specifies the maximum number of cXML documents that can be retrieved during
each get pending transaction. This parameter is set to 10 in the default configuration.
• MaxRequests, which specifies the maximum number of times to repeat the get pending transaction while
trying to empty the AN pending queue. This parameter is set to 1 in the default configuration.

CXMLProcessUndeliveredPayloads
CXMLProcessUndeliveredPayloads = {
Oldest = 3;
Units = Days;
ScheduledTaskClassName = "ariba.cxml.base.core.CXMLProcessUndeliveredPayloads";
Schedules = {
Schedule1 = {
DayOfWeek = Everyday;
Hour = 3;
Minute = 30;
};
};

The CXMLProcessUndeliveredPayloads scheduled task (display name “Process Undeliverable cXML

Documents” recovers any cXML documents that have been queued for delivery but haven’t been delivered
because the destination has been unreachable or the application server has shut down.

This task ensures delivery of the following cXML document types:

• PaymentProposalRequest
• PaymentRemittanceRequest
• PaymentRemittanceStatusUpdateRequest

In the following example, the CXMLProcessUndeliveredPayloads is configured to select messages between

one and three days old and reschedule them for reliable delivery.

{
Youngest = 1;
Oldest = 3;
Units = Days;
}

Youngest and Oldest are integer values that specify the age range of messages to select. The value is
subtracted from the current time, scaled by the Units parameter, in days, minutes, or hours.

78 Ariba Payment Implementation Guide

Appendix C Scheduled Tasks Partitioned Scheduled Tasks

DisbursementCreator
DisbursementCreator = {
ScheduledTaskClassName = ariba.payment.DisbursementCreator;
ColumnNames =
"PaymentTransactionId,PaymentDate,PaymentNumber,PaymentMethodType,SupplierName,SupplierBankName";
Columns =
"UniqueName,PaymentDate,PaymentNumber,PaymentMethodType.UniqueName,SupplierLocation.Name,Supplier
BankInfo.BankName";
}

The DisbursementCreator scheduled task (display name “Payment Disbursement Creator”) runs a query to
find payment transaction documents that have not been processed, and pushes those payment transactions to
a database staging table.

This task recognizes the following parameters:

• ColumnNames specifies database column names.
• Columns names fields of the PaymentTransaction object. Fields listed in Columns are pushed to the
corresponding column specified in ColumnNames.

In the default configuration, this task is not scheduled to run automatically.

IncrementalRemittanceImport
IncrementalRemittanceImport = {
ScheduledTaskClassName = "ariba.integration.core.IncrementalIntegrationEventTask";
DefaultStartDate = "20080901000000";
LoggingName = "IncrementalRemittanceImport";
Variant = @variant@;
Partition = @partition@;
Event = RemittanceImport;
};

The IncrementalRemittanceImport scheduled task (display name “Incremental Remittance Import”)

incrementally loads remittance advice from an SAP system.

This task recognizes the following parameters:

• DefaultStartDate, which specifies the start date for the incremental import.
• LoggingName, which specifies the logging name.
• Variant, which specifies the name of the variant.
• Partition, which specifies the name of the partition.
• Event, which specifies the name of the integration event that imports that remittance data.

Ariba Payment Implementation Guide 79

Partitioned Scheduled Tasks Appendix C Scheduled Tasks

PaymentAggregator
PaymentAggregator = {
ScheduledTaskClassName = ariba.payment.AggregatePaymentsTask;
AggregationFieldsGroup = "PaymentAggregationGroup";
PaymentAggregatorClass = "ariba.payment.AribaPaymentAggregator";
Schedules = {
Schedule1 = { DayOfWeek = Everyday; Hour = 3; Minute = 30;};
};
};

The PaymentAggregator scheduled task (display name “Payment Request Aggregator”) runs a query to find
payment requests that are scheduled to be paid and determines how (or whether) to aggregate those requests
together onto payment transactions. In the default configuration, the payment aggregator groups together
payment requests that have the same supplier location and the same payment method. It applies only to
objects whose payment model is LocalPay.

This task recognizes the following parameters:

• AggregationFieldsGroup names a group, specified in metadata XML. The fields in this group are the
fields that must match for payments to be aggregated (in the default configuration, supplier location and
payment method).
• PaymentAggregatorClass names the Java class that implements the logic of which requests are aggregated
together. To customize aggregation logic, supply your own Java class for this parameter.

PostProcessSettlementEnablement
PostProcessSettlementEnablement = {
ScheduledTaskClassName = "ariba.payment.PostProcessSettlementEnablement";
TargetPaymentModel = "ExternalPay";
};

After you have enabled Ariba Payment, you must run the PostProcessSettlementEnablement scheduled task
(display name “Performs post processing tasks after enabling settlement”). This task converts any existing
payment requests in your configuration to the Ariba Payment object model.

This task applies only to payment requests that currently have the status of Processing, and that were created
before you enabled Ariba Payment.

This task is defined in the default configuration, but is not scheduled. To use this task, you typically run it
just once, after enabling Ariba Payment.

This task takes a parameter, TargetPaymentModel, which can be set to either AribaPay or ExternalPay, to
indicate the payment model you want to use for the converted payment requests. The default value of the
TargetPaymentModel parameter is ExternalPay, which sends any outstanding payment requests out to an
external system, as in previous versions of Ariba Buyer. This parameter is required.

80 Ariba Payment Implementation Guide

Appendix C Scheduled Tasks Partitioned Scheduled Tasks

ProcessPaidPaymentTransactions
ProcessPaidPaymentTransactions = {
ScheduledTaskClassName = ariba.payment.ProcessPaidPaymentTransactions;
Schedules = {
Schedule1 = {DayOfWeek = Everyday; Hour = 4; Minute = 00;};
};
};

The ProcessPaidPaymentTransactions scheduled task (display name “Process Paid Payment Transactions”)
looks for payment transaction documents that are in the Paid state, and moves them to Cleared. Before
moving a transaction to Cleared, this task checks to see if the appropriate number of days have passed. The
number of days to wait is specified on the payment transaction, and set from the payment method. For
example, if the payment method is check, the number of days to wait is likely to be higher than if the
payment method is ACH.

ProcessPendingPaymentRequests
ProcessPendingPaymentRequests = {
ScheduledTaskClassName = "ariba.payment.ProcessPendingPaymentRequests";
Schedules = { Schedule1 = { DayOfWeek = Everyday; Hour = 3; Minute = 00;};};
};

The ProcessPendingPaymentRequests scheduled task (display name “Process Pending Payment Requests”)
picks up pending payment requests with the status Scheduling, and checks the scheduled payment date. If
the ScheduledPaymentDate is on or before the current date, ProcessPendingPaymentRequests moves them
into the Scheduled state.

ProcessSkippedPaymentRequests
ProcessSkippedPaymentRequests = {
ScheduledTaskClassName = ariba.payment.ProcessSkippedPaymentRequests;
Schedules = { Schedule1 = { DayOfWeek = Everyday; Hour = 5; Minute = 00;};};
};

When a payment request is sent to AN, certain values configured in Ariba Buyer (such as remittance address
information) must match values configured for the supplier in AN. If these values do not match, Ariba Buyer
generates validation errors. Even after an administrator fixes the values so that they match, payment requests
can remain “stuck” in the Scheduling status. The ProcessSkippedPaymentRequests scheduled task (display
name “Process skipped payment requests”) looks payment requests that have been skipped because of
validation errors, makes sure the validation errors have been fixed, and then reprocesses them.

Ariba Payment Implementation Guide 81

Partitioned Scheduled Tasks Appendix C Scheduled Tasks

RemittanceCSVImportLoader
RemittanceCSVImportLoader = {
ScheduledTaskClassName ="ariba.payment.server.RemittanceCSVImportLoader";
Adapter = RemittancePull;
IncomingFolder = "transactionData/remittance/incoming";
ProcessedFolder = "transactionData/remittance/processed";
FailedToProcessFolder = "transactionData/remittance/errors";
Schedules = {
Schedule1 = {
DayOfWeek = Weekday;
Hour = 0;
};
};
};

The RemittanceCSVImportLoader scheduled task (display name “Payment Remittance Loader (CSV)”)
reads remittance data from CSV files and loads that data into Ariba Payment. This task is part of the
Settlement module and is enabled only if you have loaded the Settlement module.

This task recognizes the following parameters:

• Adapter names the integration event that the remittance loader calls to load data files.
• IncomingFolder names a directory where the remittance loader looks for new data files.
• ProcessedFolder names a directory where the remittance loader moves data files after they have been
loaded.
• FailedToProcessFolder names a directory where the task moves data files if there were errors during the
load process. In this caes, it also sends the Notification of Remittance Load Failure message to users who
have the PaymentManager permission.

ResendFailedPaymentRequests
ResendFailedPaymentRequests = {
ScheduledTaskClassName = "ariba.payment.ResendFailedPaymentRequests";
Schedules = { Schedule1 = { DayOfWeek = Everyday; Hour = 2; Minute = 00;};};
};

The ResendFailedPaymentRequests scheduled task (display name “Retry Sending Payment Requests”)
resends payment requests that did not transmit successfully to the intended destination. This task scans the
database for all such failed payment requests and retries the transmission.

Each time it runs, the ResendFailedPaymentRequests task looks for any failed payment requests and retries
them. It can potentially retry the same payment request each time it runs, until the transmission succeeds.
ResendFailedPaymentRequests is available for all variants.

82 Ariba Payment Implementation Guide

Appendix C Scheduled Tasks Partitioned Scheduled Tasks

ResendFailedPaymentTransactions
ResendFailedPaymentTransactions = {
ScheduledTaskClassName = "ariba.payment.ResendFailedPaymentTransactions";
Schedules = { Schedule1 = { DayOfWeek = Everyday; Hour = 2; Minute = 00;};};
};

The ResendFailedPaymentTransactions scheduled task (display name “Retry Sending Payment Transactions
(Remittance)”) resends payment transaction requests that did not transmit successfully to the intended
destination. This task scans the database for all such failed payment transaction requests and retries the
transmission.

Each time it runs, the ResendFailedPaymentTransactions task looks for any failed payment transaction
requests and retries them. It can potentially retry the same payment transaction request each time it runs,
until the transmission succeeds.

Ariba Payment Implementation Guide 83

Partitioned Scheduled Tasks Appendix C Scheduled Tasks

84 Ariba Payment Implementation Guide

Index

A SLRemittanceDetails.csv 35
ABA (American Bankers Association) 30 configuring
ACH payment method 28 payment aggregator 48
ad-hoc payment terms, payment terms payment terms 12
ad-hoc 38 contracts, payment terms on 38
aggregation 47 credit card payments 27
customizing the payment aggregator 48 credit memos
payment aggregator 47 payment aggregation and 47
AN payment requests and 10
choosing as payment model 18 credit payment requests 10
enabling AN payment 14 currency, on remittance advice 58
payment methods 28 CXMLPaymentRemittanceLoader scheduled task 53, 77
payments on 10 CXMLProcessUndeliveredPayloads scheduled task 78
ANPay, in user interface 18
approvable documents
D
payment documents 10
Ariba Settlement 9 data sources, preparing 14
aribanetwork logging category 62 dates for payments 44
AribaNetworkOrganizationSync scheduled task 33 default payment aggregator 47
AribaPay payment model 22 DefaultPaymentTerms parameter 42
choosing ANPay or LocalPay 18 direct payments
AribaPaymentDiscountSelector class 46 configuration 22
AribaPaymentScheduler class 44 configuring required functionality 12
AribaPaymentTermsDefaulter class 41 DisbursementCreator scheduled task 79
configuration file entry 49
staging table 49
B DisbursementData staging table 49
bank account information discounts
account types 29 discount policy 46
buyer and supplier accounts 32 line types for 46
ID type pull 30
BuyerBankLocation field, defaulting 32
E
effective date for payments 45
C ERP integration
check payments 27 payment terms 42
cleared transactions 50 export events., payment methods 28
CommonSupplierSyncUsingSupplierLocationID
scheduled task 33
F
completed payments 9
configuration files ForceCancelPaymentTransaction permission 70
BankAccountIDType.csv 31 ForcePayPaymentTransaction permission 69
BankAccountType.csv 29 forcing status change
BankIDType.csv 30 permissions 69
PaymentMethodType.csv 27
PaymentTerms.csv 27, 39
RemittanceLocation.csv 34 G
RemittanceLocationDetails.csv 35 G/L push 49

Ariba Payment Implementation Guide 85

Index

GetPendingAribaNetworkOrganizationSync scheduled export event 28

task 33 integration event for 27
groups supplier support 28
PaymentAggregationGroup 48 translations of 28
PaymentRequestValidationGroup 25 payment models
PaymentTermsEffectiveDateField 44 about 18
PaymentTermsEffectiveDateField group 44 AN payment 18
choosing AN or direct pay 18
direct payment 18, 65
I parameters for 20
IBAN (International Bank Account Number) 31 payment requests 10
installation credit memos 10
Ariba Settlement install 13 for credit memos 10
preparing data sources 14 migrating from previous versions 80
integration events validation 25
RemittancePull 54 payment schedules 43
internationalization defining 43
payment method types 28 setting 44
invoice reconciliations, payment terms on 38 payment send methods 20
payment terms 12, 37
ERP integration 42
J line item types 46
Java classes missing payment terms 40
AribaPaymentAggregator 48 setting 40
AribaPaymentDiscountSelector 46 standard 12
payment discount selector 45 payment terms logging category 62
payment scheduler 44 payment transactions 10
clearing 50
creating 47
L direct payment 18, 65
line type categories 46 during remittance pull 10
LocalPay, in user interface 18 remittance advice 58
log categories for payments 62 send methods 23
PaymentAdministrator permission 70
PaymentAggregator scheduled task 47, 80
M PaymentDiscountSelectionPolicy parameter, parameters
PaymentDiscountSelectionPolicy 46
migrating existing payment requests 80
PaymentDiscountSelector class 46
PaymentManager permission 54, 70
N PaymentRequestValidationGroup 25
payments
notification messages dates for 44
of failed remittance load 54 discount selector 43, 45
recipients 73 G/L push 49
payments, disbursement 79
PaymentScheduler parameter, parameters
P PaymentScheduler 45
Parameters.table PaymentSendingEmail permission 70
payment scheduler 45 PaymentTerms.csv 39
payment terms defaulter 41 PaymentTermsDefaulter parameter, parameters
payment aggregation 43 PaymentTermsDefaulter 41
configuring 48 PaymentTermsEffectiveDateSkipDays parameter,
credit memos and 47 parameters
customizing 48 PaymentTermsEffectiveDateSkipDays 44
payment disbursement 43 PaymentTermsLineTypeCategories parameter,
payment logging category 62 parameters
payment methods 27 PaymentTermsLineTypeCategories 46
ACH, editing supplier preferences for 28 PaymentTermsStep.csv 39

86 Ariba Payment Implementation Guide

 Index

PaymentTermsStepDetails.csv 39 T
permissions tax accrual payment requests 47
ForceCancelPaymentTransaction 69 trigger events
PaymentAdministrator 70 SetPaymentTermsOnMAChange 41
PaymentManager 70 SetPaymentTermsOnOrderChange 41
PaymentSendingEmail 70 SetPaymentTermsOnSupplierChange 40
PostProcessSettlementEnablement scheduled task 16, 80 SetPaymentTermsOnSupplierLocationChange 40
preparing data sources 14 triggers
ProcessedID field, payment transactions 50 for payment terms 40
ProcessPaidPaymentTransactions scheduled task 50, 81 updating remittance location 34
ProcessPendingPaymentRequests 50
validation of payment requests 50
ProcessPendingPaymentRequests scheduled task 50, 81 V
purchase orders, payment terms on 38
validation
payment requests 25
R scheduling and 50
remittance address
remittance location 34 W
updates with trigger 34
wire payments 27
remittance advice 10, 12, 51
currency 58
payment transactions and 58
pulling from external system 10
RemittanceCSVImportLoader scheduled task 53
RemittancePull integration event 54
details file example lines 58
details file fields 57
header file example lines 57
header file fields 55
sample data files, location of 55

S
S.W.I.F.T. 30
scheduled tasks
CommonSupplierSyncUsingSupplierLocationID 33
DisbursementCreator 49
error handling 54
PaymentAggregator 47
PostProcessSettlementEnablement 16, 80
ProcessPaidPaymentTransactions 50
ProcessPendingPaymentRequests 50
scheduling, payment forecasting and 9
send methods 20
SetBuyerPaymentBankLocation action 32
SetPaymentTerms action 41
SetRemittanceLocation action 34
Silent send method 23
staging table 49
supplier data
payment methods 28
supplier location data 33
supplier profiles 33
supplier locations
remittance locations for 35

Ariba Payment Implementation Guide 87

Index

88 Ariba Payment Implementation Guide