Product change rollout philosophy

[Davide]

@eko

Of more concern is what happens if for any reason the developer can not continue. Without some wider trusted development team there is a great risk that at some point in time there will be no changes made even when times and needs change.

This is what fraighten me more of Manager.

[Patch]

@dalacor

Changing tax from debit/credit to payments and receipts - You yourself were affected by this issue and when it comes to tax records, the developer really has to be including end users in the decision making process. You cannot alter previous tax records in the program so it not longer matches the figures that you submitted in previous years.

When the prior reports were wrong then it is imperative Manger corrects the error. So this is exactly what should happen. To explain:

Tax reporting requirements are written in term of details of specific contractual relation between supplier and customer, products and services a business actually supplies as part of its business activity, acquisition made for specific use in a business to product taxable supplies, and retention of a common tax invoice between suppler and customer. For any giving jurisdiction and transaction between two entities these taxation requirements define who is the customer and who is the supplier, there is no flexibility. The assignment does not depend on which software package is used or if a business’s book keeper chooses to enter a transaction via the software packages’ cash sale/purchase mechanism or via a software package’s invoice.

An example of it’s significance is in Australia “G1 Total sales” is reported. The recent Jobkeeper subsidy for COVID is based on this figure. Jobkeeper provides a government subsidy of $19,500 per employee & one owner as well as a cash flow boost of between $20,000 and $100,000. These payments are not retrospectively claimable after the cut off dates. In addition in Australia GST on sales, and GST on purchases are separately submitted to the tax office which the business owner must verify are accurate, the tax office then calculates the net GST owing.

@dalacor

But my understanding is that 99% of the entries in Manager are not affected - regardless of which method Manager is using.

If you

• do not use cash transactions for barter / counter trade / Recipient-created tax invoices
• do not use cash transactions for refunds, returns, discounts, or other negative line items

Then the debit/credit to payments and receipts changes will make no difference to you.

If you only do one of the above then some versions will result in erroneous submissions to your tax office. For example

• Manager versions v20.7.30 - V20.8.66 produces correct VAT/GST submissions if you sometimes use cash transactions for refunds, returns, discounts, or other negative line items but never use cash transactions for barter / counter trade / Recipient-created tax invoices

• Manager versions older than about v20.7.30 produces correct VAT submissions if you sometimes use cash transactions for barter / counter trade / Recipient-created tax invoices but never use cash transactions for refunds, returns, discounts, or other negative line items

• If you sometime do both of the above all older version of Manager produce erroneous VAT/GST tax returns

The important thing to realize here is Manager producing the old VAT/GST reports does not make it right. You keeping old versions of the data file and program does not make them right either. The most it does is provide evidence to your tax department that it was on honest mistake, you tried to submit accurate data.

Now business owners have been alerted to the fact some of their old submissions were erroneous, corrective action maybe required depending or specific jurisdictions requirement to report errors when recognized.

A relatively easy way to find out it this may effect a business is to load a backup into

• Manager version V20.8.65 and V20.8.67 (you will need to un-install newer versions of Manager prior to installing these old versions)

• in each version create a VAT/GST report for the entire period this business has used Manager

• If they are the same then it is likely none of this is relevant for that business (the test misses refunds done on their own and entered as a positive amount. Looking for receipts in expense accounts and payments in income accounts may help find these)

• If they are different you will need to find which is actually correct, and ask your accountant how you report the error to your tax department (if your jurisdiction requires timely correction of such errors)

I do however agree with you that users need to know when their current records show past submission to any external party are no longer correct as discussed here Feature Request: Report Snapshots - #17 by Patch

[Partha]

Money could consider these modules 1. core system for accounting 2. multiple modules for specialized business flows which post entries at some point 3. i use for financial accounting purpose and they can do these things a. FD / debt instrument / cash flows ; equity and insurance enrolling integrated with cash flow statement. actual accounting could happen on basis of bank entries. accrual could be automated. architecture where my data file stays in gdrive and work through browser ; this model gives data security and privacy.

[dalacor]

The solution that Lubos has suggested - which I agree with - is that Manager fixes the bugs, but alerts users to the fact that previously submitted tax figures have changed. You can then create a journal entry in the relevant year to reconcile the previous years submissions so that once again they match what you submitted to the authorities. Then in the current year, you can reverse that journal entry(s) and then pay the correct tax due whatever that may be. This way, previous year’s submissions in Manager match what you submitted as result of this journal entry(s), but your current year corrects any tax differences as result of reversing that journal entry(s).

We are not in disagreement. I am in full agreement that Manager should fix the incorrect tax submissions, but we still need to find a way to demonstrate to the authorities why the figures in Manager no longer reconcile with what we submitted years ago - otherwise how else do the tax authorities know that we are not cooking the books?

His suggestion in my opinion is the correct approach as it a: fixes the incorrect tax results, but also enables you to show the taxman that you are not fiddling the books. I don’t know how it will work in practice, but I think the theory is sound.

[d3mad]

@dalacor

The solution that Lubos has suggested is that Manager fixes the bugs, but alerts users to the fact that previously submitted tax figures have changed.

Where did he say this?

@dalacor

His suggestion… is the correct approach as it a: fixes the incorrect tax results, but also enables you to show the taxman that you are not fiddling the books.

The reason I have started numerous threads and been moderately vocal about this exact topic in the last few weeks is because manager does not alert users when tax figures have changed and so when the tax man comes calling it does look like you were cooking the books.

Lubos has explicitly said if the values do change it’s because we relied on bad behaviour that he has weeded out of the program and then left it to us to sort out for ourselves.

[dalacor]

He has said that in future the program will implement something like this using the history audit trail. There is nothing in place at this point in time. This is a future feature that he is considering.