Proof: add new "consumption-related" fields on receipts: total amount, items count

[raphodn]

Story

When uploading a proof, we could ask the user to input the number of items on the receipt, and it's total amount.

This could be useful metadata to show afterwards to the user.

Ideally this data should only be sent back to the owner, no to other users !

Todo

• 2 new fields: number of items (receipt_price_count) & total amount (receipt_price_total): feat(Proofs): new fields to allow users to input the number of prices & total sum #497
• API: only return these fields to the logged in proof owner

Extra Price.receipt_quantity field: see #499

Frontend integration: see openfoodfacts/open-prices-frontend#974

[serpico]

Reply to #339 (comment)

I'm not opposed to it, but I'm concerned about some contributors wearing out, and again my receipts aren't that long.

Thinking of it, maybe some additional thought should be put into this, how long does it take to input X products, break down users by number of product input per session, etc...see if there's a relation, if the numbers drop. It might be linked to gamification ( an option for "hardcore" contributors ) or disabled by default in the parameters, just a thought though...

probably fit #171 as well

[raphodn]

You're right, I think I should specify a few things :

• these fields would be optional (and potentially hideable via the settings as you mention)
• they would unlock new use cases (use my receipts to store my consumer data and have my own dashboard/tracking)
• this info would be input manually to start with, but automated in the future once we run OCR on receipts

[monsieurtanuki]

My 2 cents

Sounds a bit like openfoodfacts/smooth-app#5417
Not convinced at all it makes sense to store those new data in the model. I would rather consider it as a input help ("btw it's your 4th product, and 6.45€ spent so far"). Storing them implies data consistency maintenance. Computing them on the fly should be easy, though.

[raphodn]

Also missing : the number of products bought (for instance 2x nutella)

[serpico]

If the number of products is added, I feel it should be linked/connected/available somehow to the list feature on smoothie down the road, whether it's product(s) user want to buy or even check the price of...on my shopping list I have items for this, some to buy others just to remember to take a pic to update the price on OP.
#171

[raphodn]

This weekend during the offdays we talked quite a bit about "shopping sessions" (derived from a single receipt (1 session), or from GDPR requests (multiple sessions)). And building personal dashboards from them. And allowing users to dive in their previous sessions. Comparing over time. Having "basket scores". Etc

We will have to think about fitting this somewhere between the current Prices and Proofs models.

• maybe renaming Proof to something more explicit, and creating a new ProofImage ?
• or adding extra fields to the Proof model (like proposed here)
• also taking privacy into more consideration (an anoymous user could see only prices, a logged in user could see prices with their associated proofs/sessions)

/ brainstorming

[raphodn]

cc @teolemon @raphael0202 can we talk about this on wednesday ? Or give your input here :)

[raphodn]

Storing them implies data consistency maintenance. Computing them on the fly should be easy, though.

We don't/won't use it for data consistency, because there is too many edge cases :

• global discounts with a fidelity card
• some users won't want to add some specific prices, or forget

But it could definitely help :

• to nudge users to add "missing" receipt prices
• info bubble if the sum indeed goes over the total sum (but dismissable in the case of global discounts)
• to follow their spendings (i would much rely on the fixed "total" value, instead of the "calculated/sum" one)

It's the idea of seperating "personal spendings" with "contributing to Open Prices". It will not always be 100% consistent/shared I agree

[raphael0202]

I would be in favor of adding a new field to the Proof table to add number of items + total amount. But how this data will be filled in, that's another question ;)
One project I really want to tackle in the coming months is the automatic extraction of product name and price from receipts (and store address & date), it would speed up considerably the process of adding prices through receipts.
The total amount and the number of prices would be informations extracted using the model. However, in our model schema, we should take care of separating "gold data" (data submitted by the user) from data inferred from models, so that we can be sure of what has been validated manually.

[monsieurtanuki]

I would be in favor of adding a new field to the Proof table to add number of items + total amount. But how this data will be filled in, that's another question ;)

Again, not convinced by that field addition, as they can be computed on the fly after creation, or during creation for user for input double-checks.
In addition to that, @teolemon recently complained again that in Smoothie we don't offer the feature "add prices to an 'old' proof from the proof gallery". I said "What's the use case?". He mentioned an actual personal case of "a 48 line proof from which I entered 10 prices once, and I want to complete the rest later".
TL;DR the number of items and the total amount are not related to a proof in a 1-to-1 relationship, therefore they have nothing to do at the proof level. Unless you're interested for stats reason in the typical number of items of receipts, regardless of the prices actually entered, but then that's another story.

One project I really want to tackle in the coming months is the automatic extraction of product name and price from receipts (and store address & date), it would speed up considerably the process of adding prices through receipts.

I even imagined a step further, when I painfully collected price tags for skyr and fromage blanc.
Some kind of "price tag session": I set the date, the location, and then I provide a list of price tag pictures, that contain both the barcode and the price, like that:

And "à la Robotoff", I'm being asked to confirm the barcode and the price suggestions.

[raphodn]

as they can be computed on the fly after creation, or during creation for user for input double-checks.

again, users will not always necessarily add all the products on a given receipt. but having the full amount (taking into account receipt-wide discounts for instance) is the first step towards consumption-tracking features.

Some kind of "price tag session"

Yes we discussed this during the OFFdays and during a weekly meeting, the long-term goal would be to move the price tag addition to a platform à la Hunger Games, where it would be crowdsourced/verified. It's price data, but not consumption data, so a notch below in terms of value.

[raphodn]

Linked subject (possibly in another issue): allow users to input the number bought for a given item.
Say in a receipt I buy 2x Snickers, I will add its price once, but I want to store somewhere the info that it was bought in a larger quantity. This would rather be stored on the Price model. For instance receipt_quantity. Defaults to 1.

[monsieurtanuki]

As a user I'm interested in prices rather than in consumption tracking, and therefore I would skip the additional input of quantities.
That said, no objection against adding the receipt_quantity field in the Price model, with a default of 1.