Product change rollout philosophy

#8

@Patch

You have completely misunderstood my post. Manager compared to say MYOB has quite a lot of interaction between the developer and the users of the product. I am in full agreement with you on this point. The developer is a very active user of the forum and I would suspect reads most topics if not all. Yes he engages with his users quite a lot. No argument from me!

I am also in agreement with you that the developer has a better understanding of the product from a user’s viewpoint that most companies. Again agreed.

I also believe that in the main the product is very well designed as it has very few (if any bugs), is so simple to use and is very reliable - no crashing, performance is excellent etc.

None of these points are in dispute.

I never said that I or any other user expects full agreement in any area and it’s never been the case (generally) where one person expects the product to be changed just for their special use. This is not what I said. I disagree that the problem is that users believe that they are in control of the software development goals and priorities. It has long been a complaint amongst users that there is no roadmap in place and we have no idea when (or even if) any idea will ever be implemented. Secondly, it has been complained that new features seem to be implemented in a very haphazard manner with no bearing on what would make the biggest difference to users (such as batch printing for example).

The forum is being used as a feedback panel and yes I will grant you that the developer listens to feedback very carefully after rolling out a new feature. But my point is that this is not the way to roll out new features and program updates. The problem is that more than once the developer has released an update without warning which caused a lot of problems for many users (many of whom are not wanting to be guinea pigs), with the result that he had a lot of complaints by frustrated users. This is completely unnecessary. Instead of rolling out an update to everyone - it actually makes sense to roll it out to a small group of people who are happy to have a copy of their business imported into the beta version, so that they can provide feedback on how the changes affect their businesses.

Then the developer at his leisure, can tweak the program accordingly to address any concerns raised by the feedback panel before releasing it to a stable version. I see no logic in releasing an update to every single user and then having to deal with lots of users complaining about missing information or incorrect information etc etc. All I (and other people have been asking for) is to have a stable track released to the public and a development track released to people who wish to participate in using the beta version to provide feedback on new features. The problem is that nobody can think of all ramifications of how a new feature would affect every business. That’s why you ask other people. I want to him to get feedback on a new feature before releasing to the public, not after!

I am a big fan of the developer as I think that he has a great product and he does engage quite a lot with his users. But this does not negate the fact that many companies like Mozilla and Microsoft for example have a beta version and stable version - where insiders can choose to use the beta versions and provide feedback to Mozilla and Microsoft. This is why I say he doesn’t listen, because this point has been raised quite a few times. He seems to have a blind spot on this point and I have lost count of how many times an update has caused one user or another grief over the last few years and it does cause a loss of confidence in Manager.

#9

The posts in this topic have been moved here because they are not specifically relevant to the discussion of changes to receipts and payments. It’s fine to have this discussion, but in its own place.

#10

This would be great to implement.
Another big problem is the inability to roll back versions. Surely if there are no changes to the actual database structure itself this would be possible?

#11

Yes, I’m agreed that to release only stable version.
If you need community help for alpha testing, allow users to give alpha release url to test with their own business case
it will be better for both

#12

In the last “Manager Product Updates” the developper wrote:

• The program temporarily includes two versions of the Dutch Concept BTW Aangifte report transformation. The original version remains for continuity. The new version is available for testing to confirm it remedies problems reported with the old one. Feedback should be provided on the Forum

This I think is proof of listening to users. I have tested this “experimental report” and I have reported my findings / conclusions / recommandations to the developper. I don’t know if other users did the same, but it is anyway a step forward. Both in the approach of a problem and hopefully a solution for the problems. Anyway I am very hopeful.

Sometimes the developper has to decide what is good for us and what not. You simply can’t keep everybody happy. We have a way of discussing things in the Netherlands. It is called “the poldermodel”. Things are discussed very broadly with all kinds of (possible) stakeholders. Quite a nice model when you reach concensus, but it leads to very long discussions and it is very time comsuming. Please let’s avoid this…

#13

  • Ensure you have backups of any data files you value

  • Uninstall your current version of Manager

  • Install an older version of Manager

  • Try opening a copy of your data files or a copy of your backups

#14

Yes, BUT, what about all the transactions that have occurred in between versions.
I do keep one or two previous versions along with file backups taken before updating.
The problem is when, after five days of use, I discover something is broken or not working the way it was, I then have to roll back to the previously saved version and re-enter all transactions that were entered in between.
This was a HUGE problem recently for me with the changes to the GL transactions report which I print out monthly. I had no way of recovering over a months worth of transactions by rolling back and I should not have to go through and try out every aspect of the program after updating to make sure it still does what I expect it to.
Also, one of the things that gets thrown at you when you ask questions here is “You are several versions behind, update to the current version and check again”. I have never yet been able to open a file from a later version on an earlier version, so if updating is done you are are stuck with going through everything you can think of to see if the later version actually fixes your problem or even works properly.
I would rather spend my time in my business than stuffing around with an accounting program.

#15

Did you try opening a copy of your current data file with an slightly older version of Manager which has the specific feature you wanted to retain?

It worked for me.

#16

At the time the problem occurred I tried but it did not work.
But even so, to get help here you are always told "You are several versions behind, update to the current version and check again” so what’s the point?

#17

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. As it is not easy to migrate away to another application I realize that I am stuck to whatever is implemented here. As such I also sympathize with those that ask for better communication about the risks when updating code or asking for changes o improve the use (is what this forum is for). No one wants to loose years of accounting data by software that at some point may become obsolete as roadmaps and continuity planning are not clear.

