Updating and confirming shipment with different unitOfMeasure on line and allocations

[Sigbjørn Eide]

Hi,

We are having some issues with updating and comfirming shipments when a line is ordered with a different unitOfMeasure than the base unit.

Example:
ShipmentLine: Quantity = 2, UoM = 4-PCS (where 4-PCS = 4 * PC)
Allocation: Quantity = 8, UoM = PC (The allocations are created with the base unit, in this case PC)

If only half of the items are found we will report back quantity = 4 on the allocation:

{
   "shipmentDetailLines":[
      {
         "lineNumber":{
            "value":"1"
         },
         "operation":"Update",
         "allocations":[
            {
			   "operation":"Update",
               "lineNbr":{
                  "value":"2"
               },
               "quantity":{
                  "value":4.0
               }
            }
         ]
      }
   ]
}

This updates the quantity on the allocation to 4, but does not calcualte the quantity on line based on the changes in the allocations. There is no information about the factor between the units on the shipment, so we can't calcualte the correct line quantity. Therefore, we leave it up to Visma.Net to calcualte it based on the quantities in the allocations. This calculation is done correctly if the item is a kit (which is another scenario where the sum of allocation quantites does not match line quantity), but different uom on line and allocations does not seem to trigger the calculation.

This causes a "corrupt" shipment and trying to confirm it results in the following error: "Sales order error: One or more lines contain unassigned location and/or lot/serial number."

[Magnus Johnsen]

Hi,

Does the quantity on the line not update at all or is it set to 4?

We'll test this out and report it to the development team.
As a workaround, is it feasible for you to call the UoM endpoint to grab the factor to update it correctly?

[Sigbjørn Eide]

The quantity on the line does not update at all.

We could grab the factor from the UoM endpoint, but adding more requests to an already slow operation is not something we would like to do. If we were to calculate it on our own we would probably import it ahead of this operation, but that could cause the data to become out of sync, which is not desirable.