I’ve noticed what I think that I’d call a (minor) bug with Recurring Sales Invoices.
We’re using the Desktop version with our Association Membership subscriptions set up and priced as Non-Inventory Items and then these items entered as Recurring Sales Invoices to each member, and this seems to work fine.
The subscription amount was changed at the AGM this year and the Non-Inventory Items were duly updated with the new prices.
However we now find that the updated prices did not flow though to the Recurring Sales Invoices nor the subsequent automatically generated invoices. This is not the behaviour expected and we now have to manually amend each automatically generated invoice plus each Recurring Sales Invoice.
There are only 70 members and the prices don’t change that often, so it’s not such a big deal, really this is just a heads-up for you @lubos.
not all business sell the same item at the same rate to all their customers. every customer is sold at a different rate. so updating the selling price of a non-inventory item is just a reference and does not have to change the rates on invoices automatically.
not all business sell the same item at the same rate to all their
customers. every customer is sold at a different rate.
In which case it would be simply a matter of entering these different priced non-inventory items as separate entities. Are you saying that you think that non-inventory items should not have a price field?
Recurring charges such as rent, membership fees, service fees and the like are entered as non-inventory items, which have prices set in the sales-price field and that is where price changes are entered.
The issue here is what happens when the price of a recurring non-inventory item is changed which is a quite normal occurrence.
To me, it doesn’t make sense to also have to re-edit every single Recurring Sales Invoice (painstakingly set up for each and every customer) to delete each line-item (because its price hasn’t updated) and then to re-enter the exact same item (which will then show the new price).
no. all i was saying is that what has been set to recur should only recur.
when you have created a recurring sales invoice at a specified rate and changing the rate of few things elsewhere should not affect it. this would be like the system taking over control from the user.
you have created a recurring sales invoice at a specified rate
No, it was ages ago, but I created SEVENTY Recurring-Sales-Invoices of specified ITEMS. I didn’t have to set the rate, it auto-completed, set elsewhere, in Non-Inventory Items. A few prices were changed, now I have to do SEVENTY more Recurring-Sales-Invoice edits.
and changing the rate of few things elsewhere should not affect it.
Can you give me an example of a circumstance where you think having recurring non-inventory invoices keeping their item prices current would be a problem?
this would be like the system taking over control from the user.
I think that it would be like the system doing what I want it to. Updating the price of an item should be the end of it. Why shouldn’t recurring invoices reflect the current item price. Why should another 70 edits be needed. What if there were 10,000 customers which had recurring invoices (for an item the price just got changed on). Should you have to do one edit or ten thousand?
when you create a new invoice, the new rate will automatically show.
the new rate will not change already defined rates in sales invoices or on recurring sales invoices because the user has defined the rate at which the sales invoices have to be repeated. if the user wants to sell at a different rate, the user should set the rate on the invoice wherever applicable.
You asked for an example, @Bob_Hunt, of where you would not want prices to update automatically. The most obvious would be when you have a contract with a customer for a defined period, but want to update prices for new customers and other situations.
Suppose you offered a lifetime subscription rate to recruit new members at 50 per month. You would set up the recurring sales invoice for that member at a price of 50. Next year, you increase membership to 55 per month and change the non-inventory item to 55. You would not want that lifetime member’s invoices to increase to 55. Nor would you want to edit her recurring sales invoice back to 50 every year in the future when you increase prices.
Suppose you offered a lifetime subscription rate to recruit new
members at 50 per month. You would set up the recurring
sales invoice for that member at a price of 50.
Next year, you increase membership to 55 per month
and change the non-inventory item to 55.
In your example, I would not change the price of the existing fixed-price item (let’s call it 2017_life_subs) to 55, I would simply create a new non-inventory item (2018subs), and use that new item when setting up any new recurring invoices.
In an everyday situation where prices are not set for life and you gradually add members over time, you would set up recurring invoices for new members as you go. The way Manager currently behaves, a simple item price-change a year later when you have say 1,000 customers would cause you much grief. I think that Manager currently has a real shortcoming in its handling of price changes for recurring sales, which causes unnecessary work for users.
I still don’t see a downside to automatically keeping Recuring-Sales-Invoice item prices current, but perhaps a checkbox could be added against each customer listed there, allowing the included sales-items to be updated with the up-to-date item sales-price?
I think you miss the point, @Bob_Hunt. A recurring sales invoice in Manager is exactly what it is called: a recurring invoice, not a recurring sale of an item that might change price. And what suits your particular situation would not suit many others’.
A recurring sales invoice in Manager is exactly what it is called:
a recurring invoice, not a recurring sale of an item that might
change price
what suits your particular situation would not suit many others
I do understand.
However Recurring-Sales-Invoices are not actual invoices, but templates to produce them automatically. I like automatically.
Our particular situation is also likely to be a very common way for Recurring-Invoices to be employed. Surely it must be possible to give Manager the flexibility to be able to cope with normal price changes, in everyday situations like ours, in a more efficient way than at present?
Repeatedly deleting an already entered item, and then re-entering the very same item 70 times, in order to get the current price to appear, was frustrating. Its the sort of job a computer should do.
I feel for those users who have a large subscription customer-base, who may be considering a price change.
How about implementing a check-box on the recurring invoice form ‘Reprice on Invoicing?’ That would allow the user to specify when defining the recurring.
We just increased our monthly club dues for the first time in three years and had to update 70+ recurring invoices.
It doesn’t seem reasonable that for users of recurring invoices, so much work can be caused by a simple change in the price of an item.
@lubos , what are the chances of adding the ability to auto-update the prices of items in recurring invoices or of adding a batch-create function there?
I can understand this from both sides, and I think a checkbox would be the perfect solution.
We have a large number of recurring invoices, however have not raised prices since we started the company, but that may change in the future. The automatically updated prices would help us out in that sense.
However, we also have a large number of resellers of our product. For example, Customer A is a retail customer, and pays $34.95 for a product. But Customer B is a reseller who we have given a special price of $24.95 to allow them to mark up to THEIR end user. Automatically changing prices in this case would hurt us, because as mentioned above, not every customer pays the same price for the same service.
Personally, I would not want to have a “service 1 - retail price” and a “service 1 - reseller price” item in inventory, it’s the exact same item just different prices, it doesn’t seem efficient to have multiple copies of the same item.
While I am the one who moved this to the Ideas category, I hope those supporting it will read the various comments made so far. (That’s the purpose of the Ideas category, to encourage discussion).
From everyone’s individual perspective, this seems like a small change, but from a universal perspective, there are many factors that have to be taken into account before implementing anything:
Some users will want a specific invoice, with specific prices to recur and be immune to all change.
Some will want existing recurring invoices to be updated if an underlying inventory item price is changed, without having to intervene in any way.
Some will want an edit to a recurring invoice to change all future invoices generated from that recurring invoice definition.
Some will need to maintain different prices for the same item on different recurring invoices, while maintaining some other price on non-recurring invoices.
Some will need to selectively update pricing for certain customers.
And, for everyone who wants one of the above options, there will others who do not and who would consider it a great burden. And the more option that are available, the more confusing the choices might become. We have all experienced choices when setting up computer functions (printing, spreadsheet preferences, etc.) that we could not understand. One of Manager’s design philosophies is to minimize such confusion by keeping things simple.
So, any change is likely to take time. And we should all be patient to avoid getting something that actually makes more work rather than less. Meanwhile, remember that Manager is usually quite parallel in its functions for sales invoices and purchase invoices. So any scheme has to accommodate purchasing as well as selling.
So what about the idea of adding “batch create”, “batch update” and “batch delete” buttons to the bottom of the recurring invoices page, as per many other pages in Manager?
This could provide an efficient solution to the problem which might suit all.
Batch operations only let you modify lists, not transactions.
That certainly makes sense, since transactions involve changes to account balances.
But recurring invoices do not affect any account balances until the actual invoices get created, once triggered. One could look at recurring invoices as a list of invoices (transactions), scheduled to be created.
But I suspect what you are saying that there is a technical reason this can’t be done.