Skip to main content
Solved

Shipped qty in Shipments


Forum|alt.badge.img

We have an order on our system that was created 23/02/24. It had 1 line item, with a qty of 1 required. Today (07/03/24) I added another line for the same item, with a qty of 1.

When I then Create Shipment, the original item populates the Shipped Qty with 0, but the new item populates the Shipped Qty with 1.

The behaviour we want is as per the original item - i.e. the Shipped Qty should remain 0 until we actually pick/ship the item.

We’ve noticed that the Location shows <SPLIT> for the original item and FG000000 for the new item - not sure if this is related?

Note: we have only edited the original order to demonstrate the different behavior, our new orders behave as the added line does, which is not what we want.

We have tried editing various settings, but cannot get new orders to behave as we’d like.

It seems as if when the original Sales Order was created there was item/setup data recorded that makes the Shipment behave in a certain way for the existing item.

But when you add a new item, the item/setup data isn’t the same and it makes the Shipment operate differently.

Any thoughts?

TIA

Best answer by RobLowe

Thanks for the replies - it looks like we have a solution now (by altering our internal process) which ties in with the standard way that Acumatica works.

View original
Did this topic help you find an answer to your question?

10 replies

Forum|alt.badge.img

I’m wondering if when the original line was added if the inventory was allocated out of a specific location.  That inventory has since been used up and doesn’t actually exist any longer in the original location so it makes it <SPLIT> and 0.  I’ve seen this same behavior in Lot/Serial Nbr.’s.   

What does the location on the SO say? 

If you click on the Location magnifying glass can you select a different location or can you delete and re-add the line that’s not working?  Does that resolve it? 

 

 


Forum|alt.badge.img
  • Author
  • Jr Varsity III
  • 18 replies
  • March 7, 2024
travislawson wrote:

I’m wondering if when the original line was added if the inventory was allocated out of a specific location.  That inventory has since been used up and doesn’t actually exist any longer in the original location so it makes it <SPLIT> and 0.  I’ve seen this same behavior in Lot/Serial Nbr.’s.   

What does the location on the SO say? 

If you click on the Location magnifying glass can you select a different location or can you delete and re-add the line that’s not working?  Does that resolve it? 

 

 

The only reference to Location on the Sales Order is the Location Name, which is “Warehouse” on both lines - unless I’m missing something (I’ve turned all columns on)?

There is no other Location field and no magnifying glass to click on.

If I delete the SO line that isn’t working and re-add a line, the new line works the same as the one I’ve deleted.

That’s our issue, it’s the old line that works how we want it to, not any new ones.

Thanks for the response though!


dcomerford
Captain II
Forum|alt.badge.img+15
  • Captain II
  • 648 replies
  • March 7, 2024

Do you have any customisation around this areas as standard Acumatica is that the Shipped Quantity is set to what is available. There is a setting on the Sales Order Preference that will set qty on a Shipment to zero for items not in stock but i dont think that is what is causing your issue.

I presume there is enough stock to satisfy the demand on both lines. Are you using Sales Order Allocations?


dsimmerly
Pro I
Forum|alt.badge.img+1
  • Pro I
  • 117 replies
  • March 7, 2024

FYI - not sure this is related but I did have a support issue the Open Qty on shipments and the fix is still in process… 

 


Forum|alt.badge.img
  • Author
  • Jr Varsity III
  • 18 replies
  • March 8, 2024
dcomerford wrote:

Do you have any customisation around this areas as standard Acumatica is that the Shipped Quantity is set to what is available. There is a setting on the Sales Order Preference that will set qty on a Shipment to zero for items not in stock but i dont think that is what is causing your issue.

I presume there is enough stock to satisfy the demand on both lines. Are you using Sales Order Allocations?

I’m not aware of any customisations around this area. There is enough stock to satisfy the demand, but I’m not sure what Sales Order Allocations is to know if we are using it or not, sorry. However, just to clarify, the Shipped Qty being zero on the Shipment is what we want. We have a 3rd party picking app that requires zero quantity to start with, which when the items are picked, it populates the Shipped Qty with the correct amount. When Acumatica fills in a Shipped Qty beforehand the app doesn’t recognise that any items need picking.


Chris Hackett
Community Manager
Forum|alt.badge.img
  • Acumatica Community Manager
  • 2787 replies
  • April 24, 2024

Hi @RobLowe were you able to find a solution? Thank you!


Dana Moffat
Acumatica Moderator
Forum|alt.badge.img+2
  • Acumatica Moderator
  • 620 replies
  • April 24, 2024

@RobLowe what is the 3rd party picking app that you are using?

Acumatica will create shipments and populate the Shipped Quantity if you have inventory for it in the warehouse.

To know if you have sales orders automatically allocating, you can click on the Line Details on the SO line to see if the Allocated checkbox is checked - if it is, that means that the inventory was hard allocated at the time of SO entry.  If not, the inventory will be automatically allocated at Shipment creation time to a location in the warehouse.

Automatic allocations are based on Order Types setup:

 

From what i’m reading, you’re saying that you like that 0 quantity on the shipment because you would then hand this off to your picking app, which would update the shipped quantity?  Acumatica put 0 on the shipped quantity because it thinks that you are in stockout for this item but want to show 0 items on the shipment (based on a setting).


Forum|alt.badge.img
  • Author
  • Jr Varsity III
  • 18 replies
  • Answer
  • April 26, 2024

Thanks for the replies - it looks like we have a solution now (by altering our internal process) which ties in with the standard way that Acumatica works.


dominicpolicicchio03
Freshman I
Forum|alt.badge.img
RobLowe wrote:

Thanks for the replies - it looks like we have a solution now (by altering our internal process) which ties in with the standard way that Acumatica works.

Hi, Rob. What was the underlying issue with this? How were you able to default the shipped qty to 0?


Forum|alt.badge.img
  • Author
  • Jr Varsity III
  • 18 replies
  • January 9, 2025
dominicpolicicchio03 wrote:
RobLowe wrote:

Thanks for the replies - it looks like we have a solution now (by altering our internal process) which ties in with the standard way that Acumatica works.

Hi, Rob. What was the underlying issue with this? How were you able to default the shipped qty to 0?

Hi Dominic, the underlying issue was our 3rd party warehouse app works differently to Acumatica. I can’t exactly remember what we did (as it was a few months ago), but we changed an internal process (or two) and the issue was resolved. To clarify, we were not able to default the shipped qty to 0.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings