Added ability to attach customer or supplier to any tax transaction

[lubos]

There are number of topics discussing issues with tax codes and how Manager decides whether tax transaction is a sale or purchase.

I’ll start with the background of the issue.

Unlike other accounting systems, Manager doesn’t require seperate tax codes for sales and purchases. In most countries with value added taxes, it is required to know total taxable sales and total taxable.

For this reason, accounting systems will have generally two separate tax codes to manage this requirement. One for sales, one for purchases. So for example, if VAT is 20%, the accounting system will have two tax codes:

• VAT 20% on sales
• VAT 20% on purchases

Then accounting system can give you total amounts for each tax code.

In Manager, you can get away with just single tax code:

• VAT 20%

And you can use it for both sales and purchase transactions. It’s up to Manager to figure out which transactions are sales and which are purchases.

There is Tax Summary report which will summarize all transactions whether they are sales or purchases per each tax code.

This works well for most cases because if tax code VAT 20% is used on sales invoices or credit notes - it is always a sale. If VAT 20% is used on purchases invoices or debit notes - it is always a purchase.

Where it doesn’t work well are receipts, payments and journal entries. We can’t look at cash receipt and say it is a cash sale because cash receipt can also represent refund from supplier in which case you wouldn’t want refund from supplier to be reported as sale. You’d want refund from supplier to be reported as negative purchase.

I came to realize that solution is to be able to attach customer or supplier to any tax transaction. If you are able to do that, it’s easy for Manager to determine whether any transaction is a sale or purchase.

Sales invoices, purchase invoices, credit notes and debit notes already have customer or supplier attached to the transaction but there was no mechanism to attach customer or supplier to receipts, payments and journal entries.

The latest version (20.8.81) is fixing this and it is now possible to attach customer or supplier to receipts, payments and journal entries as well.

Here is how it works:

Let’s say you are receiving refund from supplier called Brilliant Energy. Before entering the refund, you have 500 in purchases subject to VAT 20%.

Refund is entered as receipt transaction. Normally receipt transaction would be added to Sales side by we can avoid this by selecting supplier name after selecting tax code VAT 20%.

Because the transaction is now associated with supplier, it will be always considered as a purchase. Since this is a refund, it will be reported as negative purchase.

Also, when you click on Net Purchases amount, you will see supplier name as a column.

So you can see supplier names associated with tax code even if they are cash transactions. This is useful for management purposes but also important for upcoming country-specific reports (in some countries some businesses are required to provide list of suppliers and how much tax the business has paid them).

[Ealfardan]

It’s a very good solution to use customer/supplier accounts to determine whether it’s sales related or purchases related.

However the application is kind of crude and I mean the placement of the customer or supplier in the lines is kind of awkward for the following reasons:

• Why would someone need to mention the customer for each and every line of a receipt or payment when you can enter it once? This is because bulk refunds with multiple counterparties would result in a nasty matrix of counterparties and items. I would rather enter 1 transaction per customer/supplier.

• If you need a bulk receipt, you always have batch create.

If it was up to me I would rather have this field right on top of contact because it will solve two problems:

• This particular tax issue.

• If a customer/supplier is selected then you can leave contact field empty to get customer/supplier’s default address shown, as @tut already sugested here https://forum.manager.io/t/improvement-to-payment-and-receipt-forms/9179

[Patch]

Adding linkage of suppliers / customers to journal entries, receipts payments is an excellent idea. The functionality will add to the reports I can generate from Manager so is really appreciated.

There are a couple if things I’m not sure are optimal with the current implementation

• When a entity is both a customer and a supplier it has been necessary to enter them in both the customer and supplier data base. When the customer and supplier databases are combined it is not obvious which I’m selecting. Inadvertent selection is likely to be difficult to track down.

• (Combining the customer, supplier, payee, and employee databases with a flag for which list they should appear in would be useful in the future as then all transactions for an entity could be displayed together and totals calculated. However doing so would result in selection of an entity who was both a supplier and customer so not define the tax code type)

• Agree in a journal entry line item level specification of customer or supplier (or payee or employee) is an excellent idea. Journal entries are a low level tool so having maximal and specific control is optimal. They can then be used to correct all sorts of errors by those knowledgeable enough to construct the journal entry.

• I’m less convinced most users payments or receipt transactions need a different customer or suppler for each line item. I can see for bater type transactions two would be optimal (supplier and a customer, one for the forward and one for the counter trade) but in my opinion that would be best done by Manager having transaction level support for counter trade transactions.

[Patch]

Possible solution to the above issues are:

Journal entries

