Oracle Work in

Process
Backflush
Processing

Table of Contents
1. OVERVIEW............................................................................................................................................1
2. WHAT IS BACKFLUSHING?.........................................................................................................................1
3. WHEN DO BACKFLUSH TRANSACTIONS OCCUR?...........................................................................................1
4. PROCESS 1 : COMPLETE ASSEMBLIES AT OPERATION - MOVE TXN FORM...............................................2
5. PROCESS 2 : MOVE & COMPLETE ASSEMBLIES INTO INV.................................................................................4
6. PROCESS 3 : COMPLETING ASSEMBLIES COMPLETION TRANSACTION FORM.....................................................6
7. PROCESS 4 : RECEIVE ASSEMBLIES FROM OSP OPETRATION : PURCHASING.....................................................7
8. PROCESS 5 : WORK ORDER-LESS COMPLETIONS WINDOW..............................................................................9
9. PROCESS 6 : OPEN MOVE TRANSACTION INTERFACE : OVERVIEW...................................................................10
10. PROCESS 7 : INVENTORY TRANSACTION INTERFACE : OVERVIEW.................................................................11
11. PROCESSING MODES : ONLINE AND BACKGROUND PROCESSING (INCLUDING INTERFACE PROCESSING IN DETAIL) 11
12. BACKFLUSH PROCESSING (TYPES, RULES, GENERAL POINTS, LOT & SERIAL BACKFLUSH, RESOURCES, MISC POINTS)
............................................................................................................................................................20
13. HOW TO VIEW BACKFLUSH TRANSACTIONS..............................................................................................24
14. HOW HAS BACKFLUSH FUNCTIONALITY CHANGED OVER DIFFERENT APPLICATION RELEASES?...........................29
15. COMMON BACKFLUSH ISSUES AND HOW TO CORRECT THEM......................................................................31

1. OVERVIEW
The objectives of this white paper are to consolidate and
clarify information about backflushing and related issues.
There is no existing document which collates all the relevant
topics together. This white paper will aim to fulfill this need
and discuss the following in detail :

To explain what backflush transactions do

To explain how backflushing works in Move and
Completion transactions
To explain the differences between Online processing
and Background processing and relate these to
backflush transactions
To understand any differences in the behaviour of
backflush transactions in different application releases.
This will also discuss any key patches that are required.
To explain what happens when backflush transactions
fail and discuss how to correct them

2. WHAT IS BACKFLUSHING?
In the Bills of Material module, when a bill is created for any
assembly, sub-assembly or a finished good, the component
supply type for each component in the bill has to be defined.
These supply types are push, operation pull, assembly pull,
Bulk, Supplier and phantom. This Bills of material is used in
Work in Process module for manufacturing the assembly/subassembly/finished good.
If the supply type of a component is Push, the components
have to be manually issued to the shop floor for the
manufacturing process.
Assembly Pull and Operation Pull components are supplied in
a different way. When a particular operation or an assembly
is completed during manufacturing,
ie during move
transactions or completion transactions, the system
automatically BACKFLUSHES components from the supply
subinventory and locator. No manual issuing of components is
required.
The term backflushes in this case refers to the process of
automatically REDUCING the component quantity from the
subinventory-locator on hand quantity when any assembly or
an operation is completed in the WIP module manufacturing
process. At the same time as reducing the inventory for the
component, the system will issue the component to the work
order .

3. WHEN DO BACKFLUSH TRANSACTIONS OCCUR?

Backflush transactions 'pull' components with Operation Pull

and Assembly Pull supply types from inventory onto jobs and
repetitive schedules. Backflush transactions can be launched
by the following six different processes :
1. Completing assemblies at operations using the Move
Transactions window
2. Moving and completing assemblies into inventory using the
Move Transactions window
3. Completing
assemblies
into
Completion Transactions window
4.

inventory

using

the

Receiving assemblies from an outside processing

operation using the Oracle Purchasing, Enter Receipts
window.

5. Move transactions imported through the Open Move

Transaction
Interface
can
also
create
backflush
transactions
6. Transactions imported through the Oracle Inventory,
Inventory Transactions Interface can also create backflush
transactions.
Each of the above six processes will be discussed in detail.
It is possible to
reverse backflush transactions and
automatically return backflushed components back to
inventory. For example, pull components that are backflushed
as you move assemblies to the next intraoperation step in a
routing are automatically returned to inventory if you move
assemblies to a previous step in the routing or if you return
completed assemblies back from inventory to the job.
We will now discuss the different processes that lead to
backflush transactions.
4. PROCESS 1 : COMPLETE ASSEMBLIES AT OPERATION MOVE TXN FORM
Navigation : Work in Process>Move Transactions>Move
Transactions
Form Name : WIPTXSFM
When move transactions are performed from the Move
Transaction Form to COMPLETE assemblies at an operation,
2

then operation pull backflush transactions automatically take

place for all components with a supply type of Operation Pull
that are defined at that operation. This means that that the
inventory for the components is pulled into that operation.

The assemblies are completed at the OPERATION stage in the

Move Transaction Form when :

The move transaction type is MOVE

Moving assemblies from the Queue or Run

intraoperation step of an operation to the To Move,
Scrap or Reject intraoperation steps of the same
operation

Moving assemblies from the Queue or Run

intraoperation steps of an operation to the To Move,
Scrap or Reject intraoperation steps of a subsequent
operation

Assemblies are not completed at Operations by:

Moving assemblies between the To Move, Scrap, and

3

Reject intraoperation steps of the same operation

Moving assemblies from the To Move, Scrap, or Reject

intraoperation steps of the one operation to the Queue
or Run intraoperation step of a subsequent operation
So what happens when an assembly is completed at the
operation stage as above? Backflush of components takes
place (using operation pull backflush transactions)
and
resources are charged. See the following sections for a
detailed explanation :

Backflushing Process (section 11 : operation pull

backflush transactions see below)

Charging of Resources (section 11: see below)

5. PROCESS 2 : MOVE & COMPLETE ASSEMBLIES INTO

INV
Navigation : Work in Process>Move Transactions>Move
Transactions
Form Name : WIPTXSFM
Backflush transactions also take place when an ASSEMBLY
MOVE COMPLETION TRANSACTION takes place.
This is a transaction performed from the Move Transaction
Form. Assembly move completion transactions MOVE
assemblies from the current operation to the To Move
intraoperation step of the last operation then COMPLETE them
into inventory. Assemblies are completed into the default
completion subinventory and locator specified for the discrete
job or repetitive line/assembly.

The transaction type used for this is Complete.

When completing assemblies, information from the last
operation of the job or schedule is automatically defaulted into
the operation To fields - Sequence, Code, and Department and the To Move intraoperation step is defaulted for the To
Step.
The other inputs required are : UOM, quantity, date , From
Operation Sequence and From Intraoperation Step.
So what happens when an assembly is completed into
inventory as above?
Backflush of components takes place
and resources are charged. See the following sections for a
detailed explanation :

Backflushing Process (section 11:see below) . It should

be noted that in this case TWO different types of
backflush transaction take place. Firstly, when the
assembly is moved to the To Move step of the last
operation this initiates the backflush of any
components with the supply type of Operation Pull .
Then when the assembly is completed into inventory,
the backflush of all Assembly Pull components takes
place. (see the backflush processing section below).
5

Charging of Resources (see below)

6. PROCESS 3 : COMPLETING ASSEMBLIES COMPLETION TXN FORM

Navigation : Work in Process>Material
Transactions>Completion Transactions
Form Name : WIPTXCMP
The next place where Backflush Transactions originate from is
the Completion Transaction Form. Backflushing takes place
when you complete assemblies into inventory from the
Completion Transaction Form.
The transaction type required is WIP Assembly Completion

This form allows the user to specify the subinventory and

locator into which the completed assemblies will be placed in
inventory. These fields are defaulted from the wip parameters
but can be overwritten.
So what happens when an assembly is completed into
inventory as above?
Backflush of components takes place
and resources are charged. See the following sections for a
detailed explanation :

Backflushing Process (section 11: see below) . If you are

completing assemblies that have Assembly Pull
components, the system pulls (backflushes) these
components from the supply subinventory/locator
assigned to the component requirement. (or uses
system defaults for subiventory/locator)

Charging of Resources (see below)

7. PROCESS 4 : RECEIVE ASSEMBLIES FROM OSP

OPERATION : PURCHASING
Backflush transactions are also initiated when assemblies are
received from a supplier for an outside processing operation
using the Enter Receipts window.
Navigation : Purchasing Super User> Receiving> Receipts
Form Name : RCVRCERC

The receipt of the assembly for the outside processing

operation will only initiate a backflush transaction if the
following conditions are met :

The receipt transaction must be linked to an OSP

resource.
The OSP resource must have an autocharge type of PO
Move.
The outside processing operation has components of
supply type Operation Pull.

Note the following points about the activities that are

initiated by the receipt of the assemblies :

Since the autocharge type for the OSP resource is PO

Move, the system will automatically perform a Move
Transaction to complete the assemblies at the OSP
Operation. (by placing a record in the Open Move
Transaction table for processing).
The move transaction completes the assemblies at the
OSP operation by moving assemblies from the Queue
or Run intraoperation step of an operation to the To
8

Move, Scrap or Reject intraoperation steps of the same

operation or a subsequent operation.
This will then trigger the backflush of the Operation
Pull components defined for the OSP Operation.
If the OSP Operation is the last operation on the job,
then a completion transaction will also be automatically
performed. This means that the assemblies would be
completed into inventory. This therefore means that any
Assembly Pull components defined for the assembly
would be backflushed at this stage.

For more details of the actual Backflush transactions, see the

section below on Backflush Processing (section 11).

8. PROCESS 5 : WORK ORDER-LESS COMPLETIONS

WINDOW
Navigation : Work in Process> Material Transactions>Work
Order-less completions
Form Name : WIPTXCFM

The following actions can be performed from this form all

these actions initiate backflushing of components :

Assemblies can be completed in this window without

having the need for a job or a repetitive schedule.

Used to complete assemblies for Flow Schedules from

Flow Manufacturing.

Used to complete assemblies for Flow Schedules which

are created to replenish Production Kanbans.

Used to complete scheduled and unscheduled

assemblies

When assemblies are completed into inventory using this form,

components are backflushed.
Note the following about backflushing when it originates from
Work order-less completions :
In this case, (and only in this case) - the following supply types
are backflushed :

Assembly Pull

Operation Pull

PUSH

Phantom Components (the bills for phantoms are

exploded and the phantoms then backflushed)

The supply types of Bulk and Supplier are NOT backflushed.

The backflush window displays for component information for
supply type Push and for Pull components requiring additional
information, such as lot or serial number. You can change the
transaction quantity when the Work in Process parameter,
Allow Quantity Changes During Backflush, is enabled.

9. PROCESS 6 : OPEN MOVE TRANSACTION INTERFACE OVERVIEW

