sales_receipt

When a user contributes the price data, it is stored in the sales_receipt table. Each row is data about a single crop sale.

Model

Field	Type	Nullable	Constraints
id	int4
receipt_id	int4
mandi_id	int4		Foreign Key (mandi)
mandi_name	varchar
mandi_name_hi	varchar
crop_id	int4		Foreign Key (crop)
crop_name	varchar
crop_name_hi	varchar
receipt_date	timestamp
quantity	float8
price	float8
user_id	int4		Foreign Key (person_table)
booklet_number	text
receipt_image_url	varchar
is_approved	bool
created_at	timestamp
updated_at	timestamp
promised_token	int4
token_amount	int4
receipt_owner_id	int4		Foreign Key (person_table)
receipt_owner_phone_number	varchar
validated_by	int4		Foreign Key (person_table)
validated_on	timestamp
rejection_reason_ids	_int4

Description of fields

id

The primary key of the row.

user_id

It tells about the user who uploaded the receipt and is mapped to the person table.

receipt_owner_number and receipt_owner_id

It tells about the phone number of the person, who is the owner of the receipt. Receipt_owner_id is mapped to the person table.

1. It is an optional field.

2. In case a person uploads their own receipt, the user_id and receipt_owner_id will be same, else it would be different.

3. In case the receipt_owner_number is not an existing user, then a new user is created in the person_table.

4. We cannot check whether the person uploading the receipt has provided the correct information about the receipt_owner.

5. We are collecting this information as it may help us in growth. We can send the receipt_owner a notification to download the application.

6. Rewards are allocated to receipt owner wallet when a receipt is uploaded.

validated_by

Provides the user_id of the team member who validated the receipt. It is a foreign key referencing to the person table.

Each submitted receipt remains in a pending state until a data validator approves or rejects it. No receipt is shown to a user in the frontend until it is approved by a data validator.

receipt_id and booklet_number

These are unique identifiers of a sales receipt.

In a mandi multiple auctions are happening simultaneoulsly and each staff member carries a booklet with them to record the auction results. They tear one copy of the sales receipt and give it to the seller. Therefore, the booklet number and the receipt number within that booklet together can uniquely identify a sales receipt.

In a mandi thousands of auctions happen each day. Hence, tens of booklets are finsihed each day. There may be a case that same combination of booklet_number and receipt_id in used in the same mandi a few weeks down the line. Similarly, it is possible that the same booklet_number and receipt_id is used in a different mandi on the same day. Thus, to make a unique combination we must use four parameters:

1. booklet_number

2. receipt_id

3. mandi_id

4. receipt_date

This is based on the assumption that within a mandi, in a same day, the combination of booklet_number and receipt_id will not be repeated.

mandi_id, mandi_name, mandi_name_hi

All are unique identifiers of a mandi and are mapped to the mandi table.

crop_id, crop_name, crop_name_hi

All are unique identifiers of a crop and are mapped to the crop table.

quantity

Is used to store the quantity of the crop sold. Currently, all quantities are stored in quintals.

price

Is used to store the price received in auction. Currently, all prices are stored in per quintal unit and the default currency is INR.

receipt_date

Is the date written on the sales receipt.

The receipt_date can be different from the date on which the receipt is uploaded to Bolbhav.

receipt_image_url

Each uploaded image of the sales receipt is stored in AWS S3, and a unique link is generated.

The name given to the url should be unique otherwise, it will start overwriting the previous files in S3. Currently, we follow this naming convention of url. How are buckets maintained in S3?

created_at

Timestamp on which the data is submitted and the row is added.

promised_token

When a user submits a receipt, they are promised some tokens, which is a virtual currency of Bolbhav. These are payable only if the receipt is approved after validation.

Add logic to explain how promised tokens are calculated (or link)

token_amount

These are the actual tokens that are credited to a user's wallet after the submitted receipt is validated.

If a receipt is rejected, then the token_amount is changed to zero, and no entry is made in a user's wallet.

is_approved

It tells about the validation status of a receipt. It has three values:

1. null - for pending approval/rejection

2. true - for approved

3. false - for rejected

validated_on

When the data validators take any action on the is_approved field, this timestamp is set.

Does it record the first validation or the latest validation timestamp?

receipt_rejection_reasons

It stores a list of reasons for which a particular receipt is rejected. It is mapped to receipt_rejections_reasons table.

updated_at

timestamp that tells when the last time any field is edited.

It is different from validated_on, which changes only when the status is_approved is changed.