How does SAMBAPOS calculate Cost of Items

@gerlandog I wasn’t referring to what you said. I just ran a test myself… and I was talking about the warehouse screen via main menu. When I sourced it out of my warehouse it recorded it as a consumption even tho I didn’t have sales on it. Cost reported correctly… but for visual reference I wouldn’t want it showing as consumption…

1 Like

@Jesse I might be wrong since I’ve didn’t touched inventory for years but as I can remember we store values under Added, Removed columns but display it as consumption. Again we have a kind of abstraction here.

Its really not that big of a deal. I wasnt even planning on working this portion of my samba yet… i just stumbled across it when talking to @gerlandog

But something I was planning to do in the future before I deploy was working in a Supplier Buyback or Credit or Claims process whichever people prefer to call it. Just looking at it quickly with @gerlandog it seemed to work if I made a 2nd Transaction Type to use for buybacks and had it source it out of my warehouse.

EDIT: Tecnically consumption would mean the same thing I understand that. I just would like to have two columns for visual tracking… Consumption = Sales reductions Supplier Returns=Transaction reductions.

EDIT: However just like the Accounts screen… if I can get it working correctly I would rather just look at reports anyway.

It is a good idea to differentiate them by transaction types so we can improve our reports to display transaction summaries by transaction type.

Going back to our dilema here…

Does that make any sence at all?

Thanks!!!

G.

If you use a warehouse… and you source it out of the warehouse at the price you paid to source it in… cost will not be affected. Cost will be affected if supplier buyys it back at partial price… aka partial credit… however this is what you want because its accurate.

If you follow this method then what you posted above about ignoring 0 priced items would not be needed.
So you might reconsider using warehouse :stuck_out_tongue:

If your returning just 1 bottle one day… due to broken bottle… you could record it as a per unit transaction instead of case… and the next day just source it back in as per unit.

It would affect cost the first day… but it would go back 2nd day… however this is technically accurate… because until you receive that extra bottle… your out a bottle… aka cost affected… it washes when you record it back in next day… which is also accurate.

EDIT: Your not entering negatives doing this method the warehouse source determines this.

EDIT: Thanks @gerlandog you helped me decide how I was going to build my system :stuck_out_tongue:

EDIT without a warehouse you have no way to record a negative purchase btw.

In testing apparently its not working as I described. So I am back to drawing board… I can get inventory to come out right… and cost is not affected… but if I make a partial claim… cost does not reflect it.

Dear @Emre, I was giving this whole COST PRICE a tought…
I found that two rules may aplply to calculation:

  1. If you have a last Purchase Transaction Price, that SHOULD be you Cost
  2. If you dont have a Purchase Transaction Price, then COST price should be determined by a formula (I don know if you are using PPP, FIFO or LIFO, actually I think its PPP), but that formula SHOULD take in account that CERO priced items and negative amounts of buy SHOULD NOT be involved in the calculation.

What do you think about this?

Thnanks!!!

G.

I believe there should be a single formula to calculate cost. As we give special meanings to zeros or negative prices it will become too complex for me to keep stable. For example what you are understanding with negative quantity is “items you’ve sent back to supplier for replace”. Someone else can want use it like “items wasted” so he’ll want to see it included to cost.

ok!! I understand that, but about this…

because if you enter a price there, at least that is what happens in my case, that is the real cost price.

Thanks!!!

G.

What if you still have product left from the previous purchase transaction price however?

Your cost will still be accurate, since it´s the actual buying price and not an estimate…

G.

How would it be accurate… if you buy product A at price B… you buy product A at price C… you have not sold all of product A from the first buy but your only calculating cost from the last buy… then your missing some $ there.

Emre is saying he is calculating it with a custom formula specific for food which works consistently for most styles.

But it would never be accurate if you simply just go by last in…

Last purchase is not always the actual buying price of your inventory…

I understand what @emre is saying… he is saying he could change the cost formula but then it may work for some people but not for others. His formula is a set formula that we should all go by. If he tries to do it for specific instances… it would be way to complex for him to keep stable | working for everyone. He would have to support many different peoples needs at same time potentially disrupting the flow of business and over complicating it for people.

Maybe some day he could implement a system where we can choose our cost formula on install or something. But that would take a lot of resources away from other projects to recode that I am sure.

If you buy a bottle of water at $1, and in the next week at $2, and in the next week at $3, your REAL cost is $3, your PPP would be $2, and your money invested in stock would be qty bought * $1 + qty bought * $2 + qty bought * $3.

your real cost would be 3, because if you have to buy more, its more likely you will pay $3 and not $2 or $1…

do you change your menus prices everytime you calculate your cost?

G.

Thats something entirely different… that is not total cost… that is a cost/menu price relation. That is a projected cost not actual.

If your wanting projected cost for menu price planning you can create formulas and use reports to calculate that.

I guess we are confusing our use of the term REAL cost… to me REAL cost is actual cost… not projected cost based on future prices. REAL cost would be the calculated cost on moment item sold. Or the cost of goods purchased… or @emre custom solution.

What you are dealing with is a KPI projection… which is a great idea… just dont confuse it with the cost formula @emre is talking about :stuck_out_tongue:

What I am trying to say is… you could get the cost your wanting through some clever math in your reports. But the cost your talking about should not be related to you returning items for credit or it would not be accurate.

2 Likes