We have deployed a new version of the Sales Order Service API to production containing under the hood stuff to improve the quality and prepare for the future.   Release notes Description HasManualPrice property exposed in GET /salesorders/{type}/{id}/lines endpoint We added HasManualPrice property to the line in GET /salesorders/{type}/{id}/lines endpoint. This field indicates if the unit price of the line has been added manually or by the system. If you are new to the neXtGen services, please look at the Getting started with the first neXtGen service: Visma.net ERP Sales Order API for an introduction. ... Visa mer

We have deployed a new version of the Sales Order Service API to production containing under the hood stuff to improve the quality and prepare for the future.   Release notes Description freightCost and freightTotal added to the SalesOrderDto Freight properties freightCost and freightTotal has been added to the SalesOrderDto/totals.   If you are new to the neXtGen services, please look at the Getting started with the first neXtGen service: Visma.net ERP Sales Order API for an introduction. ... Visa mer

We deployed a new version of the Sales Order Service API to production. Version contains some under the hood stuff in addition to this:   Release Notes Description Use Export type on customer location to set tax category Previously the Tax category for an order line was selected based on the Export type of the customer class. This is not changed so that first we check the Export type on the customer location to set the Tax category. If the Export type on customer location is not set, the selection of the Tax Category is based on the Export type on the customer class.   If you are new to the neXtGen services, please look at the Getting started with the first neXtGen service: Visma.net ERP Sales Order API for an introduction. ... Visa mer

Yesterday we deployed a new version of the Sales Order Service API to production.   Release Notes Description Support for use of Replacement cost We have now implemented support for setting the replacement cost of a line, which is based on the supplier price, suppliers last cost and items last cost. Replacement cost is set by the system and by using the useReplacementCostForProfitAndMargin option, one can determine which cost to use in the margin and profit and total cost calculations for the order. With the option activated the replacement cost of the order lines are used and with the option off the unit cost of the lines are used. Support for Profit and margin We now implemented support for setting the unit cost of a line. Unit cost can be set in POST, else it is set automatically by the system. Unit cost is also included in GET. With the unit cost set for the order line(s), the total cost of the order and the margin and profit of an order will now be set for orders created from the API. To use the unit cost of the lines for the total cost of the order, the option 'useReplacementCostForMarginAndProfit' should be false.   If you are new to the neXtGen services, please look at the Getting started with the first neXtGen service: Visma.net ERP Sales Order API for an introduction. ... Visa mer

We deployed a new version of Sales Order Service API to production yesterday.   Release Notes Description Improve performance when posting sales order with a large number of lines We have improved the response time when posting new sales orders, especially when including a lot of lines with the request. The specific problem was related to looking up and assigning subaccounts to sales order lines. ... Visa mer

We deployed a new version of Sales Order Service API to production earlier today containing a few smaller improvements.   Release Notes Description Unit cost set when quantity on hand is 0 We have implemented a change so that the unit cost for a row is set correctly when the quantity on hand is 0. In addition we have also added a fallback to set the unit cost is warehouse is not set in the line(in this case we use the default warehouse set on the item). Upgrade libraries to .NET 6.0.3 We have upgraded libraries to the latest .NET 6.0.3 March 2022 update. Unit price not calculated correctly Previously the unit price was not calculated correctly when a order had a different currency than the base currency and the unit price was taken from the default price of the item. This has now been fixed. Unbilled and Unshipped total amounts not set correctly Previously when a order contained rows with different operation the Unbilled and Unshipped total amounts were not calculated correctly. This has now been fixed. ... Visa mer

Yesterday we deployed a new version of the Sales Order Service API to production. This version contains under the hood stuff for the near future, and should not have any effect on existing integrations. ... Visa mer

Yesterday we deployed a new version of the Sales Order Service API to production. The version contains additional performance improvements for GET inventory endpoint and also some cleaning up of old dynamic feature toggles active for all customers. ... Visa mer

Yesterday we deployed a new version of the Sales Order Service API to production. Under the hood improvements and preparing for the future.   Yesterday we also activated a new implementation of the GET inventory endpoint with improved performance and fix of functionality relating filtering on attributes.   ... Visa mer

