/API/controller/api/v1/customer is unable to find payment Method

[ReinderReinders]

I am attempting to create a Customer using the POST API call. I get a 500 error:

{
  "name": {
    "value": "testpaymentmethod1"
  },
  "defaultPaymentMethod": {
    "value": {
      "paymentMethodId": {
        "value": "1"
      }
    }
  }
}

I am certain that payment Method 1 is present, I can even retrieve it using the paymentmethod endpoint:

I am guessing something broke in the underlying query? Both values are a string "1" and there is no truncation or anything like that. There are no other ID properties so I'm not using the wrong ID.

Please fix, as this is a central point of our implementation and without this fix, I cannot continue.

[bjrkis]

I'm also having this issue when trying to POST a new customer. Payment method is not doing it despite existing in the Visma ERP.

Response: InternalServerError {"message":"VismaId: 6e4ccc27-f873-4d4e-8a14-410ae61564aa. Error inserting the customer. Object reference not set to an instance of an object."}.

"defaultPaymentMethod":
{
"paymentMethodId":{"value":"01"},
"isDefault":{"value":false}
}

[bjrkis]

Also having the same issue with glAccount. The rest seems to work fine.

Response: InternalServerError {"message":"VismaId: 17b053e2-1e50-4b74-86f2-3b23f0cca81f. Error inserting the customer. Object reference not set to an instance of an object."}.

"glAccounts":{"sales":{"value":null}}

[ReinderReinders]

Update on above issue: I WAS able to post a Customer with payment method 6, which is a debtor payment method, unlike 1 which is a creditor payment method. I'm not sure if that is a business rule of Visma.net or just the way our business analysts have configured our Visma.net environment. This issue would thus same to be the mirror image of the issue I reported here:

https://community.visma.com/t5/Forum-in-Developers-Visma-net/api-v1-paymentmethod-only-returns-credi...

the GET on the payment methods API only returns creditor payment methods, not debtor payment methods.

the POST on the customer API only accepts debtor payment methods, not creditor payment methods.

I still believe that other issue (and this one) need to be resolved. I am unable to judge if this is a business rule or an implementation error (I don't know enough about the business/data model).