For Journal entries, make the user choose if the line item is a sale or purchase first, then allow selection of tax codes and entity (from the appropriate database). For existing data the sale / purchase can be set by an upgrade script based on credit / debit status for line items with a tax code (so maintain compatibility for old data).

Receipt and Payment

Most receipt or payments are to one customer or supplier, so specification at the transaction level is optimal, in a similar location where payee/payer is currently. Also line items in most receipt / payments are for positive amounts, they are not refunds or counter transaction, so no more is required. But some receipts and payments are for counter transaction. To support them only a checkbox is required which is by default not checked

For a receipt when the counter trade option is checked further options would be displayed

Note

• To maintain compatibility with old data an upgrade script could set the counter trade flag for all existing receipts or payments with negative amount line items and put them in the counter trade section.

• A custom report can be used to list all line items with negative amount, requiring review by the business owner to determine it they really were a counter trade. Payments to customers and receipts from supplies can mostly be found by sorting the respective expense or income accounts (as expense account status is not exposed in custom reports).

• For a Payment the “Sale” and “Purchase” sections are swapped around. Also the counter trade section allows selection of a Customer not a supplier.

• The same counter trade facility could be added to invoices to enable user to use invoices for counter trades

[Davide]

Sorry to be so direct but I find this solution a real mess. It is a very strange way to reason. It seems more a programmer gymnic than a real useful reasonable solution.

First of all. What set if a tax is to be set as payable or receivable is the tax law not if it linked to a customer or a supplier. This could be a case but you cannot set it as an assumption for the whole world.

Why all this workaround instead of, at this point, giving the possibility, in the second drop down menu, to force a tax to be receivable or payable instead of linking to a customer or a supplier? What if a local law set that a credit note should be put inside tax receivable instead of a tax payable with negative sign? Should I create a the customer also as a supplier? for each customer?

All that said, the possibility to attach at line level a tax to a costumer or supplier is shown also under Invoices or Notes creating so much confusion. This is already set in the header. Please hide it.

[lubos]

@Ealfardan

However the application is kind of crude and I mean the placement of the customer or supplier in the lines is kind of awkward

I agree. There are going to be improvements to UI but the basic principle that customer or supplier can be assigned to line item is immutable.

@Ealfardan

Why would someone need to mention the customer for each and every line of a receipt or payment when you can enter it once? This is because bulk refunds with multiple counterparties would result in a nasty matrix of counterparties and items. I would rather enter 1 transaction per customer/supplier.

There will be an option to select customer or supplier for the entire receipt or payment and then you won’t see this extra field on line items.

[lubos]

@Davide

First of all. What set if a tax is to be set as payable or receivable is the tax law not if it linked to a customer or a supplier. This could be a case but you cannot set it as an assumption for the whole world.

Not sure what you mean by this. If you don’t select customer or supplier, then credit amount will be seen as sale and debit amount as purchase.

@Davide

Why all this workaround instead of, at this point, giving the possibility, in the second drop down menu, to force a tax to be receivable or payable instead of linking to a customer or a supplier?

Because it’s easier to enter name of customer or supplier associated with the tax. Also, that information is useful in other contexts. Not just to determine whether transaction is a sale or purchase. That’s just a start.

There are some topics in ideas category asking for ability to track sales by customer which are paying cash (no sales invoices).

Also, in some countries, you have to submit report to tax authority with the list of suppliers who have collected tax from you. Until now it was only possible if you used accounts payable module. Now the report can work for all suppliers (not just for those you are entering invoices for).

So there is really no way around this. We need to be able to associate every tax transaction with customer or supplier. It’s not a gimmick, it’s solving multiple topics raised in ideas category.

@Davide

All that said, the possibility to attach at line level a tax to a costumer or supplier is shown also under Invoices or Notes creating so much confusion. This is already set in the header. Please hide it.

Fixed in the latest version (20.8.82)

[Davide]

@lubos

Fixed in the latest version (20.8.82)

Thanks.

Having all taxes only linked to Invoices and Notes, at least, this new solution has zero impact on our workflow. By workflow I mean also explaining to all my colleagues what this new field mean and invite them not to use it.

[Davide]

@lubos

Not sure what you mean by this. If you don’t select customer or supplier, then credit amount will be seen as sale and debit amount as purchase.

That there can be a credit not seen as a sale even if it is linked to a customer (and vice versa). In this case you need to copy a customer under a supplier instead of forcing the inversion with a simple flag.

[Davide]

@lubos

There are some topics in ideas category asking for ability to track sales by customer which are paying cash (no sales invoices).

