Skip to content

✨(backend) BatchOrderQuote model to prepare quotes for companies batch orders #1102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 30 commits into
base: development
Choose a base branch
from

Conversation

jonathanreveille
Copy link
Member

@jonathanreveille jonathanreveille commented May 22, 2025

Purpose

Some companies need quotes to proceed for payments when they are buying for their employees some training/courses for example.

For more details :
The quote can be represented as the 1st step of another payment method, that results for the seller to create a purchase order that triggers to the process to pay for the company.

Proposal

Create a simple model to track down the information of the Batch Order to produce the document on demand.

  • Create the model BatchOrderQuote
  • Add new quoted flow into the batch order flow state machine

jonathanreveille and others added 30 commits May 5, 2025 09:29
Added discount relation to order group that allows
a buyer to create an order and benefit from a discount
amount or a discount rate on the total price.
We added the discount field into the admin OrderGroup
serializers which allows admin user to add a discount
to an existing order group. We can only add an
existing discount to the group.
Created a viewset to create and list discounts only.
This will allow admin user to create the discount that
can be added in relation to an order group. We have made
on purpose on the admin api that it is not possible to update
or delete a discount. If you want to do such action, you may
use the django admin backoffice to handle them.
Since we made it manageable to add discount through the admin
api, we should now show the information on the client serializer
for the order group details when a discount is present.
To ease the life of our admin users, we added into the order
group view the possibility to add a discount, or to take it away.
We also added the counter on the discount view to give us the
information on how many times the discount is used through
the order groups. Finally, we updated the view of the column
where it displays the value of the discount to make it more
human-readable.
We want the backend to assign order groups to an order.
We want to allow users to use a voucher code to get dicounts on orders.
In order to manage ordergroups discount in the frontend, their ids are
replacedl by actual object.
As we want to avoid discount duplicates in the select box, rate and
amount are now unique.
As we want to allow users to manage discounts through order groups, they
have been added to the existing order group form.
Now that we can have order groups without seat limitation, we mast allow
an empty string in the payload, like the frontend actually sends.
Just a convenient script alias, and some uniformization.
In front, we have a search feature on the discount select.
The API needed to support list query.
A currency were hard coded while developping the discount model.
New ordering rule was added to the OrderGroup model
through the `position` field. A little adjust was
required for a flaky test that would still based itself
on the previous ordering logic.
We want a person from a company to be able to place
a batch order for their employees to follow a session.
We created this model to track down the session they
want to follow, we prepare the estimated total, and
the contract.
To facilitate the transition and actions between different
steps of the batch order lifecycle, we have decided to
add states.
Added new endpoints to submit for signature the contract of a
batch order and to submit for payment the batch order. Some
adjustments were made into the the signature backend and
the payment backend.
To facilitate the evolution to generate different
context for contracts, we have decided to refactor
the main method into chunks that prepare each
sections.
To improve our developers experience, we added a
debug view to preview the mail sent when a batch
order payment has succeeded.
When the batch order is completed and the orders are
generated with voucher codes, the user can use one
of the voucher and assign himself to an order
in state `to_own`. As a reminder, the batch order
generates orders in `to_own` state with a discount
rate of 1. The user will only need to insert his
voucher code to get access to the course, he won't
have to pay because it has been paid through
the batch order. The voucher code is only linked
to one order in state `to_own`.
Now that we can have order groups with optional limitations, we must allow
empty strings in the payload, like the frontend actually sends.
Locale used by mui for date formating was wrong.
As we want to allow users to manage order group start and end dates,
they have been added to the existing order group form.
We need to handle the case when a batch order gets canceled. If
the batch order was in state `completed`, we need to cancel each
generated order in state `to_own` and delete the vouchers associated
to them to make sure that they will not be used. Also, if the orders
that were in `to_own` state are taken by their rightful owners with
the voucher codes, we make sure to unenroll them from the course
runs. Otherwise, if the batch order was not yet in `completed` state,
which means that no voucher nor orders were generated, we can just
mark the batch order as canceled.

Fix #1083
The batch order admin viewset allows to create, read, list
and cancel a batch order. It does not allow to update the
resource.
When running tests locally, if COURSE_WEB_HOOKS is defined,
the synchronization is triggered when running tests,
slowing them drastically.
We want our orders that are already paid that were generated
by a batch order to be accounted as seats taken on an order
group if one has been setted on the batch order at their
creation. The property available_seats on the order group
did not count the orders in state `to_own`, we have changed
this behavior to take them in account with the binding states
orders. This allows us to keep track of orders that are related
to the order group, thus knowing exactly how many seats left
are remaining.
Some of our users will want to receive a quote before proceeding
to the confirmation of their batch order. In fact, some companies
work with quotes and they don't pay with the credit card or
with a simple SEPA bank transfer. They usually use another platform
and they needs to have the quote of the batch order to generate
it on their side. For this needs, we have a create a model that
allows us to generate on demande quote for a batch order where
it regroups all the essential informations, with estimates prices,
and the content of the product into the active language.
When the batch order is related to a quote, it means
that the payment will occur outside our payment backend.
It's a new method of payment for companies. This action
will demand a manual validation from our admin users
once the organization has confirmed that it has published
the purchase order from the quote received.
Once this step is validated, the batch order can transition
to completed.
@jonathanreveille jonathanreveille changed the base branch from main to development May 22, 2025 16:11
@jonathanreveille jonathanreveille changed the title ✨(backend) BatchOrderQuote model to prepare quotes for companies ✨(backend) BatchOrderQuote model to prepare quotes for companies May 22, 2025
@jonathanreveille jonathanreveille self-assigned this May 22, 2025
@jonathanreveille jonathanreveille changed the title ✨(backend) BatchOrderQuote model to prepare quotes for companies ✨(backend) BatchOrderQuote model to prepare quotes for companies batch orders May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants