|
745 | 745 |
|
746 | 746 | ## Booking Flow with Approval
|
747 | 747 |
|
748 |
| -The <a>Booking System</a> MAY optionally support approval. As the approval processes is initiated by the <a>Booking System</a>, implementation of this section by the <a>Booking System</a> is only required if this flow is supported, otherwise this section can be completely ignored. |
| 748 | +The <a>Booking System</a> MAY optionally support approval of bookings by the <a>Seller</a>. As the approval processes is initiated by the <a>Booking System</a>, implementation of this section by the <a>Booking System</a> is only required if this flow is supported, otherwise this section can be completely ignored. |
749 | 749 |
|
750 | 750 | ### Customer Journey
|
751 | 751 | The booking journey of a <a>Customer</a> is generalised into the following logical steps:
|
|
788 | 788 |
|
789 | 789 | - The <a>Booking System</a> adds the `Order` to an <a>Orders feed</a> specific to the <a>Broker</a>, which the <a>Broker</a> reads to update its internal state, including those updates resulting from cancellations.
|
790 | 790 |
|
| 791 | +Note that the `OrderProposal` at stages 2.1 and 2.2 does not constitute a booking. The whole flow MUST be completed before the <a>Customer</a> is considered "booked" onto an <a>Opportunity</a>. |
| 792 | + |
791 | 793 | ### Leasing
|
792 | 794 |
|
793 |
| -Leasing works as specified in the Simple Booking Flow, however the lease SHOULD be carried over to the `OrderProposal` and the lease extended for a duration sufficient to cover the lifetime of the `OrderProposal`. |
| 795 | +Leasing works as specified in the Simple Booking Flow, and if a lease was acquired at **C1** or **C2** it SHOULD be carried over to the `OrderProposal` and the lease extended for a duration sufficient to cover the lifetime of the `OrderProposal`. |
| 796 | + |
| 797 | +A lease is NOT REQUIRED for this flow, as in some cases <a>Sellers</a> may prefer to manage contention for spaces manually via the approval process instead of leasing. |
| 798 | + |
| 799 | +If an `OrderProposal` remains in a `orderProposalStatus` other than `https://openactive.io/CustomerRejected` or `https://openactive.io/SellerRejected` after the lease has expired, it MUST be possible for the <a>Customer</a> to still complete the booking if they attain approval. For example, if an <a>Opportunity</a> becomes full and no substitute opportunities are available, then all remaining outstanding `OrderProposal`s related to that <a>Opportunity</a> would need to be automatically rejected. |
| 800 | + |
| 801 | +If the lease expires the <a>Booking System</a> could, for example, automatically reject the `OrderProposal` on behalf of the `Seller`, automatically renew the lease, or allow the <a>Seller</a> to manually deal with the contention for spaces as part of the approval process and hence do nothing. |
| 802 | + |
794 | 803 |
|
795 | 804 | ### High-level type flow
|
796 | 805 |
|
|
826 | 835 |
|
827 | 836 | If an `Offer` requires this **Minimal Implementation**, the <a>Booking System</a> MUST include the `openBookingFlowRequirement` of `https://openactive.io/OpenBookingApproval` in the `Offer`s within its open data. This allows <a>Brokers</a> that do not support approval to easily filter out such offers from their experience.
|
828 | 837 |
|
| 838 | +Note that when `Offer`s that require approval are mixed with `Offer`s that do not require approval in a single `OrderQuote`, the whole `OrderQuote` MUST always require approval. It is at the discretion of the <a>Broker</a> whether to issue two separate `OrderQuote`s (and hence complete two separate booking flows) that batch those `OrderItem`s that require approval separately to those that do not, or whether to instead combine them together into a single `OrderQuote` and hence complete a single booking flow with approval. |
| 839 | + |
| 840 | + |
829 | 841 | ##### Proposal Approval
|
830 | 842 |
|
831 | 843 | - If <a>Seller</a> approval is given, the <a>Booking System</a> MUST set `orderProposalStatus` to `https://openactive.io/SellerAccepted` in the <a>Orders feed</a>, which will give the <a>Broker</a> permission to proceed to **B**.
|
|
876 | 888 |
|
877 | 889 | For an `Order` that requires approval, the flow differs from the above as follows:
|
878 | 890 |
|
879 |
| -- `OrderQuote` is returned at **C1** and **C2** with `orderRequiresApproval` set to `true`. |
| 891 | +- `OrderQuote` is returned at **C1** and **C2** with `orderRequiresApproval` set to `true` if any `OrderItem`s require approval. |
880 | 892 | - `OrderItem`s that require approval within an `OrderProposal` have `orderItemStatus` of either `https://openactive.io/OrderApprovalPending` or `https://openactive.io/OrderApprovalAutomatic`, to indicate which specific items are contingent on approval and which could be purchased separately.
|
881 | 893 | - The `OrderProposal` MAY include an `orderCustomerNote` in order to "Ask a question about this opportunity?".
|
882 | 894 | - Additional data is supplied at **C1** and **C2** as in the Simple Booking Flow to satisfy the `orderItemIntakeForm` for all `OrderItems`.
|
| 895 | +- The `totalPaymentDue` from **C2** is used for Payment Authorisation as with the Simple Booking Flow. |
883 | 896 | - An additional step **P** is required after **C2** where the <a>Broker</a> submits the completed `OrderProposal` to the <a>Booking System</a>, which returns an `OrderProposal` that the <a>Broker</a> MUST store, with `orderProposalStatus` set to `https://openactive.io/AwaitingSellerConfirmation`. The call is atomic. The returned `OrderProposal` also contains an `orderProposalVersion` (constructed from the `id` of the `OrderProposal` combined an additional version UUID, e.g. `https://api.example.com/order-proposals/358105b4-e571-43fa-b737-906d319c6a32/version/8eb1a6ce-3f5b-40b0-87a7-bddb4c5518bd`).
|
884 | 897 | - Once approved, the <a>Booking System</a> puts the updated `OrderProposal` onto the <a>Orders feed</a> (**A**), with either an unchanged `orderProposalVersion` (see **Minimal Implementation**) or a new `orderProposalVersion` (see **Proposal Amendment**).
|
| 898 | +- If required due to expiration of the existing Payment Authorisation or a change in the `totalPaymentDue`, the payment can be re-authorised before **B**. |
885 | 899 | - The <a>Broker</a> supplies a minimal `Order` to **B** that just contains this `orderProposalVersion`, and continues the flow as per the Simple Booking Flow.
|
886 | 900 |
|
887 | 901 |
|
|
940 | 954 |
|
941 | 955 | ### Additional Details
|
942 | 956 |
|
943 |
| -This version of the specification does not provide details to construct a complex additional details capture form, however it does facilitate simple text fields to capture additional details. |
| 957 | +This version of the specification does not provide details to construct a complex additional details capture form, however it does facilitate simple text fields to capture additional details. These can be used for both the Simple Booking Flow and the Booking Flow with Approval. |
944 | 958 |
|
945 | 959 | If an `Offer` requires additional details capture, the <a>Booking System</a> MUST include the `openBookingFlowRequirement` of `https://openactive.io/OpenBookingIntakeForm` in the `Offer`s within its open data. This allows <a>Brokers</a> that do not support additional details capture to easily filter out such offers from their experience.
|
946 | 960 |
|
|
1800 | 1814 | | [`oa:orderProposalVersion`](https://openactive.io/orderProposalVersion) | - | REQUIRED | [`schema:URL`](https://schema.org/URL) | The unique URL representing this version of the `OrderProposal`, or the version of the `OrderProposal` to which this `Order` is related. |
|
1801 | 1815 |
|
1802 | 1816 |
|
1803 |
| - |
1804 | 1817 | ### `oa:OrderQuote`
|
1805 | 1818 |
|
1806 | 1819 | `OrderQuote` subclasses `Order`, and includes of the above properties as specified for `Order` with the addition of `oa:lease`, without `oa:payment`, and with `totalPaymentDue` only required in the response.
|
|
1811 | 1824 | | [`oa:lease`](https://openactive.io/lease) | - | OPTIONAL | [`oa:Lease`](https://openactive.io/Lease) | The lease on the OrderItems which lasts for the duration specified by the <a>Booking System</a>. |
|
1812 | 1825 | | [`oa:payment`](https://openactive.io/payment) | - | - | [`oa:Payment`](https://openactive.io/Payment) | `payment` is not expected for `OrderQuote`. |
|
1813 | 1826 | | [`schema:totalPaymentDue`](http://schema.org/totalPaymentDue) | - | REQUIRED | REQUIRED | [`schema:PriceSpecification`](http://schema.org/PriceSpecification) | The total price of the `Order`, which includes or excludes tax depending on the `taxMode`. |
|
| 1827 | +| [`oa:orderRequiresApproval`](https://openactive.io/orderRequiresApproval) | - | REQUIRED | [`schema:Boolean`](https://schema.org/Boolean) | Whether the Booking Flow with Approval MUST be used to book the set of `OrderItem`s included. MUST be `true` if any of the `OrderItem`s require approval. | |
1814 | 1828 |
|
1815 | 1829 |
|
1816 | 1830 | ### `oa:OrderProposal`
|
|
0 commit comments