Visma logo

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

Show field mapping

Ongoing WMS field name Visma.net field name
SupplierNameName
SupplierNumberNumber
Address ⇒ NameName
Address ⇒ AddressSupplierAddress ⇒ AddressLine1
Address ⇒ Address2SupplierAddress ⇒ AddressLine2
Address ⇒ Address3SupplierAddress ⇒ AddressLine3
Address ⇒ CitySupplierAddress ⇒ City
Address ⇒ PostCodeSupplierAddress ⇒ PostalCode
Address ⇒ CountryCodeSupplierAddress ⇒ Country ⇒ Id
Address ⇒ MobilePhoneSupplierContact ⇒ Phone2
Address ⇒ TelePhoneSupplierContact ⇒ Phone1
Address ⇒ EmailSupplierContact ⇒ Email
Address ⇒ RemarkSupplierContact ⇒ 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:

No specific action is taken for the class Not numbered. Lot corresponds to a batch in Ongoing WMS, and if an order row in Visma.net contains an allocation with lot specified the integration will ensure that the corresponding created order row in Ongoing is setup with a filter so that an item with the specific batch is picked. Similar logic is applied for serial number. If the order rows in Visma.net does not contain any allocations, but the lot serial class is either lot or serial numbered for an order row that information will be reported to Visma.net when the order in Ongoing WMS has been picked.
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

Show field mapping

Ongoing WMS field name Visma.net field name
Article definition ⇒ ArticleNumberInventory ⇒ InventoryNumber
Article definition ⇒ ArticleNameInventory ⇒ Description
Article definition ⇒ PurchasePriceInventory ⇒ DefaultPrice
Article definition ⇒ IsStockArticletrue
Article definition ⇒ IsObsoleteInventory ⇒ Status <> Active
Article definition ⇒ MainSupplier ⇒ SupplierNumberInventory ⇒ SupplierDetails ⇒ SupplierId
Article definition ⇒ BarCodeInventory ⇒ Crossreferences (alternateType = Barcode AND description = GTIN) ⇒ AlternateID
Article definition ⇒ SupplierArticleNumberInventory ⇒ SupplierDetails ⇒ SupplierItemId
Article definition ⇒ StatisticsNumberInventory ⇒ Intrastat ⇒ CN8
Article definition ⇒ CountryOfOriginCodeInventory ⇒ Intrastat ⇒ CountryOfOrigin
Structure article ⇒ Article NumberKit specification ⇒ Kit inventory ID
Structure article ⇒ Article NameKit specification ⇒ Description
Structure article ⇒ Sub article numberKit specification ⇒ Stock component line ⇒ Component ID
Structure article ⇒ Sub article nameKit specification ⇒ Stock component line ⇒ Description
Structure article ⇒ Sub article quantityKit 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

Show field mapping

Ongoing WMS field name Visma.net field name
OrderInfo ⇒ GoodsOwnerOrderIdSalesOrder ⇒ OrderNo
OrderInfo ⇒ GoodsOwnerOrderNumberShipment ⇒ ShipmentNumber
OrderInfo ⇒ TermsOfDeliveryShipment ⇒ ShippingTerms ⇒ Description
OrderInfo ⇒ DeliveryDateShipment ⇒ ShipmentDate
OrderInfo ⇒ OrderTypeShipment ⇒ ShipmentdetailLines ⇒ OrderType
OrderInfo ⇒ ReferenceNumberSalesOrder ⇒ CustomerOrder
OrderInfo ⇒ OrderRemarkSalesOrder ⇒ Description
Customer ⇒ OrganisationNumberCustomer ⇒ CorporateId
Customer ⇒ VATNumberCustomer ⇒ VatRegistrationId
Customer ⇒ ExternalCustomerCodeShipment ⇒ Customer ⇒ InternalId
Customer ⇒ CustomerNumberShipment ⇒ Customer ⇒ Number
Customer ⇒ NameShipment ⇒ DeliveryContact ⇒ Name
Customer ⇒ EmailShipment ⇒ DeliveryContact ⇒ Email
Customer ⇒ NotifyByEmailfalse
Customer ⇒ MobilePhoneShipment ⇒ DeliveryContact ⇒ Phone1
Customer ⇒ NotifyBySMSfalse
Customer ⇒ TelePhoneShipment ⇒ DeliveryContact ⇒ Phone2
Customer ⇒ AddressShipment ⇒ deliveryAddress ⇒ addressLine1
Customer ⇒ Address2Shipment ⇒ deliveryAddress ⇒ addressLine2
Customer ⇒ Address3Shipment ⇒ deliveryAddress ⇒ addressLine3
Customer ⇒ CityShipment ⇒ deliveryAddress ⇒ City
Customer ⇒ CountryCodeShipment ⇒ deliveryAddress ⇒ Country ⇒ Id
Customer ⇒ CountryStateCodeShipment ⇒ deliveryAddress ⇒ County ⇒ Id
Customer ⇒ PostCodeShipment ⇒ deliveryAddress ⇒ PostalCode
CommunicationInfo ⇒ FromSystemName"Visma.net"
CommunicationInfo ⇒ ToSystemName"Ongoing WMS"
CommunicationInfo ⇒ TransporterContractClassNo mapping. There is an option to add special logic which selects the transporter automatically based on the order.
ExternalOrderLineCodeShipment ⇒ ShipmentDetailLine ⇒ LineNumber
NumberOfItemsShipment ⇒ ShipmentDetailLine ⇒ OrderedQty
ArticleNumberShipment ⇒ ShipmentDetailLine ⇒ InventoryNumber
CurrencyCodeSalesOrder ⇒ Currency
ArticleNameShipment ⇒ 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.

Show filters

Visma.net field name Default filter
Shipment ⇒ FromWarehouse ⇒ IdNo filter
Shipment ⇒ Status"Open"
Shipment ⇒ ShipmentDetailLines ⇒ location ⇒ idNo 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

Show field mapping

Ongoing WMS field name Visma.net field name
Purchase order ⇒ GoodsOwnerReferencePurchaseOrder ⇒ RequisitionRefNbr
Purchase order ⇒ GoodsOwnerOrderNumberPurchaseOrder ⇒ OrderNbr
Purchase order ⇒ InDatePurchaseOrder ⇒ PromisedOn
Purchase order ⇒ OrderDatePurchaseOrder ⇒ Date
InOrderSupplier ⇒ SupplierNamePurchaseOrder ⇒ Supplier ⇒ Name
InOrderSupplier ⇒ SupplierNumberPurchaseOrder ⇒ Supplier ⇒ Number
CommunicationInfo ⇒ FromSystemName"Visma.net"
CommunicationInfo ⇒ ToSystemName"Ongoing WMS"
Purchase order line ⇒ ArticleNumberPurchaseOrder ⇒ Lines ⇒ Inventory ⇒ Number
Purchase order line ⇒ NumberOfItemsPurchaseOrder ⇒ Lines ⇒ OrderQty
Purchase order line ⇒ ExternalOrderLineCodePurchaseOrder ⇒ 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

Show field mapping

Ongoing WMS field name Visma.net field name
Purchase order ⇒ GoodsOwnerOrderNumberShipment ⇒ ShipmentNumber
Purchase order ⇒ GoodsOwnerReferencesalesOrder ⇒ orderNo
Purchase order ⇒ InDateSalesOrder ⇒ Date
Purchase order ⇒ OrderDateSalesOrder ⇒ Date
Purchase order ⇒ OrderRemarkSalesOrder ⇒ Description
Customer ⇒ CustomerNumberShipment ⇒ Customer ⇒ Number
Customer ⇒ NameShipment ⇒ DeliveryContact ⇒ Name
Customer ⇒ AddressEmailShipment ⇒ DeliveryContact ⇒ Email
Customer ⇒ MobilePhoneShipment ⇒ DeliveryContact ⇒ Phone1
Customer ⇒ TelePhoneShipment ⇒ DeliveryContact ⇒ Phone2
Customer ⇒ AddressShipment ⇒ DeliveryAddress ⇒ AddressLine1
Customer ⇒ Address2Shipment ⇒ DeliveryAddress ⇒ AddressLine2
Customer ⇒ Address3Shipment ⇒ DeliveryAddress ⇒ AddressLine3
Customer ⇒ CityShipment ⇒ DeliveryAddress ⇒ City
Customer ⇒ CountryCodeShipment ⇒ DeliveryAddress ⇒ Country ⇒ Id
Customer ⇒ PostCodeShipment ⇒ DeliveryAddress ⇒ PostalCode
CommunicationInfo ⇒ FromSystemName"Visma.net"
CommunicationInfo ⇒ ToSystemName"Ongoing WMS"
ExternalOrderLineCodeShipment ⇒ ShipmentDetailLine ⇒ LineNumber
NumberOfItemsShipment ⇒ ShipmentDetailLine ⇒ OrderedQty
ArticleNumberShipment ⇒ ShipmentDetailLine ⇒ InventoryNumber

Filters

By default, any return orders matching the following filter in Visma.net is synced to Ongoing WMS.

Show filters

Visma.net field name Default filter
Shipment ⇒ FromWarehouse ⇒ IdNo filter
Shipment ⇒ Status"Open"
Shipment ⇒ ShipmentDetailLines ⇒ location ⇒ idNo filter
Shipment ⇒ ShipmentDetailLines ⇒ OrderType"RR","RC", "RM"
Shipment ⇒ ShipmentDetailLines ⇒ ShipmentTypeNo 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

