Independent IFS Cloud practice · Warehouse floor design
Move the transaction to the point of work, one tested process at a time
IFS Cloud Warehouse Data Collection is the documentation area for executing warehouse transactions through a scanning page, so that the transaction is entered where the work happens. Without it, the transaction is entered where the system is: the floor works from paper or memory and someone keys the result later. The stake is stock accuracy and the delay between the physical move and the system record. Scanning removes that delay only for the processes that someone configured and tested.
This article stays on the configuration and activity pages cited in it. It says nothing about device types, offline behaviour or the mobile client.
Key takeaways
- Warehouse Data Collection covers the processes the documentation lists for scan-based execution, and each process is configured and tested on its own.
- Start with the transactions that happen farthest from a terminal and are costliest when entered wrongly.
- Warehouse Data Collection supports GS1-128, GS1 DataMatrix, GS1 DataBar and GS1 QR barcodes, and not stacked or composite barcodes. Label content is decided before go-live.
- When the warehousing functionality is used, the pick list for customer orders, shipment orders, project deliverables and purchase receipt returns is replaced by a warehouse task, and pick reporting is performed in the warehouse functionality.
- The scenario table tests one process per row: counting, picking by choice, shop order receipt, receipt labels and a warehouse task.
1.What is Warehouse Data Collection in IFS Cloud?
Warehouse Data Collection is the part of IFS Cloud in which warehouse transactions are captured by scanning or typing at the place where the work is done. The documentation on Warehouse Data Collection configuration describes how the processes are set up.
The scope is the list of processes the documentation names for scan-based execution. That makes the first design task a list: which processes your floor performs, and which of them the documentation supports through scanning.
2.Which floor processes should move to scanning first?
The processes to move first are the ones where the physical action and the system entry are farthest apart and where a wrong entry is costliest. The method has two passes: list the transactions by where they happen physically, then rank them by what an error costs.
Among the processes the documentation describes for the scanning page are these three. Counting can run as a guided process: in the configuration example the documentation gives, the first sequence number is picked automatically once the count report number is entered, and the operator then scans or types the location number and part number. Picking a part by choice can be run from the scanning page, and shop order receipts can be captured there by scanning or typing according to the configured process. Each of these is a candidate row for the ranking, and the page references are collected in the scenario table below.
The mechanics of resolving count variances, which a scanned count produces as well as a typed one, are covered in cycle count variance reconciliation.
3.How do barcodes and guided processes fit together?
A guided process tells the operator which value to scan next, and a barcode label supplies that value without typing. The documentation on Warehouse Data Collection configuration lists GS1-128, GS1 DataMatrix, GS1 DataBar and GS1 QR as supported and states that stacked and composite barcodes are not supported. Choose the label format from that list, and print a test label in the chosen format before the labels are ordered in bulk.
Labels can be produced at receipt, and the label content has to be decided before go-live. The page on printing barcode labels from a purchase order receipt describes the function. Label content has to match what the downstream process expects, and that includes lot or serial numbers for tracked parts, as discussed in lot and serial tracking decisions in IFS Cloud.
Receipt itself, including the statuses a received part passes through, is covered in goods receipt, inspection and put-away in IFS Cloud.
4.How does scanning relate to warehouse tasks and pick lists?
When warehouse tasks are used, picking is driven by tasks and not by pick lists: if the warehousing functionality is used, the pick list is replaced by a warehouse task and the pick reporting is performed within the warehouse functionality. The documentation on picking describes the relation and names the sources it covers: pick lists connected to customer orders, shipment orders, project deliverables and purchase receipt returns.
Warehouse tasks can be planned and prioritised, and someone has to own that planning. The page on planning warehouse tasks describes the planning step. The design question for scanning is therefore a question about ownership: someone has to decide what a task contains and in which order workers receive tasks. The neighbouring shipping steps have their own articles: the packing proposal and the shipment order.
5.What must the location model support before scanning works well?
A scanned transaction names a location, so the location model has to match what the operator sees on the shelf. A location label that the floor cannot find, or two locations that look identical, make a scan as unreliable as a handwritten note. The design of the levels and their names is covered in warehouse structure design in IFS Cloud, and this article does not repeat it.
6.How do you test scanning before go-live?
Test scanning with one scenario per process, run by the people who will perform it, on the device and label they will use. Record the expected system record before the scenario, then compare it with the record that the scan created. The general method for planning and tracking such tests is in testing in IFS Cloud.
| Process | What is scanned or typed | Expected record | Owner |
|---|---|---|---|
| Guided count | Location and part, in the sequence defined with the warehouse team | Counted quantity recorded for that location and part | Warehouse lead |
| Pick part by choice | Part and location chosen at the page | Pick recorded against the stock the operator chose; see the page on picking a part by choice | Picker |
| Shop order receipt | Shop order and quantity, per the configured process; see the page on receiving a shop order | Finished part received into the intended location | Production lead |
| Receipt labels | Label printed at receipt and scanned later | The label content that the next process reads | Receiving clerk |
| Warehouse task | The task assigned to a worker | Task closed with the physical move confirmed | Warehouse planner |
7.What does a floor-process scanning checklist contain?
A scanning rollout is ready when each of the checks below has a record behind it.
- The floor processes are listed, and each one is marked supported or not supported for scanning in your release.
- The processes are ranked by distance from a terminal and cost of an error.
- The label format is one of the supported GS1 barcode types.
- Label content is agreed with the process that reads it.
- The use of warehouse tasks is confirmed, with a named planner.
- Every scanned location can be found on the floor.
- Each process has a scenario with expected record, owner and evidence.
8.Frequently asked questions
What is Warehouse Data Collection in IFS Cloud?
Warehouse Data Collection in IFS Cloud is the documentation area for capturing warehouse transactions by scanning or typing at the place of work. Each process, such as counting or shop order receipt, is configured and tested on its own. The IFS documentation on Warehouse Data Collection configuration describes how the processes are set up.
Which barcode formats are supported?
The IFS Cloud documentation on Warehouse Data Collection configuration lists GS1-128, GS1 DataMatrix, GS1 DataBar and GS1 QR as supported; stacked and composite barcodes are not supported.
Do warehouse tasks replace pick lists?
When warehouse tasks are used in IFS Cloud, picking is driven by tasks and not by pick lists. The IFS documentation on picking states that the pick list is replaced by a warehouse task when the warehousing functionality is used, for pick lists connected to customer orders, shipment orders, project deliverables and purchase receipt returns. Define who plans and prioritises the tasks.
What should be tested before go-live?
Test every scanned process in IFS Cloud with one scenario each, performed by the people who will do the work, on the device and label they will use. Write down the expected system record first, run the scan, and compare. Every difference is a defect in the configuration, the label or the expectation.
9.About the author
Dariusz Myśliwiec: 18 years hands-on with IFS, including IFS Cloud. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Does the floor still write on paper and key it afterwards?
A floor-process walk-through decides which transactions to scan first, with the warehouse lead and the people who do the work.
Book a floor-process walk-through Read about warehouse structure design