Professional Documents
Culture Documents
An Overview
An Oracle White Paper
June 2003
Objective:............................................................................................................ 3
Introduction: ...................................................................................................... 3
Business Needs .................................................................................................. 3
Kanban Supply Status....................................................................................... 4
Kanban Source Types....................................................................................... 5
a) Production: ................................................................................................ 5
b) Intra Org:................................................................................................... 5
c) Inter Org:................................................................................................... 6
d) Supplier...................................................................................................... 6
Setup Required:.................................................................................................. 7
Kanban Planned Items - Setup ................................................................... 7
Kanban Card Definition .............................................................................. 7
Kanban Pull Sequences - Setup .................................................................. 8
Kanban Card Sizing .......................................................................................... 9
Calculation Formula ................................................................................... 10
How the Program Determines Average Daily Demand ....................... 11
Kanban Card Printing ................................................................................ 13
Technical Overview: ....................................................................................... 14
Tables used: ................................................................................................. 14
Packages used: ............................................................................................. 14
References: ....................................................................................................... 18
About the Author:........................................................................................... 18
Page 2
OBJECTIVE:
INTRODUCTION:
Kanban in Japanese means sign or signal. This system is used in where the
items have a relatively stable demand and medium to high production volume.
Kanban Cards are used in a Pull based System. A pull based system is one where
inventory items for a particular part or assembly area are replenished as soon as
they are needed. When the items are needed, Kanban cards in Oracle Inventory
change their Supply Status to Empty, and Inventory generates the Kanban
replenishment request automatically.
Oracle Inventory allows you to define Kanban planned items and replenishment
chains based on sourcing information to support your continuous flow
manufacturing systems. You can define Kanban planned items, and create a
Kanban Pull Sequence for each Kanban item. You can specify different
replenishment sources for your Kanban locations. Kanban Cards are used to
replenish your Kanban items by triggering replenishment requests based on
sourcing information. You can print Kanban cards for a replenishment plan or a
pull sequence.
BUSINESS NEEDS
Page 3
Minimize stockouts
Achieve shorter lead times
Reduce inventory with minimal manual supervision
Kanban cards are generated with default Card Status of Active. When you define a
card manually, you can initially give it either Active or Hold status. If the Supply
Status is Full, you can temporarily pull a card out of the replenishment chain by
changing the Card Status to Hold. You can terminate use of a Kanban card by
changing the Card Status to Canceled, but you cannot reverse this change. Only
Canceled cards can be deleted.
All the Kanban Supply Status codes can be set manually only. Kanban is a manual
control system. However a Kanban API can be used to update the Supply status of
the Kanban Cards.
The Various valid statuses of Kanban Cards are:
1. New The Kanban has just been created and is not yet part of the replenishment
chain.
2. Empty The Kanban is empty and a replenishment signal has been generated.
4. Wait The Kanban is waiting until the minimum order quantity has been met by
the aggregation of cards.
5. In-Process for the Supplier source type, the purchase order has been approved.
For the Inter-organization source type, the internal requisition has been approved.
6. In-transit You have received an advanced shipment notice indicating that All
Kanban cards are generated with a Supply Status of New. You can change this
status to Empty to trigger a Kanban replenishment signal. During initial setup, you
can switch the status to Full if you are starting out with a full bin. When you are
defining a card manually, you can create it with a status of Empty, Full or New.
Page 4
The Kanban Source types identifies the type of replenishment that is required to
fulfill a material requirement planning that is generated by a Kanban.3
Production
Intra Org
Inter Org
Supplier
a) Production:
When the Kanban Pull Sequence Source Type is set to Production, after the
Kanban card is set to Empty, Kanban replenishment would launch a WIP Job
for "make" item. Records are inserted in the table
WIP_JOB_SCHEDULE_INTERFACE. This works for the Date Effective items
only.
On Selecting the Source type as Production, while defining the Source type, enter
the flow or discrete line that supplies to this location.
b) Intra Org:
When the Kanban Pull Sequence Source Type is set to Intra Org, i.e. The item is to
be transferred from a Subinventory within the Organization, the Kanban
replenishment would result in a Replenishment Move Order generation, which
would authorize the movement of the material within an Organization.
When the Source type is Intra Org, while defining the Source type, choose the
Source Inventory and the locator from where you want to replenish.
Page 5
c) Inter Org:
When the Kanban Pull Sequence Source Type is set to Inter Org, i.e. The item is to
be transferred from a different Organization, depending on the set up in shipping
network for the Organization, with shipment type of 'In transit' or Direct, the
Kanban replenishment would result in a Internal Requisition generated.
When the Source type is Inter Org, while defining the Source type, choose the
Organization from where you want to replenish.
The Requisition Import generates an internal requisition for the item with a status
of Approved. (If encumbrance/budgetary control is on, Purchasing sets the status
to Pre-Approved.)
Once Purchasing approves the standard purchase order, blanket release, or internal
requisition, Inventory automatically receives a status for the Kanban card of In
Process.
d) Supplier
When the Kanban Pull Sequence Source Type is set to Supplier, i.e. The item is to
be brought from a Supplier, when query and select a Kanban card and then
Replenish it, a row is inserted in to the
PO_REQUISITIONS_INTERFACE_ALL. And then Purchasing creates a
blanket release (if a blanket agreement exists) or a standard purchase order (if a
valid quotation exists) for the item.
This record is then converted in to a pre-Approved Requistion by running the Reqimport process.
Page 6
When the Source type is Supplier, while defining the Source type, choose the
Supplier code and the site you wish to procure the material from.
SETUP REQUIRED:
You can specify an item to be a Kanban planned item by setting the Release Time
Fence attribute in the MPS/MRP Planning Attribute Group to Kanban Item. Only
Kanban planned items can be used in defining a pull sequence.
You can create Kanban cards for an item, subinventory and locator. Oracle
Inventory allows you to generate Kanban cards automatically or manually. A
Page 7
Kanban number uniquely identifies each Kanban card. The Kanban numbers are
automatically generated for those cards that are generated from a Kanban pull
sequence. For manually defined cards, both replenishable and non-replenishable,
you can enter an unused Kanban number or let the system create the number.
Replenishable cards are used for Kanbans that cycle through the system from full
to empty, remaining active until they are withdrawn. Non-replenishable Kanban
cards are one-time signals that are primarily used to manage sudden spikes in
demand. Nonreplenishable cards do not have to be associated with a pull
sequence.
For every Kanban planned item, you must define a pull sequence, which is a series
of Kanban locations that model the replenishment network on the shop floor. A
Kanban location can be a subinventory or an inventory locator. The replenishment
source for a Kanban location can be another Kanban location, a production line,
another organization or an outside supplier. You have the option to use locators
even if the locator control is turned off at the organization, subinventory and item
levels.
Pull sequences cannot be used with model/unit effective number controlled item
since the Model/unit effective items are for project manufacturing environment
and pull sequences are for flow manufacturing kind of environment. Pull sequences
are not supposed to be used by items that are model/unit effective number
controlled (project manufacturing). Both functionalities are for different kind of
industry segments.
The following snapshot gives an example of a Pull Sequence for item KB15138:
Org: M1
SubInv. RIP
Org: M1
SubInv. Stores
Locator: 1.1.1..
Supplier Kanban
Supplier:
Advanced Network
Site:
SANTA CLARA
Page 8
Note:
The subinventory and locator on the first pull sequence in your replenishment
chain must equal the subinventory and locator on either the material control region
of all bills of material using this Kanban location or the WIP supply location on the
Organization Item Master. If these values do not match exactly, Kanban planning
for the item will fail.
Kanban Size is calculated when the line is designed, since the line is designed for
maximum rate, the Kanban size is also calculated accordingly. The Kanban Size
reflects the minimum amount of Inventory that is required to support the designed
daily rate of Production.
Page 9
You can choose what you want the program to calculate: Kanban size or Kanban
cards. The product of Kanban size and number of Kanban cards (or containers)
will satisfy the demand at capacity for the planning horizon.
Kanban size refers to the number of items in each Kanban container. Each Kanban
container has one Kanban card, so the number of Kanban cards is the same as the
number of Kanban for each item.
In the planning process, there are Order modifiers defined for each pull sequences:
Minimum Order Quantity This is defaulted from the item setup.
Lead-time This lead-time is the time required to replenish one Kanban from its
source.
Lot Multiplier Use this if you want to have lots in fixed Multiples.
Allocation Percentage This represents the distribution of an items demand across
multiple locations.
Safety Stock The number of days of safety stock you want to maintain.
If you specify the Kanban Size, the program will not consider the above Order
Modifiers to calculate the number of cards.
Calculation Formula
One of the most important tasks of a Kanban planning system is determining the
optimal number of Kanban cards. The Kanban planning software takes care of this
calculation provided you enter correct values for Kanban size, average daily
demand for the Kanban item, and the lead-time to replenish one Kanban.
Oracle provides a package that you can use to customize the calculation. See the
Oracle Manufacturing, Distribution, Sales and Service Open Interfaces Manual.
(C - 1) * S = D * A * (L + SSD)
where:
Page 10
In addition to this basic formula, when the calculation program calculates Kanban
size, it takes into account the values for the following order modifiers (specified in
the pull sequence), in the following order:
Note: The program uses order modifiers only when calculating the Kanban size. If
you specify the Kanban size and want the program to calculate the number of
Kanban cards, the program does not use order modifiers.
Before the Kanban calculation program can calculate the Kanban size or the
number of Kanban cards, it needs values for the other variables. It gets the values
of L and C or S from the pull sequence you define in Oracle Inventory. The
program calculates the average daily demand by following these steps:
It identifies all the Kanban items that you want to include in your Kanban
calculation; using the parameters you enter when you launch a Kanban calculation.
Page 11
It finds location information for each Kanban item. For each Kanban item, it
identifies every BOM in which the item appears so that it can explode the demand
from the assemblies down to the Kanban item.
Using the MDS, MPS, Actual Production, or forecast you specify in the Kanban
Names window - it identifies all the demand entries for each Kanban item for
which the demand is independent. For example, suppose that from the forecast you
specified in Kanban Names, the program finds independent demand for 600 of
Kanban item A. It uses the Allocation Percentage specified in the pull sequence for
each Kanban item to determine how to distribute demand for the item among its
different locations. For example, if the allocation percentage for item A at location
L1 is 20%, then the program places demand of 120 (that is, 20% of 600) at location
L1.
Using the MDS, MPS, Actual Production, or forecast you specify in the Kanban
Names window - it calculates demand for each Kanban item for which demand is
dependent on the demand for other items. It does so by using the following
information:
Quantity per Assembly. For example, if there are 2 of Kanban item R per one
assembly of item K, and the demand for K is 10, then the demand for R is 20.
Component Yield. The program divides the demand for the child item by that
item's component yield to determine the actual demand for the child item. For
example, if the component yield for item R is 50%, the new demand for R is 40
(because 20 divided by 50% is 40).
Reverse Cumulative Yield. The program further divides the demand for the child
item by the Reverse Cumulative Yield (specified in the operation sequence of the
flow routing for the parent item) to determine the actual demand for the child item.
For example, if the reverse cumulative yield for K is 10%, the new demand for R is
400 (because 40 divided by 10% is 400).
Net Planning Percentage. The program then multiplies the demand for the child
item by the Net Planning Percentage (specified in the operation sequence of the
flow routing for the parent item) to determine the actual demand for the child item.
For example, if the net planning percentage for K is 80%, the new demand for R is
320 (because 400 multiplied by 80% is 320).
Finally, the program sums up the demand entries that fall within the Kanban
planning horizon for each Kanban item at each location and divides the demand
for each item at each location by the number of workdays. For example, if the
number of workdays on the planning horizon is 20, then the average daily demand
for item A at location L1 is 6 (because the total demand for item A at location L1
for the planning horizon is 120). The program prorates the demand from periodic
Page 12
forecasts for those days between the Demand window specified for the calculation
program.
In the following example, the Kanban Size is defined for the item KB15138.
You can print Kanban cards for a replenishment plan or a replenishment chain
when you generate the cards. You can also print cards individually if the card
information is complete. You can print duplicate cards only if the original is lost or
voided.
In a Kanban System, every container has a Kanban that displays the item number,
Item description, usage point, supply point, size of the Kanban (or pull quantity)
and the sequence number of the card.
Page 13
TECHNICAL OVERVIEW:
Tables used:
MTL_KANBAN_CARDS:
MTL_KANBAN_CARDS is the definition table for Kanban cards. The associated
attributes describe which pull sequence this card belongs to, the Kanban size,
supply status, and card status
MTL_KANBAN_CARD_ACTIVITY:
MTL_KANBAN_CARD_ACTIVITY is a history table of the activity performed
on a Kanban card. The associated attributes describe which Kanban card this
activity belongs to, and what document replenished it.
MTL_KANBAN_PULL_SEQUENCES:
MTL_KANBAN_PULL_SEQUENCES is the definition table for pull sequences.
The associated attributes describe which item, subinventory, and locator this pull
sequence belongs to, the source type, number of Kanban, Kanban size,
replenishment lead time, and other planning attributes.
Packages used:
Get_Pull_Sequence_Tokens:
This procedure gets the names required to build the message for a pull sequence
Delete_Pull_Sequence: This procedure deletes all pull sequences for a given plan.
Page 14
Launch_MLP: This program will launch the WIP Mass load program to upload the
data from WIP_JOB_SCHEDULE_INTERFACE table.
Page 15
Create_Wip_Job: This procedure will decide about the creation of a WIP replenish
mode.
Create Replenishment: This procedure would create kick off the replenishment
cycle for the Kanban cards.
Procedure to Create_Kanban_Cards
procedure card_check_and_create
INVKBCGB.pls
This Stored package is a Concurrent program, primarily for Generating Kanban
cards and launching the card printing report.
It has got following subprograms:
Page 16
6. Card_check_and_create checks for the existence of valid cards and calls APIs for
generating cards.
Page 17
REFERENCES:
Page 18