OUM

RA.040 BUSINESS DATA STRUCTURES

Bytes Shared Service Centre
Customer Data Structure
Author:

Hillel Frame

Creation Date:

25-Nov-1313

Last Updated:

20-Dec-133

Document Ref:

RA 040 Customer Data Structure

Version:

DRAFT 1A

Approvals:

Sandy Bierman
Dirk Eksteen

RA.040 Business Data Structures

Error: Reference source not found

1.

Doc Ref: RA 040 Customer Data Structure

DOCUMENT CONTROL

1.1

Change Record
3

Date

Author

Version

Change Reference

25-Nov-13

Hillel Frame

Draft 1a

No Previous Document

1.2

Reviewers

Name

Customer Data
File Ref: 258823868.doc

Position

(v. DRAFT 1A )

Graphical View of the KEY Customer components

9 of 17

RA.040 Business Data Structures

Error: Reference source not found

Doc Ref: RA 040 Customer Data Structure

Contents

1.

Document Control................................................................................................... iii

1.1
1.2

Change Record.......................................................................................................... iii

Reviewers................................................................................................................... iii

2.

Introduction............................................................................................................... 1

2.1
2.2

Purpose....................................................................................................................... 1
Scope.......................................................................................................................... 1

3.

Business Rules for Customers................................................................................2

4.

Graphical View of the KEY Customer components...............................................9

5.

Existing Oracle Customer High Level Data Structure.........................................10

6.

Shared Services Customer High Level Data Structure........................................11

7.

Open and Closed Issues........................................................................................ 13

7.1
7.2

Open Issues.............................................................................................................. 13
Closed Issues............................................................................................................ 14

Appendix..................................................................................................................................... 15
1.

Customer Data
File Ref: 258823868.doc

Open and Closed Issues........................................................................................ 20

(v. DRAFT 1A )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

2.

INTRODUCTION

2.1

Purpose

The purpose of the Business Data Structures document is to describe the key business structural
elements that affect subsequent set up of the applications. This deliverable is used to assist in the
development of application setups. It includes:

Definition of Common Customer Master Data structure that will used in the shared
Service Centre

2.2

Scope

This document defines the fields and the business rules that are required to support the design of
customer master taking the existing customer masters that have been defined in separate lines of
business into account also the existing reporting requirements have also been taken into
consideration.

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

3.

BUSINESS RULES FOR

CUSTOMERS
The following business rules apply to the creation of customers
1. Party Level
1.1. Organization Name
This will be the full name of the customer and will have a one to one relationship with the customers
Company Registration Number and
Companys Tax Registration Number
If a company has more than one Tax registration number additional Bill To sites will be created in the
respective operating units or lines of business and this information will be stored on the tab profile at the bill
to site level
1.2. Sic Code Classification
The SIC Code classification will be captured in a descriptive flexfield at the party level
1.3. Party Relationships
Party relationships will be used for example Bidvest has diverse companies each with its own tax numbers
and these companies will be linked together using the party relationships for reporting purposes
1.4. Registration Number
The companys registration number will be captured on the profile Tab at the party level
1.5. Vat Number
The Vat number will be captured on the Profile Tab at the part level
2. Account Level
2.1. Account Number and Name: (Customers Account Number)
All account numbers will be system generated and customers that are brought from legacy system will
have a new account number that will be generated during the import process

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

Each Line of Business (Operating Unit) will have a Customer Account Name and Number if required
For customers that are imported from legacy systems there will be a mapping to the existing account
number and this account number will be stored in a descriptive flexfiled on the customer account level
in oracle.
If a customer requires more than one account then the name needs to be specific and prefixed with 3
letter acronym for the specific line of business for example BUS Account or BUS training Account or
BUS Northern Cape Account
Each account will have a bill to site and statement site (Note an account can have multiple bill to sites
with one statement site)
2.2. Account Classification
Account will be classified according to the values defined in the lookup
2.3. Account Type
Customer Account type will be external for all customers except for the internal customer which will be
manually created
2.4. Sales Channel
Users need to populate this field when creating new customers if the field is not populated on legacy
system default the value to Direct
2.5. Context Value
Two additional Descriptive Flexfileds have been configured at the customer account level to capture
the following:
1. Operating Unit (Used for a validation on Order Management when creating the sales Order)
2. Legacy Account Number For customers that are imported from Legacy systems
3. Account Profile
3.1 Profile Class
There will be a default profile class configured for each operating unit the reason is to default in the following
information when creating a customer:
a. Payment Terms - 30 Days Net

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

