Inventory - Correct method to setup

Hey Everyone,

I am trying to familiarise myself with all of the features of SambaPOS so that i have a better understanding of the entire system, but i am struggling a little with the inventory.

The basics seem pretty straight forward with Inventory Items & Recipes mapping inventory items to products on the menu, transactions record updates and additions to inventory item levels and the end of day records display the information but there are a few parts i don’t quite understand.

  • Warehouse types? Why bother having warehouse types? I have assumed that warehouses refer to places where things will be stored. As in if i have a setup with a bar and a kitchen i might setup 2 warehouses 1 x Bar & 1 x Kitchen but why would i bother creating different warehouse types?
  • Transaction Types lists a whole bunch of options regarding source and target, but i was under the impression transaction referred to purchases. If i am listing the source warehouse (and warehouses refer to my own storage areas) why would a transaction involve a source warehouse and a target warehouse? And why bother having a source & a default.
  • Document types. What are these used for?

I have had a look for some comprehensive documentation on Inventory but the majority of documents explain the transactions and inventory items with little information on transaction types, document types and warehouse types.

Anyone have any more information?

Warehouse Types:

Used for organization and filtering. For example, none of my Supplier Warehouses are displayed in the Warehouse Screen (they are hidden), because I don’t care about their Stock counts. Only my Local Warehouses appear in this screen.

Local Warehouses: Shop, Bodega
Supplier Warehouses: a Warehouse for every supplier I have

Document Types:

Documents contain Transactions. You buy product A, B, and C from your supplier. For each product bought, there is a Purchase Transaction. The Purchase Document contains 3 Transactions (1 for each Product). If I want to move a case of Bagels, 3 Trays of Croissants, and a Bottle of Rum from my onsite Shop (Local) Warehouse to my offsite Bodega (Local) Warehouse, I use a Transfer Doc which contains 3 Transfer Transactions (1 for each Product).

Purchase Doc (Supplier to Shop)
Stock Transfer Doc (Shop to Bodega)
Stock Transfer Doc (Bodega to Shop)

Transaction Types

These describe the type of stock movement for a single product. Likely the same or similar to above.

Purchase Tx (Supplier to Shop)
Stock Transfer Tx (Shop to Bodega)
Stock Transfer Tx (Bodega to Shop)


Thanks QMcKay,

If you dont mind i’d like to reiterate what you’ve mentioned just to confirm i’ve got the right idea. Having a bit of trouble with the document types section.

As far as warehouses in SambaPOS are concerned we could define them as “Areas where items are sourced from or moved to”. Generally speaking, this would include internal and external warehouses. What other warehouse types could there be?

Warehouses section would then go on to define each warehouse, this would include all suppliers as well as local warehouses? Possibly additional venue’s warehouses. These ultimately define sourcepoints and endpoint for inventory items?

As we move on to Transaction types. This would define stock movement between warehouses, whether they are suppliers or internal movements?

Document types - I dont fully understand this part. If i bought product A,B & C from my supplier, i would head in to the transactions section add a “Transaction Document”, enter a document number (i have assumed this is an external number, possible a receipt number or invoice number etc) and then in the “Transaction” column i would select from my Transaction Types. This then loads the default entries regarding source and target (related to selected transaction type) - where does the document type come into play? Also, in defining document types, samba pos refers to source entity and target entity, this is adding to my confusion.

Thanks for your previous response, really appreciate the detailed explanation!

You can use Entities as a way to define Suppliers, or other shops, venues etc.


My setup has only 2 Warehouse Types

  • Local Warehouses
  • Supplier Warehouses

For finer control over Suppliers, I could have created Warehouse Types for Grocery Suppliers, Alcohol Suppliers, Paper Product Suppliers, Cleaning Product Suppliers, etc. But it isn’t really necessary; it is a matter of choice.


My setup has 2 Local Warehouses & 39 Supplier Warehouses:

Local Warehouses:

  • SHOP : all my product shipments land here
  • BODEGA : I transfer excess stock to here for longer-term storage, and when I need something, I transfer items back to the SHOP Warehouse

Supplier Warehouses:

  • 39 different suppliers; each has its own Warehouse defined


My setup has 3 Transaction Types:

  • Purchase Tx : when product arrives from a supplier, this Transaction Type moves stock from a Supplier Warehouse to my SHOP Warehouse
  • Transfer Tx (SHOP > BODEGA) : this Transaction Type is used to transfer excess stock from SHOP Warehouse to BODEGA Warehouse
  • Transfer Tx (BODEGA > SHOP) : this Transaction Type is used to transfer depleted items in my Shop from BODEGA Warehouse to SHOP Warehouse

