Glossary 

Input addressing

Used data

The input addressing rules involve parameters and information defined at several levels:
  • Product level: the input mode
  • Container level: ABC classes, assignment classes, prohibition classes, priority input store, maximum number of pallets, incomplete pallets and stacking coefficient and correction

Used algorithms

  • Cross-docking input (available depending on the version)
  • Picking input
  • Merging (available depending on the version)
  • Picking vicinity search (available depending on the version)
  • Standard input

Product

  • A product is defined by means of a given site and depositor.
  • A product is identified in a unique manner via its code (alphanumerical field of 20 characters).
  • A product only has a meaning for G.E.O.D.E. GX if it is associated with a container (see product containers).
  • A product is defined by its type (CU or STK management), its physical characteristics (containers) and its management rules (input mode, output mode, ABC classes, assignment classes, FIFO, groups, origin, chaining rules, etc.).

Assembling

Assembling

The assembling functionality in Warehousing allows the following operations:

  • Assemble kits upon request: it is the assembling procedure.
  • Disassemble kits upon request: it is the disassembling procedure.

These two procedures are managed through assembling orders (AO) of either "Assembling" or "Disassembling" type.

The assembling procedure is as follows:

  • Creation of an AO with the "Assembling" type comprised of AO lines (kit + components). These AO can be created manually or via an interface from the level-3 work orders.
  • Creation of an assembling wave with the "Assembling" type which regroups several "Assembling" AO.
  • Assembling wave launch. These waves operate like the merging of flows. In other words, the first phase consists in generating TO with the "Component transfer" type directed to the assembling zone. The second phase consists in declaring the kit production.

The disassembling procedure is as follows:

    • Creation of an AO with the "Disassembling" type which regroups AO lines (kit + components). These AO can be created manually or via an interface from the level-3 work orders.
    • Creation of an assembling wave with the "Disassembling" type which regroups several "Disassembling" AO.
    • Assembling wave launch. These waves operate like the merging of flows. In other words, the first phase consists in generating TO with the "Kit transfer" type directed to the assembling zone. The second phase consists in declaring the kit disassembly.

Locking a location

  • Locking a location makes it possible to prohibit any new addressing.

Warning: The validation of pending movements at the time of a location locking is not impacted by the locking operation.

  • The locking parameter prohibits any new input and/or output addressing.

Note: In case of a multi-product location, there is no need to lock it. Assigning a stock nature to the object in the location is enough to prohibit its output.

Delivery Note (DN)

  • The Delivery Note (DN) is a document intended for the customer to whom the goods are shipped. This document specifies the quantities shipped according to a Delivery Order (DO).
  • The DN composition can be performed either during an intermediate stage of the DO output sequence (provisional Delivery Note) or it can be associated with a shipment confirmation stage (final Delivery Note).
  • The DN is identified by means of a single number which is incremented automatically by the system and is linked to the output movements. The name of the DN report is set up at depositor level and at DO header level, thus enabling different DN to be printed for a given customer.
  • A Delivery Order allows the creation of a single DN if the balance management is not set up, if there is no additional PO to the DO and if the shipment postponement function is not used.
  • All the DN for a same ship-to customer and for the same shipment date can be regrouped in the same document called Carriage Receipt (CR).
  • All the DN for a shipment constitute the Carriage Note (CN).

Carriage Note (CN)

The Carriage Note (CN) combines all the DN for a shipment. It is generated upon shipment confirmation of a round. The name of the CN report is set up in the carrier table.

Inventory campaign

An inventory campaign is an entity that represents a period set in time by a start date and an end date and during which minimum inventory objectives are determined in terms of stock count numbers.

These objectives are determined by product by means of the inventory class.

Example Let us consider an inventory campaign defined from 01/01/07 to 31/12/08.
Let us consider three inventory classes for each product in the base.
Class A: 3 counts during the campaign
Class B: 2 counts during the campaign
Class C: 1 count during the campaign

The system will automatically submit the products to count with respect to their inventory class using the campaigns during the creation of inventories.
The inventory campaigns correspond to inventories more commonly called 'rotating inventory by product'.

Input sequence

The process is the following:

CHAINE_ENTREES.GIF

Output sequence

The process is the following:

Chaine_Sorties.gif

Assignment class

It is possible for each location to define a priority assignment class. This concept is also linked to products.

Based on a process identical to the one used for ABC classes, the system will try to match the assignment class of the location and the assignment class of the product during the search for a location.

Likewise it is possible to define chaining rules for the search for assignment classes.

For a product with an assignment class defined as class H (for Heavy product), the computer will first search a class H location inside the product storage area (usually levels '0' and '1' of a pallet rack are defined as class H in order to prevent heavy goods from falling when pallets are handled during storing).

The assignment class is also used for "outsize" management.

Prohibition class

The prohibition class, which is a concept specific to the product container, is not defined in a table. It actually refers to the assignment class.

Three values can be assigned to each product container in order to bar access to specific locations for these objects, although chaining rules are defined in the assignment class table.

Let us consider the chaining of the H assignment class (heavy products) to the Hi assignment class (very high products).
Let us consider the pallet container of product A of the H assignment class.
To prohibit the chaining of the H assignment class to the Hi assignment class, the Hi assignment class must be entered in the 'Prohibited allocation class' field of the pallet container of product A with the Hi assignment class.

This field is used to prohibit the chaining rule applied to the search for assignment classes.

Inventory class

The inventory class represents a code associated with each product and representing the management rules related to the inventory.
This code is used in the inventory campaigns to define the frequency of the inventories to be performed during a given campaign.

For example, products with a high added value can benefit from an inventory class specifying a larger number of inventories during a campaign.

ABC class

These classes are those defined by the A,B,C. analysis rules. They are specified on each product container.

Each location is assigned to an ABC class. This class should be considered in parallel with the ABC class of the container.

When searching for storage locations, the system will try to match the ABC class of the input container and the ABC class of the location.

Chaining rules are used to inform the system of the order in which the classes must be searched. The authorization to use these chaining rules is dependent on the input mode defined for each product, and on the storage type of the location.

For a product whose ABC class is defined as class B, the system will first search a class B location in the product storage area.

Bar code

The Bar Code (BC) is the identification system most widely used in the industry, distribution, medical sector, etc. because of its many advantages:

  • Low marking and entry cost
  • Easy to implement and use
  • Reliable
  • High data acquisition speed
  • Standardization

There are different code types available on the market, the most widely used being:
  • EAN
  • Interleaved 2 of 5
  • Alpha 39
  • Code 128

The difference between all these bar code types is mainly their density and their ability to manage alphabetical characters (and not only numerical characters). As a standard, Warehousing GX prints documents containing 128-type bar codes.

EAN code

The EAN code is the standard used for Mass Distribution in France. Its structure and use are defined by the GENCOD standard.

The EAN code is defined for each container of a product. Product and/or EAN code labels are available in Warehousing GX.

Supplier EAN code

The supplier EAN code is a code that identifies three pieces of data (supplier, product, container). It is defined in the products containers function.
A check option at the Sites function level (GESSIT) is used to check the uniqueness of the supplier EAN code by site.
This code is used in the supplier EAN code receipt procedure which can only be performed using the handheld receipt procedure (VTRCP).

Status code

The status is a value used to follow the evolution of an entity.

The status of a header changes when the status of all the lines that constitute the header has changed.

Expected Inputs (EI):

    • Header status codes
      1-Not received
      2-Partial receipt
      3 - 1st receipt pending
      4 - Nth receipt pending
      8 - Fully received/closed
    • Line status codes
      1-Not received
      2-Partial receipt
      8-Fully received

Receipt:

      1-Declared
      2 - Pending
      3-Partially validated
      4- Validated

Direct input:

    • Header status codes
      0-Pending storage
      2-In control
      4-Addressed
      8 - Storage performed (all lines are set to status '8')
    • Line status codes
      1-Not addressed (no movement validated for the line)
      4-Addressed (all movements addressed for the line)
      8-Stored/closed (the movements for the line are fully validated).
    • Status codes for the input movements
      1-Not addressed
      4 -Addressed (and pending validation)
      8-Movement validated

Storage list:

      1-Not validated
      3-Partially validated
      4- Validated
      5-Being created

Delivery orders:

    • DO header status codes
      1-Wait 1st pick
      2-Wait nth pick
      3-Selected for preparation
      4-Preparation in progress
      5-Wait to be packed
      6-Wait to palletized
      7-Wait to load
      8-Wait to deliver
      9-Shipped / Closed
    • DO line status codes
      1-Wait 1st pick
      2-Wait nth pick
      3-Selected for preparation
      4-Preparation in progress
      8-Wait to deliver
      9-Shipped / Closed
    • Output movement status codes
      1-Being addressed
      3-Addressed
      4-In shortage
      5-Canceled in the preparation
      6-Canceled in the shipment
      7-Deferred in the shipment
      8- Validated
      9-Shipped
    • Parcel status codes
      3-Creation pending
      4-Not validated
      5-Auto Palletization
      6-Wait to palletized
      7-Wait to load
      8-Wait to deliver
      9-Shipped
    • SU status codes
      4-Not validated
      6-Preparation pending
      7-Waiting to load
      8-Wait to deliver
      9-Shipped

Picking Orders (PO):

      1-Not validated
      3-Partially validated
      4- Validated
      5-Being created

Palletization Orders (PAO):

      1-Not validated
      3-Partially validated
      4- Validated
      5-Being created

Wave:

      1-Wait to launch
      3-Wait to transfer
      4-Wait 2nd step
      5- Ended

Transfer/Replenishment orders:

    • Status codes of transfer/replenishment movements
      3 - Addressed
      7 -Transfer pending (for a 2-phase transfer)
      8- Validated
      9 - Canceled

Adjustment:

    • Status codes of the adjustment movements
      8-Stored/closed

Assembling orders:

      • Header status codes
        1-Pending preparation
        3-Selected for preparation
        4 - Preparation under progress
        9 - Processed
      • Line status codes
        1-Pending preparation
        3-Selected for preparation
        4 - Preparation under progress
        9 - Processed
      • Assembly declaration status codes
        1 - Not addressed
        3 - Addressed
        5 - Non-compliant
        6 - Compliant
        9- Validated
      • Assembly movement status codes
        1 - Not addressed
        3 - Addressed
        9 - Validated

