Dear Vincent, Thank you very much for your quite comprehensive explanation and provided references. Now I see the difference and understand why this feature is implemented this way.
In regard to suggested workaround, I probably would use the idea: anyway I am using mariadb as a data storage with some extra functionality already implemented in nodejs, so I can implement these extra splits creation automation while keeping the "generic" invoices implementation functional. I am just trying to use as many existing gnucash functions as possible for the project I am presently working on. Kind regards, Sergey On Tue, May 30, 2023 at 3:05 AM Vincent Dawans <dawa...@gmail.com> wrote: > Hi Sergey: > > I think you are describing the ability to use cash accounting instead of > accrual accounting. Gnucash does not offer this by default unfortunately. > There is an old enhancement report about it > https://bugs.gnucash.org/show_bug.cgi?id=95700 and even an old wiki page > https://wiki.gnucash.org/wiki/Cash_Based_Accounting > > There is actually a not-so-bad workaround but it still requires some > manual adjustments. So it's a workaround, not an ideal solution. > > It is very similar to what you have done so far as per your description, > with the additional advice of putting all of your transitional accounts > under a single top-level account. If you want to accommodate both invoices > and bills you would have: > Pending invoices and bills (TOP LEVEL of type asset or liability) > -- Pending bills (type: liability) > ---- Bills Payable (type: a/payable) This is the account where bills will > be posted by gnucash -- it will be selected by default because it is of > type a/payable > ---- Deferred Expenses (type: asset) This is the account you need to use > inside bills in lieu of expense account. Ideally it should include sub > accounts matching your expense accounts needed in bills, although not > entirely necessary. > -- Pending invoices (type: asset) > ---- Invoices Receivable (type: a/receivable) This is the account where > invoices will be posted by gnucash -- it will be selected by default > because it is of type a/receivable > ---- Deferred Income (type: liability). This is the account you need to > use inside invoices in lieu of income accounts. Ideally it should include > sub accounts matching your income accounts needed in invoices, although not > entirely necessary. > > You can just do the Pending invoices part if you don't use the bills > feature of course. > > The reasons why this structure is useful: > - the low level accounts in that hierarchy under Pending bills and Pending > invoices should always balance each other. If they do, you will see zeros > under Pending bills and Pending invoices in the account view. If you don't > see zeros, it means your manual adjustments are wrong OR your mistakenly > used income/expense accounts (instead of deferred income/deferred expenses) > in your invoices or bills. Without that check it will be hard to detect > errors. > - by not using actual income/expense accounts they will be excluded from > the P&L by default. > > The BIG caveat: > - After you process each payment, you need to enter adjustments between > the Deferred Expenses and expense accounts (for bills) and Deferred Income > and income accounts (for invoices); Ideally you put the adjustments as > additional splits in the same transaction processing the payment so there > is an easy track record of it and no risk of getting the date wrong. If you > have complex invoices with a lot of items going to different > income/expenses accounts this is far from ideal of course as you have to > adjust each account. You could also just use one "deferred income" account > and one "deferred expense" account and distribute expenses and income to > the correct expense/income account in the adjustment. In that case you need > the info from somewhere else (the item description in the invoice, etc). > Hence why this is a workaround. This is the part requiring the most manual > work and the main part that would need to be automated for this feature to > be fully implemented. How much work depends on how complex your > invoices/bills are. > > Little caveats: > - You need to exclude these accounts from the balance sheet, although the > balance sheet is still balancing with them, it just shows an additional > asset balanced by an additional liability of opposite value. Not what you > want but still not unbalanced. Still best to exclude them in the report > options. It's easy because they are all under one single main account. > - You need to include these accounts in some reports such as Customer > summary for instance. Easy enough to do in report options as well. > > Now the above workaround is the heavy-duty one when you want your books to > be in cash-basis at all times. Personally, because I don't use the vendor > bill option and do have that many invoices and only need precise reporting > once a year, I just edit my unpaid invoices and push them to January 1st > when I reach the end of the fiscal year. Not pretty but it does the job for > me. But I could see that not working if you have a lot of invoices or need > cash-basis reporting more often. > > There could also be a way to deal with this purely with reports. It would > keep the registers in accrual mode as they are, not do any pending accounts > and adjustments there, but then provide a cash-basis P&L and cash-basis > Balance sheet reports that would do the adjustment. That would be the > simplest way to provide at least some functionality without any manual > entries. But the challenge would come from partial payments. If an invoice > has several income accounts in it, and a partial payment is made, there is > no way (for the computer) to tell which income account the partial payment > should be applied to without additional info from the user. One could > decide to either pay the invoice items in the order presented or distribute > proportionally or any other way. Partial payment is an edge case but still > has to be accounted for. The same would need to happen for bills as well of > course. At the end this would still not be ideal since your main registers > would still follow accrual so the info wouldn't match the report. For > instance when closing books, profit/loss would be calculated as accrual in > the register, you would only see the cash-basis in the report. > > The alternative is to automate the workaround above and enable it on a > per book basis. It's actually sort of similar to the type of per book > selection and automation done by the trading accounts (for a completely > different purpose). But it's a substantial amount of work to do it properly. > > Sorry if my explanations are confusing. It's hard to explain this sort of > thing without visuals. I might try to update the wiki page with some of > these ideas and some screenshots. Also it's possible there might be some > other caveats I have not run into of course as each use case can be > different. > > Sincerely, > > Vincent Dawans > > On Mon, May 29, 2023 at 2:46 PM Sergey Mende <ser...@mende.spb.ru> wrote: > >> Hi there, >> I am trying to figure out if the existing customer invoice system is >> suitable for my needs. >> For simplicity, let's say I have the following accounts: >> >> Current (Bank) >> Undetermined Income (Income, for bank account transactions just imported >> from the online banking) >> Deferred Income (Income, used at invoice creation to track invoices that >> are posted and sent to the customers but not paid yet) >> Income (for invoices that got paid, so the payment actually received as a >> bank transaction and processed as a payment of an invoice) >> Receivable (A/Receivable, for tracking invoices) >> >> The problem is that I don't like to see non-paid invoice splits in the >> Income Register until the invoice payment arrives to my bank account, >> imported and processed as invoice payment. >> >> The idea is to assign an incoming imported transaction as a payment for an >> invoice from the Bank account Register and change the Income account >> appropriately, so the paid invoice appears in the Income Register >> >> As I got from the docs, this mailing list and my experiments, >> there is no way to change the Income account after the Invoice has been >> posted and specifically at the payment processing step. >> >> Am I missing something? >> >> Thank you, >> Sergey >> _______________________________________________ >> gnucash-user mailing list >> gnucash-user@gnucash.org >> To update your subscription preferences or to unsubscribe: >> https://lists.gnucash.org/mailman/listinfo/gnucash-user >> ----- >> Please remember to CC this list on all your replies. >> You can do this by using Reply-To-List or Reply-All. >> > _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.