I can see why it would make sense to offer advanced options install… or a way to uncover advanced functions… but I can also understand that the REAL demand may not be there. To me it feels like it makes sense… but in real world it may not.
I wasn’t only thinking of very advanced options like this ticket type/warehouse link (I don’t even really need it, I was only suggesting it as a way to make the system even more flexible) but also less advanced parts which probably a lot of users don’t really need to see and get confused about because of the multitude of complex options). These could be hidden per default to make the system look simpler for beginners.
Like when people want to use sambapos for a very basic setup (one department, one menu, one warehouse, etc), they could just download a prebuilt database (once there are some more available of course), and just make some small changes to the menu and such. They wouldn’t have to see all the options they don’t really need for a basic system (unless they wanted to, then they’d just have to click on that checkbox and suddenly everything is there).
But then, that might not be such an important thing to have right now among the list of things to still add to sambapos…
@pipo I got your point. You are not talking about moving warehouse setting from departments to ticket type. You just want a second level warehouse selection for ticket types to override department’s warehouse setting.
I have similar case for menu setting. In fact I don’t like having a menu setting both for department and ticket types. Department’s menu setting useful for a specific case but essential because of how we handle fast food department. Of course it is a little confusing for new users. Should they set it through department or ticket type? It is something they’ll think they need to learn.
Slowly I started to publish “overrides” as actions. I think having a warehouse setter for ticket might solve such needs. However I don’t implement such features by thinking “it might be useful somewhere”. First we’ll find a real life case that we’ll use and implement features to solve that case. That technique reveals if we need to set it through change ticket properties action, update order action or implement a separate action.
I don’t really have a real need (yet) for this feature, so for me it’s not necessary. I’ll just use a custom field for the entity to find the warehouse needed (I can also just hard-code it in the action’s parameter).
I’ll start using V4 now, so I might do things differently than I planned before, I’ll find out after playing with V4 for a bit.
It might be useful to change the captions for these kind of fields, to make them easier to understand. For example you could change the caption for the Ticket Type’s “POS menu” property into “POS menu (dept. override)” or something, and the caption in the Department into “default POS menu”.
Question about having two warehouses 1 used as Main Stock Storage then the other 1 is used as Bar Stocks Storage. All purchases are placed on main stock storage, if bar needs stocks i transfer stocks from the main storage.
Problem is if i look at the report all transfers are recorded as purchases. How should i correct this… thanks in advance
I don’t think this is something that can be changed right now. Inventory transactions update the ‘purchase’ column in end-of-day records. It is basically a zero price purchase from another department.
Thats bad news for me. i wish theres a workaround
I have many Warehouses, and this may be overkill, but it works for me:
(Local Warehouse) SHOP
(Local Warehouse) BODEGA
(Supplier Warehouse) Supplier1
(Supplier Warehouse) Supplier2
(Supplier Warehouse) Supplier3
(Supplier Warehouse) ...
(Supplier Warehouse) Supplier20
Each of the Warehouses are linked to their own Entity and Account.
I have 3 Inventory Transaction Types:
Inventory Purchase Tx
Inventory Txfr (SHOP to BODEGA)
Inventory Txfr (BODEGA to SHOP)
When a Supplier delivers Product, the first Type is used. This effectively transfers Stock from the Supplier Warehouse to the SHOP Warehouse. An Account Transaction is also created, moving money from one of my internal Accounts to the Supplier Account.
Then I transfer extra Stock from SHOP to BODEGA using the 2nd Type. No Account transaction is made, so it is like a zero cost Account Transaction, but the Stock Quantities in each Warehouse are updated. This is the Physical Stock counts, not the Consumptions.
Later in the week/month, I transfer Stock from BODEGA to SHOP using the 3rd Type. Again, no Account transaction is made, so it is like a zero cost Account Transaction, but the Stock Quantities in each Warehouse are updated. This is the Physical Stock counts, not the Consumptions.
The SHOP Warehouse is the only one which sees Consumption of Stock from Recipe definitions.
Here is an example of what it looks like … watch Croissant:
Purchase:
Transfers:
Transfer:
End of Day:
This is all done very easy, facilitated by this: