SambaPOS 4.1.73 Released

Oww looks sweetly dangerous. It was Halloween there right? Happy holidays…

nice!!!
really beautifull!!!
G

… and guys I’m glad I’ve didn’t disappointed someone. I know that was not you’ve talked about but I’ve tried to find the best solution both for your issues and other issues we’ve encountered in the past. Of course this is not the final implementation. I’ll improve things for better handling more cases. Just keep discussions here. While reading every request I try to understand the reason of the request and if the reason is a bad design I try to solve that. This is the reason of these surprises. It will probably result with a change on your implementation but changing implementation to avoid future or bigger issues is a good thing… I hope that won’t happen again. I should have wait completing these before releasing custom reports :slight_smile:

Yeap my youngest first Halloween.

1 Like

@emre no worries I actually enjoy messing with it and learning from it. Honestly I think being able to help improve custom reports like this is more satisfying.

1 Like

@Jesse I’m learning too :slight_smile: This is amazing…

1 Like

I have an issue with products that I buy in kilos and sell in grams. For example CHEESE. My base unit is grams. Trans unit empty, multiplier 0. Unoque extra unit is kilos, multiplier is 1000. I have my base unit ij hrams because a pizza has 350, but a sandwich has 50. The cost of a kilo is 14,10 that means that Samba calculates the cost of a gram in 0,0142. When we do reporting with this info, cheese cost is shown as 0.02 resulting in an error. I need to use grams because sandwiches, calzones, and “pasteis” do vary cheese quantity.

The same happens with wiskey, rum, tequila. I buy them by bottle or litre but i sell them in 50ml units.

How can i handle this situation?

Thanks!!!

G

So how in the world can you keep up with inventory of cheese? Do you weight it every day and then correct the grams every night? I would think it would make more sense to track this by the kilo instead of tracking it by the gram. But use gram in recipe.

For cheese base unit will be grams and transaction unit will be kilograms. Don’t leave transaction unit empty for cheese as you don’t purchase / track cheese inventory in grams.

It can be something like that.

With that setup you’ll purchase cheese as package or box but see inventory in kilograms not package or box. You’ll also configure recipes in grams.

… alternatively if you want to track cheese inventory in Package your setup becomes…

3 Likes

@emre, how close is this to final implementation in regard to how values are store in the DB? I’ve started to make changes in PHP to accommodate this great feature, but want to know if it is going to change in any significant manner…

Thanks @Emre… was missing the TRANS UNIT part… so in this case TRANS Unit is important!!!

Thanks again

G.

one silly question… how would be the best approach to change or add the trans unit and not getting all my cheese stock messed up?

Thanks!

Interesting… something to look into maybe @emre.

Yesterday I had Parent Unit being stored as NULL for Croissant Unit Tray, but today, after DB restore (from v4.1.73) and fresh install/upgrade to v4.1.75, then re-configure Croissant, the Parent Unit is being stored (properly) as Piece. Also, the Parent Multiplier was 0 yesterday and today it is 1.

Yesterday:

Today:

use [SambaPOS4]

SELECT
 iu.[Id]
,ii.[GroupCode] as [Gcode]
,ii.[Name]
,ii.[BaseUnit] as [Bunit]
,ii.[TransactionUnit] as [Tunit]
,ii.[TransactionUnitMultiplier] as [Tmult]
,[IsDefaultTransactionUnit] as [dTxU]
,iu.[Name] as [Aunit]
--,[InventoryItemId]
,[Multiplier] as [Amult]
,[ParentUnitName] as [Punit]
,[ParentUnitMultiplier] as [Pmult]
,[DefaultCost] as [Acost]
FROM [InventoryItemUnits] iu
left join [InventoryItems] ii on ii.[Id]=iu.[InventoryItemId]
where 1=1
and ii.[GroupCode]='Bread'
order by ii.[GroupCode],ii.[Name],iu.[Multiplier] desc

