Hi. I'm Adarsh Sriramula, working for Oracle Advanced Customer Services' team.

I
'm working Oracle for eight years now. I come by an experience of consulting and
development.
Today we will be doing a session on suppliers and data migration. During the ses
sion, I would expect audience to know how the varied process works from 11i to R
12, and what are the data clean-up activities that is required in 11i. So let's
get started.
Let us start with the supply data migration. So the agenda, we would go through
the 11i and the R12 architecture. We would see how the upgrade logic is when the
upgrade process is running. And after the session, I would expect the audience
to gain knowledge on what are the data clean-up activities that we would have to
do in 11i to get an expected data structure in R12 for supplier master.
Few of the recommendations that Oracle suggests. So this is the data model that
we have currently in 11i where we create the supplier header record, which is ac
cessible throughout the instance. So when we say, throughout the instance is tha
t we create a supplier, say, General Electric, in which an operation is operatin
g unit.
You can very well get into Vision Services operating unit, and query the supplie
r. And the supplier record is already available.
At the OU level, we have the site details and address details, which are OU-spec
ific. So the site details are available in PO vendor sites All table, which are
classified by [INAUDIBLE].
So this is a supplier header record which is created in Vision Operations. When
you get to any other operating unit, you can very well query this supplier heade
r record. And it's available to create sites in that operating unit.
So we have the supplier sites. This screen which we are seeing is for the Vision
Operations. And the points that I would like to focus on is the site name, whic
h is General Electric.
And the address elements, which are the address line one. Currently it is 3135 E
aston Turnpike. And the same way, we have address line two, three, four, and cit
y, state, province, and country. So all these I refer to as address elements goi
ng forward, because these play a crucial role when doing the update and when cre
ating the record in R12.
So these records in 11i are currently in PO vendor sites All table.
So this is the R12 data model. With the Trading Community Architecture update in
R12, we have the HZ parties, HZ party sites, and HZ party site usages, which ar
e specifically for any of the parties that we deal with. So when we create a sup
plier, each record is created in HZ party. And we have a HZ party classification
, which classifies that record as a supplier.
We would see in the next slide how the managed sites are created and record in A
P supplier sites All is created. So at the instance level, we have all the HZ re
cords, HZ parties, HZ party sites, HZ party site usages.
So HZ party sites are specifically for storing the address elements and the addr
ess name. And party site usages is the site attributes, whether we are using it
for a pace site, for a tracing site, or a mal FQ site.
Moving forward. So this is a screen which we create a supplier. So when you ente

r an organization name, it is actually inserted into AP supplier's table and als

o HZ party's. And the HZ party record is classified as an organization type of r
ecord. And the assignment of Assignment Usages table is classified as a supplier
.
So once a supplier is created, you might be knowing that we are supposed to crea
te an address book. So once we navigate to the address book, we see that we have
the address name and the address elements. So the address column name is derive
from the site name on which it's stored in HZ party site's table. And all of th
e address elements are stored in HZ location's table.
So when we click on the managed site, we are taken to this managed site's page,
which stores all the records. And the records are stored in AP supplier site's A
ll table. So we have a few of the table-level changes in R12.
By this time, you must have noticed that all of the PO vendor's records are migr
ated to HZ parties. And each of the HZ record is available in AP supplier's tabl
e. And the PO vendors, which is 11i table, is now a View in R12.
So each of the vendor's sites, all records, are migrated into two tables, which
is HZ party sites and HZ locations. HZ locations stores all of the address eleme
nts. And HZ party site table stores the address name for the combination of the
address name and the HZ locations. We see it in the address book in the front en
d.
And we have the PO vendor contacts details, which are the supplier contacts, whi
ch get migrated into HZ parties and HZ contact points. In HZ parties, we have ea
ch record with a party type as person. So the HZ relationship table holds the re
cords of HZ parties of the contact and the supplier with the party ID as the joi
ning column.
We would now look at the data migration into these tables. So we have when we mi
grate the supplier records, each 1-1 record is migrated into HZ parties. And whe
n we migrate the PO vendor site details, we have to insert records into HZ locat
ions and HZ party sites.
So while creating records in HZ party locations, which is the address element, a
grouping logic is applied so that duplicates are not created in R12. So that be
comes more crucial, because we don't want the users to get confused with the dup
licate records.
So we would see how the grouping logic is applied when creating the supplier sit
es in R12. The same way we have the grouping logic which gets applied when the s
upplier contacts are getting created.
So this is a high-level pictorial representation of how the supplier header info
rmation is migrated. From PO vendors table, the records get inserted into AP sup
pliers. And all of the supplied information is then moved to TCA.
So the records are inserted into HZ parties, HZ party usage assignments. So the
usage assignment will classify the party as supplier. And in case the supplier h
as an relationships, like the supplier has any contact, then the HZ relationship
will hold a record of the paid-in supplier or the contact information.
Once the TCA record has created, the party site ID-- sorry, the party ID is tamp
ered on AP suppliers.
This slide will give an overview on how the supplier sites are created in R12. B
y this time, we know that a new level is introduced in R12 that once a supplier
is created, we are first required to create the address of the supplier.

