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.
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.
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.
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
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
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.
- 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.
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…
This is being covered by this topic. Working on it.
Perhaps I should have been clearer
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.
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?
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.
- 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.
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
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.
You are correct.
The reason I grouped them is
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.
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%
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.