Analysis requests:

      • Header status codes
        1 - Wait for quality control
        2 - Quality control in progress
        7 - Wait to validate
        9-Validated/closed

Operator code

The operator code is used to identify a set of persons working on the site and assign them authorizations with respect to each logistic flow to be handled:

  • Receipt: authorization granted to validate receipts of expected inputs
  • Storing: authorization to validate storage lists
  • Picking: authorization to validate picking orders
  • Prepacking: authorization to validate parcels created during prepacking
  • Declarative packing: authorization to validate parcels created during declarative packing
  • Stock on dock: authorization to validate parcels/SU transfers
  • Forced shipping: authorization to force the shipment of a DO or a round containing parcels/SU with the "Pending transfer" status
  • Carrier EDI: authorization to manually create EDI messages
  • Manual adjustment: authorization to create manual adjustments (quantity- or quality-related, etc.).
  • Transfer: authorization to validate transfers
  • Replenishment: authorization to validate replenishment orders
  • Preventive inventory: authorization to validate preventive inventories
  • Assembly: authorization to perform assembly declarations
  • Disassembly: authorization to perform disassembly declarations
  • Quality control: authorization to validate the quality control of an analysis request
  • Analysis request: authorization to validate an analysis request
  • Consumable input: authorization to validate consumable inputs
  • Consumable outputs: authorization to validate consumable outputs

Based on the setup of each flow, on operator code may be necessary when the flows are validated.
If an operator code is mandatory, various processes are available depending on the work mode (Client Server, Web, VT) and the user type (with or without linked resource):
  • In server client or Web mode: an operator code must always be entered irrespective of the user type or resource.
  • In VT mode (Video Terminals procedures):
    • In the case of a user with no linked resource: an operator code always needs to be entered.
    • In the case of a user with linked resource: it will depend on the type of management defined for the resource.
      • Manual: an operator code must always be entered.
      • Semi-automatic: an operator code will need to be entered upon first validation, then Warehousing will automatically use this code for further validations.
      • Automatic: no entry is required. Warehousing will automatically use the operator code defined at resource level.

Note on the "Semi-automatic" mode: The VT function "Operator code RTZ" is used to reinitialize the operator code. Thanks to this function, it is possible to reset to zero the operator code stored upon the first validation in "Semi-automatic" mode. As a consequence, during the next validation, the resource will be required to enter an operator code again.

Merging

Merging is a storage option used to store a pallet without having to occupy an additional space on the site. It corresponds to the search of a maximum of one or two objects from incomplete pallets likely to accommodate all or part of a pallet while complying with a maximum time difference for the FIFO dates (refer to the maximum 'FIFO Tolerance' parameter defined in the main product record).
This option can be used in the location search chain, that is to say on input, during a transfer, or even when re-addressing a partially consumed pallet (or remainder of a replenishment) during a picking replenishment.
There is no merging of stock objects pending output.
Merging is only performed for level-1 containers.

Merging principle: The merging algorithm follows specific priorities:
1.Merging on the (level 1) container of the input movement
2. Merging on the (level 1) default container of the product if the homogeneous container of the input movement is part of the product palletization plan
3. Merging on the first (level 1) container of the product (by alphabetical order)
4. If no level 1 container could be found for the product, no merging is performed.

Consumable

Consumable

A consumable is a product that is not managed on location, and for which specific input and output movements are performed. A consumable type product allows stock inquiries displaying at any given time the theoretical stock and the input and output movements that took place.

Movements for consumable products can be created directly, without any reference to the Warehousing flows, or they can be entered from the receipt and shipment functions, provided the flows are not recorded.

Container

Palletization plan

The palletization plan of a product represents the physical description of its various packings.

The user must describe the composition of the palletization plan(s) for each of the products that will be managed by the system.
A palletization plan can be broken down into 5 levels of hierarchically nested containers (principle of the Russian nesting dolls).
The need to create several palletization plans for a single product may correspond to logical or physical constraints.
The diagram below describes a palletization plan with the following components:
Level 1 container: pallet PP1
Level 2 container: layer LL1
Level 3 container: box CC1
Level 4 container: bag SS1
Level 5 container: Unit A CU or STK

A maximum of 5 nesting levels is possible to describe a palletization plan.

If incomplete containers are created, the system tries to reconstitute the object in one of the levels defined for the container of the stock object.

glossaire_contenant_01.gif

Input container

It is the container of the default palletization plan of the product used by the input algorithm. The system searches a location likely to accommodate this container.

  • If the input request is defined as:
    1 PP1 of 10 CC1 = 1000 ACU, the system searches a pallet location
  • If the input request is defined as:
    1 CC1 of 10 SS1 = 100 ACU, the system searches a box location

Homogeneous container

It features the highest intermediate container level that can be expressed in integers.

Let us consider the following standard palletization pallet:
1 PP1 = 1 LL1 (1000 ACU) = 10 CC1 (100 ACU) = 100 SS1 (10 ACU) = 1000 ACU

  • Let us consider a movement or a stock object defined as 1 PP1 of 980 ACU, the homogeneous container will be 98 SS1.
  • Let us consider a movement or a stock object defined as 1 PP1 of 900 ACU, the homogeneous container will be 9 CC1.

Volume classes

The concept of container refers to a volume class in the meaning of Warehousing.

A volume class corresponds to a set of objects of identical levels whose dimensions are roughly similar.
In most cases, it is necessary to define volume classes according to the type of the storage locations (for example, height between sills).

The example below reveals that three pallet heights can belong to the same volume class:
2 meters < Volume Class 1 < 1 meter  Pallet PP1
1 meter < Volume Class 2 < 0 meter  Pallet PP2

glossaire_contenant_02.gif

A pallet that is not in compliance with the palletization standard (less or additional quantity) does not change its container code. As a consequence, for the system, it occupies the same space as a standard pallet.

Warning! Creating a different container for the same product with each change in quantities on a pallet leads to a very complicated management and can cause system failures.

Customer date contract

The customer date contract contains two different options:

  • Option 1: the date contract is used to guarantee that products with a sufficiently long lifetime are shipped to the customer.
  • Option 2: the strict sequentiality is used to guarantee that products with a lifetime longer than the previous shipments are shipped to the customer.
Prerequisite:
The customer date contract can only be used for products that manage the FIFO date from the sell by date or the use by date.
Consequently the system will use the FIFO date of the DO line (standard output addressing algorithm), thus allowing stock with a FIFO date >= the FIFO date of the DO line to be addressed.

Option 1 - Date contract:
The principle is to ship to the customer only stock having a sell by date > provisional delivery date of the DO + X days/month (X represents the date contract leadtime defined for this customer).

When launching the wave, if the DO line meets the date contract criteria, the system determines the FIFO date used on the DO line:
  • if the FIFO date is already entered on the DO line, this date is kept: In Warehousing, the date sent to the customer order is preferred over the setup of the date contract.
  • If the FIFO date has not been entered on the DO line, the date to be applied on the line is calculated (= provisional delivery date + X days/months).
Setup:
a DO line meets the date contract requirements if the DO picking mode authorizes it and if a X date contract leadtime has been defined (see the date contract setup function)

Option 2 - Strict FIFO sequentiality:
using this option, the shipment sent to the customer can only contain stock with a sell-by date superior to the sell-by date of the previous shipment sent for the Ship-to customer/Depositor/Product group.

When launching the wave, if the DO line meets the strict sequentiality criteria, the system determines the FIFO date used on the DO line:
  • if the FIFO date is already entered on the DO line, this date is kept: the date sent to the customer order is preferred over the setup of the Warehousing product.
  • if the FIFO date has not been entered on the DO line, the FIFO date is calculated based on the stored date of the last shipment for the Ship-to customer/Depositor/Product group, if any.
When validating the DO shipment, if the FIFO date of the shipped movement is
  • strictly superior to the stored date of the last shipment, the system updates this stored date with the movement FIFO date.
  • inferior or equal to the stored date of the last shipment, the system keeps the stored date.
  • if no date is stored (no record for the group of three elements), a record is created with the FIFO date of the movement.
Setup:
A DO line falls within the scope of the strict FIFO sequentiality if the picking mode for the DO authorizes the date contract and a strict sequentiality setup has been defined (refer to the FIFO sequentiality/Site function).
The last shipment date is stored for the group of three elements (ship-to customer, depositor, product) in the ITMCLTFIF table. It can also be viewed in the FIFO sequentiality management / Depositor function.

SEEINFOFor this function to run properly, the "Output priority" setup for the product output mode must have the FIFO date set as thefirst criteria.

Case where both options are activated:
These two options run independently but if the DO line falls within the scope of both options, the FIFO date entered on the DO line will have to be the later date.
For example: if the system determines a date D for the date contract and a date D+5 for the strict sequentiality, the date D+5 is used.

Supplier date contract

The supplier date contract contains two different options:

  • Option 1: the date contract is used to ensure that the supplier guarantees a sufficient number of consumption days for products with a limited lifetime.
  • Option 2: the date return is used to guarantee that the supplier ships products with interesting expiry dates.
