Back Flush

Oracle Work in Process – Backflush Processing

An Oracle White PaperJanuary 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

2. WHAT IS BACKFLUSHING?

In the Bills of Material module, when a bill is created for any assembly, sub-assembly or a finished good, the component supply type for each component in the bill has to be defined. These supply types are push, operation pull, assembly pull, Bulk, Supplier and phantom. This Bills of material is used in Work in Process module for manufacturing the assembly/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 .

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, Inventory Transactions Interface can also create backflush transactions.

Each of the above six processes will be discussed in detail.

It is possible to reverse backflush transactions and automatically return backflushed components back to inventory. For example, pull components that are backflushed as you move assemblies to the next intraoperation step in a routing are automatically returned to inventory if you move assemblies to a previous step in the routing or if you return completed assemblies back from inventory to the job.

We will now discuss the different processes that lead to backflush transactions.

4. PROCESS 1 : COMPLETE ASSEMBLIES AT OPERATION - MOVE TXN FORM

Navigation : Work in Process>Move Transactions>Move Transactions

Form Name : WIPTXSFM

When move transactions are performed from the Move Transaction Form to COMPLETE assemblies at an operation, 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 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

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 over-completions 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 allowed2. 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, thesecomponents 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 supplysubinventory/locator specified by the WIP Supply Subinventoryand 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 tiedto outside processing resources with an autocharge type of PO Moveand 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 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 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

29

(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 before the data hits the MMTT table.

These errors can then be corrected and the transaction can be 30

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 recordscorresponding to those backflush components will fail. The other moverecords 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.

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

31

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

32

Process the transaction online.

2. XXXXX: Quantity must be less than or equal to Available to transact (where xxxx is item number).


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 :


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 .

33

Solution : Set the inventory organization to not allow negative balances.

4. Lots are not being consumed based on FIFO (lot expiration)


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.

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

5. Transaction Quantity cannot be zero


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.

34

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


Go to Wip Move Transactions form. Perform a completion transaction. The transaction fails with an APP-25105 error.

Error : APP-25105 : Failed backflush transaction exists for TRANSACTION_HEADER_ID (xxxxx)

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.


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

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


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_id,c.serial#from all_objects a ,sys.V_$LOCKED_OBJECT b,v$session cwhere a.OBJECT_ID=b.object_idand 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 utilityFrom Main Menu, select Maintain Application FilesEnter 6. Generate form files

36

Do you want to regenerate Oracle Forms PL/SQL library files [Yes] ? YesDo you want to regenerate Oracle Forms menu files [Yes] ? YesDo you want to regenerate Oracle Forms executable files [Yes] ? YesEnter list of products ('all' for all products) [all] : allGenerate 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


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

37

https://support.us.oracle.com/oip/faces/secure/km/DownloadAttachment.jspx?attachid=737442.1:WIPBFLOTERROR

January 2011Author: Zar Ahmed

Oracle CorporationWorld Headquarters500 Oracle ParkwayRedwood Shores, CA 94065U.S.A.

Worldwide Inquiries: Phone: +1.650.506.7000Fax: +1.650.506.7200 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 CorporationAll rights reserved.

38

Back Flush

Documents

Transcript of Back Flush