Show field mapping

Ongoing WMS field name Visma.net field name
Production order ⇒ Production dateKit assembly ⇒ Date
Production order ⇒ CommentKit assembly ⇒ Description
Production order line ⇒ Quantity to produceKit assembly ⇒ Quantity
Production order line ⇒ Article number to produceKit assembly ⇒ Item ID
Production article ⇒ Article numberKit assembly ⇒ Item ID
Production article ⇒ NameKit assembly ⇒ Description
Production article ⇒ Sub article ⇒ Article numberKit assembly ⇒ Stock component line ⇒ Item ID
Production article ⇒ Sub article ⇒ Article nameKit assembly ⇒ Stock component line ⇒ Description
Production article ⇒ Sub article ⇒ QuantityKit assembly ⇒ Stock component line ⇒ Component quantity

Filters

By default, any kit assemblies matching the following filter in Visma.net is synced to Ongoing WMS.

Show filters

Visma.net field name Default filter
Kit assembly ⇒ WarehouseNo filter
Kit assembly ⇒ StatusBalanced
Kit assembly ⇒ TypeProduction

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.

Show field mapping

Visma.net receipt ("kvittering") field name Source field
SupplierIdVisma.net ⇒ PurchaseOrder ⇒ Supplier ⇒ Number
LocationIdVisma.net ⇒ PurchaseOrde ⇒ Location ⇒ Name
WarehouseIdSpecified when the integration is set up
holdfalse
currencyVisma.net ⇒ PurchaseOrder ⇒ Currency
SupplierRefVisma.net ⇒ PurchaseOrder ⇒ SupplierRef
Lines ⇒ poOrderLineNbrVisma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ LineNbr
Lines ⇒ poOrderNbrVisma.net ⇒ PurchaseOrder ⇒ OrderNbr
Lines ⇒ poOrderTypeVisma.net ⇒ PurchaseOrder ⇒ OrderType
Lines ⇒ completePoLinetrue
Lines ⇒ receiptQty(Ongoing WMS ⇒ ReceivedInOrderLine ⇒ ReceivedNumberOfItems)
(Visma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ QtyOnReceipts)
Lines ⇒ lineNbrVisma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ LineNbr
Lines ⇒ lineType”GoodsForInventory”
Lines ⇒ warehouseIdSpecified when the integration is set up
Lines ⇒ locationIdVisma.net ⇒ Warehouse (same warehouse as above) ⇒ Shiplocation ⇒ id
Lines ⇒ uomVisma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ uom
Lines ⇒ branchIdVisma.net ⇒ PurchaseOrder ⇒ PurchaseOrderLine ⇒ branch ⇒ number
Lines ⇒ inventoryIdVisma.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

Show field mapping

Ongoing WMS field name Visma.net field name
Inorder ⇒ Purchase order ⇒ GoodsOwnerOrderNumberShipment ⇒ ShipmentNumber
Inorder ⇒ InorderOrderLine ⇒ LineNumberShipment ⇒ ShipmentDetailLine ⇒ LineNumber
Inorder ⇒ ReceivedInOrderLine ⇒ ReceivedNumberOfItemsShipment ⇒ 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

Show field mapping

Ongoing WMS field name Visma.net field name
Order ⇒ OrderInfo ⇒ GoodsOwnerOrderNumberShipment ⇒ ShipmentNumber
Order ⇒ PickedOrderLine ⇒ LineNumberShipment ⇒ ShipmentDetailLine ⇒ LineNumber
Order ⇒ PickedOrderLine ⇒ PickedNumberOfItemsShipment ⇒ 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 InventoryPreferencesReason Codes.

location of Reasons Codes button in Visma

The reason codes in question are those where "Usage" is "Issue" (sv: "Lageruttag", no: "Årsak").

list of Reason Codes

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 RegistersAdjustment 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

Show field mapping

Visma.net field name Ongoing WMS field name
Issue ⇒ DateInventoryTransaction ⇒ InventoryTime
Issue ⇒ DescriptionInventoryTransaction ⇒ ItemComment
Issue ⇒ ExternalReferenceInventoryTransaction ⇒ InventoryId
Issue ⇒ DateInventoryTransaction ⇒ InventoryTime
Issue line ⇒ DescriptionInventoryTransaction ⇒ AdjustmentCause or ItemComment
Issue line ⇒ InventoryNumberInventoryTransaction ⇒ ArticleNumber
Issue line ⇒ QuantityInventoryTransaction ⇒ Abs(ChangesNumberOfItems)
Issue line ⇒ ReasonCodeInventoryTransation ⇒ AdjustmentCode
Issue line ⇒ TranTypeIssue or Return, based on if the adjustment increased or decreased the stock
Issue line ⇒ WarehouseIdSpecified 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.