Added ability to attach customer or supplier to any tax transaction

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.

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.

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).

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.

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.

A post was split to a new topic: View screen shows tax when edit screen has no tax selected

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

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.

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

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

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.

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

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 :grin:

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.

You are correct.

The reason I grouped them is

  • Counter trade / Recipient-created tax invoices

have a component of barter trade but typically also contain a component of actual money transfer. As such they must be handled by Managers invoice or cash transaction mechanism.

A Counter trade / Recipient-created tax invoices with a vanishingly small money transfer is a pure barter trade. They can still be handled by Manager invoice or cash transaction mechanism using a zero value receipt/payment (or zero value counter trade invoice). Alternatively they could be handled very cleanly by a journal entry.

A choice the user can make. Personally I would used the same mechanism a I used for other similar transactions, just to keep similar things together.

In the latest version (20.8.86) it’s now possible to select customer or supplier on receipt/payment level.

If you select customer or supplier on receipt/payment level. Ability to select customer/supplier on line item level will be hidden as it is assumed every line item will belong to the customer/supplier on transaction level.

Is there a recommend workflow to move from single tax code to two tax codes? Will this type of change affect past transactions?

This update does not make that necessary. We can continue using one tax code for both sales and purchases. So no changes.

Yes I understand that it’s not necessary, but in case I have to switch for reasons that for example the audit requires to keep track of two tax codes. Then what?

There is going to be new Find & Recode tool which will allow you to recode in bulk any attribute so that would be a solution.

2 Likes

Thanks @lubos.