Add groceries with prices + scan barcodes

[LEON-BROTHER]

So there is one feature that I am missing.

It's that you are able to add the groceries you bought with prices and from what store (e.g. store A: 9,99; store B: 12,49) so that you can add a transaction easily. When you begin doing this, it will take while that you actually scanned everything but after that you only scan the barcode and from what store and boom: you can track when you last bought that specific product, or what calories it contains or how much salt/sugar etc. see price history from a product or the size changes (shrinkflation)

Also:
Being able take a picture from the product and enter/scan the barcode.

So TLDR: A database for your groceries, with stats

a little bit like #696 but more different and prob more advanced

I'm sorry for my grammar and spelling mistakes.

[ulsklyc]

Your grammar is fine, and the idea is clear. Let me separate it, because one third of it fits Yuvomi well and the other two thirds pull against what the app is.

Price history per product and store: this fits, and it needs nothing external. "What did I last pay for this, and where" is answerable entirely from data you enter yourself. What blocks it today is small and concrete: a shopping item cannot carry a price. Give it one, and the history follows from the items you already tick off, without a database of anything.

A product database with nutrition, package sizes and calories: this does not fit. Realistically that data comes from Open Food Facts or a similar service, which means every household running Yuvomi would be talking to an outside server about what it eats. The whole promise of this app is that it does not do that. I would rather not have the feature than have that footnote.

Barcode scanning: not soon, and honestly not primarily for technical reasons. There is no camera code anywhere in the project today, and a scanner is only worth its complexity once there is something to look the code up in, which brings back the point above. Scanning into your own catalogue is coherent, but then you are typing the first entry for every product by hand, which is the part you rightly describe as taking a while.

Shrinkflation tracking is a nice observation and the honest answer is that it needs exactly the data set I just declined, package size over time from a source that is not you.

So: the useful, self-contained core of this is a price on a shopping item and a history built from it. That is the part I would build. The catalogue is the part I would not, and I want to be clear about that now rather than leaving it looking merely postponed.

You compare this to #696 yourself, and you are right that they rhyme: both want to keep a record of objects with a value attached. Whether that becomes one shape or two is not decided, and both threads stay open as the reference for it.

[LEON-BROTHER]

Hello!

Thx for the quick feedback!

What I meant for the calories, product size, etc. was that you (the user) read it from the packaging, most products have their nutrition printed on them. So no external server needed.

For the scanner, fair point. It really is complex to do something like that so I totally understand.

Thx again for reading my idea!