Oracle Work in

Process – Backflush
Processing

An Oracle White Paper

January 2011
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

1. 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/sub-
assembly/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 .

2. 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 inventory using the

Completion Transactions window

4. 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

2
Transaction Form to COMPLETE assemblies at an operation,
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:

2
 • Moving assemblies between the To Move, Scrap, and
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.

1
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).
1
 • 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’

3
 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

3
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
1
 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

2
 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

Name of Interface : Open Move Transaction Interface

2
 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)

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

Transactions Form. Controls processing mode for MATERIAL
transactions related to completion transactions from this form)
3
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
transactions are then processed on a periodic basis in
the ‘background’.

• Background processing of Move and Complete

transactions utilizes the interfaces (open move

3
 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
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.
2
 • 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
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

2
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 :

3
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

3
 • 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
WIP_MOVE_TXN_INTERFACE. If the record fails, the
1
 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

Name of Interface : Inventory Transaction Interface

2
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.

The transaction type (transaction_type_id column in MTI

table) for wip assembly completion is 44.
2
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
Method’ is set to one of the automatic methods, and there is
sufficient inventory.

3
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 non-

standard 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
adding only those operations that are required.
However, the routing reference must exist for
3
 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
item’s 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 :

Assembly and Operation Pull components under lot, serial, or

2
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 transactions—including 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
type of Operation pull to an assembly at a Count Point off /
2
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.

• Move transactions are held in the
2
 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, let’s 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)

2
a. 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
3
 initiated by the Move Transaction in b) above. The
following screens will highlight this in more detail. They are
from the same form.

b. 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.

2
c. 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.

1
So how would we query the transactions above ?

d. To query the move transactions :

Select * from WIP_MOVE_TRANSACTIONS where

transaction_id in (17701293, 17701294)

e. To query the backflush transactions :

We can use the following :

Select * from MTL_MATERIAL_TRANSACTIONS where

transaction_id in (14714658)

Select * from MTL_MATERIAL_TRANSACTIONS where

move_transaction_id in (17701293, 17701294)

Select * from MTL_MATERIAL_TRANSACTIONS where

SOURCE_CODE = ‘WIP Backflush’

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

3
complete, the move worker would process this transaction.
b. Completion transactions are 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, 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
2
 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
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
2
which already cover these topics

1. Processing serial control or lot control backflush

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 :
2
 1. Delete the transaction from the Pending Transaction
table. This is done as follows :

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

2
Available to transact (where xxxx is item number).

Cause : This is as a result of a valid inventory validation.

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 negative for some

backflush components.

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 Inventory> On

Hand Qty> Wip Subinventory

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.

2
Solution : None. The standard functionality does not support
FIFO backflush based on expiration dates.

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.

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

Error : APP-25105 : Failed backflush transaction exists for

TRANSACTION_HEADER_ID (xxxxx)

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).

1
8. Intermittent Wip Move Errors at Backflush Setup
stage

How is the issue seen?

• 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_m
ode,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

3
 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?

• 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)

Backflush Processing
January 2011
Author: Zar Ahmed

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
1
www.oracle.com

Oracle is a registered trademark of Oracle Corporation. Various

product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.

Copyright © 2003 Oracle Corporation

All rights reserved.