10

Name of Interface : Open Move Transaction Interface

Table used : WIP_MOVE_TXN_INTERFACE
The Open Move Transansaction interface can be used to
process Move and Complete Transactions and therefore
initiate Backflush Transactions. This topic will be discussed in
detail in the Background Processing Section later.
10. PROCESS 7 : INVENTORY TRANSACTION INTERFACE OVERVIEW
Name of Interface : Inventory Transaction Interface
Table used : MTL_TRANSACTIONS_INTERFACE
The Inventory Transaction Interface can be used to process
Complete Transactions and therefore initiate Backflush
Transactions. This topic will be discussed in detail in the
Background Processing Section later.

11. PROCESSING MODES ONLINE AND BACKGROUND

PROCESSING :
Now that the different methods of initiating Backflush
transactions have been discussed, we need to consider the
different processing modes. There are two main processing
modes :

Online Processing

Background Processing

To enable Online or Background processing is dependent on

setting certain profile options. The following profiles can be
set to enable Online or Background Processing (please note :
some of these profiles also enable concurrent processing when you save a move transaction, a concurrent process to
process the material part of the move transaction is spawned
and control is returned to you immediately)
a. TP:INV Transaction processing mode (can override the rest of
the profile options)

11

b. TP:WIP Completion Material Processing (Form : Completion

Transactions Form. Controls processing mode for MATERIAL
transactions related to completion transactions from this form)
c. TP:WIP Completion Transactions Form (Form : Completion
Transactions Form. Controls processing mode for completion
transactions in this form)
d. TP:WIP Shop Floor Material Processing (Form :Move
Transactions Form. Controls processing mode for MATERIAL
transactions related to move transactions from this form)
e.TP:WIP Move Transactions Form (Form : Move Transactions
Form. Controls processing mode for Move transactions in this
form)
f. TP : WIP: Work Order-less Completion Form (Form : Work
Order-less Completions Form. Controls processing mode for
backflush transactions in this form)
11. 1 : ONLINE PROCESSING :
The following points need to be noted about online
processing :

When you save a completion transaction or move

transaction, it is processed while you wait and control is
returned once transaction processing is completed.

Serial controlled and lot + serial controlled components

can ONLY be processed in ONLINE mode.

If the lot selection method is manual, a lot controlled

component cannot be backflushed unless the processing
mode is online.

Online processing does not utilise the interfaces. The

transactions are processed as you wait.

11. 2 : BACKGROUND PROCESSING :

The following points need to be noted about background
processing :

When you save a move or completion transaction,

control is returned to you immediately. These
12

transactions are then processed on a periodic basis in

the background.

Background processing of Move and Complete

transactions utilizes the interfaces (open move
transaction interface and inventory transaction
interface).

If Move and Completion Transactions are performed

from the Move Transactions Window and the processing
mode is Background the
WIP_MOVE_TRANSACTION_INTERFACE (also called open
move transaction interface) is used to periodically
process the transactions. The records are inserted into
this interface and then processed by a program which
picks up the records from the interface (see the section
below)

If Completion Transactions are performed from the

Completion Transactions Window and the processing
mode is Background the
MTL_TRANSACTIONS_INTERFACE (also called inventory
transaction interface) is used to periodically process
the transactions. The records are inserted into this
interface and then processed by a program which picks
up the records from the interface (see the section
below).

If Completion Transactions are performed from the Work

Order-less Completions Window and the processing
mode is Background the
MTL_TRANSACTIONS_INTERFACE is used to periodically
process the transactions. The records are inserted into
this interface and then processed by a program which
picks up the records from the interface (see the section
below)

The MTL_TRANSACTIONS_INTERFACE and

WIP_MOVE_TRANSACTION_INTERFACE are also
populated directly (i.e not just from the forms). In this
case, scripts are used to populate the interfaces or the
interfaces are populated automatically from other
systems. Whenever an interface is used to process a
transaction, the processing mode is automatically
background irrespective of any of the settings of the
profile options above. This means that the transaction
will be processed periodically by the use of a program
(transaction worker or manager). Therefore, it is
13

important to ensure that all criteria required for

background processing are met see next two points).

Serial controlled and lot + serial controlled components

cannot be backflushed using background processing. An
error will occur which will be discussed in the issues
section below.

If the lot selection method is manual, a lot controlled

component cannot be backflushed in background mode.

11.3 : BACKGROUND PROCESSING : OPEN MOVE

TRANSACTION INTERFACE
Name of Interface : Open Move Transaction Interface
Table used : WIP_MOVE_TXN_INTERFACE
This interface is used in the following ways :

Populated directly to process move and complete

transactions. It is populated using scripts or populated
from other systems.

Move transaction records are automatically inserted into

the Open Move transaction Interface when receipts that
involve PO Move resources are entered in Oracle
Purchasing.

Populated when Move and Complete transactions are

initiated by the Move Transaction Form AND the
transaction processing mode is Background (due to the
settings of the profile options)

The WIP_MOVE_TXN_INTERFACE is the Open Move Interface

table (or Wip Move Transaction interface or WMTI). It contains
information about the shop floor Move transactions that need
to be processed. Each row contains the transaction date, the
job or repetitive schedule in which you are moving assemblies,
the primary unit of measure, the actual unit of measure,
transaction quantities, the foreign keys necessary for WIP to
process the Move transaction as well as information about the
From and To operation sequence numbers, operation codes,
and intraoperation steps. This table supports all shop floor
Move transactions including transactions loaded from other
systems, such as bar code readers, factory floor machines (e.g
14

cell controllers) and other manufacturing execution and quality

