Inconsistency in voucher_create mutation

[Magnus Vadla]

Hello,

I am trying to figure out how Nxt behaves when I omit the field debit/creditAccountType on voucher_create values.

I made a simple batch and voucher create mutation that worked fine for one nxt company, but when I tried it with another companyId I got an error message "Error: Supplier 7519 does not exist.". If the solution is to always provide the accountType along with accountNo then so be it, but it would be nice to understand what happens in the backend.

The mutation I used:

mutation create_batch_and_vouchers($batchno: Int = 0) {
  useCompany(no: 123456) {
    batch_create(
      values: [{voucherSeriesNo: 500, valueDate: 20240602, description: "testfile"}]
    ) {
      items {
        batchNo @export(as: "batchno")
      }
    }
    voucher_create(
      values: [
        {
          batchNo: $batchno, 
          amountDomestic: 14296.19, 
          debitAccountNo: 7519, 
          valueDate: 20240602, 
          voucherDate: 20240601, 
          voucherType: 50
        }, 
        {
          batchNo: $batchno,
          amountDomestic: 14296.19,
          creditAccountNo: 2920, 
          valueDate: 20240602, 
          voucherDate: 20240601, 
          voucherType: 50
        }]
      suggest: {voucherNo: true}
    ) {
      affectedRows
    }
  }
}

[Marius Bancila]

I want to second this NB. The order of fields assignment is important in BNXT. This is way putting the suggested fields at the end may lead to incorrect results. For this reason we made that feature obsolete a while ago (should be removed actually from our API). Use null as a value to indicate suggest.

voucher_create(
      values: [
        {
          batchNo: $batchno, 
          voucherNo: null,
          amountDomestic: 14296.19, 
          debitAccountNo: 7519, 
          valueDate: 20240602, 
          voucherDate: 20240601, 
          voucherType: 50
        }, 
        {
          batchNo: $batchno,
          voucherNo : null,
          amountDomestic: 14296.19,
          creditAccountNo: 2920, 
          valueDate: 20240602, 
          voucherDate: 20240601, 
          voucherType: 50
        }]
    ) {
      affectedRows
    }

Note that I'm not saying this is the cause of your problem, but it can be the cause of problems in other cases.

[Øyvind Årseth]

Hi @Magnus Vadla 
I'm not able to reproduce with your example, so I am inclined to think the result depends on something in the company data. 
It should not be necessary to set the accountType, but something leads to the assumption that 7519 is a supplier for some reason. 

NB! Be aware you are using a deprecated way of suggesting voucher numbers.