Approval of data

Receipts can be approved from both the "Pending Receipts" and "Rejected Receipts" pages. Upon approval, tokens are granted to the receipt uploader.

• When a receipt is validated, the endpoint admin/update_approval_status is triggered. The request payload includes information such as the action (whether it's approved or rejected), the receipt ID (sale_receipt_id), and an array of rejection reason IDs if applicable.

• The function update_approval_status(user) is responsible for updating sale receipt data. It handles team member validation, grants tokens upon receipt approval, calculates eligible tokens, manages contribution bonus events for every tenth approval, checks if the user is eligible for referral rewards based on receipt contribution, triggers in-app or WhatsApp notifications based on crop count, and updates cached data or creates new entries if the data doesn't exist.

What happens when a receipts gets rejected?

Upon rejection of a receipt, it is marked as having invalid or incorrect data. If a receipt is rejected from the "Approved Receipts" tab, the cached data for the particular crop and mandi for the specific date are updated.

What happens when a receipts gets approved?

When a receipt is approved, if it's approved from the "Rejected Receipts" page, the rejection reasons are removed from the sale receipt data. Additionally, the cached data is updated, including crop metrics details, in a unique entry table. These details typically encompass crop price metrics, mandi details, receipt image URLs, and user is granted tokens.

Tokens awarded to a contributor

Tokens are awarded upon the approval of receipts, determined by both the count of receipts and time-based factors.

Count of Receipts	Tokens award
<= 10	5 silver tokens
<=20	4 silver tokens
<=50	3 silver tokens
>50 or after 4pm	2 silver tokens

Storing cached metrics

We store several cached data for faster API performance. These cached data are generally in JSON format, stored in unique_entry table and contain pre-calculated aggregated values for mandis and crops.

For example, if a mandi has 1000 sale receipts in a day and a user is loading the page to view sale receipts, we do not make DB query everytime to get data for 1000 sale receipts and do not calculate metrics like total quantity, max, min, median, total prices. Instead, on every sale receipt approval or rejection, these metrics are calculated & stored instantly so that when user is viewing the page, there is speed benefit from pre-calculated metrics.

The following entries are stored as cache:

1. trader_mandi_{mandi_id}crop{crop_id}_{date}

2. trader_parent_crop_{crop_id}_{date}

3. trader_crop_mandi_{crop_id}_{date}

4. cs_mandi_crop__{mandi_id}_{crop_id}_{date}

5. cs_mandi__{mandi_id}_{crop_id}

For more details about what data stored, visit the unique_entries table.

Force update of cached entries

It's not easy to modify cached entries on certain actions. For example, if a sale receipt is rejected by an admin after it was approved, then the metrics needs to be updated. That will require modifying several parameters in the stored cache data like min, max, median price. And it might not be a simple subtraction of data. Hence it was decided that it's easier to re-calculate the whole of the metrics in actions like these. This is what forced-update of cached entries means.

In the following scenarios, force update of cache data happens:

1. Pending Receipt Page -> Approved button.

2. Rejected Receipt Page -> Edit Modal -> Status -> Approve-> Save action.

3. Rejected Receipt Page -> Edit Modal -> Status -> Pending-> Save action.

4. Rejected Receipt Page -> Edit Modal -> Edit Data -> Save action.

5. Approve Receipt Page -> Edit Modal -> Edit Data -> Save action.

6. Approve Receipt Page -> Edit Modal -> Status -> Rejected-> Save action.

7. Approve Receipt Page -> Edit Modal -> Status -> Pending-> Save action.

How tokens are allocated?

A receipt can be approved from three places in Admin Portal:

1. Pending receipt page -> Approve button

2. Pending receipt page -> Edit modal -> Status dropdown -> Save action

3. Rejected receipt page -> Edit receipt modal -> Status dropdown -> Save action

Upon approval of a receipt, the receipt uploader is granted promised tokens and corresponding wallet ledger entry is created.

The following modifications are done in the data:

1. sale_receipt table

   1. The validator id and validation timestamp are updated

   2. Token amount granted value is updated

2. A new ledger entry is made in wallet_ledgers

   1. Source wallet id is set to uploader's membership wallet id

   2. Target wallet id is set to bank's membership wallet id

   3. Amount is equal to promised token or token amount value in sale receipt table

   4. Reason is set to "Reward for mandi contribution"

   5. Ref id is set to refer to the sale receipt id. Something like sale_receipt_id_123

3. Uploader wallet balance is updated in user_wallets table