Makes sense. The Tag {REPORT CONSUMPTION DETAILS:X} runs queries against DB table [PeriodicConsumptionItems] … which is also what an EoD “report” is. All the same thing, getting data from the same place.
I think our problem here is EOD was never meant to be a continuous stock take report for manual stock takes. It was meant specifically to adjust daily inventory you may have sold because in restaurant we never have exacts it can be off a little.
So this has to be an issue.
I just will find it hard explaining to the customer he has to go to 2 places to enter his stock adjustments after a physical count.
He will not know his wastage as he still believes the Samba values are correct until he physical does a count.
Yes but unfortunately we are very limited with inbuilt Samba functionality to build it - we would need to go ala Q style… I guess I surprised this has not been raised before.
I disagree. Why have a “Physical Inventory” column that is editable, if it were not meant to make corrections and track “shrinkage” ?
I think Inventory was started ages ago, things were added and changed over the years, and the result is a “broken” band-aid solution to many “issues”.
Please don’t take this the wrong way Emre… it’s just how I see it. Thus the PHP system I built for v4, because the Inventory system in SambaPOS is missing a lot of things and has flaws IMHO.
I noticed this years ago, but I don’t even use EoD. Never did.
@emre I honestly think if the APPEND Unmapped items just went and got the last item it can find in Period consumptions and used that cost everything would work as normal in these cases where there was no consumption last period.
BUT - there must be a limit because it seems the consumption record will be maintained with no consumptions for 100 days
[PeriodicConsumptionItems] as the name suggests does not contain records for Inventory Items that have no “transactions” (as per Recipe for something Sold, or per Purchase Transactions) within the given Period (WP).