web
You’re offline. This is a read only version of the page.
close
  • Fixed zones for items

    Today we have the possibility to assign fixed locations to an item. The fixed locations is integrated to the location directives logic, meaning we could utizile the "Fixed location usage" to reduce the required location directive sequences per item/location.


    As zones has been more and more introduced to the warehouse functionality, a similar concept for zones would be beneficial.


    For example, when using replenishment it would be beneficial to be able to use a criteria like "Only fixed zones for the product" instead of having to specify each zone to be picked or put from for the combinations required for the scenario.

  • Adding the related load, shipment and work id as fields possible to pass to detours in outbound MDMI:s

    In warehouse implementations there are from time to time information that is required at the time of picking which is not available in the associated warehouse app screen.

    How-ever thanks to the combined use of detours and data inquiry many of these GAP:s can now be fulfilled in the standard product.


    Examples:

    • Being able to pass the "Load Id" to the "Receiving completed confirmation" MDMI.
    • Look up incoming loads and pick which load to receive in "Load item receiving" MDMI


    How-ever in the outbound scenario, load, shipment id or work id is not possible to pass from e.g. "User directed" MDMI to a detour.

    By enabling the possibility to pass the related shipment, load or work id to a data inquiry detour, many cases were users today use a physical printed picking list or going in to the FnO client to obtain information can be solved.


    Examples could be to look up the assigned shipping carrier, having the possibility to validate what has been picked already on the current work id and many more possible use cases.


    So a possible small change, could unleash a lot of ways to in the standard product solve customer specific requirements for data inquiries at the point of picking.

    Requirements that today either are solved by customization, physically printed pick lists or heading over to the FnO client for lookups.

  • Location license plate positioning enhancement

    The current functionality for "Location license plate positioning" supports scenarios where the physical licenseplate is put and picked from the same physical side.


    There are warehousing systems where the gravity racking system is replenished from one side, and picked from the other side.

    This could be supported with the licenseplate positioning if it would be possible to sort on the license plate position in the location directives.


    If sorting is not possible to add in the location directives action query, it should be possible to parameterize the order of the LP position sequence per location profile to be able to determine the ordering of the position assignment.

  • Warehouse App: Option to present tiles/list records as a list and not multiple records per row

    The current list view in the warehouse app will list records from left to right, and then continue with the next row depending on screen resolution.

    I.e. when using the "Show work line list" the current experience of reading data from left to right, then down does not provide an effecient or logical user experience.


    Compare it to a physical document(e.g. picking list), where you would never present data this way. Having it as a list with 1 record per line would be a useful option and make it easier to replace the need of a physical picking list for businesses that needs a structured overview of picking lines.



    Adding an option to present the records from top to down as a list(not sideways) would provide a more logical and effecient overview for warehouse workers.


    It could be a function that is saved as default for the user per screen next to the "Sort by" buttons that are currently available in these views.



  • Slotting: Improved control of put location suggestion

    The current design of slotting is ignoring the location directives for the put location. The slotting design seem to only respect the 1 location that is identified in the «Slotting plan» after «Locate demand» function.


    This behaviour reduces the use cases where slotting functionality can be applied and is probably one reason why it is not used to a higher extent.


    The current design ignores location directives for “Put” and does not allow warehouses to work in a dynamic way with refilling of locations with slotting. I.e. by using the location directives strategy «Empty location with no incoming work» to make sure that slotting will be done to an empty location, and not to a location where it already holds material.


    The current behaviour will continuously refill the location that holds the item in the slotting area. This is suboptimal for many warehouses.


    Suggestion to either incorporate the location directives logic for “put” in slotting or to enhance the slotting framework to enable a similar use of the strategy “Empty location with no incoming work” to increase the chances for warehouses to actually use slotting and in a WMS optimal way.

     

    Slotting should support the zone concept(or other criteria in location directives) and not only single location usage.