Recommendation for standardization of transaction layout

That could quickly become unworkable. Even landscape layout gives less additional width than most people assume.

1 Like

It is what it is. This new layout will make it possible to show tax amounts for each tax component as per example below.

Can be generated like this…

Currently the output format depends on how the data is entered.

Imo it would make more sense if the output format was a business preference. Data could then be entered in what ever format was most efficient.

But can live with the current method if a significant number of users need to support multiple formats from the same business.

During data entry I much prefer to see all of the columns (tax exempt, tax, tax inclusive) as some invoices supply a random combination of information which are otherwise hard to decipher.

First of all good initiative to try to tackle so many issues and ideas. The form you show includes the necessity by tax authorities for unique consecutive serial numbers. This is indeed somewhere in ideas as well but it will necessitate another column in the table and thus taking more unavoidable real estate when all applies.

I agree with @Tut that

It is important to as in the current invoices indicate tax inclusive or exclusive and also to clearly post this as part of the totals on the bottom right. Bolding a single total is actually confusing and a more standard presentation with subtotal → tax (Vat incl or excl) → shipping & handling (if applicable) → Total , would

I don’t mind the added columns, but I don’t like two things about the totals layout:

  1. The order of columns isn’t fixed, example 0 rated taxes go behind the amount. I prefer that the columns sort order remains fixed with the totals amount being last. Also, all summable amounts should come last.

  2. The previous totals sections is much more elegant and more commonly used. I know that they wouldn’t add up to the the last column. However, this problem can be solved by matching the totals label to the column heading. I believe this would be tidier and more palatable.

What I’m thinking of is something along these lines:

All the information required are displayed without breaking the conventions when it comes to totals display. I personally think that these totals are more readable and understandable this way as opposed as laying them out in a single row.

2 Likes

@Ealfardan we should still have totals under each column where applicable. Mostly because this will allow us to show totals even for columns that do not contribute to transaction total in any way. For example Qty column or various custom fields (both feature requests in ideas category).

This brings me why repeat all that again in vertical total section. But we could. Especially when transaction has columns with various totals but only some of them are part of the transaction total calculation.

Totals of the qty column only make sense if all the lines have the same unit of measure

1 Like

Whether @Ealfardan’s recommendation on the vertical totals section is followed or not, his post contained two important points, in my opinion:

  1. The order of columns remains fixed, regardless of whether the transaction is tax-inclusive or tax-exclusive. Changing column orders may not bother a transaction recipient, since they typically see only one transaction at a time. But it is very confusing for accounting personnel in businesses that use both inclusive and exclusive transactions. And it is unnecessary. Why go to all the work of standardizing layout only to flip back and forth when a checkbox is ticked? Constancy of column order was a principal feature of my recommendations in post #1 (when I started this topic) and post #13. Headings changed as necessary to reflect inclusion or exclusion of tax.

  2. The ultimate total, balance due, or whatever is being displayed by the particularly transaction form is in the almost universally accepted lower right corner (for left to right languages) rather than buried in a middle column. Yes, I know you tried to emphasize it with boldface type, but that was not very effective. In fact, rather than leading me to an awareness that that was the important number, it left me wondering why it was in bold type. Realization that this was what I should focus on only came later, after the confusing tax-inclusive layout was puzzled over for quite a while.

1 Like

But that’s forcing the table to do too much at a time which detracts from the main purpose of the document. But as with other things in life, this boils down to being a trade-off, so we should weigh the costs against benefits and compare all possible alternatives.

And that begs the question: Since payments were left out from all of the examples above, what would happen to the payments? How would they be displayed?

Currently there is no other way to know how and when a particular invoice is paid except by going to the invoice and getting the payment reference from there. To me at least, that’s a more valuable feature than being able to show custom totals and I suspect that most users would agree. For one, you could easily write a theme to sum up the quantities or a custom field, but it’s impossible to write a theme that show the payments towards an invoice.

Why not have these additional totals displayed as a note after the amount in words and before custom fields? For me that would seem like the best place for any extra non-financial information. This frees the main table to give the financial data their due attention. For example:

2 Likes

On another note – while I can’t object to keeping up with regulatory requirements no matter how overboard they may seem, I agree with @Tut, it’s true that landscape page could fit more columns, but at some point the format is going to get too overcrowded to be legible.

