Peoplevox

Peoplevox 25.07.01 Release Notes


Descartes® is pleased to announce the latest release of Peoplevox. This update includes the very first release of our cycle count action. Below, you'll find a summary of the changes implemented in this version. For any questions about specific items, please reference the associated number (if provided) when contacting Descartes Customer Support.

In this release, we are releasing some components to support the new action creation mechanism. We are also fixing some minor bugs related to the new fields introduced to help manage stock take and cycle counting.


Tip: Use our Ideas Portal to our Ideas Portal to submit your Enhancement ideas for Descartes Peoplevox. Click here for additional information and instructions for requesting access to the Ideas Portal.


As we continue the migration of screens to the new web app styling, we will move the older version of each screen to legacy mode. The older versions will remain available for the immediate future, but you are encouraged to use the new screens wherever possible. Also, we welcome your feedback on the new screens. Your input helps us to ensure that the new screens meet your needs before the legacy screens are switched-off at a later date. The new versions of those screens include:

  • Locations

  • Location groups

  • Removals

  • Sites

  • Returns

  • Reports

  • Dashboards

Thank you to everyone that has provided feedback on these screens so far. Please rest assured that we are reviewing all feedback and have several enhancements planned to implement many of those changes that you have proposed.


Highlights

New cycle count action - available now

This release includes the very first version of our new cycle count action. This is an auto-generated instruction created by the system to direct mobile operators to perform stock takes for locations that need to be counted.

Cycle count actions are driven by a couple of new properties that you may have seen recently on the location, called stock take frequency and last stock take date. The frequency is an optional new field that allows you to control how often you want to count each location: If you leave it blank, you won't see any cycle count actions for that location.

The last stock take date automatically records the date and time that a stock take is performed on each action. You do not need to do anything to fill this out: the system will automatically start keeping track of stock takes from this release onwards.

If you provide a frequency (in days), the system will automatically create cycle count actions for a location when the time since the last stock take exceeds that frequency. For example, if you set a frequency of 90 days for a given location, then we will automatically create a cycle count for the location after 90 days have passed since the most recent recorded stock take was performed.

Note: If there is no last stock take timestamp, then any frequency will trigger the creation of a cycle count. For example, if you add any frequency to a location immediately after this release, we will automatically create a cycle count action for it, because we have not yet tracked a stock take timestamp for that location. Please be mindful of this when updating the frequency for large numbers of locations at once.


Once a cycle count has been created, mobile operators with the appropriate permissions will be able to see them listed on the mobile device, much like a pick list, under the new Cycle Count menu:


From that new menu, operators will be able to search for and filter locations based on several parameters. For example, you can narrow down this list based on the location use type, or the storage type associated with the location:



If you tap into one of those cycle count actions, you will see a screen that looks very similar to the standard stock take items workflow:


From here, the operator performs the stock take exactly as they would if they had launched the old stock take workflow manually. Starting work on a cycle count action like this will lock the location, just like an ad-hoc stock take would, and submitting the count will generate a variance for review by supervisors.


New cycle count action - coming soon

This is just the first release of our new and improved cycle count workflow, but we have a host of other changes and improvements still in the works.

  • In this first release, the cycle count workflow will allow you to count items in a location. In the next update, we will be extending this to support:

    • Counting items in the location

    • Counting containers in the location

    • Clearing the location entirely

  • Currently, a cycle count generates a variance to be approved through the existing web app or mobile variance approval process. In one of the next major updates, we plan to update that web app variance approval workflow. Some changes that will come as part of that:

    • The ability to define automatic variance approval thresholds, so that you can save time by auto-approving low-variance counts, and focus more on counts with a higher deviation.

    • An updated, cleaner interface, that clearly indicates the expected item count, the actual item count, and separately lists any changes to containers.

In addition to those changes, we have also received a wide range of excellent suggestions that we are aiming to incorporate. This is by no means a comprehensive list, but some of those suggestions include:

  • Adding the ability for mobile operators to quickly indicate that a location is empty as a part of other actions - for example after they pick the last item from a location. This would save you a huge amount of time, by drastically cutting down on the number of cycle count actions that send operators to go and check empty locations.

  • Allowing variances to be approved line-by-line, while leaving some lines unapproved for review later. This would allow supervisors to quickly approve variances that they believe are safe, while still retaining control over more granular item-level deviations.

  • Adding an indicator to the variance approval workflow to show previous variances, to allow supervisors to determine whether a given variance is typical for a particular location, and help to identify patterns in high-variance counts.

We're keen to hear any feedback you have on this first release as well as any suggestion you have for future improvements, so please reach out of you have any questions or ideas.


New and improved web app screen for viewing actions

We are continuing with our rollout of improvements to the action creation process, and in this release, we are updating the workflow for viewing actions that have already been created:



From here, you'll be able to search for actions, and drill into the detail on each one:



Please let us know what you think, and as always, we welcome your suggestions on how to improve this further.


Resolved Issues

🟩 We fixed a bug with the new put away and returns workflows on mobile that prevented some alternative barcodes from being recognized. These workflows now support all barcode fields, including composite barcodes and supplier part numbers. (1252281, 1271367)

🟩 We fixed a rare bug that could cause an item to be incorrectly displayed in the despatch summary report. (1111354)

🟩 We fixed a bug that could cause the repack button on the mobile app to instead redirect the operator to the unpick function. (1269240)


Preview of Changes Coming Soon

Put away improvements

We are continuing to work on several improvements to the put away process. Below is a brief summary of some of the challenges that were identified and our current thinking around potential solutions. We would love to hear your feedback on these topics as well.

🟦 We are making some changes to the way the new put away rules work in relation to checking previous location usage for each item. Currently, the rules allow you to guide operators to a previously-used location, but do not allow you to define a sort condition to ensure that it is the most recently used previous location. We're still experimenting on the best way to solve this, but our current line of development is to provide a filter condition that will specifically look at the most recently used location of a given type (pick, bulk, quarantine, potentially despatch if useful).

🟦 Related to that, we are also looking at making a series of improvements to the performance of the rules. Each rule relies heavily on live, up-to-date information about the current state of the warehouse, which can often mean running some complex calculations during the rules. We are exploring ways to save more of that data during other warehouse transactions so that the rules can simply read information rather than having to run a complex calculation.

🟦 We are exploring ways to prevent the rules from providing the same location suggestion for multiple products in a batch. Specifically, if multiple products need to be put away to an empty location. Currently, each put away suggestion is generated in isolation, without context of any other rules being run, and the suggestions for all products in a batch are generated at the same time. This means that if one rule directs a product to an empty location, a second rule for a different product may direct the user to the same empty location because it still views it as empty. We're planning a two-step solution here:

  1. Initially, we're looking to introduce an automatic refresh of suggestions that may be "stale" before we show them to the mobile operator. For example, if the first item directs the user to an empty LocationA, then before we show the next suggested item(s) bound for LocationA, we refresh the suggestions. That will introduce a small delay while the system recalculates the destination, so we will also provide a role-level permission or configuration switch to allow you to decide whether that delay is more impactful than having the operator skip the put away.

  2. Longer-term, we want to expand the put away rules to generate actions, the same way we would for a pick or a replenishment. This would allow each rule to have context of any suggestions that have already been made, including those being performed by other operators. This part is contingent on some of the ongoing action creation work, so we will need a little more time before we can implement this piece.


Descartes ShipRush

You can also find the latest release notes for ShipRush here:

ShipRush release notes

Back to Top