We deployed a new version of Sales Order Service API to production earlier today containing a few smaller improvements. Release Notes Description Fix for validation of Shipping rule 'Back order allowed' for order types not requiring shipment Previously it was possible to set the shipping rule 'Back order allowed' for order types not requiring shipment. This has now been fixed, so that the validation is correct, not allowing the 'Back order allowed' shipping rule on these types of orders. Wrong error message returned for postPeriod When postPeriod was set for a order type not allowing the period, the error message given was 'The specified condition was not met for 'Post Period'. This has now been fixed to better explain the reason for the error, new error message being 'Post period cannot be set for this order type' ... Visa mer

We have today deployed 3 new versions of Sales Order Service to production with under the hood stuff for the future.   Release Notes Description Created by information in GET order response The response from GET /api/v3/salesorders/{type}/{orderId} now includes the username of the user that created the order provided the order was created using the UI (createdBy field).     ... Visa mer

We have deployed a new version of Sales Order Service to production with under the hood stuff for the future.   ... Visa mer

We have deployed a new version of Sales Order Service API to production with under the hood stuff for future functionality and we have now made available full support for discount on document and line level!   Release notes Description Full support for discount on document and lines We now support full discount on both document and line level. This give full support for document, group and line discounts according to configuration in the discount hierarchy when creating a new sales order. Document and group level discounts will be set automatically according to configuration. The same applies to line level discount supported according to branch, customer, customer price class, inventory price class, item, site (warehouse). In addition we have support for overriding with manual discount on line level, and setting manual discount flag on line level is automated when you override. ... Visa mer

We have released a new version of the Sales Order Service API with more under the hood stuff soon to be made available. In addition the version also contains the following element:   Release Notes Description Unit cost not set correctly We have fixed an issue where the unit cost of a line wasn't set correctly by the system when the order currency was different then then the company base currency. ... Visa mer

We have released a new version of the Sales Order Service API with under the hood stuff soon to be made available. In addition the version also contains the following element:   Release Notes Description Update of swagger documentation for addresses and contacts  We have updated the swagger documentation related to shipping and billing address and contact fields, to better explain the behavior of the fields.   ... Visa mer

We have released a new version of the Sales Order Service API.   Release Notes Description Additional validation for cash account Further improvement on cash account validation done by checking if "Use In AR" is not set on cash account in corresponding payment method we will return a response status 400 with information "Error: Cash account cannot be used with the set Payment Method.". Validation will be done both when CashAccountID is set automatically or manually.   In addion we have done further under the hood improvements to prepare for the future with functionality not yet made available.   ... Visa mer

We have released a new version with under the hood stuff for future functionality and generic improvements in quality and performance. ... Visa mer

We have released a new version with under the hood stuff for future functionality and generic improvements in quality and performance. ... Visa mer

We have released a new version with under the hood stuff for the soon to come profit/margin. ... Visa mer

Release Notes Description Support for Cash account We have implemented support for setting cash account for the order. Cash account can be provided in POST, and if not provided the default cash account of the customer is set. Support for all order types except TR We have now added support for the automation behaviour for all order types, also custom defined order types using the default order types as templates. Support for TR order types is not included with this implementation, but will be supported at a later stage. For supporting the order types we have added fields in the sections financialInformation(invoice related fields), paymentSettings(payment related fields) and lines(operation of the line) in GET and POST. ... Visa mer

Release Notes Description Support for Total cost on order We have now added support for calculating the Total cost-field for a sales order. Support for order Payment method We have added support for setting the default Payment method for the sales order based on the customer settings. The payment method can also be set in POST, thus overriding the default value. Setting unit cost on order line for items with valuation method Specific We have implemented support for setting the unit cost for an order line for items with the valuation method Specific Setting unit cost as Last cost on order line for items with valuation method FIFO and Average We have implemented support for setting the unit cost for an order line for items with the valuation method FIFO and Average, when you in the warehouse settings have set to use the Last cost for these type of items Support for option 'Use last cost if there is no available stock' in the Unit cost field in sales order line We have now added support for setting last cost of an item as the unit cost in the sales order line, when there is no available quantity of the item in the warehouse. Shipping rule for IN order types We have implemented the business logic for setting the default Shipping rule for an order when the order is of type IN. In this scenario, the Shipping rule will default be set to Cancel Remainder. For this type of order the Shipping rule: Back order allowed is not accepted and you will get an error for this value if it is included in POST Setting unit cost as Average cost on order line for items with valuation method FIFO and Average  We have implemented support for setting the unit cost for an order line for items with the valuation method FIFO and Average, when you in the warehouse settings have set to use the Average cost for these type of items Setting unit cost on order line for items with valuation method Standard We have implemented support for setting the unit cost for an order line for items with the valuation method Standard   In addition to a lot of improvements under the hood to improve quality and performance. If you are new to the neXtGen services, please look at the Getting started with the first neXtGen service: Visma.net ERP Sales Order API for an introduction.   ... Visa mer

