Global Allocation at Lot Level, Instead of Product Level

Is it possible to configure Sage X3 to enable Global Allocation behavior but specified by Lot instead of Product? e.g. If global allocation worked as it should for our business, which is a fluid process production setup, we would globally allocate a product and have the choice to declare a specific lot to use without regard for which sublot is chosen. For work orders, this would enable picking of the sublots (in our case, drums of product) as determined on the floor, rather than having those drums predetermined by an admin disconnected with the floor. It is the case that we want to select the lot, at times, as the lot has specific characteristics helpful in achieving quality results that another lot may not have (proven through analytical work).

Does anyone know if there is a way to configure Global Allocation behavior such that you choose the lot despite the fact that inventory is sublot managed?

Top Replies

  • The only reason why we sublot manage, by the way, is to identify each drum that is containing the lot. Also open to alternatives that may involve serial numbers of packaging or anything that may allow us to move away from sublot managing and into lot managing, yet maintain traceability to the drum of product consumed in a work order or placed on a truck for shipment.

  • Global Allocation, from what I know, will never go down to the lot level.  If you do want allocation at the lot level, then you will need to do "detail allocation", which will allow you to allocate to a specific lot or sub lot.

  • in reply to KChristianson

    Hi 
    I don't see any standard solution to your demand. Either you are using global allocation and then you can consumme any lots, sub-lots and even mix them or you are using a detailed allocation but then you must indicate the exact lot, sub-lot to use.
    Note: a detailed allocation doesn't force you to consumme what is allocated you can always manually change the stock to consumme upon the material tracking. -> can this be an acceptable workaround?

    It seems to me, you don't really need detailed allocation. I think you would need a development that will add the lot number to consume on the WO component list (as a specific field). Then you need to use this new field in the material slip. It would even be possible to reuse this specific field to restrict the consumption of the specified lot upon material tracking by writing some code.

  • in reply to Julien Patureau

    On the MFGMAT table, and on the MFG2 screen, there's a "LOT" field where the field description is "Preferred Lot". Do you know how that works? If we turn it on, can the user enter a "Preferred Lot" number that doesn't allocate, but specify the lot to consume during tracking?

  • in reply to Mike Tsai

    I don't know for work order but this possibility exists for sales orders so there is a chance to make it work!

  • in reply to Julien Patureau

    Damned , you are right!! 
    We can set a Lot filter the same way than for sales order by doing this:

    Then you can entered the favorite Lot number:

    If you manage only a global allocation and not automatic stock determination on the material tracking transactions, then the user can only select the lot pre-defined in the work order (this control can be by-passed when changing the stock selection criteria):

    Not I have 2 lots available in my example:

  • in reply to Julien Patureau

    Cool, Julien! Thank you for confirming it. I have some vague memory of using that field in the past, but don't remember much detail about it. And I didn't know I can access that field through "Allocation filter" window. That's great information. Thank you!

  • in reply to Mike Tsai

    Cool!! I will be trying this out and will verify if it suits our purposes! Hopefully that is what does it for us... will report back when I know. It's one of those things where there are some products that we absolutely must stipulate lot-specificity (each lot could be comprised of chemical properties that make it only suitable for use as inputs into specific products, despite being the same product), and when we stipulate that lot, we don't care what sublots are pulled but we do want traceability at the sublot level. We want to tell the system which sublot we are using ON AN ADC SCREEN tracking material issue into a work order, not be told. But since allocating those sublots is what limits what can be material tracked on an ADC screen, we are greatly concerned and anticipate great struggle regarding the logistics of pulling the exact sublots allocated out of inventory.

  • in reply to Julien Patureau

     How do you turn automatic stock determination off on the material tracking transactions? The lot in my configuration still autopopulates using FIFO, so the filter is nonfunctional to this end.

    Is this the main setting? And how does Manual issue only function in this context?

  • in reply to Julien Patureau

    I tried the solution and it didn't quite suite our needs. This is a great find, though, and I wish it was useful for us. Today, we wish to material issue our work orders using ADC Material Output because this way we take the guesswork out by forcing the user to scan the lot-sublot of the product, which will already have the STK Qty associated with it. Going about allocations as was proposed here means the user has to manually enter qty, plus they have to manually select the sublot they are consuming in the WO (barcode is useless). 

    Basically, we want to be able to allocate a lot of material to the work order, not caring about which sublot exactly gets allocated. But when we track, we want to track each sublot into the WO to be able to confirm potential sources of defect down to the specific sublot of input.

    For us, a sublot is an abstraction to represent each container of fluid material. I've tried every way I can think of, using serial numbers, containers, etc., and they all end up either behaving like sublot when allocated or they break inventory...

  • in reply to KChristianson

    Well, all this time later and I am a bit more optimistic this solution may work for us. Pending feedback from the users, this is viable. For us, in this scenario, we would be globally allocating; indicating the preferred lot, status, and production staging location; reserving the material onto a specific stock status; and then have the production team stage the material in a designated location for the work center group. That follows with the production team performing their own allocation, which when these filters are applied, is as simple as opening manual allocations and then clicking the "All" checkbox (in fact, haven't tested this, but I'm hopeful I can just click the Detail Allocation button and this filter will work, though I am doubting it as I type it). Anyway, now we're detail allocated and get the option at this stage to scan each sublot as we have chosen to pull them from inventory. 

    I'm pretty excited about this direction as it will save a LOT of warehouse management.

  • in reply to KChristianson

    Well, all this time later and I am a bit more optimistic this solution may work for us. Pending feedback from the users, this is viable. For us, in this scenario, we would be globally allocating; indicating the preferred lot, status, and production staging location; reserving the material onto a specific stock status; and then have the production team stage the material in a designated location for the work center group. That follows with the production team performing their own allocation, which when these filters are applied, is as simple as opening manual allocations and then clicking the "All" checkbox (in fact, haven't tested this, but I'm hopeful I can just click the Detail Allocation button and this filter will work, though I am doubting it as I type it). Anyway, now we're detail allocated and get the option at this stage to scan each sublot as we have chosen to pull them from inventory. 

    I'm pretty excited about this direction as it will save a LOT of warehouse management when we 

    I think, for now at least, I am happy to have 's answer be considered the answer for this query, since I was the one who disagreed with it earlier.