Recommendation for standardization of transaction layout

1

I am posting this as an idea on the public forum at @lubos’ request, after first raising the issue with him privately.

The latest implementation of tax-inclusive versus tax-exclusive receipts and payments leaves much to be desired, especially when considered along with layouts for other transaction types. Overall, Manager now uses different terminology for the same quantity, price, and tax information on different forms, fails to clearly identify whether prices and amounts are tax-exclusive or -inclusive, entirely omits the untaxed amount in some tax-exclusive cases (making it non-compliant in some jurisdictions), and involves three different presentations of the same basic data in different situations:

  • Tax-exclusive receipts and payments
  • Tax-exclusive forms of other types
  • Tax-inclusive forms of all types

It could all be so much simpler. I am not proposing any changes to item codes, descriptions, or line-item custom fields, but only to what I will refer to as the financial information displayed on completed forms.

Let’s start with the premise that fewer different formats and standard terminology are desirable. So let’s define terms that could be used across all situations:

  • Quantity (abbreviated as Qty)
  • Unit price (label for unit price from a tax-exclusive form)
  • Unit price with tax (label for unit price from a tax-inclusive form)
  • Tax code (rather than tax rate, to match terminology elsewhere in the program and be less confusing if the code has a name that does not include a numerical percentage)
  • Tax (the actual tax amount)
  • Amount without tax (label for product of quantity and tax-exclusive unit price)
  • Amount with tax (label for product of quantity and tax-inclusive unit price)

Now, formatting comes down to what is displayed by transaction type. I suggest the following columns and content. Note that the same layout would be used on all forms. Only the column labels change. Variables are the same as already present. Entry screens do not change, only the View of finished transactions, and only for the financial information columns:

Type Qty Unit
price		 Unit price
with tax		 Tax
code		 Tax Amount
w/out tax		 Amount
with tax
Tax-exclusive X X X X X
Tax-inclusive X X X X X

The totals section of all forms would also be standardized. The tax-exclusive and -inclusive versions would match the current layout on invoices. That is:

  • Tax-exclusive transactions would list Sub-Total, Tax Totals for each tax code, and Total or Balance Due as appropriate. The option to suppress the total on sales quotes would remain.
  • Tax-inclusive transactions would list Total, Includes… for each tax code, and Balance Due if appropriate.
  • Mini-statement information, where currently listed, would remain unchanged.

This simplification would have the benefit of always looking at the same things in the same places on all transaction forms. The label changes would make it clear whether the transaction is tax-exclusive or tax-inclusive. And it would provide line-item level tax mount information as many users have requested.

1 Like
2

Just to be clear if I understood you right. You are proposing entry forms change, not presentation view of lets say receipts or forms? No change of exposed variables in themes, nor change in build in themes? If later, than it will pull an complete rewrite of many custom themes, we have worked on, to made presentation of documents country specific.
If you propose just entry form changes than it is OK, but why not showing all fields, with that not appropriate with selected method (exclusive or inclusive) just read only.

I would like it like this (ro = read only)

Type Qty Unit
price		 Unit price
with tax		 Tax
code		 Tax Amount
w/out tax		 Amount
with tax
Tax-exclusive X X X(ro) X X X X(ro)
Tax-inclusive X X(ro) X X X X(ro) X

Once again I would like a choice. I personaly prefer first bullet option, for everything. It is preference of mine.

As I read, i have a filing you are proposing also a presentation change, not just data entry change.

Also bear in mind that in one entry form, for example sales invoice, you can have both taxable and non-taxable line items.
Also, once again from diferent thread. As I understand chechbox Amounts are inclusive/exclusive is just how Manager calculates TAX per form, it has nothing to do with if the whole invoice for example is or is not tax inclusive or exclusive, so you don’t need various representations of columns and totals.
My opinion is to postpone this standardisation idea, not a bed one, until Lubos give as, a long awaited invoice/receipt/whatsoever builder, and than we could have standardized entry forms, and country/legal specific output/presentation forms.

