I agree it could work.
For it to work well it would need to result in a consistent user interface for a range of transactions.
In the past, cash and invoiced transactions have had different support for
@Brucanna, @lmns@vez@busy and others who regularly do these type of transactions, how do you think Manager should optimally support these types of transactions if invoices were uniformly used. In particular
Invoices typically must provide specific legal identification of the parties involved in the transaction.
In private transactions there are typically two parties however in trading groups or agent transactions more parties can be involved in a transaction.
In your opinion, how many is typically required and how many is sometimes required, or to put the question another way, how many should Manager be optimised to support and how many should it be able to accommodate.
And how would this requirement be integrated into a user interface which is both efficient for the more common arrangement (Sale only invoice, Purchase only invoice) but allows for these more advanced transactions. Do we need an new “Other Invoice” type?
I don’t think it will work for my situation as a single bank transaction results in both a sales invoice and a purchase invoice in manager. This is because of the issues highlighted in the past, whereby line item on a sales invoice against an expense account (with a negative value) does not result in a purchase for BAS reporting purposes.
In other accounting packages, BAS statements are calculated based on invoice line items (not invoice totals). A line item against an expense account shows up within G10 or G11 (the purchases section) on the BAS form.
I would need line items on a payment (or sales invoice) that are posted to an expense account to reflect as an expense in the Business Activity Statement report. This has been discussed in the past and it was not possible. This was because when Manager generated the report it was tallying the total values for an invoice and was not processing items on a line by line basis. If this has changed, then maybe it can be resolved. Otherwise, we are stuck.
I already understood that the way we work is somewhat different from the typical company and our needs may not be in line with best bookkeeping practices. Still, I wanted to answer on the practical situation we sometimes get into.
We have a construction where several consultants work on different projects across different countries. Sometimes we already invoice amongst the partners, while clients have not yet received or settled invoices. We also work with organisations where services are bartered and “real” payments sometimes do not take place. Within the EU, we have reversed VAT charge and ICP requirements with the tax authorities. We are often on-site with clients, or at conferences for presentations and workshops. All of these activities are labeled as projects, and are connected to a client. One of my earlier questions was about the barter deal, where VAT/ICP entries get lost when one would credit, while the activity and the value would still exist.
@joris_manager mentions the common issue of having paid something with credit card or direct debit, where the invoice comes after a receipt/confirmation: wanting to create a purchase invoice for that transaction after the fact, based on a bank statement, but connected to a project or activity makes a lot of sense. We simply don’t always have the choice to follow what is the logical way in sequence.
We are now using Manager mostly as sales invoice only solution. We stopped creating purchase invoices to match after the fact of a transaction in Manager. We are looking into a full switch to another solution, where we import bank transactions and connect them with “virtual” purchase invoices after the fact just before the closing of the quarterly tax reports.
@Tut is right about the complexity. When it concerns products and services and shipments and different taxations, it can be messy. In our case, it is mostly our services being invoiced and cash payments for licenses/products and on-site payments (travel/stay).
@Patch seems to exactly describe the process. And yes, this would be quite the change.