I can’t help but to wonder, is this something that users will be able to undo? Possibly a checkbox in the Tax Code form to display components as separate columns?

I say this since not all users have a legal obligation to display all this information and they would much rather keep their invoices simple to save paper and to display a more presentable format to their customers.

I think a lot of people are getting lost in the detail. What I would suggest is stepping back and asking - what problem are you trying to solve by changing the format of the layout? I just feel that things are being over complicated here and what problem is actually being solved has been lost in the process.

I think the issue is laid out in the initial post.

In the initial posts - yes. But the solutions seem to be over complicating the issue and creating more problems than it is solving from what I am seeing. It looks information overload on the forms.

I wasn’t disagreeing with you, @dalacor, just pointing out what I thought the original issue was, at least for this thread. Note, however, that @lubos stated he is trying to address multiple ideas at once.

I’ve incorporated the feedback and here is how it behaves now

Transaction without discounts, tax codes and quantities

Transaction with quantities

Transaction with tax codes (amounts tax inclusive)

Transaction with tax codes (amounts tax exclusive)

Transaction with tax codes (0% tax codes)

Transaction with quantities, discounts and tax codes (amounts tax inclusive)

Transaction with quantities, discounts and tax codes (amounts tax exclusive)

Also every line item can be different - the layout will adapt

1 Like
  1. Can we presume the Qty column behaves as it previously did? That is, if units are all the same, the heading adopts the unit name and, if different, the heading renames as “Qty” and units are listed within the column?

  2. The totals are much improved. But I think they could be even simpler. What if the row immediately under the main table was labeled as Totals? Then you could do away with the Sub-total row on tax-exclusive transactions. And you would not need to duplicate the tax code total(s). Place the grand total in the cell that is now empty in what would be the Total-Total position.

  3. I also think you could get rid of the Includes Tax Code X% line on tax-inclusive transactions. The tax total would already be shown as described in #2 above. The only difference remaining between inclusive and exclusive layouts would be in the unit price column. If the transaction is tax-inclusive, label that column Unit price with tax. If tax-exclusive, leave it as Unit price.

  4. It isn’t clear from your examples how you are now treating multiple-tax-code situations. But can the tax amount column be made to function much like the Qty column? That is, if all tax codes are the same in the Tax column, the heading would adopt the tax code name. But, if tax codes are different, the heading would change to Tax Amount and all tax amounts would be displayed in one column. This would reduce column proliferation. Totals for different tax codes could all be separated in the Totals row, one below the other within the same cell. This would require labeling the amounts in the Totals row under the Tax column. In fact, it might be nice to label all tax totals regardless of the situation.

  5. You have not shown how you would handle multi-component custom tax codes. I think a suitable solution would be include the full tax code label and amount on individual line items. Then label and break out the various components in the Totals row. You really cannot handle this by adding more columns for every component, or you could easily end up with transaction forms two or more pages wide.

3 Likes

Much better, thanks. As for “Transaction with tax codes (0% tax codes)” the FIRS wants as is VAT 7.5% but also zero VAT and 0% VAT displayed per line item and under the Total when VAT inclusive and below the Sub-total when VAT exclusive (so all VAT options). As such @Tut’s points 2 and 3 disagreeable, but I do support his points 1, 4 and 5.

1 Like

I’m removing this from ideas because this has been basically implemented in the latest version (22.7.4.161). All transactions are now using the same layout logic.

One exception is sales invoices where I need to be sure everything is working properly before rolling out to everyone.

Therefore on sales invoices, there is temporary checkbox New layout which will enable it on per-invoice basis.

image

I encourage you to check it so you can see how new layout turns out on your invoices and to see what issues there are still to address.

1 Like
  1. Maybe on invoices with multiple Vat codes items, the layout may be with just one Vat Amount Column, instead of column for every tax code. As an option maybe, so users can choose depending on local tax requirements.
  2. Can the Totals without tax can be exposed to be used in custom themes. We personally need that in Macedonia.
    I have an example here (Tax base before Tax total at the bottom) Recommendation for standardization of transaction layout - #23 by MarV

Tax codes can be already configured that way. If label or tax component name is the same, Manager will group those amounts into single label.

Custom themes are not meant to be solving country-specific needs. This should be supported out of the box. However, if you need tax-exclusive totals, your only option currently is to make invoice where amounts are not tax-inclusive. This will show tax-exclusive sub-total, then tax amount then total.