3

No, exactly the opposite. As I wrote, “Entry screens do not change, only the View of finished transactions….” The changes involve only the columns presented and their labels.

As for themes, these would, in most cases, be unaffected. Unless you wrote large amounts of code to manipulate the order of presentation of columns or change their titles, there would be no effect. But every custom theme risks becoming obsolete with future program modifications.

You do not have a choice now. My three bullets were not options to choose from. They represent the current reality. I was only summarizing what now exists on invoices and recommending that current practices be kept.

See my earlier answer. I am proposing only a presentation standardization, with no changes to data entry.

That is irrelevant. The differences occur in whether the transaction form is tax-exclusive or tax-inclusive, just as is now the case. Whether tax codes are applied to individual line items does not matter, except that if the entire form has no tax codes, some columns will be eliminated as now happens.

Your understanding is incorrect. Checking that box changes the tax calculation method and the presentation. It does now and it still would. And it has everything to do with whether the whole transaction is or is not tax-exclusive or tax-inclusive. You most definitely need some form of different representation of columns and totals, because they represent different quantities according to whether the box is checked or not. My suggestion just minimizes the differences.

4

I fully agree with implementing consistency within the program. Using the same names, formats on every form etc does help tremendously to keep the program simple to use. Consistency is important here.

Could you post some screenshots showing examples of the current problems. I could investigate what you are talking about, but the same question will apply to everyone else. I can’t think offhand where these discrepancies that you are referring to occur. Then we can better see what issues you are talking about and make suggestions based on this.

5

So, before anything else, I am glad we are now on same page.

And that risk of custom theme chance of breakdown, must be addressed before everything else. Because in most cases, it will be affected. A large amount of users have custom themes as provided ones doesn’t meet needs of many jurisdictions. Including myself. And if the presentation level, exposed variables, order of columns, etc. will be changed, than there maybe should be beta version and a time frame to give such users time to adapt. I really cant imagine any user in my country, and surrounding neighbors, that can live and work with build-in ones. They are simply not applicable.

But if we make changes, why not to have choice.

OK, and how do you define what form will be tax inclusive/exclusive? Give me a sample for example an invoice? I have one line with aplied taxcode for 18%, and one line with no taxcode. Amounts are tax inclusive is checked. The resulting form is ?

No I understand based on guides and workflow till now. If I enter invoice, with or without Amounts are inclusive checked/unchecked (and have line items with taxes) I get the same invoice as output, only totals section is different (I can argue about that also but …). And that is how it should be.

  • Another option lets you indicate Amounts are tax inclusive. If this box is checked, tax amounts are deducted from the unit price; otherwise they are added to the invoiced amount.

The various presentations now depending of what the status of checkbox is, is not good in my country, and that’s one reason why we need to use custom themes, among others. We need always to have totals section as per your bullet #1 (or like tax exclusive entry). The process of entering data should be irrelevant, and personal preference.

So again. If we are going to make changes, beta version, testing, time to adapt will be essential. The Presentation Form Builder of some kind, would be the best.

6

Here is a tax-exclusive receipt or payment:

Screen Shot 2020-12-07 at 6.08.19 AM

This is a tax-exclusive sales invoice (representative of other forms, too):

Screen Shot 2020-12-07 at 6.14.16 AM

And this is a tax-inclusive receipt or payment (representative of all forms):

Screen Shot 2020-12-07 at 6.16.25 AM

1 Like
7

The risk of theme breakdown is independent of anything else. As I wrote earlier, the exposed variables will be the same. Column order will actually be simpler, because it will be constant and function better across multiple types of forms and transactions.

Because you cannot choose among the characteristics of the totals section you are addressing. You need them all. To say it one more time, all I was doing was summarizing what now exists and emphasizing that I propose no changes to it except to apply it all forms uniformly. (Tax-exclusive receipts and payments are now different.)

