that’s a good point
Tut, I agree that Batch Update (and Batch Create / Delete) should be supported on Recurring Transactions, but can I also get your opinion on updated Selling Prices (for Inventory and Non-inventory items). When you create a recurring Sales Invoice with an inventory line item, I would have thought that when the new Invoice is created it would use latest Selling price from the item, regardless of the original selling price when the recurring invoice was originally created. Since Inventory and non-inventory items has batch update functionality, and if this is an easier enhancement for Lubos to implement, would this approach not make sense until such time as batch functions are implemented for recurring transactions?
You should not expect this. Consider the following situation: A company sells subscription services at prices fixed for the duration of a contract, with monthly billing. A recurring invoice needs to be fixed through the defined period. The next week, the company may sell the same subscription service to a new customer at a higher (or lower) price. The recurring invoice for the new customer needs to also be fixed for a different period. Automatic price updates would cause the business to violate the terms of its contracts with existing customers. The point of a recurring sales invoice is that the invoices for a specific customer can be standardized, regardless of what is offered to other customers.
Then I think automation options are limited. If inflation data is annual inflation then this process could be done annually, when the data is released. If it is the inflation over the prior term for each contact, then it would need to be calculated more frequently.
I agree in this instance it is limited for reasons provided. We like the way it is as we have fixed amounts throughout and it would be actually worrisome if these changed because of our changes in costs. The whole purpose of recurring sales invoices deals with some kind of agreement within which these occur. If there are too many changes it should not qualify as recurring as it now seems that if a client gets an invoice the subsequent ones need to be labeled recurring while in essence the parameters change enough to be a new invoice.
This is true, but the user remains in control of changing the item selling prices and could achieve the same by having items per contract. Having batch functions on recurring transactions remains the most logical solution for the moment, as it will enable maintaining more that selling prices.