control systems.
The following concurrent program processes the records in the
WIP_MOVE_TXN_INTERFACE table :
Also known as : Wip Move Transaction Manager
Internal Name : WICTMS
The Open Move Transaction Interface allows you to perform the
following types of transaction :

Move assemblies between operations and intraoperation

steps (Transaction Type = 1 : Move. This is the value of
the Transaction_type field in the
WIP_MOVE_TXN_INTERFACE table to designate the type
of transaction )

Move assemblies from an operation and complete them

into inventory with a single transaction (Transaction
Type = 2 : Move and Complete)

Overcomplete a quantity greater then the job or

schedule if over-completions are available.

Scrap assemblies

Return assemblies. (Transaction Type = 3 : Return)

The following diagram explains the functionality of the Open

Move Transaction Interface :

15

Some points to note from the above diagram :

The wip move transaction manager, during the

backflush setup stage, inserts records for backflush
components into the MTTT
(MTL_MATERIAL_TRANSACTIONS_TEMP ) table after
validations have passed successfully. This is the Pending
Transactions table for material transactions. The MMTT
table is the gateway for all inventory transactions.

Data for completion transactions is also stored in the

MMTT table
16

Successfully processed material transactions for

backflush components and for completed assemblies
are held in the MMT (MTL_MATERIAL_TRANSACTIONS)
table. This is the parent table for MMTT. Transactions
are processed into the MMT table from the MMTT table
by the transaction processor which updates all the other
relevant tables also.

Successfully processed Move Transactions are stored in

the WIP_MOVE_TRANSACTIONS table.

Costing data for the resource, move transaction and

overheads is moved to the WIP_COST_TXN_INTERFACE
table ready to be processed by the Cost Manager.

Any processing errors for the Open Move Transaction

Interface are held in WIP_TXN_INTERFACE_ERRORS.

The column PROCESS_PHASE in WIP_MOVE_TXN_INTERFACE

describes the current processing phase of the transaction. The
Move Transaction Worker processes each transaction row
through the following three phases. You should always load 1
(Move Validation). The options are:

Move Validation (process phase 1) : The Move worker

validates the records with a process phase of 1 and a
process status of 1 or 2 (Pending/Running). Failed
records will error and process phase will remain at 1.
Validated records will be set to process phase of 2
(move processing).

Move Processing : The Move worker picks up the records

with a process phase of 2 and a process status of 1 or 2
(Pending/Running). Failed records will error and process
phase will remain at 2. Successful records are set to
process phase of 3 (backflush setup) and are moved to
the WIP_MOVE_TRANSACTIONS table because the move
transaction itself is processed.

Operation Backflush Setup : The Move worker picks up

the records with a process phase of 3 and a process
status of 1 or 2 (Pending/Running). If processing is
successful, the corresponding record is deleted from the
17

WIP_MOVE_TXN_INTERFACE. If the record fails, the

status will be set to error and the process phase will
remain at 3. If there is a failure in the Backflush setup
phase, there will be a record in error in
WIP_MOVE_TXN_INTERFACE and a corresponding record
in WIP_MOVE_TRANSACTIONS.
Reasons Backflush setup phase could error:
1. Backflush is trying to drive inventory negative, but
negative balances are not allowed
2. There are lot-controlled components, but lot selection
method is manual.
3. Lot selection method is not manual, but the lot
couldn't be derived because of insufficient lot quantity.
4. There are serial controlled components to be
backflushed and serial numbers cannot be assigned.
The column PROCESS_STATUS contains the state of the
transaction. You
should always load 1 (Pending):

Pending

Running

Error

So when is backflushing initiated? When the Move Transaction

Manager processes the following records from the
WIP_MOVE_TXN_INTERFACE table, backflushing is initiated :

The
processed
move
transaction
in
WIP_MOVE_TXN_INTERFACE completes the assemblies
at an operation by moving assemblies from the Queue
or Run intraoperation step of an operation to the To
Move, Scrap or Reject intraoperation steps of the same
operation or a subsequent operation. This will then
trigger the backflush of the Operation Pull components
defined for the Operation.

When an assembly is completed into inventory for a

completion transaction. This will trigger the backflush of
the Assembly Pull components for the assembly.

11.4 : BACKGROUND PROCESSING : INVENTORY

TRANSACTION INTERFACE
18

Name of Interface : Inventory Transaction Interface

Table used : MTL_TRANSACTIONS_INTERFACE (MTI)

The Inventory Transaction Interface can be used to process

Complete Transactions and therefore initiate Backflush
Transactions. This interface is used in the following ways :

Populated directly to process completion transactions. It

is populated using scripts or populated from other
systems.

Populated when Completion transactions are initiated by

the Completion Transactions Form AND the transaction
processing mode is Background (due to the settings of
the profile options)

Populated when Completion transactions are initiated by

the Work Order-less Completions Form AND the
transaction processing mode is Background (due to the
settings of the profile options)

The appropriate transactions are loaded into the MTI table

from various sources or by using loading scripts. These are
then processed by a concurrent program.
The program which processes the transactions from the
interface table is called the Inventory Transaction Worker.
The internal name of the program : INCTCW.
The Inventory Transaction Interface processes several
transaction types. The type which initiates the backflush of
components is :

WIP completion transactions : these update the job or

repetitive schedule completed quantities, launch
appropriate backflush transactions, and relieve costs of
completed assembly from the job/schedule

