@QMcKay I’m aware of this but sorry for not being able to implement it immediately. Like I’ve said before this is something related with infrastructural design of inventory system. So before diving into that let me finish some immediate tasks.
Poet and didn’t know it. 
Thanks @emre, just didn’t want it to get lost in the shuffle. I agree, the Inventory System needs some work, and I don’t expect it to come too soon, that’s why I built the PHP system (which I will continue to improve unless it becomes moot).
1 Like
Just to give you something to think about when you get to implementing… Let me give you an example of Croissants:
Unit 1: Piece Quantity: 8 Cost: 1 (calculated automatically)
Unit 2: Tray Quantity: 6 Cost: 8 (calculated automatically)
Unit 3: Case Quantity: 1 Cost: 48 (value entered manually)
This means there are 8 Pieces in a Tray, and 6 Trays in a Case.
I only need to enter the Cost of the Case (48) and the other costs are calculated automatically when I leave them blank. Costs are based on the Quantity of the Unit (Transaction Multiplier):
Tray Cost = Case Cost / Tray Quantity = 48 / 6 = 8
Piece Cost = Case Cost / Tray Quantity / Piece Quantity = 48 / 6 / 8 = 1
I like the way the above works. Obviously you should be able to override the Cost per Unit, but the Automatic Calculation is nice and saves work when entering Inventory Items.
So I think I have to tell in advance what is in my mind.
- We’ll have a base unit.
- We’ll have many transaction units (you can think it as packaging)
- We’ll define how many items per transaction unit contains individually. It wont be cumulative like Piece > Tray > Case. Piece will be base unit. Tray & Case will be transaction units. You’ll define Tray has 8 Pieces and Case has 48 pieces.
- We’ll always calculate cost for base unit because you’ll configure recipes by base unit. If you purchase 10 case we’ll divide price with 480 and take it as base unit cost. If you make multiple purchases from different units it will be the average cost as packaging generally changes base cost.
- I’ll probably bring last transaction price to transaction if you leave cost values empty. I won’t calculate it from other cost values.
1 Like
@emre, thanks for letting me know your approach.
I realize that method is how it is currently done. Since you are going to re-visit the infrastructure, I like my method better, because it takes the manual math out of it.
Working in a cumulative fashion as I am suggesting doesn’t require any math on the part of the user… the system does it for you, forward and backward…
Base Unit Cost is still determined by Case Cost - that doesn’t change. I simply don’t want to have to figure out (8 x 6 = 48) in a Case; I want the system to do it for me by taking the Quantity of Pieces (8) and multiplying it by the Quantity of Trays (6).
Consider this, for a Case of Wine.
1 Case
12 Bottles
24 Ounces per Bottle (6 ounces poured to a glass x4)
I don’t want to need to figure out there are 288 Ounces in a Case. That’s why I want a Quantity for Base Unit.
Unit 1 (base): Ounce, Quantity: 24
Unit 2 : Bottle, Quantity: 12
Unit 3 : Case, Quantity: (default 1, x number of cases ordered)
Unit 3 should have the Cost as well, per 1 case
Now the system decides that there are 12x24=288 ounces in a Case - honestly, I don’t care how many ounces are in the case - this is what I’m getting at, or call me lazy.
I also don’t want to calculate the Base Unit Cost… Let the system do it for me, i.e. if a Case cost $100, then all the rest is done for me automatically (consider too that I sell by the Bottle, so I need to know the cost of a Bottle, not just a 6 oz glass)… I want to avoid having to make these calculations when I’m entering Inventory.
100/12 = 8.33 per bottle
100/12/24 = 0.347 per ounce
Recipe uses 6 ounces per glass = 6 * 0.347 = 2.08 (cost per glass)
This should also allow me to create a recipe for Bottle of Wine.
No matter the implementation, I look forward to it, and I’ll make it work for me, since I really need a 3rd Unit right now.
@QMcKay wine is a great example. Some wineries offers slightly bigger version of retail bottles for restaurants and they can purchase both.
I know this is not the case but found it while searching for an example 
Still waiting for more Units, and Quantities… 
On another Topic, @emre, is there any Indexes I can add to the DB to improve the performance of Work Period Close? Because since I started tracking Inventory, Close Work Period takes 30+ seconds to complete…
Can you do something for me? Please create a backup before ending the work period and send me the zip of the backup file.
you can have two backups…
I thought that my pc was getting slower and slower… closing a samll work periods takes 15 to 30 secs… closing a saturday may take up to one minute…
Its not a problem, but if we can improve that it would be great!!!
G.
@gerlandog did you noticed an improvement for work period end?
@QMcKay. I’ve added Hidden setting to Warehouse Type's. So these warehouses won’t appear on Warehouse module but you’ll be able to see them on End of Day records.
1 Like
I definitely noticed a massive improvement - it’s nearly instantaneous now - I mentioned this in another Topic. @gerlandog, how about you?
Thanks for that - looks good!
I have not ahd a busy saturday so I cannot tell for sure… I am intalling 4.1.70 now…
Let you know as soon as I try it!!!
Thanks!!!
G.
Multiple Units added in v4.1.73 … thanks @emre!
It isn’t exactly what I was looking for, since I need to calculate Ounces per Case, and I have no way to define Bottles per Case (other than 288/24=12), but it will suffice, so I’m not complaining…
This is one of the last things I would like to see when it comes to Inventory Transactions that would make entering Purchases much simpler: a Default Tax Template on a per-item basis.
I have some suppliers that list their items on invoices with Tax included, but most list Items with Tax excluded, and all suppliers use the same Tax Rates depending on the type of Product. In my case, T1=15% and T2=18%.
Similar to the Default Transaction Cost, it would be very nice to have a Default Tax Type that could be defined in a way that is similar to Sales. So when I go to Purchase Stock, my line items already contain the Tax Type for that item.
Do you need only tax template selection for items without tax implementation for transactions? I couldn’t understand 
Sorry, I don’t understand your question @emre. Basically I want Tax Mappings for Inventory Items.
Currently in my code I am gathering Sales Tax Templates and populating a pick list with the Names (and Rates) for those Templates. Then I have some hard-coded filters for specific Inventory Item Types, for example Alcohol and Cigarettes get T2 (18%) by default, and most everything else gets T1 (15%) by default. There are some items with NoTax as well.
This lets me enter the cost of the item as it appears on an Invoice, and the Tax is added automatically at the proper Rate, giving an Invoice Total that matches what the Supplier gives me. In practice, I don’t need to enter the cost at all, because the Item has a default Cost. If I could get a default Tax as well, I wouldn’t need to guess which Tax the item needs.
This could be done like the Tax Template mappings on the POS/Sales side (makes sense to me), or it could be another field/column in the [InventoryItems] Table similar to Default Base Cost and Default Transaction Cost. Mappings seem to make more sense to me, because you could theoretically assign more than 1 Tax to an Item.
Keep in mind too, Suppliers sell Items of all Tax Rates, so we can’t rely on Supplier Account mappings; instead we need Item Mappings, just like we have for Products.
I mean when we add tax templates for inventory items we should also add tax calculations for purchase transactions and maintain related accounts. What you’re requesting sounds like you don’t need a tax calculation in transactions and only need to know default tax rate. That’s why I’m asked because when you say “it appears on an invoice” I assume you’re talking about your inventory tracking system, not sambapos…
Calculating tax in transactions is something we’ll implement however before doing that we should improve accounting integration for inventory transactions. I’ve implemented 2 more invoicing apps before SambaPOS and this is something needs a lot of development as some suppliers can send tax included invoices, some can send tax excluded and even some suppliers sends invoices where tax amounts incorrectly calculated so what your computer calculates does not match to the printed invoice.
This is my plan for tax.
- Integrating accounting to inventory transactions so we can automatically update supplier accounts. (and tax accounts)
- Adding a Tax amount under transaction documents (not orders) so you’ll be able to manually type total tax amount as it printed on invoice. We’ll update purchase taxes account with that amount.
- Adding a setting to let user select if tax is included to prices or not so we’ll know if we’ll update purchasing accounts (and also calculate cost) by decreasing tax amount or not.
- Adding a setting on order lines to define tax rate so we’ll be able to calculate total tax automatically but we’ll still allow user to modify total tax manually.
- Calculating tax amounts separately for each tax rate and update individual tax accounts.
- Finally assigning tax templates to inventory items to define default tax rates.
What I’ve asked is if you’re requesting all of them or just the last item
Yes, I’m requesting just the last one: assigning Tax Templates to Inventory Items to define Default Tax Rates for the Item.
This is the the correct assumption. I am talking about my system, however I want to use as much of the native/default system built-in to SambaPOS as possible. I agree with you on what should be done and needs to be done eventually regarding Tax Calculations, etc… I just don’t need that level of integration yet.
I just want the part outlined in Red, but for Inventory Items instead of Menu Items…
Sounds like big plans and a lot of work @emre! I’m all for it… the Accounting (Money not Stock) for Inventory is one of the last remaining missing pieces.
I’m going to guess that your future plans for Inventory involve the screen on the left, which I am currently not using; instead I use the screen on the right… at least in the case of Account Transactions (I do use the Inventory Transaction Type). The reason for this is simple: my Purchases/Payouts are already well-defined in the Accounting side, so I saw no need to duplicate it - plus, there is no Button Header field on the Inventory side - and I need that button!
@emre, any chance you could improve this: Parent Unit is NULL in the DB, but should be Ounce as shown.
In my PHP code, I explicitly set this value, but if the item is created within SambaPOS, the value in the DB is NULL.
EDIT: not a big deal… I added some PHP code to select the ParentUnit as either the TransactionUnit or BaseUnit. Though I still think the ParentUnit value should not be NULL if configured via SambaPOS. Also, I assume that if there are more than 1 AdditionalUnits that use another AdditionalUnit as the ParentUnit, this value will not be NULL in the DB.