OverrideContact: false gives incorrect details

[JohanFriedrichsen]

In our current order integration we have an option that controls the overrideContact flag. Regardless of that setting is true or false we are sending contact details on the order if those are available in the order source (I don't have the reason why this is done).

The result if we create an order with overrideContact: false is that the order is created with the supplied contact details even though the contact shouldn't be overridden. The bigger problem is that the next order you create for the same customer will also inherit the same details even if the order is done manually via the GUI.

1. Is it intended that supplied contact details takes precedence over the override flag? If so this needs to be documented.
2. It can be argued that you shouldn't send both details and override: false but it isn't documented that you can't. It would be OK if it only affected the current order but since it also affects future orders it feels that the API should handle it better.
3. Does the SalesOrder service handle this type of behaviour better?

[Yıldırım]

Please send your payload and request URL by specifying the operation type.

[JohanFriedrichsen]

HTTP POST to https://integration.visma.net/API/controller/api/v1/salesorder

{
"orderType": {
"value": "SO"
},
"orderNumber": {
"value": "007-75"
},
"customerVATZone": {
"value": "01"
},
"soBillingContact": {
"value": {
"overrideContact": {
"value": false
},
"name": {
"value": "Kajsa Testar"
},
"attention": {},
"email": {
"value": "external.accounts@sharespine.com"
},
"phone1": {
"value": "0000000000"
},
"phone2": {},
"fax": {}
}
},
"soBillingAddress": {
"value": {
"overrideAddress": {
"value": false
},
"addressLine1": {
"value": "PB adress"
},
"addressLine2": {},
"postalCode": {
"value": "45132"
},
"city": {
"value": "Uddevalla"
},
"county": {},
"countryId": {
"value": "SE"
}
}
},
"soShippingContact": {
"value": {
"overrideContact": {
"value": false
},
"name": {
"value": "Kajsa Testar"
},
"attention": {},
"email": {},
"phone1": {
"value": "0000000000"
},
"phone2": {},
"fax": {}
}
},
"soShippingAddress": {
"value": {
"overrideAddress": {
"value": false
},
"addressLine1": {
"value": "PB adress"
},
"addressLine2": {},
"postalCode": {
"value": "45132"
},
"city": {
"value": "Uddevalla"
},
"county": {},
"countryId": {
"value": "SE"
}
}
},
"date": {
"value": "2023-05-09T10:45:39.000"
},
"shipVia": {
"value": "DHL"
},
"branchNumber": {
"value": "1 "
},
"printDescriptionOnInvoice": {
"value": false
},
"printNoteOnExternalDocuments": {
"value": false
},
"printNoteOnInternalDocuments": {
"value": false
},
"note": {
"value": "."
},
"currency": {
"value": "SEK"
},
"customer": {
"value": "10990"
},
"status": {
"value": "open"
},
"hold": {
"value": false
},
"lines": [
{
"operation": "Insert",
"warehouse": {
"value": "2"
},
"inventoryNumber": {
"value": "test123"
},
"lineDescription": {
"value": "En mycket fin testprodukt"
},
"quantity": {
"value": 1.0
},
"unitPrice": {
"value": 15.2
}
}
]
}

[Magnus Johnsen]

Hi,

We'll test this and get back to you, is there a reason you are using v1 instead of v2?

[JohanFriedrichsen]

Correction: the problem occurs with SalesOrder but not with SalesOrderv2

It is the contacts that are affected. If "overrideContact" = false is combined with additional values (see below) on the first SO for a customer these values will be used on this SO and every consecutive SO, regardless of if it is created via API or manually. 

"soBillingContact": {

"value": {

"overrideContact": {

"value": false

},

"name": {

"value": "Billing Contact"

},

"attention": {},

"email": {

"value": "billing.contact@mail.com"

},

"phone1": {},

"phone2": {},

"fax": {}

}

},

It can be argued that override and extra values shouldn't be used at the same time but there is nothing stopping it (tehcnically or in the docs). The effects are also very problematic since it will affect every future SO.

Regarding the use of v1 over v2: we had prior to this no urgent reason to move to v2 since the focus was on the initial SalesOrderService timeline. But since that has been pushed we have to rethink what we need to do.

[JohanFriedrichsen]

No, there is no technical reason. I believe that my collegue have verified this behaviour manually with v2 also.