So during the supplier sites migration, what the upgrade logic would do is to po
pulate records in two tables. One is HZ party sites, and another is HZ locations
. So while creating HZ locations, we have the grouping logic, which gets applied
, which is address lines one to four-- city, state, country, province, county, z
ip code, and language.
So we will see an example in the next slide of what the address and details are
all about. And the HZ party site is the address name, which is derived from the
vendor's site code from 11i.
So once the TCA details is created, the party site ID is stamped on AP supplier
site's All table.
So we have a representation and an example. Consider there are three
nits-- Operating Unit 1, Operating Unit 2, and Operating Unit 3. And
r site names are Supplier Site 1, Supplier Site 2, and Supplier Site
the address details. Physically, all of these address represent the
on.

operating u
the supplie
3. Consider
same locati

But then for Operating Unit 2, the address is spelled differently. We have a cou
ple of parentheses inserted into that desk component. So this makes the grouping
logic and the address for the operating unit is technically different to others
. So when the grouping logic is applied, there are two physical address created
in R12, which is the right side of this slide.
So the first slide, the first address which gets created is 2300 West Plano Park
way, Plano, Texas. So Operating Unit 1 and Operating Unit 3 share the same physi
cal address. When the address is created, the address name, which is the HZ part
y site, it derives a randomly chosen site name between OU1 and OU3. And then the
second address, which is from OU2. And then we have the down-level supplier sit
es, which are inserted into AP supplier site's All table.
But what can be done better in this case is in 11i, assuming that all of the sup
plier site names are similar and all of the address names, address elements are
similar in R12, and the upgrade would have created a single address, and the sin
gle address would be shared across operating units-- Operating Unite 1, 2, and 3
, which makes the address book show a single record, and makes the data maintena
nce easier.
This slide is a representation on how the supplier contacts have migrated. So fo
r each records from the AP supplier contacts table, HZ parties, which represents
the physical party of the contact, and HZ party sites, and HZ contact points wh
ich share multiple information of the contact.
May be the email ID, phone number, and the organization details. Are populated i
nto the TCA tables. And once the TCA table is created, we have an appropriate li
nkage between AP supplier contacts and the supplier sites.
So the grouping logic which gets applied when creating all of these supplier con
tacts are listed here, starting from the first name, last name. All of the detai
ls of the email address and the phone numbers.
So here is an example of a supplier which is migrated from 11i to R12. We have a
vendor in 11i, and the two tables which are created after upgrade is HZ parties
and HZ party usage assignments. You could see that the party usage code is supp
lier, which makes the party identified as a supplier in R12.
And a similar record from PO vendors is created into AP supplier's table. This i
s a 1-1 migration from PO vendors to AP supplier sites, All, and HZ parties tabl

e.
This slide will show us how the address book in R12 is created. The first table
on the slide A is the 11i data, which gives us the supplier site and the address
details. Consider the records in blue where the vendor site code is similar acr
oss two operating units. 2408, and 14790. And all the other address elements are
similar.
Once the grouping logic, which we have looked in the earlier slide, is applied,
a single HZ location is created. And the location ID is tampered when we look in
to the HZ party site's All table. So this similar way, look at the records in re
d where the grouping logic is applied. However, that this line 2 is not populate
d. So there are two records which are created in HZ locations.
So this is a slide which shows the data in HZ party sites. So the record in blue
is tied up to the party ID, the supplier. And we have the location ID which sto
res the address elements. And the party site name is derived from the vendor sit
e code of 11i.
So this is a single record, meaning when we're looking in the address book of th
e supplier, we would see a single record for the address. And when we get into d
etails of managed site, we have two records for each of the operating unit. Othe
r records, we have the grouping logic, which is not satisfied, because of which
we would see multiple address details.
This slide represents how the data is populated into HZ party sites table. From
our earlier slide, we have seen how the location ID is populated, which uses the
address tables-- address elements of 11i. And a unique location is created.
So for those in blue, the address elements are similar. So we have a single loca
tion ID populated. And in HZ party sites table, we have the site name, which is
derived from vendor site code. Similarly, for those in red and green, grouping l
ogic is not applied, because either the address details are incomplete. So we se
e that the duplicate records are created in HZ party sites table. And for each l
ocation ID, we have the party ID and the party site ID associated in R12.
This slide shows data on supplier contacts. This is an extract of a vendor, a co
ntact for a particular vendor ID in 11i. We would be concentrating on the record
s which are created in red. So the grouping logic we have is starting for all of
the elements. Last name, email address, phone numbers, and mail stop.
Looking at the data, we could see that for a couple of records, we don't have th
e mail stop populated. So a single record is created for which the mail stop is
null. And for the one where the title and the phone number is populated, we have
a record created in R12. And for the rest of the records in red, a single recor
d is created.
So we could see that in R12, we have three records populated for party contact.
And each of the party ID is associated to the respective supplier sites.
An example is 612507, where the person title is populated. We could see that it
is linked up to vendor contact 139393. For 11i vendor contact 139393, we could s
ee that the R12 vendor contact party ID is 612507. It is after applying in the g
rouping logic, we have arrived to this state.
So what is the impact if you don't clean up the address details? The address ele
ments are duplicated, and the address name, which is the HZ party site's All tab
le are duplicated. And on the front-end address book, we would see the duplicate
d records, which is confusing state for the end users.