The above transaction completes assemblies into inventory.

This therefore initiates the Assembly Pull backflush.
Components with a supply type of Assembly Pull will be
backflushed.
19

The transaction type (transaction_type_id column in MTI

table) for wip assembly completion is 44.

12. BACKFLUSHING PROCESSING

Backflush transactions 'pull' components with Operation Pull
and Assembly Pull supply types from inventory onto jobs and
repetitive schedules. There are two types of Backflush
Transaction :

Operation Pull Backflush Transactions

Assembly Pull Backflush Transactions

12.1 : OPERATION PULL BACKFLUSH TRANSACTIONS

If there are Operation Pull components at the operation AND
the operation is defined as a backflush operation,
the
components are automatically pulled (backflushed) from
inventory.
Any components for non-backflush operations between the
current operation and the last completed backflush operation
are also pulled. Components for non-backflush operations are
only pulled at the appropriate backflush operation. The last
operation in the routing should always be defined as a
backflush operation to ensure that all Operation Pull
components are backflushed by the end of the routing.
If you have the TP:WIP:Move Transaction profile option set to
Online processing, you cannot move more assemblies than
exist in an operation step. If this option is set to Background
processing, however, you can move any number of
assemblies, but the quantity is validated in the background.
The system automatically backflushes pull components NOT
under lot or serial number control or lot+serial control.
Pull components under lot control can also be automatically
backflushed if the Work in Process parameter Lot Selection
20

Method is set to one of the automatic methods, and there is

sufficient inventory.
12.2: ASSEMBLY PULL BACKFLUSH TRANSACTIONS :
When you complete an assembly that has Assembly Pull
components, these
components are automatically pulled (backflushed) from their
assigned supply
subinventories/locators. If no supply
subinventory/locator is assigned to the component, the
system pulls components from the default supply
subinventory/locator specified by the WIP Supply Subinventory
and Supply Locator Parameters.
If the components being backflushed are under manual lot
control, serial control, or lot and serial control, you must enter
lot and/or serial numbers. If the job is tied to one or more
sales orders, the system automatically completes the
assembly for those orders.
Note: Purchasing transactions initiate backflushes only if they
are tied
to outside processing resources with an autocharge type of PO
Move
and only if requirements with a supply type of Operation Pull
exist at the outside processing operation.
12. 3 : BACKFLUSH TRANSACTION RULES
The following rules are enforced when performing backflush
transactions:

An enabled default supply subinventory must be

defined for the component. Also, a locator must be
defined if required by the subinventory. These will be
used to supply the backflush components. Supply
subinventories and locators can be defined at the
item or bill of material component level. If they are
not defined, the system uses the supply subinventory
and locator specified by the WIP Backflush Supply
Subinventory
and
Locator
Parameters
when
components are backflushed.

Routing references must be specified for nonstandard discrete jobs. On the Discrete Job>Routing
tab, select the routing Reference when defining a
non-standard job. Routing references can be used to
create
routings
(operations
and
resource
requirements) for non-standard discrete jobs, but are
not required. You can optionally define non-standard
jobs without routings, then customize them by
21

adding only those operations that are required.

However, the routing reference must exist for
backflush transactions to occur.

The component item must be defined as

transactable. This refers to the inventory item
parameter.

The Subinventory you you are backflushing from

must be an asset subinventory if the Allow Expense
to Asset Transfer profile option is set to No.

Backflush quantities in decimal values must be no

more than five decimal places in order to create the
backflush transaction.

Yield calculations are based on exact requirements,

rather than rounded values.

For component items under revision control, the

system always defaults the revision based on the
items current revision as of the date of the
transaction. Backflushing will therefore always issue
the current revision of the component. To issue older
revisions of a component would require changing the
supply type to Push.

12. 4 : GENERAL POINTS FOR ALL BACKFLUSH

TRANSACTIONS :
Backflushing of components does NOT take place if :
1. The operation that assemblies are being completed at is not
a backflush operation
2. The components are under serial number control and the
processing mode is set to background.
3. The components are under lot control and the lot cannot be
derived whilst the processing mode is set to background.
4. The components are lot controlled and the Work in Process
parameter Lot Selection Method is set to Manual whilst the
processing mode is background.
5. There is insufficient inventory in the supply subinventory
12.5 : LOT AND SERIAL NUMBER BACKFLUSHING :
22

Assembly and Operation Pull components under lot, serial, or

lot and serial number control can be backflushed using the
backflush window. The Backflush window provides efficient
entry for large numbers of lot and serial controlled items when
creating assembly move transactionsincluding scrap, reject,
and assembly completion. Work in Process parameters
determine how lot numbers are assigned and verified during
backflush transactions.

The Backflush Window appears when you perform a move,

scrap, reject, or assembly completion. The Backflush window
automatically appears only if you are backflushing lot or serial
controlled pull components.
It is possible to
reverse backflush transactions and
automatically return backflushed components back to
inventory. For example, pull components that are backflushed
as you move assemblies to the next intraoperation step in a
routing are automatically returned to inventory if you move
assemblies to a previous step in the routing. These are simply
the opposite of backflush transactions.
12.6 : COUNT POINT AND AUTOCHARGE OPERATIONS :
When you define operations in Oracle Bills of Material, you can
specify whether an operation is a count point and whether
resources at that operation should be automatically charged
during a move transaction. You can update this information in
Work in Process using the Operations window. Operations that
are non-count point/autocharge operations must be defined as
backflush operations. If you issue components with a supply
23

