ORACLE EDI GATEWAY

Support Document
Order Management Transactions: Additional
Information

Creation Date: October 24, 2002

Updated: October 24, 2002
Contents

Introduction 4
Document Purpose 4
Related Documents 4

Topic: Sold To Address 5

Issue: PO Acknowledgements are Not Extracted by Non-Primary SOLD TO Address Sites 5
Introduction

Document Purpose
This document provides additional information about Order Management transactions.

Related Documents
Refer to the following:

• e-Commerce Gateway Implementation Manual

Topic: Sold To Address

Issue: PO Acknowledgements are Not Extracted by Non-Primary SOLD TO Address Sites

SOLD TO Address Concept:

The Sold To address is meant to be a one-to-one correspondence to the CUSTOMER (parent). It

is THE (Official) address for that customer.

The “customer” Sold To site can have only one “official” address. Any other address would
define a NEW customer or possibly require a change in the Order Management data model.

Currently there is no concept or use of non-primary Sold To addresses in Order Management base
processing, although the standard Oracle Receivables allows you to define them. The SOLD TO
Site was defined only for transaction processing in the e-Commerce Gateway as described below.

Any other business purpose that you have defined for the use of the Sold To site must be
discussed with the Order Management development team to change the data model of that
application. Explain your business need in an enhancement request for that product.

Although the customer sites and the Gateway let you define non-primary Sold To sites, do not set
them up for the POI/POCI or the POAO/POCAO transactions.

Bottom line on this issue:

Customer can extract PO Acknowledgements only by the primary Sold To address for that
customer.

Even if they are successful at loading orders using non-primary Sold To sites, the extract for the
PO acknowledgement searches only for orders under the primary Sold To site.

Order Management does not provide for an extract by secondary Sold To sites since the Sold To
site is not stored on each order, though they can be set up as Trading Partners for the transaction.
The Gateway does not look up site usage when it allows you to set up the trading partner. It just
examines the addresses and lets you select transactions to enable for that site.

Background:

The SOLD TO ADDRESS is defined in OM only for the sake of the EDI Gateway processing in
the following ways:

1. For POI/POCI:

The SOLD TO ADDRESS is required in the POI transaction so that the Gateway can derive the
(parent level) customer. The address table lookup is performed on the addresses to derive the
CUSTOMER_ID or SOLD_TO_ORG_ID.

It did not matter that a primary or secondary address was given in the POI/POCI transactions,
since site usage is NOT examined. Just the address records are examined in the table lookup. The
table search is by the EDI Location Code and/or the address detail components.

The SOLD TO ADDRESS ID is not stored in OM base header table.

2. For POAO/POCAO (PO Acknowledgments):

Since the SOLD TO site table ID was not stored in the OM base tables, it is not available for the
PO Acknowledgments processing. The PO Acknowledgment transaction only looks up the
PRIMARY Sold To address, and then determines if the PO Acknowledgment transaction is
enabled for that site. This process would not know which non-primary address to use, since it was
not stored.

Work Around:

If a non-primary sold-to site identifier must be associated with the sales order, consider the
following.

1. Trading Partner Level

Add an alternate Sold To Site EDI location associated with the Trading Partner (Primary Sold to
Site) or on ALL the transactions for this Trading Partner.

Since you want to identify a Sold To site on each transaction, the following places will work since
the data in the Gateway is at the trading partner or trading partner/transaction level:

• Place an alternate Sold To EDI Location Code in the TP REFERENCE 1 and 2 in the
Gateway or

• Use the TP Header or TP Detail flexfields in the Gateway for the full address and the
EDI Location code.

These values will be constant for ALL PO Acknowledgements for this trading Partner for ALL
their PO Acknowledgments.

2. Transaction Level

At the transaction level consider the following:

In the POI/POCI transactions:

1. Use an appropriate site for the SOLD TO record in the POI/POCI transaction to allow the table
lookup using Address Derivation in the Gateway to find the CUSTOMER_ID and
SOLD_TO_ORG_ID

2. If you also have an alternate EDI Location Code that represents your non-primary SOLD TO
site, you can use descriptive flexfields for it. Place that EDI Location Code in a descriptive
flexfield that is in both in the POI /POCI transactions (so you can load it) and the POAO/POCAO
transactions (so you can extract it). Compare the two transactions to see which header flex fields
are in common.

In the POAO/POCAO transactions:

3. If you need the full address for this non-primary Sold To, you can review using the Extension
Columns method in the e-Commerce Gateway (see white paper in Metalink). The
EDI_LOCATION_CODE in the flexfield and the CUSTOMER_ID already in the transactions
may be keys to the address table to extract the entire address that will be placed in the extension
columns in the PO Acknowledgement transactions, or possibly overlay the SOLD TO address on
record 1400 if you do not need the sold to address.

The Gateway’s API may help on this table search if this is a public API.

(NOTE: Order Management must release patch 2474987 to enable these extension columns in the
transactions.)
In the EDI Translator:

4. Once the data is in the flexfield of the PO Acknowledgement transaction files, you need a
criterion in the EDI Translator on when and how to use the alternate EDI location code and/or the
full address in your extension columns, or on record 1400 Sold To data for data mapping in your
EDI Translator.

The POAO/POCAO transaction detail will still have only the address and EDI location code of
the primary address if you do not overlay it.

ENHANCEMENT on Order Management:

Retain the SOLD TO site’s table ID in the Sales Order Header so it may be extracted by the PO
Acknowledgments. This value is derived by the POI/POCI transactions. Currently the Sold To
address detail in the POI/POCI transactions is used to derive the CUSTOMER_ID and
SOLD_TO_ORG_ID. You need to retain this Sold To address ID so the customer has it available
for processing when it is extracted on the PO Acknowledgment transactions. At least get it in the
dbview so the customer may use that value in the Extension Column process in the e-Commerce
Gateway. Eventually the PO Acknowledgement should retrieve the SOLD TO address detail
based on the supplied Sold To address instead of always the primary Sold To address. This is a
different issue that the select statement is using the primary Sold To site that is enabled in the
Gateway Trading Partner set up.
Oracle e-Commerce Gateway
October 2002
Author: Bonnie Shebat Williams
Contributing Author:
Copyright © Oracle Corporation
All Rights Reserved Printed in the U.S.A.
This document is provided for informational purposes only and
the information herein is subject to change without notice.
Please report any errors herein to Oracle Corporation. Oracle
Corporation does not provide any warranties covering and
specifically disclaims any liability in connection with this
document.
Oracle is a registered trademark and Enabling the
Information Age, Oracle, Oracle EDI Gateway, Oracle e-Commerce Gateway
are trademarks of Oracle Corporation.

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
650.506.7000
Fax 650.506.7200
Copyright © Oracle Corporation 2002
All Rights Reserved