#18

@Hennie The inclusion of the two versions of the Dutch Concept report is about the only time that I am aware of when the developer has done something like this - apart from the old and new custom reports forms. What he did there was a good idea. He released the new feature, whilst keeping the old one and asked users for feedback on how it works in real use.

I think in those two particular cases he wasn’t sure how it would work and required users to provide him with feedback. It wasn’t so much a question of him listening to users, but rather because he couldn’t proceed further without input from customers. However, it is pointless to debate this point as we don’t know and it’s not really germane to the discussion anyway.

I am not expecting the developer to keep everyone happy and secondly, I don’t think that he needs to discuss every single change with users as you are quite right that it would end up in very long discussions and be very time consuming. I work in IT and I have the same issue. I don’t consult with my clients about every single change I made, because I would never get anything done as result.

But there are times when implementing a new feature that it makes sense to have input from customers before rolling it out to all users.

For example the following changes caused a lot of frustrations to users when these changes were just implemented without warning!

  1. Changing the summary page from the old format to the new format - The developer had to spend quite a lot of time resolving all the various complaints from users about the new layout. I still agree with a lot of people that the loss of aged payments and receivables was a step backwards and I am still waiting for this to be brought back! I really hope that the developer brings aged payables/receivables back as this is information that should be on the Summary Page.

  2. 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. I am hoping that the new solution (which I thought was quite clever) has fixed your problems, but I submit that this whole angst was entirely unnecessary. The discussion should have been had before rolling out the changes, not afterwards. One user actually updated the program just hours before he was due a meeting with his accountant to discuss his accounts. Not good at all. I would have been furious as I don’t need accounting problems hours before going to my accountant.

  3. Linking customers and suppliers to payments and receipts. - I personally am very happy with this feature, but @Tut was hopping mad about this, because he doesn’t use customers and suppliers and he quite rightly pointed out that not every business works the same way. In point of fact, Tut made the exact point that I am trying to make here. Every business works differently, which is why the developer needs a feedback panel to see how new changes will affect all businesses, not just how he would have the business setup. As Tut said, every business is different so you cannot apply a one size fits all solution like expecting all businesses to use clients and suppliers in order to put a payee or payer in the field on the payment/receipt forms. Again this angst would have been avoided with a feedback panel forum.

  4. Adding three new tabs in relation to bank and cash accounts - The changes here could really have benefited from feedback from users before implementation. Many people are not convinced that the current design is optimal. We have lost functionality that was in previous designs and now have more tabs as result. I actually made a post somewhere where I provided a solution to amalgamate a lot of these extra tabs into fewer tabs whilst still retaining all the information. The implementation of this could be a lot better in my opinion. Bank reconciliations I understand had functionality in it that was lost when the new design came out. I speak under correction, but this has still not been addressed.

My suggestion of having a development/stable track would simply mean that discussions would take place on the forum as they have always done, but the difference would be that users would not be upset that their live business accounts have been altered. The new features would be implemented on the development track and any users who wishes to join in the development track beta basically has their live business on the stable track and a copy of their live business on the development track. This means that their live business is safe and they have a chance to provide feedback on new features rolled out onto the development track without getting annoyed because they have lost information or whatever on the live business. Also it would ensure that only people who wish to contribute to the discussions are involved instead of having users who just use the program having to login and complain that they have lost something as a result of the update. The current design makes every user (paying or otherwise) a guinea pig in the development process. The vast majority of users just want to use the program - they don’t want to be on the forum discussing Manager feature changes. This factor needs to be considered. I enjoy being on the forum discussing Manager, but I use a lot of programs and I don’t want to be on the forum for every program that I use to discuss development of it.

Mozilla, Microsoft etc all have insider rings or beta testers. Why does Manager development not recognise the benefits of having a development track that allows new features to be provided feedback on before those changes are rolled onto the stable track. It would make no difference to the amount of discussion because we already discuss all the changes to Manager on the forum anyway. The difference would be that the changes we are discussing would be on the development track not on our live businesses! We could provide feature improvement feedback before rolling out to live, not after!

As for @Patch asking who chooses the membership - it would work the same way as Microsoft and Mozilla and other companies do it. Users can opt to join the development track. Nobody chooses who is on this panel. All users who want to participate can join. The key point is that you have your live business on the stable track and also have it on the development track - I am not exactly sure how the developer would get that to work, but that to me makes brilliant sense so you don’t have to keep exporting and importing your business between the stable version and the development track.

I really hope that we get a live and development track soon as well as a roadmap!

1 Like
#19

Yes, it has, in version 20.8.44.

#20

Ok I have not seen the changes because I have not updated since July. I am waiting on Lubos to fix the issue with customers and suppliers showing in the contact field on the new payments/receipts instead of in the new payee/payer fields that have been created. Otherwise I will need to do some kind of find and recode operation.

I am looking forward to seeing these options for Bank reconciliation because that functionality was lost before I started using Bank Recon.

#21

8 posts were split to a new topic: Converting old payers/payees to customers/suppliers

#26

This is what fraighten me more of Manager.

1 Like
#27

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.

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

#28

Money could consider these modules :slight_smile: 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.

#29

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.

#30

Where did he say this?

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.

#31

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.