Also, in some countries, you have to submit report to tax authority with the list of suppliers who have collected tax from you. Until now it was only possible if you used accounts payable module. Now the report can work for all suppliers (not just for those you are entering invoices for).

So there is really no way around this. We need to be able to associate every tax transaction with customer or supplier. It’s not a gimmick, it’s solving multiple topics raised in ideas category.

I understand it. So, under this point of view, a requirement to hide the drop-down for client and customer if a tax code is not selected makes sense or not?

In the case it should be used also independently from Tax Codes, I think that it should not be putted under the same header (Tax Code for both the columns).

[AJD]

@lubos

@Davide

All that said, the possibility to attach at line level a tax to a costumer or supplier is shown also under Invoices or Notes creating so much confusion. This is already set in the header. Please hide it.

Fixed in the latest version (20.8.82)

Consider purchase of a new vehicle with existing vehicle trade-in. MV Trader will give you an invoice detailing the new vehicle cost less the trade in allowance. Version 20.8.81 allowed purchase invoice to be entered with negative amount for trade-in allowance and select a customer which reported correctly. Latest version 20.8.83 no longer allows selection of customer so the negative amount for trade-in allowance now reports incorrectly. Only way to get this to report correctly now is to do PI for New vehicle and SI for old vehicle.

[Davide]

@AJD

Only way to get this to report correctly now is to do PI for New vehicle and SI for old vehicle.

Don’t know your nationality but in Italy (so also in most of EU) you should issue a SI by law. You are deliberately reducing the company’s turnover which determines how taxes are applied.

[Patch]

Sales or purchases where no single customer or supplier linkage is appropriate

@Davide

What set if a tax is to be set as payable or receivable is the tax law not if it linked to a customer or a supplier.

Agree
An example of a journal entry where sale / purchase must be set different to credit / debit status but there is no single supplier Private vehicle use - worked example

Entering a Counter trade or Recipient-created tax invoice using Managers invoice facility

I’m not sure how this this solution solves the equivalent problem for invoices. If counter trade functionality is vital for cash transactions, then surely it is even more important for invoice transactions in an accounting package optimized for accrual based accounting. An example of Counter trade / Recipient-created tax invoices required when generating an invoice in Manager Negative invoiced amounts missing from GST (tax) reports

Default sale / purchase assignment for the entire Payment or Receipt

If barter transactions / Counter trade / Recipient-created tax invoices really need the ability to link to an unlimited number of customers and suppliers, then please make the default

• Receipt: all line items tax is of type sales (independent of the sign of the line item amount), and can be linked to a single customer if desired

• Payment: all line items tax is of type purchase (independent of the sign of the line item amount), and can be linked to a single supplier if desired

• Doing so maintains consistency between cash transactions and invoice transaction

For barter transactions / Counter trade / Recipient-created tax invoices have the option to allow:

• sale / purchase to be set at the line item level

• Supplier / customer to be set at the line item level

• For old data sale / purchase will be as desired when supplier / customer are added (which must be done manually). Sale / purchase flag could only be set by and upgrade script if a sale / purchase flag existed independently of the customer / supplier linkage.

[lubos]

@Patch

• Receipt: all line items tax is of type sales (independent of the sign of the line item amount), and can be linked to a single customer if desired
• Payment: all line items tax is of type purchase (independent of the sign of the line item amount), and can be linked to a single supplier if desired

This is being covered by this topic. Working on it.

Improvement to payment and receipt forms

It would be very helpful if the cash payment and receipt forms were improved to include several features: Linkage to customer/supplier subaccounts. Established customers don’t always buy on credit, making a sales invoice unnecessary. Likewise, businesses often pay cash to established suppliers, so purchase invoices are not needed. This linkage would eliminate separate invoice and spend/receive transactions. And it would allow the complete history of a customer/supplier in a statement, not jus…

[Patch]

@lubos

This is being covered by this topic. Working on it.

Perhaps I should have been clearer

Single supplier or customer per transaction data entry mode

In the mode where the customer or supplier applies to the whole transaction ie not displayed or selectable at the line item level. I practice it covers by far the majority of all receipts and payments, and requires less user data entry, so should be the default mode in Manager. This mode must cover the transaction where there is a unique customer for all line items or a unique supplier for all line items. This case includes when one of the line items is a return or refund. Thus

• Receipt: all line items tax is of type sales (independent of the sign of the line item amount)

• Payment: all line items tax is of type purchase (independent of the sign of the line item amount)

• Doing so maintains consistency between cash transactions and invoice transaction

If an actual supplier or customer is added to the entire receipt or payment then all line items continue to be applied to just one of sale or purchase never a mixture of both.

