Cross-Warehouse Returns, Nonserialized Quantity Issues

Comments

3 comments

  • Benjamin 'Bigs' Coppel

    Hi Ian-

    I understand your frustration. I don't have a magic bullet solution for you, but here are some various ideas to consider:

    Plan the inventory movement in advance

    If you know in advance which gear will be returning to Depot B, you can use the Warehouse view for quotes, to set the Return warehouse for individual line items that you know will be returned to Depot B.

    Notes / caveats:

    • I would suggest selecting multiple lines and using Bulk Edit, for efficiency.
    • This will make Flex expect the whole line to return to Depot B after the event, so if only some of them are going to Depot B and some are going to Depot A, you may want to split into two lines and adjust quantities accordingly.
    • Modifications to the columns in this view will persist down from the quote to the pull sheet and manifest, but you can't see the modified values anywhere in the UI aside from in this Quote view. So certain lines in a Manifest may be expected to return to Depot B, which will be reflected in that inventory's calendar, but you can't see in the Manifest itself that they are not returning to the origin warehouse. For that reason, I would suggest adding a line item note to any lines which are set to return to Depot B.

    Spot counts - by weight

    Counting non-serial items by weight is an efficient way to maintain accurate inventory numbers. Ensure that the unit weight in Flex is accurate, then dump the lot of them on a shipping scale and update your numbers. Easy!

    Equipment list trickery

    Transfer Orders are almost identical to Pull Sheets, except that they have different source and destination warehouses. You can also enable the Return Warehouse for Pull Sheets, so that it can be set differently from the Source warehouse.

    You could therefore create an equipment list (PS or TO) associated with a particular event which has a bunch of gear in it that is expected to leave Depot A, do the job, then return to Depot B.

    This would require you separating your gear into two lists in advance, which may not be sensible based on what gear you're talking about. Doesn't really make sense to have moving light clamps on one list and the actual lights on another, for example.

    Serialize more

    You mentioned serializing everything and its pitfalls. I could see a scenario in which you serialize more, but split jobs into smaller chunks. For example, I'm a big fan of having Audio, Lighting, Video, Staging, and Labor quotes inside an Event Folder, rather than putting it all on one quote. That keeps the number of manifest line items lower (you mentioned 5000) - it also keeps quote line items under the recommended max of 500.

    RFID could be a key part of a solution like this, it can be perfect for items that would typically be non-serialized due to shape and quantity.

    Ignore allocated quantity

    An easy solution is to just ignore the allocated quantity (the second number in the X/X pair). It doesn't affect Flex's inventory availability planning engine, it just looks wrong. So you can just let things get out of whack, and fix them up at whatever frequency is convenient for you.

     

    I hope some of these suggestions are helpful to you! If you would like any help with any of the above, or perhaps a custom report for oversight of this issue, reach out to our team at hello@squarewave.com.au

    We are a full service consultancy for organizations using Flex and love developing comprehensive solutions to challenging problems.

    Cheers,
    Bigs
    Lead Consultant
    www.squarewave.com.au

    0
    Comment actions Permalink
  • Ian Bender

    And the ultimate question--what's even the point of the allocated number if it's literally ignorable for nonserial items?

    All the allocated gives me is problems with people companywide asking me "how do we have 492 out of -342 owned?"

    1
    Comment actions Permalink
  • Andrew Dammer

    I've also noticed this issue, can anyone explain to me why it would be desirable for it to work this way? Seems to defeat the purpose of having an automated system if you have to go back and manually adjust or count everything every time you transfer something.

    2
    Comment actions Permalink

Please sign in to leave a comment.