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, subassembly 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 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,
Transactions Interface can also create backflush transactions.
Inventory
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, 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.
2
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 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
3
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.
4
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’
6
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
7
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 Move, Scrap or Reject
intraoperation steps of the same operation or a subsequent
operation.
8


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
9
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 orderless 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
Table used : WIP_MOVE_TXN_INTERFACE
10
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)
c. TP:WIP Completion Transactions Form (Form : Completion Transactions
Form. Controls processing mode for completion transactions in this form)
11
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 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
12
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.

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 :
13

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
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 overcompletions are available.
14

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 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
17
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
Table used : MTL_TRANSACTIONS_INTERFACE (MTI)
18
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.
19
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.
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.
20
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
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.
21

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 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.
22
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 / 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.
23
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 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’.
24
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 initiated by the Move Transaction in b)
above. The following screens will highlight this in more detail. They are
26
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.
So how would we query the transactions above ?
f. To query the move transactions :
Select * from WIP_MOVE_TRANSACTIONS where transaction_id in
(17701293, 17701294)
g. To query the backflush transactions :
We can use the following :
Select * from MTL_MATERIAL_TRANSACTIONS where transaction_id in
(14714658)
28
Select
*
from
MTL_MATERIAL_TRANSACTIONS
move_transaction_id in (17701293, 17701294)
where
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 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.
29
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 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
30

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 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.
31
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 :
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 :
32
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. 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.
33
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
Wip Subinventory
Inventory> On Hand Qty>
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.
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.
34
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
TRANSACTION_HEADER_ID (xxxxx)
backflush
transaction
exists
for
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 :
35
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?

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_mode,session_i
d,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;
36
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?

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)
37