For now, you can think of the Document Type as a container, or a folder with pieces of paper inside it. The pieces of paper are Transactions.

Bread Supplier delivers some items with Invoice #2222. You create a Purchase Doc named “2222” and add the following Transactions:

Purchase Tx for 1 Case of Everything Bagels
Purchase Tx for 1 Case of Plain Bagels
Purchase Tx for 1 Case of Croissants
Purchase Tx for 1 Case of Ciabattas

In the future, the Document Type can be used to define buttons in the same way as can currently be done in the Accounts section. It is also tied to the Account Transactions mechanisms, so that you can make Payouts to Supplier Entity Accounts effectively.

This is where the Entity comes in. Since Entities can have an Account, and they can also have a Warehouse, you would set up your suppliers as Entities, each with their own Account and Warehouse (my setup works this way). The Document Type controls which Account Transaction Type is used, decides which Entity to use, thus deciding which Warehouse and which Accounts will be affected by an Inventory Purchase.

When transferring stock “internally”, it makes less sense. That is, unless you perceive transfers as a type of purchase. Then you can track Costs of stock items sitting in your Local Warehouses.

Let’s go back to that first sentence:

In the future, the Document Type can be used to define buttons in the same way as can currently be done in the Accounts section.

Here is a look at the future - this is the Warehouses Screen, and the buttons you see on the right are Inventory Transaction Document Types…

The “Drawer Cash”, “Wallet”, and “Bank” buttons can be used to create a Document Type for the selected Warehouse, which I would then add Transactions for items to. Then, when the Document is saved, an Account Transaction takes place, which moves actual funds from one Account to another.

Now, if I click that “Drawer Cash” button, I am creating a Document, where I can select my Supplier Warehouse, and add Inventory Transactions to it. When I save this Document, Inventory Items move from Supplier Warehouse to SHOP Warehouse, and an Account Transaction is fired, moving money from my Cash (Drawer) Account to the Supplier Account.


Legend! Explanations dont get much better than that. Thanks mate.

wow, the future looks good. This is one feature that I intend to implement my own in version 3 of this superb software. It’s a shame that version 4 is not open source and I can not work with it.
I just wrote to you asking some questions and I am very pleased to find such a complete answer yours. Thanks for your time.

The limits of the Inventory System in v4 (and earlier) are what drove me to design a PHP solution, which uses those Document Types. When v5 is released, it may make my PHP solution somewhat obsolete. That said, there are still elements to my PHP solution that I prefer over SambaPOS will offer in the near-term.

Here is the Purchase Screen, which uses the Document Types defined in SambaPOS:

You can read about the implementation here:

which is why I chose the version 3, to try to develop on it things like your solution.
I had not seen your module in php, it’s great, I’ll try to do it on version 3, from the warehouse view.

Have you done anything to improve reporting ?? Have you used crystal report or something to get reports of bd?
What is the “licensing module” that you’re talking about?
thanks again.

No, I do almost all of my reporting using SQL, with the result sets exported to Excel, where the analysis takes place. Though the Custom Report Module (v4) is very good at giving you insight into your operation.

In v5, @emre is developing support for graphs, and a lot more flexibility in the Automation regarding scripting, like JScript and SQL. It allows for an even more powerful level of control over the application like we’ve never seen before… I thought v4 was powerful enough already, but v5 is shaping up to blow the doors off of v4 from a power-user perspective.

Version 4 is closed source because a lot of the components that add functionality are not allowed to be in an open-source package. @emre can give you a better explanation.

Thank you very much for your time, I would take the opportunity to exchange more ideas with you. Are you developer and business owner like me?

I have written to emre but he did not answer me, I guess the time he is somewhat limited.

thanks again.

I wouldn’t call myself a Developer, but I understand a good deal about different programming languages. I am a Business Owner primarily.

Yes, his time is limited and taken up by developing v5, which is what we all want. The community in the Forum is here to help otherwise. I don’t expect much support for making changes to v3 from the people here, or @emre himself. His time is better spent on v5, and that is the priority.

1 Like

I’m really sorry… I rarely answer PM’s (e-mails, facebook messages, twitter DM’s) as we already have a forum for questions. Private Message is better for things that we should keep private like issues with your accounts, licenses (or maybe trade secrets you need to share) :slight_smile: … OK. seriously I can’t pay more than few seconds for messages and I want to spare more time to create useful answers and develop tools that helps more than one people. I hate doing that but I have to.

1 Like