In my opinion, to simplify selection of a contact in the transaction level specification mode, payments should link to suppliers and receipts should link to customers. Cash returns / refunds should be entered as negative line item amounts either when part of a larger cash transaction or when entered on their own.

Line item level supplier or customer data entry mode

This data entry mode in Manager requires the customer / supplier be selected for each line item. It allows different line items to be linked to a different customer or supplier

• In barter transaction / Counter trade / Recipient-created tax invoices there are always line items with different customer or supplier.

• Counter trade transactions will always require the entry mode where customer or suppler is specified at the line item level.

• In a counter trade transaction it is never possible to set the supplier or customer once per transactions and have it apply to all line items.

As a result the data entry mode where customer or supplier is specified at the line item level exists purely to support barter transaction / Counter trade / Recipient-created tax invoices.

I theory in the line item customer / supplier data entry mode, line items could default to sale or purchase based on the sign of the amount. In my opinion that would be confusing but it is a way of maintaining compatibility with old data.

Given the function of line item level specification of customer / supplier, the options should be called “Counter trade exchange” and perhaps default to on for old data on off for new data.

PS
If that is the option chosen, for users who never use counter trades, it would be very useful if a simple recode option was available to change all old receipts and payments

• from “Counter trade exchange” / line item customer / supplier mode

• to “transaction level” customer / supplier specification with all line items in payment assumed to be purchases, and all line items in receipts assumed to be sales

[Davide]

I give an idea… how about giving the possibility under settings to show or not, for each Tab, the client/supplier drop-down?

[AJD]

@Davide

Don’t know your nationality but in Italy (so also in most of EU) you should issue a SI by law. You are deliberately reducing the company’s turnover which determines how taxes are applied.

I’m in Australia and yes for large companies there are turnover thresholds which determine the rate of income tax and also a turnover threshold that requires registration for GST. This would be the amount reported at net sales on the GST summary report.

After reference to the tax regulations for trade-ins and barter transactions a tax invoice should be issued for both the sale (trade-in) and the purchase (new vehicle). The dealer may issue a RCTI for the trade-in. So, strictly a PI and a SI is required but this rarely happens in practice.

Therefore the latest set up is correct for this example. I guess the important take-out from this dialogue is that users need to be aware that PI and SI need to be entered for these barter transactions. That is: a negative amount in a purchase invoice for this type of transaction will report both the sales GST turnover incorrectly as well as the financial turnover incorrectly. Using a debit note for the trade in would also report incorrectly.

[Ealfardan]

@Patch

• Receipt: all line items tax is of type sales (independent of the sign of the line item amount)
• Payment: all line items tax is of type purchase (independent of the sign of the line item amount)
• Doing so maintains consistency between cash transactions and invoice transaction

That’s an elegant solution, if I may add, you can change title according the sign to customer refund/supplier refund.

@lubos

I agree. There are going to be improvements to UI but the basic principle that customer or supplier can be assigned to line item is immutable.

Nothing wrong with that but:

First, just to avoid typing customer/supplier a 100 times I will define:
Counterpart = customer/supplier
and hopefully this will be extended to include employees and claim payers as well like @Patch pointed out earlier.

Second, I am all for counterparts in general ledger lines but definitely not like this. I mean couterpart selected after tax code is kind of random, don’t you think?

Counterparts are there to stay but the implementation must be intuitive and fully exploited to the max as follows:

• Counterpart field should not be visibly linked to tax code; tax can use such information but without the arbitrary confusing visual link of the two.

• Counterpart in the lines should be fixed behind account like it’s supposed to (like manager has always been, but this time it’s visible by default and required) and this should serve both as detail for receivables/payables as well for tax code.

• Counterpart field in the header is a must, when a counterpart is selected in the header, two things should happen: (1) the user can fill contact field in case he wants to display a new address or leave it blank to show default address in view mode; and (2) all counterpart fields in the lines are prefilled and greyed out.

But please @lubos don’t keep it like this for long

[Ealfardan]

@Patch

In barter transaction / Counter trade / Recipient-created tax invoices there are always line items with different customer or supplier.

Unless barter transaction is broken down into its two components you cannot really call it a receipt or a payment.

Usually the direction of cash determines whether it’s a receipt or payment but in barter transactions there is no cash changing hands.

Suppose we exchanged tomatoes for onions; is it really a receipt of tomatoes or a payment with onions? If a method leads you to such philosophical questions then – more likely than not – this means that a square peg is trying to fit a round hole and that method should be changed.

Barters are their own thing and since it’s a rare occurrence in business they should be handled using general journals.