The same way you do now. That is a choice of the user, depending on whether the user wants prices to include tax or not. I cannot give you an example, because what I propose does not exist. But you can do your own test on mixed tax codes even now.

8

I see. I am wondering if this issue is being looked at the wrong way around.

The difference between unit price in the first and second example of receipts/payments - If I am understanding things correctly is that in the first example, I would put in £80 - ex vat and get £100 as the total vat amount.

Whereas in the second example, you are putting in the vat inclusive amount of £100 and getting the program to work out that the vat is £20.

I also don’t understand (but is not necessary for this discussion) is why vat is being included in payments/receipts. This may be down to my using invoices all the time. I include the vat there and my payments and receipts never have vat on the form. But as I said, that is a whole separate discussion and not relevant here.

What I would do is keep the view forms identical regardless of whether vat is exclusive or inclusive. With the edit form, if you tick the box include vat/tax then the program knows that the amount that you are putting in is including the tax and should calculate accordingly.

I think that what you want to end up achieving is the exact same end result on the view form for both inclusive/exclusive tax options. The tax exclusive form works logically for everyone as most people are used to quotes and invoices in that layout. So why not keep it like that? There is no reason to change the form layout. Use the tax exclusive form for both options and let Manager take care of the details with regards to what the amount is that goes into the unit price (which will be the ex vat price).

I am of course, speaking under the assumption that the reason that people use the tax inclusive price is because they know what figure they want as the tax inclusive price, not because they don’t want to see the ex tax price on the form?

I don’t like the tax inclusive form example that you have shown. It does not look logically laid out.

However, as I don’t use tax inclusive on my invoices nor do I have tax on the payments/receipts - my tax is already calculated on the invoices, so I don’t know why payments/receipts are designed the way that they are as I am not using them that way. But my personal opinion is that you need the forms to be consistent regardless of whether tax is inclusive or exclusive.

Your suggestion of unit price and unit price with tax is further complicating things and I feel is looking at the issue the wrong way around. Just my opinion.

9

To be clear, the examples you asked me to post were of the problems/differences in the current implementation. They do not model what I propose.

In all cases, the unit price input on the entry screen was 100.00 and the tax code applied was GST 10% (a VAT code, although that does not matter). So for both tax-exclusive examples, 10.00 of tax was added to the unit price for a total of 110.00. And in the tax-inclusive example, 9.09 was backed out of the unit price, leaving the total at 100.00. All that has nothing to do with my proposal. That is just the difference between tax-exclusive and tax-inclusive pricing. Manager works that way now and would continue to work that way. Since you apparently use only tax-exclusive pricing in your business, you may not have been aware of that.

Because you must do that for cash-and-carry sales. If the payments or receipts are against invoices, you would not include tax codes. That is the way you do things.

That is the purpose of my proposal. The program already knows what the various numerical figures are; it just displays them in inconsistent and confusing ways.

Not quite. The physical layouts will be the same, but columns for unit price and amount will be with or without tax, depending on whether you check the tax-inclusive box. So the numbers would differ.

You cannot display tax-exclusive and tax-inclusive forms with the same content. So you need two versions. And some jurisdictions require line-item level tax amounts to be shown, regardless of form type. So the layout had to change, but the way it was done led to more versions than necessary, some being confusing.

The program already does. I am not proposing to change that, only to standardize the layout and improve terminology.

That is not what I am proposing. As I’ve said several times, that is the current, problematic display the program currently provides.

Again, that is the whole point of my suggestion.

The purpose of this change of column heading—again, it only changes the column heading—is to make clear whether the form is tax-exclusive or tax-inclusive. Presently, nothing informs the recipient which is the case. The user knows, because they checked or unchecked the box, but the recipient does not know and has to puzzle it out from the numbers.

I think many of your points of uncertainty would vanish if you used both types of transaction forms. If someone only uses tax-exclusive versions, the tax-inclusive forms can definitely be confusing.

10

