Skip to content
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

docs: add ADR for fixed USD pricing #4395

Merged
merged 1 commit into from
Jul 30, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions docs/decisions/0028-fixed-usd-pricing.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
28. Fixed USD Pricing
========================

Status
--------
Accepted (Jul 2024)

Context
---------
Course Discovery is equipped with the capability to ingest and update courses from external sources (through the csv_loader).
These external courses may be priced in various currencies, necessitating conversion to a standardized currency (USD) before
their introduction into discovery. Given the volatility of exchange rates, the product prices coming into discovery may fluctuate with
each data ingestion.

The regular fluctuation in prices poses challenges for customers, especially those purchasing courses in bulk (B2B). These fluctuations can lead to
situations where a customer plans to make a purchase within budget, only to find that prices have changed unfavorably when
they proceed with the transaction. This inconsistency may disrupt budgetary planning and affect decision-making processes for
customers. This is particularly problematic for B2B customers, who may have predefined contracts and can not exceed their budget constraints.

Decision
----------
A new field, fixed_price_usd, will be introduced to the course run model within Course Discovery. This field will be accessible
through the standard course and search APIs. Consumers will have the ability to retrieve and utilize this field from Discovery APIs,
enabling them to price their offerings based on this stable fixed price in USD. It is assumed that the fixed price will remain
relatively stable over time, minimizing the impact of currency fluctuations for B2B customers.

The existing pricing fields and their associated logic will remain unchanged within Course Discovery. It will be the responsibility
of consumers, such as enterprise, to appropriately manage any potential implications of using the fixed price field within their own
systems and processes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it worth mentioning that this field is specific to course runs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding to that, given the pricing SoT is Entitlement, we might want to add here why the field is not on Course level.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it worth mentioning that this field is specific to course runs?

At line 22, I have mentioned that the field will be added to CourseRun model.

we might want to add here why the field is not on Course level

Can you suggest a sentence or two here? My understanding is that in the "SoT is Entitlement" model, it surely could have been. It is just that our business needs necessitate run level "pricing". I don't understand why the SoT was chosen to be the Course level in the first place.

Copy link
Contributor

@DawoudSheraz DawoudSheraz Jul 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it surely could have been. It is just that our business needs necessitate run level "pricing".

Rather than saying "our" business needs, we can mention that ability to have prices different on course runs was not directly allowed and we needed to use coupons in e-commerce to change pricing for runs, etc. I understand not all context might be relevant here but considering how the price flow is currently, the information would be helpful in future for others learning more about this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added some context to this effect^ in the Alternatives section.


Consequences
--------------
- The current Pricing flow in Discovery will remain as is.
- There will be no impact on Seats, Entitlements, and their associated logic.
- The current flow of propagation of pricing information to Ecommerce will remain as is.
- Analytics/Data teams will need to ensure that they track Enterprise Customers' purchases against the fixed price appropriately.

Alternatives Considered
-------------------------

- It would have been preferable to add this field at the Seat level somehow, and not clutter the CourseRun model unnecessarily.
However, due to some historical reasons, Executive Education courses (for which we need this functionality), only have unpaid
seats. It would be confusing to add pricing information to an unpaid seat.

- The field could have been integrated at the course level, aligning with the current discovery flows where the course price (CourseEntitlement)
is applied to all course runs. However, this approach does not accommodate pricing at the course run level, which has been a significant
issue for discovery users in the past. Although there are some workarounds, such as manually adjusting prices in the database, these solutions
are both cumbersome and inefficient.
Loading