Order management went back with features?

[cmatte]

Hi, I'm using a vm1.x shop that is working and functional and I am now trying to develop a new one with vm 2.x.
I've just tried sending an order and I've just discovered a huge difference. I see I can only change state and put comments in my orders, or change the status of a single product. The old vm 1.x allowed to do every other change you could want, starting from prices of the products chosen, removing/adding/opening products listed, adding/removing fees, and so on...all this is not present in vm 2.x.
I was sure we all wanted to go forward in features, not back. Is it something you're going to work on? Is intended to always stay this way? Am I missing something else that allows me to do the same elsewhere or in another way?

Thanks 

[Milbo]

The problem is the advanced stocking feature and others things like this. The vm1.1 way produced very fast inconsistent data. What todo with the tax in that case, what todo with the inventory, do we allow to override the costprice or the final price and so on.

So of course we wanna readd such features, but maybe as consequence of a ticket-to-bill-system.

[cmatte]

Mmh, that's interesting, how did vm 1. create inconsistencies, with inventory and/or what else?

Well, I understand all the problems with how to calculate taxes, recalculate, leave them as they were, and so on. That's a good point. But I think that when an admin changes values there doesn't want any recalculation of taxes, does want to be able to override any cost/final price, does want the inventory, if used, to be decreased the right way. I also understand this is just my own opinion, and someone could want it to be different, so I got your reasons, but I still think we should give flexibility at first, then, when/if it's not a nightmare for devs, give automation. What I mean here is, I surely would want to furnish personalized orders due to possible problems and so on. Mainly because here we are denying to receive payments that are different from the store-given price, what if the client is paying with paypal? I would have to ask him to send a payment himself, it would be a real nightmare, other taxes would born, it's quite impossible imho. I think you should then discharge the responsibility of modifications to the store admins that do them. So, if I want to recalculate taxes, well, I know I have to do it myself at this point. Inventory, well, the numbered items are decreased, if it's one more change it, if it's two at the price of one, put in two and decrease manually the price of one as a discount. Etc...

What is a ticket-to-bill-system? Something like clients can ask for all those modifications on request? Seems a huge project 
I think here we miss we could want to modify an order just because the client wasn't able to do it the right way / has particular discounts or requests that have to be paid. All these requests, I think, are done by phone the most or by email, and I'm quite sure a client won't change its order details by himself. We want to be efficient, so, client calls, we solve the problem on the fly, he can pay its price, done, we are all happy and fast.
Can I have the hope to see these options in a minor upgrade? If yes, do you think it will be a long-time wait?

[Milbo]

I agree completly. I just think that it is important to create good tools with it. Like recalculate taxes. Set manually the stock modifier and things like this. It should also be mentioned in the order history and so on. Or a js which indicates the fields which you have also to manually alter when you change a field. There are various ideas.
There is also the idea to create for this a more advanced order view. Connect it with a invoice center, ticket system and more (simular als you already described).

In general we have some more features then vm1.1 and we are 2-3 features still missing. We priorise this next time.