Hi @lubos,
When i update from desktop version 22.7.1.139 to 22.1.5.168 (latest) something strange happens.
On version 22.7.1.139: nothing in suspense and no unpaid invoices.
After update to desktop version 22.1.5.168 there was an amount in suspense and two unpaid invoices,
When i press the suspense amount the invoice bellow opens,
When i return to the previous version (22.7.1.139) there are no unpaid invoices and no ammount in suspense. Is there an error in the database?
Thanks.
Could you show the edit screen of the invoice #666 in the previous version?
I suspect there was an error in my database. I have corrected the purchase invoice #666 and checked the numbers and everything seems to be correct. But I have no idea how this error came about and don’t know if there are any other errors. Is there a way to check the database?
Then it appears to be a bug with the previous version since you can’t use the customer directly into the account.
This had me wondering, how was this transaction posted to the customer accounts in the first place?
I really have no idea how this is possible and why it only became visible with the last update and not with earlier versions.
We can test this further by looking into the batch update of that particular transaction. Maybe there’s some clue there.
This is the batch update of the invoice #666. I do not see anything strange.
| IssueDate | DueDate | DueDateDays | DueDateDate | Reference | OrderNumber | Supplier | PurchaseQuote | PurchaseOrder | Description | Lines.Item | Lines.Account | Lines.BillableExpenseCustomer | Lines.BillableExpenseSalesInvoice | Lines.CapitalAccount | Lines.SubAccount | Lines.Employee | Lines.SpecialAccount | Lines.FixedAsset | Lines.IntangibleAsset | Lines.Description | Lines.CustomFields | Lines.Qty | Lines.UnitPrice | Lines.CurrencyAmount | Lines.DiscountPercentage | Lines.DiscountAmount | Lines.TotalBeforeTax | Lines.TaxCode | Lines.TaxAmount | Lines.Total | Lines.Project | Lines.Division | PurchaseInventoryLocation | LineDescription | AmountsIncludeTax | Discount | DiscountType | WithholdingTax | WithholdingTaxType | WithholdingTaxPercentage | WithholdingTaxAmount | HasPurchaseInvoiceCustomTheme | PurchaseInvoiceCustomTheme | ClosedInvoice | AutomaticReference | CustomFields.4dee5e09c4ea4cf1b82bfc703c419586 | CustomFields.aaf1c9cc341a4a269bafb6893817d450 | Key |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 25-1-2021 | Net | 30 | 666 | 9c98ff71-80c9-4435-bfcf-6dac7f520345 | lasbochten 30x2 - lasnippel 1 | 9063eaed-df72-461f-adcf-a7b10c099e8f | 47,94 | 0 | 0 | 0 | 33855cc4-964b-44d1-be27-cf268b0ad77d | FALSE | TRUE | FALSE | Percentage | FALSE | Rate | 0 | 0 | TRUE | 3e701d55-00a2-411f-a6b9-7716edc1c4cf | FALSE | FALSE | 21700171 | f7b4cf1a-4cca-4ed2-a9f4-7e1fd6d45894 |
Can you confirm that this account exists in the COA and that it isn’t a restricted account (i.e. Cash and Bank, Receivables, Payables, Depreciation, etc):
Yes i can but this is the corrected invoice.
Beneath is the not corrected one, as you can see is the suppliers code the same as the account code.
| IssueDate | DueDate | DueDateDays | DueDateDate | Reference | OrderNumber | Supplier | PurchaseQuote | PurchaseOrder | Description | Lines.Item | Lines.Account | Lines.BillableExpenseCustomer | Lines.BillableExpenseSalesInvoice | Lines.CapitalAccount | Lines.SubAccount | Lines.Employee | Lines.SpecialAccount | Lines.FixedAsset | Lines.IntangibleAsset | Lines.Description | Lines.CustomFields | Lines.Qty | Lines.UnitPrice | Lines.CurrencyAmount | Lines.DiscountPercentage | Lines.DiscountAmount | Lines.TotalBeforeTax | Lines.TaxCode | Lines.TaxAmount | Lines.Total | Lines.Project | Lines.Division | PurchaseInventoryLocation | LineDescription | AmountsIncludeTax | Discount | DiscountType | WithholdingTax | WithholdingTaxType | WithholdingTaxPercentage | WithholdingTaxAmount | HasPurchaseInvoiceCustomTheme | PurchaseInvoiceCustomTheme | ClosedInvoice | AutomaticReference | CustomFields.4dee5e09c4ea4cf1b82bfc703c419586 | CustomFields.aaf1c9cc341a4a269bafb6893817d450 | Key |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 25-1-2021 | Net | 30 | 666 | 9c98ff71-80c9-4435-bfcf-6dac7f520345 | lasbochten 30x2 - lasnippel 1 | 9c98ff71-80c9-4435-bfcf-6dac7f520345 | 39,62 | 0 | 0 | 0 | 33855cc4-964b-44d1-be27-cf268b0ad77d | FALSE | TRUE | FALSE | Percentage | FALSE | Rate | 0 | 0 | TRUE | 3e701d55-00a2-411f-a6b9-7716edc1c4cf | FALSE | FALSE | 21700171 | f7b4cf1a-4cca-4ed2-a9f4-7e1fd6d45894 |
I think it’s better for @lubos to take a look at your case.
Thanks for your help. I’m going to investigate some further.
@Frankie you need to fix this entry manually. Why purchase invoice is posting to its supplier account? Shouldn’t it be posting to some expense account?
I’ve corrected this now and everything seems fine. I also checked via bulk update to see if there were any other invoices wrong but this doesn’t seem to be the case.
I frankly have no idea how that happened. Normally you can’t even choose the supplier as an account. Perhaps in the older version of manager it was possible to manually fill in a wrong or non-existing account. But it is remarkable that it only became visible with the last update of Manager.
This wasn’t possible if you’re manually filling in the form but it could’ve happened using batch operations and API. The program is fault tolerant enough, such that any user mistakes will not to cause any major issues but the faulty text will be preserved in field.
The weird thing though, is that in your case @Frankie these wrong GUIDs were interpreted into Customer names, which is weird.
Despite this being the minor issue that it is, but any help provided by Manager to help users identify their mistakes would be nice. For example:
It would be nice if these mistakes are caught during batch operations and set to blank and later we get a flag on these documents on the tab view.
I wouldn’t go as far as to block individual transactions in a batch because it’s highly probable that users will not be able to identify those individually blocked transactions.
Blocking the entire batch seems like a slightly better option at first but I think this will cause users to feel frustrated after one or more failed attempts.
That’s why I think setting to blank and then flagging is the more user friendly option.
I’m having this same issue, but with thousands of sales invoices going back years. Now after updating from 22.6.1 to 22.7.13, I suddenly see many unpaid purchase invoices from years age and all those lines from the sales invoices going to a “suspense account” (I’m not sure what’s it’s called in English, “tussenkaart” in Dutch).
At one point (don’t know the exact software number, I think something released in 2019) it was possible to have a line in the sales invoice add/deduct money from a purchase invoice and the other way around. Is there any way to keep the system backwards compatible with what how stuff worked 3 years ago? I understand this feature being removed going forward, but an update making it impossible to look into the books from a couple of years ago is a bit of a problem. Otherwise I’ll just have to stay with v22.6.1
Some background: This option was leveraged to write a bulk import script from a webstore that would put the cost of the payment provider from every sales invoice directly on a monthly invoice from the payment provider. In doing so, it made it possible to see how much payment processing cost there was for each transaction as well as an easy check to see if the system was calculating the correct payment processing costs, as it had to settle with the purchase invoice.
I just tested it and running a batch import of sales invoices where the “Lines.Account” uses the UID of a purchase invoice is still possible in v22.6.1
Apologies if this doesn’t belong in this thread and I should start a new one instead.
Welcome to the forum @Flapkan
That’s probably the cause, but this needs @lubos to confirm whether there’s been any changes in this regard because from whatever screenshots posted, it seems like there isn’t enough information to determine the cause with certainty.
Anyway, this kind of situation is now handled using Expense Claims Billable Expenses since you can’t use Receivable or Payable accounts in the lines of invoices, the reason mostly being that all the lines of the invoice belong to a single customer/supplier.
Unfortunately not. But I agree that compatibility needs some improvement especially if we consider that changes can have an effect on figures previously audited and filed with government agencies.
Maybe if any new changes could affect newly created transactions only and the GL transactions of previously created transactions wouldn’t be recomputed unless the user deliberately updates the transaction.
But we might be getting a bit ahead of ourselves, so let’s wait for @lubos to look into this.
The issue is that it was never possible to do this via user interface. It was possible via batch operations or API but that was a bug that some ended up relying on.
The point I’m trying to make is that if you are creating entry using API or batch create which is not possible to create using standard user interface, then you are doing something that could eventually stop working.
As per your use case, the reason why I don’t allow invoices to interact with accounts receivable and accounts payable accounts has to do with cash-basis accounting. There are edge-cases which will make cash-basis reports wrong.
The correct way is to have custom asset general ledger account which you can use on sales invoices. Each sales invoice can debit this account with the payment provider fee. When payment provider sends you purchase invoice, you can pay it using debit note where you offset balance of their custom asset account against the outstanding purchase invoice.
Yes, it’s little bit more convoluted because you can’t have purchase invoice paid automatically. You need debit note.
That’s makes sense.
But Imo, this be made a bit more obvious:
