### UC.1 Private person simple booking

booking wizard Personal Data->Order: create (state: cart)
Order->LineItem: create
Order->Payment: create
payment checkout->Payment: update (state: placed)
job->Order: update(state: delivered)
Order->CompensationItem: create
job->Order: update(state: settled)

>[name=Jan Kaczorowski][color=gold]
>
> :+1: nicely done, clarity at last!
> ActionPoints:
> - Create StatusUpdaterJob (covers both placed->delivered and delivered-settled transitions, per order)
> - Update Order statuses

#### order upgrade

service provider/admin->Order: upgrade
Order->LineItem: update
Order->Payment: update
Payment->payment checkout: trigger

### UC.2 Organizational Vaccination Order, patients as objects

admin->Order: create (state: placed)
Order->LineItem: create
Order->Payment: create
job->Order: update(state: delivered)
Order->CompensationItem: create
job->Order: update(state: settled)

#### Business flow
- (organization) makes a booking (or admin on their behalf)
- patients register themselves by means of IPad or get registered by representative of an org

#### IT flow
- Booking object is the source of order information
- in our current flow V2::Order is afterwards generated from a booking
- Patient records get created along with PatLinks to Booking
- Order.line_item.qty

#### Doubts
- should Order.line_item.qty be calculated out of booking.patient_count or should Order.line_item.qty be set upfront and limit the booking.patient_count

>[name=Jan Kaczorowski][color=gold]
>
> I think we may wanna have interest in LineItem.qty being **decoupled** from booking.qty. Meaning:
> Obviously, ultimately `line_item.qty == line_item.bookins.map(&:patient_count)` by the time order.order_state == 'settled', but prior to that if bookings.patient_count() < line_item.qty that'd mean order is just not yet delivered and thats just fine. (We would obviously have a checks and jobs to make all of it in sync but that gives us more freedom)

- if line_item.qty limits the booking.patient_count
- you either cannot have multiple bookings for line_item, only just one
- or you cant calculate compensations out of lineItems (you can do that though from a booking obj)
- you need to make sure that `line_item.qty` >= `line_item.bookings.map(&:patient_count).sum` to avoid situation in which vaccinated people count will exceed the number the customer is willing to pay for.

> [name=Jérémie Poiraudau] couldn't we update the `line_item.qty` if `line_item.bookings.map(&:patient_count).sum > line_item.qty `

### UC.3 Organizational Vaccination Order, patient number override
- Booking object is the source of order information
- in our current flow V2::Order is afterwards generated from a booking
- Organization registered 5 initial patients, but then resolved to vaccinate additional 50, for all of which they are willing to pay. Admin desires to just set a line_item / booking qty to 55 somehow, and not to be bothered with having to create 50 extra fake patient objects.

#### IT flow (hypothesis)
- Booking has an additional column of `quantity`:int.
- Booking.patient_count() calculates `quantity || patients.count`

Order.line_item.qtity is set from `5` to `55`
order gets recalculated. Status changes to `not_fulfilled` (or something?)
##### Option #1 if booking was not yet completed
existing booking is updated (quantity field gets set to `55`)
order gets recalculated
##### Option #2 if booking for those 5 ppl was already completed
for those extra 50 patients another booking object is implicitly created and attached to the same `line_item`
order gets recalculated

### UC.4 (future) Organizational order with multiple bookings
#### Business flow
- (organization) makes an order for COVID tests for 100 folks
- these tests are to be conducted within 2 month timeframe
- That produces V2::Order with 1 V2::LineItem with qty=100
- to that there will be, say 1 booking a month, for a total of two bookings.
- the pat_number of any of those booking is a rough estimate (can be 50 and 50, but theres an understanding that all kinds of things can happen, like for a first 20 ppl will show up, and 80 ppl for the second), so it has to be flexible.
- we don't wanna create those patient records
- organization already paid for 100 folks, and thats the patient cap for both of the bookings combined
- question: how should the compensation look like?
> [name=Jérémie Poiraudau]
> - I'm not sure we should have a "patient cap" but we should require an extra payment on quantity update.
> -

> [name=Jérémie Poiraudau] UC.5 Organizational Booking through the vaccine wizard.
> #### Business flow
> - OrganizationBooking is created first, without patient and user linked to it
> - the customer select the line_item quantity. Cart and line_item is created simultaneously
> - customer enter order details, order is created.
> - the order is subject to change : first by the customer as he can come back during the vaccine wizard and change the vaccines quantity on the line_item. The admin has also the possibility to change the vaccines quantity or adding patients to the underlying booking.