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. For sales orders the integration uses the new sales orders API.
Note that the information in this document might differ from your integration if any special requests were made during the implementation of the integration.
Get started
In order to setup the integration you will need perform the following steps:
-
Authorize the Ongoing WMS app in the Visma.net app store.
-
Accept the application permissions by clicking the Integrate button, and then by confirming the permissions in the popup.
-
Click the "Get App" button in the app store:
This will redirect you to the a website where you can start providing the information needed by Ongoing WMS.
-
Provide your Tenant ID in the input and click Save. The Tenant ID is required by the integration to fetch data from Visma.net. The Tenant ID can be found in the Visma.net app store by clicking on your name/organization on the top right corner. You can easily copy the Tenant ID to the clipboard using the provided copy icon:
-
When the Tenant ID has been verified you will be redirected to the Ongoing landing page:
Here you will be asked to provide credentials for the WMS where you want to setup the integration. In the box marked System you can provide either the URL of the WMS, for example https://demo.ongoingsystems.se/demo/, or you can provide the Ongoing customer ID which can be found using the support info button at the bottom of the page when you are logged in on your WMS:
Username and Password corresponds to the user and password for the WMS.
-
-
When the requested permissions are accepted you will be redirected to the previously provided Ongoing WMS.
-
As the final step before creating the integration in your Ongoing WMS you can fine tune the integration settings. Once you are done click the Create button to create the integration.
Note that the final step to create the integration in your Ongoing WMS requires some settings to be configured. For example if you want to update shipments in Visma.net once they have been handled in Ongoing WMS you will need to provide a package type to be used. If there were no existing package types when you started setting up the integration you can simply create them in Visma.net and then trigger a reload of data from Visma.net using the provided button.
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
There are two ways of syncing orders from Visma.net to Ongoing WMS:
-
Sales orders in Visma.net are used to create shipments. These shipments are mapped to Ongoing WMS, where they are called orders. Thus:
Sales order (Visma.net) ⇒ Shipment (Visma.net) ⇒ Order (Ongoing WMS)
This is the most used way of syncing orders from Visma.net to Ongoing WMS.
-
Sales orders in Visma.net are mapped to Ongoing WMS, where they are called orders. Thus:
Sales order (Visma.net) ⇒ Order (Ongoing WMS)
This way of syncing orders from Visma.net to Ongoing WMS is mainly used by companies using cross-docking.
Field mapping (Shipment ⇒ Order)
| 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. |
| OrderRow ⇒ ExternalOrderLineCode | Shipment ⇒ ShipmentDetailLine ⇒ LineNumber |
| OrderRow ⇒ NumberOfItems | Shipment ⇒ ShipmentDetailLine ⇒ OrderedQty |
| OrderRow ⇒ ArticleNumber | Shipment ⇒ ShipmentDetailLine ⇒ InventoryNumber |
| OrderRow ⇒ CurrencyCode | SalesOrder ⇒ Currency |
| OrderRow ⇒ ArticleName | Shipment ⇒ ShipmentDetailLine ⇒ Description |
| OrderRow ⇒ LinePrice | (SalesOrder ⇒ Line ⇒ UnitPrice) * (Shipment ⇒ ShipmentDetailLine ⇒ OrderedQty) |
Filters (Shipments)
By default, any shipments matching the following filters in Visma.net are 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" |
Field mapping (Sales Order ⇒ Order)
| Ongoing WMS field name | Visma.net field name |
|---|---|
| OrderInfo ⇒ GoodsOwnerOrderId | SalesOrder ⇒ OrderNo |
| OrderInfo ⇒ GoodsOwnerOrderNumber | SalesOrder ⇒ OrderNo |
| OrderInfo ⇒ TermsOfDelivery | SalesOrder ⇒ ShippingTerms ⇒ Description |
| OrderInfo ⇒ OrderType | SalesOrder ⇒ 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. |
| OrderRow ⇒ ExternalOrderLineCode | SalesOrder ⇒ Line ⇒ LineNbr |
| OrderRow ⇒ NumberOfItems | SalesOrder ⇒ Line ⇒ Quantity |
| OrderRow ⇒ ArticleNumber | SalesOrder ⇒ Line ⇒ Inventory ⇒ Number |
| OrderRow ⇒ CurrencyCode | SalesOrder ⇒ Currency |
| OrderRow ⇒ ArticleName | SalesOrder ⇒ Line ⇒ Inventory ⇒ Description |
| OrderRow ⇒ LinePrice | (SalesOrder ⇒ Line ⇒ UnitCost) * (SalesOrder ⇒ Line ⇒ Quantity) |
| OrderRow ⇒ CustomerLinePrice | (SalesOrder ⇒ Line ⇒ UnitPrice) * (SalesOrder ⇒ Line ⇒ Quantity) |
| OrderRow ⇒ Discount | SalesOrder ⇒ Line ⇒ DiscountPercent |
| OrderRow ⇒ OrderLineTotalCustomsValue | SalesOrder ⇒ Line ⇒ ExtPrice |
| OrderRow ⇒ OrderLineComment | SalesOrder ⇒ Line ⇒ LineDescription |
Filters (Sales Orders)
By default, any sales orders matching the following filters in Visma.net are synced to Ongoing WMS.
| Visma.net field name | Default filter |
|---|---|
| SalesOrder ⇒ Lines ⇒ Warehouse ⇒ Id | No filter |
| SalesOrder ⇒ Status | "Open" |
| SalesOrder ⇒ Lines ⇒ Location ⇒ Id | No filter |
| SalesOrder ⇒ OrderType | "SO" |
| SalesOrder ⇒ Lines ⇒ Operation | "Issue" |
Purchase orders
Purchase orders in Visma.net are fetched to Ongoing WMS and a corresponding purchase order in Ongoing WMS is created or updated. This allows the warehouse to receive goods on purchase orders in Ongoing WMS while the integration reports inbound deliveries to Visma.net and connects them to corresponding purchase order in Visma.net.
Inventory transfer orders in Visma.net with the destination warehouse set to the warehouse Ongoing WMS handles can optionally be fetched to Ongoing WMS as purchase orders. This allows the warehouse workers to receive goods using the same efficient process as they receive goods on purchase orders. When goods have been received on the purchase order in Ongoing WMS the corresponding inventory transfer in Visma.net will be updated with the correct quantities and released.
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 created or updated in Ongoing WMS. They also need to have at least one line marked for delivery to the warehouse connected to Ongoing WMS.
Supplier returns
If a return has to me made from the warehouse to a supplier a purchase receipt of the type "Return" can be created in Visma.net. The purchase receipt can be synced to Ongoing WMS where it will show up as an order. By default, this feature is turned off.
Field mapping
| Ongoing WMS field name | Visma.net field name |
|---|---|
| OrderInfo ⇒ GoodsOwnerOrderId | PurchaseReceipt ⇒ ReceiptNbr |
| OrderInfo ⇒ GoodsOwnerOrderNumber | PurchaseReceipt ⇒ "SR" + ReceiptNbr |
| Customer ⇒ CustomerNumber | PurchaseReceipt ⇒ Supplier ⇒ SupplierNumber |
| Customer ⇒ Name | PurchaseReceipt ⇒ Supplier ⇒ Name |
| CommunicationInfo ⇒ FromSystemName | "Visma.net" |
| CommunicationInfo ⇒ ToSystemName | "Ongoing WMS" |
| OrderRow ⇒ ExternalOrderLineCode | PurchaseReceipt ⇒ Line ⇒ LineNumber |
| OrderRow ⇒ NumberOfItems | PurchaseReceipt ⇒ Line ⇒ ReceiptQty |
| OrderRow ⇒ ArticleNumber | PurchaseReceipt ⇒ Line ⇒ Inventory ⇒ Number |
| OrderRow ⇒ ArticleName | PurchaseReceipt ⇒ Line ⇒ Inventory ⇒ Description |
| OrderRow ⇒ Discount | PurchaseReceipt ⇒ Line ⇒ DiscountPercent |
| OrderRow ⇒ LinePrice | (PurchaseReceipt ⇒ Line ⇒ UnitCost) * (PurchaseReceipt ⇒ Line ⇒ ReceiptQty) |
| OrderRow ⇒ CustomerLinePrice | (PurchaseReceipt ⇒ Line ⇒ UnitCost) * (PurchaseReceipt ⇒ Line ⇒ ReceiptQty) |
| OrderRow ⇒ OrderLineTotalCustomsValue | PurchaseReceipt ⇒ Line ⇒ ExtCost |
| OrderRow ⇒ CurrencyCode | PurchaseReceipt ⇒ Currency |
Filters
By default, any orders matching the following filter in Visma.net is synced to Ongoing WMS.
| Visma.net field name | Default filter |
|---|---|
| Shipment ⇒ Warehouse ⇒ Id | No filter |
| Shipment ⇒ Status | Balanced |
Working with returns to the warehouse
There are three ways of working with returns in Ongoing WMS. Performing a return directly on an order, using a return order connected to an order or using a purchase order of return type. The first two are mainly used for consumer returns when you know which original order you return based on. The third is used for B2B returns when you do not know the original order. With the integration to Ongoing WMS, you can work in all three ways. The choice you make depends on the type of returns you perform.
A return order in Visma.net is by default used to create a purchase order in Ongoing WMS that will be marked as a return. This is useful when you receive a return from a company which has been advised prior to shipment and it cannot be linked to a specific order.
Optionally a return order can be created in Ongoing WMS. This is useful if you work with advised returns that can be linked to a specific order. For example, if you ship to consumers which must use a return management system prior to returning.
If you perform a return on an order in Ongoing WMS it can optionally be reported as an inventory issue in Visma.net and you will have the goods in stock again. The inventory issue will have a comment indicating to which original shipment/order it belongs but no hard linkage. You will have to manually perform additional actions such as repay the customer. To turn this on you will have to activate the sending of inventory changes from Ongoing WMS to Visma.net.
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 filters in Visma.net are 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 in Ongoing WMS. This triggers a few calls to the Visma.net API. First a receipt (se: "inleverans", no: "mottak") is created. The received quantities are also recorded on each line and connected to the purchase order in Visma.net.
It is possible that the received quantities differ from the advised quantities. It is also possible to receive multiple times on the same purchase order in Ongoing WMS which will create multiple receipts in Visma.net. By default, it is not possible to create many receipts on the same purchase order line in Visma.net.
Ongoing WMS sends a complete signal to Visma.net for each purchase order line we create a receipt for. When all lines have been completed Visma.net automatically closes the purchase order. When the purchase order has been automatically or manually closed it is no longer possible to create more receipts in Visma.net from Ongoing WMS.
Optionally, all goods can automatically be released in Visma.net after it has been received in Ongoing WMS.
Field mapping
The below table specifies where the information originates from in the Visma.net receipts which the integration creates.
| Visma.net receipt (se: "inleverans", no: "mottak") 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. If the order in Ongoing WMS is mapped from a shipment in Visma.net these calls will confirm the shipment and update the delivered quantities on each order line in Visma.net. If the order is mapped from a sales order without any shipments in Visma.net a call to create a shipment will first be made. Then a call to add sales order lines to the shipment will be made. Then calls to confirm the shipment and update the delivered quantities on each order line in Visma.net will be made.
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: "Vareuttak").
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 |