@gerlandog you could create a new cheese inventory item add it to the recipes remove the old cheese from recipes and correct the stock on end of day reports.You would need to take the old cheese out of recipe and use new one then change old cheese to 0 on end of day. At some point you could delete the old Cheese item. Perhaps after you set it to 0? I am not sure if that would affect old reports or not.

One day I will succeed in getting you to understand me on inventory lol. This might blow your mind but @emre did not change how it works we’re still dealing with same multiplier and same transaction unit he just added more clarity to reporting and purchase transactions. What you did when you chose not to set trans unit for bottles and what your doing now to use it for cheese is what I’ve been trying to get you to do the entire time. Difference being it now puts better naming for reporting and transactions. And lets you define how to make purchases.

Hopefully my suggestion above helps you.

dear @kendash I allwyas understood you… I just changed recently the way I do some things to acomodate them to samba operations and with extra units that fact became easier…

and now, I meassure cheese in 50 grams, becuase thats the minimum I sell, and here cheese is hiber-very-recontra expensive. Its one of the most expensive items in my grocery list. Its R$18 the kilo… and I charge R$18 for a large musarella cheese pizza (that has 350 grs f cheese)… so I have to be very carefull with cheese.

adding one more inventory items, changing all receipes is NO for the moment. to much work. have to find a better solution, an inmediate solution, so I do not change one more time my inventory. I am tired… and want a caipirinha… and my pipe…

Thanks!!!

g.

I am not sure that there would be an easy solution to convert that. All the calculations etc were already done without a multiplier… if you add one now it will mess it all up. Maybe @emre can help you here.

Ok good. I love the fact that he added the Extra Units feature and I love the fact that it does not actually add extra units it is still calculated the same way this allows it to work with older setups and no changes required yet it enhances it for those of us that want to use it.

I’ve re-uploaded 4.1.75 to public with some required verifications on unit changes. If you’ve downloaded 4.1.75 under this topic please redownload from http://sambapos.com/download-sambapos/

2 Likes

Over the last 2 days I started re-writing the unit and quantity calculation code in my PHP to support “unlimited” units. I must say, @emre, I think the implementation is fantastic, and I see no need to change it.

On the user-side, we see units and quantities that make sense, without having to make calculations on how many ounces are in a case of wine. This was thanks to the Parent Multiplier and Parent Unit. If you recall our discussion regarding quantities of units as it pertains to Wine, this implementation allows for things to make sense to the user. At the same time, it has convinced me that I don’t need a Quantity for a unit which I originally asked for - it simply isn’t necessary now.

On the inside (DB), things are stored a bit differently than they are displayed, and this is a good thing - it has made the PHP code much easier to define. What @emre has done is to store the Multiplier for each Unit as a multiple of the Base Unit. It makes sense to store it this way, because the Base Unit is always present, and it is the most important unit.

USE [SambaPOS4]

SELECT 
-- [Id]
 [GroupCode]
,ii.[Name]
,[BaseUnit] as [Unit]
,[TransactionUnit] as [TxUnit]
,[TransactionUnitMultiplier] as [Mult]
,null as [PUnitMult]
FROM [InventoryItems] ii
where ii.[Name]='Montes Chardonnay'

union

SELECT 
-- [Id]
 [GroupCode]
,ii.[Name]
,iu.[Name] as [Unit]
,coalesce(iu.[ParentUnitName],[BaseUnit]) as [TxUnit]
,iu.[Multiplier] as [Mult]
,iu.[ParentUnitMultiplier] as [PUnitMult]
FROM [InventoryItemUnits] iu
left join [InventoryItems] ii on iu.[InventoryItemId]=ii.[Id]
where ii.[Name]='Montes Chardonnay'

order by [Mult]

So I’m getting close to having the PHP finished, and have decided on the layout for Stock to support Additional Units:

1 Like

OK. I liked that layout idea!! Great :slight_smile:

PS: One of the reasons of that unit configuration was the need of configuring multiple units from same single parent unit. For example some wine suppliers offers both 24 and 30 ounce bottles.