Professional Documents
Culture Documents
Instructor Guide
Instructor Guide
Instructor Guide
Foundation
Instructor Guide
D12333GC10
Edition 1.0
May 2001
D32897
Copyright © Oracle Corporation, 2001. All rights reserved.
This documentation contains proprietary information of Oracle Corporation. It is provided under a license
agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse
engineering of the software is prohibited. If this documentation is delivered to a U.S. Government Agency of the
Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:
Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software
and shall be deemed to be Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii)
of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988).
This material or any portion of it may not be copied in any form or by any means without the express prior
written permission of the Education Products group of Oracle Corporation. Any other copying is a violation of
copyright law and may result in civil and/or criminal penalties.
If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is
delivered with “Restricted Rights,” as defined in FAR 52.227-14, Rights in Data-General, including Alternate III
(June 1987).
The information in this document is subject to change without notice. If you find any problems in the
documentation, please report them in writing to Worldwide Education Services, Oracle Corporation, 500 Oracle
Parkway, Box SB-6, Redwood Shores, CA 94065. Oracle Corporation does not warrant that this document is
error-free.
Oracle and all references to Oracle Products are trademarks or registered trademarks of Oracle Corporation.
All other products or company names are used for identification purposes only, and may be trademarks of their
respective owners.
Author
Charles Pirnat, Tom Marik, Mani Rana, Prasanth Pala, Sachin Patel, Arvydas
Nakas
Oracle Tutor
Table of Contents
Before you begin this course, you should have the following qualifications:
Prerequisites
• Inventory
• Bills of Material
• Engineering
• Work in Process
• Purchasing
• Cost Management
2) Ability to perform queries and display data with SQL and SQL*Plus
Additional Publications
• readme files
• Oracle Magazine
This course uses simplified navigation paths, such as the following example, to
direct you through Oracle Applications.
(N) Invoice > Entry > Invoice Batches Summary (M) Query > Find (B) Approve
1. (N) From the Navigator window, select Invoice > Entry > Invoice Batches
Summary.
Notations :
(N) = Navigator
(M) = Menu
(I) = Icon
(H) = Hyperlink
(B) = Button
This course uses a “navigation path” convention to represent actions you perform
to find pertinent information in the Oracle Applications Help System.
1. In the navigation frame of the help system window, expand the General
Ledger entry.
4. Review the Enter Journals topic that appears in the document frame of the
help system window.
Getting Help
Oracle Applications provides you with a complete online help facility.
Whenever you need assistance, simply choose an item from the Help menu to
pinpoint the type of information you want.
1. Choose Window Help from the Help menu, click the Help button on the
toolbar, or hold down the Control key and type 'h'.
2. If the document frame contains a list of topics associated with the window,
click on a topic of interest to display more detailed information.
You can perform a search to find the Oracle Applications help information you
want. Simply enter your query in the text field located in the top-left frame of the
browser window when viewing help, then click the adjacent Find button.
Applications Architecture
Chapter 1 - Page 1
Applications Architecture
Applications Architecture
Applications Architecture
Chapter 1 - Page 2
Objectives
Objectives
Applications Architecture
Chapter 1 - Page 3
Applications Network Architecture
Forms
Browser Server
Admin
Browser Server
Applications Architecture
Chapter 1 - Page 4
Desktop Tier
Desktop Tier
Desktop
Browser
Client
Applet
Browser
®
Web Browser/JInitiator
The Forms Client Applet must run within a Java Virtual Machine (JVM) on
the desktop. For Oracle Applications the JVM is supplied by the JInitiator
program, which works in conjunction with the web browser.
Applications Architecture
Chapter 1 - Page 5
Forms Client Applet
Desktop
Web
Client Server
Applet
Forms
JAR files Server
The required and commonly used JAR files are downloaded from the Web
Server once at the beginning of the client’s first session. Afterwards it
remains in the browser’s local disk cache, ready for future sessions until
an updated version is released. All updates are installed on the application
tier and downloaded to the client automatically through the use of
JInitiator. Other less commonly used JAR files are downloaded as
needed.
Applications Architecture
Chapter 1 - Page 6
JInitiator
JInitiator
Desktop
Web
Client Server
Applet
Forms
Server
Once installed, Oracle JInitiator will run the Forms Client Applet and start
an Oracle Applications session.
Applications Architecture
Chapter 1 - Page 7
Application Tier
Application Tier
Application
Web
Server
Forms
Server
Concurrent Processing
Server
Reports
Server
Admin
Server
The Application Tier is the location of servers that provide the business
logic and code processing. This tier is sometimes referred to as the middle
tier. There are five servers that comprise the application tier:
This tier provides the communication between the desktop tier and the
database tier. The application tier also supports load balancing among
multiple forms servers to provide optimal scalability and processing.
Applications Architecture
Chapter 1 - Page 8
Web Server
Web Server
Application
Web
Server
Forms
Server
Concurrent Processing
Server
Reports
Server
Admin
Server
The Web Server processes the requests it receives over the network from
the desktop clients. The Web Server consists of an HTTP listener, load
balancer, and needed modules.
1 The HTTP listener accepts incoming HTTP requests (URLs) from
desktop tier (browsers). If possible, the HTTP listener services the
request itself, for example, by returning a simple HTML web page.
2 If the page referenced by the URL needs some kind of advanced
processing, e.g. PL/SQL or Java, the listener passes the request on
to the module.
3 The load balancer determines the least loaded Forms Server name
and passes the information back to the desktop tier by means of a
dynamically created HTML page.
4 The desktop tier can then connect directly to the Forms Server by
the name it has been provided.
5 From this point on, all communication is between the client tier and
the Forms Server with the Forms Server handling the
communication with the Oracle8i database.
Applications Architecture
Chapter 1 - Page 9
Forms Server
Forms Server
Application
Web
Server
Forms
Server
Concurrent Processing
Server
Reports
Server
Admin
Server
The Forms Server hosts the Oracle Applications forms and the forms
runtime engine. The Forms Server is a Developer Server component that
mediates the communication between the desktop tier and the Oracle8i
database, displaying client screens and causing changes in the database
records based on user actions. Data is cached on the forms server and
provided to the client as needed, such as when scrolling through multiple
order lines. The Forms Server communicates with the desktop tier in one
of three ways:
• a TCP/IP connection
• a standard HTTP connection
• a secure HTTPS connection
The Forms Server communicates with the Oracle8i database using Net8.
Applications Architecture
Chapter 1 - Page 10
Concurrent Processing Server
Application
Web
Server
Forms
Server
Concurrent Processing
Server
Reports
Server
Admin
Server
Applications Architecture
Chapter 1 - Page 11
Accessing Concurrent Processing Output
Application
Web
Server
Forms
Server
Concurrent Processing
Server
Reports
Server
Admin
Server
You can use system settings to control the size of the files and pages
passed through the system.
Applications Architecture
Chapter 1 - Page 12
Reports Server
Reports Server
Application
Web
Server
Forms
Server
Concurrent Processing
Server
Reports
Server
Admin
Server
Applications Architecture
Chapter 1 - Page 13
Administration Server
Administration Server
Application
Web
Server
Forms
Server
Concurrent Processing
Server
Reports
Server
Admin
Server
The administration server is the machine from which you maintain the data
in your Oracle Applications database. You carry out the following
operations from this server:
Applications Architecture
Chapter 1 - Page 14
Database Tier
Database Tier
Database
Data
Server
The database tier holds all the data stored and maintained by the Oracle
Applications system. It also contains some processing code that is stored
in the database to optimize performance. In Release 11i the database also
includes the Oracle Applications help files.
More specifically, the database tier contains Oracle8i Server files and an
Oracle Applications database instance that physically stores the tables,
indexes, and other database objects for your installation.
By definition the data server does not communicate directly with the
desktop tier, but rather with the servers on the application tier that mediate
these communications.
Applications Architecture
Chapter 1 - Page 15
Database Architecture
Database Architecture
Applications Architecture
Chapter 1 - Page 16
Oracle Applications Database Objects
Tables Triggers
Views
Packages
Indexes
Synonyms
Sequences
®
Data objects are used for storing and accessing business data. These
objects include tables, indexes, and sequences.
Code objects are used to process the data. Code objects are stored in
the database and used for optimizing application processing. Code objects
include triggers, packages, synonyms and views.
Applications Architecture
Chapter 1 - Page 17
APPS Schema
APPS Schema
APPS Schema
INV Schema
Views
Triggers
GL Schema
Synonyms
Packages
Each product’s schema grants full privileges to the APPS schema. The
APPS schema has synonyms to all base product tables and sequences.
Tthe APPS schema contains all code objects which access the data
objects in the product schemas.
Applications Architecture
Chapter 1 - Page 18
Additional Schemas
Additional Schemas
HR APPLSYSPUB APPLSYS
PAY APPS
AOL
PER
AD
The data objects for some products are combined within a single schema.
For example, tables for the Human Resources products (PER, PAY, etc.)
are combined under the HR schema; tables for the Application
Technology Layer products (AOL, AD, etc.) are combined under the
APPLSYS schema.
Applications Architecture
Chapter 1 - Page 19
Multiple Organizations Views
SO_Headers_All Table
Eastern Region
View
Western Region
View
Org_Id
Column
®
When you run any Oracle Applications product, you first choose an
organization either implicitly by choosing a responsibility or explicitly in a
Choose Organization window. After you have chosen a particular
organization, all forms and reports display information for that organization
only.
Applications Architecture
Chapter 1 - Page 20
Multiple Reporting Currencies
The Multiple Reporting Currencies (MRC) feature allows you to report and
maintain accounting records at the transaction level in more than one
functional currency. You do this by defining one or more reporting sets of
books in addition to your primary set of books. In your reporting sets of
books, you maintain records in a functional currency other than your
primary functional currency. The data for the reporting set of books is
stored in its own schema having its own tables and views.
Applications Architecture
Chapter 1 - Page 21
File System Architecture
(to Product (to Log / (to Oracle8 (to Oracle (to Oracle
Directories) Out and and Tools Applications 8i Files)
Java Files) Files) Database Data
Files)
Applications Architecture
Chapter 1 - Page 22
APPL_TOP
APPL_TOP
<env name>APPL
<db name>.
name>.env
env admin au fnd inv
The Oracle Applications file system contains the product files for Oracle
Applications itself. The top level directory path is defined in an
environment variable APPL_TOP.
Technical note:
The <db name>.env file is a very important file containing parameters
defining the Oracle Applications environment. Typically, Rapid Install
creates the <db name>.env file during the installation. Many of the
parameters located in the <db name>.env file define important directories
within the Oracle Applications file structure. For example, the APPL_TOP
directory is identified in the environment parameter APPL_TOP. Additional
parameters point to product top directories.
Applications Architecture
Chapter 1 - Page 23
APPL_TOP
APPL_TOP
<env name>APPL
<db name>.
name>.env
env admin au fnd inv
Each product has its own subdirectory. Since products can exist at
different version levels, the version is typically reflected in the subdirectory
name. Keep in mind that multiple releases and product versions cannot
exist in a single APPL_TOP directory.
Applications Architecture
Chapter 1 - Page 24
Product Directories
Product Directories
<PROD>_TOP
Applications Architecture
Chapter 1 - Page 25
Admin Directory
Admin Directory
<PROD>_TOP
driver: the upgrade driver files (.drv). The upgrade process is divided into
several phases. Phase driver files specify processing by phase. Example
files: glseq.drv creates sequences for the General Ledger (GL) product
during the sequence phase; glfile.drv, lists the GL files needed to run the
application, gldep.drv, specifies dependencies between GL and other
products so that upgrade jobs between products are processed in the
correct order.
odf: the object description files used to create tables and other database
objects.
sql: the SQL scripts and PL/SQL scripts used to upgrade data.
Applications Architecture
Chapter 1 - Page 26
Bin Directory
Bin Directory
<PROD>_TOP
The concurrent programs, other C language programs and shell scripts for
each product are stored in its respective bin directory. Of particular
importance to Oracle Applications are the FND_TOP/bin and AD_TOP/bin
directories. Some of the programs you will find here include:
Applications Architecture
Chapter 1 - Page 27
Forms Directory
Forms Directory
<PROD>_TOP
US
The forms directory contains Oracle Forms files. Oracle Forms may be
portable source files (.fmb files) or generated runtime files (.fmx files). The
installation utility generates form files by converting the .fmb source file to
.fmx runtime files. The source files are stored in AU_TOP/forms so
generation of runtime files can be done more easily.
Applications Architecture
Chapter 1 - Page 28
Help Directory
Help Directory
<PROD>_TOP
US
bin html lib mesg plsql sql
The help directory contains the online help source files. These files are
imported into the database during an install or an upgrade to optimize the
performance of online help. Under the help directory, there is a language
directory to store the help files for each language in which your are
running Oracle Applications.
Applications Architecture
Chapter 1 - Page 29
HTML Directory
HTML Directory
<PROD>_TOP
The html subdirectory contains HTML, Javascript, and Java Server Page
files used by various products. These files are used primarily by products
that have a Self-Service interface. The Javascript (.js) and Java Server
Page (.jsp) files are kept in the main directory. HTML files are kept in
subdirectories by language.
Applications Architecture
Chapter 1 - Page 30
Include Directory
Include Directory
<PROD>_TOP
The include directory contains header (.h) files. These files may be
required by the files contained in the lib directory for the relinking process.
Applications Architecture
Chapter 1 - Page 31
Java Directory
Java Directory
<PROD>_TOP
make jar
*.jar
®
For each product that uses Java, there will be one or more Java ARchive
(JAR) files under the jar directory. There will also be a product specific
.dep file under the make directory that specifies the dependencies
between this product and other products using Java.
Applications Architecture
Chapter 1 - Page 32
Lib Directory
Lib Directory
<PROD>_TOP
At some time, you may need to relink Applications programs, for example
if you upgrade the Oracle8i server. The lib subdirectory contains files
pertinent to the process of relinking Applications programs:
library file: (.a file) the compiled C code common to that product’s
programs.
makefile: (.mk file) specifying how to relink the .o file(s) with the .a file(s)
to create the newly linked C programs.
Applications Architecture
Chapter 1 - Page 33
Log and Out Directories
<PROD>_TOP
The log directory holds concurrent log files from each concurrent request
as well as the concurrent manager log files. The out directory holds the
concurrent report output files.
The default locations for these two files are <PROD>_TOP/log and
<PROD>_TOP/out, but you can change the default directory and the
default file names by changing the APPLLOG and APPLOUT environment
variables in the <db name>.env file.
You can consolidate all product log and out files into one directory by
defining the APPLCSF environment variable in the <db name>.env. This
parameter identifies a directory to hold all log and output files.
Applications Architecture
Chapter 1 - Page 34
Media Directory
Media Directory
<PROD>_TOP
The Applications Forms Client Applet displays graphics in the form of .gif
files. The media directory contains all product specific .gif files.
Applications Architecture
Chapter 1 - Page 35
Mesg Directory
Mesg Directory
<PROD>_TOP
These messages can be translated into different languages and are stored
in message files separate from the forms and programs. Each product’s
mesg directory contains one or more files for the language-specific
messages that the product uses:
Applications Architecture
Chapter 1 - Page 36
Patch Directory
Patch Directory
<PROD>_TOP
• driver: contains the driver files (.drv). Phase driver files specify
processing by phase.
• sql: contains sql (.sql) and PL/SQL (.pls) scripts used to update the
database.
• odf: contains object description files (.odf) to update the data
model.
• import: contains lct and slt files to update the seed data.
Applications Architecture
Chapter 1 - Page 37
PLSQL and Resource Directories
<PROD>_TOP
• The files in the plsql subdirectory (.pll files) are used by Oracle
Reports.
• The files in the resource subdirectory (.pll and .plx files) are used by
Oracle Forms.
After these files are unloaded, they are moved to equivalent subdirectories
under the AU_TOP directory.
Applications Architecture
Chapter 1 - Page 38
Reports Directory
Reports Directory
<PROD>_TOP
US
This directory contains the report files for this product. For each report
there is a portable binary .rdf file. The AD Administration utility can
regenerate these reports by converting them to their executable format
(.rex files) and then back to portable format. This is usually recommended
so the PL/SQL is optimally compiled for the platform.
Applications Architecture
Chapter 1 - Page 39
SQL Directory
SQL Directory
<PROD>_TOP
Applications Architecture
Chapter 1 - Page 40
AD Directory
AD Directory
<env name>APPL
<db name>.
name>.env
env admin au ad fnd
Applications Architecture
Chapter 1 - Page 41
AU Directory
AU Directory
<env name>APPL
<db name>.
name>.env
env admin au ad fnd
Applications Architecture
Chapter 1 - Page 42
Admin Directory
Admin Directory
<env name>APPL
<db name>.
name>.env
env admin au ad fnd
11.5.0
adovars .env
adovars. adrelink preupg restart
adconfig..txt
adconfig adsetenv log <db name>
applprod.. txt
applprod out
applora.. txt
applora
log out restart
®
Most AD programs put their log, out and restart files in a separate <db
name> subdirectory. The value for <db name> comes from the
TWO_TASK or ORACLE_SID parameters. Some programs when run from
the command line, cannot access the <db name> value and therefore
store their log, out, and restart files in the log, out and restart directories
directly under the APPL_TOP/admin directory.
Applications Architecture
Chapter 1 - Page 43
Admin Directory Text Files
<env name>APPL
<db name>.
name>.env
env admin au ad fnd
11.5.0
adovars .env
adovars. adrelink preupg restart
adconfig..txt
adconfig adsetenv log <db name>
applprod.. txt
applprod out
applora.. txt
applora
log out restart
®
There are many text files stored under the admin directory. These files are
used by many different utilities. Some of the files include:
Applications Architecture
Chapter 1 - Page 44
Common Components Directory
oracle apps.zip
Apache JRE118
*.zip
apps US WebTools
Unlike previous releases, Release 11i supports the placement of the java
directory (JAVA_TOP) and the HTML directory (OAH_TOP) anywhere in
your file system.
Applications Architecture
Chapter 1 - Page 45
Copying Java Files: apps.zip
java
au
11.5.0 apps.zip jdbc xml oracle
apps
java
fa gl
apps.zip
jar jar
Applications Architecture
Chapter 1 - Page 46
Technology Stack Directories
(Oracle8i)
java
Apache modplsql BC4J
reports60
jserv perl
Applications Architecture
Chapter 1 - Page 47
Database Data Files
Disk 1
cntrl01
log01a
log02a
Disk 2 rbs01 Disk 3
cntrl02
cntrl03
log01b Disk 4
log02b product
system01 temp01 data
ctxd01
product
index
The <env name>DATA file system contains the .dbf files that comprise the
Oracle Applications database itself. The Rapid Install utility installs all the
system, data, and index files across four disks. You can specify mount
points and directory names during the installation. Oracle Applications
Release 11i uses an Oracle8i database server.
Applications Architecture
Chapter 1 - Page 48
File Types
File Types
The Oracle Applications file system contains a variety of files. This list
describes some of the types of files you will find in the file system:
Applications Architecture
Chapter 1 - Page 49
File Types
File Types
Applications Architecture
Chapter 1 - Page 50
Naming Standards
Naming Standards
• Database objects
• Form file standards
• PL/SQL packages and procedures
• Reserved words
INSTRUCTOR NOTE:
Applications Architecture
Chapter 1 - Page 51
Database Objects
Database Objects
Tables: prod is the short name of the product. objects is the object stored
in the table and should be plural. The table name should be 20 characters
or less.
View: table is the name of the root table the view is based on. The criteria
is a qualifier of the objects shown by the view. Use the criteria qualifier if
using table name alone is not unique, the view is based on a join of 2 or
more tables, the view contains a WHERE clause, or the view is unusual.
Triggers: table is the name of the table on which the trigger is based, and
i is a unique ID starting at 1.
Synonyms: Your synonym should have the same name as the table or
view it is based on.
Constraints: _PK is for Primary Keys. _Ui is for unique indexes. _Fi is
for foreign keys. table is the name of the table on which the constraint is
created, while I is a unique id starting at 1. You should name all of your
constraints so that you can enable or disable them easily.
Applications Architecture
Chapter 1 - Page 52
Database Objects
Database Objects
Table Handler Package and Procedures: table is the name of the table
on which the package acts. The package name should be 24 characters
or less.
Forms PL/SQL Program Units: prod is the product short name, and
verb_noun is a brief explanation of the purpose.
Applications Architecture
Chapter 1 - Page 53
Database Objects
Database Objects
Applications Architecture
Chapter 1 - Page 54
Forms File Standards
fmb is the suffix for the source binary file, and fmx is the
suffix for the executable binary file.
All file names must be no greater than 8 chars in length plus a three
character extension (FILENAME.ext). The files names must be all caps
except for the extension. This will provide a consistent naming scheme
across all platforms.
Applications Architecture
Chapter 1 - Page 55
PL/SQL Packages, Procedures and Source Files
End all SQL and PL/SQL files with the following lines:
COMMIT;
EXIT;
ppp is the two or three character product short name, gg is a one or two
character abbreviation for the functional group, and xxx is a character
abbreviation for the explanation of the purpose. s indicate a specification
file, and b indicates a body file. Each file defines only one package
specification or body.
Applications Architecture
Chapter 1 - Page 56
Reserved Words
Reserved Words
Applications Architecture
Chapter 1 - Page 57
Summary
Summary
Applications Architecture
Chapter 1 - Page 58
Applications Basics
Chapter 2
Applications Basics
Chapter 2 - Page 1
Applications Basics
Applications Basics
Applications Basics
Chapter 2 - Page 2
Objectives
Objectives
Applications Basics
Chapter 2 - Page 3
Basic Applications Tools
Applications Basics
Chapter 2 - Page 4
Basic Applications Tools
Applications Basics
Chapter 2 - Page 5
Overview of Concurrent Processing
• Concurrent requests
• Concurrent programs
• Concurrent managers
For forms-based users, they can run reports from the data entered into the
system. When a report is needed, the command to run the report is a
concurrent request. The program that generates the report is a concurrent
program. Concurrent programs are controlled by a concurrent manager.
Applications Basics
Chapter 2 - Page 6
Overview of Flexfields
Overview of Flexfields
• Key flexfields
• Descriptive flexfields
Applications Basics
Chapter 2 - Page 7
Overview of Alerts
Overview of Alerts
• Event alerts
• Periodic alerts
Oracle Alert is your complete exception control solution. You can define
one of two types of alerts: an event alert or a periodic alert. An event alert
immediately notifies you of activity in your database as it occurs. A
periodic alert, on the other hand, checks the database for information
according to a schedule you define.
Applications Basics
Chapter 2 - Page 8
Overview of Workflow
Overview of Workflow
Applications Basics
Chapter 2 - Page 9
Summary
Summary
Applications Basics
Chapter 2 - Page 10
ERDs and Applications
Technology
Chapter 3
Objectives
ERDs are conceptual models that show entities and relationships. While it
really is that simple, we should answer the question, why?
What is an Entity?
• An Entity is:
– “Something” of significance to the business
about which data must be known.
– A name for the things that you can list.
– Usually a noun.
• Examples: objects, events
• Entities have instances.
Attributes
Relationships
In Oracle Applications, relationships are the primary key, foreign keys, and
unique indexes that are maintained on the table (entity).
Relationships
JOB manager
EMPLOYEE cook
Shintaro waitress
dish washer
Jill financial controller
Adam
Ahmed porter
waiter
Maria
piano player
Numerical observation:
• All EMPLOYEES have a JOB
• No EMPLOYEE has more than one JOB
• Not all JOBS are held by an EMPLOYEE
• Some JOBS are held by more than one EMPLOYEE
®
• Drawn as a “softbox”
• Name singular
EMPLOYEE JOB
• Name inside
ELECTION
• Neither size,
nor position
has a special TICKET
meaning ORDER
RESERVATION
JOB ASSIGNMENT
EMPLOYEE JOB
* Family Name * Title
* Address o Description
o Birth Date
o Shoe Size
o Email
EMPLOYEE JOB
has
held by
mandatory: optional:
held by
P split into Q
part of
Let's start with the basics. Oracle Applications ERDs do not use
"softboxes". They use regular rectangles. This has no impact on reading
Oracle Applications ERDs other than the shape change.
At the top of each entity, or Table, will be the Table Name. Beneath the
Table Name is the primary key columns for that Table. There will always
be at least 1 column, and there may be several.
Table Name 1
Foreign Key
Constraint Recursive
Foreign Key
Delete Rule
Indicator
Table Name 2
NOTE: Oracle Applications ERDs are not always clear on foreign key
relationships. For example, Table 2's primary key is the foreign key into
Table 1 even though it may not be part of Table 1's primary key. As such,
the foreign key relationship would be implied rather than explicitly
described.
Table Name 3
Oracle Applications ERDs use an arc. The arc, shown above with circles
and an arc, is used to specify that, for any given row in a table, a value
must be entered in one of the arc columns. The remaining columns within
the arc must be null.
On the next several pages, I’ve reproduced the slides from the Applied
Technology ERDs. The single best source of the actual diagrams is the
AOL Technical Reference Manual (TRM). An online copy of that TRM has
been provided in your student materials. Reference that as a better and
more complete source.
NOTE: Over the course of the next several slides, we are going to
reproduce the ERD diagrams for Applications Technology objects.
Because of the limitation of Powerpoint, these diagrams will be simplified
compared to normal ERDs.
Key Flexfields
FND_IFS
FND_FVS FND_FVRS
FND_FERL FND_FVR
FND_FVQ
FND_FVRL
FND_V AT
FND_FIRL
FND_CIFS
FND_S AT FND_CIF
FND_IF
The diagram above shows the Key Flexfields ERD. Because of its size,
we had to compress its presentation. The following listing gives you the
information key for the diagram above.
FND_SAV FND_SEGMENT_ATTRIBUTE_VALUES
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
ID_FLEX_NUM
APPLICATION_COLUMN_NAME
SEGMENT_ATTRIBUTE_TYPE
FND_SFA FND_SHORTHAND_FLEX_ALIASES
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
FND_IFSTR FND_ID_FLEX_STRUCTURES
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
ID_FLEX_NUM
FND_FVS FND_FLEX_VALUE_SETS
Primary Keys: FLEX_VALUE_SET_ID
FND_FVRS FND_FLEX_VALIDATION_RULE_STATS
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
ID_FLEX_NUM
FND_FERL FND_FLEX_EXCLUDE_RULE_LINES
Primary Keys: RULE_LINE_ID
FND_FVR FND_FLEX_VALIDATION_RULES
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
ID_FLEX_NUM
FLEX_VALIDATION_RULE_NAME
FND_FVQ FND_FLEX_VALIDATION_QUALIFIERS
Primary Keys: FLEX_VALUE_SET_ID
ID_FLEX_APPLICATION_ID
ID_FLEX_CODE
SEGMENT_ATTRIBUTE_TYPE
VALUE_ATTRIBUTE_TYPE
FND_FVRL FND_FLEX_VALIDATION_RULE_LINES
Primary Keys: RULE_LINE_ID
FND_VAT FND_VALUE_ATTRIBUTE_TYPES
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
SEGMENT_ATTRIBUTE_TYPE
FND_FIRL FND_FLEX_INCLUDE_RULE_LINES
Primary Keys: RULE_LINE_ID
FND_CIFS FND_COMPILED_ID_FLEX_STRUCTS
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
ID_FLEX_NUM
COMPILER_VERSION_NUM
SEQUENCE
LANGUAGE
FND_SAT FND_SEGMENT_ATTRIBUTE_TYPES
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
SEGMENT_ATTRIBUTE_TYPE
FND_CIF FND_COMPILED_ID_FLEXS
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
COMPILER_VERSION_NUM
SEQUENCE
LANGUAGE
FND_IF FND_ID_FLEXS
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
FND_APP FND_APPLICATION
Primary Keys: APPLICATION_ID
FND_TAB FND_TABLES
Primary Keys: APPLICATION_ID
TABLE_ID
WF_RPV WF_RUNNABLE_PROCESSES_V
FND_FWP FND_FLEX_WORKFLOW_PROCESSES
Descriptive Flexfields
FND_DESCR_FLEX_COLUMN_USAGES
FND_DESCRIPTIVE _FLEXS
FND_TABLES
FND_APP LICATION
The diagram above shows the Descriptive Flexfields ERD. Because of its
size, we had to compress its presentation. The following listing gives you
the information key for the diagram above.
Table Name
FND_DESCR_FLEX_COLUMN_USAGES
Primary Keys: APPLICATION_ID
DESCRIPTIVE_FLEXFIELD_NAME
DESCRIPTIVE_FLEX_CONTEXT_CODE
APPLICATION_COLUMN_NAME
FND_FLEX_VALUE_SETS
Primary Keys: FLEX_VALUE_SET_ID
FND_DESCR_FLEX_CONTEXTS
Primary Keys: APPLICATION_ID
DESCRIPTIVE_FLEXFIELD_NAME
DESCRIPTIVE_FLEX_CONTEXT_CODE
FND_COMPILED_DESCRIPTIVE_FLEXS
Primary Keys: APPLICATION_ID
FND_DEFAULT_CONTEXT_FIELDS
Primary Keys: APPLICATION_ID
DESCRIPTIVE_FLEXFIELD_NAME
DEFAULT_CONTEXT_FIELD_NAME
FND_DESCRIPTIVE_FLEXS
Primary Keys: APPLICATION_ID
DESCRIPTIVE_FLEXFIELD_NAME
FND_TABLES
Primary Keys: APPLICATION_ID
TABLE_ID
FND_APPLICATION
Primary Keys: APPLICATION_ID
Flexfield Values
FND_FVH FND_FVS
FND_IFS
FND_FVNH
FND_FH
FND_FV
FND_FVE
FND_FVRL
FND_FVR
FND_FVRU
The diagram above shows the Flexfield Value Sets ERD. Because of its
size, we had to compress its presentation. The following listing gives you
the information key for the diagram above.
FND_FVS FND_FLEX_VALUE_SETS
Primary Keys: FLEX_VALUE_SET_ID
FND_IFS FND_ID_FLEX_SEGMENTS
Primary Keys: APPLICATION_ID
ID_FLEX_CODE
ID_FLEX_NUM
APPLICATION_COLUMN_NAME
FND_FVNH FND_FLEX_VALUE_NORM_HIERARCHY
FND_FH FND_FLEX_HIERARCHIES
Primary Keys: FLEX_VALUE_SET_ID
HIERARCHY_ID
FND_FV FND_FLEX_VALUES
Primary Keys: FLEX_VALUE_ID
FND_FVE FND_FLEX_VALIDATION_EVENTS
Primary Keys: FLEX_VALUE_SET_ID
EVENT_CODE
FND_FVRL FND_FLEX_VALUE_RULE_LINES
Primary Keys: FLEX_VALUE_RULE_ID
INCLUDE_EXCLUDE_INDICATOR
FLEX_VALUE_LOW
FLEX_VALUE_HIGH
FND_FVR FND_FLEX_VALUE_RULES
Primary Keys: FLEX_VALUE_RULE_ID
FND_FVRU FND_FLEX_VALUE_RULE_USAGES
Primary Keys: APPLICATION_ID
RESPONSIBILITY_ID
FLEX_VALUE_RULE_ID
FND_RESP FND_RESPONSIBILITY
Primary Keys: APPLICATION_ID
RESPONSIBILITY_ID
FND_TAB FND_TABLES
Primary Keys: APPLICATION_ID
TABLE_ID
Concurrent Managers
FND_CCR
FND_CCL
FND_CQC
FND_CR
FND_CQ
FND_APP
®
The diagram above shows the Concurrent Managers ERD. Because of its
size, we had to compress its presentation. The following listing gives you
the information key for the diagram above.
FND_CCL FND_CONCURRENT_COMPLEX_LINES
Primary Keys: APPLICATION_ID
COMPLEX_RULE_ID
COMPLEX_RULE_LINE_ID
FND_CPG FND_CONCURRENT_PROGRAMS
Primary Keys: APPLICATION_ID
CONCURRENT_PROGRAM_ID
FND_CRC FND_CONCURRENT_REQUEST_CLASS
Primary Keys: APPLICATION_ID
REQUEST_CLASS_ID
FND_USER FND_USER
Primary Keys: USER_ID
FND_CQC FND_CONCURRENT_QUEUE_CONTENT
Primary Keys: QUEUE_APPLICATION_ID
CONCURRENT_QUEUE_ID
TYPE_CODE
TYPE_APPLICATION_ID
TYPE_ID
FND_CR FND_CONCURRENT_REQUESTS
Primary Keys: REQUEST_ID
FND_NDS FND_NODES
Primary Keys: NODE_NAME
FND_CPR FND_CONCURRENT_PROCESSES
Primary Keys: CONCURRENT_PROCESS_ID
FND_DG FND_DATA_GROUPS
Primary Keys: DATA_GROUP_ID
FND_CQP FND_CONCURRENT_QUEUE_PARAMS
Primary Keys: QUEUE_APPLICATION_ID
CONCURRENT_QUEUE_ID
NAME
FND_CQ FND_CONCURRENT_QUEUES
Primary Keys: APPLICATION_ID
CONCURRENT_QUEUE_ID
FND_CPP FND_CONC_PROCESSOR_PROGRAMS
Primary Keys: PROCESSOR_APPLICATION_ID
CONCURRENT_PROCESSOR_ID
PROGRAM_APPLICATION_ID
FND_CPS FND_CONCURRENT_PROCESSORS
Primary Keys: APPLICATION_ID
CONCURRENT_PROCESSOR_ID
FND_CQS FND_CONCURRENT_QUEUE_SIZE
Primary Keys: QUEUE_APPLICATION_ID
CONCURRENT_QUEUE_ID
PERIOD_APPLICATION_ID
CONCURRENT_TIME_PERIOD_ID
FND_CTS FND_CONCURRENT_TIME_PERIODS
Primary Keys: APPLICATION_ID
CONCURRENT_TIME_PERIOD_ID
FND_APP FND_APPLICATION
Primary Keys: APPLICATION_ID
Concurrent Processing
FND_CPA FND_CRA FND_RRL
FND_CR
FND_CD FND_RES
FND_CRC FND_DGU
FND_USR FND_CRC
FND_CPS FND_CPG
FND_EXE
FND_CRA FND_CONC_REQUEST_ARGUMENTS
Primary Keys: REQUEST_ID
FND_RRL FND_RUN_REQ_LANGUAGES
Primary Keys: PARENT_REQUEST_ID
NLS_LANGUAGE
FND_CR FND_CONCURRENT_REQUESTS
Primary Keys: REQUEST_ID
FND_CD FND_CONFLICT_DOMAINS
Primary Keys: CD_ID
FND_CRC FND_CONC_RELEASE_CLASSES
Primary Keys: APPLICATION_ID
RELEASE_CLASS_ID
FND_DGU FND_DATA_GROUP_UNITS
Primary Keys: APPLICATION_ID
DATA_GROUP_ID
FND_LOG FND_LOGINS
Primary Keys: LOGIN_ID
FND_DG FND_DATA_GROUPS
Primary Keys: DATA_GROUP_ID
FND_OID FND_ORACLE_USERID
Primary Keys: ORACLE_ID
FND_USR FND_USER
Primary Keys: USER_ID
FND_CRC FND_CONCURRENT_REQUEST_CLASS
Primary Keys: APPLICATION_ID
REQUEST_CLASS_ID
FND_CPS FND_CONCURRENT_PROGRAM_SERIAL
Primary Keys: RUNNING_APPLICATION_ID
RUNNING_CONCURRENT_PROGRAM_ID
TO_RUN_APPLICATION_ID
TO_RUN_CONCURRENT_PROGRAM_ID
FND_CPG FND_CONCURRENT_PROGRAMS
Primary Keys: APPLICATION_ID
CONCURRENT_PROGRAM_ID
FND_EXE FND_EXECUTABLES
FND_CONC_REL_CONJ_MEMBE RS FND_CONC_RELEASE_DISJS
FND_CONC_REL_DISJ _MEMBE RS
Table Name
FND_CONC_RELEASE_CLASSES
Primary Keys: APPLICATION_ID
RELEASE_CLASS_ID
FND_CONC_REL_CONJ_MEMBERS
Primary Keys: CLASS_APPLICATION_ID
RELEASE_CLASS_ID
DISJUNCTION_APPLICATION_ID
DISJUNCTION_ID
FND_CONC_RELEASE_DISJS
Primary Keys: APPLICATION_ID
DISJUNCTION_ID
FND_CONC_REL_DISJ_MEMBERS
Primary Keys: DISJUNCTION_APPLICATION_ID
FND_CONC_RELEASE_STATES
Primary Keys: APPLICATION_ID
CONCURRENT_STATE_ID
FND_CONC_RELEASE_PERIODS
Primary Keys: APPLICATION_ID
CONCURRENT_PERIOD_ID
FND_CONC_STATE_LOOKUPS
Primary Keys: LOOKUP_TYPE_ID
LOOKUP_VALUE
FND_CONC_STATE_LOOKUP_TYPES
Primary Keys: LOOKUP_TYPE_ID
FND_RS
FND_RSP FND_RSA
FND_RR FND_DF
FND_CPG FND_RES
FND_APP
®
FND_RS FND_REQUEST_SETS
Primary Keys: APPLICATION_ID
REQUEST_SET_ID
FND_RSS FND_REQUEST_SET_STAGES
Primary Keys: SET_APPLICATION_ID
REQUEST_SET_ID
REQUEST_SET_STAGE_ID
FND_RG FND_REQUEST_GROUPS
Primary Keys: APPLICATION_ID
REQUEST_GROUP_ID
FND_RSP FND_REQUEST_SET_PROGRAMS
Primary Keys: SET_APPLICATION_ID
REQUEST_SET_ID
REQUEST_SET_PROGRAM_ID
FND_RSA FND_REQUEST_SET_PROGRAM_ARGS
Primary Keys: APPLICATION_ID
REQUEST_SET_ID
REQUEST_SET_PROGRAM_ID
DESCRIPTIVE_FLEX_APPL_ID
DESCRIPTIVE_FLEXFIELD_NAME
APPLICATION_COLUMN_NAME
FND_RR FND_RUN_REQUESTS
Primary Keys: PARENT_REQUEST_ID
REQUEST_SET_PROGRAM_ID
SET_APPLICATION_ID
REQUEST_SET_ID
FND_DF FND_DESCRIPTIVE_FLEXS
Primary Keys: APPLICATION_ID
DESCRIPTIVE_FLEXFIELD_NAME
FND_CPG FND_CONCURRENT_PROGRAMS
Primary Keys: APPLICATION_ID
CONCURRENT_PROGRAM_ID
FND_RES FND_RESPONSIBILITY
FND_APP FND_APPLICATION
Primary Keys: APPLICATION_ID
Workflow
WF_AA WF_AAV
WF_IAS
WF_ITY WF_ITM
WF_IA WF_IAV
WF_MA WF_NA
WF_MS G WF_NO T
WF_RR WF_RRA
The diagram above shows the Workflow ERD. Because of its size, we
had to compress its presentation. The following listing gives you the
information key for the diagram above.
WF_AAV WF_ACTIVITY_ATTR_VALUES
Primary Keys: PROCESS_ACTIVITY_ID
NAME
WF_ACT WF_ACTIVITIES
Primary Keys: ITEM_TYPE
NAME
VERSION
WF_PA WF_PROCESS_ACTIVITIES
WF_AT WF_ACTIVITY_TRANSISTIONS
Primary Keys: FROM_PROCESS_ACTIVITY
RESULT_CODE
TO_PROCESS_ACTIVITY
WF_IAS WF_ITEM_ACTIVITY_STATUSES
Primary Keys: ITEM_TYPE
ITEM_KEY
PROCESS_ACTIVITY
WF_ITY WF_ITEM_TYPES
Primary Keys: NAME
WF_ITM WF_ITEMS
Primary Keys: ITEM_TYPE
ITEM_KEY
WF_IA WF_ITEM_ATTRIBUTES
Primary Keys: ITEM_TYPE
NAME
WF_IAV WF_ITEM_ATTRIBUTE_VALUES
Primary Keys: ITEM_TYPE
ITEM_KEY
NAME
WF_MA WF_MESSAGE_ATTRIBUTES
Primary Keys: MESSAGE_TYPE
MESSAGE_NAME
NAME
WF_NA WF_NOTIFICATION_ATTRIBUTES
Primary Keys: NOTIFICATION_ID
NAME
WF_MSG WF_MESSAGES
Primary Keys: TYPE
WF_NOT WF_NOTIFICATIONS
Primary Keys: NOTIFICATION_ID
WF_RR WF_ROUTING_RULES
Primary Keys: RULE_ID
WF_RRA WF_ROUTING_RULE_ATTRIBUTES
Primary Keys: RULE_ID
NAME
TYPE
Function Security
FND_MENUS
FND_APPLICATION
The diagram above shows the Function Security ERD. Because of its
size, we had to compress its presentation. The following listing gives you
the information key for the diagram above.
Table Name
FND_MENU_ENTRIES
Primary Keys: MENU_ID
ENTRY_SEQUENCE
FND_ENABLED_PLSQL
Primary Keys: PLSQL_TYPE
PLSQL_NAME
FND_MENUS
Primary Keys: MENU_ID
FND_FORM_FUNCTIONS
Primary Keys: FUNCTION_ID
FND_RESP_FUNCTIONS
Primary Keys: APPLICATION_ID
FND_FORM
Primary Keys: APPLICATION_ID
FORM_ID
FND_RESPONSIBILITY
Primary Keys: APPLICATION_ID
RESPONSIBILITY_ID
FND_APPLICATION
Primary Keys: APPLICATION_ID
Login Security
FND_URG FND_RES
FND_S G FND_APP
FND_DGU FND_AS
FND_LSF FND_LR
FND_LOG FND_UL
FND_USER
The diagram above shows the Login Security ERD. Because of its size,
we had to compress its presentation. The following listing gives you the
information key for the diagram above.
FND_RES FND_RESPONSIBILITY
Primary Keys: APPLICATION_ID
RESPONSIBILITY_ID
FND_SG FND_SECURITY_GROUPS
Primary Keys: SECURITY_GROUP_ID
FND_APP FND_APPLICATION
Primary Keys: APPLICATION_ID
FND_AS FND_APPLICATION_SERVERS
Primary Keys: SERVER_ID
FND_OID FND_ORACLE_USERID
Primary Keys: ORACLE_ID
FND_DG FND_DATA_GROUPS
Primary Keys: DATA_GROUP_ID
FND_SESS FND_SESSIONS
Primary Keys: SESSION_ID
FND_LRF FND_LOGIN_RESP_FORMS
Primary Keys: LOGIN_ID
LOGIN_RESP_ID
FORM_APPL_ID
FORM_ID
START_TIME
FND_LR FND_LOGIN_RESPONSIBILITIES
Primary Keys: LOGIN_ID
LOGIN_RESP_ID
FND_LOG FND_LOGINS
Primary Keys: LOGIN_ID
FND_UL FND_UNSUCCESSFUL_LOGINS
Primary Keys: USER_ID
ATTEMPT_TIME
LOGIN_NAME
TERMINAL_ID
FND_USER FND_USER
Primary Keys: USER_ID
AuditTrail
FND_COLUMNS FND_AUDIT_COLUMNS
FND_TABLES FND_AUDIT_TABLES
FND_AUDIT_GROUPS
The diagram above shows the AuditTrail ERD. Because of its size, we
had to compress its presentation. The following listing gives you the
information key for the diagram above.
Table Name
FND_ORACLE_USERID
Primary Keys: ORACLE_ID
FND_AUDIT_SCHEMA
Primary Keys: SCHEMA_ID
FND_COLUMNS
Primary Keys: APPLICATION_ID
TABLE_ID
COLUMN_ID
FND_AUDIT_COLUMNS
Primary Keys: TABLE_APP_ID
TABLE_ID
COLUMN_ID
SCHEMA_ID
FND_AUDIT_TABLES
Primary Keys: AUDIT_GROUP_ID
AUDIT_GROUP_APP_ID
TABLE_APP_ID
TABLE_ID
FND_AUDIT_GROUPS
Primary Keys: APPLICATION_ID
AUDIT_GROUP_ID
User Profiles
FND_P RO FILE_OPTION_VALUE S
FND_USE R_ RE SP_GROUPS
FND_RES PONSIBILITY
FND_APPLICATION
The diagram above shows the User Profiles ERD. Because of its size, we
had to compress its presentation. The following listing gives you the
information key for the diagram above.
Table Name
FND_PROFILE_OPTION_VALUES
Primary Keys: APPLICATION_ID
PROFILE_OPTION_ID
LEVEL_ID
LEVEL_VALUE
LEVEL_VALUE_APPLICATION_ID
FND_USER_RESP_GROUPS
Primary Keys: USER_ID
RESPONSIBILITY_ID
RESPONSIBILITY_APPLICATION_ID
SECURITY_GROUP_ID
FND_PROFILE_OPTIONS
Primary Keys: APPLICATION_ID
PROFILE_OPTION_ID
FND_RESPONSIBILITY
Primary Keys: APPLICATION_ID
RESPONSIBILITY_ID
FND_APPLICATION
Primary Keys: APPLICATION_ID
FND_DOC_S EQ_AUDIT
FND_FOLDER_COLUMNS
Table Name
FND_DOC_SEQUENCE_ASSIGNMENTS
Primary Keys: DOC_SEQUENCE_ASSIGNMENT_ID
FND_DOC_SEQUENCE_CATEGORIES
Primary Keys: APPLICATION_ID
CODE
FND_DOC_SEQUENCE_AUDIT
Primary Keys: DOC_SEQUENCE_ID
DOC_SEQUENCE_VALUE
FND_DOC_SEQUENCE_USERS
Primary Keys: DOC_SEQUENCE_ID
DOC_SEQUENCE_ASSIGNMENT_ID
FND_DOCUMENT_SEQUENCES
Primary Keys: DOC_SEQUENCE_ID
FND_DEFAULT_FOLDERS
Primary Keys: FOLDER_ID
FND_FOLDER_COLUMNS
Primary Keys: FOLDER_ID
SEQUENCE
FND_FOLDERS
Primary Keys: FOLDER_ID
FND_USER_DESKTOP_OBJECTS
Primary Keys: DESKTOP_OBJECT_ID
FND_DESKTOP_OBJECTS
Primary Keys: DESKTOP_OBJECT_ID
Attachments
FND_AD
FND_DOCT FND_DST
FND_DOC FND_DLT
FND_DLR
FND_DC FND_DD
FND_DCU FND_DE
The diagram above shows the Attachments ERD. Because of its size, we
had to compress its presentation. The following listing gives you the
information key for the diagram above.
FND_DOCT FND_DOCUMENTS_TL
Primary Keys: DOCUMENT_ID
LANGUAGE
FND_DST FND_DOCUMENTS_SHORT_TEXT
Primary Keys: MEDIA_ID
FND_DOC FND_DOCUMENTS
Primary Keys: DOCUMENT_ID
FND_DLT FND_DOCUMENTS_LONG_TEXT
Primary Keys: MEDIA_ID
FND_DC FND_DOCUMENT_CATEGORIES
Primary Keys: CATEGORY_ID
FND_DD FND_DOCUMENT_DATATYPES
Primary Keys: DATATYPE_ID
LANGUAGE
FND_DCU FND_DOC_CATEGORY_USAGES
Primary Keys: DOC_CATEGORY_USAGE_ID
FND_DE FND_DOCUMENT_ENTITIES
Primary Keys: DOC_ENTITY_ID
FND_AF FND_ATTACHMENT_FUNCTIONS
Primary Keys: ATTACHMENT_FUNCTION_ID
FND_AB FND_ATTACHMENT_BLOCKS
Primary Keys: ATTACHMENT_BLK_ID
FND_ABE FND_ATTACHMENT_BLK_ENTITIES
Primary Keys: ATTACHMENT_BLK_ENTITY_ID
FND_DPFS
FND_DFP
FND_DPP S
FND_HTREE FND_HTAR
The diagram above shows the Document Management and Help ERDs.
Because of their size, we had to compress the presentation. The following
listing gives you the information key for the diagrams above.
FND_DPRODS FND_DM_PRODUCTS
Primary Keys: PRODUCT_ID
FND_DFUNC FND_DM_FUNCTIONS
Primary Keys: FUNCTION_ID
FND_DPFS FND_DM_PRODUCT_FUNCTION_SYNTAX
Primary Keys: PRODUCT_FUNCTION_ID
FND_DFP FND_DM_FUNCTION_PARAMETERS
Primary Keys: PARAMETER_ID
FND_DPPS FND_DM_PRODUCT_PARAM_SYNTAX
FND_LOBACC FND_LOB_ACCESS
Primary Keys: ACCESS_ID
FND_LOBS FND_LOBS
Primary Keys: FILE_ID
FND_HDOC FND_HELP_DOCUMENTS
Primary Keys: FILE_ID
FND_HTREE FND_HELP_TREE
Primary Keys: FILE_ID
FND_HTAR FND_HELP_TARGETS
Primary Keys: FILE_ID
TARGET_NAME
FND_FKCOLS FND_FKEYS
FND_INCO LS FND_INDEXES
FND_COLUMNS
The diagram above shows the AOL Data Dictionary ERD. Because of its
size, we had to compress its presentation. The following listing gives you
the information key for the diagram above.
Table Name
FND_APPLICATION
Primary Keys: APPLICATION_ID
FND_VIEW_COLUMNS
Primary Keys: APPLICATION_ID
VIEW_ID
COLUMN_SEQUENCE
FND_VIEWS
Primary Keys: APPLICATION_ID
VIEW_ID
FND_SEQUENCES
Primary Keys: APPLICATION_ID
SEQUENCE_ID
FND_PRIMARY_KEY_COLUMNS
Primary Keys: APPLICATION_ID
TABLE_ID
PRIMARY_KEY_ID
PRIMARY_KEY_SEQUENCE
FND_PRIMARY_KEYS
Primary Keys: APPLICATION_ID
TABLE_ID
PRIMARY_KEY_ID
FND_FOREIGN_KEY_COLUMNS
Primary Keys: APPLICATION_ID
TABLE_ID
FOREIGN_KEY_ID
FOREIGN_KEY_SEQUENCE
FND_FOREIGN_KEYS
Primary Keys: APPLICATION_ID
TABLE_ID
FOREIGN_KEY_ID
FND_INDEX_COLUMNS
Primary Keys: APPLICATION_ID
TABLE_ID
INDEX_ID
COLUMN_SEQUENCE
FND_INDEXES
Primary Keys: APPLICATION_ID
TABLE_ID
INDEX_ID
FND_COLUMNS
Primary Keys: APPLICATION_ID
FND_APPLICATION
The diagram above shows the Currency and Language ERD. Because of
its size, we had to compress its presentation. The following listing gives
you the information key for the diagram above.
Table Name
FND_LOOKUP_VALUES
Primary Keys: LOOKUP_TYPE
LANGUAGE
LOOKUP_CODE
SECURITY_GROUP_ID
VIEW_APPLICATION_ID
FND_LANGUAGES
Primary Keys: LANGUAGE_CODE
FND_LOOKUP_TYPES
Primary Keys: LOOKUP_TYPE
SECURITY_GROUP_ID
VIEW_APPLICATION_ID
FND_NEW_MESSAGES
FND_APPLICATION
Primary Keys: APPLICATION_ID
Summary
Development Topics
Chapter 4 - Page 1
Development Topics
Development Topics
Development Topics
Chapter 4 - Page 2
Objectives
Objectives
Development Topics
Chapter 4 - Page 3
Interface Options
Interface Options
• What is an interface?
• Interface Tables
• Application Programming Interfaces (APIs)
• Other methods
We are going to use the following definition for interfaces. An interface will
allow you to:
1. INTERFACE TABLES
Development Topics
Chapter 4 - Page 4
to load your data, and then to run an Application concurrent program.
That concurrent program will take the data from the Interface Table,
validate it, and import it into your Applications' instance.
APIs allow for tight integration into the Oracle Applications product. There
are also 3rd-party products that integrate into Oracle Applications and
extend its integration capabilities.
3. OTHER METHODS
This seems like a catch all category, and it is. Oracle Applications also
provides other methods for data import and export. The most common of
these is through spreadsheets.
Several Oracle Applications products allow for data upload and download
via spreadsheets. The spreadsheet formats are pre-defined. But, the
mechanics of the upload or download are quite simple.
Any else? Oracle Applications also support data uploads and downloads
to Oracle Discoverer and word processing files. While I think that covers
the bases, Oracle Applications is a growing product that adapts to new
and evolving standards. So, who knows. By the time you read this, there
may be new standards that have been released, or are just about to make
their appearance.
Development Topics
Chapter 4 - Page 5
Interface Table Diagram
Data Source
Loader
Validate
Maintain Interface Errors
Table Table
Concurrent
Program
Destination
Product
The first thing to note is the Loader (in some cases also called, Feeders).
The Loader is responsible for uploading and downloading data from the
Interface Table. It should also be noted that some Interface Tables are
Inbound-only, some are Outbound-only, and some are both.
Once the data is into the Interface Table, it must be validated. Validation
is generally handled through a concurrent program. In some cases this
concurrent program is part of the import process. In others, it is a
separate validation program.
In either case, invalid data is separated and noted. This can be done
through the generation of a report. It can also be done by moving the
invalid records into an Error Table.
Development Topics
Chapter 4 - Page 6
Once validation is complete, there may need to be maintenance on the
data to correct errors or inconsistencies. This is typically done by a form
built by the product development team for this purpose.
With the data ready to go, the concurrent program takes the data from the
Interface Table and loads it into the Application. As noted previously,
validation may be occurring at this point or separately.
IMPORTANT NOTE:
It is critical to note how the data is imported. At NO TIME are you writing
data into or from the product tables. The only tables you write or read are
the Interface Tables.
Development Topics
Chapter 4 - Page 7
API Diagram
API Diagram
Data Source
Return Return
Call
Error Result
Business
Object API
Perform
Business
Function
Destination
Product
It should be noted that this method is distinctly different from the Interface
Table methodology. First off, the data is not staged. The data is sent
directly through the API. This has an implication. API methods are for
single-record data importing. Interface Tables are for mass data
importing. Of course, you could do mass imports with API, but it will be
slower, and performance is always a concern.
Another implication is that the API communicates directly with the Data
Source, letting it know if the import was successful. This implies that the
Data Source must be more than a data source. It must be able to handle
unsuccessful attempts to move data into the product.
IMPORTANT NOTE:
It is critical to note how the data is imported. At NO TIME are you writing
data into or from the product tables. Only the API writes or reads from the
Development Topics
Chapter 4 - Page 8
product tables. The API is responsible for communicating with your data
source.
Development Topics
Chapter 4 - Page 9
Development Standards
Development Standards
• Document
• Follow the documentation
• Adhere to the rules
• Check your data
DOCUMENT:
Development Topics
Chapter 4 - Page 10
It is quite amazing when you consider that the interfaces, both Interface
Tables and APIs, are documented in their product manuals. Use these
sources. If you do not have the manual on the interface you are trying to
use, you are missing the center of the puzzle.
Read the descriptions of the Interface Tables and APIs. Follow what the
documentation says. Don't assume that you can short-cut the process,
even though your short-cut "seems" to do the same. Oracle Applications
is a complex, inter-related product. Those assumptions are not safe.
It is critical to note how the data is imported. At NO TIME are you writing
data into or from the product tables. Only the API writes or reads from the
product tables or the concurrent programs that service the Interface Table.
Do not wite or read directly!
The single biggest cause of problems with Interface Tables and APIs is
misformatted data. You are either NOT putting the right data into the right
columns of the Interface Table. Or, you are not passing the proper
arguments in the proper format to the API. In over 90% of the problems
with the interfaces, the net result is data. Check it!
Development Topics
Chapter 4 - Page 11
Summary
Summary
Development Topics
Chapter 4 - Page 12
Exploring Applications
Database
Chapter 5
Objectives
This lesson is in place to help those students who need some assistance
with those skills. It will also help those students who don't need help,
because it will add a trick or two that they might not have seen.
Exploration Basics
• Logging in to SQL*Plus
• Running SQL scripts
• Listing scripts
• Description scripts
• Configuration scripts
LOGGING IN TO SQL*PLUS:
What this section does cover is the usernames and passwords that are
defaults on your database. (NOTE: These are only the defaults.
Usernames and passwords can be changed. In fact, Oracle recommends
that these passwords be changed.)
To run a SQL script, you can do 1 of 2 things. From the command line,
put at @ followed by the script name at the end of the command. For
example:
$ sqlplus apps/apps
Connected to:
Oracle8i Enterprise Edition Release 8.1.6.1.0 - Production
With the Partitioning option
JServer Release 8.1.6.1.0 - Production
SQL> @script1.sql
TYPES OF SCRIPTS:
There are 3 major categories that clearly delineate the scripts we will use
to explore the database, listing scripts, description scripts, and
configuration scripts.
Listing Scripts
What follows are several scripts that will list the various objects in your
database. These scripts are:
The scripts are reproduced here for your use. We give them default
names, but you are welcome to rename them when you use them on your
database.
CLEAR COMPUTES
CLEAR BREAKS
REPHEADER OFF
BREAK ON REPORT
COMPUTE SUM OF Objcnt ON REPORT
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
REPHEADER OFF
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
REPHEADER OFF
SELECT to_char(sum(sharable_mem)/1024,'9,999,999.9')
"TOTAL SPACE (K)"
FROM v$db_object_cache
WHERE type in ('FUNCTION','PACKAGE',
'PACKAGE BODY','PROCEDURE')
AND owner not in ('SYS');
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 85
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Link_List PROMPT 'Input DB Link or % for All: '
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Function Name or % for
All: '
ACCEPT Status_List PROMPT 'Input Status or % for All:
'
REPHEADER OFF
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Index_List PROMPT 'Input Index Name or % for
All: '
ACCEPT Table_List PROMPT 'Input Table Name or % for
All: '
ACCEPT Status_List PROMPT 'Input Status or % for All:
'
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF INDEX_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF STATUS ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF STATUS ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF STATUS ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Table_List PROMPT 'Input Table Name or % for
All: '
ACCEPT Col_List PROMPT 'Input Column Name/Attribute or
% for All: '
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF COLUMN_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input PAckage Name or % for
All: '
ACCEPT Status_List PROMPT 'Input Status or % for All:
'
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF OBJECT_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Package Body Name or %
for All: '
ACCEPT Status_List PROMPT 'Input Status or % for All:
'
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF OBJECT_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Procedure Name or % for
All: '
ACCEPT Status_List PROMPT 'Input Status or % for All:
'
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF OBJECT_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Sequence Name or % for
All: '
REPHEADER OFF
BREAK ON SEQUENCE_OWNER SKIP 2
COMPUTE COUNT OF SEQUENCE_NAME ON SEQUENCE_OWNER
CLEAR COMPUTES
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Synonym Name or % for
All: '
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF SYNONYM_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Table Name or % for
All: '
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF TABLE_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Trigger Name or % for
All: '
ACCEPT Type_List PROMPT 'Input Trigger Type or % for
All: '
ACCEPT Event_List PROMPT 'Input Triggering Event or %
for All: '
ACCEPT Status_List PROMPT 'Input Status or % for All:
'
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF TRIGGER_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input Type Name or % for All:
'
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF TYPE_NAME ON OWNER
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 132
SET NEWPAGE 0
SET VERIFY OFF
ACCEPT Owner_List PROMPT 'Input Owner or % for All: '
ACCEPT Name_List PROMPT 'Input View Name or % for All:
'
REPHEADER OFF
BREAK ON OWNER SKIP 2
COMPUTE COUNT OF VIEW_NAME ON OWNER
Description Scripts
What follows are several scripts that will describe the various objects in
your database. These scripts are:
NOTE: In this discussion, we are not going to give you samples of the
scripts for description. That would be too lengthy. Rather, we will discuss
the Database Views that maintain the information you need. Those static
views are discussed at the end of the scripts.
The scripts are reproduced here for your use. We give them default
names, but you are welcome to rename them when you use them on your
database.
CLEAR COMPUTES
CLEAR BREAKS
SET HEADING ON
SET PAGES 1000
SET LINESIZE 80
SET VERIFY OFF
BREAK ON TSPACE
REPHEADER LEFT 'Database Configration' SKIP 2
REPHEADER OFF
CLEAR COMPUTES
CLEAR BREAKS
REPHEADER OFF
For the objects stored in your Applications database, you will want to know
which static view, maintained by the Database, will give you the
information that you need. The following table shows that information.
Use the Listing Scripts as templates for Description scripts that you may
want to create. Also, use the DESCRIBE command in SQL*Plus to get
detailed descriptions of the available columns of these static data
dictionary views.
Configuration Scripts
What follows are several scripts that will report on your current
configuration of your database. These scripts are:
With little doubt, the most useful configuration script is the Applications
Configuration Script. This scripts useful is enhanced because it is actually
shipped with the Application. The script is reproduced here for study, but
you can find this script in ANY Applications instance in the file
$AD_TOP/sql/adutconf.sql
SPOOL adutconf.lst
prompt
prompt Oracle Applications Database Configuration Report
prompt
prompt
prompt All dates are shown in DD-MM-YYYY FORMAT
prompt
show pause
prompt
prompt --> Sql*Plus NEWPAGE setting
prompt
prompt
prompt --> Rollback Segment Information
prompt
prompt --> Start of Application Information Gathering
prompt
select decode(a.APPLICATION_short_name,
'SQLAP','AP','SQLGL','GL','OFA','FA',
a.APPLICATION_short_name) apps
, o.ORACLE_username
, fmi.module_short_name
, fmi.module_version
, decode(fmi.status,'I','Installed','S','Shared',
'N','Inactive',fmi.status) status
, decode(fmi.db_status,'I','Installed',
'N','Inactive',db_status) module_db_status
from fnd_oracle_userid o, fnd_application a, fnd_module_installations fmi
where fmi.application_id = a.application_id(+)
and fmi.oracle_id = o.oracle_id(+)
order by 1,2,3
/
select data_group_id,
data_group_name
, decode(default_group_flag,'N','No','Y','Yes',
default_group_flag) default_group_flag
select decode(installed_flag,'I','Installed','B','Base','Unknown')
installed_flag,
language_code, nls_language from fnd_languages
where installed_flag in ('I','B')
order by installed_flag;
prompt
prompt --> End of Application Information Gathering
spool off
exit;
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
REPHEADER OFF
BREAK ON TABLESPACE
CLEAR COMPUTES
CLEAR BREAKS
SET PAGESIZE 66
SET LINESIZE 80
SET NEWPAGE 0
SET VERIFY OFF
REPHEADER OFF
Summary
Objectives
Topics
This unit describes the database tables that are affected by setup activities
within certain Oracle Manufacturing applications.
At the end of this unit, you should be able to identify these tables within each
application setup definition and explain the major columns within each table.
Additionally, you should be able to understand and use an entity relationship
diagram from an application technical reference manual to assist you in further
exploring these database table relationships.
Agenda
Agenda
applsys.
applsys.env fnd inv “custom”
1.0
1.0
Naming Standards
Oracle uses certain standards to create tables, columns, views, and indexes.
Following these guidelines makes it easier for you to understand the application
data structures that support them.
Database objects (tables, views, or indexes) should be:
• Unique across all applications
• Prefixed with the application short name
• Plural
• End-user oriented
• Concise (avoid unnecessary abbreviations)
• Unambiguous
Column names should be:
• Unprefixed if not a primary key column
• Singular
• End-user oriented
• Concise (avoid unnecessary abbreviations)
• Unambiguous
Index names should:
• Reflect the name of the table they index (prefix is the table name)
• Be identified as unique indexes by using the suffix _Um, where m is a
number
Development Standards
Summary
Agenda
• Primary key
• Foreign Key
• Diagramming Conventions
Primary Key
PO_HEADERS_ALL Table
123 57 Y .. .
124 58 N ...
. .. . .. . .. .. .
Description
Good relational database design ensures data integrity and minimizes data
redundancy. These goals are accomplished by storing the details of an entity
(such as item, supplier, and category) only once, and maintaining relationships
between that entity and other entities in the database that need access to its
details. For example, an item description is stored only once, but bills of
material that use that item as a component need access to its description. The
database design maintains a relationship between the table that stores the item
attributes (MTL_SYSTEM_ITEMS_B) and the table that represents the bills of
material component (BOM_INVENTORY_COMPONENTS). Since items and
components are called entities, these relationships are referred to as entity
relationships.
Foreign Key
PO_LINES_ALL Table
Description
In a relational database, foreign key relationships are represented by storing a
matching element of data in both tables. Most often, it is the data element (or
combination of elements) that uniquely identifies an entity, the primary key,
stored in another table to indicate the relationship between tables. When the
primary key from one table is stored in another table, it is referred to as the
foreign key. For example, the primary key of the MTL_SYSTEM_ITEMS_B
table (INVENTORY_ITEM_ID/ ORGANIZATION_ID) is stored as a foreign
key in BOM_INVENTORY_COMPONENTS table. Refer to the application
Technical Reference Manual (TRM) for the complete listing of foreign keys.
Multiple Products with Shared Entities
• Items:
– Bills of Material/Engineering
– Planning
– Inventory
– Order Management
– Work in Process
• Locations:
– Inventory
– Master Scheduling/MRP
– Oracle Payables
– Purchasing
Copyright © Oracle Corporation, 2001. All rights reserved.
123 57 Y ...
124 58 N ...
. .. . .. . .. .. .
PO_LINES_ALL
Note
In the example in the slide, PO_HEADER_ID is the primary key in the
PO_HEADERS_ALL table and the foreign key in the PO_LINES_ALL table.
Note
You can refer to each individual application Technical Reference Manual
(TRM) for the full list of tables with their primary and foreign keys. For the
example above, refer to the Oracle Purchasing Technical Reference Manual.
You can find a list of these manuals in the Related Publications section of the
preface.
May be relationship
Types of Table Relationships
Each row in Table A
may be related to a row
A B in Table B
B
Each row in Table A
must be related to a
A row in either Table B
or Table C, but not
both
C
Database Diagrams
A database diagram or entity relationship diagram (ERD) graphically represents
the database tables of an application and the relationships among them. By
understanding these diagrams, you can learn which tables are used by a
particular application and how these tables interrelate.
The major tables and their relationships are discussed within each Oracle
application module, with reference to the ERD.
Additionally, each Oracle application module has a technical reference manual
that details these relationships. Refer to these technical reference manuals for
additional information regarding the database table relationships. For the
purpose of this course, the primary tables selected are based on the core
manufacturing tasks performed in a business environment.
Practice Setup
Practice Overview
Practice 1
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: fnd_lookups
• Keys: lookup_type
• Columns: lookup_type, lookup_code, meaning
Practice 1 Solution
Practice 2
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: fnd_user
• Keys: user_name
• Columns: user_name, user_id, encrypted_user_password
Practice 2 Solution
Practice 3
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: fnd_user, fnd_user_responsibility, fnd_responsibility_tl
• Keys: user_name, responsibility_id, application_id, user_id
• Columns: user_name, responsibility_name
Practice 3 Solution
Practice 4
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: mtl_parameters, hr_all_organization_units
• Keys: organization_id
• Columns: organization_id, organization_code, name,
master_organization_id
Practice 4 Solution
Agenda
• Inventory
• Bills of Material
• Engineering
• Cost Management
• Work in Process
• Purchasing
Lesson Overview
The core Oracle Manufacturing applications major functionalities will be
discussed at a very high level to facilitate the database table discussions. For
detailed application information, attend an individual class covering detailed
content specific to that application module.
Oracle Inventory
Supplier
Transfer
Inventory
Shipment
Order entry
Internal
shipment Expense
Inventory Inspect
®
Description
Oracle Inventory maintains quantities on hand using a variety of stock
maintenance tools, controlled transactions, and planning methods.
Organization and Item Definition
• Set up inventory structure.
• Define stock and nonstock parts.
• Establish planning and purchasing attributes.
• Track inventory by item, item revision, serial number, or lot number.
Transactions and Maintenance
• Receive parts from and return parts to suppliers.
• Transfer inventory between organizations directly or as in-transit
shipments.
• Add material overhead to the cost of a part.
• Conduct inventory cycle counts based on ABC classification.
• Record physical inventory counts and adjustments.
• Process miscellaneous issues and receipts.
• Transfer material between subinventories.
• Receive and inspect material returned from a customer.
• Track lots and serial numbers for an item.
• Return repaired or substitute items to a customer.
Oracle
Bills of Material
®
Description
Oracle Bills of Material develops and maintains manufacturing bills of material
(BOMs) and routings to drive planning, costing, and work-in-process tracking.
Routings
• Specify department and resources usage.
• Define shop floor controls.
• Maintain multiple revisions of routings.
• Define Dybanic, lot-based flow routing for operation flexibility.
Bills of Material
• Define component usage, yield, and material control.
• Integrate with routings for point-of-use definition.
• Maintain multiple revisions of bills of material.
Lead Time
Calculate manufacturing lead time to produce goods from routing standards.
Standard Cost
Calculate standard costs from bills of material and routings.
Views and Reports
• Perform a single-level explosion of bills of material (or fully indented
explosions).
• Choose to include or exclude costs in the explosion.
Oracle Engineering
Oracle Engineering
®
Description
Oracle Engineering interacts with other Oracle manufacturing applications to
provide a cohesive integrated business solution. Oracle Engineering helps you
define product and process specifications. It also provides the information
required for effective planning and execution.
Oracle Oracle Engineering
• Define engineering and manufacturing bills of material.
• Define engineering and manufacturing routings.
• Manage product changes with engineering change orders (ECOs).
• Create new design specifications using Oracle Engineering.
• Determine resource availability using the workday calendar.
• Specify detailed resource use.
Introducing New Products
• Define engineering items, BOMs, and routings to prototype new product
designs.
• Calculate lead times and release engineering prototypes to manufacturing.
Defining Planning Bills
• Define planning bills to assist with sales strategy.
• Provide BOM maintenance.
Managing Engineering Changes
Description
Oracle Cost Management automatically performs the cost accounting for all
your Oracle Inventory, Work in Process, and Purchasing transactions. At any
time, your inventory and work-in-process costs are up-to-date, and your
inventory value matches the cumulative total of your accounting transactions.
Standard Costing
• Oracle Cost Management supports standard costing for inventory, bills of
material, and work-in-process costing.
• You may use standard costing for one organization and average costing for
another organization.
Average Costing
• Oracle Cost Management supports average costing for inventory, bills of
material, and work-in-process costing. Average costs are automatically
updated as transactions are processed.
• If you have Oracle Bills of Material installed, you can transact your
inventory at average, and use the standard cost features for product cost
simulations and budgeting.
Extensive Cost Simulation Capability
Create unlimited sets of product costs, called cost types. Each cost type has its
own items and specific cost controls for the items.
Issue
material
Jobs and
Raw material
schedules
inventory
Complete
finished
assemblies Move assemblies on
the shop floor and
charge resources
Finished goods
Scrap rejected
subinventory assemblies
Description
Oracle Work in Process tracks material and production activity on the shop
floor to facilitate inventory control, job scheduling, and costing.
Material Issue
Record material issues to discrete jobs, repetitive schedules, or nonstandard
jobs.
Shop Floor Move
Record production activity and job completions.
Resource Charging
• Charge multiple resources option.
• Charge resources automatically (based on shop floor moves) or manually, at
either standard or actual labor rates.
Other Transactions
• Cost material using standard cost.
• Use repetitive schedules to simplify material and production reporting.
• Use lot and serial number controlled parts in production moves.
Oracle Purchasing
ve
Manually ppro Automatically
A
create create
PO
Requisition
pool
Maintain documents
Description
Oracle Purchasing is a comprehensive procurement solution, designed to reduce
administration costs while focusing on value analysis, strategic supply base
management, and contract negotiation.
Requisitioning
• Replace paper processing with online requisition generation, purchase order
creation, and document approval.
• Regulate document access, control or modification activity, and approval
based on organizational signature and security policies.
• Minimize data entry time with time-saving templates, express processing
functions, and default infrastructures.
Purchasing
• Control purchasing activity and enable accurate automatic pricing using an
approved supplier list.
• Consolidate purchase requirements from multiple warehouses, plants, or
locations.
Receiving
Receive production items, Maintenance, Receipt and Overhead (MRO) items,
and services using a common flexible receiving process.
Business Communication
• Facilitate communication between requesters, buyers, receiving staff, and
accounts payable staff using online inquiries and notes.
Purchasing Transactions
• Suppliers
• Requisitions
• Purchase orders
• Receipt and delivery
Transaction Functionality
Purchasing provides you with request for quotation (RFQ) and quotation
features to handle your sourcing needs. You can create an RFQ from
requisitions, match supplier quotations to your RFQ, and automatically copy
quotation information to purchase orders.
Additionally, you are able to:
• Review all your purchases with your suppliers to negotiate better discounts
• Create purchase orders simply by entering a supplier and item details
Purchasing provides you with the features you need to satisfy your receipt,
inspection, transfer, and delivery needs.
Agenda
Importing Information
Importing Information
Basic Importing Needs
Oracle Manufacturing applications import programs provide the features you
need to fill the following basic integration needs:
To import information in the easiest way possible, the format must be consistent
with the structure of the new system.
Import information from a variety of environments, including your own and
other accounting systems.
Import historical data from your previous manufacturing, sales order, or other
management systems to keep your records consistent and up-to-date.
Review the results of your import run. Identify which data has been successfully
imported and any errors that may have occurred during the import process.
Choosing a Feeder Program
You must choose a tool for writing a feeder program to extract data from your
existing application system’s printed reports, flat file, relational database, or
other repository of application information. Use your feeder program to
populate an Oracle application import table with the information you want to
introduce to your Oracle manufacturing system.
SQL*Loader is a powerful and easy-to-use tool that you can use to write a
feeder program. It enables you to map elements of a character-delimited or
fixed-format file, such as a listing or flat file, and to specify which columns of
which tables they populate.
Importing Information
Errors
Interface table
Maintain table (optional)
Process
Destination
Destination
application
application
®
Data Conversion
Data Conversions
The purpose of this section is to give you an understanding of how to perform
data conversions from external systems to Oracle Applications products. The
emphasis in this section is on conversion methodology, not on one specific
conversion (for example, item conversion).
Movement of Data
Plan the movement of data from an external system to Oracle Applications with
a conversion project plan. Develop a detailed conversion plan for each entity,
listing all design, development, testing, and conversion tasks. Include resource,
software, and hardware requirements to successfully convert each entity.
Designing the Conversion Process
• Determine what data to convert (for example, convert only active data).
• Document business objectives.
• Specify time constraints for the conversion, especially for dynamic data.
• Determine the appropriate conversion method; do not overlook manual data
entry.
• Perform data mapping.
• Install all hardware and software required for the conversion.
• Scope all coding efforts, including the cleanup of existing data, extract
programs, translation programs, validation programs, and migrating
programs.
• Determine the testing requirements.
Developing Programs for Conversion
• Write extract and import programs.
• Write scripts to create any interface or translation tables in Oracle RDBMS.
• Write validation, translation, and migration programs.
1
2
3
4
5
6
7
Data Verification
For each converted entity, design a conversion process from data extraction
through data verification. Consider business objectives and dependencies for
each point in the process.
Reduce the time required to execute the conversion process with accurate
designs. Plan resources effectively with reasonable time estimates and good
design specifications. Be sure to clean up the database before conversion.
Steps for Design
1 Examine the business objectives and requirements to determine the data to
be converted.
2 Map the source data to the Oracle applications.
3 Identify the tools used to extract and import data. Do not disregard manual
data entry.
4 Define flat-file configuration.
5 Identify any interface tables to create.
6 Design any translation and validation programs.
7 List the testing phases and procedures.
Instructor Note
These are points to bring up with your students, because each question is
particular to a customer’s conversion. The goal is to help students consider
issues that are critical to their conversion while you explain the conversion
method.
Ensuring Integrity
After designing and developing all elements of the conversion, perform the
conversion. Manage any time constraints and ensure the integrity of the
converted data. Minimize the time required to actually convert from the original
system to Oracle Applications by reviewing all programs and designs before
executing the conversion process.
Steps to Perform Conversion
1 Create a unique application username, and use it to populate the WHO
columns.
2 Extract data from the original source; load and format the data in a flat file.
3 Create temporary tables using SQL*Loader scripts.
4 Use SQL*Loader scripts to upload the data into interface tables.
5 Run translation programs on data in the interface tables.
6 Run validation programs on data in the interface tables.
7 Migrate translated and validated data into the production tables.
8 Run verification scripts.
9 Run application reports to verify converted data.
Summary
Topics
This unit describes the database tables that are affected by setup activities
within certain Oracle Manufacturing applications.
At the end of this unit, you should be able to identify these tables within each
application setup definition and explain the major columns within each table.
Additionally, you should be able to understand and use an entity relationship
diagram from an application technical reference manual to assist you in further
exploring these database table relationships.
Objectives
Lesson Aim
The aim of this lesson is to provide the student an overview of the item
definition process in Oracle Inventory and discuss the database tables that are
populated as a result of item setup activity.
Instructor Note
The primary key for each of the ERD tables is in each table definition in the
Notes section of the slides. Example: ‘The primary key is INVENTORY_ID,
ORGANIZATION_ID’, where there are two elements that make up the primary
key. Some _INTERFACE and _TEMP names may not have a primary key
associated with it.
An “(o)” following a primary key name indicates that element to be optional.
Example: ‘WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o)’. In this example it indicates that the
REPETITIVE_SCHEDULE_ID is part of the primary key when you reference
specific Repetitive schedules tables and not part of the primary key when you
reference Discrete job tables.
Agenda
• Item definition
• Inventory transactions
• Open interfaces
Agenda
• Item definition
• Inventory transactions
• Open interfaces
Oracle Inventory
Supplier
Transfer
Inventory
Shipment
Order entry
Internal
shipment Expense
Inventory Inspect
®
Description
Oracle Inventory maintains quantities on hand using a variety of stock
maintenance tools, controlled transactions, and planning methods.
Organization and Item Definition
• Set up inventory structure.
• Group inventory organizations into multilevel, hierarchical trees for
managing large organization structures.
• Define stock and nonstock parts.
• Establish planning and purchasing attributes.
• Track inventory by item, item revision, serial number, or lot number.
Transactions and Maintenance
• Receive parts from and return parts to suppliers.
• Transfer inventory between organizations directly or as in-transit shipments.
• Create move orders for subinventory transfers.
• Receive alerts or notifications about material shortages.
• Add material overhead to the cost of a part.
• Conduct inventory cycle counts based on ABC classification.
• Record physical inventory counts and adjustments.
• Track serial controlled items from receipt through work in process and
inventory to the customer sale.
Forecasting and Planning
MTL_SYSTEM_ITEMS_TL
MTL_SYSTEM_ITEMS_B
SUBINVENTORY
LOCATOR MTL_MATERIAL_TRANSACTIONS
MTL_TRANSACTION_ACCOUNTS MTL_ONHAND_QUANTITIES
®
Inventory Organizations
Enterprise
Master Org
Organizations
MTL_INTERORG_
MTL_PARAMETERS
PARAMETERS
HR_ORGANIZATION_
GL_SETS_OF_BOOKS
INFORMATION
GL_CODE_ HR_ALL_ORGANIZATION_UNITS
COMBINATIONS
MTL_PARAMETERS
MTL_PARAMETERS is an inventory organization with which an item is
associated. The primary key is the ORGANIZATION_ID.
MTL_INTERORG_PARAMETERS
This table identifies the receiving organizations linked to a particular
organization. You must define the interorganizational relationship before you
perform any interorganization transfers.
Units of measure, distance, transfer charge, and accounting information are also
specified in this table. The primary key is FROM_ORGANIZATION_ID,
TO_ORGANIZATION_ID.
GL_SETS_OF_BOOKS
GL_SETS_OF_BOOKS stores information about the sets of books you define
in your general ledger application. Each row includes the set of books name,
description, functional currency, and other information. This table corresponds
to the Define Set of Books form. The primary key is SET_OF_BOOKS_ID.
GL_CODE_COMBINATIONS
This table stores valid Accounting Flexfield segment value combinations for
each accounting flexfield structure within your general ledger application. The
primary key is CODE_COMBINATION_ID.
HR_ALL_ORGANIZATION_UNITS
HR_ALL_ORGANIZATION_UNITS stores generic information about
organizations. An organization can be used for various purposes in Oracle
Defining Organizations
Organization
Organization
Inventory
Inventory Parameters
Parameters (M1)
(M1)
(N) Inventory > Setup > Organizations > Organizations (B) Others
Locator: Organization
Sub Inv.
Eng Dept. Seattle Stores
Oracle Inventory:
Subinventories and Locators
GL_CODE_COMBINATIONS
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_TL
MTL_SECONDARY_INVENTORIES
MTL_ITEM_SUB_INVENTORIES
MTL_ITEM_LOCATIONS
MTL_SECONDARY_LOCATORS
MTL_PARAMETERS
®
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
flexfield code is MSTK. The primary key for an item is the
INVENTORY_ITEM_ID and the ORGANIZATION_ID. The same item could
be defined in more than one organization. Each row represents an item in an
organization.
MTL_SYSTEM_ITEMS_TL
MTL_SYSTEM_ITEMS_TL is a table holding translated Description column
for Items. The primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID,
LANGUAGE.
GL_CODE_COMBINATIONS
This table stores valid Accounting Flexfield segment value combinations for
each accounting flexfield structure within your general ledger application. The
primary key is CODE_COMBINATION_ID.
MTL_SECONDARY_INVENTORIES
MTL_SECONDARY_INVENTORIES is the definition table for the
subinventory. Subinventories are assigned to items, indicating a list of valid
places in which this item may be located. The primary key is
SECONDARY_INVENTORY_NAME, ORGANIZATION_ID.
MTL_ITEM_SUB_INVENTORIES
Defining Subinventories
Subinventories
Subinventories Summary
Summary (M1)
(M1)
Defining Locators
Stock
Stock Locators
Locators (M1)
(M1)
MTL_ITEM_ATTRIBUTES
MTL_SYSTEM_ITEMS_B
MTL_ITEM_TEMPL_ATTRIBUTES
MTL_ITEM_STATUS
MTL_ITEM_TEMPLATES
MTL_STATUS_ATTRIBUTE_VALUES
MTL_PARAMETERS
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
flexfield code is MSTK. The primary key for an item is the
INVENTORY_ITEM_ID and the ORGANIZATION_ID. The same item could
be defined in more than one organization. Each row represents an item in an
organization.
MTL_ITEM_ATTRIBUTES
MTL_ITEM_ATTRIBUTES stores the item attributes, their user-friendly
names if the item is maintained at the item or item/organization level, and the
kind of validation required for each attribute. This table is seeded on install or
upgrade. The primary key is ATTRIBUTE_NAME.
MTL_ITEM_TEMPL_ATTRIBUTES
MTL_ITEM_TEMPL_ATTRIBUTES stores the attributes and attribute values
for a template. When a template is created, a row is inserted for each available
item attribute. When the template is applied to an item, the enabled attribute
values are propagated to the item. The primary key is TEMPLATE_ID,
ATTRIBUTE_NAME.
MTL_ITEM_STATUS
MTL_ITEM_STATUS is the definition table for a material status code. The
status code is a required item attribute and indicates the item status (for
example, active, pending, or obsolete). You may define as many additional
status codes as you want. The values of the individual status attributes
Defining Items
Item
Item Template
Template (M1)
(M1)
No control?
Credit card or
Supplier control?
petty cash
Item list
POs/suppliers
on-hand
no item #’s
Defined Defined
expense items stock items
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
flexfield code is MSTK. The primary key for an item is the
INVENTORY_ITEM_ID and the ORGANIZATION_ID. The same item could
be defined in more than one organization. Each row represents an item in an
organization.
MTL_ITEM_REVISIONS
MTL_ITEM_REVISIONS stores revision levels for an inventory item. When an
item is defined, a starting revision record is written out to the table; every item
will have at least one revision. The primary key is INVENTORY_ITEM_ID,
ORGANIZATION_ID, REVISION.
MTL_SERIAL_NUMBERS
MTL_SERIAL_NUMBERS stores the definition and current status of all serial
numbers in Oracle Inventory. These serial numbers are also used in other areas
of Oracle Manufacturing applications.
A serial number can have one of four statuses:
• Defined, but not used
• Resides in stores
• Issued out of stores
• Resides in transit
MTL_PENDING_ITEM_STATUS
MTL_SYSTEM_ITEMS_B MTL_ITEM_STATUS
MTL_STATUS_ATTRIBUTE_VALUES
MTL_ITEM_ATTRIBUTES
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
flexfield code is MSTK. The primary key for an item is the
INVENTORY_ITEM_ID and the ORGANIZATION_ID. The same item could
be defined in more than one organization. Each row represents an item in an
organization.
MTL_ITEM_ATTRIBUTES
MTL_ITEM_ATTRIBUTES stores the item attributes, their user-friendly
names if the attribute is maintained at the item or item/organization level, if the
attribute is controlled by an item’s status, and the kind of validation required for
each attribute. This table is seeded on install or upgrade. The top eight item
attributes are as follows:
1 Stockable
2 Transactable
3 BOM allowed
4 WIP allowed
5 Purchasable
6 OE Orderable
7 Internal Orderable
8 Billable
The primary key is ATTRIBUTE_NAME.
1. Stock N Y Y Y N
2. Trans N Y Y Y N
3. BOM Y Y Y Y Y
4. WIP N Y Y N N
5. Pur N Y Y N N
6. OE N N Y Y N
7. Intern N N Y Y N
8. Bill N N Y Y N
Item
Item Status
Status
Item Categories
Example
Category Set
Categories
MTL_ITEM_CATEGORIES MTL_SYSTEM_ITEMS_B
MTL_CATEGORY_
SET_VALID_CATS
MTL_CATEGORIES_B MTL_CATEGORY_
SETS_B
FND_ID_FLEX_
STRUCTURES
MTL_CATEGORIES_TL MTL_CATEGORY_SETS_TL
MTL_DEFAULT_
CATEGORY_SETS
®
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
flexfield code is MSTK. The primary key for an item is the
INVENTORY_ITEM_ID and the ORGANIZATION_ID. The same item could
be defined in more than one organization. Each row represents an item in an
organization.
FND_ID_FLEX_STRUCTURES
FND_ID_FLEX_STRUCTURES stores structure information about key
flexfields. The primary key is APPLICATION_ID, ID_FLEX_CODE,
ID_FLEX_NUM.
MTL_CATEGORIES_B
MTL_CATEGORIES_B is the code combinations table for item categories.
Items are grouped into categories within the context of a category set to provide
flexible grouping schemes. The primary key is CATEGORY_ID.
The item category is a key flexfield with a flexfield code of MCAT.
MTL_CATEGORIES_TL
MTL_CATEGORIES_TL is a table holding translated Description column for
Item Categories. The primary key is CATEGORY_ID, LANGUAGE.
MTL_CATEGORY_SETS_B
MTL_CATEGORY_SETS_B contains the entity definition for category sets. A
category set is a categorization scheme for a group of items. Items can be
Categories
(N) Inventory > Setup > Items > Categories > Category Codes
MTL_SYSTEM_ITEMS_B
MTL_DESCR_ELEMENT_VALUES
MTL_DESCRIPTIVE_ELEMENTS
MTL_ITEM_CATALOG_GROUPS
MTL_ITEM_CATALOG_GROUPS
MTL_ITEM_CATALOG_GROUPS is the entity table for item catalog groups.
An item catalog group consists of items that can be described by the same set of
descriptive elements or item properties. The item catalog group assignment for
an item is done at the item master organization level.
The item catalog group is a key flexfield. The flexfield code is MICG. The
primary key is ITEM_CATALOG_GROUP_ID.
MTL_DESCRIPTIVE_ELEMENTS
MTL_DESCRIPTIVE_ELEMENTS stores the descriptive element definitions
for an item catalog group. Descriptive elements are defining properties used to
describe the catalog group. The primary key is
ITEM_CATALOG_GROUP_ID, ELEMENT_NAME.
MTL_DESCR_ELEMENT_VALUES
MTL_DESCR_ELEMENT_VALUES stores the descriptive element values for
a specific item. An item can only be assigned to one item catalog group and will
only have descriptive elements for a single catalog group. The primary key is
INVENTORY_ITEM_ID, ELEMENT_NAME.
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
flexfield code is MSTK. The primary key for an item is the
INVENTORY_ITEM_ID and the ORGANIZATION_ID. The same item could
Practice 1 Setup
Setup Instructions
Create Seven Items
1. Navigate to the Master Item form.
(N) Inventory > Items > Master Items (note: select M1-Seattle Manufacturing as
your default)
• Name the item and fill in the description (note: item number is case
sensitive).
• Apply the Item Template for each item as shown in the example table
below.
[M]Tools > Copy From
• Select the correct template for each item from list of values, and Click the
Done button.
• Assign Unit of Measure as shown in the example table below.
• Select the Lead Time tab and enter 2 for processing lead time.
• Save your work.
[M]Tools > Organization Assignment
• Assign Item to the M1-Seattle Manufacturing organization.
• Save your work.
• Repeat step 1for the additional six items, substituting the appropriate
Template for each.
Example:
Practice 1
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: mtl_system_items, mtl_parameters
• Keys: segmentl, organization_code, organization_id
• Columns: purchasing_item_flag, internal_order_enabled_flag,
customer_order_enabled_flag, stock_enabled_flag, bom_enabled_flag,
build_in_wip_flag, mtl_transactions_enabled_flag, invoiceable_item_flag
Practice 1 Solution
Agenda
• Item definition
• Inventory transactions
• Open interfaces
Inventory,
Order entry Receiving
WIP
RCV_
RCV
TRANSACTIONS_
processor
INTERFACE
MTL_TRANSACTIONS_INTERFACE
This is the interface point between non-Inventory applications and the Inventory
transaction module.
The Transaction Manager concurrent program polls this table at a user-specified
process interval and submits the transaction workers to process them.
Processing consists of data derivation, validation, and transfer of records from
MTL_TRANSACTIONS_INTERFACE,
MTL_TRANSACTION_LOTS_INTERFACE, and
MTL_SERIAL_NUMBERS_INTERFACE into their respective TEMP tables,
from where they are processed by the transaction processor.
MTL_MATERIAL_TRANSACTIONS_TEMP
This table is the gateway for all material transactions. Records are processed
from this table into Inventory through the transaction processor. All Inventory
transaction forms write directly to this table. Outside applications must write
transaction records to MTL_TRANSACTSIONS_INTERFACE to be processed
through MTL_MATERIAL_TRANSACTIONS_TEMP and the transaction
processor by the Transaction Worker concurrent program.
MTL_MATERIAL_TRANSACTIONS
This table stores a record of every material transaction or cost update performed
in Inventory.
Records are inserted into this table either through the transaction processor or
by the standard cost program. The primary key is TRANSACTION_ID.
MTL_TRANSACTION_ACCOUNTS
Copyright © Oracle Corporation, 2001. All rights reserved.
Oracle Inventory:
Inventory Transactions and Item Controls
MTL_SYSTEM_ITEMS_B
MTL_SERIAL_ MTL_LOT_NUMBERS
NUMBERS
MTL_ITEM_
REVISIONS
MTL_UNIT_ MTL_TRANSACTION_
TRANSACTIONS LOT_NUMBERS
MTL_MATERIAL_TRANSACTIONS
®
MTL_UNIT_TRANSACTIONS
MTL_UNIT_TRANSACTIONS stores a record of every material transaction of
a serialized unit in Oracle Inventory. Records are inserted into this table through
the transaction processor. The primary key is TRANSACTION_ID,
SERIAL_NUMBER.
MTL_SERIAL_NUMBERS
MTL_SERIAL_NUMBERS stores the definition and current status of all serial
numbers in Oracle Inventory. These serial numbers are also used in other areas
of Oracle Manufacturing applications. The primary key is
INVENTORY_ITEM_ID, SERIAL_NUMBER,
CURRENT_ORGANIZATION_ID.
MTL_TRANSACTION_LOT_NUMBERS
MTL_TRANSACTION_LOT_NUMBERS stores lot number information for
transactions in the MTL_MATERIAL_TRANSACTIONS table. The primary
key is TRANSACTION_ID, LOT_NUMBER.
MTL_LOT_NUMBERS
MTL_LOT_NUMBERS stores the definition and expiration date of all lot
numbers in Oracle Inventory. The primary key is INVNETORY_ITEM_ID,
ORGANIZATION_ID, LOT_NUMBER.
MTL_ITEM_REVISIONS
Generate tags
Count items
Void tags
Approve counts
MTL_PHYSICAL_
INVENTORIES
MTL_ MTL_PHYSICAL_
MTL_
PHYSICAL_ SUBINVENTORIES
PHYSICAL_
INVENTORY_
ADJUSTMENTS
TAGS
MTL_
SECONDARY_
INVENTORIES
MTL_PHYSICAL_SUBINVENTORIES
MTL_PHYSICAL_SUBINVENTORIES specifies which subinventories are
involved in a physical inventory when the physical inventory does not include
all subinventories. The primary key is ORGANIZATION_ID,
PHYSICAL_INVENTORY_ID, SUBINVENTORY.
MTL_SECONDARY_INVENTORIES
MTL_SECONDARY_INVENTORIES is the definition table for the
subinventory. Subinventories are assigned to items, indicating a list of valid
places in which this item is located. The primary key is
SECONDARY_INVENTORY_NAME, ORGANIZATION_ID.
MTL_PHYSICAL_INVENTORY_TAGS
MTL_PHYSICAL_INVENTORY_TAGS stores information regarding physical
inventory tags, including tag number, SKU information, tag quantity, and a
pointer to the corresponding adjustment in
MTL_PHYSICAL_ADJUSTMENTS. A change to this table can require a
change to MTL_PHYSICAL_ADJUSTMENTS to ensure that the information
therein remains consistent with its tags. The primary key is TAG_ID.
MTL_PHYSICAL_ADJUSTMENTS
MTL_PHYSICAL_ADJUSTMENTS contains all information about the
adjustment transactions, including the size of the necessary adjustment, the
accounts to which the adjustment transaction was posted, and the approval
status of each transaction. The primary key is ADJUSTMENT_ID.
MTL_MATERIAL_TRANSACTIONS
Copyright © Oracle Corporation, 2001. All rights reserved.
Define
Define Physical
Physical Inventory
Inventory (M1)
(M1)
(N) Inventory > Counting > Physical Inventory > Physical Inventories
MTL_ABC_COMPILES
MTL_ABC_ MTL_ABC_COMPILE_
ASSIGNMENTS HEADERS
MTL_ABC_
MTL_ABC_ MTL_ABC_ASSGN_ ASSIGNMENT_
CLASSES GROUP_CLASSES GROUPS
MTL_ABC_CLASSES
MTL_ABC_CLASSES contains information about ABC classes. Each row in
this table defines an ABC class. An ABC class is a category under which items
with similar metrics are put together. An ABC class can be used in more than
one ABC group, but only once within a given group. The primary key is
ABC_CLASS_ID.
MTL_ABC_ASSIGNMENT_GROUPS
MTL_ABC_ASSIGNMENT_GROUPS contains information for ABC groups.
Each row in this table defines an ABC group and is populated by the Define
ABC Group table. Oracle Inventory uses this information as the basis for ABC
class assignment and item assignment. The primary key is
ASSIGNMENT_GROUP_ID.
MTL_ABC_ASSGN_GROUP_CLASSES
MTL_ABC_ASSIGN_GROUP_CLASSES stores information about the ABC
classes assigned to an ABC group. An ABC class can be assigned to one or
more ABC groups, but can be used only once in each ABC group. The primary
key is ASSIGNMENT_GROUP_ID, ABC_CLASS_ID.
MTL_ABC_ASSIGNMENTS
MTL_ABC_ASSIGNMENTS holds assignments of inventory items to ABC
classes and ABC groups. Oracle Inventory uses this information to load the
cycle count process. The primary key is INVENTORY_ITEM_ID,
ASSIGNMENT_GROUP_ID, ABC_CLASS_ID.
MTL_ABC_COMPILE_HEADERS
Copyright © Oracle Corporation, 2001. All rights reserved.
A 33
B 126
C 905
Cycle Counting
Cycle counting is the periodic counting of individual items throughout the year.
Count items of higher value more frequently than items of lower value. Perform
cycle counting instead of performing physical inventory. You can use both
techniques to verify the accuracy of on-hand quantities and values.
MTL_
MTL_CYCLE_ MTL_CYCLE_
MATERIAL_
COUNT_HEADERS COUNT_
TRANSACTIONS
CLASSES
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
primary key for an item is the INVENTORY_ITEM_ID and the
ORGANIZATION_ID.
MTL_CYCLE_COUNT_ITEMS
MTL_CYCLE_COUNT_ITEMS stores information about all items eligible for
cycle counting within the scope of a cycle count name. Oracle Inventory uses
this information to direct the cycle count scheduling process, and as a validation
table when entering manual schedule requests. The primary key is
CYCLE_COUNT_HEADER_ID, INVENTORY_ITEM_ID.
MTL_CYCLE_COUNT_CLASSES
MTL_CYCLE_COUNT_CLASSES stores information about cycle count
classes, such as associated cycle count name, approval tolerance limits, and
minimum counting frequency. Oracle Inventory uses Cycle Count Classes as a
unit for specifying and defaulting cycle count attributes. The primary key is
ABC_CLASS_ID, CYCLE_COUNT_HEADER_ID.
MTL_CYCLE_COUNT_HEADERS
MTL_CYCLE_COUNT_HEADERS stores information about cycle count
names. Oracle Inventory uses this information to track defined cycle count
names, to indicate tolerance/approval limits, cycle count calendar and exception
set, ABC initialization information, scheduling options, and recount options.
The primary key is CYCLE_COUNT_HEADER_ID.
Oracle Inventory:
Demand and Reservation Information
MTL_SYSTEM_ITEMS_B
OE_ORDER_HEADERS_ALL
OE_ORDER_LINES_ALL
MTL_SALES_ORDERS
MTL_
GL_CODE_COMBINATIONS DEMAND_
MTL_ INTERFACE
MATERIAL_
TRANSACTIONS MTL_GENERIC_
DISPOSITIONS
MTL_DEMAND
MTL_DEMAND
MTL_DEMAND stores demand and reservation information used in Available
to Promise, Planning, and other manufacturing functions. Four row types are
stored in this table:
• Summary Demand rows
• Dependent Demand rows
• Open Demand rows
• Reservation rows
The primary key is INVENTORY_ITEM_ID, DEMAND_SOURCE_TYPE,
DEMAND_SOURCE_HEADER_ID, DEMAND_SOURCE_LINE (o),
DEMAND_SOURCE_DELIVERY (o), COMPONENT_SEQUENCE_ID (o).
MTL_SALES_ORDERS
MTL_SALES_ORDERS stores the Oracle Inventory local definition of sales
orders and maps sales orders between Oracle Inventory and other Oracle
Manufacturing applications. The primary key is SALES_ORDER_ID.
OE_ORDER_HEADERS_ALL
OE_ORDER_HEADERS_ALL stores header information for orders in Oracle
Order Management. The primary key is HEADER_ID.
OE-ORDER_LINES_ALL
OE_ORDER_LINES_ALL stores information for all order lines in Oracle
Order Management. The primary key is LINE-ID.
GL_CODE_COMBINATIONS
Copyright © Oracle Corporation, 2001. All rights reserved.
Practice 2 Setup
Setup Instructions
Create Miscellaneous Transactions
1. Navigate to the Miscellaneous Transaction form.
(N) Inventory > Transactions > Miscellaneous Transaction
• Select Miscellaneous Receipts from the list of values in the Type field.
• Click Transaction Lines.
• Enter your item numbers for your Purchased items (NOT Planning or
Fnished Good items).
• Select a subinventory (Stores, RIP or Floor Stock) and reasonable quantity
for each item.
• In the Account field, enter “%”, press the tab key and select an account
number.
• Save your work.
Determine On-hand Quantities
2. Navigate to the Find On-hand Quantities form.
(N) Inventory > On-hand, Availability > On-hand Quantity
• Enter each item number you received and verify the on-hand quantity.
Practice 2
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: mtl_system_items, mtl_onhand_quantities, mtl_parameters
• Keys: segmentl, organization_code, organization_id, inventory_item_id
• Columns: inventory_item_id, organization_id, subinventory_code, revision,
locator_id, transaction_quantity
Practice 2 Solution
Agenda
• Item definition
• Inventory transactions
• Open interfaces
Oracle Applications
Open Interfaces for Inventory
Oracle Inventory
Open Transaction Interface
This interface is used as an integration point with Oracle Order Management for
shipment transactions. Oracle Order Management uses the Inventory interface
program to populate the interface tables with transactions submitted through the
Confirm Shipments window.
Open Demand Interface
This interface program provides all the functions you need to interface an
external order entry system with Oracle Inventory and Oracle Manufacturing
applications.
Open Replenishment Interface
This allows you to load replenishment requests from external systems, such as a
bar-code application. Such requests may be in the form of stock-take counts or
requisition requests for subinventories in which you do not track quantities.
Open Item Interface
You can import items from any source into Oracle Inventory and Oracle
Engineering using this interface
Customer Item Interface
You can import customer items and customer item cross-references into Oracle
Inventory to achieve faster order processing and shipments.
Major Tables:
Open Interfaces
• Transactions
• Demand Interface
• Replenishment
Transactions
You can load transactions from external applications and feeder systems using
this interface. These transactions could include sales order shipment
transactions from an external order entry system, or they could be simple
material issues, receipts, or transfers that are loaded from data collection
devices.
This is also used as an integration point with Oracle Order Management for
shipment transactions. The Oracle Order Management Inventory Interface
program populates the interface tables with transactions submitted through the
Ship Confirm window.
Open Demand Interface
This is a two-way interface that lets you have visibility as well as reserve
demand that is created in external applications for forecasting, planning, and
order-promising purposes. This includes the option to automatically check ATP
when adding demand to verify availability.
Open Replenishment Interface
Using this interface, you can load replenishment requests from external systems
such as a bar-code application. Such requests may be in the form of stock-take
counts or requisition requests for subinventories in which you do not track
quantities.
Inventory Transactions
Open Interface Tables
Interface Data Flow Table, Table, View, or Module name
Name Direction View, or
Process
Transactions Inbound Table MTL_TRANSACTIONS_INTERFACE
MTL_SERIAL_NUMBERS_INTERFACE
MTL_TRANSACION_LOTS_INTERFACE
Demand Inbound Table MTL_DEMAND_INTERFACE
Interface
Replenishment Inbound Table MTL_REPLENISH_HEADERS_INT
MTL_REPLENISH_LINES_INT
MTL_SYSTEM_ITEMS_INTERFACE
Item Inbound Table
MTL_ITEMS_REVISIONS_INTERFACE
Customer Item
Inbound Table MTL_CI_XREFS_INTERFACE
Cross-Reference
Summary
Objectives
Lesson Aim
The aim of this lesson is to provide the student an overview of the flow of
purchasing activity from the requisition stage to the receipt stage and discuss the
database tables that are populated as a result of these activities.
Instructor Note
The primary key for each of the ERD tables is in each table definition in the
Notes section of the slides. Example: ‘The primary key is INVENTORY_ID,
ORGANIZATION_ID’, where there are two elements that make up the primary
key. Some _INTERFACE and _TEMP names may not have a primary key
associated with it.
An “(o)” following a primary key name indicates that element to be optional.
Example: ‘WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o)’. In this example it indicates that the
REPETITIVE_SCHEDULE_ID is part of the primary key when you reference
specific Repetitive schedules tables and not part of the primary key when you
reference Discrete job tables.
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
ve
Manually ppro
A
create AutoCreate
PO
Requisition
pool
Maintain documents
Description
Oracle Purchasing is a comprehensive procurement solution, designed to reduce
administration costs while focusing on value analysis, strategic supply base
management, and contract negotiation.
Requisitioning
• Replace paper processing with online requisition generation, purchase order
creation, and document approval.
• Regulate document access, control or modification activity, and approval
based on organizational signature and security policies.
• Minimize data entry time with time-saving templates, express processing
functions, and default infrastructures.
Purchasing
• Control purchasing activity and enable accurate automatic pricing using an
approved supplier list.
• Consolidate purchase requirements from multiple warehouses, plants, or
locations.
Receiving
Receive production items, Maintenance, Receipt and Overhead (MRO) items,
and services using a common flexible receiving process.
Business Communication
• Facilitate communication between requesters, buyers, receiving staff, and
accounts payable staff using online inquiries and notes.
Requisition
RFQ
Quote
Blanket
Contract PO
PO
Standard Blanket PO
PO Release
Purchasing Overview
A requisition is generated either manually or by the system, which is ultimately
turned into a purchase order by the buyer. Sometimes the buyer decides a
Request for Quotation (RFQ) is required by other suppliers to determine the
best price for the goods or services requested. Once the quote is received back,
that information is used to finalize the purchase order.
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
PO -VENDORS RCV_SHIPMENT_HEADERS
PO _VENDOR_SITE S_ALL
RCV_SHIPMENT_LINE S
RCV_TRANSACTIONS
PO _LINES_ALL
PO_VENDORS
This table stores information about your suppliers. Oracle Purchasing uses this
information to determine active suppliers. The primary key is VENDOR_ID.
RCV_SHIPMENT_HEADERS
This table stores common information about the source of your receipts or
expected receipts. You group your receipts by the source type and the source of
the receipt. Oracle Purchasing does not allow you to group receipts from
different sources under one receipt header. The primary key is
SHIPMENT_HEADER_ID.
PO_VENDOR_SITES_ALL
This table stores information about supplier sites. Oracle Purchasing uses this
information to store supplier address information. The primary key is
VENDOR_SITE_ID.
RCV_SHIPMENT_LINES
This table stores information about items that have been shipped or received
from a specific receipt source. This table also stores information about the
default destination for in-transit shipments. The primary key is
SHIPMENT_LINE_ID.
PO_HEADERS_ALL
PO_HEADERS_ALL contains information for your purchasing documents.
Each row contains buyer information, supplier information, notes, foreign
currency information, terms and conditions information, and the document
Suppliers
PO _VENDORS HR_EMPLOYEES
PO _VENDOR_SITE S_ALL
PO _VENDOR_CONTACTS
PO_VENDORS
This table stores information about your suppliers. Oracle Purchasing uses this
information to determine active suppliers. The primary key is VENDOR_ID.
HR_EMPLOYEES
HR_EMPLOYEES is a view that contains information about employees. You
must have a row for each requestor, requisition preparer, approver, buyer, or
receiver who uses Oracle Purchasing. The primary key is EMPLOYEE_ID (o).
PO_VENDOR_SITES_ALL
This table stores information about supplier sites. Oracle Purchasing uses this
information to store supplier address information. The primary key is
VENDOR_SITE_ID.
PO_VENDOR_CONTACTS
This table stores information about supplier site contacts. The primary key is
VENDOR_CONTACT_ID.
Suppliers Window
Suppliers
Suppliers (Vision
(Vision Operations)
Operations)
PO_REQUISITION_HEADERS_ALL
PO_REQUISITION_HEADERS_ALL stores information about requisition
headers. Each row contains the requisition number, preparer status, and
description. It is one of three tables that stores requisition information. The
primary key is REQUISITION_HEADER_ID.
HR_EMPLOYEES
HR_EMPLOYEES is a view that contains information about employees. You
must have a row for each requestor, requisition preparer, approver, buyer, or
receiver who uses Oracle Purchasing. The primary key is EMPLOYEE_ID (o).
PO_REQUISITION_LINES_ALL
This table stores information about requisition lines. Each row contains the line
number, item number, item category, item description, need-by date, deliver-to
location, item quantities, units, prices, requestor, notes, and suggested supplier
information for the requisition line. This table is one of three tables that stores
requisition information. The primary key is REQUISITION_LINE_ID.
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID.
PO_REQ_DISTRIBUTIONS_ALL
PO_REQ_DISTRIBUTIONS_ALL stores information about the accounting
distributions associated with each requisition line. Each requisition line must
have at least one accounting distribution. Each row includes the Accounting
Requisitions Window
req uisitio
n
Purchasing Documents
PO _
PO _LINES_ALL RELEASES_ ALL
PO _LINE_LOCATIONS_ALL
PO _DISTRIBUTIONS_ALL
GL_CODE_COMBINATIONS
®
PO_HEADERS_ALL
PO_HEADERS_ALL contains information for your purchasing documents.
Each row contains buyer information, supplier information, notes, foreign
currency information, terms and conditions information, and the document
status. Oracle Purchasing uses this information to record information related to
a complete document. The primary key is PO-HEADER_ID.
PO_LINES_ALL
PO_LINES_ALL stores current information about each purchase order line.
You need one row for each line you attach to a document. Each row includes
the line number, item number and category unit, price, tax information, and
quantity ordered for the line. Oracle Purchasing uses this information to record
and update item and price information for purchase orders, quotations, and
RFQs. The primary key is PO_LINE_ID.
PO_LINE_LOCATIONS_ALL
This table contains information about purchase order shipment schedules and
blanket agreement price breaks. You must have one row for each schedule or
price break you attach to a document line. Each row contains the location,
quantity, and dates for each shipment schedule. Oracle Purchasing uses this
information to record delivery schedule information for purchase orders and
price break information for blanket purchase orders, quotations, and RFQs. The
primary key is LINE_LOCATION_ID.
PO_DISTRIBUTIONS_ALL
e
pu rcha s
ord e r
Receiving
RCV_SHIPMENT_
HEADERS
PO _ RCV_ MTL_MATERIAL_
DIS TRIBUTIO NS_ALL TRANSACTIONS TRANSACTIONS
RCV_SUPPLY
RCV_SHIPMENT_HEADERS
This table stores common information about the source of your receipts or
expected receipts. You group your receipts by the source type and the source of
the receipt. Oracle Purchasing does not allow you to group receipts from
different sources under one receipt header. The primary key is
SHIPMENT_HEADER_ID.
RCV_SHIPMENT_LINES
This table stores information about items that have been shipped or received
from a specific receipt source. It also stores information about the default
destination for in-transit shipments. The primary key is SHIPMENT_LINE_ID.
PO_LINE_LOCATIONS_ALL
This table contains information about purchase order shipment schedules and
blanket agreement price breaks. You must have one row for each schedule or
price break you attach to a document line. Each row contains the location,
quantity, and dates for each shipment schedule. Oracle Purchasing uses this
information to record delivery schedule information for purchase orders, and
price break information for blanket purchase orders, quotations, and RFQs. The
primary key is LINE_LOCATION_ID.
RCV_TRANSACTIONS
This table stores historical information about receiving transactions you have
performed. Once a row is inserted into this table, it will never be updated. When
you correct a transaction, the net transaction quantity is maintained in
RCV_SUPPLY. The original transaction quantity is not updated. You can delete
Receiving Transactions
One of the many receiving transactions is the
receipt. With the receipt you can display the
supplier shipments and inter-organization
shipments corresponding to your search criteria.
You can receive goods into a receiving location or
to their final destination.
Receipts (M1)
Practice 1 Setup
Setup Instructions
1 Navigate to the Requisition Summary Window
(N) Purchasing > Requisitions > Requisitions Summary
– Enter the item number in the “Item, Rev” field for one of your released
orders
– Note the requisition number, go to step 3
– If you do not find your requisition, go to step 2
2 Create a manual requisition
(N) Purchasing > Requisitions > Requisitions
– Click in the Item field and enter one of your purchased item numbers,
Click the tab key
– Scroll or tab horizontally to fill in the Quantity, Price (less than $10.00)
and Need-By date (use LOV) fields
– Save your work
– Click the Approve button
– Click OK to Submit for Approval
– Click the OK button after the submitted window appears
– Repeat step 1 above
3 Create a purchase order
(N) > Purchasing > Autocreate
Practice 1
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: po_lines_all, po_line_locations_all, mtl_system_items_b
• Keys: segment1, organization_id, item_id, po_line_id, inventory_item_id
• Columns: segment1, item_description, quantity
Practice 1 Solution
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
Oracle Purchasing
Open Requisitions Interface
You can automatically import requisitions from other Oracle applications or
other systems using this interface. This allows you to integrate your Oracle
Purchasing application with new or existing applications, such as material
requirements planning, inventory management, and production control systems.
Your Oracle Purchasing application automatically validates your data and
imports your requisitions. You can import requisitions as often as you want.
Then, you can review these requisitions, approve or reserve funds for them if
necessary, and place them on purchase orders or internal sales orders.
Purchasing Documents Open Interface
You can automatically import and update standard purchase orders, price/sales
catalog information, and responses to request for quotations (RFQs) from
suppliers through this interface. The Purchasing Documents Open Interface uses
the Applications Program Interfaces (APIs) to process document data in the
Oracle Applications interface table to ensure that it is valid before importing it
into Oracle Purchasing. After the data is validated, the program converts the
information in the interface table into the into the appropriate document in
Purchasing.
Receiving Open Interface
You can automatically import receipt information from other Oracle
applications or other systems using the Receiving Open Interface. This interface
lets you integrate your Oracle Purchasing application with new or existing
Summary
Objectives
Lesson Aim
The aim of this lesson is to provide the student an overview of the setup
definition process in Oracle Engineering and Bills of Material and discuss the
database tables that are populated as a result of the setup activity.
Instructor Note
The primary key for each of the ERD tables is in each table definition in the
Notes section of the slides. Example: ‘The primary key is INVENTORY_ID,
ORGANIZATION_ID’, where there are two elements that make up the primary
key. Some _INTERFACE and _TEMP names may not have a primary key
associated with it.
An “(o)” following a primary key name indicates that element to be optional.
Example: ‘WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o)’. In this example it indicates that the
REPETITIVE_SCHEDULE_ID is part of the primary key when you reference
specific Repetitive schedules tables and not part of the primary key when you
reference Discrete job tables.
Agenda
Agenda
Description
Oracle Bills of Material develops and maintains manufacturing bills of material
(BOMs) and routings to drive planning, costing, and work-in-process tracking.
Routings
• Specify department and resources usage.
• Define shop floor controls.
• Maintain multiple revisions of routings.
• Define dynamic, lot based flow routing for operation flexibility.
Bills of Material
• Define component usage, yield, and material control.
• Integrate with routings for point-of-use definition.
• Maintain multiple revisions of bills of material.
Lead Time
Calculate manufacturing lead time to produce goods from routing standards.
Standard Cost
Calculate standard costs from bills of material and routings.
Views and Reports
• Perform a single-level explosion of bills of material (or fully indented
explosions).
• Choose to include or exclude costs in the explosion.
MTL_ MTL_
ITEM_ SECONDARY_
BOM_
LOCATIONS INVENTORIES
INVENTORY_
COMPONENTS
MTL_
BOM_BILL_OF_ MTL_ SYSTEM_
MATERIALS ITEM_ ITEMS_B
PRIMARY REVISIONS
BILL
ALTERNATE
BILL
BOM_
OPERATION_ BOM_ALTERNATE_
SEQUENCES DESIGNATORS
®
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
item attribute BOM_ENABLED allows an item to be used in bills of material.
The primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID.
BOM_BILL_OF_MATERIALS
BOM_BILL_OF_MATERIALS stores information about manufacturing and
engineering bills of material. Each row represents a unique manufacturing or
engineering bill and is defined by its primary key, BILL_SEQUENCE_ID.
BOM_ALTERNATE_DESIGNATORS
BOM_ALTERNATE_DESIGNATORS stores the alternate designators used to
define alternate bills of material and routings. The primary key is
ALTERNATE_DESIGNATOR_CODE (o), ORGANIZATION_ID
BOM_INVENTORY_COMPONENTS
BOM_INVENTORY_COMPONENTS stores information about bill of material
components. COMPONENT_SEQUENCE_ID uniquely identifies each row.
There is one row per component on an operation within a given date range. The
primary key is COMPONENT_SEQUENCE_ID.
BOM_OPERATION_SEQUENCES
You
You can
can create
create bills
bills of
of material
material for
for your
your parent
parent when
when
entering
entering all your component information for
all your component information for that
that bill.
bill.
Bills
Bills of
of Material
Material (M1)
(M1)
Item
Item Revisions
Revisions (M1)
(M1)
BOM_RESOURCES
BOM_
DEPARTMENT_
RESOURCES
BOM_DEPARTMENTS
BOM_RESOURCES
BOM_RESOURCES stores information about material and outside processing
resources. It also stores overhead, material overheads, and material
subelements. COST_ELEMENT_ID determines the resource type. The primary
key is RESOURCE_ID.
BOM_DEPARTMENTS
BOM_DEPARTMENTS stores department information. DEPARTMENT_ID is
the primary key that uniquely identifies each row. You can assign a delivery
location for each department used, which is used with outside processing
resources. The primary key is DEPARTMENT_ID.
BOM_DEPARTMENT_RESOURCES
BOM_DEPARTMENT_RESOURCES stores information about resources that
you assign to a department. You can use these resources on routing operations.
The primary key is DEPARTMENT_ID, RESOURCE_ID.
Outside Processing
Example
B C
Part B is sent for outside processing, and then combined
with Part C to make Part A.
Routing Steps
WIP completion of Part B
Completion of Step 1 signals a requisition for a purchase order for an outside
service
Receive goods back into WIP for completion
Defining a Routing
Routings (M1)
BOM_ALTERNATE_
DESIGNATIONS
®
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
primary key is INVENTORY_ID, ORGANIZATION_ID.
BOM_OPERATIONAL_ROUTINGS
BOM_OPERATIONAL_ROUTINGS stores information about manufacturing
and engineering routings. The primary key is ROUTING_SEQUENCE_ID.
BOM_ALTERNATE_DESIGNATORS
BOM_ALTERNATE_DESIGNATORS stores the alternate designators you use
to define alternate bills of material and routings. The primary code is
ALTERNATE_DESIGNATOR_CODE (o), ORGANIZATION_ID.
MTL_RTG_ITEM_REVISIONS
MTL_RTG_ITEM_REVISIONS stores revision levels for routings. A revision
must be inserted into this table when a routing is defined; every routing has at
least one valid revision. The primary key is INVENTORY_ITEM_ID,
ORGANIZATION_ID, PROCESS_REVISION.
BOM_OPERATION_SEQUENCES
BOM_OPERATION_SEQUENCES stores information about routing
operations. You can define multiple operations for a routing. You must specify
the department in which every operation must occur. The primary key is
OPERATION_SEQUENCE_ID.
BOM_OPERATION_RESOURCES
Practice 1 Setup
Plan Item
FG 1 FG 2
Setup Instructions
• Assign Planning percentages for Finished Good 1 and Finished Good 2
when constructing the Plan Item BOM.
• Vary your QPAs for Purchased Parts 1 through 4 as it suits you, when
building the two finished good BOMs.
• Optionally, assign yields to the purchased parts (values must be between 0
and 1).
Create Bills of Material
1. Navigate to the Bills of Material window.
(N) Bills of Materials > Bills > Bills
• Type in the Item Number for the parent item in the single BOM. Hit the
Tab key. The item description will fill in automatically.
• Place the cursor in the Component Region field.
• Enter the appropriate Component Item Number and hit the Tab key.
• For the two Standard bills, place cursor in “Quantity” field and change
quantity per assembly (QPA) as appropriate.
• Select the Component Details tab. Change the Planning Percentage for the
planning bill and yield values for the Standard bills as appropriate.
• Save your work.
• Repeat step 1 for the remaining BOMs.
Verify Bills of Material
Practice 1
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: mtl_system_items, bom_bill_of_materials,
bom_inventory_components, mtl_system_items
• Keys: segment1, organization_id, inventory_item_id, assembly_item_id,
bill_sequence_id, component_item_id
• Columns: segment1, component_quantity, segmentl
Practice 1 Solution
Practice 2
Setup Instructions
Create Resources
1. Navigate to the Resources form.
(N) Bills of Materials > Routings > Resources
• Enter ##-res as your resource.
• Enter a description for your resource.
• Select Machine as Type.
• Select HR (hour) as UOM.
• Select WIP Move Charge Type.
• Save your work.
Create Departments
2. Navigate to Departments form.
(N) Bills of Materials > Routings > Departments
• Enter ##-dep as your Department.
• Enter Description for your Department.
• Click Resource button.
• Enter your Resource in the Resource field.
• Uncheck the Available 24 Hours box.
• Enter 10 in the Units field.
• Select the Shifts button.
Agenda
Oracle Engineering
Description
Oracle Engineering interacts with other Oracle manufacturing applications to
provide a cohesive integrated business solution. Oracle Engineering helps you
define product and process specifications. It also provides the information
required for effective planning and execution.
Oracle Engineering
• Define engineering and manufacturing bills of material.
• Define engineering and manufacturing routings.
• Manage product changes with engineering change orders (ECOs).
• Create new design specifications using Oracle Engineering.
• Determine resource availability.
• Specify detailed resource use.
Introducing New Products
• Define engineering items, BOMs, and routings to prototype new product
designs.
• Calculate lead times and release engineering prototypes to manufacturing.
Defining Planning Bills
• Define planning bills to assist with sales strategy.
• Provide BOM maintenance.
Managing Engineering Changes
BOM_BILL_OF_ MTL_
MATERIALS SYSTEM_
PRIMARY ITEMS_B
ENG_ BILL
REVISED_
COMPONENTS ENG_
ALTERNATE
REVISED_ BILL
ITEMS
ENG_
CHANGE_
ORDER_
REVISIONS ENG_ENGINEERING_CHANGES
®
ENG_ENGINEERING_CHANGES
ENG_ENGINEERING_CHANGES stores information about engineering
change order headers. Each row includes the unique identifier of the ECO, a
description, change order type, the reason and priority codes, the status and the
requestor, approval list and approval status, implementation costs, and
cancellation information. The primary key is CHANGE_NOTICE,
ORGANIZATION_ID.
ENG_CHANGE_ORDER_REVISIONS
ENG_CHANGE_ORDER_REVISIONS stores information about the user-
defined revisions of an engineering change order. It is a child table of
ENG_ENGINEERING_CHANGES. The primary key is REVISION_ID.
ENG_REVISED_ITEMS
ENG_REVISED_ITEMS stores information about the revised items (usually
assemblies) on an engineering change order. It is a child table of
ENG_ENGINEERING_CHANGES. The primary key is
REVISED_ITEM_SEQUENCE_ID.
ENG_CURRENT_SCHEDULED_DATES
ENG_CURRENT_SCHEDULED_DATES stores information about the
effective date for each revised item on an engineering change order. Each time
the effective date for a revised item on an ECO is changed, a new row is
inserted into this table. The primary key is SCHEDULE_ID,
REVISED_ITEM_SEQUENCE_ID (o).
BOM_BILL_OF_MATERIALS
Copyright © Oracle Corporation, 2001. All rights reserved.
Practice 3 Setup
Setup Instructions
Create an ECO
1. Navigate to the Engineering Change Orders form.
(N) Engineering > ECOs > ECOs
• Enter ##-eco in the first field on the header form. In the other header fields,
enter any values you choose from the list of values (Caution: Do NOT use
the New Prod change type; it is set up for a Workflow process).
• Click the Revised Items button and enter the item number of the BOM you
wish to change.
• Optionally, enter a new revision.
• Enter an effective date of a week from today.
• Click the Components button.
• Go to the Action field and select Disable from the list of values.
• Enter the item number of the component you wish to disable.
• Return to the Action field, and select Add from the list of values.
• Enter the item number of your new component.
• Enter the new sequence for the component.
• Return to the header form, and change the approval status to Approved, if
necessary.
• Save your work.
• Record your ECO number _____________.
Practice 3
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: eng_engineering_changes, mtl_system_items, eng_revised_items
• Keys: change_notice, revised_item_id, inventory_item_id,
• Columns: change_notice, segmentl
Practice 3 Solution
Agenda
Summary
Objectives
Lesson Aim
The aim of this lesson is to provide the student an overview of the flow of
inventory through a factory and the resulting transactions that occur in Oracle
Inventory, and discuss the database tables that are populated as a result of these
activities.
Instructor Note
The primary key for each of the ERD tables is in each table definition in the
Notes section of the slides. Example: ‘The primary key is INVENTORY_ID,
ORGANIZATION_ID’, where there are two elements that make up the primary
key. Some _INTERFACE and _TEMP names may not have a primary key
associated with it.
An “(o)” following a primary key name indicates that element to be optional.
Example: ‘WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o)’. In this example it indicates that the
REPETITIVE_SCHEDULE_ID is part of the primary key when you reference
specific Repetitive schedules tables and not part of the primary key when you
reference Discrete job tables.
Agenda
Agenda
WIP_ENTITIES
WIP_REPETITIVE_ WIP_
ITEMS OPERATIONS
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID.
WIP_ENTITIES
WIP_ENTITIES stores information about each discrete job or repetitive
assembly. Each row includes a unique discrete job or repetitive assembly name,
entity type, and the assembly built by the job or by the repetitive assembly. The
primary key is WIP_ENTITY_ID.
WIP_REPETITIVE_ITEMS
WIP_REPETITIVE_ITEMS stores your repetitive assemblies and the
production lines on which you build each assembly. Each row represents a
particular assembly/line combination. The primary key is WIP_ENTITY_ID,
LINE_ID.
WIP_REPETITIVE_SCHEDULES
WIP_REPETITIVE_SCHEDULES stores repetitive schedule information.
Oracle Work in Process uses this information to control repetitive production.
The primary key is REPETITIVE_SCHEDULE_ID.
WIP_DISCRETE_JOBS
WIP_DISCRETE_JOBS stores information about discrete jobs. Each row
represents a discrete job. Oracle Work in Process uses this information to
control discrete production. The primary key is WIP_ENTITY_ID.
MTL_
SYSTEM_
ITEMS_B
WIP_
WIP_ DISCRETE_JOBS
REPETITIVE_
SCHEDULES MTL_
ITEM_
LOCATIONS
WIP_OPERATION_ WIP_
RESOURCES SHOP_FLOOR_
STATUSES
WIP_OPERATIONS
®
WIP_REQUIREMENT_OPERATIONS
WIP_REQUIREMENT_OPERATIONS stores information about the material
requirements for jobs or schedules. Oracle Work in Process uses this
information to track the material used in a job or schedule. The primary key is
INVENTORY_ITEM_ID, WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
WIP_REPETITIVE_SCHEDULES
WIP_REPETITIVE_SCHEDULES stores repetitive schedule information.
Oracle Work in Process uses this information to control repetitive production.
The primary key is REPETITIVE_SCHEDULE_ID.
WIP_OPERATIONS
WIP_OPERATIONS stores information about the operations for your discrete
jobs and repetitive schedules. Oracle Work in Process uses this information to
control and monitor your assembly production on the shop floor. The primary
key is WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
primary key is INVENTORY_ITEM_ID, ORGANIZATION_ID.
MTL_ITEM_LOCATIONS
MTL_MATERIAL_
TRANSACTIONS WIP_ENTITIES
WIP_
WIP_ ACCOUNTING_
WIP_ CLASSES
OPERATION_ REQUIREMENT_
RESOURCES OPERATIONS
WIP_
DISCRETE_
JOBS WIP_WORK_
ORDER_
INTERFACE
WIP_OPERATIONS
WIP_DISCRETE_JOBS
WIP_DISCRETE_JOBS stores information about discrete jobs. Each row
represents a discrete job. It also contains the information about the assembly
being built, the revision of the assembly, the job quantity, the job status,
accounting information, and job schedule dates. Oracle Work in Process uses
this information to control discrete production. The primary key is
WIP_ENTITY_ID.
WIP_OPERATIONS
WIP_OPERATIONS stores information about the operations for your discrete
jobs and repetitive schedules. Oracle Work in Process uses this information to
control and monitor your assembly production on the shop floor. The primary
key is WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
WIP_REQUIREMENT_OPERATIONS
WIP_REQUIREMENT_OPERATIONS stores information about the material
requirements for jobs or schedules. Oracle Work in Process uses this
information to track the material used in a job or schedule. The primary key is
INVENTORY_ITEM_ID, WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
WIP_OPERATION_RESOURCES
WIP_OPERATION_RESOURCES stores information about the resources
associated with an operation for a job or a repetitive schedule. Oracle Work in
Process uses this information to schedule jobs and repetitive schedules, and to
MTL_MATERIAL_ WIP_
WIP_REPETITIVE_ITEMS ACCOUNTING_
TRANSACTIONS
CLASSES
WIP_OPERATIONS
WIP_
WIP_ WORK_ORDER_
REPETITIVE_ INTERFACE
WIP_ WIP_ SCHEDULES
REQUIREMENT_ OPERATION_
OPERATIONS RESOURCES
WIP_REPETITIVE_ITEMS
WIP_REPETITIVE_ITEMS stores your repetitive assemblies and the
production lines on which you build each assembly. Each row represents a
particular assembly/line combination and includes information such as the line
priority, the accounting class associated with the line, the line speed, the line’s
supply type, if the line is used in calculating the assembly’s lead time, the
completion subinventory and locator for a line, and the alternate bill and routing
you use for a particular line. Oracle Work in Process uses this information when
you define repetitive schedules. Oracle Master Schedule/MRP and Oracle
Capacity use this information when mass loading repetitive schedules and
running capacity loads on repetitive schedules. The primary key is
WIP_ENTITY_ID, LINE_ID.
WIP_REPETITIVE_SCHEDULES
WIP_REPETITIVE_SCHEDULES stores repetitive schedule information.
Oracle Work in Process uses this information to control repetitive production.
The primary key is REPETITIVE_SCHEDULE_ID.
WIP_OPERATIONS
WIP_OPERATIONS stores information about the operations for your discrete
jobs and repetitive schedules. Each row represents a specific operation and
includes an operation sequence number to order the operations for a job or
repetitive schedule. Oracle Work in Process uses this information to control and
monitor your assembly production on the shop floor. The primary key is
You
You can
can display
display the
the assemblies
assemblies with
with their
their statuses
statuses for
for
aa repetitive
repetitive line.
line.
Repetitive
Repetitive Schedules
Schedules Summary
Summary (M1)
(M1)
Agenda
Issue
material
Jobs and
Raw material
schedules
inventory Complete
finished
assemblies Move assemblies on
the shop floor and
charge resources
Finished goods
Scrap rejected
subinventory assemblies
MTL_
TRANSACTION_
ACCOUNTS
MTL_ WIP_
WIP_
MATERIAL_TXN REQUIREMENT_
OPERATIONS
ALLOCATIONS OPERATIONS
MTL_
MATERIAL_ WIP_DISCRETE_JOBS
TRANSACTIONS
®
MTL_MATERIAL_TXN_ALLOCATIONS
This table stores the repetitive schedules charged by a material transaction. Each
row contains the quantity transacted to each schedule for a given transaction.
Oracle Work in Process uses this information to report changes to individual
schedules for multischedule material transactions. The primary key is
TRANSACTION_ID, REPETITIVE_SCHEDULE_ID, ORGANIZATION_ID.
MTL_TRANSACTION_ACCOUNTS
This table holds the accounting information for each material transaction in
MTL_MATERIAL_TRANSACTIONS. Oracle Inventory uses this information
to track the financial impact of quantity moves. (There is no primary key for
this table.)
MTL_MATERIAL_TRANSACTIONS
This table stores a record of every material transaction, including issues and
returns of component items in Work in Process. Records are inserted into this
table through the transaction processor. The primary key is
TRANSACTION_ID.
WIP_REQUIREMENT_OPERATIONS
This table stores information about the material requirements for jobs or
schedules. Oracle Work in Process uses this information to track the material
used in a job or schedule. The primary key is INVENTORY_ITEM_ID,
WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
WIP_OPERATIONS
Copyright © Oracle Corporation, 2001. All rights reserved.
WIP
WIP Material
Material Transactions
Transactions (M1)
(M1)
WIP_
OPERATIONS
WIP_
DISCRETE_JOBS
WIP_
TRANSACTIONS WIP_
OPERATION_
RESOURCES
WIP_MOVE_ MTL_MATERIAL_
TRANSACTIONS TRANSACTIONS
®
WIP_DISCRETE_JOBS
WIP_DISCRETE_JOBS stores information about discrete jobs. Each row
represents a discrete job. Oracle Work in Process uses this information to
control discrete production. The primary key is WIP_ENTITY_ID.
WIP_REPETITIVE_SCHEDULES
WIP_REPETITIVE_SCHEDULES stores repetitive schedule information.
Oracle Work in Process uses this information to control repetitive production.
The primary key is REPETITIVE_SCHEDULE_ID.
MTL_MATERIAL_TRANSACTIONS
This table stores a record of every material transaction, including issues and
returns of component items in Work in Process. Records are inserted into this
table through the transaction processor. The primary key is
TRANSACTION_ID.
WIP_OPERATIONS
WIP_OPERATIONS stores information about the operations for your discrete
jobs and repetitive schedules. Each row represents a specific operation and
includes an operation sequence number to order the operations for a job or
repetitive schedule. Oracle Work in Process uses this information to control and
monitor your assembly production on the shop floor. The primary key is
WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
WIP_OPERATION_RESOURCES
Move
Move Transactions
Transactions (M1)
(M1)
WIP_OPERATION_ WIP_
OVERHEADS OPERATIONS WIP_
DISCRETE_
WIP_ JOBS
TRANSACTION_
ACCOUNTS
®
WIP_DISCRETE_JOBS
WIP_DISCRETE_JOBS stores information about discrete jobs. Each row
represents a discrete job. Oracle Work in Process uses this information to
control discrete production. The primary key is WIP_ENTITY_ID.
WIP_REPETITIVE_SCHEDULES
WIP_REPETITIVE_SCHEDULES stores repetitive schedule information.
Oracle Work in Process uses this information to control repetitive production.
The primary key is REPETITIVE_SCHEDULE_ID.
WIP_OPERATIONS
WIP_OPERATIONS stores information about the operations for your discrete
jobs and repetitive schedules. Each row represents a specific operation and
includes an operation sequence number to order the operations for a job or
repetitive schedule. Oracle Work in Process uses this information to control and
monitor your assembly production on the shop floor. The primary key is
WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
WIP_OPERATION_RESOURCES
WIP_OPERATION_RESOURCES stores information about the resources
associated with an operation for a job or a repetitive schedule. Oracle Work in
Process uses this information to schedule jobs and repetitive schedules, and to
charge resources to jobs and schedules. The primary key is WIP_ENTITY_ID,
OPERATION_SEQ_NUM, RESOURCE_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o).
MTL_
TRANSACTION
ACCOUNTS
MTL_MATERIAL_
WIP_FLOW_
TRANSACTIONS_
SCHEDULES
TEMP
MTL_MATERIAL_
TRANSACTIONS
WIP_DISCRETE_
JOBS
WIP_DISCRETE_JOBS
WIP_DISCRETE_JOBS stores information about discrete jobs. Each row
represents a discrete job. Oracle Work in Process uses this information to
control discrete production. The primary key is WIP_ENTITY_ID.
WIP_REPETITIVE_SCHEDULES
WIP_REPETITIVE_SCHEDULES stores repetitive schedule information.
Oracle Work in Process uses this information to control repetitive production.
The primary key is REPETITIVE_SCHEDULE_ID.
MTL_MATERIAL_TRANSACTIONS_TEMP
MTL_MATERIAL_TRANSACTIONS_TEMP is the gateway for all material
transactions. Transfer records are stored in this table as a single record. The
primary key is TRANSACTION_HEADER_ID (o).
MTL_MATERIAL_TRANSACTIONS
MTL_MATERIAL_TRANSACTIONS stores a record of every material
transaction or cost update performed in Oracle Inventory. Records are inserted
into this table either through the transaction processor or by the standard cost
update program. The primary key is TRANSACTION_ID.
MTL_TRANSACTION_ACCOUNTS
MTL_TRANSACTION_ACCOUNTS holds the accounting information for
each material transaction in MTL_MATERIAL_TRANSACTIONS. Oracle
Inventory uses this information to track the financial impact of quantity moves.
There is no primary key for this table.
MTL_MATERIAL_
TRANSACTIONS
MTL_MATERIAL_ WIP_
TRANSACTIONS_ WIP_
FLOW_
TEMP SCHEDULES TRANSACTIONS
BOM_
BILL_OF_
WIP_ENTITIES
MATERIALS
BOM_
OPERATIONAL_
ROUTINGS
®
WIP_FLOW_SCHEDULES
WIP_FLOW_SCHEDULES stores Work Order-less Flow schedule
information. Each row represents a Flow schedule. Oracle Work in Process uses
this information to control Flow schedule production. The primary key is
WIP_ENTITY_ID.
MTL_TRANSACTIONS_INTERFACE
MTL_TRANSACTION_INTERFACE is the interface point between non
Oracle Inventory applications and the Oracle Inventory transaction module.
Transaction Manager concurrent program polls this table at a user specified
process interval, and submits the Transaction Workers to process them. There is
no primary key for this table.
MTL_MATERIAL_TRANSACTIONS
MTL_MATERIAL_TRANSACTIONS stores a record of every material
transaction or cost update performed in Oracle Inventory. Records are inserted
into this table either through the transaction processor or by the standard cost
update program. The primary key is TRANSACTION_ID.
MTL_MATERIAL_TRANSACTIONS_TEMP
MTL_MATERIAL_TRANSACTIONS_TEMP is the gateway for all material
transactions. Transfer records are stored in this table as a single record. The
primary key is TRANSACTION_HEADER_ID.
BOM_BILL_OF_MATERIAS
Practice 1 Setup
Setup Instructions
Navigate to the Discrete Jobs window.
. (N)WIP > Discrete > Discrete Jobs
• Enter your assembly number in the Assembly field and choose Find.
• In the Discrete Job Summary window, select one of your jobs and Open it
• Record your job number
• Change the status of your job to “Released” from the LOV
• Click in the Bill box for a list of regions and select Routing
• Enter a Completion Subinventory from the LOV
• Save your work
• Check the operation and component information for your assembly
• Navigate to the Material Requirements window.
(N) WIP-> Job/Schedule Details->Material Requirements
• Change some of your components to Push supply type.
• Save your work.
• Navigate to the WIP Material Transaction window.
(N) WIP > Material Transactions > WIP Material Transactions
• Enter your job number and click Continue (you should see your Push
components in the window for issue); then select Done.
• Navigate to the Move Transactions window.
Practice 1
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: wip_discret_jobs, mtl_system_items_b, mfg_lookups
• Keys: segment1, organization_id, inventory_item_id, primary_item_id,
status_type
• Columns: lookup_type, lookup_code, meaning, wip_entity_id, description,
start_quantity, quantity_completed, scheduled_completion_date
Practice 1 Solution
Agenda
Summary
Objectives
Lesson Aim
The aim of this lesson is to provide the student an overview of the setup
definition process in Oracle Cost and discuss the database tables that are
populated as a result of the costing setup activity.
Instructor Note
The primary key for each of the ERD tables is in each table definition in the
Notes section of the slides. Example: ‘The primary key is INVENTORY_ID,
ORGANIZATION_ID’, where there are two elements that make up the primary
key. Some _INTERFACE and _TEMP names may not have a primary key
associated with it.
An “(o)” following a primary key name indicates that element to be optional.
Example: ‘WIP_ENTITY_ID, OPERATION_SEQ_NUM,
REPETITIVE_SCHEDULE_ID (o)’. In this example it indicates that the
REPETITIVE_SCHEDULE_ID is part of the primary key when you reference
specific Repetitive schedules tables and not part of the primary key when you
reference Discrete job tables.
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
Description
Oracle Cost Management automatically performs the cost accounting for all
your Oracle Inventory, Work in Process, and Purchasing transactions. Your
inventory and work-in-process costs are up-to-date, and your inventory value
matches the cumulative total of your accounting transactions.
Standard Costing
• Oracle Cost Management supports standard costing for inventory, bills of
material, and work-in-process costing.
• Organizations that use Oracle Work in Process must use standard costing. If
you use Oracle Inventory without Oracle Work in Process, you can choose
either standard or average costing.
• You may use standard costing for one organization and average costing for
another organization.
Average Costing
• Oracle Cost Management supports average costing for inventory. Average
costs
are automatically updated as transactions are processed.
• If you have Oracle Bills of Material installed and do not use Oracle Work in
Process for your organization, you may transact your inventory at average, and
use the standard cost features for product cost simulations and budgeting.
Extensive Cost Simulation Capability
Cost Information
Cost rollup
Engineering
information
Cost update
Cost Processes
There are two main processes in defining costs: cost updates and cost rollups.
Costs are defined at the item level and the cost rollup process will determine
costs at the higher levels as defined in the bill of material. Typically, a series of
cost rollups are performed in order to:
• determine appropriate cost information at the higher bill of material levels
• perform a cost update to freeze costs for the next period, when final costs
seem appropriate.
Each of these processes runs exclusively to avoid conflict in processing, since
there is a general ledger impact. As items are sold, a cost variance for a gain or
loss is recorded in the general ledger.
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
MTL_SYSTEM_ITEMS_B
CST_COST_
CST_COST_TYPES ELEMENTS
BOM_
CST_ITEM_COSTS CST_ACTIVITIES RESOURCES
CST_ITEM_COST_DETAILS
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
primary key is INVENTORY_ID, ORGANIZATION_ID.
CST_COST_TYPES
CST_COST_TYPES stores the cost type definition. Cost types represent sets of
costs, frozen cost, or next year’s cost. The table is seeded with the following
costs types:
• Frozen: The organization uses the standard costing method.
• Pending: For standard cost organizations, Pending charges to the frozen
cost.
• Average: The organization uses the average costing method.
• FIFO: The organization uses the FIFO costing method.
• LIFO: The organization uses the LIFO costing method.
You can define as many additional cost types as you want. The primary key is
COST_TYPE_ID.
CST_ITEM_COSTS
CST_ITEM_COSTS stores the cost control information. The Define Item Cost
window inserts information into this table. The primary key is
INVENTORY_ITEM_ID, ORGANIZATION_ID, COST_TYPE_ID.
CST_COST_ELEMENTS
MTL_SYSTEM_ITEMS_B
CST_COST_
CST_COST_TYPES ELEMENTS
BOM_
CST_ITEM_COSTS CST_ACTIVITIES RESOURCES
CST_QUANTITY_LAYERS
CST_LAYER_
COST_DETAILS
®
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B is the definition table for items. This table holds the
definitions for inventory items, engineering items, and purchasing items. The
primary key is INVENTORY_ID, ORGANIZATION_ID.
CST_COST_TYPES
CST_COST_TYPES stores the cost type definition. Cost types represent sets of
costs, frozen cost, or next year’s cost. The table is seeded with the following
costs types:
• Frozen: The organization uses the standard costing method.
• Pending: For standard cost organizations, Pending charges to the frozen
cost.
• Average: The organization uses the average costing method.
• FIFO: The organization uses the FIFO costing method.
• LIFO: The organization uses the LIFO costing method.
You can define as many additional cost types as you want. The primary key is
COST_TYPE_ID.
CST_ITEM_COSTS
CST_ITEM_COSTS stores the cost control information. The Define Item Cost
form inserts information into this table. The primary key is
INVENTORY_ITEM_ID, ORGANIZATION_ID, COST_TYPE_ID.
CST_COST_ELEMENTS
CST_
RESOURCE_
COSTS
BOM_RESOURCES
MATERIAL OVERHEAD
CST_
MATERIAL RESOURCE/
OUTSIDE RESOURCE_ BOM_
OVERHEAD PROCESSING OVERHEADS DEPARTMENTS
CST_DEPARTMENT_OVERHEADS
®
BOM_DEPARTMENTS
BOM_DEPARTMENTS stores department information. DEPARTMENT_ID is
the primary key and uniquely identifies each row.
CST_RESOURCE_COSTS
CST_RESOURCE_COSTS stores resource and outside processing resource unit
costs by a cost type. The primary key is RESOURCE_ID, COST_TYPE_ID.
CST_COST_TYPES
CST_COST_TYPES stores the cost type definition. Cost types represent sets of
costs, frozen cost, and next year’s cost. The table is seeded with the following
costs types:
• Frozen: The organization uses the standard costing method.
• Pending: For standard cost organizations, Pending charges to the frozen
cost.
• Average: The organization uses the average costing method.
• FIFO: The organization uses the FIFO costing method.
• LIFO: The organization uses the LIFO costing method.
You can define as many additional cost types as you want. The primary key is
COST_TYPE_ID.
CST_RESOURCE_OVERHEADS
Item
Item Costs
Costs Summary
Summary (M1)
(M1)
Current Item
Item Costs
Costs Details
Details (M1)
(M1)
Engineering
Frozen
Pending Current
Practice 1 Setup
Setup Instructions
1 Assign Material and Material Overhead costs.
(N) Cost > Item Costs > Item Costs (B) New
a Enter your Finished Good item numbers, enter a cost type of Pending.
b Save your work.
c Enter your a Purchased item number, enter a cost type of Pending.
d Click the Costs button.
e Enter Material as your Cost Element.
f Select an Amount.
g Go to the next row down and select Material Overhead as your Cost
Element.
i Select Mat’l Mgmt as your SubElement.
j Select Total Value as your Basis.
k Enter any decimal percentage ( e.g. 5% = .05) in the Rate/Amount field.
l Save your work.
Repeat steps c through i for the remainder of your purchased items.
2 Assign Resource costs
(N) Bills of Materials > Routings > Resources
a Query up your resource.
b Click the Costed & Standard Rate check boxes.
Practice 1
Instructions
Enter the following values for Tables, Keys, and Columns:
• Tables: mtl_system_items_b, cst_item_costs, cst_cost_types
• Keys: segment1, cost_type, organization_id, cost_type_id, ventory_item_id
• Columns: segment1, material_cost, material_overhead_cost, cost_type_id
Practice 1 Solution
Agenda
• Overview
• Entity Relationship Diagrams (ERDs)
• Open interfaces
Summary