I fully understand that the examples that you are showing me is how the program currently works. I know that. I also understand the main point that you are trying to make - because I noticed that immediately myself. As you say, it is very difficult to tell whether the amounts include or exclude tax!

I understand that as I only use invoices, this works differently from cash payments which I don’t use at all. So I understand why this is different.

What I would do is keep the view forms identical regardless of whether tax is exclusive or inclusive. - you have said that this is the purpose of your proposal.

So we are in perfect agreement on the above points.

Where are moving apart is your suggestion is to rename the column unit price inclusive or exclusive. My suggestion would be to have the form absolutely identical regardless of whether the prices are inclusive/exclusive.

You say below:

What I would say in response is, perhaps both forms could be changed (because the inclusive layout is confusing and not logically laid out) and you say that you cannot use the tax exclusive format because you require line-item level tax amounts etc. So why not combine the advantages of both forms into one new form - loosely based on the tax exclusive design layout, but incorporating whatever is required for tax inclusive information.

I would not rename the headers. The amounts will be the same regardless of whether you are using tax inclusive or exclusive - the different will be in exclusive, the unit field will be £80 which is what I entered, whereas tax inclusive, manager will calculate what the amount is from the total that you put in.

So I see no reason to change the header names from unit price with tax or unit price without tax.

Hopefully that makes sense to you. Not sure how else to explain it. The key issue is that tax exclusive manager puts in the unit price whatever you type in on the edit form, whereas with tax inclusive, manager calculates the figure that is tax exclusive and enters that amount in.

11

This is what my proposal tries to do.

Are you saying that you would enter the price on the entry form, check or uncheck the box, and if tax-inclusive Manager would calculate the effective untaxed price so that you could show either under a column just named Unit price? I could support that, but it would require a new variable to be calculated, because Manager does not now calculate an effective untaxed price for tax-inclusive transactions. If you did that, however, you would still need to relabel the Amount column, because you would need to show the Amount with tax for tax-inclusive forms.

The problem with all this is that some jurisdictions require display of untaxed amounts and tax for each line item, even though the transaction is tax-inclusive. Otherwise, I would go with your idea of having all displays the same and letting the program calculate what goes in each box. We wrestle with government bureaucrats with little understanding of accounting realities.

That is where you are incorrect. Manager backs the tax out of the tax-inclusive price, but does not presently calculate—or at least does not expose the result of such a calculation—on tax-inclusive forms.

12

With the second point - regarding Manager calculating the tax. I was not talking about what manager currently does - but rather what I was proposing should happen.

Yes to your longer paragraph. I would keep the table identical for both forms and get manager to autofill the unit price by calculating the ex tax amount on tax inclusive. Manager does not currently do this. This is what I am proposing.

I cannot comment on the legal requirements as I don’t know what they are. But if you could get Manager to autocalculate and autofill where required and simultaneously address the legal information, then this is what I am recommending. Otherwise your solution of renaming columns and adding extra columns for tax inclusive may be the only solution.

I suspect that my solution is doable, but will require more thought and effort than simply renaming columns and adding extra columns. I Iike the way the ex tax form is laid out - it makes sense and my personal desire would be to tweak that form to make it work for tax inclusive reports as well.

Anyway we will see what the developer thinks. He has both options.

13

So here are two more possibilities, incorporating ideas exchanged with @dalacor above.

Possibility #1

The two types of forms would be identical in layout in their main tables, with the exception that Amounts would be designated as being with or without tax:

| Type | Qty | Unit
price | Tax
code | Tax | Amount
w/out tax | Amount
with tax |
| — | :—: | :—: | :—: | :—: | :—: | :—: | :—: |
| Tax-exclusive | X | X | X | X | X | |
| Tax-inclusive | X | X | X | X | | X |

The unit price would be determined by Manager based on whether prices were indicated to be tax-exclusive or tax-inclusive. But in both cases, the unit price shown would be ex-tax. So, when entering a form, you could enter either type of price, instructing the program how to treat that price by whether you checked the box. The unit price displayed would change based on your selection. Totals would remain as originally described for each type of form.