type of Operation pull to an assembly at a Count Point off /

Autocharge off count point operation, Work in Process
backflushes these components when you move out of the
Count Point off / Autocharge off count point operation into a
count point operation that allows backflushing. Work in
Process never pulls components with a supply type of
Assembly pull from Count Point off/ Autocharge off count point
operations. However, you must turn Backflush on for Count
Point off / Autocharge off count point operations. The
Backflush field should always be turned on for the last
operation in a routing.

12.7 : NEGATIVE REQUIREMENT BACKFLUSHING :

When Operation Pull components that have negative
requirement quantities are backflushed, they are returned to
inventory (i.e they are NOT supplied from inventory as for a
normal backflush).
12.8 : REPETITIVE PRODUCTION LINE BACKFLUSHING :
For repetitive manufacturing, all backflush assemblies are
automatically allocated to the correct repetitive schedule
using a FIFO algorithm. The algorithm is based on a first unit
start date, and on the assemblies moved or completed in the
transaction that initiated the backflush.
12.9 : CHARGING OF RESOURCES
If there are WIP Move resources at the operation that is being
completed, the system automatically charges these resources
at their standard rate.
If there are Manual resources at the operation that is being
completed, the system notifies you that Manual resources
exist at the operation so that you can manually charge them.
13. HOW DO YOU VIEW BACKFLUSH TRANSACTIONS?
The purpose of this section is to understand how to view
backflush transactions using the applications and also to
recognize which tables the transactions are stored in.
Backflush transactions from all sources can be seen from the
View Material Transactions form.

The backflush transactions are held in the MMT table.

24

Move
transactions
are
held
in
the
WIP_MOVE_TRANSACTIONS table.
Completion transactions are held in the MMT table.

The following sequence of screenshots clarifies how to view

backflush transactions :
a. Before we view the material transactions, lets have a look
at the BOM that we will use in the examples. The next
screen shows a BOM and shows that the components have
a supply type of Operation Pull.

b. The next 2 screens shows the screen shots of 2 move

transactions for the assembly. They are taken from
WIP>Move Transactions>View Move Transactions. The
purpose of the second screen is to highlight the move
transaction ids. It is important to note the following :

There is one move transaction for : From Op 20

Queue> To Op 20 To Move. This completes the
assemblies at this operation and will result in the
backflush of components of operation pull at this
operation (components pc and pb)
There is one move transaction for : From Op 10
Queue> To Op 20 Queue. This assumes that
operation 10 has been completed. Therefore any
operation pull components at operation 10 will be
backflushed. (component re)
25

c. The navigation for the form shown below is WIP>Material

Transactions>View Material Transactions.
The search
criteria used were transaction type (wip component issue)
and job name. It shows the backflush of the components
26

initiated by the Move Transaction in b) above. The following

screens will highlight this in more detail. They are from the
same form.

d. The next screenshot is from the same form, showing the

reason,reference tab. The key thing to note is that the
source code of WIP Backflush indicates that the
transaction was a backflush transaction. The quantity
backflushed is also shown. The last column is the
TRANSACTION_ID which will be used later to query the
MTL_MATERIAL_TRANSACTIONS table.

27

e. The tab below shows the originating Move Transaction Id

for the move transaction which resulted in the backflush of
the components. If the backflush was origininated by a
completion transaction, that would be shown in Completion
transaction Id. Note that the two move transactions in
step b) are both shown compare the move transaction id
with that in step b.

28

So how would we query the transactions above ?

f.

To query the move transactions :

Select
*
from
WIP_MOVE_TRANSACTIONS
transaction_id in (17701293, 17701294)

where

g. To query the backflush transactions :

We can use the following :
Select * from MTL_MATERIAL_TRANSACTIONS
transaction_id in (14714658)

where

Select * from MTL_MATERIAL_TRANSACTIONS

move_transaction_id in (17701293, 17701294)

where

Select * from MTL_MATERIAL_TRANSACTIONS

SOURCE_CODE = WIP Backflush

where

14. HOW HAS BACKFLUSH FUNCTIONALITY CHANGED

OVER DIFFERENT APPLICATION RELEASES?
The important thing to note is that Backflush functionality has
NOT changed in release 12.
In fact, the Backflush functionality only changed in release
11.5.10.
We will now look at the functionality prior to 11.5.10 and how
it changed in 11.5.10.
11.5.9 Behaviour :
The way in which backflush transactions are processed from
the Open Move Transaction Interface (also known as Wip
Move Transaction Interface or WMTI) and the Inventory
Transaction Interface (also known as Material Transaction
Interface or MTI) is where the behaviour was slightly different
in 11.5.9.
1. Wip Move Transaction Interface (WMTI): move and complete
through WMTI :
a. Once the record is populated in WMTI for move and
complete, the move worker would process this transaction.
b. Completion transactions are processed first and then the
29

backflush transactions (PULL components)

