Apr 13, 2015
Yosh M wrote
Hello,
I realize this might be a bit complicated to implement, but it would be extremely useful, since multishop management in the Store Manager is not very user-friendly from my point of view. The PS backoffice does this very nicely (SM does not do it at all): when you select a shop from the shop selector dropdown and then go to Customers you only see customers from current shop, then you can move on to Orders and you will see only orders from that shop (the context does not change) and so forth with every section (addresses, attributes, etc).
On the other hand, this is how SM works: on the "Categories & Products" select a shop to manage categories & products for that shop, then move on to "Orders" section, now you have to filter AGAIN per shop, then move on to "Customers & Groups" section and sure enough, you have to filter once AGAIN per shop... (when all I am trying to do is just manage data from 1 shop). Now, for instance, go back to orders and filter by a different shop in to view orders from that shop (lets call this new selection shop B), now click on "Point of Sale" to add a new order... guess what? the new order is added to the first shop selected way back at the beginning in the "Categories & Products" section, instead of being added to the current shop B selected in the "orders" filter from which we clicked on "POS".
Furthermore, the POS does not filter the customers per currently selected shop, so it allows to create an order on shop B for a customer from shop A (this customer never registered and is not related at all to shop B), so it guides to even more confusion. For instance, when opening POS from any window other than Categories & Products, there is nowhere in the screen where you can see in which shop the order is being created...
I hope the shop context synchronization between sections can be improved because it is quite needful, and the POS needs the bugs mentioned above fixed...
Any questions let me know.
I realize this might be a bit complicated to implement, but it would be extremely useful, since multishop management in the Store Manager is not very user-friendly from my point of view. The PS backoffice does this very nicely (SM does not do it at all): when you select a shop from the shop selector dropdown and then go to Customers you only see customers from current shop, then you can move on to Orders and you will see only orders from that shop (the context does not change) and so forth with every section (addresses, attributes, etc).
On the other hand, this is how SM works: on the "Categories & Products" select a shop to manage categories & products for that shop, then move on to "Orders" section, now you have to filter AGAIN per shop, then move on to "Customers & Groups" section and sure enough, you have to filter once AGAIN per shop... (when all I am trying to do is just manage data from 1 shop). Now, for instance, go back to orders and filter by a different shop in to view orders from that shop (lets call this new selection shop B), now click on "Point of Sale" to add a new order... guess what? the new order is added to the first shop selected way back at the beginning in the "Categories & Products" section, instead of being added to the current shop B selected in the "orders" filter from which we clicked on "POS".
Furthermore, the POS does not filter the customers per currently selected shop, so it allows to create an order on shop B for a customer from shop A (this customer never registered and is not related at all to shop B), so it guides to even more confusion. For instance, when opening POS from any window other than Categories & Products, there is nowhere in the screen where you can see in which shop the order is being created...
I hope the shop context synchronization between sections can be improved because it is quite needful, and the POS needs the bugs mentioned above fixed...
Any questions let me know.
Completed
1 vote
Vote
Reply
3 Answers
Apr 15, 2015
Alex Pryshlivskiy
agent
wrote
Hello Yoush.
Do you need Global seleector for everything ? right ?
For example - we have Shop selector in Products\Categories, Orders - see screenshot shops-1.png
So you need to implement such option for POS (order creation) - shop-selector.png
Please confirm. Am I right ?
Do you need Global seleector for everything ? right ?
For example - we have Shop selector in Products\Categories, Orders - see screenshot shops-1.png
So you need to implement such option for POS (order creation) - shop-selector.png
Please confirm. Am I right ?
Apr 15, 2015
Yosh M
wrote
Yes, the POS definitely needs a shop selector because right now you don't know to which shop the order is being added.
2) The POS should filter customers per current shop like the PS BO, it doesn't make sense to add an order to Shop A for a customer from Shop B (unless shops A and B are in a shop group with "shared customers" enabled).
Furthermore, what I was trying to communicate is that I think the shop selection should be common to the whole application. When I select "shop A" in "categories & products" and then I go to "Orders" I'd like to see only orders from "shop A" automatically (without having to filter again), but maybe this is a personal preference. I personally prefer the way PS backoffice handles this.
2) The POS should filter customers per current shop like the PS BO, it doesn't make sense to add an order to Shop A for a customer from Shop B (unless shops A and B are in a shop group with "shared customers" enabled).
Furthermore, what I was trying to communicate is that I think the shop selection should be common to the whole application. When I select "shop A" in "categories & products" and then I go to "Orders" I'd like to see only orders from "shop A" automatically (without having to filter again), but maybe this is a personal preference. I personally prefer the way PS backoffice handles this.
Apr 15, 2015
Alex Pryshlivskiy
agent
wrote
Thanks for comment.
ok. I'll try to discuss this suggestion with our development team.
But I'm afraid we'll not be able to implement this suggestion before summer.
All major tasks were included in future sprints - April, May, June.
ok. I'll try to discuss this suggestion with our development team.
But I'm afraid we'll not be able to implement this suggestion before summer.
All major tasks were included in future sprints - April, May, June.