How to capture provider offering currency values #9

Closed
opened 2026-08-27 05:42:36 +00:00 by Xeplosion · 0 comments
Owner

What's the question or topic?

Should currency move off the provider level to model providers that
display different currencies per region/product line?

Context / background

Currently currency is a single required field on provider (schema
Convention C) — every price in the file is assumed to be in one currency.
But price_entry already carries region_id per price, so a provider
selling in multiple regions can already vary price by region without being
able to vary currency by region. Today's documented workaround
(docs/capture-guide.md) is: capture in the primary storefront currency and
log the multi-currency display as a quirk.

Decision so far: leave this unchanged for now. Nothing is broken — the quirk
workaround covers it — and fixing it properly touches a lot of surface area
(schema version bump, migrating providers/*.json, capture-form UI, docs,
tests). Revisit only if this becomes a recurring problem in practice.

Options or approaches considered

Option A — currency on product_line: fixes providers where different
product LINES use different currencies. Doesn't fully fix a single product
line whose own prices span multiple currency regions.

Option B — currency on price_entry, alongside the existing region_id: fully
general, handles a single product line priced in EUR for REG-EU and USD for
REG-US simultaneously. More verbose (currency repeated per price line) but
matches the granularity region_id already committed to.

Leaning toward B if/when this gets picked up, since A risks needing this
exact conversation again for a line that spans regions.

Checklist

  • I have searched for existing issues or discussions on this topic
  • This is a question or discussion, not a bug or feature request
### What's the question or topic? Should `currency` move off the provider level to model providers that display different currencies per region/product line? ### Context / background Currently `currency` is a single required field on `provider` (schema Convention C) — every price in the file is assumed to be in one currency. But `price_entry` already carries `region_id` per price, so a provider selling in multiple regions can already vary price by region without being able to vary currency by region. Today's documented workaround (docs/capture-guide.md) is: capture in the primary storefront currency and log the multi-currency display as a quirk. Decision so far: leave this unchanged for now. Nothing is broken — the quirk workaround covers it — and fixing it properly touches a lot of surface area (schema version bump, migrating providers/*.json, capture-form UI, docs, tests). Revisit only if this becomes a recurring problem in practice. ### Options or approaches considered Option A — currency on product_line: fixes providers where different product LINES use different currencies. Doesn't fully fix a single product line whose own prices span multiple currency regions. Option B — currency on price_entry, alongside the existing region_id: fully general, handles a single product line priced in EUR for REG-EU and USD for REG-US simultaneously. More verbose (currency repeated per price line) but matches the granularity region_id already committed to. Leaning toward B if/when this gets picked up, since A risks needing this exact conversation again for a line that spans regions. ### Checklist - [x] I have searched for existing issues or discussions on this topic - [x] This is a question or discussion, not a bug or feature request
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
XeplosionGames/minecraft-provider-analysis#9
No description provided.