c. If completion is successful, the job is completed.
d. If backflush fails for any reason, the backflush components
will remain in MMTT (pending material transaction form) with
error. The completion transaction has already gone through
successfully by this time.
2. MTI: completion through the Material Transaction Interface
or MTI :
a. Once the record is populated in MTI for completion, the
inventory transaction worker will process this transaction.
b. Completion transaction will be processed first and then
backflush transactions (ASSEMBLY PULL components).
c. If completion is successful, the job is completed.
d. If backflush fails for any reason, the backflush will remain
in MMTT (pending material transaction form) with error. The
completion transaction has already gone through successfully
by this time.
11.5.10 Behaviour :
The way in which backflush transactions are processed from
the two open interfaces changed slightly in release 11.5.10
onwards. The functionality was changed in TWO steps :
Step 1 : Base 11.5.10 Behaviour
WMTI and MTI:
For both the interfaces, if backflush failed for any reason, the
completion was also prevented.
Step 2: Current 11.5.10 Behaviour
Customers complained about the initial 11.5.10 behaviour.
Their concern was that the functionality stopped jobs from
being completed and prevented goods leaving the factory.
A patch was introduced to change this behaviour. The patch
was 4504810. The behaviour now is :
1. WMTI:
a. Once the record is populated in WMTI for move and
complete, the move
worker will process this transaction.
b. The completion transaction will be processed first and then
the backflush transactions (PULL components).
c. If completion is successful, the job is completed.
d. If backflush fails for any reason, WMTI record is updated to
30

process phase
"Backflush setup" and status="error". It will also populate the
reason why
the backflush failed.
e. The user then needs to resubmit the WMTI record after
correcting the error.
Advantantages of this functionality :

The 11.5.9 functionality caused a lot of data corruption

errors in MMTT because the data was not validated
before loading the data in MMTT.
The current functionality validates the data and
explains the errors in the WMTI table. The functionality
forces you to correct the data before the data hits the
MMTT table.
These errors can then be corrected and the transaction
can be resubmitted.

2. MTI:
The behaviour of MTI is exactly same as in base 11.5.10 i.e,
the completion fails if the backflush fails.
Important 11.5.10 patches :
There were some issues around backflush functionality after
patch 4504810 was introduced. These were resolved by
applying patch 5038886. One of the key issues resolved by
this patch was as follows :
If backflush component fails inventory validation, only the
move records
corresponding to those backflush components will fail. The
other move
records will go through.
15. COMMON BACKFLUSH ISSUES AND HOW TO
CORRECT THEM :
This section examines some of the common errors around
backflush transactions and how to correct them. It should be
noted that this section ONLY looks at issues which are related
to Backflush transactions. It does not look at all causes of
Pending Move or complete transactions. There are documents
which already cover these topics
1. Processing serial control or lot control backflush
31

components in background mode :

How is the issue seen?

Go to the Pending Move Transactions form. There

will be a Pending Move Transaction that will be in
error
The transaction in WIP_MOVE_TXN_INTERFACE will
be in error in the Backflush Setup Phase (process
phase 3).
There will be record in WIP_MOVE_TRANSACTIONS
for this record because the move transaction will
have been processed.
The error will be as below.

Error : An Assembly transaction cannot be processed in

background mode if it has backflush components that are
serial or lot controlled where the Lot cannot be derived.
Cause : If backflush components are under serial control or
under lot but WIP cannot derive lot for some reason, the
system will throw an error "An Assembly transaction cannot be
processed in background mode if it has backflush components
that are serial or lot controlled where the Lot cannot be
derived." This is an unsupported feature, and customers
should not try to backflush serial control component in the
background mode.
Solution : The solution is as follows :

If the lot selection wip parameter was set to manual

and the item is lot controlled then this transaction
cannot be processed in background mode. Change the
lot selection wip parameter to an appropriate value
other then manual (after confirming this is not a
business need) and then resubmit the transaction from
the Pending Transaction Form :
WIP > Move Transactions > Pending Move Transactions
Select the transaction and then choose the resubmit
option.

If you need to use serial numbers or manual lot

derivation, then the following solution will need to be
used :
1. Delete the transaction from the Pending Transaction
table. This is done as follows :
32

WIP > Move Transactions > Pending Move Transactions

Through the Pending Move Transactions window you
can view, update, delete, and resubmit Move
transaction records that have failed validation and
remain in the Open Move Transaction Interface table
(WIP_MOVE_TXN_INTERFACE).
If the transaction cannot be deleted from the forms,
then use the script below with great caution and after
careful validation :
delete from WIP_MOVE_TXN_INTERFACE
where TRANSACTION_ID = &erred_transaction;
2. Now you need to perform the transaction ONLINE.
This kind of transaction must NOT be transacted in
background mode (where you need to enter serial
number or where lot numbers are manually entered). To
perform the transaction online, do as follows :
1. Change the profile TP:WIP Move Transactions Form to
ONLINE
2. Go to WIP>Move Transactions>Move Transactions.
Process the transaction online.
2. XXXXX: Quantity must be less than or equal to
Available to transact (where xxxx is item number).
How is the issue seen?

The error message is seen in the Completion

Transaction Form if the processing mode is
ONLINE. In this case, both the completion
transaction and the backflush transaction fail.
If the processing mode is BACKGROUND, the issue
is seen via a pending transaction in the interface
(WIP_MOVE_TXN_INTERFACE
or
MATERIAL_TRANSACTION_INTERFACE).
In
this
case, the completion transaction completes and
the backflush transaction fails.

Error : XXXXX: Quantity must be less than or equal to

Available to transact (where xxxx is item number).
Cause :

This is as a result of a valid inventory validation.

33

There is not enough stock to allow the transaction to process.

Solution : The solution is as follows :

Ensure that there is enough stock to allow the

transaction to proceed.
If the processing mode is online, re-enter the
transaction from forms.
If the processing mode is background, then resubmit
the transaction from the Pending Transactions window
after the quantity issue has been resolved.

3. Backflush Transactions are performed even though

the Profile: Inv: Override Negative for Backflush is set
to NO :
How is the issue seen?

The inventory is driven

backflush components.

negative

for