b. Default collector - Default Collector

c.

Credit Check tick box will default to Yes

d. Send Statement tick box will default to Yes

e. Credit Limit Currency - ZAR
f.

Credit Limit = 0.00

g. Order Credit Limit = 0.00

3.2 Collector
Person responsible to collect the outstanding amount needs to be defined in AR as collector it will default to
Default from the profile class user needs to update the filed accordingly
3.3 Credit Check
Default in from Profile Class
3.4 Payment Terms
Default in from Profile Class Can be overridden needs to be defined as AR Payment Terms
3.5 Send Statement
Default in from Profile Class used as part of the statement run
3.6 Statement Cycle
Default in from Profile Class
3.7 Tax Printing
Default to Total Tax Only
4. Profile Amounts
4.1. Currency
For each Customer a credit profile per currency needs to be setup.
4.2. Credit Limit

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

Default to 0.00 users will override the amount according to the credit profile check or the value will be
imported in from legacy
4.3. Credit Order Limit
Default to 0.00 users will override the amount according to the credit profile check or the value will be
imported in from legacy
5. Communication
There is a requirement t0 email the statement and invoice to the customer and to achieve this, the customer
contact needs to be captured as part of the customer creation process. These programs will look to see if the
customer has an email address and the correct contact role of invoice or statement. If these values are true then
the program will mail the statement and invoice. The following fields are required to create a customer contact:
5.1. First Name
5.2. Last Name
5.3. Email
5.4. Phone Number
5.5. Address
5.5.1.

Address Line 1

5.5.2.

Address Line 2

5.5.3.

Town

5.5.4.

City

5.5.5.

Postal Code

5.5.6.

Province

6. Account Relationships
6.1. Used for phase 2
7. Create Sites
7.1. Operating Unit

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

Every customer site created in Oracle TCA needs to belong to an operating unit therefore the user needs to
select an operating unit when creating a new site. For the customers imported from legacy systems the
operating unit needs to mapped to the customer site
Also every customer site must be defined with an address. Oracle allows a customer to have a single bill to
and ship to address or for the customer to have multiple sites with different addresses for example a
customer can have multiple ship to addresses with a single bill to address.
7.2. Site Name
The user needs to capture a site name that is specific to the purpose of the sites for example if a customer
has multiple ship to sites the site name can be the Cape Town Site or Durban Site etc. In case of Eskom
where there are multiple accounts the site name can be the same as the Account Name. Business need to
populate this column with a meaningful for customers imported from legacy systems
7.3. Create Address
The following fields are required to define a customers address:
Address Line 1
Address Line 2
Address Line 3
Town
City
Postal Code
Province
Addressee (Used for iStore Essentially Addressee is used when an order is made by a customer and is
shipped somewhere else. For example: I purchase a book and have it shipped to my mother. My
mother becomes the addressee at the address that the book is sent to)
7.4 Site Purpose
The following site purposes have nee identified
1. Ship To

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

The address on the sales order where the goods are shipped to not customer can have multiple ship to
addresses
2. Bill To
This is the address where the bill is sent to. Note there can be multiple ship to for one bill to sites
3. Statement
Extract form the Oracle User Guide
If you have defined a statement site for your customer, Receivables will create one consolidated statement for the statement site,
rather than creating a separate, site-specific statement for each bill-to site. Receivables subdivides each customer's consolidated
statement to show subtotals for each of the customer's bill-to sites. Receivables then sorts each of these subtotals by currency. This
consolidated statement contains a summary page at the end of the report with summarized subtotals by currency for each of a
customer's bill-to sites. If there are any on-account or unapplied receipts with no location, they will be printed on a separate sheet
before the summary page.
If you did not define a statement site, Receivables will print a separate statement for each bill-to site that shows all the transactions
relating to that site, subtotaled by currency. On-Account or Unapplied receipts with no location will not appear on any of the
statements.
In both cases, cross site and cross customer receipts will be displayed below the unapplied receipts for each bill-to site.

