How to read entity 'warehouse' property

Although it wouldn’t help me at the moment since I’m still stuck to V3, that would be a good update, since departments can have separate tickets and menus which shouldn’t necessarily be dealing with one single warehouse.
Maybe a better way to handle this would be to link a warehouse to ticket types and reading the order’s warehouse from the ticket type? Also adding the ‘Change Warehouse’ parameter in Update Order would make it even more flexible of course for specific cases.

If you think about for what cases you create new departments and ticket types you’ll quickly see configuring warehouses through ticket type is not a good idea :slight_smile:

I’ve been configuring departments and ticket types for all kinds of purposes. Why wouldn’t it be a good idea to link warehouses to ticket types?
Maybe it’s just too late and I’m very tired (it’s 6.20 in the morning here), but I don’t get what you mean…

I mean… for example if you create a “Refund Ticket” type you should configure one for each warehouses.

Think for I have Bar, Restaurant departments and related warehouses.

I don’t know if you misunderstood what I meant or it’s the other way around.
What I meant is to have a ‘warehouse’ field in the ticket type, so that when you create the orders for this type of ticket, you check the ticket type’s warehouse instead of the department’s and put that in the order.
I’m not sure how a refund ticket works, but why would it have anything to do with the warehouse? Refunds don’t update any inventory, or do they?

A refund could update inventory counts, if the item is returned unused, unopened, undamaged, etc. In that case, the item could be placed back in stock.

I see.
In that case wouldn’t the refund ticket just be copied from the original ticket (and using the same warehouse for each order)? What could go wrong with that?

This is where I’m getting confused:

Why would you need to make a new refund ticket type for each warehouse just because the ticket type has a ‘warehouse’ property (used when adding orders to that type of ticket)? Or would it have to be used for something else as well were it could cause problems?
 
 
This is how I see it, but I might be missing something obvious that you guys are seeing clearly:

  • select a warehouse in the ticket type (or leave it empty, then it still uses current department’s warehouse just like before)
  • when orders added to a ticket: the order’s ‘warehouse’ gets copied from the ticket type (or the department’s if the ticket type’s warehouse is empty)
  • you can still update the order’s warehouse from a rule if you want for some reason (with Update Order).
  • when you create a refund ticket, you use the same warehouse that was already in the order (if the inventory was deducted from that warehouse, then you should add it to the same warehouse again)

I can see how this might work… but that would allow us to make a very complex system with tickets which personally I can see advantages for…BUT I can see how potentially it could really screw it all up.

For some of us this would not be an issue but for an average user or a new user to SambaPOS this could royally mess the entire integrity of the system up if someone was to assign warehouse type to a ticket type not knowing how it might interact with their inventory if they use that ticket for other departments, refunds, etc.

I can’t see how most people would use this option though. A few of us might, I know I could, but average users would not need it and it adds a very big complexity to the system. So I can see why leaving Warehouse to just departments is a good approach.

1 Like

I see your point. That could be an issue.

On the other hand, it wouldn’t be the only setting in SambaPOS that could screw things up when not used correctly (like unit multipliers for example :slight_smile: ).

True but unit multipliers is a necessary evil. This we could say really is not. Don’t get me wrong me personally I would love having Warehouse assigned to ticket type. I can think of a ton of things I could do with it. Maybe we need a SambaPOSv4(ADVANCED INSTALL) hahah or SambaPOSv4 (PROFESSIONAL) With disclaimer that you need a good knowledge of it before installing haha.

1 Like

Yes, or a setting ‘show advanced options’ or something… That would be something that would probably be good for a lot of new users.

The more advanced and configurable SambaPOS becomes, the more confusing it will become for starters, so that would probably be a very good setting to have…

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: