Adecco

Project Nautilus 2.5

Functional Design Specification_I11_Customer Information
Table of Contents

Nautilus 2.5 Design Document Page 1

1 INTRODUCTION.......................................................................................................4
1.1 Purpose................................................................................................................................. 5
1.2 Audience............................................................................................................................... 5
1.3 Glossary................................................................................................................................ 5
1.4 References............................................................................................................................ 5

2 FUNCTIONAL OVERVIEW.......................................................................................6
2.1 Background.......................................................................................................................... 6
2.2 Scope..................................................................................................................................... 6
2.3 Assumptions......................................................................................................................... 7
2.4 Pre-Requisites...................................................................................................................... 7
2.5 Process overview................................................................................................................. 7
2.6 Process Flow........................................................................................................................ 8
2.7 Configuration Document..................................................................................................... 8
2.8 Exception Handling Requirements.....................................................................................8
2.9 Document References.......................................................................................................... 9

3 CEMLI OVERVIEW.................................................................................................10
3.1 CEMLI Type......................................................................................................................... 10
3.2 Assumptions....................................................................................................................... 10
3.3 Business Logic................................................................................................................... 10
3.4 Design Decisions............................................................................................................... 10
3.5 Interface Description.......................................................................................................... 10
3.6 Flow diagram...................................................................................................................... 10
3.7 Source to Target Mappings............................................................................................... 10
3.8 Middleware.......................................................................................................................... 11
3.9 Transformations................................................................................................................. 11
3.10 Legacy Sample Files....................................................................................................... 11
3.11 User Screens and/or Report Layout..............................................................................11
3.12 Selection Criteria............................................................................................................ 11
3.13 Default Values................................................................................................................. 11
3.14 Lookup: <enter name>................................................................................................... 11
3.15 Values.............................................................................................................................. 11
3.16 Validations....................................................................................................................... 12
3.17 Other Design Consideration..........................................................................................12

4 SECURITY REQUIREMENTS................................................................................13

Nautilus 2.5 Design Document Page 2

 4.1 Data Security...................................................................................................................... 13
4.2 Roles.................................................................................................................................... 13
4.3 Any Other Security Requirements....................................................................................13

5 PROPOSED TEST SCENARIOS...........................................................................14

6 NON FUNCTIONAL REQUIREMENTS..................................................................15

6.1 Frequency / Scheduling..................................................................................................... 15
6.2 Volume................................................................................................................................ 15
6.3 Distribution......................................................................................................................... 15
6.4 Notifications........................................................................................................................ 15
6.5 Performance....................................................................................................................... 15
6.6 Any other NFR.................................................................................................................... 15

7 DOCUMENT CONTROL.........................................................................................16
7.1 Change Record................................................................................................................... 16
7.2 Reviewers............................................................................................................................ 16
7.3 Distribution......................................................................................................................... 16
7.4 Open Questions.................................................................................................................. 17

8 APPENDIX..............................................................................................................18

Nautilus 2.5 Design Document Page 3

1 Introduction
Adecco Inc. will implement a single unified cloud solution to globally support finance processes across
Adecco business units.  The desired outcomes are:

• To increase efficiencies and reduce costs by eliminating multiple unsupported systems.

• provide on-demand access to the right data via both web and mobile
• enable the distinct needs of regional Adecco business units and potentially grow the ERP cloud
solution to other business units
The objective of this document is to provide Adecco/TCS with a Functional Specification as part of their
Oracle Cloud Integration initiative for the Adecco (Meaningful CEMLI Name).

The Functional Specification supports the delivery of a successful business transformation by

• Establishing a functional design to address key business objectives

• Identifying the touch-points for functional-level integration
• Capturing the key steps for the component and key design decisions
• Providing high level functional design for the audience listed in this document and developers
• Capturing data mapping between two systems in the context of this integration
• Capturing any business rules and considerations that are pertinent for this integration

This document details the need to transition the Customer information process which involves New
Customer creation as well as updates on the existing Customer information. Below is the flow that depicts
the pictorial representation of the existing AS-IS processes

Customer Creation Process

Bullhorn

General Staffing Professional Staffing

Middle
Smart Search Custom App
ware

Customer Billings
Orders/Sales

Custom Match

Billings PSFT AR

EBS 11i

Nautilus 2.5 Design Document Page 4

Purpose

The purpose of this functional design document is to provide details about the inbound interface that will be
used to Customer information from existing legacy systems into Oracle Cloud ERP system.

This functional design document is intended to provide the technical team with all the key information ,
assumptions, business rules and criteria to be considered for extracting Customers details from peopelsoft
and EBS 11i as source systems into Oracle Cloud Accounts Receivable as a target system.

Audience

This document is primarily aimed at:

 Adecco integration, reports, conversion, extensions and solution architects

 Adecco Design Authority

 Oracle and TCS designers and developers

 Quality Assurance Team

Glossary

Abbreviation Definition

API Application Program Interface

FA Fusion Applications – provided as SaaS
TIBCO TIBCO Middleware
EBS Oracle E_business Suite
PS People Soft Application
WS Web Service
WSDL Web Services Definition Language
SaaS Software as a Service
PaaS Platform as a Service
FBDI Front Based data integtaion

References

Not Applicable

Nautilus 2.5 Design Document Page 5

2 Functional Overview
Background

Adecco will maintain Customers in legacy systems(People soft and EBS 11i AR) and same need to integrate
ERP Cloud system. So the Customer creation is ongoing process to integrate between People Soft and EBS
11i Into Cloud AR.

Scope

 Customer Inbound Integration between People Soft & EBS 11i Into Cloud AR.
 Customers will be maintained in EBS and PS, Cloud updates will not be interfaced back to legacy
systems
 Customer/Site numbers from the legacy system needs to be retained in Cloud
 All updates to existing or new customers be made in Legacy system and same need to integrate to
ERP Cloud system.
 Customer name will maintain the same in ERP Cloud Oracle based upon legacy systems.
 Customer Information like,Site and Contacts need to integrate to ERP Cloud System.
 On Daily basis customer program need to Schedule in ERP Cloud system.
 Email notification sent to the users for any errors and processed for Customers data.
 Customer number to be maintain same as legacy systems.
 D&B Id as a key to link customers across GS and PS stacks, D&B Id should be flowing into Cloud from
EBS and PS
 GEMs ID’s to be captured in Customer/Customer site level for coprocess.
 One way integration,legacy to ERP Cloud ,no ERP cloud updates posted back to legacy
 Customer Account number prefix Starts with Alphanumeric for people soft and Customer Account
Number prefix Starts with Numeric for EBS and same will be integrated to Cloud AR
 Profile Class will be maintained at site level of Customers in Cloud.
 Coresponding cloud profile classes will be mapped to EBS Customers,based upon customer account
type.
 New Field will be added in customer header level in PS for profile class.

Nautilus 2.5 Design Document Page 6

Assumptions

 Inbound integration is done using the standard template provided by Oracle and the contents are
limited to those provided in the template.
 Inbound interface from/to Oracle Financials Cloud will be limited to the delivered and configured
data items in Oracle Financials Cloud.
 New Customers will created in Cloud and process the invoices ,this customers will not defined in
legacy
 Adecco/TCS will be responsible for formatting, orchestration of integrations and end to end
monitoring
 Adecco’s middleware is OIC.
 Bizlink is the SFTP for solution for Adecco

Pre-Requisites

 Dependency

Translation - All data translations would be identified and mapped properly to eliminate or reduce
errors when converting records to the target system . This will follow Customer Conversion Strategy

 Application Setup Requirement

1. Enterprise structure (BU, Legal entity, Ledger) in advance.
2. Chart of Account - COA segments would be available in Oracle Cloud ERP.
3. Manage Receivables System Options
4. Manage Autoaccounting Rules
5. Manage Remit to Addresses

Nautilus 2.5 Design Document Page 7

 6. Manage Receivables Payment Terms
7. Manage Receivables Customer Profile Classes
8. Customer payment methods.
9. All required DFFs should be configured

Process overview

This section describes the details of the Integration process to be used for Customer information from
peopleSoft/EBS11i to Oracle Cloud AR . The steps involved are as below:

1. PeopleSoft/EBS11i receives customer information from respective legacy systems.

2. Customer is created in PeopleSoft/EBS11i.
3. The final Customer information sent to Cloud AR through PeopleSoft/EBS11i integration with Cloud
AR by uploading FBDI template.

Process Flow

Configuration Document

Configuration Document will updated once all AR setups are placed

Nautilus 2.5 Design Document Page 8

Exception Handling Requirements

Not Applicable

Document References

Not Applicable

Nautilus 2.5 Design Document Page 9

3 CEMLI Overview
CEMLI Type

Integration

Assumptions

This is a high level overview, and if any technical components are missing in this flow, please factor
that in the technical section of this document.

Business Logic

The people soft and EBS 11i customer information details will be intigrated to Cloud AR from legacy
PSFT and EBS.

Design Decisions

1. New Customers will be created in People Soft and EBS

2. D&B Id as a key to link customers across GS and PS stacks, D&B Id should be flowing into Cloud from
EBS and PS

3. New Field be added in People soft for GEMS ID

4. New field will be added In people soft for profile class

5. From people soft Customer address, based upon Country code it will be mapped to cloud business
unit.

Interface Description

Below are the steps:

1. Integration program should be able to pick the newly created Customer records in PSFT/EBS 11i
based on last run date
2. Integration should pick the updates to existing Customer based on last run date
3. Customer record should be prepared in the FBDI format from flat files generated and then uploaded
to FBDI .
4. Oracle standard import process called and run which populates the Customer records in Cloud AR

Flow diagram

Refer Technical design document

Nautilus 2.5 Design Document Page 10

Source to Target Mappings

Data mapping should follow the Customer Conversion Strategy. Below is an indicative mapping and the
detailed field mapping should be part of Technical design document .