Possibility #2

This idea takes up @dalacor’s suggestion that all forms be exactly identical. Enter either tax-exclusive or tax-inclusive prices and indicate which they are by checking the box. Regardless of which is chosen, Manager produces something similar to today’s tax-exclusive sales invoice. All prices and amounts would be ex-tax.

This concept eliminates separate presentations for tax-exclusive and tax-inclusive forms. So far as I know, tax-exclusive forms are acceptable everywhere in the world. This approach gives the user two ways to produce them—by inputting tax-exclusive or tax-inclusive prices. Manager would calculate effective ex-tax unit price from the tax-inclusive price, if necessary (and if it does not already). This approach also adds the line-item tax figure required in some jurisdictions.:

Type Qty Unit
price		 Tax
code		 Tax Amount
All X X X X X

The totals section would list Sub-Total, Tax Totals for each tax code used, and Total or Balance Due as appropriate. The option to suppress the total on sales quotes would remain.

Comparison

Possibility #1 preserves the option to display tax-inclusive pricing. But it could still be confusing to some recipients. The most significant point of confusion will be that recipients might expect Tax to be included in Amount. (That could be remedied by labeling the final column Untaxed amount.) Its biggest advantage is the ability to communicate with customers in terms of tax-inclusive prices. But that seems most useful in cash-and-carry situations where customers tend not to care about receipt format. It would not stop anyone from advertising tax-inclusive prices.

Possibility #2 maximizes consistency across the program. It produces familiar formats regardless of how prices are entered, especially in the totals section. But it sacrifices the ability the show tax-inclusive pricing. Its biggest advantage is that you would always be looking at the same things on completed transaction forms, and those would be very understandable. It would be user-friendly by allowing two ways of entering prices, both producing equivalent results.

14

Yes. This is it. Possibility #2, this is what I was talking all the time. Checkbox is just how data is entered and nothing else. Presentation should be uniform. And just if possible layout like this (combination of #1 and #2)

Possibility #1+2

Type Qty Unit
price		 Amount
w/out tax		 Tax
code		 Tax Amount
with tax
All X X X X X X

The totals section would list Sub-Total, Tax Totals for each tax code used, and Total or Balance Due as appropriate. The option to suppress the total on sales quotes would remain.
[/quote]

15

Two points I would highlight @Tut

As you mentioned in possibility one, do customers actually care about vat when you are dealing with cash and carry. Generally cash and carry receipts go straight into the rubbish bin. So probably the format is not that important to the end client.

With possibility two - this may affect people who have extensively customised their themes. For the vast majority of users who have custom themes, it probably won’t affect anything as generally all we change is the colours and sizes of things, as well as moving the logo, address locations. But the fields themselves we don’t generally touch in custom themes. I also don’t recommend it due to the fact that changes in the program in the future may cause problems for themes.

@MarV - the unit price would always be without tax - for both tax inclusive/exclusive therefore your amoutn w/out tax is redundant.

16

For retail sales in Australia, the unit price is tax inclusive

17

Is the receipt required to show the tax-inclusive unit price, @Patch? If so, that explains why there were two presentations in the first place. And it takes you back to the suggestion in post #1.

18

The

  • advertised price must be inclusive of all taxes and charges
  • you must supply at or below the advertised price
  • as a result the consumer expects to see the GST inclusive price
  • the tax receipt (sales invoice) must show the total tax inclusive.
    See Displaying prices | ACCC

In theory the unit price could be gst exclusive (provided the line item total is shown tax inclusive) however that is not what a retail consumer expects to see.

In contrast sales to businesses typically include the tax exclusive price as the business customer can claim gst back.

19

The ACCC reference quoted by @Patch is about price statements (advertising, Price lists, shelf prices, quotes) it is not about invoicing. Invoices/receipts must comply with the GST law.

1 Like
20

And what does the GST law say? Are prices required to be inclusive of tax?