After todays update the GET v1/project endpoint returns quite a few duplicates. We have 2 projects in our test client and the totalcount from the API is now 7150. Seems like someone might have been a bit creative with a join somewhere.   After further inspection I see that the duplicates have different branches connected to them. We don't use branches, and the branches seems to be from other test clients. ... View more

Hi,   Creating allocations with expirationDate when updating a Shipment does not seem to work.    Endpoint: PUT to /controller/api/v1/shipment/{shipmentNbr}   Lot/Serial Class:     Request: { "shipmentDetailLines": [ { "lineNumber": { "value": "1" }, "shippedQty": { "value": 2.0 }, "operation": "Update", "allocations": [ { "lineNbr": { "value": 0 }, "uom": { "value": "STK" }, "quantity": { "value": 1.0 }, "operation": "Insert", "lotSerialNumber": { "value": "34645" }, "expirationDate": { "value": "2023-03-23T00:00:00" } }, { "lineNbr": { "value": 0 }, "uom": { "value": "STK" }, "quantity": { "value": 1.0 }, "operation": "Insert", "lotSerialNumber": { "value": "64354" }, "expirationDate": { "value": "2023-03-23T00:00:00" } } ] } ] } The update is completed, but the expirationDate field is not set. Since the Lot/Serial class requires expirationDate, confirming the shipment fails with the following error: "Error confirming shipment: Error: Updating 'Shipment line split' record raised at least one error. Please review the errors."   ... View more

Hi,   We have a problem with getting ShipmentConfirmations through the API at one of our customers. This is usually fixed by making sure the correct permissions is given to the integration user, but it does not seem to fix the issue this time.   Endpoint: v1/shipment/{shipmentNumber}/printShipmentConfirmation Error response: 500 Internal Server Error {     "message": "VismaId: eaada5b7-4cac-4000-9754-be0eb96889e4. You do not have enough rights to access SO64200S." }   Any idea of what could be wrong here? ... View more

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." ... View more