For the Bytes project the template needs to cater for both of the above cases
8.

Bill To Site
8.1. Accounting
For certain customers there is a requirement for the inventory workflow to derive some of the segments of
the revenue and cost of sales account from the customers revenue GL string defined at the bill to site.
Question about Legacy Customers MD
8.2. Site Use and Details
Not Required
8.3. Order Management
Not Required

9.

Ship To Site
9.1. Accounting
Not Required
9.2. Site Use and Details

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

Not Required
9.3. Order Management
Not Required

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

4.

GRAPHICAL VIEW OF THE KEY

CUSTOMER COMPONENTS

Graphical View of the KEY Customer components

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

5.

OPEN AND CLOSED ISSUES

5.1

Open Issues

ID

Issue

Resolution

Responsibility

Sandy to define the Business

Dependent on Customer Requirements

Sandy Bierman

Rules for Customer

Bidvest etc

Relationships
Sandy to define the List of

Use the standard Relationship Types

Target Date

Impact Date

Sandy Bierman

Values for Customer

3

Relationship Types
Test the account type

Marguerite Drake

functionality of internal and

external for Intercompany
4

Selling
Investigate why we have a

Party Level Classification is Still

SIC code at the party level

Required

and not at the Bill to Account

5

Level
Revenue for Tenders needs

Marguerite Drake

to be reported separately.
Need to investigate the
pricing agreement
functionality in Advanced
6

Pricing Module
Business need to review the

Customer Category field is still required

requirement of using the

and will drive the pricing functionality

Sandy Bierman

customer category field at the

7

party level
Business to investigate if AR

Not Required

Sandy Bierman

Sales Territory flexfield will be

used for geographic reporting
requirements. Sandy to speak
9

to Shaun Cochran
Account Relationships Sandy

Sandy Bierman

to Investigate the need for the

phase 1 onboarding
companies switch on
functionality to automatically
11
12

create the relationship initially

Address Style from Richard
Old Legacy Number that is in

May not be used

DFF at Customer Account Level

Hillel Frame
Hillel Frame

13

the Reference Field

Profile Classes

Bytes Require Profile Classes

Hillel Frame

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

ID

Issue

Resolution

14

Remit to Bank Accounts

Configure 2 for CRP 1

DFF looking at the bank accounts as

Responsibility

Target Date

Impact Date

Target Date

Impact Date

the link this is to print the bank

accounts on the invoice for the
customer to pay into

5.2

Closed Issues

ID

Issue

Resolution

Responsibility

Confirm that a receipt cannot

AR will not allow a Receipt to be

Hillel Frame

be matched to an invoice

matched to an invoice from another

from a different operating unit

Configure a DFF to store

Operating Unit
JO JO had a solution of adding

email address at the site

additional contact point to lookup value

Purpose level

(CONTACT_POINT_PURPOSE)

10

Hillel Frame

And then added the additional address

to the commination ta. See screenshot
in the appendix
11

Collector cannot create

customer Credit Check not
allowed to touch Credit Hold
not allowed Terms not allowed
Not allowed to touch Party
and account classifications

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

APPENDIX
Customer Category

SIC Code

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

Modifying the Customer Search Fields DQM HZ ORG SIMPLE SEARCH RULE

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

1. Copy Name
2. Then Click on Copy
3. Add and Remove Fileds
4. Update Profile Options

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

File Ref: 258823868.doc

(v. )

Graphical View of the KEY Customer components

9 of 17

Doc Ref:

1.

File Ref: 258823868.doc

OPEN AND CLOSED ISSUES

(v. )

Graphical View of the KEY Customer components

9 of 17