...
Anchor exception_1 exception_1
Expand title теоретично можлива ситуаціяСитуація, коли немає Переможців Можливо таке, що перший Авард одразу отримає статус pending_waiting. Логічно, що всі наступні Аварди також отримають цей статус.
В такому випадку, перший Авард має одразу отримати статус pending_admission і слідувати логіці цього статуса.
Наприклад,
Організатор вказав procedure.items.quantity == 10 000
Учасник_1 запропонував 10 000 по найменшій ціні 10
Учасник_2 запропонував 500 по ціні 11
Учасник_3 запропонував 500 по ціні 12
Всі три учасники успішно пройшли перевірку документів (awards.status == waiting)
ЦБД розраховує x_quantityLimit == (10000 + 500 + 500) * 0.8 == 8 800
Реалізувати є можливість тільки 8800, а перший Авард пропонував 10000, що є більше, ніж очікується. Він одразу автоматично отримує статус pending_waiting, і всі наступні Аварди також.
Система має перевірити "Всі наявні Аварди у статусі pending_waiting? і якщо так, то
Одразу після цього автоматично перший Авард отримає статус pending_admission і може погодитись на 8800 із своїх 10000, які він ставив спочатку. В момент отримання статусу pending_admission, всі інші Аварди отримують статус cancelled
Якщо він відмовиться ставити 8800 замість 10000, то процедура вважається неуспішною. Наступних Авардів вже не кваліфікують.
- Перевіряється наступний Авард із черги. Береться його quantity і порівнюється з (x_quantityLimit - awards[0].items.quantity).
- Якщо awards[1].items.quantity <= (x_quantityLimit - awards[0].items.quantity) залишку, то Авард отримує статус pending
- Якщо awards[1].items.quantity > (x_quantityLimit - awards[0].items.quantity) залишку, то Авард отримує статус pending_waiting
- Аналогічна перевірка відбувається з кожним наступним Авардом до моменту, коли перший Авард отримує статус pending_waiting. Коли перший із всіх Авардів отримає статус pending_waiting, то всі наступні також автоматично отримують цей статус.
...