And the end users wouldn't know to which address they have to update or do some
modifications. It becomes more difficult, because the supplier sites are in mang
ed sites form where they need to navigate to the next page.
Here is another example. Because the address names are duplicated, in case the u
ser tries to update the address, an error message stating the address name is al
ready existing as shown.
So the remedy for these issues is to apply the standard Oracle patch, which woul
d deliver a SQL script, which can be done on 11i instance, which will give data
of all the duplicate records.
This patch will deliver three SQLs-- one for vendor sites which have the same na
me but different address details. So as explained earlier, the output of this SQ
L can be used to correct all the address elements. So then the grouping logic wi
ll create a unique record in R12.
A second SQL, which gives data of vendor sites which have same details but diffe
rent name. So the site name is different, but then all the address elements are
different. So this creates different records in HZ party sites All table, thereb
y again creating duplicates. Using the output of this SQL, we would have to corr
ect the site names in 11i.
The
and
all
and

third SQL would give the vendor contact details, which have same first name
last name, but different contact details. We may use this output to correct
the other contact details, which can further be used by the grouping logic,
then create unique records for the contact party.

We now move to bank data migration. We would see on how the data model is for R1
2 and 11i. We would see a few of the examples and recommendations. In 11i, and t
he bank data is stored in AP bank branch's table and the account information in
AP bank accounts All and the supplier and bank details are associated in AP bank
account user's All table.
When the upgrade script is executed, these bank records are created in HZ party.
And the party is classified as a bank record.
Further, the bank account details are now available in IBY tables, which are IBY
EXT Bank Accounts, IBY External Payees All, IBY Account Owners, and IBY Payment
Instruction Uses All. This table stores the account details and the association
of the bank account with the suppliers and the supplier sites.
So the upgrade would consider creating three different entities. One is the bank
, bank branch, and bank account. While creating bank record in HZ parties, a gro
uping logic of bank name, bank number, institution type, and country is applied.
In 11i, when we create bank accounts, they are classified by operating units. B
ut then can be linked to a single bank branch, which is created across operating
units. It is pretty much possible that users may create duplicate banks.
Example, Bank of America, spelled as Bank of America. But then another user crea
tes a bank record as BOA. Or the bank name is created as New York, and the other
user creates it as NY, which creates duplicates in 11i and further carried forw
ard to R12.
We do have the address details for the bank branch. It is recommended that we ke
ep the address details of the bank branch consistent across all of the branches,
because it would create duplicate records in HZ locations, technically.
Looking at the bank accounts, we know that we would not be able to create duplic
ates for bank account number in 11i. But then, if the bank name and the bank bra

nch name is different, users can create duplicate bank account number. Thereby,
creating duplicate bank account numbers in 11i.
This is an extract of AP bank branches which holds the bank name and the bank br
anch name details. Looking at this data, when the grouping logic is applied for
the bank name, bank number, institution type, and the country, we can identify t
he three records which gets created in R12. For those, the country is null, the
country is defaulted from the default country profile option.
So here is the data of the bank record which gets created. Two records with the
country name as JM and the other country, US, which is defaulted from the profil
e option, Default Country. One of the record for the party name NCB is duplicate
d in HZ parties, because the bank number is entered as NCB in 11i.
So the point to note when cleaning data in 11i is to ensure we have the correct
country populated for all of our bank records, the bank number is properly updat
ed, and the institution type is verified.
This is data of the bank branches from 11i which are associated to the vendor an
d vendor sites. This is a single vendor, which is operating in different operati
ng units. So the org ID of 2, 62, and 10128 identify that these supplier sites h
ave been operated in different operating units.
We could see that the bank account number 488005759884 is duplicated across oper
ating units in 11i. Since the operating unit ID is populated in bank account tab
le in 11i, these are duplicated. When these have migrated to R12, the duplicates
are migrated as is.
This is the data which shows in R12. So the duplicate account number still exist
s. So when the user's credit for this bank account number, they would see duplic
ate search results, thereby getting confused to which bank account number the su
pplier site to be associated.
So here is an example of how the bank account numbers are shown when the account
number is duplicated after an upgrade. The remedy is to apply the patch 1014479
8, which gives SQLs to identify the bank account numbers which are duplicated.
This is a post-upgrade step which needs to be executed, which then merges all th
e duplicate bank account numbers into a single record. And all of the related tr
ansactions-- AP payments, schedule results, AP checks All are updated with the m
erged bank account ID.
This completes the session on supplier and data migration. Thank you for attendi
ng.