some

Error : No error message the issue is seen by noticing that

the inventory for some backflush components is negative.
Cause :
The inventory organization is flagged to allow
negative balances. This overrides the profile : Inv: Override
Negative for Backflush .
Solution :
Set the inventory organization to not allow
negative balances.
4. Lots are not being consumed based on FIFO (lot
expiration)
How is the issue seen?

To see the consumed lots, go to

Hand Qty> Wip Subinventory

Inventory> On

Error : Notice that the system does not consume lots based
on lot expiration.
Cause : The standard functionality does not support FIFO
backflush based on expiration dates.
Solution : None. The standard functionality does not support
FIFO backflush based on expiration dates.
34

5. Transaction Quantity cannot be zero

How is the issue seen?

This issue is ONLY seen in releases BELOW 11.5.10

A backflush record with zero primary and
transaction quantity is errored in MMTT.
(MTL_MATERIAL_TRANSACTIONS_TEMP)

Error : The record has the error : Transaction Quantity

cannot be zero.
Cause : Prior to release 11.5.10, backflush transactions were
not validated. This often led to corruption in the MMTT table.
Therefore, sometimes, transactions with zero quantities were
not validated and then got stuck in MMTT.
Solution :
a. Ensure that enough quantity is available in a lot in the
supply subinventory.
b. Log a bug with the Inventory Development team to provide
a datafix. The datafix will likely do the following :
Update the transaction quantity and primary quantity in the
stuck MMTT record with the correct quantity to be
backflushed.
Insert records in MTL_TRANSACTION_LOTS_TEMPS to match
the transaction quantity.
Caution : Do not attempt to update the tables or delete
records from tables without a detailed analysis by
Development.
6. APP-25105 : Failed Backflush Transactions
How is the issue seen?

Go to Wip Move Transactions form.

Perform a completion transaction.
The transaction fails with an APP-25105 error.

Error : APP-25105 : Failed backflush transaction exists for

TRANSACTION_HEADER_ID (xxxxx)
35

Cause : The item was inactivated and could not transacted.

Solution : Change the item status to an active status.
7. APP-25105 : Quantity required to complete this
transaction is no longer available.
How is the issue seen?

A completion transaction is stuck in the MMTT

table. (MTL_MATERIAL_TRANSACTIONS_TEMP).
The error could manifest in different ways for
this instance, the completion transaction and any
associated backflush transactions will not be able
to be completed.
The error is as follows :

Error : APP-25105 : Quantity required to complete this

transaction is no longer available.
Cause : One cause of the issue could be as follows :
The component backflush was already completed at an earlier
date/time. When the pending transaction was re-processed,
the material was no longer available. There are various other
causes however. Each needs to be examined as a separate
case.
Solution : The solution is as follows:
a. Check whether the record in MMTT is a backflush or a
assembly related transaction (i.e completion transaction).
b. If the stuck record in MMTT is a backflush, you need to
check whether the parent transaction is in MMT or not.
c. If the stuck records in MMTT is an assembly related
transaction, then you need to make sure no backflush
records are in MMT.
d. Then you need to log a bug against the INV Product
because the records are stuck in MMTT which is an INV
table. You will need to provide all the above details (steps a
to c).
8. Intermittent Wip Move Errors at Backflush Setup
stage
How is the issue seen?
36

When this WIP Backflush error occurs, the discrete job

remains in Released Status at the last operation step
and no material is issued to it. There is also an
Inventory Pending transaction for the WIP Completion
that gets stuck in the interface with status Pending.

Error : The WIP work order associated with this transaction

is currently locked and being updated by another user. Please
wait for a few seconds and try again. Transaction processor
error
Cause : Possible file corruption
Solution :
1. Identify who locked the WIP or INV table using the query
below :
select
ORACLE_USERNAME,OS_USER_NAME,OBJECT_NAME,locked_mo
de,session_id,c.serial#
from all_objects a ,sys.V_$LOCKED_OBJECT b,v$session c
where a.OBJECT_ID=b.object_id
and
c.sid=session_id;
2. Inform the user who locked the tables to save their pending
transaction or close the form if they don't plan to save.
3. The final solution to this may require the form to be
regenerated after the above is done :
Using Adadmin utility
From Main Menu, select Maintain Application Files
Enter 6. Generate form files
Do you want to regenerate Oracle Forms PL/SQL library files
[Yes] ? Yes
Do you want to regenerate Oracle Forms menu files [Yes] ? Yes
Do you want to regenerate Oracle Forms executable files
[Yes] ? Yes
Enter list of products ('all' for all products) [all] : all
Generate specific forms objects for each selected product
[No] ? No
Make sure you enter the products in lowercase, in example
above, enter 'all'
not 'ALL'.
9. Records stuck in MMTT with BF_LOT_ERROR
How is the issue seen?
37

This issue is ONLY seen in release 11.5.9 and prior

releases. It is not seen in later releases.

Error :

BF_LOT_ERROR

Cause : Lot could not be derived during operation pull due to

insufficient onhand.
Solution :
Log a bug against WIP and provide the output of the script
wip_bf_lot_error.sql. This can be downloaded from the
Knowledge base.
10. Move Transaction related issues.
These are not covered in this paper. If there are Pending
Move transactions which are stuck , these will obviously
also prevent any associated backflush transactions. Please
refer to the following note to assist with these issues :
WIP_MOVE_TXN_INTERFACE Common Errors In Pending
Move Transactions With Possible Causes And Action Plan
To Process Them (Doc ID 457066.1)

38