Prerequisite:
The supplier date contract can only be used for products that manage the FIFO date from the sell by date or the use by date.
The customer return flows (receipt line linked to an EI line with Customer return" selected) are not submitted to the supplier date contract.

Option 1 - Date contract:
The principle is that it is impossible to receive stock from a supplier having a sell by date/use by date < the day's date + X days/month (X represents the date contract lead time defined for this supplier).

When a receipt line is recorded, if the line falls within the scope of the date contract, the system will check that the FIFO date on the line complies with the supplier date contract.
If the FIFO date on the line does not comply with the supplier date contract, a warning message is displayed and the line is set to on dispute. No stock is put away and the nature of the stock is specified by setup. After this receipt has been validated, this line will not generate any direct input (DI) line.

Setup:
A receipt line falls within the scope of the date contract if an X date contract lead time has been defined (refer to the Customer date contracts/Site function).

Option 2 - Date return:
the principle is to receive from the supplier only stock having a sell-by date superior or equal to the last stored receipt date for the Ship-to customer/Depositor/Product group.

When a receipt line is recorded, if the line falls within the scope of the date return, the system will check that the FIFO date on the line ≥ the last receipt FIFO date stored.
If this is not the case, a warning message is displayed and the line is set to on dispute. No stock is put away and the nature of the stock is specified by setup.
After the receipt has been validated, if the line does not generate any stock put away, the receipt will not generate any direct input (DI) line.

When the receipt is validated, and it moves to status '4-Validated', the system checks all the validated receipt movements subjected to the date return. If the FIFO date of the movement is
  • strictly later than the last receipt date stored, the system updates the stored date using the FIFO date of the movement.
  • prior to or equal to the last receipt date stored, the system keeps the stored date,
  • if there is no stored date (no record for the group of three elements), the system creates a record using the FIFO date of the movement + number of days from the effective date set up.
SEEINFOthis update of the stored date is only done when the receipt moves to status 4. For the same administrative receipt, several FIFO dates can indeed exist on the supplier stock and it cannot be guaranteed that the operator's receipt will start by the less recent FIFO dates.

Setup:
a receipt line falls within the scope of the date contract if a date return setup has been defined (refer to the date return setup function).
The last receipt date is stored for the Ship-to customer/Depositor/Product group in the ITMDVRFIF table. It can also be viewed in the date return tracking function.

Case where both options are activated:
these two options run independently but if the receipt line falls within the scope of both options, the contract date option is used as a priority (as more restrictive).
Example: If the receipt date does not comply with the date contract, it is set to 'on dispute' and not added into stock. The date return does not need to be controlled.
However, if the receipt line complies with the date contract, a control is then applied to see if it complies with the date return.

Consumable

Consumable

A consumable is a product that is not managed on location, and for which specific input and output movements are performed. A consumable type product allows stock inquiries displaying at any given time the theoretical stock and the input and output movements that took place.
Movements for consumable products can be created directly, without any reference to the Warehousing flows, or they can be entered from the receipt and shipment functions, provided the flows are not recorded.

Quality control

The quality control is used to perform checking operations on the received goods.

The function is activated for an Expected Input via the supplier or directly on the EI header for a given product (new quality control tab on the product record); when the 2 conditions are verified, the created input lines referring to the received stock are assigned the quality stock nature (product configuration) in order to be stored in a store dedicated to the quality control (store with the stock nature of quality control type).

Once the storage list has been validated, the quality control operations can start by the creation of an Analysis Request for a given quality store; there are several possible options depending on the product setup:
- use of a quality record: the control entry is then carried out by means of a record containing questions and answers on the characteristics of the products.
- Running the single-lot control: the ARs are then created by input/product/lot triplet.
- sampling of the stock to be checked: a sample is automatically calculated based on the product setup, the quality control concerns this sample.

The quality control is carried out by entering complying and non-complying quantities and possibly quantities consumed during the control.

Depending on the control results and if the sampling is used, the "scrap" stock nature (stock configuration) is assigned automatically or not to the whole stock in quality control. When quantities have been consumed, they must be attributed to the stock objects being checked by manual assignment of the "consumed " stock nature (stock configuration).

Finally the RA can be validated or closed if the automatic addressing is activated by said RA. The stock is then transferred from the quality store to another store.

The parameters linked to the quality control are:
- the supplier record
- the expected input header
- the product record
- the stock setup
- the stock nature
- the operator codes
- the quality record management (questions, answers, quality record)

Cross-docking

Cross-docking is used to optimize the input-output stock movements. In case of an arrival on the receipt dock and a DO has the same product on hold, cross-docking prevents putting the product away in the standard stores to take it out immediately afterwards. The product will go from the input to the output via a cross-docking type store.

The cross-docking search consists in:

  • search of the stock (available or not) in the cross-docking store and of the unavailable stock in the reserve. If some stock is found, POs are created and printed.
  • search of cross-docking requirements in the Expected Inputs (status 2, 3 or 4) and the unaddressed Direct Inputs. Any requirement found is grouped on a cross-docking PO.

There are two types of cross-docking (that can be set up at picking mode level):
  • Cross-docking in priority: upon launching of a wave, a cross-docking search is carried out in priority. If no cross-docking stock is found or no cross-docking requirement has been expressed, a standard addressing is then carried out.
  • Cross-docking in case of shortage: upon launching of a wave, a standard addressing is carried out and if there is a stock shortage, a cross-docking search is started.

Notes:
  • Even if no requirement is found, it is still possible to create these requirements upon wave launching if the flag "Always express the requirement" is activated at output configuration level.
  • Launching the Cross-Docking POs is then used, when the stock is available in the cross-docking store (pending input or stock put away), to generate POs.

It is necessary, for the Cross-Docking functionality to be activated on a site, to:
  • assign the cross-docking store at site level,
  • activate it in the depositor output configuration,
  • activate it in the picking mode of the DO, with "partial delivery" set to yes in the DO header and the merging of flows deselected. The delivery unit of the DO lines must be at level 5 and it must not concern a kit.
  • activate it in the "management" tab of the product records of those products that need to be managed with the cross-docking functionality.

To be handled by cross-docking, an EI must have a receipt mode authorizing cross-docking and a DI must have its "cross-docking" setup set to yes in the "General" tab of its header.

Important: the "quality control" process has priority over the cross-docking process.

Flow merging

The "merging of flows" (refer to the picking mode table) is used to regroup DO lines (sum of quantities by product) in order to generate only one output request and consequently minimize preparation movements.
The system generates transfers that correspond to the consolidated requirements by wave product. These transfers are addressed in an allocation store where the preparation will be carried out.
glossaire_cumul_flux.gif

Important note: the 'merging of flows' picking does not manage the single lot on output. A DO line with the flag "Single lot" will be managed as a normal DO line with merging of flows.

Note: The expression PREPARATION IN TWO PHASES is used to describe this picking mode.

Please refer to: Preparation method table

This functionality is available from the Advanced version of Warehousing.

Dates

A set of 7 dates is associated with each object.

  • Input date: date usually corresponding to when the product enter the site
  • Production Date (PD): production date corresponding to the end of the product production cycle.
  • Detention date (DRET): date before which the stock object remains unavailable for any output movement (i.e. quarantine)
  • Sale-by Date (SbD): date normally used as the FIFO date for food products
  • Use By Date (UBD): date, also called Best Before Date, usually mentioned on the packaging of food or pharmaceutical products
  • Send By Date (SBD): Date used to limit the marketing of a product in time, either within the framework of a sales operation (e.g. discount operation), or because of the sell by date of a product
  • FIFO date: The FIFO date determines the stock-issue order when starting an order preparation (the oldest objects being removed from the stock in priority).
    It is also used to check that certain transactions are valid (merging, output on imposed FIFO date within the framework of the date contract management, etc.).

The value of the FIFO date is set up at the level of each product record, among the following values:

Input date
Production date
SbD
UBD
SBD

When entering an input line, these various dates are automatically calculated by the system if they have not been assigned by the operator, and if the parameters contained in the Main Product Record and that allow such a calculation (duration in days, weeks or Months) are not null.

 Input date

System date ( current date)

 DFAB

PD + Detention date

 SbD

PD + Product longevity

 UBD

PD + Shelf life

 SBD

PD + Marketing duration

The system prohibits the picking input and the purely reserve outputs of stored products meeting at least one of the following conditions:

DRET > system date
SbD <= system date
UBD <= system date
SBD <= system date

Depositor

In logistic terms, the concept of depositor is used to process flows or separate traffics within the same site. It covers the notion of order-giving customer for service suppliers.
Receipts, shipments and locations only are multi-depositor.

After the site, the depositor is the secondary access key to the Product, Input and delivery Order files.

The depositor code is comprised of a maximum of 10 alphanumerical characters.

The depositor is displayed at the bottom of the screen from the user environment. It is possible to change site/depositor depending on the access rights linked to the user, either by keying in Ctrl+F7 or by selecting Display, then Change of Environment.

WIPs

Pending movements are all the movements that have been ordered but for which the end of the physical movements has not been declared yet.

The concept of pending movement disappears from the stock object as soon as the movement is validated.
The distinction is made between a pending "output" movement when an output is performed from the location. This output can be represented by an output movement (itself coming from a DO), but also by a transfer or replenishment movement (removal location).

There are also pending "input" movements in case of receipts to stock. This input can be represented by an input movement (coming from a direct input), but also by a transfer or replenishment movement (repositioning location).

Validating a pending movement generates the change of the status code of said movement (from status 3 to status 8).

FIFO

F.I.F.O is the English abbreviation for "First In First Out". It corresponds to a management option of the stock issue where the oldest objects are taken from the stock in priority.

FIFO is the basic operating rule of the output sequence in the Warehousing application.

The FIFO rule of the stock objects can be an output criterion with more or less priority (output mode).

A (minimum) FIFO date like a Lot no. or a Reservation no. can be imposed at DO line level. The system will try to remove from stock objects with a FIFO date prior to and/or equal to the requested date (according to the setup).

Stock issue from a FIFO or LIFO location: for mass locations, stock issue can be performed in FIFO or LIFO (Last In First Out) mode.

Outsize

A stock object is of the "Outsize" type when its width exceeds the one of the location. If such a stock object is added to stock, it will spill over the next location.

Warehousing authorizes the management of "outsize" objects, according to the following rules:
- an "outsize" stock object can take up to two locations. It can step on the location on the right or on the left of the storage location.
- a location containing an "oversize" object cannot receive additional stock, as long as this object exists.
- an "oversize" stock object can only be stored in an "oversize" location if the location next to it is empty.
- only locations at the end of the line (same row, alley, level or first three components of the address structure) can receive "outsize" stock objects.

The operating principle is to use assignment classes to manage the identification of such stock objects and how they will be addressed to locations.

Assignment class: outsize mode management on the assignment class with three possible options:
- "No": not managed
- "Yes": outsize management
- "Adjoining outsize": specifies that the location is next to a location that can receive "outsize" objects. Stock objects can thus spill over.

Example: let us consider a line containing 5 locations numbered from 1 to 5 (1 and 5 being the start and end of line locations).
Location 1 accepts "outsize" stock objects that will spill over location 2.
Location 2 authorizes stored objects to spill over location 1.
Location 3 does not authorize oversizing.
Location 4 authorizes stored objects to spill over location 5.
Location 5 accepts "outsize" stock objects that will spill over location 4.

Assignment class H: Class type "Yes"
Assignment class G: "Adjoining outsize" class type
Assignment class A: Class type "No"

Assignment class chaining is authorized in the following cases:
A => G => H
G => H

 "Outsize management"

 Yes

Adjoining

No

Adjoining

Yes

 Assignment class

 H

G

A

G

H

 Location

1

2

3

 5


Let us consider an "outsize" stock object (including a class H product): location 1 or 5 are addressed exclusively
Let us consider a non "outsize" stock object (including a class A product): location 3 is addressed and by default, location 2 or 4, and as a last resort, locations 1 and 5.

Please not that you can prohibit the addition of non "outsize" objects to "outsize" locations (such as 1 and 5). To do so, you need to use a new assignment class B set up with no chaining towards classes G and H.

"Outsize" stock posting:
the "outsize" stock object is stored in an "outsize" location. The locations next to it, where the stock objects will spill over, are considered as empty locations. However, if the "Overflowing outsize" flag is used, the location is blocked because objects are spilling over it.

Stock count

Several types of stock count can be carried out: pinpoint stock count on address criterion, pinpoint stock count on product criterion and cycle stock count by product depending on the stock count class.

The user is free to organize the stock count as they see fit.

Thus, it is possible to create a stock count for a store and create a count for each of the operators in charge of a count, or a stock count can be created by area whose stock needs to be taken, and a single count corresponding to the area, associated to it.

The stock count in Warehousing GX is based on localized stock, in other words, on stock objects. Before any stock count, it is thus necessary to set up a procedure likely to count all the elements of a product stock.

For instance:
Upon creation of an inventory by product, all localized stock with or without pending movements will be identified and can be submitted to a count.

On the other hand, although the stock is physically located in the warehouse, some flows are not identified as such. They are:
  • The expected inputs: Products belonging to DIs whose receipt is "declared" or "pending"; they are not localized. It can become necessary to post them. The reprint of the receipt check lists can be a way to achieve this.
  • Direct inputs: The receipt is validated but the addressing has not been performed or it has been performed but the stock count does not take the pending movements into account. A stock print by addressed or non-addressed input movement can be useful.
  • Delivery orders: All output movements with status 7-Postponed, 8-Validated. These output movements are potentially pending palletization or loading, or postponed upon shipment, but they are neither canceled nor shipped. Physically, the stock of these movements is in principle in the warehouse.
    glossaire_inventaire.gif

The stock count can be carried out with or without pending movements so as to enable a "procedure-based" organization at the level of the completion of the physical operations.

Likewise, the fact of being able to move a product in stock can be set up by depositor (flow control setup).
A product in inventory is at the level of its product record "blocked in input and output" and "in inventory".

  • On input, controls are performed for the creation of expected input lines and direct input lines, the administrative receipt, the addressing. On the other hand, it is possible to generate SLs and to validate them.
  • On output, controls are carried out upon creation of the DO lines, the launch of a wave, the manual output addressing. On the other hand, it is possible to validate POs and parcels.

Irrespective of the setup, it is not possible to perform transfers for a product being counted or adjustments.

A location "in inventory" has the same information, but it cannot be moved irrespective of the setup.

Preventive stock count

A preventive stock count is an optional stock count operation which can take place following the picking of a product from an undifferentiated picking location via VT procedures.

This preventive stock count presents some limits:

  • only the undifferentiated picking locations are concerned.
  • only the products with no serial number management are concerned.

Principle: In the VT picking procedure, after the picked quantity of a product has been validated, and based on the setup, the system asks the operator to enter the stock quantity of this product in this location. Then the system automatically adjusts the stock if necessary.

The preventive stock count is carried out provided the site level setup (VT procedures tab) allows it:

  • the preventive stock count is active on the site.
  • the store authorizes it (refer to the Store function)
  • the time elapsed between two stock counts on this location is longer than the time specified in the VT procedures tab.
  • the movement code used for the automatic adjustment is duly entered.

SEEINFOa preventive stock count is not counted in the stock count in progress.

Storage list

The storage list is generated automatically upon automatic input addressing. It is used to regroup addressed movements, depending on the input configuration setup of the current depositor. It can also be printed and it is then used as a storage medium.

The SL can be modified, deleted or created based on the criteria specific to the storage of the products in the warehouse.

The SL contains a progress status:
  • Status 1-Not validated
  • Status 3-Partial validation
  • Status 4-Validated
  • Status 5-Creation

Lot

The concept of lot provides full traceability of the objects from receipt to shipping. It can correspond to a number assigned during production, a quality identifier etc.

The lot number (alphanumerical field of 13 characters) can be assigned when the products enter the warehouse or at any moment in stock; the same number can be assigned to different objects (separate references, different FIFO dates, etc.).

The DO lines can mention a lot number. In that case, the stock issue with that lot number must be exclusive.

Management of the "single-lot" on output:
If the management of lots on output is not provided for (field not assigned on the DO line), according to the setup of the DO line (flag "single-lot"), the result is as follows:
- If not checked, the system sees the stock indifferently; in other words, any object having or not a lot number can be issued from stock.
- If checked, the system will necessarily address the DO line from a single lot. If the system cannot entirely address the DO line, it will address it from the lot having the largest quantity except in case of prohibited partial lot (DO or line level) where the DO line will reveal a stock shortage.
Important note: the 'merging of flows' picking does not manage the single lot on output. A DO line with the flag "Single lot" will be managed as a normal DO line with merging of flows.

Management of the "single-lot" on location:
Depending on the setup (refer to the storage type), it is possible to use the concept of "single lot" for the locations of reserve or picking type. Concerning the picking locations:

- if the single lot mode is activated, the stock objects are necessarily differentiated.
- the single lot can be managed by means of the notion of multi-picking.
- the "single lot" mode means that at a moment m, there is only one lot number in a given picking location.
- With a new input in an empty picking location, the lot is assigned to the location. When the whole picking stock is empty, the lot number is withdrawn from the location.
- The lot number requested in the DO line will be the number provided; if the stock of the requested lot does not suffice, the system generates a shortage. If the whole stock of a picking location with a lot A is pending output, and a DO related to a lot B is started in preparation, the system does not generate any shortage even if the output mode prohibits reserve output, and it searches the objects with lot B in reserve.
- if no lot is requested on the DO line, the system tries to sample stock objects according to the priority output criteria (objects can have a lot number or not ).

Lot exclusion by customer management:
The shipment of particular lot numbers can be prohibited for a given customer.
Using the customer setup, you can activate this feature and define the lots to be excluded for the Ship-to customer/Depositor/Product group in the "Lot by customer management function.
This way, upon output addressing, the relevant DO lines will not recover these lot numbers in stock.

Store

This notion is used to perform a representative splitting of the warehouse. For each store in the warehouse, it is necessary to mention the management rules that are specific to it.

The delineation of the stores is carried out jointly with the logistics team of the company based on the nature and constraints of the products to be dealt with, the physical configuration of the storage locations and the handling means available in the warehouse.

A store will have a unique address structure.

Stock on quay

The "Stock on dock" function is used to manage and track parcels/SU on docks.

The principle is to manage validated parcels/SU on locations of dock type. It is then possible to transfer parcels/SU from a dock location to another.

Parcel stock on dock:

  • Activation: the parcel dock management works if and only if the "Parcel dock management" flag is ticked in the output configuration.
  • Functioning:
    • Upon validation of a parcel (in prepacking, declarative packing or repacking), the system specifies the destination dock according to the parcel allocation criteria. The parcel is then 'In transfer' or 'On dock' according to whether the stock on dock automatic validation is activated or not.
    • Once the parcel is 'On dock', it is possible to transfer it to any other location of dock type.
    • Caution, a parcel palletized in an SU is automatically located on the dock of this SU. If there is no SU dock management, the palletized parcel is no longer located on a dock and has an "Ex-dock" status. On the contrary, if it is depalletized, the system will suggests a new dock location for the parcel.

SU stock on dock:

  • Activation: the SU dock management works if and only if the "SU dock management" flag is ticked in the output configuration.
  • Functioning:
    • Upon closing of an SU, the system specifies the destination dock according to the SU allocation criteria.  The SU is then 'In transfer' or 'On dock' according to whether the stock on dock automatic validation is activated or not.
    • Once the SU is 'On dock', it is possible to transfer it to any other location of dock type.

Dock transfer:A function makes it possible to transfer parcels/SU from a dock location to another.

Transport method

A transport method is assigned to each DO. It stipulates the way in which the goods are going to be routed.

The transport method is involved in:
  • The assignment of a carrier to a delivery order
  • Round management.

Load preparation modulus

The modulus refers to an output movement, expressed in "CU" units, and that specifies a quantity being the multiple of a container of a higher level.

This information is only used for the load preparation processing in the output sequence.
It specifies if the product container must be used as a load preparation modulus when it cannot be shipped as it is.
As a matter of fact, if a level 2, 3 or 4 container is not dispatchable as is and the quantity of the output movement expressed in CUs is the multiple of one of these containers, the system takes into account the dimensions and weight of this container in the prepacking algorithm.

Thus, this function prevents splitting the units of a complete layer (level 2), a complete box (level 3) or a complete bag (level 4) into several packages.

The setup of the modulus as an active element in the prepacking calculation is carried out in the product container file.

For example: Let us consider a standard pallet with the following palletization process:
1 PP1 = 1 LL1 (1000 ACU) = 10 CC1 (100 ACU) = 100 SS1 (10 ACU) = 1000 ACU

Where:
  • the modulus is active on the CC1 and SS1 containers
  • the flag 'dispatchable as is' is inactive on the CC1 and SS1 containers
  • the prepacking function is active on the DO
  • a picking is defined in CU
  • which means an output request of 282 ACUs.

During the prepacking process, the system splits the output request as follows:
282 ACU = modulus of CC1 X 100 ACU + modulus of SS1 X 10 ACU - 2 ACU
Modulus of CC1 is equal to 2 and modulus of SS1 equals 8.
No split into multiple parcels is performed during a CC1 or SS1 prepacking if at least one parcel of the selected routing is big enough to contain it all.

Stock movement

A movement defines the transfer of a stock object within the site or an operation without transfer on a stock object.

This can be:
  • an input movement (stock being put away)
  • a transfer movement (or replenishment)
  • an output movement (preparation)
  • a qualitative or quantitative adjustment

It is made up of:

  • Movement no.
    Movements are usually regrouped according to predefined criteria under a no. identifying a load:
    For an input movement, the regrouping is performed via the SL.
    For an output movement, the regrouping is carried out via the PO.
    For a transfer or replenishment movement, the regrouping is performed via the transfer or replenishment no.
    For an adjustment movement, there is no regrouping, since the adjustment movements are validated as soon as they are created.

  • Movement type
    The movement type allows a movement to be classified according to its nature.
    I = Input movement
    O = Output movement
    A += Positive adjustment movement
    A - = Negative adjustment movement
    A  = Qualitative adjustment movement
    Binary movements: T+,T- = Transfer/Replenishment Output/Input, internal picking

  • Movement store:
    Store where the physical operation is carried out.

  • Movement address:
    The store and the address identify in a unique way the location where the physical operation is carried out.
    The object no. is used to characterize the operation in a clear manner for the mass type addresses.

Note: This information is only valid for an addressed movement.

  • Movement status code:
    It materializes the progress status of the computerized or physical processes that need to be carried out.
    • Input movement:
      1 - Not addressed
      4 - Addressed
      7 - Stored
    • Replenishment movement:
      3 - Addressed
      7 - In process
      8- Validated
      9 - Canceled
    • Output movement:
      1 - Being addressed
      4 - In shortage
      5 - Canceled in the preparation
      6 - Canceled in the shipment
      7 - Deferred in the shipment
      8 - Validated
      9-Shipped

  • Movement date:
    date upon which the current movement has been requested.

Via the File/Properties option, the user and times of creation and modification of records are displayed.

Stock nature of a Product

It is used to manage the quality-related differences at stock object level (Expiry, quarantine, etc.).
The assignment of a stock nature is used to isolate some stock objects from a product. These objects will not be considered as being available by the output sequences (except when a stock nature is being imposed at order line level). This information is used to impose the exclusive output of stock objects of a particular nature.
If the stock for such a nature is insufficient, a shortage is triggered by the system.
This option generates a reserve processing (the potential picking locations are being ignored).

The assignment to and/or withdrawal from a stock object of a stock nature code generates the entry of a qualitative adjustment movement.
A relation can be set up between a stock nature and a store, it is used to direct the blocked products towards a specific area. This store takes the place of the default input store of the container considered during the addressing of a product bearing this stock nature.

This rule is applied:
  • During an input
  • During a transfer

Note: It is possible to block a product either from receipt or once it has been put into stock. The transfer movements remain possible for any blocked stock object.

Warning: If a stock object pending output is blocked, the system does not cancel the product output. The output pending movement needs to be canceled to block the output of this stock object.

Container level

The container level represents the space that a container of this type should occupy in the palletization program of a product.

Warehousing manages 5 container levels:
  • Level 1: Pallet (also called storage unit)
  • Level 2: Layer
  • Level 3: Box (also called delivery unit)
  • Level 4: Bag
  • Level 5: CU (also called consumer sales unit) or STK (stock unit)

The highest level container has the value '1' and usually corresponds to the pallet.
Among the five possible container levels, only the lowest level (level '5') is mandatory when creating the product containers (case of the products managed in bulk).

Homogeneous container of a stock object

The homogeneous container of a stock object is defined as the first lower-level container (other than level 1, the pallet) whose CU stock quantity is a multiple. This homogeneous container is calculated automatically based on the CU quantity of the object and the container of the stock object.

Here are a few possible representations of a stock having a palletization program of type:

1 PP1 of 4 LL1 of 10 CC1 of 5 SS1 of 20 ACU

 CU stock

Stk cnt

Homogeneous cnt

 4000

1 PP1

4 LL1 1000 

 3900

1 PP1

39 CC1 100

 3780

1 PP1

189 SS1 20

 3779

1 PP1

3779 ACU 1 

 3900

39 CC1

39 CC1 100

 120

3 CC1

2 SS1 20

Homogeneous level

In order to manage the stock of homogeneous pallets in terms of containers (for instance, full layer pallet, full box pallet), it is possible to set up the homogeneous level of each of the product containers.

This minimum homogeneity level is then demanded upon input to stock of a product container, or upon modification of a stock object.

For a homogeneity level n, it must be possible to express the input stock as an integer of containers of level n.

Example:
For a standard container of type: 1 PP1 of 4 LL1 of 10 CC1 of 5 SS1 of 20 ACU
The input of a non-standard container is only authorized for the mentioned levels:

 Container on input

Homogeneous level

 1 PP1 of 1000 CUs (10 CC1)

3

 1 PP1 of 1240 CUs (62 SS1)

4

 1 PP1 of 1250 CUs

5

Validating the SL does not make it possible to break a box (1st case) or a bag (2nd case). The last case (or level) makes it possible to break the lowest unit. In order to break the lowest unit, it is necessary to set up the homogeneous level to level 5 for each of the container levels of the product.

Bill Of Materials

A Bill of Materials is a list of components forming a compound (kit). It is solely used in the management of outputs and shipments.

The definition of a kit can be preset in a table, or it can be systematically transmitted or entered without any link with predefined kits.

The line nature of the Kit or component DO defines the product type.

The preparation of a kit is different in the sense that the Kit output movements are devoid of addresses and the component output movements are the ones making up the PO. Kits are isolated upon preparation of kit-type POs, so that the preparation of a kit is not split between several POs.

The load preparation and prepacking of a kit only takes into account the quantities and dimensions of the kit product. The components are ignored although they belong to the same parcels as the kit.

Upon launching the wave and upon validating the POs/parcels, the system checks that it is possible to carry out at least one kit while meeting the exact number of components per kit.

  • Calculation of the wave shortages
    A shortage detected on one of the components necessarily generates a recalculation of the quantities to be prepared for all the component lines so that the quantities whose preparation has been launched always match an integer of complete kits.

  • Declarative prepacking/load preparation
    The calculation of the parcels is carried out from the unit characteristics of the compound and not of the components.

  • PO or parcel validation
    Only the lines of "component" type can be entered, and the system makes sure that the validated quantities of each of the components is equivalent to the preparation of the complete kit.

    Stock object

    The stock object is the smallest storage object in Warehousing.
    It corresponds to the quantity of one product in a given palletization program (see Container).

    It has the following properties:
    • it is located on a location of one of the stores of the site.
    • it has logical characteristics (stock nature, reservation, lot, FIFO, dates, etc.).
    • it has a number assigned by the system upon its creation by entry or by adjustment.

    Upon quantitative modification of a stock object, in the case of a transfer for instance, the object no. is updated and incremented.

    In order to ensure full traceability between its x objects coming from the same object, and another area, the container no. is updated by the object number of origin.
    By querying the stocks by means of this identifier, it is possible to know all the stock objects constituting the object at the origin of its creation.

    These pieces of information are displayed in the detail of the stock object.

    Linked stock object

    • A stock object is said to be linked (to another stock object) when it is located inside the same physical container.
      For instance: Let us consider a product with the following palletization program: 1 PP1 =2 LL1 of 10 UCU, managed in Lot no. 2 PP1 incomplete in stock from different lots and in separate reserve locations.
      By means of a transfer with merging without accrual, the 2 objects only occupy a single location (the available space being calculated with respect to the master object), they are linked together and each keeps its own characteristics.

    • This notion enables "multi-product" pallets, "multi lot number" pallets, etc. to be managed.

    • A linked stock object is displayed in the stock inquiry with the character "&". The "displayable" Link no. field in the detail of the stock object is then completed with the no. of the "master" object (support on which the objects are linked).

    Field

    Update

    Comments

    Stock object no.

    Object creation
    Stock transfer

     

    Link no.

    Merging without accrual
    Addition to container adjustment

    Is equal to the master object no.

    Container no.

    Stock transfer

    Is equal to the object no. if no
    stock object modification.
    It then keeps the original object no.

    Delivery Order (DO)

    A Delivery Order (DO) features the minimum preparation entity.
    It can be the exact reflection of a commercial order, or an image of that same order, minus the known shortages of the commercial management system, or a regrouping of orders for the same recipient. In that case, the order corresponds to a DO line. It is possible to manage a multiple link between DO and orders, each DO line being attached to an order.

    A DO is necessarily composed of a Header and a group of Lines.

    It is used as a reference for all the information reports related to the preparation, load preparation and shipping.

    A DO can be identified by means of a number (sequence automatically assigned by the system), a reference (external information whose uniqueness is checked) and an order number (external information that can be common to several DOs).

    The DO balance management is possible in Warehousing if it is not taken into account upstream by the commercial management.
    If it is managed by the sales administration system, EDOs (Executable Delivery Orders) are sent to Warehousing. Warehousing then transmits the preparation report and, depending on the commercial decisions of the sales administration department, a balance DO is transmitted to Warehousing again.
    If it is managed in Warehousing, further to the 1st preparation, a report can be transmitted to L3 but the DO remains in the Warehousing DO portfolio for later processing.

    Delivery Order pending transfer

    The DO "pending transfer" is a special delivery order that is shipped to another site, in order for example to be consolidated, before being shipped to the final ship-to customer.

    The DO is said to be "pending transfer" from the moment that the "inter-site" round to which the DO is assigned has been shipped.

    No operation takes place on the destination site. For instance, the unloading of the parcels or SUs of the DO is not possible. Generally speaking, everything to do with a DO "pending transfer" is fixed.

    On the other hand, it is possible to consolidate the DOs "pending transfer" with those of the current site inside the same final shipping round.

    Palletization Order (PAO)

    A Palletization Order represents a parcel palletization load. It is linked to the auto palletization functionality.

    It is composed of a group of parcels to be palletized.

    A PAO contains a progress status:

    • Status 1-Not validated
    • Status 3-Partial validation
    • Status 4-Validated

    Picking Order (PO)

    A Picking Order represents a preparation load attached to a wave.

    It is comprised of a set of output movements concerning one or several POs. It is sorted so as to provide an optimum preparation path.


    The parameters used to split and sort the POs of a wave are contained in:
    • the Preparation Method Table
    • the Travel Sequence Table
    • the Preparation Field Table

    An additional PO can be requested within the framework of a DO in preparation with or without prepacking (outside of a wave) if available stock enables those shortages recorded upon preparation start to be covered.


    A PO contains a progress status:
    • Status 1-Not validated
    • Status 3-Partial validation
    • Status 4-Validated

    Source

    The origin is used to classify products according to their places of production. Known from the creation of the inputs, the code of origin (defined in a table) is a characteristic of the stock object.

    Incomplete object

    The notion of incomplete object occurs at various operating stages of Warehousing in order to reserve a special treatment to the pallets whose CU quantity is different from the palletization standard defined as the default container in the product container record.


    The information '% incomplete container' of the product container record is only used when searching for locations (input, transfer and merging). It represents the percentage below which an object is considered to be incomplete:
    • If the value of this setup is 100%, only those objects whose quantity is equal to the palletization standard are not considered to be incomplete.
    • If the value of the setup is 0%, the objects are never considered to be incomplete.

    The storage type, linked to the location, makes it possible to prohibit storage at certain object addresses that do not comply with the palletization standard, irrespective of whether the quantity to be stored is lesser or greater than the standard.

    The output mode, linked to the product, includes a setup used to prohibit the output of incomplete containers from the reserve, thus making preparation easier and saving the operator having to complete this pallet from the picking. These objects from incomplete pallets are then only used for the replenishment of the picking area.

    Automatic palletization

    Automatic palletization is the function used to automatically palletize a list of parcels pending palletization (in status 6). The palletization algorithm is the one used in prepalletization

    The system generates a Palletization Order (PAO) comprised of parcels to be palletized in SUs.

    Multiple picking

    The multiple picking function, only available in the Premium version, is used to manage several picking locations for a same Product + Container pair in a site.                                   A maximum number of 5 picking locations can be created for a Product + Container pair.  

    All the picking locations of a product with the same container (UCU, level-5 container) must have a picking storage type, either with differentiated stock objects, or undifferentiated stock objects.

    The output mode (multi-picking flag) assigned to the product conditions the multiple picking management and the possibility to create several picking locations.                                                                                                                                                                                                                                                        

    A 'O' priority order is assigned by default to the creation of these locations. This priority order can be set up, in the product record or in the location and picking location records, at the various picking locations assigned to a product.      

    This parameter is used to sort locations by order of priority for the output addressing management. Nevertheless, the output addressing will only be impacted if the picking mode assigned to a DO has the multiple picking type.

    The input addressing is not impacted by the assignment of these orders of priority.         

    The parameters linked to multiple picking are the following:

    • Preparation method table
    • Output method table

    Picking Pivot

    The picking pivot function is characterized by the use of picking locations that are not assigned to a product (setup of the storage type) and that can be assigned or not to a depositor.

    This function, when it is activated for a product (via the output mode), makes picking possible from picking locations in CUs, assigned upon launching the preparation of the DOs according to the wave requirements. Nevertheless there should be no so-called "classical" picking location assigned to the product for the CU container.

    The picking pivot locations are always replenished in complete pallets from the reserve; this replenishment can cover the requirement of one or several DOs depending on the output mode. Similarly it is possible to replenish a picking pivot location within the framework of one or several waves.

    The picking pivot tab of the stock configuration is used to define the addressing rules when selecting the picking pivot locations to be replenished.

    The parameters linked to the picking pivot are the following:

    • Storage type table
    • Output method table
    • Stock configuration

    Prepacking

    Prepacking is the definition by the system, upon starting preparation, of the types of parcels to be composed and their content.

    This function is triggered via the picking mode associated with the DO header.

    The purpose of the algorithm is to constitute the minimum number of shipping parcels for a DO while meeting the following constraints.

    The algorithm takes into account:
    • the grouping constraints
    • the size constraints
    • the weight constraints
    • a parcel filling margin
    • the requirements related to the parcel range being used
    • the concept of "Big Parcel" and the minimum filling threshold granted

    The parameters linked to prepacking are the following:
    • Group table: Group/Regrouping/Range
    • Range table of the various shipping parcels: Range/Description
    • Parcel type table: Range/Type/Dimensions/Volume & max Weight Surface Equivalent/Big Parcel Type
      Linked to the previous table, for a given range, there can be 1 or several types of parcels.
      The notion of 'Big Parcel' is used to assign a minimum filling rate to this type of parcels, unlike small parcels.
      There can also be physical differences between the handling equipment used to prepare big and small parcels.
    • Preparation Area Table: A preparation area regroups one or several stores.
      It is used for the splitting of the Picking Orders and the routing of the print-outs of the preparation documents.
      The sort criteria for the POs are the DO nos. preparation area and routing within this area.
    • Product container table: if an output movement is dispatchable as is, the parcel type defined in this table for the movement container will be used. If the parcel type is not defined, it can be found in the container table.
    • Container table: if an output movement is dispatchable as is, the parcel type defined in this table will be used (after table above: product container). If the parcel type is not defined, the parcel type for output movements dispatchable as is set up in the output configuration will be used. 
    • Default parcel range: The system uses the value of this setup to package a product for which it is not possible to determine a parcel range according to the standard rules.
    • Strict sequence: Using this parameter informs the system that it must perform the prepacking while strictly complying with the sequential nature of the picking addresses.
      In that case, there is only one parcel available for the packing that is being carried out.
      Note: Using this setup can only increase the number of parcels that are being constituted.
    • Single-parcel product: Forcing a single parcel product makes it possible to minimize the risk of randomizing the references in the parcels.
      The system opens a new parcel when it is not possible to prepack a whole movement inside the same parcel.
      The movement is single-parcel if there is a parcel with a sufficiently large size to pack it.
    • Modulus packing: If an output movement, expressed in CUs (level 5), corresponds to a quantity being a multiple of a level 4, 3, or 2 container, the system creates output movements by dividing this quantity by the corresponding equivalent number in CUs of the container (modulus) plus possibly a balance in CUs.
       For that purpose, the level 4 and 3 containers of the product are sorted in decreasing order by the system.
       If this level 4 or 3 container is not dispatchable as is, the prepacking algorithm takes account of its dimensions and weight. This function makes it possible to prevent the splitting of CUs from a box (level 3) or sub-boxes (level 4) among several parcels.

    Prepalletization

    Prepalletization is the definition by the system, upon starting preparation, of the types of SUs to be composed and their content. This function is based on two steps: prepacking (parcel composition), followed by palletization (SU composition from the prepacked parcels).

    This function is triggered via the picking mode associated with the DO header.

    The purpose of the algorithm is to constitute the minimum number of SUs while meeting the following detailed constraints.

    The algorithm (2nd step: palletization) considers:
    • the grouping constraints
    • the size constraints
    • the weight constraints

    The parameters linked to the prepalletization are:

    • Parcel type table: SU group / Default SU type / Palletizable as is / Type of SU shippable as is. If a parcel is palletizable as is, the type of SU palletizable as is defined in this table will be used. If the parcel type is not defined, the SU type shippable as is and set up in the output configuration will be the one to be used. If a parcel is not palletizable as is, the default SU type defined in this table will be used to palletize this parcel. If the parcel type is not defined, the SU type set up in the output configuration will be the one to be used.
    • Preparation Area Table: A preparation area regroups one or several stores.
      It is used for the splitting of the Picking Orders and the routing of the print-outs of the preparation documents.
      The sort criteria for the POs are the DO nos. preparation area and routing within this area.
    • Container table: if an output movement shippable as is, is also palletizable as is (flag at container level), the SU type defined in this table will be the one to be used to palletize this movement. If the parcel type is not defined, the SU type shippable as is and set up in the output configuration will be the one to be used.
    • SU type table Useful volume / Surface equivalence / Maximum weight
    • Single recipient SU, single-DO SU defined in the DO header.

    Picking Proximity

    This location search mode on input is used to locate the reserve pallets in the nearest proximity to the product picking location. The reserve area thus formed is often called "Advanced reserve".
    This algorithm excludes any other search mode and is only run inside a store.
    The parameters that enable this management are defined in the store table, they are independent from the pairs (product code/picking address).
    A picking reassignment can thus be carried out very simply without the setup having to be modified.
    An additional parameter, linked to the level 1 container (pallet) of each product, makes it possible to limit the number of objects in this store.

    glossaire_proximite_picking.gif

    Note: The numbered arrows mention the order in which the addresses should be explored. The (inverted Gaussian) curve represents the probable presence of a reserve pallet based on the distance with respect to the picking location.

    This functionality is available from the G2 version.

    Picking replenishment

    Replenishment during preparation

    Two types of replenishment can be triggered automatically by the system during the launch of a wave preparation. Their purpose is to provide for the stock coverage required for the picking operations.

    • Necessity replenishment:
      This replenishment mode is used to provide for the necessary picking stock coverage during a wave for all products concerned.
      This mode does not take into account the replenishment threshold defined for each picking location. A replenishment order will only be triggered if the quantity to be picked is greater than the available stock of the picking location.
    • End-of-wave replenishment (preventive):
      A parameter for the output mode, linked to the product, can be used to trigger the replenishment if the picking stock at the end of the wave is less than the threshold defined for each location.

    Warning: Only those products contained in the wave will be replenished via the end-of-wave replenishment.

    Replenishment triggered by the user

    • Automatic replenishment
      It is carried out for a store and a picking location range that correspond to the products to be replenished.
      The "systematic" (or "stuffing") or "threshold" replenishment type can be requested if the available stock is less than the threshold defined for the picking location.
    • Selective replenishment
      It is carried out upon request from the operator, for a designated product, even if the available stock exceeds the threshold defined on the picking location. The operator then selects the stock objects that they wish to use for the replenishment.

    Operating principle (common to the 4 procedures)

    • Unlike the available "Reserve" stock, that does not includes the pending input movements, the available "Picking" stock used as the basis for the replenishment is provided by the formula:
      Physical stock + Pending input movements - Pending output movements or Stock objects – Pending output movements.
      Available space = Max. qty of the location – Available qty
      Qty to be replenished: Available space + Replenishment requirement
      It is the maximum quantity to be replenished that is brought back to the maximum capacity of the location or to the selected object in order to avoid removals from incomplete pallets or the multiplication of objects to be selected.

    • The replenishment movements generated by the system may not be physically carried out. A setup is used to trigger only replenishment movements. "always executable", which means that the pending output movements are systematically removed from the available space.
    • When the system needs to perform a replenishment movement, it tries to perform it either from a higher-level picking (cascading replenishment) or from the reserve (to be set up at the level of each location). The setup is available depending on the version.
    • The search for stock objects for replenishment purposes applies the same management rules as the search on output.

    Carriage Receipt (CR)

    The Carriage Receipt (CR) regroups all the DNs for a same ship-to customer with the same carriage conditions.

    Per validated round, the composition key of the CR file from the DN file is the following:
    • Ship-to customer code
    • Company name
    • Post code for shipment address

    Receipt

    In Warehousing, the physical receipt of a delivery goes hand in hand with an administrative receipt if the EIs (Expected Inputs) are managed.

    There are two receipt modes:

      • "Standard": upon validation of the received quantities, the administrative receipt (AR) is closed. The latter moves to status 4 - Validated.
      • "Drip and drop": upon validation of the received quantities, the administrative receipt (AR) remains open. The latter remains in status 2 - Pending.

    The receipt contains a status making it possible to know its progress.

      • Status 1-Declared
      • Status 2-Pending
      • Status 3-Partial validation
      • Status 4-Validated

    There are two functional receipt procedures concerning the portable receipt procedure (VTRCP):

      • Receipt by supplier barcode: in this mode, the user selects the AR, scans the supplier barcode that identifies an EI line, scans the product (product code or EAN code) and finally enters the information relating to the quantity and the container.
      • Receipt by supplier EAN code: in this mode, the user scans the supplier EAN code that identifies both a product container and a supplier. The user then only needs to choose the EI line among those selected by the system. The user finally enters the quantity information.
      • Receipt by support number: in this mode, the user scans a support number. The user then only needs to choose the EI line among those selected by the system. The user scans the product (product code or EAN code) and ends by entering the quantity information.

        Note: At site level, tab "Handheld procedures", there is a dropdown list "Default method" to select the receipt procedure submitted by default in the RF receipt function.

    Drip and drop receipt

    The validation of receipts in "Drip and drop" mode is used to receive goods over several receipts while staying on the same administrative receipt.

    Unlike a normal receipt mode, after the received quantities have been validated, the administrative receipt remains open (Status 2-Pending).

    Within the framework of an administrative receipt, the two receipt modes "Standard" and "Drip and Drop" are available. It is thus possible to switch from a "Drip and Drop" mode to a "Standard" mode. On the other hand, it is not possible to do the opposite because this would mean that a new administrative receipt would have to be created.

    The parameters "Close the line" and "Close the input" of the receipt mode act like a balance management. This means that the absence of balance management is not compatible with the "Drip and Drop" receipt mode.

    Should an administrative receipt need to be closed further to a receipt carried out in "Drip and Drop" mode, the receipt will have to be validated with lines whose quantities are null.

    Search for locations on input

    The location search principle is based on the adequacy between parameters linked to the input request and the product and their counterparts relating to the location, while complying with the management modes specific to the two entities.

    glossaire_recherche_entree.gif

    Should the search fail, and based on the authorizations defined in the input mode, the system downgrades one or several parameters (concept of sequence or equivalence) in order to widen the possible locations.
    This downgrade makes it possible to keep an optimum value to the preferred criteria for as long as possible.

    Product search on output

    The product search principle is based on the adequacy between parameters linked to the output request and the product and their counterparts relating to the stock objects, while complying with the management modes specific to the various entities.

    glossaire_recherche_sortie.gif

    The product output priority is set up in the output mode. It is used to sort the stock objects that can be chosen to meet the request.

    Regrouping of movement in RF

    This RF picking feature is used to provide the operator with grouped output movements sharing the same characteristics.

    For example, instead of asking the operator to pick 1 box and then a second box and a third identical box for the same location, the operator will only be asked to pick 3 boxes at once.

    Use:
    the movement grouping option is only available in the RF picking function (VTPKO). Movements on the same location and with the same characteristics are grouped.
    If the operator cannot pick the total quantity, he/she can enter the quantity used and the system will automatically load this quantity onto the various output movements (based on the sorting order of movements in the PO).

    Setup:
    At site level ("Portable procedures" tab), the regrouping can be activated.
    At the picking mode and storage type level, various grouping criteria can be activated.

    Rules for movement POs:
    output movements are grouped based on the same characteristics:
    • the location
    • the product
    • the source movement container (ORICTR) + the homogeneous container (HMGCTR) + the homogeneous quantity (HMGQTY)
      • you would never ask for 1.5 pallet but always for 1 pallet and then 0.5 pallet.
    • the movement container (CTR) - the one requested on the DO line
    • the lot number if the DO line requires a lot number or if the 'Lot swap' option in disabled.
    • the reservation number
    • the support number
    • the stock nature
    • the Customer or DO number or DO line (optional criteria defined at the picking mode level)
    • the stock object number (optional criteria defined at the storage type level)
    • the FIFO date (optional criteria defined at the storage type level)
    Rules for parcel POs (prepacking) and SU (prepalletization):
    grouping is only available for parcels that cannot be shipped as it is.
    Besides the criteria already defined for the PO movement, the parcel number criteria is added.

    Rules for kit POs:
    There is no grouping on these PO types.

      Reintegration

       

      Reserve

      Reintegration to the reserve of the picking objects is obtained by simply transferring picking objects to a reserve location. The user only needs to specify the palletization.

      Reintegration for non-delivery

      The system performs the automatic reintegration of non-delivered parcels or quantities when shipments are canceled in the store defined for this functionality in the site table.

      These reintegrations are carried out via adjustments on creation with a movement code of automatic adjustment type.

      Reorder balances

      Definition of a reorder balance: Following a reorder order (RO), only a part of the SO can be transferred to the destination picking location. The remaining SO part (in the RO location of origin), considered as incomplete, is then referred to as "Reorder balance".

      Readdressing procedure of the reorder balances:
      The purpose of this procedure is to keep an optimized stock by attempting to automatically readdress the reorder balances that appeared following the creation of a Reorder Order (RO).
      The readdressing of these balances consists in automatically transferring these incomplete SOs to the reintegration store defined on the store of the destination picking location of the RO.
      This readdressing takes place providing:
      - the flag "Incomplete object transfer" of the stock configuration is activated.
      - the flag "Readdressing" of the store of the destination picking location is activated.

      Like for any automatic transfer, depending on the "Transfer mode" specified on the product record, this balance transfer will be of type "Normal", "Merging with accrual" or "Merging without accrual".

      Notes:
      - In the event of a "normal" type transfer", it will only be authorized if the reintegration store is different from the one where the reorder balance is located.
      - If it is impossible to readdress the whole balance to the reintegration store, no transfer is performed and the balance remains in its initial location.

      Reservation

      The concept of reservation is used to assign upon receipt or at any moment on the stock, a number specific to one or several stock objects.
      This information (15 alphanumerical characters) makes it possible, for instance, to manage all the products of a DO intended for a specific customer.

      A reserved stock can only be used for the preparation of a DO line if the latter contains the same reservation number.

      Depending on the setup (see Output configuration), it is possible to use the notion of Reservation in two different ways:
      • Non-exclusive reservation:
        If the DO line mentions a reservation number, the corresponding reserved stock is then considered to be the priority. If the quantity available for this stock is not sufficient, the system processes the balance of the request with the non-reserved stock (i.e. : blank reservation no.).
      • Exclusive reservation:
        If the DO line mentions a reservation number, the corresponding reserved stock is then considered to be exclusive. If the quantity available for this stock is not sufficient, the system generates a shortage.

      It is prohibited to reserve or store stock objects bearing a reservation no. in a picking location.

      Serial (no.)

      The serial no. is a normally unique identifier that characterizes each unit of a product to be distributed. This identifier enables a very thorough traceability since it is used to know the ship-to customer and the supplier of a product unit, and not of a stock object.
      Some sectors of activity use it frequently, even systematically: let us mention for instance the telephone sector where each telephone is identified, the sector of spare parts in the automotive industry, and more generally speaking, the products with a very high added value.

      In Warehousing, 2 modes can be used to manage the serial nos.:
      • Traceability and full follow-up:
        products are entered to stock with a serial no. by the unit.
        On output, the serial nos. are also scanned or entered, and the system runs a match between the serial no. in stock and the output serial no.
        In this way, for a given serial no., the IS is able to know by whom it has been procured and when and to which ship-to customer (DO) it has been distributed.
        This method means that, either the suppliers are able to transmit the product serial nos to the IS, or these serial nos. have been scanned or entered at a given moment of their receipt.
      • Output traceability:
        another mode requiring lighter logistic operations is used to scan or enter the serial nos. only on output.
        Thanks to this method, it is possible to know to which ship-to customer the serial no. has been distributed.

      For enhanced flexibility, Warehousing GX accepts duplicate serial nos. for a same product code when they have not been entered at the same time.
      A blocking uniqueness check is implemented on entry of the serial nos. of a product of an input; on the other hand, concerning several separate inputs, duplicates are authorized but the operator is informed of them.

      These two management types are set up in the management of the input and output modes.
      glossaire_serie.gif

      Site

      Independent and homogeneous management unit for all concepts mentioned. In IT terms, the site is the main access key to all the Warehousing files and tables.

      The site code is composed of 2 alphanumerical characters.

      There are two types of data related to site: the 1st is defined in the general structure of Warehousing (GESFCY Site function) and the 2nd is defined in the general setup (GESSIT Site function) used to specify the logistic setup.

      SSCC no.

      The purpose of the management of the SSCC numbers (Serial Shipping Container Code) in Warehousing GX is to trace the shipped logistical units by means of a standardized code as per the EAN Gencod standard.

      This code is made of:
      - an identifier (00)
      - an extension criteria
      - a prefix (7 characters) corresponding to the company issuing the SSCC
      - a unique sequence number (9 characters) identifying logistics units
      - a control character (check digit)

      This SSCC no. is set up for each Warehousing depositor, and when it is activated for a given DO, it can be automatically generated for parcels and SUs: the generation for SUs makes it mandatory to use the SSCC for parcels.

      Then the SSCC assignment can be triggered by the following events:
      - wave launch with prepacking
      - creation of parcels with declarative load preparation
      - creation of Shipping Units

      Some operations can be performed by entering the SSCC no. of the units, for instance:
      - load preparation (in prepacking mode)
      - palletization
      - control upon loading.

      The parameters linked to the SSCC management are:
      - the customer file management
      - the depositor management
      - the output setup
      - the DO header management

      Lot swap

      The Lot swap feature gives an operator the possibility to perform a RF picking of a lot, different from the one suggested by the system (provided that the lot is not mandatory on the DO line).

      If the operator cannot find the requested lot in the location (no stock on the lot or complications when searching for the physical lot amongst the ones in the location): the operator can pick another lot (under certain conditions).

      Use:
      lot swap can only be performed in the RF picking function (VTPKO). It can be applied to an output or replenishment movement.
      All location types are concerned, except from picking with undifferentiated stock objects.
      Lot swap consists in using another lot from a stock object located on the same location and for the same product as the initial product.

      Setup:
      at the storage type level, the lot swap and movement split options can be authorized.

      Rules:
      lot swap can be applied to an output/replenishment movement when
      • the DO line does require a particular lot
      • the picking location storage type authorizes it
      At the level of the stock object where the swap is applied:
      • the object must be in the same location and used for the same product
      • it must comply with the same standard controls (characteristic required on the DO line, homogeneous level, etc.)
      • in the case of a replenishment movement, it must not be in input progress.
      Case of a single lot DO:
      • if at least one output movement has been picked on this line, the lot swap is rejected on all other movements awaiting picking.
      • if no output movement has yet been picked, the lot swap is allowed but will apply to all movements. Si this is not possible (not enough stock on the other lot), the lot swap will be rejected.

      (Delivery) round

      In the application, a "Shipment Round" features the content of a truck, the latter having to be made of a set of full or partial DOs to be delivered.

      The components of a round can be all active DOs, in other words, those included between status 2 and status 8 (pending shipment).

      The shipment round can be multi-depositor (two depositors can deliver the same ship-to customer).

      A shipment round is identified by a round no., a round Date, a round Time, a Carrier code and a transport method.

      The Dock, generic round information is optional and it depends on the implemented setup.

      Inter-site round

      An "inter-site" shipment round is a shipment round whose destination is not a customer but another site.

      It is specified upon creation of this shipment round whether or not it will be an "inter-site" round, and its destination site is also mentioned. The goods are not unloaded on the destination site. On the other hand, it can be consolidated with DOs of the current site within a single final shipment round. It can also be shipped again to a third site or else returned to its original site: it is then called a return "inter-site" round. 

      All DOs contained in an "inter-site" round are said to be "pending transfer" upon shipment of said round. The delivery documents corresponding to this type of round are printed if the carrier set-up requires it, both for the CR and the CN, and if the output configuration set-up requires it as well for the DN.

      Stock transfer

      A transfer is characterized by a set of transfer movements, each representing a physical movement of a stock object from one reserve location to another reserve location, or from a picking location to a reserve location.

      Moving an object from a reserve location to a picking location or from a picking location to a picking location is made possible by a replenishment movement.

      These two case are materialized by a stock transfer movement with a different movement type.

      The transfer movement type assumes one of the following values:
      • Normal
      • Merging with accrual: transfer to a stock object to end up with one only
      • Merging without accrual: transfer to a stock object to be linked without accrual
      • Transfer entire container: transfer of related objects
      • Necessity replenishment: transfer to a picking location generated by a wave launch while the stock available on this location was not sufficient.
      • Preventive replenishment: transfer to a picking location generated by a wave launch or a user.
      • Merging of flow transfer: transfer to a splitting location generated by the system upon a wave launch of type merging of flows
      • Merging of flow replenishment: transfer to a picking location generated by a wave launch of type merging of flows.

      Warehousing allows the management of external stores (surplus storage, for instance) or remote stores. Beyond a fixed threshold, a functionality automatically triggers a transfer of goods to this area, these transfer movements are of normal type.

      2-phase transfer

      A transfer movement can be validated in 2 different ways:

      • Normal mode: the user validates the whole movement once.
      • 2-phase mode: the user validates the removal from the initial location (1st phase), then the relocation to the final location (2nd phase). Following the relocation, the transfer movement is validated.

      The 2-phase transfer operation is carried out via the Unit validation in CS mode or the transfer function in VT mode.

      The normal mode validation is conducted in CS mode only via the Unit validation and mass validation functions.

      2-phase transfer operation:

      The principle is that the logical stock must follow the physical stock. Thus, following the removal, the removed stock object is no longer located in the initial location, but in a temporary location of "2-phase transfer" type. Depending on the user (linked to a resource or not) performing this removal, this temporary location is the one defined on the resource or the first location of "2-phase transfer" type being available (i.e. not already used for another transfer). Following the relocation to the final location, the stock object will be located in said final location.

      Here is a table presenting the evolution of the stock, of the transfer movement during a 2-phase transfer.

      Process

      Initial loc.

      Temporary loc.

      Final loc.

      Mvt status

      Possible actions

      Initial view

      Stock = OS1

       

      Stock = empty

      3-Addressed

      - Validation
      - Take
      - Cancellation

      Phase 1: take

      Stock = empty

      Stock = OS1

      Stock = empty

      7- In process:

      - Relocation

      Phase 2: deposit

      Stock = empty

       

      Stock = OS1

      8-Validated

      - None

      Note: the stock decrementation in these (initial and temporary) locations is performed via automatic adjustments.

      Unit

      The Consumer Unit (Level 5 of Warehousing) is the undividable (minimum) unit for stock counting. It is generally used as the reference unit for the interfaces between the commercial management system and Warehousing.

      It is the only mandatory container for each product.

      UL

      The Logistic Unit is the container in which the output request is expressed. It may equally correspond to containers of levels '1', '2' (available depending on the version), '3','4' or ‘5’.

      Shipping Unit (SU)

      The Shipping Units (or shipping loads) can be used in declarative load preparation, prepacking and prepalletization mode.
      They are used to manage the palletization of the Warehousing parcels. These SUs are single-DO or multi-DO, single-recipient or multi-recipient. They are formed after parcel validation.

      The declaration of SUs for a DO is set up at the level of the current depositor in the output configuration, and at the level of each DO. Thus, this palletization phase can be ignored for some flows.

      Generally speaking, the palletization procedure is carried out via a handheld procedure. It reflects what can occur on a fixed screen.

      Wave

      A wave is the entity that regroups the DOs launched simultaneously for preparation.

      A wave MUST be single-depositor.

      A wave is associated with a set of ROs (Replenishment Orders), POs (Picking Orders) and possibly parcels to be composed (use of the prepacking module).

      A wave is single DO type, either with or without merging of flows.

      A wave is the grouping of a set of DOs for a given depositor that will be launched simultaneously for preparation. The term "preparation wave" is usually referred to. This concept presents a twofold advantage: it is used to optimize the preparation process by authorizing the constitution of multi-DO picking orders. It is also used to pilot and follow-up the preparation and shipping activities.

      Traditionally a wave corresponds to a grouping of DOs to be shipped simultaneously and (or) whose preparation processes are homogeneous.

      The various statuses of a wave are:
      • 1 – Pending launch
      • 3 – Pending transfer
      • 4 – Pending 2nd phase
      • 5- Completed

      Generic wave

       A generic wave is defined by a code and a title. It regroups the various criteria that will enable the DOs on wave to be selected.

      A generic wave is like a "traditional" wave: either it only contains DOs managed with merging of flows or only DOs that are not managed with merging of flows.

      A global memo code can be defined with selection criteria on the DO header table and associated with the generic wave.

      It can be single or multi-DO, with a limited or unlimited load. It is possible to authorize the DOs corresponding to the selection criteria to be added to an already existing wave that has not been launched yet and has the same generic wave. It is given a priority number, O being the highest priority and 999 the lowest priority.

      The "Automatic launch" flag can be checked for a generic wave, in other words, the generic wave will be taken into account upon the automatic launch of waves. In the wave creation screen, it is also possible to create a wave manually and then to flag "Automatic launch".

      There are two tasks:

      - a task to perform the "creation of automatic waves" that will create waves based on the active generic waves, and following their order of priority, then the alphanumerical order of their code, by selecting for each wave the DOs that correspond to their criteria. In case the criteria are identical for the DOs, the latter are selected first based on the fact that they are flagged urgent or not, then according to their service priority level, and finally according to the DO no. (from the smallest to the biggest).

      - a task to perform the "launch of automatic waves", that launches either only those waves associated with a generic wave and that are flagged "Automatic launch" by checking "waves generated automatically", or only those waves not associated with a generic wave and that are flagged "Automatic launch" by checking "waves generated manually".

      These two tasks can be launched manually or in batch.

       

      Preparation area

      A preparation area is a logical group of stores presenting common characteristics:

      • Same geographic location
      • Same storage type
      • Same preparation activity

      The preparation areas are defined in the preparation area table.

      A store can be assigned to a preparation area in the store table.

      The preparation areas are used to:
      • Constitute independent workloads.
      • Set up the maximum load of a PO according to the area.
      • Provide for the routing of the preparation documents to various printers.