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.
No, I’m not saying there is a technical reason. I’m saying the entire scheme for batch operations works by modifying a list in a spreadsheet made up of individual rows, with each row being a similar thing, such as a customer or an inventory item. A recurring transaction could include many line items, in addition to all the header information, custom fields, and so forth. So a recurring invoice could not be represented by a row in a spreadsheet. So a completely different concept would be required. Additionally, there could be dozens of preferences for how users might want an automatic update to work. Batch operations are not automatic; they require proactive manipulation of every cell in every row that you want to change. Powerful, but not automatic.
This is still an interesting idea, just not straightforward.