SambaPOS 4.1.73 Released

General
6

Hi @Emre… let me try to explain this with expamples:

I do have some different items in my inventory, like

CHEESE
Base Unit: Grams
Trans Unit: KILO
Multiplier: 1000

BEER
Base Unit: Bottle
Trans Unit: BOX
Multiplier: 24

SHRIMPS
Base Unit: Grams
Trans Unit: KILO
Multiplier: 1000

PIZZA PIES
Base Unit: Unit
Trans Unit: Unit
Multiplier: 1

ALL KIND OF SODAS
Base Unit: Bottle
Trans Unit: Pack
Multiplier: 12

So, finally after a few long posts with @Jesse and @QMcKay I found that this seems to be the wright path to follow since, BASE UNIT is the unit in wich you sell, and TRANSACTION UNIT is the unit in wich you usually buy.

Using this configuration works fine for most of the functions in SAMBA, lets review this:

  1. Item Sales Report: Shows BASE UNITS (Seling units) PERFECT!!!
  2. Inventory Report: Shows TRANS UNITS (buying units) Not That Perfect, could show BASE UNIT and TRANS UNIT, just doing a multiplication.
  3. Cost Report: Shows BASE UNIT, PERFECT!!!
  4. Inventory Pucrchase Report: Shows Products bought in ORIGINAL buying unit, either BASE or TRANS, PERFECT!!!
  5. WareHouses: Shows you TRANS UNIT, PERFECT!!!
  6. Transactions screen: Gives you the option to buy either one bottle or a box, 500 grams of cheese or the whole kilo. (when you buy a cheese, at least here, the cheese weight is 4,56 kilos or 4,78 kilos. Its never 4 or 5 or 3. With Shrimps or meat its different. You buy a whole KILO)
  7. Receipes: Lets you add your ingredients in BASE Unit, PERFECT!!!
  8. End of Day Records (and here is my problem, you can see all your inventory items in TRANS UNIT, that means that if I have ONE (1) bottle of beer missing, I have to do the conversion to see if the % of a box is correct. Usually in the End of Day Record screen you will modify existence according to losts or brakes or missconsumption. So, you will add in my case BASE UNITS quantityes for everything that comes in PACKS and BASE UNITS for everything that we meassure. you dont adjust 1 PACK of beer, except that someone loses a whole case (strange), and if that is the case, choosing unit would be helpfull.

In a normal day, I would go to that screen and correct ONE bottle of beer (becuase it broke, or it did not have gas, or just dissapeared). Having to calculate how much % of a box I do have is complicated at that point. Lets imagine I have 17 bottles in my fridge, out of 24 bottles of a box. that means that i have 0,708333% of a box. when I go to End of Day Records and see that It says 0,75 I have to do the conversion to units, count the units in my fridge, convert it again to box and then compare to see that its wrong…

So bottom line, I we could se the end of day record in base units, and choose unit as in transaction screen, it would be more than great!!!

Hope this was not too long, and sorry to bother you so much!!!

Thanks!!!

G.

1 Like
7

I understand why you want to keep your multiplier set to your Transaction Unit as its symbolic and you like it to appear that way…but like I said this can all be avoided by setting a multiplier of 1 and purchasing accordingly. You could then adjust your end of day reports by bottle and not have to calculate anything…

The reason I keep saying this is because its available now and @emre does not have to redo the system for it to work.

8

Imho seeing end of day records for beer by in packs is the reason of the issue. As you count inventory in bottles you should also see / update inventory in bottles. To do this you have to remove transaction unit for beer and the base unit for beer becomes bottle.

However when you do this you won’t be able to purchase beer in packs. That’s why I’ve implemented additional units feature. Pack will be an additional unit and you’ll be able to use it in purchase transactions without changing reports. I still have few to do’s for defining base units for transactions.

For meat it will have both grams for base unit and kilograms for transaction unit as you’ll both buy and tally meat in kilograms but use grams in recipes.

I can still think some cases that will need unit selection but I think I can solve these by allowing unit selection in recipes.

Sorry for not just implementing that simple feature but I strongly believe people will forget changing unit and they won’t be able to fix it as editing past eod record is not possible. I think there should be no need for changing units while editing eod records.

2 Likes
9

Wy would you keep multipier in 1? If so, why would you have many units, just 1 will solve all trouble.
I dont get having multiple units with different name and multiplier in 1… that makes no sense to me.

Well, thats great! Doing this is exactly the same thing that I was requesting, The plus here is that your concern about people forgetting to change will be gone.

Exactly the same occurs with transactions (purchases), you should be carefull, thats all… you should be carefull in any transaction…

I strongly beleive that choosing units ie EOD Records would be benefitial… but thats only me… for now!!! LOL!!

Thanks!!!

G.

1 Like
10

Gerlandog this is effectively the same thing as setting it to 1. Except now we have another unit to fix the purchasing issue Thank you @emre.

I don’t understand what you mean by

I never said you should have multiple units with different name… what do you mean by this?

11

@emre this works great! Thank you for this. One step further to a better inventory system!


48c5b47cacf7fa4a.png858×366 12.3 KB


1229335e41791caf.png993×408 20.2 KB

12

I have noticed one small thing… if you leave Transaction Unit empty in the purchase transaction Unit Drop Down there is a blank unit I understand why its showing up but is there away you can filter this out?

38b2a1f44135c917.png892×468 13.5 KB

13

You don’t need to enter a multiplier as 0 or empty multiplier already becomes 1 but when you enter it as 1 (>0) it thinks there is a transaction unit.

Edit: Your base unit is Ea but it displays as box in reports. Was transaction unit of it box?

1 Like
14

Yeah its small annoyance nothing major I just thought maybe you could filter that out somehow. Regardless it works great.

1 Like
15

Yes I’ll filter that :slight_smile: Just wanted to let you know the reason of it …

16

I kind of put two together and figured that out. It makes perfect sense too. Its funny but I really did not have to change anything with how I have been tracking my stuff you just enhanced it with this feature :stuck_out_tongue: I really was happy with it but now its just a little easier as I can just use my regular transaction unit in purchases.

Maybe @gerlandog will finally understand what I have been trying to tell him all this time :stuck_out_tongue:

17

I fixed that… it was me experimenting with behavior… I had Box defined as transaction unit…+Extra transaction unit as Box.

I changed the screenshot to not confuse anyone.

PS: I learned how those reports fill that column doing this though. So if you fill in Transaction Unit it uses that if you leave it blank it uses base unit.

1 Like
18

Yes we’ll still need transaction unit for items we purchase & track in kilograms but use grams in recipes. For example meat inventory will decrase in grams (base unit) but it will display reports in kilograms (transaction unit)

1 Like
19

Yes in fact I use it this way. I only track specific items by Ea and the rest I want tracked by Box or Case etc. Like meat, French Fries, Tomatoes etc. The screenshot you see is just my test DB maybe when I’m at the business ill take a screenshot of my actual inventory.

1 Like
20

That is EXACTLY my point… having BASE unit and TRANS unit both in units, grams, kilos or whatever and multiplier in 1 seems to me a waste of space, and makes no sense.

Having aditional units its great, but why would you have two units and only use one? If you set your multiplier to 1 seems that the units, regardles the name, are the same…

Yes dear @Jesse, every time we write about this you are suggesting me to put my multiplier in 1, and again, that makes no sense. Why would I set two units and multiplier to 1?

Now that we have mutiple units, that means that TRANSACTION UNIT and BASE UNIT will become the same and most of us will have them both set to something with multiplier to 1.

As to me, BASE unit is the unit in wich you sell, and the unit in wich you track your countable and uncountable inventory items. TRANS unit is the unit in wich you buy, and in wich you track your (only) uncountable inventory items.

I will try this (for 5th time LOL!!!):

  1. I will put all my stock in CERO
  2. I will define BASE and TRANS unit the same with multiplier in 1
  3. I will define and EXTRA unit as my old TRANS unit
  4. I will redefine all my stock reports

After doing all that I will try to see @emre and @Jesse points and try to understand why should we using both BASE and TRANS unit with multiplier 1 (meaning this that with a multiplier set to 1 they are the same unit, but different name).

Thanks!!!

G

21

@gerlandog, before you go all crazy redefining your Inventory Units, let me say this: I agree with you, and your perception of how (base and transaction) units should work.

While there are certain scenarios where you could (and probably should) set your Transaction Multiplier to 1 (which is effectively ignoring it), these scenarios are both subjective, and in the case of my business very rare. Other types of businesses may see things differently, due to the nature of their products, and to each their own.

I for one am still pondering how I should set things up now, with our new Additional Units (thanks again @emre!). If I am clear in my understanding of how they operate, I may do the same thing that is being suggested by @Jesse and @emre, and abolish the Transaction Unit in some cases in favor of Additional Units, since they appear to behave differently.

@emre, how do Additional Units have any bearing on how things operate (i.e. Consumption, Purchase Transactions)?

1 Like
22

dont worry I made a backup, just in case, LOL!!!

I really would like to understand @Emre and @Jesse, but I am having a hard time doing so…

Thanks!!!

G.

23

Look at my screenshots maybe it will make more sense. I am not using two units… I am using Base unit and Box unit… base and transaction…I just have it setup so that the Transaction aka Box unit is an extra unit so it reports correctly. I am not using Transaction Unit…Extra Unit in my implementation took the place of Transaction Unit.

The reason it needs to be this way is because I also want some of my items tracked by % of case or % of transaction unit which case I would define Transaction unit and multiplier accordingly. I would not use extra unit. By design it is allowing this.

This allows me to purchase using the Transaction Unit I defined in extra units… but it tracks it by the single unit which is exactly what you wanted @gerlandog

24

Dear @Kendash, I think we will never understand each other. I am sorry. but for me having two units is more than enough, having extra units is a great bonus. For me having two units and in some products not using them, but using the extra unit is a waste of space. I do track items by the unit and the same time by the box (beers). I do count how many BOTTLES (by the unit) I have in my fridge, and then I go to the storage room and count how many boxes… I CANNOT PUT BOXES in my Fridge, and I sure cannot be sure to have allways a whole complete box in the fridge…

I found a small bug…

If in a transaction you mix two units of the same product… the stock goes crazy
for example

1 Pack of Coca cola (extra unit, multiplier 6)
and
2 Coca Cola (base unit multiplier 1)

Stock gives yu 16 Coca colas…

G.

PD, restoring my backup, and keeping it as it was
Base unit = sell unit
TRANS unit = Transaction units

and will still have to do math conversions to use EOD Records…

Thanks!!!

G.

25

NONONO I would use Trans unit if I wanted it to track by % of case… which I do for some of my items.