We are transitioning the Visma.net ERP Sales Order Service from alpha to beta state. This indicates that we will no longer introduce any breaking changes in existing endpoints. If this will be required we will introduce a new version of the endpoint. The journey to frequently add more functionality will continue, but we will give you (the ISVs) 6 months to migrate to the new version of an endpoint if we introduce a breaking change. This will create better predictability for you as a consumer of the Visma.net ERP Sales Order Service API and ensure you will be able to serve your customers the best way possible.   Rename Site to Warehouse We want to be consistent in our naming and use Warehouse as the term for sites and warehouses. We're also moving the (formerly) defaultSiteId to the shipping section to be consistent with the GET endpoint response. POST /api/v3/salesorders Rename defaultSiteId to preferredWarehouseId, and move to shipping. Before change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "defaultSiteId": "Site1" }       After change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "shipping": { "preferredWarehouseId": "Site1" } }       Rename siteId to warehouseId Before change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "orderLines": [ { "inventoryId": "SomeItem1", "quantity": 2.0, "siteId": "Site1" } ] }       After change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "orderLines": [ { "inventoryId": "SomeItem1", "quantity": 2.0, "warehouseId": "Site1" } ] }       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Rename siteId to warehouseId. Before change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 1, "inventory": { "baseUnit": "STK", "id": "SomeItem1" }, "quantity": 2.0, "siteId": "Site1" } ] }       After change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 1, "inventory": { "baseUnit": "STK", "id": "SomeItem1" }, "quantity": 2.0, "warehouseId": "Site1" } ] }       GET /api/v3/customers/{customerId}/locations Rename siteId to warehouseId. Before change       Response: [ { "internalId": 1, ... "siteId": "Site1" } ]       After change       GET /api/v3/customers/{customerId}/locations Response: [ { "internalId": 1, ... "warehouseId": "Site1" } ]       Rename Customer Fields We want to be consistent and not repeat parent object's name in properties GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Rename customerOrder to order, customerRefNo to refNo. Rename customerId to id. Before change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Response: { "type": "SO", "orderId": "10001", ... "customer": { "customerId": "10000", "name": "some name", "customerOrder": "arbitrary order number", "customerRefNo": "reference number" } }       After change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Response: { "type": "SO", "orderId": "10001", ... "customer": { "id": "10000", "name": "some name", "order": "arbitrary order number", "refNo": "reference number" } }       Rename DiscountPrice Rename property for consistency GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Rename discountPrice to discountAmount. Before change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 1, "inventory": { "baseUnit": "STK", "id": "SomeItem1" }, "quantity": 2.0, "discountPrice": 1.00 } ] }       After change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 1, "inventory": { "baseUnit": "STK", "id": "SomeItem1" }, "quantity": 2.0, "discountAmount": 1.00 } ] }       Use descriptive names instead of codes We want to return names of property values when we can, as opposed to codes used internally by the system. Please note that these changes are currently feature toggled and can be tried out today by enabling the switch for one or more companies if necessary. POST /api/v3/salesorders Use names for status. Before change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "status": "N" }       After change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "status": "Open" }       Use names for shipping/rule. Before change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "shipping": { "rule": "B" } }       After change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "shipping": { "rule": "BackOrderAllowed" } }       Use names for shippingRule. Before change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "orderLines": [ { "inventoryId": "SomeItem1", "quantity": 2.0, "shippingRule": "B" } ] }       After change       POST /api/v3/salesorders { "type": "SO", "customer": { "id": "10000" }, "orderLines": [ { "inventoryId": "SomeItem1", "quantity": 2.0, "shippingRule": "BackOrderAllowed" } ] }       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Use name for status. Before change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Response: { "type": "SO", "orderId": "10001", ... "status": { "description": "N" } }       After change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Response: { "type": "SO", "orderId": "10001", ... "status": { "description": "Open" } }       Use name for shipping/rule. Before change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Response: { "type": "SO", "orderId": "10001", ... "shipping": { "rule": "L" } }       After change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Response: { "type": "SO", "orderId": "10001", ... "shipping": { "rule": "CancelRemainder" } }       GET /api/v3/salesorders(/{salesOrderType}) Use name for status. Before change       GET /api/v3/salesorders/{salesOrderType} GET /api/v3/salesorders Response: { "value": [ { "type": "SO", "orderId": "10001", "status": "H" } ] }       After change       GET /api/v3/salesorders/{salesOrderType} GET /api/v3/salesorders Response: { "value": [ { "type": "SO", "orderId": "10001", "status": "Hold" } ] }       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Use name for lineType. Before change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 3, "lineType": "GI" } ] }       After change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 3, "lineType": "GoodsForInventory" } ] }       Use name for operation. Before change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 3, "operation": "I" } ] }       After change       GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 3, "operation": "Issue" } ] }       Use Tax consistently We want to switch to use Tax as a term for VAT and tax in general. GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Change names in the totals section Note that this only applies if expand=all, or expand=financialInformation.   Before change     GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}?expand=all Response: { "type": "SO", "orderId": "10001", ... "totals": { "orderTotal": 1000.00, "orderTotalInBaseCurrency": 1000.00, "vatTaxableTotal": 100.0, "vatTaxableTotalInBaseCurrency": 100.0, "vatExemptTotal": 0.0, "vatExemptTotalInBaseCurrency": 0.0, "taxTotal": 25.00, "taxTotalInBaseCurrency": 25.00, } }     After change     GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}?expand=all Response: { "type": "SO", "orderId": "10001", ... "totals": { "orderTotal": 1000.00, "orderTotalInBaseCurrency": 1000.00, "taxableTotal": 100.0, "taxableTotalInBaseCurrency": 100.0, "taxExemptTotal": 0.0, "taxExemptTotalInBaseCurrency": 0.0, "taxTotal": 25.00, "taxTotalInBaseCurrency": 25.00, } }     Change names in the customer section Note that this only applies if expand=all, or expand=customer.   Before change     GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}?expand=all Response: { "type": "SO", "orderId": "10001", ... "customer": { "vatZone": { "id": "01", "description": "some description" } } }     After change     GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}?expand=all Response: { "type": "SO", "orderId": "10001", ... "customer": { "taxZone": { "id": "01", "description": "some description" } } }     Use consistent format for Subaccount We want to be consistent in the notation for subaccounts, using the same segment id/segment value we use when posting a new sales order. GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Use the new format for lines. Before change     GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 3, ... "subaccountId": "101" } ] }     After change     GET /api/v3/salesorders/{salesOrderType}/{salesOrderId}/lines Response: { "value": [ { "lineId": 3, ... "subaccount": { "1": "1", "2": "0", "3": "1" } } ] }     Use consistent name for for Shipping information We want to be consistent in the notation for shipping information, using "shipping" and not "shipment". GET /api/v3/salesorders(/{salesOrderType}) Change name for shipmentScheduledDate to shippingScheduledDate. Before change     GET /api/v3/salesorders/{salesOrderType} Response: { "value": [ { "type": "SO", "orderId": "100001", ... "shipmentScheduledDate": "2021-06-04T00:00:00" } ] }     After change     GET /api/v3/salesorders/{salesOrderType} Response: { "value": [ { "type": "SO", "orderId": "100001", ... "shippingScheduledDate": "2021-06-04T00:00:00" } ] }     Use consistent name for for payment settings section We want to use a better name for the payment section in the sales order head as it relates to the payment settings tab in the UI using "paymentSettings" and not "payment". GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Change name for payment to paymentSettings. Before change     GET /api/v3/salesorders/{salesOrderType}/{salesOrderId} Response: { "type": "SO", "orderId": "10001", ... "payment": { "paymentMethod": {...}, "cashAccountId": "1" } }     After change     GET /api/v3/salesorders/{salesOrderType} Response: { "type": "SO", "orderId": "10001", ... "paymentSettings": { "paymentMethod": {...}, "cashAccountId": "1" } }     If you are new to the neXtGen services, please look at the Getting started with the first neXtGen service: Visma.net ERP Sales Order API for an introduction. ... Visa mer