Integration between Ongoing WMS and Visma.net
Table of contents
Introduction
Ongoing Warehouse has developed an integration for Visma's web-based ERP Visma.net. This integration makes it possible for businesses which use Visma.net to easily outsource their warehouse needs to a 3PL company which uses Ongoing WMS. The integration can also be used by businesses who run Visma.net and who want to run their own warehouse using Ongoing WMS. By passing information electronically between Visma.Net and Ongoing WMS, many manual tasks concerning stock balances, order statuses, etc. are eliminated or reduced. As a complement to the integration, users of Visma.net can also be given direct access to the WMS.
The integration works well together with the Ongoing workflow. It uses the Visma.net API. Most functions run every 15 minutes, but some functions are based on user actions.
Note that the information in this document might differ from your integration if any special requests were made during the implementation of the integration.
Scheduled functions
Some functions in the integration run on a schedule. The supplier registry, article registry, orders and purchase orders are synced automatically from Visma.net to Ongoing WMS.Supplier registry
The supplier registry is read automatically from Visma.net to Ongoing WMS. The registry may be used for e.g. customs reports.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| SupplierName | Name |
| SupplierNumber | Number |
| Address ⇒ Name | Name |
| Address ⇒ Address | SupplierAddress ⇒ AddressLine1 |
| Address ⇒ Address2 | SupplierAddress ⇒ AddressLine2 |
| Address ⇒ Address3 | SupplierAddress ⇒ AddressLine3 |
| Address ⇒ City | SupplierAddress ⇒ City |
| Address ⇒ PostCode | SupplierAddress ⇒ PostalCode |
| Address ⇒ CountryCode | SupplierAddress ⇒ Country ⇒ Id |
| Address ⇒ MobilePhone | SupplierContact ⇒ Phone2 |
| Address ⇒ TelePhone | SupplierContact ⇒ Phone1 |
| Address ⇒ Email | SupplierContact ⇒ Email |
| Address ⇒ Remark | SupplierContact ⇒ Attention |
Article registry
The article registry is read automatically from Visma.net to Ongoing WMS. If a change is made in Visma.net, it will be reflected automatically in Ongoing WMS. Note that structure/production articles can be synced from Visma as well. This functionality is activated by making sure the integration modules for syncing kit specifications and kit assemblies are activated.
Information about the lot/serial class for each article can be retrieved. This information is used to control how order rows in Ongoing WMS are created, and how information about the picked items is reported back to Visma.net. Each article in Visma.net can have one of these three classes:
- Not numbered
- Lot numbered
- Serial numbered
Note: If you want to use the lot/serial class for an existing integration you will need to resync all articles to ensure that the information about lot/serial class for each article exists in Ongoing. Before this data was exposed in Visma.net it was only possible to setup the integration to always report serial or batch data to Visma.net for all articles, i.e. the integration assumed that all articles in Visma.net had the same lot/serial class.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| Article definition ⇒ ArticleNumber | Inventory ⇒ InventoryNumber |
| Article definition ⇒ ArticleName | Inventory ⇒ Description |
| Article definition ⇒ PurchasePrice | Inventory ⇒ DefaultPrice |
| Article definition ⇒ IsStockArticle | true |
| Article definition ⇒ IsObsolete | Inventory ⇒ Status <> Active |
| Article definition ⇒ MainSupplier ⇒ SupplierNumber | Inventory ⇒ SupplierDetails ⇒ SupplierId |
| Article definition ⇒ BarCode | Inventory ⇒ Crossreferences (alternateType = Barcode AND description = GTIN) ⇒ AlternateID |
| Article definition ⇒ SupplierArticleNumber | Inventory ⇒ SupplierDetails ⇒ SupplierItemId |
| Article definition ⇒ StatisticsNumber | Inventory ⇒ Intrastat ⇒ CN8 |
| Article definition ⇒ CountryOfOriginCode | Inventory ⇒ Intrastat ⇒ CountryOfOrigin |
| Structure article ⇒ Article Number | Kit specification ⇒ Kit inventory ID |
| Structure article ⇒ Article Name | Kit specification ⇒ Description |
| Structure article ⇒ Sub article number | Kit specification ⇒ Stock component line ⇒ Component ID |
| Structure article ⇒ Sub article name | Kit specification ⇒ Stock component line ⇒ Description |
| Structure article ⇒ Sub article quantity | Kit specification ⇒ Stock component line ⇒ Component quantity |
| Structure article ⇒ Type* | Kit specification ⇒ Is non stock |
* If the kit specification is a non stock article the corresponding article in Ongoing WMS will be a structure article, otherwise it will be a production article.
Filters
By default, only articles with the Visma.net field "Inventory ⇒ Type" set to "FinishedGoodItem" will be synced to Ongoing WMS.
Orders
An order in Visma.net may be used to create a delivery. These deliveries are mapped to Ongoing WMS, where they are called orders. Thus:
Order (Visma.net) ⇒ Delivery (Visma.net) ⇒ Order (Ongoing WMS)
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| OrderInfo ⇒ GoodsOwnerOrderId | SalesOrder ⇒ OrderNo |
| OrderInfo ⇒ GoodsOwnerOrderNumber | Shipment ⇒ ShipmentNumber |
| OrderInfo ⇒ TermsOfDelivery | Shipment ⇒ ShippingTerms ⇒ Description |
| OrderInfo ⇒ DeliveryDate | Shipment ⇒ ShipmentDate |
| OrderInfo ⇒ OrderType | Shipment ⇒ ShipmentdetailLines ⇒ OrderType |
| OrderInfo ⇒ ReferenceNumber | SalesOrder ⇒ CustomerOrder |
| OrderInfo ⇒ OrderRemark | SalesOrder ⇒ Description |
| Customer ⇒ OrganisationNumber | Customer ⇒ CorporateId |
| Customer ⇒ VATNumber | Customer ⇒ VatRegistrationId |
| Customer ⇒ ExternalCustomerCode | Shipment ⇒ Customer ⇒ InternalId |
| Customer ⇒ CustomerNumber | Shipment ⇒ Customer ⇒ Number |
| Customer ⇒ Name | Shipment ⇒ DeliveryContact ⇒ Name |
| Customer ⇒ Email | Shipment ⇒ DeliveryContact ⇒ Email |
| Customer ⇒ NotifyByEmail | false |
| Customer ⇒ MobilePhone | Shipment ⇒ DeliveryContact ⇒ Phone1 |
| Customer ⇒ NotifyBySMS | false |
| Customer ⇒ TelePhone | Shipment ⇒ DeliveryContact ⇒ Phone2 |
| Customer ⇒ Address | Shipment ⇒ deliveryAddress ⇒ addressLine1 |
| Customer ⇒ Address2 | Shipment ⇒ deliveryAddress ⇒ addressLine2 |
| Customer ⇒ Address3 | Shipment ⇒ deliveryAddress ⇒ addressLine3 |
| Customer ⇒ City | Shipment ⇒ deliveryAddress ⇒ City |
| Customer ⇒ CountryCode | Shipment ⇒ deliveryAddress ⇒ Country ⇒ Id |
| Customer ⇒ CountryStateCode | Shipment ⇒ deliveryAddress ⇒ County ⇒ Id |
| Customer ⇒ PostCode | Shipment ⇒ deliveryAddress ⇒ PostalCode |
| CommunicationInfo ⇒ FromSystemName | "Visma.net" |
| CommunicationInfo ⇒ ToSystemName | "Ongoing WMS" |
| CommunicationInfo ⇒ TransporterContractClass | No mapping. There is an option to add special logic which selects the transporter automatically based on the order. |
| ExternalOrderLineCode | Shipment ⇒ ShipmentDetailLine ⇒ LineNumber |
| NumberOfItems | Shipment ⇒ ShipmentDetailLine ⇒ OrderedQty |
| ArticleNumber | Shipment ⇒ ShipmentDetailLine ⇒ InventoryNumber |
| CurrencyCode | SalesOrder ⇒ Currency |
| ArticleName | Shipment ⇒ ShipmentDetailLine ⇒ Description |
| LinePrice | (SalesOrder ⇒ Line ⇒ UnitPrice) * (Shipment ⇒ ShipmentDetailLine ⇒ OrderedQty) |
Filters
By default, any orders matching the following filter in Visma.net is synced to Ongoing WMS.
| Visma.net field name | Default filter |
|---|---|
| Shipment ⇒ FromWarehouse ⇒ Id | No filter |
| Shipment ⇒ Status | "Open" |
| Shipment ⇒ ShipmentDetailLines ⇒ location ⇒ id | No filter |
| Shipment ⇒ ShipmentDetailLines ⇒ OrderType | "SO" |
Purchase orders
Purchase orders in Visma.net are mapped to purchase orders in Ongoing WMS. This allows the warehouse to report received goods to Visma.net.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| Purchase order ⇒ GoodsOwnerReference | PurchaseOrder ⇒ RequisitionRefNbr |
| Purchase order ⇒ GoodsOwnerOrderNumber | PurchaseOrder ⇒ OrderNbr |
| Purchase order ⇒ InDate | PurchaseOrder ⇒ PromisedOn |
| Purchase order ⇒ OrderDate | PurchaseOrder ⇒ Date |
| InOrderSupplier ⇒ SupplierName | PurchaseOrder ⇒ Supplier ⇒ Name |
| InOrderSupplier ⇒ SupplierNumber | PurchaseOrder ⇒ Supplier ⇒ Number |
| CommunicationInfo ⇒ FromSystemName | "Visma.net" |
| CommunicationInfo ⇒ ToSystemName | "Ongoing WMS" |
| Purchase order line ⇒ ArticleNumber | PurchaseOrder ⇒ Lines ⇒ Inventory ⇒ Number |
| Purchase order line ⇒ NumberOfItems | PurchaseOrder ⇒ Lines ⇒ OrderQty |
| Purchase order line ⇒ ExternalOrderLineCode | PurchaseOrder ⇒ Lines ⇒ LineNbr |
Filter
By default, only open purchase orders in Visma.net of type "Regular order" will be synced to Ongoing WMS.
Return Orders
A return order in Visma.net may be used to create a purchase order in Ongoing that will be marked as a return. Note that you cannot do returns on specific outbound orders in Ongoing if you want to report it back to Visma.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| Purchase order ⇒ GoodsOwnerOrderNumber | Shipment ⇒ ShipmentNumber |
| Purchase order ⇒ GoodsOwnerReference | salesOrder ⇒ orderNo |
| Purchase order ⇒ InDate | SalesOrder ⇒ Date |
| Purchase order ⇒ OrderDate | SalesOrder ⇒ Date |
| Purchase order ⇒ OrderRemark | SalesOrder ⇒ Description |
| Customer ⇒ CustomerNumber | Shipment ⇒ Customer ⇒ Number |
| Customer ⇒ Name | Shipment ⇒ DeliveryContact ⇒ Name |
| Customer ⇒ AddressEmail | Shipment ⇒ DeliveryContact ⇒ Email |
| Customer ⇒ MobilePhone | Shipment ⇒ DeliveryContact ⇒ Phone1 |
| Customer ⇒ TelePhone | Shipment ⇒ DeliveryContact ⇒ Phone2 |
| Customer ⇒ Address | Shipment ⇒ DeliveryAddress ⇒ AddressLine1 |
| Customer ⇒ Address2 | Shipment ⇒ DeliveryAddress ⇒ AddressLine2 |
| Customer ⇒ Address3 | Shipment ⇒ DeliveryAddress ⇒ AddressLine3 |
| Customer ⇒ City | Shipment ⇒ DeliveryAddress ⇒ City |
| Customer ⇒ CountryCode | Shipment ⇒ DeliveryAddress ⇒ Country ⇒ Id |
| Customer ⇒ PostCode | Shipment ⇒ DeliveryAddress ⇒ PostalCode |
| CommunicationInfo ⇒ FromSystemName | "Visma.net" |
| CommunicationInfo ⇒ ToSystemName | "Ongoing WMS" |
| ExternalOrderLineCode | Shipment ⇒ ShipmentDetailLine ⇒ LineNumber |
| NumberOfItems | Shipment ⇒ ShipmentDetailLine ⇒ OrderedQty |
| ArticleNumber | Shipment ⇒ ShipmentDetailLine ⇒ InventoryNumber |
Filters
By default, any return orders matching the following filter in Visma.net is synced to Ongoing WMS.
| Visma.net field name | Default filter |
|---|---|
| Shipment ⇒ FromWarehouse ⇒ Id | No filter |
| Shipment ⇒ Status | "Open" |
| Shipment ⇒ ShipmentDetailLines ⇒ location ⇒ id | No filter |
| Shipment ⇒ ShipmentDetailLines ⇒ OrderType | "RR","RC", "RM" |
| Shipment ⇒ ShipmentDetailLines ⇒ ShipmentType | No filter |
Production Orders
A kit assembly in Visma.net may be used to create a production order in Ongoing. Since a kit assembly only contains one assembled article number, the production order in Ongoing WMS will always contain only one production order line. If the structure of the kit assembly in Visma.net doesn't match the structure of the corresponding article in Ongoing WMS the latter will be updated by this sync.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| Production order ⇒ Production date | Kit assembly ⇒ Date |
| Production order ⇒ Comment | Kit assembly ⇒ Description |
| Production order line ⇒ Quantity to produce | Kit assembly ⇒ Quantity |
| Production order line ⇒ Article number to produce | Kit assembly ⇒ Item ID |
| Production article ⇒ Article number | Kit assembly ⇒ Item ID |
| Production article ⇒ Name | Kit assembly ⇒ Description |
| Production article ⇒ Sub article ⇒ Article number | Kit assembly ⇒ Stock component line ⇒ Item ID |
| Production article ⇒ Sub article ⇒ Article name | Kit assembly ⇒ Stock component line ⇒ Description |
| Production article ⇒ Sub article ⇒ Quantity | Kit assembly ⇒ Stock component line ⇒ Component quantity |
Filters
By default, any kit assemblies matching the following filter in Visma.net is synced to Ongoing WMS.
| Visma.net field name | Default filter |
|---|---|
| Kit assembly ⇒ Warehouse | No filter |
| Kit assembly ⇒ Status | Balanced |
| Kit assembly ⇒ Type | Production |
Functions based on user actions
Inbound deliveries
When a delivery is made to the warehouse, this will be recorded on a purchase order. This triggers a few calls to the Visma.net API. First a receipt ("kvittering") is created, recording that that purchase order has been received. The received quantities are also recorded on each line. It is possible that the received quantities differ from the advised quantities.
By default, all goods will automatically be released in Visma.net after it has been received in Ongoing WMS. It is possible opt out of this behavior.
Field mapping
The below table specifies where the information originates from in the Visma.net receipts which the integration creates.
| Visma.net receipt ("kvittering") field name | Source field |
|---|---|
| SupplierId | Visma.net ⇒ PurchaseOrder ⇒ Supplier ⇒ Number |
| LocationId | Visma.net ⇒ PurchaseOrde ⇒ Location ⇒ Name |
| WarehouseId | Specified when the integration is set up |
| hold | false |
| currency | Visma.net ⇒ PurchaseOrder ⇒ Currency |
| SupplierRef | Visma.net ⇒ PurchaseOrder ⇒ SupplierRef |
| Lines ⇒ poOrderLineNbr | Visma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ LineNbr |
| Lines ⇒ poOrderNbr | Visma.net ⇒ PurchaseOrder ⇒ OrderNbr |
| Lines ⇒ poOrderType | Visma.net ⇒ PurchaseOrder ⇒ OrderType |
| Lines ⇒ completePoLine | true |
| Lines ⇒ receiptQty | (Ongoing WMS ⇒ ReceivedInOrderLine ⇒ ReceivedNumberOfItems) (Visma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ QtyOnReceipts) |
| Lines ⇒ lineNbr | Visma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ LineNbr |
| Lines ⇒ lineType | ”GoodsForInventory” |
| Lines ⇒ warehouseId | Specified when the integration is set up |
| Lines ⇒ locationId | Visma.net ⇒ Warehouse (same warehouse as above) ⇒ Shiplocation ⇒ id |
| Lines ⇒ uom | Visma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ uom |
| Lines ⇒ branchId | Visma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ branch ⇒ number |
| Lines ⇒ inventoryId | Visma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ inventory ⇒ number |
Inbound deliveries of returned goods
When an inbound delivery that is marked as a return is made in Ongoing, the return order in Visma will be confirmed and the number of items returned will be set.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| Inorder ⇒ Purchase order ⇒ GoodsOwnerOrderNumber | Shipment ⇒ ShipmentNumber |
| Inorder ⇒ InorderOrderLine ⇒ LineNumber | Shipment ⇒ ShipmentDetailLine ⇒ LineNumber |
| Inorder ⇒ ReceivedInOrderLine ⇒ ReceivedNumberOfItems | Shipment ⇒ ShipmentDetailLine ⇒ ShippedQty |
Outbound deliveries
When an order has been set to status Sent or Collected in Ongoing, a few calls are made to the Visma.net API. These calls will confirm the delivery and update the delivered quantities on each order line in Visma.net.
If you intend to make partial deliveries, it is important to check that Visma.net is set to automatically create a back order for the remaining quantity.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| Order ⇒ OrderInfo ⇒ GoodsOwnerOrderNumber | Shipment ⇒ ShipmentNumber |
| Order ⇒ PickedOrderLine ⇒ LineNumber | Shipment ⇒ ShipmentDetailLine ⇒ LineNumber |
| Order ⇒ PickedOrderLine ⇒ PickedNumberOfItems | Shipment ⇒ ShipmentDetailLine ⇒ ShippedQty |
Production of production orders
Once the production order line has been produced and the production order status is updated to Finished the corresponding kit assembly in Visma will be updated with the produced amount and then released.
Note: If the warehouse has manually created production orders in Ongoing the inventory changes that the production of those orders results in will be reported back as inventory adjustments.
Inventory adjustments
If an inventory adjustment has been made in Ongoing WMS, it is possible to create and release a corresponding inventory issue in Visma. This will ensure that the stock in both systems is always up to date.
Note: For this to work each inventory adjustment in Ongoing needs to be given a reason, where the reason code must correspond to a reason code in Visma. To find the reason codes in Visma, navigate to Inventory ⇒ Preferences ⇒ Reason Codes.
The reason codes in question are those where "Usage" is "Issue" (sv: "Lageruttag", no: "Årsak").
For the integration to work you will need to copy those reason codes and create them in Ongoing. This can be done by navigating to Registers ⇒ Adjustment Cause.
These reasons will then be available when creating an inventory adjustment. It is also possible to enforce that the adjustments always are provided with an adjustment cause, please contact your contact at Ongoing for this.
Note: Do you only ever use a single reason code for inventory issues in Visma? It is possible to configure the integration so that all inventory adjustments are reported back to Visma using this code. This saves the warehouse from having to manually set the reason code on all inventory transactions that they do.
Field mapping
| Visma.net field name | Ongoing WMS field name |
|---|---|
| Issue ⇒ Date | InventoryTransaction ⇒ InventoryTime |
| Issue ⇒ Description | InventoryTransaction ⇒ ItemComment |
| Issue ⇒ ExternalReference | InventoryTransaction ⇒ InventoryId |
| Issue ⇒ Date | InventoryTransaction ⇒ InventoryTime |
| Issue line ⇒ Description | InventoryTransaction ⇒ AdjustmentCause or ItemComment |
| Issue line ⇒ InventoryNumber | InventoryTransaction ⇒ ArticleNumber |
| Issue line ⇒ Quantity | InventoryTransaction ⇒ Abs(ChangesNumberOfItems) |
| Issue line ⇒ ReasonCode | InventoryTransation ⇒ AdjustmentCode |
| Issue line ⇒ TranType | Issue or Return, based on if the adjustment increased or decreased the stock |
| Issue line ⇒ WarehouseId | Specified when the integration is set up |
Preparations
To configure this integration Ongoing WMS will need username and password to Visma.net API. From these credentials Ongoing WMS will generate a bearer token to use when accessing the API. If the API user has access to several companies, Ongoing WMS will also need the company ID and name to use as context. If you are unable to get this information, please ask your Visma reseller.