6. Supply Stand-alone Objects
Several supply objects are not part of an order flow but are used for stock management. Where some objects can be either used as part of a flow, or as stand-alone, they have been included in the section on order flow objects (see previous entries).
6.1 Real Consumption Report
Menu Mapping: Warehouse > Warehouse Management >Real Consumption
Preceding documents
N/A always from scratch
Successive documents
Delivery Order type Consumption (OUT-CONSO)
Statuses of Consumption reports
Draft –initial status of report, modifications possible
Closed – Document has been processed via the “Save & process” button, stock has been consumed from stock location and a Delivery Order (type Consumption) will have been created and processed to Closed automatically.
Cancelled – Document has been Cancelled. No more modification can be done. No stock moves.
Lines/Products specificities
Products can be added as per usual methods (Add, Add multiple & import) but also with a specific one “Copy all”.
If using Add (single product) button functionality, if magnifying glass is used to display list of product, the quantity displayed for each the products will select the quantity for the location selected in the header of the Real Consumption report.
For import functionality an export/import file can be generated from a Closed Incoming Shipment “XML export” and this is the exact same format as needed for the import into a Real Consumption report. This functionality was developed for the case where a Coordo creates an FO, and due to the push flow, project can receive the goods into their instance (via IN) but want to send the goods on to be consumed by an external location, so can do this easily by exporting from the Closed IN and then importing this file into a Real Consumption report (see Jira ticket BKLG-33/UFTP-309. However, with the last developments some updates have been done on the export/import file directly generated from the RCR screen which has not been reflected on the export from the Closed IN (last dev on US-6650).
An additional method for adding products to a Real Consumption Report is the button “Copy All” and this will fill the Real Consumption Report with all products and their details (quantities, batch numbers and expiry dates) which are present in the selected location. If this button is not used, user must enter other information (batches etc) manually.
While the “Indicative Stock” is displayed after using this button, the “Qty Consumed” is now set to “0” by default to avoid users consuming/ emptying all the stock by mistake (as it happened few times in the past).
Batch and Expiry Date mandatory products must have their relevant information present. Assets should have Asset reference present also.
If the quantity entered in Qty Consumed field is greater than quantity of indicative stock, system will flag this but not block if user decides to continue therefore the UR will limit the use of this function (US-2482).
Updates from successive documents
N/A
Direct Reports / Exports
Consumption report – PDF
6.2 Initial Stock Inventory
Menu Mapping: Warehouse > Inventory Management > Initial Stock Inventory
Preceding documents
N/A always from scratch
Successive documents
N/A
Statuses of Initial Stock Inventory
Draft – Initial status of document, modifications possible, possible to cancel, Confirm Inventory button can be used to progress Initial stock inventory to Validated status
Validated – no modification possible but still can be Cancelled, “Confirm Inventory” button can be used to close the Document.
Done – no modification possible. In this status, product lines have been added to stock location.
Initial Stock Inventory Functionalities
Initial Stock Inventory (ISI) is meant only to be used at the initial stages to load products into a stock location. An ISI will only add quantity for product in a stock location, it will not reduce quantity. Therefore, a second Initial Stock Inventory should not be created for a stock location to adjust stock levels. Any adjustment of stock levels should be performed via a Physical Inventory. An ISI exists for the main purpose of migration of stocks at the beginning of a deployment or to load a new location with new products.
When using the import file, some checks are done on product and Location (inactive, virtual or external locations cannot be used; checks is done exact location naming).
Lines/Products specificities
Batch number and Expiry date products should have this information added.
Batch numbers will be created directly from manually filled values of fields.
Updates from successive documents
N/A
Direct Reports / Exports
Stock Initial Excel Export
6.3 Physical Inventory (US-3501)
Menu Mapping: Warehouse > Inventory Management > Physical Inventories
Preceding documents
N/A always created from scratch
Successive documents
N/A
Physical Inventory functionalities
Physical Inventory can be used to adjust quantities for one or more lines (products), this can be to increase or decrease quantity or adding missing products. During the process of PI a Discrepancy sheet enables to see the difference between the data entered after counting manually and the information in the system.
This functionality has been entirely redeveloped with US-3501 in UF7.0 replacing the initial OpenERP default one. Please refer to this ticket for detailed initial specifications.
Statuses of Physical Inventory
Draft – Initial status of document, definition of PI scope (selection location and products), modifications possible, possible to cancel, “Generate Counting Sheet” button can be used to progress document to “Counting” status. Possible to select with more or less detailed “Counting sheet” (with or without prefill BN/ED and/or with or without product with 0 stock).
Counting – new tab “Counting sheet” is generated and display the previously selected products with or without BN/ED (-without being called “Blind count”). Modification possible on BN/ED, “Quantity” needs to be filled and new product line can still be added. Update can be done by import. Clicking on “Finish counting” to progress document to “Counted”. Possible to Cancel.
Counted – Modifications still possible and Cancellation as well. Clicking “Generate Discrepancies” will generate an intermediate pop up to highlight the missing expected lines (with quantity not filled). User will choose whether to ignore these highlighted lines (i.e.: no change for these lines, they won’t be included for the rest of the PI process) or to set them to “0” (so that they are taken into account for the rest of the PI process).
A new tab “Discrepancy report” is created and the status remains “Counted”. Updates can be done on “Adjustment type” or “Comment” only (import possible)
Still possible to “Cancel Inventory” or to “Re-Generate discrepancies” (will refresh the data in case the PI remained untouched in this same status for a while).
Clicking on “Finished” will set the document to “Validated”.
Validated – Modifications can be done on “Adjustment type” or “Comment” only (import possible). At this stage “Adjustment type” has to be filled to process forward.
Still possible to “Cancel Inventory” or to “Re-Generate discrepancies” (will refresh the data in case the PI remained untouched in this same status for a while). Also possible to “Recount” (will set back the status to “Counting” and remove the “Discrepancy report” tab.
Click “Confirm Inventory” to set the document to “Confirmed”.
Confirmed – A new tab “Posted Inventory” is created. At this stage stock movement are done.
On the new tab “Posted Inventory” no modification is possible. However, the “Comment” field still can be edited in the “Discrepancy report” tab.
Clicking on “Close Inventory” will Close the PI for good.
Closed – No more modification nor Cancellation can be done.
Lines/Products specificities
It is only possible to have 1 location per PI.
When selecting product for the Counting Sheet (CS), use has the option to select product that are “currently in Stock” or “Products with recent movement in the location” (stock move from 1 to 12 months – user will select the requested duration in months) thanks to a first drop down list filter. Then user can select all the product in the Location, or per Familly or per Product List or per CC/CS/DG.
Once the products are selected user will have the option to generate the CS with prefilled BN/ED details or without prefilled BN/ED details (in which a default of 3 blank line per BN/ED product will be displayed in the blank CS). In addition, just before generating the CS, user can chose to display “only lines with stock different than 0” or all the BN/ED including the one at 0 (i.e.: product which had previous stock moves).
At CS import some checks are done on product existence; product attributes mandatory or not; uniqueness of combination line number and product…
Products are displayed by alphabetical order
At generation of Discrepancy report, more checks are done for product with no information for “Quantity counted”. User will have to decide whether these products should be Ignored (won’t be part of the PI) or Counted as 0.
The Discrepancy report will compare the Quantities counted (physically) vs the theoretical stock in UF. No change on quantities can be done at this stage. Adjustment type is the only mandatory field. “Comments” field can be updated up to status “Confirmed”.
The “Recount” option at status “Validated” can be redone as many time as necessary.
Updates from successive documents
N/A
Direct Reports / Exports
Stock Inventory
Stock Inventory Excel Export
Counting sheet Export/ Import
Discrepancy sheet Export/ Import
6.4 Monthly Consumption Report
Menu Mapping: Warehouse > Reporting > Consumption Reports > Monthly Consumption
Report for which dates selected (period from & period to) must reflect first and last day of given month(s) and from date should be before to date. Default period to value is last day of current month but can be changed.
Default and only possible location is for whole instance, so reflects all consumptions of instance, including all internal locations.
Products can be added as per standard methods (Add, Add multiple, Import)
Value AMC cannot be adjusted as pulls from AMC of product according to transactions.
The AMC value is based on the total quantity of the product which has left the instance via a consumption report or outgoing deliveries (both quick (OUT) and full shipment (Pick/Pack/Ship) processes). Any quantities of the product which have left the instance due to loan, donation, loss or discrepancy will not be included in this calculation. If any of the products have been received (returned) back in (via incoming shipment) to this instance within this period, this quantity will be deducted from the total consumption figure.
Value FMC can be filled manually / via import. Once validated, FMC cannot be modified unless validated checkbox is unticked. When FMC is validated, this value will be used by other calculations (e.g. Replenishment Rules)
Historical Consumption Report
Report for which dates selected (period from & period to) must reflect first and last day of given month(s) and “from” date should be before “to” date. Default “period to” value is last day of current month but can be changed.
According to period parameters set, one or more months will be displayed.
For calculation either Real Average Consumption (default) or Average Monthly Consumption can be selected.
Real Average Consumption is calculated using the total of all stock which left the instance due to a Real Consumption report. Unlike AMC it does not consider any other picking/transport documents which take products out of the instance.
“Source Location” field will only display internal locations. “Destination Location” field will only be displayed when “RAC” is chosen as Consumption type and will enable to also select External Consumption Unit.
As opposed to the “Source location”, the “Destination location” is not a mandatory field.
By default all products in database will be displayed, but products can be pre-filtered using Lists or product nomenclature filters (main type, group, family, root)
6.5 Claims (US-3516)
This Claim functionality has been upgraded mainly with the synchronisation option with the recent development done on US-3516 ( however, some adjustment still need to be done to cover all the possible test cases – and that’s why user might still experience some unexpected behaviour that might need corrections)
Claims can be created by the following
- From an Incoming Shipment (Available/Available shipped): menu Warehouse > Incoming Shipment
- From an Internal movement (Available) => menu Warehouse > Internal moves
- From scratch (for goods already received into requesting location): menu Purchases > Claim or Orders > Claim
- Created by Synch: if Supplier Claim created at receiving instance
For Claims on goods in the process of being received, Claim can be created from existing Internal move (INT) in status “Available” linked to the processed Incoming Shipment (ie default checkbox in IN “Direct to Requesting Location” was not ticked) or directly from the IN which has to be in status “Available” or “Available Shipped”.
For Claims where the INT or IN has already been processed, or where goods were received directly into Cross Docking, the Supplier Claim must be raised from scratch from either Purchases or Orders menu.
Claims automatically created by synchronization can only be “Customer” Claim with status “Draft – in progress”. They will be created after the synchronization of a Supplier Claim to an Internal/IM/IS partner with status “Validated – In Progress”.
Once the Supplier Claim is “Closed” as well as its Transport document, the synchronization will update the Customer Claim (at other instance) to status “Confirmed”.
Claim Statuses
Draft – Claim has been created from scratch, not yet validated. Still editable and products should be from selected transport document (IN/INT/PICK/OUT). Event can still be chosen
Draft in progress – Claim has been created automatically via synch (only “Customer” Claim can be created by sync)
Validated in progress – claim has been validated manually (if from scratch ) or has been created via IN or INT after selection of Event.
Confirmed – at receiving side Claim is still open but Claim has been closed at internal supplier side (all documents sent or no more expected to be sent)
Closed – Claim is closed (in this instance). No more modification possible. Will be closed manually once all related transport documents are Closed (cannot be Closed before since button to close won’t be available before related documents are Closed)
Types of Claim
There are 3 types of Claim:
- Supplier: raised by the instance which received the goods. Will be sync’d to Supplier once in status “Validated- In Progress”
- Customer: received by the instance which supplied the goods. Can be automatically created by sync in status “Draft- in progress” for Internal/IM/IS flow (will have the reference of the initiating Supplier Claim from other instance).
Can be created from scratch for External Supplier.
- Transport
For Claims created from scratch, in order to create any of these types, there must be a closed picking document of an OUT, IN or Pick. Default source location will be stock, so may need to be modified to LOG or MED and integrity checked. Claim cannot be processed (have event added) if products not available, or for products not relating to chosen picking document or for a quantity greater than picking quantity. Claims which are created directly from an INT or an IN will have the correct data filled automatically. In order to process a claim, an event (how products are dealt) must be added:
Claims can have the following actions/ events:
- Accept
- Move to Quarantine
- Scrap
- Return
- Return (surplus)
- Request missing products/quantities – can only be raised for an Available/Available shipped INcoming shipment.
- As a complement to these options (except for “Return (surplus)”, there is a separate checkbox to activate the option “Replacement expected for Claim”. It is ticket by default for the action “Request missing products/ quantities”. (
For option Accept, no additional movement is created. IN/INT is processed to requested location and Claim is Validated – In progress
Move to Quarantine/Scrap will create an Internal Move to transfer the products to the Quarantine (analysis) location and for the Scrap option, the goods will be sent to the Quarantine (scrap) location and Claim is Validated – In Progress
If option Return is selected, a PICK-Return is created to remove products from instance and send back to Supplier. This Pick can be converted to an OUT. Claim is Validated – In Progress.
A Claim Refund should be created in the Supplier refund
If option Return – Surplus is selected, a PICK-surplus is created to remove products from instance and send back to Supplier. This Pick can be converted to an OUT. Claim is Validated – In Progress.
A Claim Refund should be created in the Supplier refund.
For all of the above the checkbox “Replacement expected” (if from scratch) or “Replacement expected for Claim?” (if from IN/INT) will appear and can be ticked, which will result in an Incoming shipment (IN-replacement) being created. This IN will be linked to the original PO. If this box is ticked in a claim from scratch, the new IN will contain reference to the PO (even if the PO is now closed). If this box is ticked in a Claim raised from an IN, the IN will have reference to the PO and ideally work as a back order (so PO is closed when IN replacement is fully received (or when last BO IN is processed)) . For the Supplier any Claim registered will be displayed in the Supplier data sheet, in the claims tab, along with the status of each claim.
Finally, Request missing products/quantities options will create a new IN with Status IN/XXXXX – missing in Available status (while the initial IN will be Cancelled).
Closing the Claim & synch
As with the current mechanism, a claim must be closed manually. It will be possible for “Supplier instance” to Close their (own) claim flow, having processed any relevant transport documents and then manual action to close claim -if all linked transport documents are closed/cancelled then the “Close claim” button is available and will lead to status Closed. Along with synching of transport documents, the closing of the Claim will be synched to update the claim/documents at the customer side (project/customer claim will become “Confirmed” and will only be “Closed” by manual action on button “Close claim”). Project Claim can be closed (manually) only if all picks, INTs and INs linked to claim are closed/cancelled) .
6.6 Product functionalities in stock transactions
Expiry dates
All products for which the attribute “Batch Mandatory” and / or “Expiry Date Mandatory” have been ticked will be treated in the system as needing this extra information on batch and / or expiry date for all stock movements and inventories in the system.
Where a product has expired, the line for this batch of products will be displayed in red. For transport documents, products which have expired will not automatically be selected, except in the case if there are no other / insufficient quantity of in-date products to fill the need. Where there are not enough in-date products, the line will show as “available” but the batch will not be shown, so that user must consciously open window to search for and select expired products.
Force availability
This functionality was already present in the original software. In the system it is visible in all stock movement transactions where the source of goods is internal, therefore for Internal moves, Delivery Orders, Picking Tickets and Consumption reports. The force availability icon is displayed if a line or split line of product quantity is not available in the selected location. If used, the green arrow with Force availability, will force products to become available (ie causing negative stock levels) meaning that the line can be processed together with the others in the document. However, for products which are Batch Mandatory or Expiry Date Mandatory, these cannot be forced. This is due to the other functionalities which are linked to these characteristics which would be made unreliable if force availability were made possible – e.g. batch recall, products to expire etc. Once Force availability has been applied to a line, and the line is available, any use of the “Check Availability” button will re-check the true availability, as a product with Available status is now included in this check.
Reason Types
There are several Reason types possible in the system for warehouse stock transactions: Incoming Shipments, Delivery Orders, Internal Movements, Initial Stock Inventories, Physical inventories, Shipments and Real Consumption Reports- For each a reason type is assigned by default in the transaction but usually can be changed:
- Internal Supply – In an Incoming Shipment from an Internal Supplier
- Consumption – can be selected in OUT
- Consumption Report– On OUT generated by Consumption Report
- Return from Unit – can be manually selected in Incoming Shipment
- External Supply – In an Incoming Shipment from External Supplier
- Deliver partner – for OUT
- Internal move – In an Internal move, may be changed
- Loan – relates to picking linked to PO/FO of this type
- Donation (standard) – relates to picking linked to PO of this type
- Donation (before expiry) – relates to picking linked to PO/FO of this type
- In Kind Donation – relates to picking linked to PO of this type
- Loss – Internal move with destination Inventory / inventory control
12.1- Loss / Scrap – Internal move with destination location Scrap
12.2- Loss / Sample – can be manually selected in Physical Inventory (Adjustment type)
12.3- Loss / Expiry – can be manually selected in Physical Inventory (Adjustment type)
12.4- Loss / Damage – can be manually selected in Physical Inventory (Adjustment type)
- Discrepancy – default in Physical Inventory, can be changed
- Other – for Internal Move to Destruction location, can be used in other documents also.
- Kit – for Internal Move to linked to Kitting Order
- Goods Return – for OUT linked to Claim returning goods to Supplier
- Goods Replacement – for IN linked to Claim where replacement expected
- Stock Initialization – default in Initial Stock Inventory
6.7 Product Cost Revaluation
Menu mapping: Warehouse / Inventory Management / Product cost revaluation
Transaction which permits average cost price value of products in stock to be changed.
Products can be added via usual means, individually, multiple, import or with nomenclature filters.
Statuses:
Draft: all modifications possible, price can be changed.
Confirmed: Confirmed button has been clicked, no modifications possible
Done: No more modification possible, product data sheet has been updated with new cost price. This
can be traced in the product master data action menu with “Track changes – Product prices”.
Export:
Cost Reevaluation Excel Export
6.8 Replenishment Rules (US-6490)
Menu mapping: Warehouse/Replenishment Rules
This functionality has been entirely reviewed and still under progress. Initiated with released ticket US-6490 and related linked tickets in Jira…
6.9 Manage Expired Stock (US-3092)
Menu mapping: Warehouse / Inventory Management / Manage Expired Stock
