Incoming transactions can have their date field set to any date, and we'll save them like that; and when calculating turnover, we look at date value for existing transactions; but we ignore date value of the transaction under consideration and always compute turnover for the current month.
E.g. if on January 15th 2024, a transaction with date: '2023-12-01' and amount: 2000 arrives: we'll store it with December date.
Then, if a second transaction with date: '2023-12-01' arrives: we'll try to get turnover for the current month (January 2024), which will be zero, so we won't use "high turnover" rule.
This behavior is inconsistent: both transactions have the same date, and both arrived to our API on the same day, yet for turnover calculation purposes we use date field of the first transaction (and not the date when it arrived to our API), but the date of arrival to our API for the second transaction (and not its date field).
Incoming transactions can have their `date` field set to any date, and we'll save them like that; and when calculating turnover, we look at `date` value for existing transactions; but we ignore `date` value of the transaction under consideration and always compute turnover for the current month.
E.g. if on January 15th 2024, a transaction with `date: '2023-12-01'` and `amount: 2000` arrives: we'll store it with December date.
Then, if a second transaction with `date: '2023-12-01'` arrives: we'll try to get turnover for the current month (January 2024), which will be zero, so we won't use "high turnover" rule.
This behavior is inconsistent: both transactions have the same `date`, and both arrived to our API on the same day, yet for turnover calculation purposes we use `date` field of the first transaction (and not the date when it arrived to our API), but the date of arrival to our API for the second transaction (and not its `date` field).
Incoming transactions can have their
datefield set to any date, and we'll save them like that; and when calculating turnover, we look atdatevalue for existing transactions; but we ignoredatevalue of the transaction under consideration and always compute turnover for the current month.E.g. if on January 15th 2024, a transaction with
date: '2023-12-01'andamount: 2000arrives: we'll store it with December date.Then, if a second transaction with
date: '2023-12-01'arrives: we'll try to get turnover for the current month (January 2024), which will be zero, so we won't use "high turnover" rule.This behavior is inconsistent: both transactions have the same
date, and both arrived to our API on the same day, yet for turnover calculation purposes we usedatefield of the first transaction (and not the date when it arrived to our API), but the date of arrival to our API for the second transaction (and not itsdatefield).