Name the language, amount, rate, and authority first
A UI dictionary, translation JSON, currency symbol, provider fetch, or accepted checkout does not prove language completeness, approved fallback, the correct rate, settlement, posting, revaluation, or consolidation.
Short answer
Separate language, currency, rate, conversion, and accounting authority
Open Mercato provides reviewed foundations for interface locales, entity translations, currency masters, dated directional rates, and selected transaction-currency consumers. A buyer still needs explicit policy, ownership, implementation, integration, and external accounting acceptance for the complete operating model.
- Do not treat interface locale as translated business content.
- Do not treat stored rates as approved conversion or accounting policy.
- Stop when source, date, direction, rounding, owner, or acceptance evidence is unknown.
Open the complete technical evidence and planning pack17 evidence sections
Direct answer: separate five international-operation records
Reviewed Open Mercato has available and configurable foundations for four interface locales, scoped entity translations, currency masters, dated directional rates, and selected transaction-currency consumers. This reviewed foundation does not include complete language coverage, translation governance, recurring scheduled rate fetching, universal conversion, accounting posting, revaluation, gains or losses, or consolidation. Assign policy, custom work, integration, and external accounting acceptance per record.
| Record | Business question | Current evidence | System of record | Owner | State | Acceptance | Stop |
|---|---|---|---|---|---|---|---|
| Language requirement | Who reads which interface, content, document, or message? | Four fixed UI locales plus separately configured content locales | Approved market and channel language policy | Product and localization owner | configurable | Surface-by-surface language test | Required UI locale or fallback is unsupported |
| Content and translation record | Which fields need which locale, state, and approval? | Scoped JSON translation records and finite declarations | Base entity plus governed translation register | Content owner and linguistic reviewer | available | Completeness, overlay, lifecycle, and deletion tests | No source owner, approval, or downstream consumption proof |
| Currency and amount record | What is the transaction, functional, and presentation currency? | Scoped currency master and selected currency fields | Commercial document or accounting system by use case | Commercial and finance owners | available | Precision, base invariant, freeze, and reconciliation tests | No base owner, effective date, or amount authority |
| Exchange-rate record | Which source, date, direction, type, and selected value apply? | Directional dated rates, providers, fallback, and all-result lookup | Approved application or accounting rate policy | Treasury, tax, or accounting policy owner | configurable | Direction, date, correction, selection, and failure tests | Rate policy, legal fitness, or continuity is unapproved |
| Accounting and reporting result | Who posts, revalues, consolidates, and approves the result? | No reviewed universal accounting or consolidation path | External accounting, tax, and governed BI systems | Finance controller and statutory owner | integration-required | Posting, settlement, revaluation, close, and audit evidence | Journal or consolidation owner and evidence are absent |
Keep interface locale, entity or content locale, customer or document language, transaction currency, base or functional currency, reporting currency, rate evidence, converted amount, and posted amount separate in every decision.
Evidence snapshot and classification
Product source reviewed: branch develop · 01911d00e28f44cf484d0b1d04860dcfef5370bf · v0.6.5-1202-g01911d00e · latest reviewed public tag v0.6.5 · source and page review 2026-07-14. The default application enables translations and currencies. Public v0.4.4 introduced entity translations. The local 0.6.6 changelog heading is not among the reviewed public tags.
Post-tag behavior is current develop. Documentation records documented behavior. It does not prove runtime behavior. Architecture instructions describe intended changes. They do not prove shipped outcomes. An evidence gap does not create a fifth capability state.
- available
- configurable
- custom
- integration-required
- latest public release
- current develop
- current first-party documentation
- specification or instruction
- external primary requirement
- editorial recommendation
Plain-language glossary
- Interface locale
- language of application labels and messages
- Content locale
- language requested for selected entity fields
- Customer or document language
- approved language of a customer-facing artifact
- Transaction currency
- currency in which a commercial amount is agreed
- Base or functional currency
- primary currency chosen for an organization or ledger
- Reporting or presentation currency
- currency used to present a report
- Rate direction
- ordered from-currency and to-currency pair
- Buy or sell type
- bank quotation type, separate from arithmetic direction
- Converted amount
- calculated amount with retained conversion evidence
- Posted amount
- amount accepted into an accounting journal
Interface language and content locale are different controls
On 2026-07-14 the fixed UI locale registry contains exactly en, pl, es, and de; en is default. OM_FORCE_LOCALE can pin one supported interface locale and hide switching. It does not translate entity content. Reviewed evidence does not show complete and linguistically reviewed coverage across core, custom, email, provider, portal, export, and generated surfaces.
The supported-content-locale setting is tenant-scoped and separate. Its reviewed API accepts 1 to 50 two-letter ISO 639-1 locale codes. It provides no regional-locale or universal language support.
Translation record, declaration, and overlay boundaries
A translation record identifies entity type and id, tenant, optional organization, a JSON payload, timestamps, and scoped uniqueness. Validation permits up to 50 locale maps; a locale key is 2 to 10 characters, a field name is 1 to 100 characters, and a value is null or a string of at most 10,000 characters. Save replaces the full JSON document.
| Area | Representative records | Exact representative fields |
|---|---|---|
| Catalog | product, variant, offer, option schema, category, tag | title, subtitle, description, seoTitle, seoDescription, name, label |
| Dictionaries | dictionary entry | label |
| Custom-field definitions | custom field definition | label, description |
| Resources | resource, resource type | name, description |
| Staff | staff team member | display_name, description |
| Customer roles | customer role | name, description |
| Checkout | link and template surfaces | name, title, subtitle, description, success/cancel/error titles and messages, email subject and body |
Enabled modules contribute declarations at build time, while selected core declarations are also registered manually. A declaration proves only addressability. Test every route, page, export, document, email, custom field, and integration for overlay coverage, completeness, and extension ownership.
Current overlay selection priority is query locale, x-locale header, locale cookie, then applicable Accept-Language resolution. Test each route because validation can differ among these paths. The overlay uses the exact locale map, changes only keys already present on the base record and only with non-null and non-undefined values, and may add _locale and _translated markers. Base values remain when no overlay applies. Reviewed evidence contains no fr-CA to fr to en or other regional/source hierarchy. Base retention is not an approved business fallback without a policy.
Translation lifecycle and completeness are operating responsibilities
Assign owner, state, evidence, entry and exit criteria, rollback, and downstream verification.
- 1
Source creation and ownership
- 2
Translation request
- 3
Draft
- 4
Linguistic review
- 5
Business or legal review where required
- 6
Approval
- 7
Publication
- 8
Change detection
- 9
Retranslation
- 10
Rollback
- 11
Retirement
The reviewed core provides none of the following workflow controls:
- Review state
- Approval state
- Publication state
- Completeness scoring
- Terminology management
- Translation memory
- Machine translation
- Vendor handoff
- XLIFF or PO exchange
- Retranslation scheduling
Use these editorial workflow states only in the completeness matrix. Product enums remain separate:
- not required
- missing
- draft
- reviewed
- approved
- published
- stale
| Entity | Surface | Source locale | pl | de | Owner | Acceptance |
|---|---|---|---|---|---|---|
| Product identity | Catalog list and detail | published | reviewed | missing | Catalog content owner | Declared-field and rendered-overlay test |
| Checkout template | Customer screen and email | published | draft | not required | Checkout journey owner | Screen, failure-message, and email test |
| Resource type | Backoffice selection | approved | stale | not required | Resource steward | Change detection and retranslation |
| Customer role | Portal account surface | published | missing | missing | Portal content owner | Missing-content stop and route consumption test |
Full-document replacement makes stale payload and field preservation tests essential for concurrent editors. Current develop provides a scoped lookup and upsert transaction, command history and undo, events, a mutation guard, and optional optimistic locking when a version is supplied. Current command history and undo do not roll back external effects. Current route validation does not show that every submitted field is registered or every host record exists before storage. Test orphan detection, field drift, delete cleanup through query-index coupling, restore, and index rebuild.
Translation access and segregation of duties
Current feature ids are translations.view, translations.manage, and translations.manage_locales. Seed defaults grant translations.* to admin and grant view plus manage to employee. Use these defaults as review input. Seed defaults do not define a production role design.
Assign responsible and accountable roles, separation, backup, evidence, prohibited combinations, and emergency authority.
- 1. Locale administration
- 2. Source-content ownership
- 3. Translation editing
- 4. Linguistic review
- 5. Business or legal approval
- 6. Publication
- 7. Emergency rollback
- 8. Audit review
Currency master, base invariant, and precision
The scoped currency master stores code, name, symbol, decimalPlaces, decimal and thousands separators, base and active flags, timestamps, and soft deletion. Validation accepts three uppercase characters. Three uppercase characters do not establish ISO 4217 membership. Refresh reference data and approve the standard boundary.
Setting one currency as base atomically demotes other active bases, and deleting a base is blocked. Current source can unset the base flag and the reviewed database does not prove exactly one base per scope. Ten seed examples include USD, EUR, JPY, GBP, CHF, CAD, AUD, CNY, CNH, and PLN. USD is only the seed base example. The seed list does not define production inventory or recommend a base currency. Assign functional-currency owner, effective date, historical-data rule, migration, immutability, and an invariant test.
| Layer | Reviewed evidence | Required decision |
|---|---|---|
| Currency display decimals | decimalPlaces 0 to 8 | Formatting only until each consumer is tested |
| Representative sales amounts | numeric(18,4) | Storage and calculation policy |
| Exchange rate | numeric(18,8) | Direction, rounding, retained raw value |
| Pricing and tax | No universal rule established | Jurisdiction and document policy |
| Gateway minor units | Provider-specific | Gateway contract and acceptance |
| Accounting posting | External boundary | Ledger precision and close policy |
| Report and export | Consumer-specific | Presentation plus reconciliation |
Display decimal configuration does not by itself change every stored amount, calculation, tax, gateway, accounting, or export precision.
Exchange-rate record and evidence chain
A rate record has a directional currency pair, numeric(18,8) rate, requested or effective timestamp, required source, optional buy or sell type, active state, tenant and optional organization scope, timestamps, and soft deletion. The service can perform exact-date lookup, previous-day fallback within a configurable limit, optional fetch-on-miss, return all matching rows, and expose per-pair batch errors. Returning rows does not select the authoritative source or type.
Retain this value with the conversion decision and downstream join.
- 1. Requested date
- 2. Actual fallback date
- 3. Source
- 4. Provider response identifier where available
- 5. From and to direction
- 6. Buy or sell type
- 7. Raw value
- 8. Selected value
- 9. Selection rationale
- 10. Use case and approver
- 11. Downstream record
Synthetic direction test: if one EUR costs 4.25 PLN, EUR to PLN uses 4.25 and PLN to EUR uses its reciprocal, subject to approved rounding. Bank buy or sell type remains separate from direction and from the tax or accounting basis selected by the organization.
Provider matrix and external acceptance
| Provider | Registration | Base | Direction and type | Invocation | Configuration effect | Scheduling evidence | Validation owner |
|---|---|---|---|---|---|---|---|
| NBP | Yes, current develop | PLN | Official Table C bid/ask mapped to directional buy/sell records | Manual API/CLI or service fetch | Row may store enablement and sync time; service does not read it | No consuming worker found | Accounting/tax owner validates fitness |
| Raiffeisen Bank Polska | Yes, current develop | PLN | External bank endpoint mapped to directional buy/sell records | Manual API/CLI or service fetch | Same configuration boundary | No consuming worker found | Contract, terms, continuity, and legal owner |
| Custom | Accepted configuration value; no reviewed provider implementation registered | not established | Custom implementation responsibility | Custom | Value alone does not create behavior | Not established | Implementation and external-validation owner |
NBP is an official API source and the reviewed provider maps Table C bid and ask values around PLN. The reviewed provider does not prove statutory fitness for a buyer. Raiffeisen uses an external bank endpoint; no SLA, contract, permanence, or tax/accounting authority is implied. Both providers persist pairs only for currencies that already exist and are active in scope. Provider availability, terms, semantics, holidays, corrections, continuity, network behavior, and legal or accounting fitness require external acceptance.
Configuration does not create scheduled fetching
Current fetch configuration stores isEnabled and nominal syncTime, and the UI offers toggles and fetch now. No reviewed non-test currency scheduler or worker consuming syncTime was found. RateFetchingService does not read fetch-config enablement and defaults to every registered provider when no provider list is supplied. ExchangeRateService auto-fetch currently invokes it without an explicit provider list. Disabling a provider in configuration does not block service-level auto-fetch.
Current Open Mercato project currency documentation uses broader automatic and scheduled wording than the inspected runtime. Treat it as documentation evidence and keep the runtime boundary above until implementation and tests prove recurring behavior.
Manual UI or API fetch
Explicit request; validate access, date, provider selection, errors, and persisted rows.
CLI fetch
Operator-invoked path; it is not recurring automation.
Service auto-fetch on miss
ExchangeRateService may call fetching without a provider list; RateFetchingService then defaults to all registered providers.
Recurring scheduled fetch
Not established: no reviewed non-test currency scheduler or worker consumes syncTime.
A production recurring design needs timezone, market calendar and holiday policy, retries, timeout, concurrency, idempotency, alerting, last-good-rate behavior, corrections, and backfill.
Selective consumers do not prove universal conversion
CRM deal summary and aggregate are one selective consumer: they convert toward a configured base currency with auto-fetch disabled and disclose missing or partial conversion. The rate lookup can return multiple rows, so source and type selection remains application or business policy. These consumers do not prove conversion in catalog, quotes, orders, invoices, credits, payments, checkout, shipping, reports, exports or integrations.
Sales records carry currency fields and an order may store an optional supplied exchangeRate. Supplied input is neither frozen as evidence nor converted automatically. Current reviewed quote-to-order conversion sets the order exchangeRate to null, so acceptance must decide when and how a rate is captured and frozen. Checkout validates gateway-supported currency and persists transaction currency. Checkout validation does not prove settlement conversion or accounting posting.
| Record | Amount meaning | Authority |
|---|---|---|
| Quote | Quoted transaction amount | Sales guide and quote record |
| Order | Order currency plus optional supplied exchangeRate | Sales order |
| Invoice | Document currency and statutory result | Sales document plus accounting owner |
| Credit memo | Credit and reference amounts | Sales and accounting policy |
| Payment | Received or recorded amount | Sales payment record |
| Allocation | Applied amount | Receivable allocation owner |
| Checkout transaction | Gateway-accepted transaction currency | Checkout and gateway |
| Settlement | Provider settlement amount and fees | Provider and reconciliation ledger |
| Accounting journal | Posted functional and reporting result | External accounting system |
No reviewed universal path proves dual transaction and base amounts, automatic revaluation, realized or unrealized FX gains and losses, journals, consolidation, or statutory rate selection. The currencies module AGENTS instructions describe architecture and change rules for date-based rates, transaction and base amounts, realized gains or losses, and atomic posting. They do not prove shipped product behavior. External accounting and tax owners must approve rate source, type, date, rounding, posting, revaluation, settlement, correction, and retention.
Poor fit and early stop signals
- Unsupported interface locale or regional-locale hierarchy: keep the specialist authority or prove custom integration and acceptance.
- Turnkey translation-management lifecycle: keep the specialist authority or prove custom integration and acceptance.
- Proof every surface consumes translations: keep the specialist authority or prove custom integration and acceptance.
- Statutory rate automation without external acceptance: keep the specialist authority or prove custom integration and acceptance.
- Universal dual-currency posting: keep the specialist authority or prove custom integration and acceptance.
- Automatic revaluation and realized or unrealized FX gains and losses: keep the specialist authority or prove custom integration and acceptance.
- Group consolidation: keep the specialist authority or prove custom integration and acceptance.
- Universal tax and accounting compliance: keep the specialist authority or prove custom integration and acceptance.
Record evidence, owner, threshold, exception, recovery, and mandatory stop. Unknown means stop.
- 1. Required locale coverage
- 2. Source and translation ownership
- 3. Completeness and publication policy
- 4. Base currency invariant
- 5. Currency and precision policy
- 6. Rate source, date, direction, and type
- 7. Provider continuity and legal fitness
- 8. Scheduler and fetch gating
- 9. Document rate capture and freeze
- 10. Settlement and accounting handoff
- 11. Scope isolation
- 12. Recovery, correction, close, and audit
Three synthetic cross-border scenarios
Every scenario names transaction, base or functional, and reporting or presentation currency separately; use same or not applicable only when true.
Hypothetical only
1. Synthetic two-market multilingual catalog
Three-currency model: transaction: not applicable; functional: not applicable; presentation: not applicable.
- Normal flow
- Source content is translated, reviewed, approved, published, and consumed on tested surfaces.
- Edge
- A declared field is intentionally not required in one locale.
- Failure
- Missing translation silently retains a base value or a surface ignores the overlay.
- Recovery
- Block publication, assign owner, repair and repeat route-specific consumption tests.
- Owner
- Content, market, linguistic, and release owners
- Evidence
- Completeness matrix, approval, screenshots, and downstream assertions
- Conclusion
- conditional
Hypothetical only
2. Synthetic Polish organization selling in PLN and EUR
Three-currency model: transaction: PLN or EUR; functional: PLN; presentation: PLN or EUR.
- Normal flow
- Approved NBP policy selects source, date, direction and type; documents and settlement reconcile.
- Edge
- Weekend lookup uses an accepted prior actual date within the configured limit.
- Failure
- Checkout accepts EUR but invoice, payment, settlement, or posting cannot be reconciled.
- Recovery
- Stop posting, retain raw evidence, correct policy or rate and replay governed reconciliation.
- Owner
- Finance controller, sales owner, gateway owner, and accountant
- Evidence
- Requested and actual dates, provider row, selected rate, documents, settlement, journal handoff
- Conclusion
- conditional
Hypothetical only
3. Synthetic international multi-organization estate
Three-currency model: transaction: organization-specific; functional: organization-specific; presentation: group reporting currency.
- Normal flow
- Each organization owns scoped locales, currencies and rates; external accounting owns group reporting.
- Edge
- Transaction, functional and group presentation currencies are all different.
- Failure
- A rate or locale leaks across scope, or group consolidation is assumed inside Open Mercato.
- Recovery
- Stop close, isolate records, reconcile affected periods and restore through the external authority.
- Owner
- Local controllers, group finance, platform owner, and auditors
- Evidence
- Scope tests, currency invariants, consolidation joins, close and audit evidence
- Conclusion
- no-go until consolidation is owned
Local planning tool
Language and money decision register
Starts empty, accepts abstract planning labels only, and stays browser-local. Use it to plan evidence. The register does not grant linguistic, tax, accounting, provider, settlement, compliance or go-live approval.
Do not enter real data: Never enter real customer, product, document, amount, rate, tax treatment, credential, contract, incident, personal data, provider response, or production configuration. Reset before using a shared device.
Privacy: The page does not send worksheet content, put it in the URL, or store it in cookies.
Acceptance pack and mandatory stops
Specify setup, abstract record, expected state, prohibited outcome, evidence, owner, recovery, and pass criterion.
- 1. Fixed UI locale set and default
- 2. Forced locale
- 3. UI dictionary completeness
- 4. Content-locale scope
- 5. Content-locale bounds
- 6. Translation payload bounds
- 7. Scoped uniqueness
- 8. Declared catalog fields
- 9. Declared non-catalog fields
- 10. Build-time declaration collection
- 11. Query locale priority
- 12. Header locale priority
- 13. Cookie locale priority
- 14. Accept-Language behavior
- 15. Exact-locale overlay
- 16. Base retention
- 17. Null translation
- 18. Overlay markers
- 19. No regional hierarchy
- 20. Full-document replacement
- 21. Concurrent stale editor
- 22. Optional optimistic lock
- 23. Command history and undo
- 24. Mutation guard
- 25. Orphan detection
- 26. Field drift
- 27. Delete cleanup
- 28. Restore and reindex
- 29. Translation ACL
- 30. Segregation of duties
- 31. Currency code boundary
- 32. Currency precision
- 33. Exactly one base invariant
- 34. Base change migration
- 35. Base delete block
- 36. Rate requested and actual date
- 37. Rate direction
- 38. Reciprocal inversion
- 39. Buy and sell separation
- 40. All matching rates
- 41. Fallback limit
- 42. Per-pair batch errors
- 43. Active scoped currency prerequisite
- 44. NBP mapping
- 45. Raiffeisen mapping
- 46. Custom provider absence
- 47. Manual API fetch
- 48. CLI fetch
- 49. Auto-fetch provider list
- 50. No recurring scheduler
- 51. Provider correction
- 52. CRM partial conversion
- 53. Order rate input
- 54. Quote-to-order null rate
- 55. Checkout currency acceptance
- 56. Settlement reconciliation
- 57. Accounting handoff
- 58. Cross-scope isolation
- 59. Register privacy
- 60. No-JavaScript and print
- Stop when a required interface locale or fallback hierarchy is not supported.
- Stop publication when source, reviewer, approval, completeness, or downstream evidence is missing.
- Stop currency migration when functional-currency owner, effective date, historical rule, or exactly-one invariant is absent.
- Stop conversion when source, date, direction, type, selection, rounding, or correction policy is unapproved.
- Stop recurring automation when schedule, gating, holiday, retry, alert, backfill, and last-good-rate behavior are not implemented and tested.
- Stop financial close when settlement, journal, revaluation, consolidation, or statutory owner and evidence are missing.
Practical questions
Is missing content automatically translated?
Interface translations and business-content translations are separate. A fallback can display another language; it does not create or approve a translation. Assign an owner to required market content.
Is the seeded USD base currency a recommendation?
USD is a seed example. Select the base currency for your business and verify that exactly one intended base exists in the relevant scope before calculating conversions.
Are exchange rates fetched automatically every day?
A configured synchronization time alone does not establish a running scheduler in the reviewed source. Verify the actual job, enabled provider, requested date, fallback date and failure alert.
Does checkout conversion prove financial settlement?
Checkout conversion calculates an amount for that journey. Define settlement currency, provider fees, exchange differences and accounting entries, then reconcile them with the responsible system.
Contextual evidence and correction path
Claim, capability state, evidence label, date or immutable revision, limitation, confidence, external acceptance, and review owner recorded.
- 1. Open Mercato v0.6.5 public release
- 2. Pinned UI locale configuration and endpoint
- 3. Pinned translations module and declarations
- 4. Pinned currencies module entities and services
- 5. Pinned NBP provider implementation
- 6. Pinned Raiffeisen provider implementation
- 7. Pinned sales currency consumers
- 8. Pinned CRM conversion consumers
- 9. Pinned checkout currency path
- 10. Current first-party currency documentation
- 11. NBP Web API documentation
- 12. ISO 4217 reference
- 13. Catalog canonical guide
- 14. Sales, payments, and reporting canonical guides
Latest reviewed public release · Immutable translations source · Immutable currencies source · NBP Web API · ISO 4217
The evidence refresh compared runtime, tests, Open Mercato project docs, release labels, NBP and ISO references, and English and Polish search expectations on 2026-07-14. Report corrections with the exact claim, replacement primary evidence, affected revision, operating impact, and owner.