When creating a SupplierInvoice via API Service to Service error GL account settings

[ExactGebruiker]

Hi,

Since the 30th of May 2023, we have been getting an error for some invoices we have been trying to create via the Service API.

The error we keep getting for some invoices is 

'Supplier transactions' record raised at least one error. Please review the errors.\r\nMissing taxable, non-taxable, EU or import accounts. Check the GL account settings for the item, supplier and supplier class\r\n"

When changing the GL account, we indeed sometimes get to create the invoice, but this issue has been occuring for mutltiple of our companies (contexts) and within the same company it is not consistent.

For example, one invoice we try to create is the following:

{
    "documentType": {
        "value": "Invoice"
    },
    "hold": {
        "value": false
    },
    "date": {
        "value": "2023-06-02T00:00:00.000Z"
    },
    "supplierReference": {
        "value": "7792639-Declaraties juni"
    },
    "description": {
        "value": "7792639-Declaraties juni"
    },
    "supplierNumber": {
        "value": "25008"
    },
    "currencyId": {
        "value": "EUR"
    },
    "branchNumber": {
        "value": "01"
    },
    "paymentMethod": {
        "value": "2"
    },
    "taxDetailLines": [],
    "invoiceLines": [
        {
            "operation": "Insert",
            "lineNumber": {
                "value": 1
            },
            "transactionDescription": {
                "value": "period screening"
            },
            "costInCurrency": {
                "value": 33.85
            },
            "accountNumber": {
                "value": "4199"
            },
            "vatCodeId": [],
            "branchNumber": {
                "value": "01"
            }
        }
    ],
    "overrideNumberSeries": {
        "value": false
    },
    "validateLineDetails": {
        "value": true
    }
}

And we get the before mentioned error. When changing the accountNumber value to '4504' for example, the invoice is created. In other companies other accounts are the problem.

This process has been working no problem for the last 3 months for all of our companies, but since the 30th opf May, it gives the error.

Foes anyone know why this is happening?

Thanks!

Izan

[Magnus Johnsen]

Hi,

If we start by looking at one of the companies, could you please try to enter it with the same account in the UI and the API.

Could you please make sure for the example above with supplier 25008 that all mandatory accounts are filled in? 

[ExactGebruiker]

Hi,

This error mainly occurs with purchase invoices made for Employees. My example concerned an employee, and when I change the supplierId to one of an actual supplier, then it does work.

Also, I am pushing VatCode NULL, as I do not want to fill in a VAT code and do not want Taxlines on the invoice. But when changing this to VatCode 0, this also circumvents the error. 

Do you know where the problem lies? Maybe a combination of VATcode and account numbers? Below the settings of another employee which experiences the same error (as the original invoice has been solved manually in the meantime).

Look forward to hearing from you. Thanks.

[Magnus Johnsen]

Hi,

Have you also checked according to the error message:

Missing taxable, non-taxable, EU or import accounts. 
Check the GL account settings for the item, supplier and supplier class

 Depending on how each company have set up their accounts in their enviroments results may vary.

Have you seen any patterns in what suppliers/items give you errors apart from just the accountNumber? 

[ExactGebruiker]

Hi,

Where are we with this issue?

Thanks.

[Magnus Johnsen]

Hi,

You can't push any null values to Financials API, we strongly recommend not sending fields you do not need.

For the employees that give an error, make sure that the financial details under the employee is set to the values that you want, and that all mandatory fields are set.

If these are set and you are still having issues, it could be due to an account being used on the employee that has been modified/disabled since it was initially set on the employee:

[ExactGebruiker]

Hi,

We have found the error. It seems when creating a purchase invoice via the Service API, and we fill in a ledger account on a purchase invoice line, if this is also the default ledger account for costs in the Employee settings, it does not work. If I change, given above example, the default ledger account from 4199 to 4300, the push does work.

So if we want to push an invoice line with (the already) default ledger account of 4199, it does not work, but if the default does not match the pushed value (either by changing the pushed value or default value) then it DOES work.

Please look into a fix for this, because we have to currently change all defaults for running invoices from employees in the meantime as this gets stuck.

Thanks ahead!

[ExactGebruiker]

Hi,

Please review as this all is not the case. It does work if we use a different ledger account in the API POST. And it does work if we push the POST with a different GL account and change it manually to the erroneous account. So it is not a null value that is the issue (just a different value), the account is not inactive (as we can change the ledger account in the same purchase invoice manually). All mandatory fields (as shown before) are filled in. This is a glitch with a certain set ledger account in Employees for which it apparently requires EU and Import ledger accounts as if it is a supplier. This had earlier not been an issue, and now it occurs en masse for loads of our companies. This seems to be a bug from an update, probably the one in week of 305h of May.

[Magnus Johnsen]

Thank you, we'll forward this to the development team. 

[ExactGebruiker]

Hi,

Any news on this issue?

[ExactGebruiker]

Great, thanks!

[ExactGebruiker]

Hi,

Per company there seems to be 1 specific ledger account number that does not work with the call. It is not a consistent one overall from company to company. For the one it concerns 4199, the other company has a problem with 4400 in our case.

What could cause this? Because when we push it with another account, and manually change (or create manually entirely) the invoice, it does work. This seems to be a problem with the API.