Template Attached

PSOFT_to_Cloud_Cus EBS_to_Cloud_Custo Customer DFF.xlsx Customers Mapping

tomer_Import_Mapping.xlsx
mer_Import_Mapping.xlsx Template.xlsx

Middleware

Refer Technical design document for details

Transformations

Transformation required for Customer,Sites and Contacts (PS (BU) and EBS (OU) transform to Cloud
business unit  / customer site.

Legacy Sample Files

Not Applicable

User Screens and/or Report Layout

Navigation of Target data(Cloud Customers):Receivables-Billing-Click on Manage customers

Cutomer Accounts and Site

Nautilus 2.5 Design Document Page 11

Customer site Detials:

Nautilus 2.5 Design Document Page 12

Payment details

Contact Detials

Nautilus 2.5 Design Document Page 13

Profile Class

Tax Profile

Nautilus 2.5 Design Document Page 14

Selection Criteria

Refer section 3.5

Default Values

No specific additional default values required for this integration on Oracle Cloud site

Variable Data Description Operation Value

Name Type

Lookup: <enter name>

Not Applicable

Name Description

SourceToTargetTitles To transform titles from source to target format

Values

Not Applicable

Nautilus 2.5 Design Document Page 15

 <Domain1 e.g EBS> <Domain 2 e.g. Oracle CLOUD>

Validations

Refer section 2.2 and more details to be incorporated in Technical design document

Other Design Consideration

No specific additional design considerations required for this integration on Oracle Cloud site

Nautilus 2.5 Design Document Page 16

4 Security Requirements
Data Security

None

Roles

None

Any Other Security Requirements

None

Nautilus 2.5 Design Document Page 17

5 Proposed Test Scenarios

Below are some high level test scenarios. Detailed test scenarios should be captured in the QA document by
the QA team.

SL TEST DESCRIPTION ENTRY EXIT TEST

NO CASE CRITERIA CRITERIA RESULT
1 Custome Customer account is created in
r ERP Cloud
2 Address Bill To, Ship To sites created in
ERP Cloud.
3 Contact Contacts created at the Account
level in ERP Cloud

Nautilus 2.5 Design Document Page 18

6 Non Functional Requirements
Frequency / Scheduling

All Integration will be scheduled to run on Daily and adhoc basis .

Distribution

Not Applicable

Notifications

 Any data that fails the validations before transformation shall be written to error file on SFTP ERROR
folder and the details are communicated to the owner (email to be configured)

 Any data that fails to load into cloud via FBDI can be referred to directly on Data Exchange > Import
and Load Data on cloud side. Summary mail notification need to triger to Users(Subscribed email
alias) shall include the processed and error counts .

Performance

No performance issues are expected. Will be addressed if performance issues are identified during
testing.

Any other NFR

No known NFR

Nautilus 2.5 Design Document Page 19

7 Document Control
Change Record

Date Author Version Change Reference

05/18/2020 Mahipal Reddy.CH Draft 1a No Previous Document
06/24/2020 Mahipal Reddy.CH V1 Incorporated document as
per FDD review

Reviewers

Name Position
Erica/Anu Accounts Receivables Lead

Distribution

Copy No. Name Location

1 Library Master Project Library

Note to Holders:

If you receive an electronic copy of this document and print it out, please write your name on the equivalent
of the cover page, for document control purposes.

If you receive a hard copy of this document, please write your name on the front cover, for document
control purposes.

Nautilus 2.5 Design Document Page 20

Open Questions
This section is used to summarise any open questions relating to this integration design and responses to
these questions when known.

ID Topic Question Status Response

001 Customer details mapping Anu
Customer
between Source and target Open
Inofmration
system to Cloud AR
002 Customer Error handling for the data which Closed As per discussion with Vinod
Inofmration fallout that will be handled email notification be trigred to
through email notification ? users
003 Customer DFF DFF Mapping Open Erica

004 Customer profile How to identify Customers to Open New Field for profile calls will be
Class assign Profile class from PSFT to defined in PSFT and same need
Cloud to intigrate to Cloud ,Anu need
to provide details on New field
name from Peoplesoft.
005 Customer Transformation logic for Closed EBS customers for Profileclass
Customers profile class for EBS to need to based upon customer
Cloud AR Account type

New field GEMS ID will stored in

PSFT same need to intigrate to
Where will be the GEMSID will be
006 Customer Open Cloud , Anu need to provide the
stored in Legacy and Cloud?
New field name from Peoplesoft.
,
D&B Id will be mapped in cloud
Where will be the D&B Id will be
007 Customer Closed with Column DUNS Number in
stored in Legacy and Cloud?
Cloud
How does PS (BU) transform to Based upon PSFT customer
008 Customer Cloud business unit  / customer Closed address,Country it will mapped
site? to Cloud Buisness Unit

Nautilus 2.5 Design Document Page 21

8 Appendix

Nautilus 2.5 Design Document Page 22