Najpierw nazwij język, kwotę, kurs i autorytet
Słownik UI, JSON tłumaczenia, symbol waluty, fetch providera ani accepted checkout nie dowodzą kompletności językowej, zatwierdzonego fallbacku, właściwego kursu, settlementu, księgowania, revaluation lub consolidation.
Krótka odpowiedź
Rozdziel język, walutę, kurs, konwersję i autorytet księgowy
Open Mercato zapewnia sprawdzone fundamenty locale interfejsu, tłumaczeń encji, kartotek walut, datowanych kursów kierunkowych i wybranych consumerów waluty transakcji. Kupujący nadal potrzebuje jawnej polityki, odpowiedzialności, implementacji, integracji i zewnętrznego odbioru księgowego dla kompletnego modelu operacyjnego.
- Nie traktuj locale interfejsu jako przetłumaczonego contentu biznesowego.
- Nie traktuj zapisanych kursów jako zatwierdzonej polityki konwersji lub księgowania.
- Zatrzymaj decyzję, gdy źródło, data, kierunek, zaokrąglenie, owner lub dowód odbioru są nieznane.
Otwórz pełny pakiet dowodów technicznych i planowania17 sekcji dowodowych
Odpowiedź: rozdziel pięć rekordów operacji międzynarodowej
Sprawdzone Open Mercato ma fundamenty available i configurable dla czterech locale interfejsu, zakresowych tłumaczeń encji, kartotek walut, datowanych kursów kierunkowych i wybranych consumerów waluty transakcji. Ten sprawdzony fundament nie obejmuje kompletnego pokrycia językowego, ładu tłumaczeń, cyklicznego pobierania kursów, uniwersalnej konwersji, księgowania, przeszacowania, zysków lub strat ani konsolidacji. Dla każdego rekordu przypisz politykę, custom work, integrację i zewnętrzne acceptance księgowości.
| Rekord | Pytanie biznesowe | Bieżący dowód | System źródłowy | Właściciel | Stan | Odbiór | Stop |
|---|---|---|---|---|---|---|---|
| Wymaganie językowe | Kto czyta jaki interfejs, content, dokument lub komunikat? | Cztery stałe locale UI oraz osobno konfigurowane locale contentu | Zatwierdzona polityka języka rynku i kanału | Właściciel produktu i lokalizacji | configurable | Test języka dla każdej powierzchni | Wymagane locale UI lub fallback nie są obsługiwane |
| Rekord contentu i tłumaczenia | Które pola wymagają jakiego locale, stanu i zatwierdzenia? | Zakresowe rekordy JSON tłumaczeń i skończone deklaracje | Encja bazowa i zarządzany rejestr tłumaczeń | Właściciel contentu i reviewer językowy | available | Testy kompletności, overlay, cyklu i usunięcia | Brak właściciela źródła, approval lub dowodu użycia downstream |
| Rekord waluty i kwoty | Jaka jest waluta transakcji, funkcjonalna i prezentacyjna? | Zakresowa kartoteka walut i wybrane pola currency | Dokument handlowy lub system księgowy zależnie od użycia | Właściciele sprzedaży i finansów | available | Testy precyzji, invariant base, zamrożenia i uzgodnienia | Brak właściciela base, daty wejścia lub autorytetu kwoty |
| Rekord kursu walutowego | Jakie źródło, data, kierunek, typ i wybrana wartość obowiązują? | Kierunkowe datowane kursy, providerzy, fallback i lookup wszystkich wyników | Zatwierdzona polityka kursowa aplikacji lub księgowości | Właściciel polityki treasury, tax lub accounting | configurable | Testy kierunku, daty, korekty, wyboru i awarii | Polityka kursu, legal fitness lub ciągłość niezatwierdzone |
| Wynik księgowy i raportowy | Kto księguje, przeszacowuje, konsoliduje i zatwierdza wynik? | Brak sprawdzonej uniwersalnej ścieżki księgowej lub konsolidacji | Zewnętrzne systemy accounting, tax i governed BI | Kontroler finansowy i właściciel statutory | integration-required | Dowody księgowania, settlement, revaluation, close i audytu | Brak właściciela i dowodu journal lub consolidation |
W każdej decyzji oddziel locale interfejsu, locale encji lub contentu, język klienta lub dokumentu, walutę transakcji, walutę bazową lub funkcjonalną, walutę raportową, dowód kursu, kwotę przeliczoną i kwotę zaksięgowaną.
Migawka dowodów i klasyfikacja
Sprawdzony kod produktu: branch develop · 01911d00e28f44cf484d0b1d04860dcfef5370bf · v0.6.5-1202-g01911d00e · najnowszy sprawdzony tag publiczny v0.6.5 · przegląd źródła i strony 2026-07-14. Aplikacja default włącza translations i currencies. Publiczne v0.4.4 wprowadziło tłumaczenia encji. Lokalnego headingu changelog 0.6.6 nie ma wśród sprawdzonych tagów publicznych.
Zachowanie po tagu ma etykietę current develop. Dokumentacja opisuje udokumentowane zachowanie. Nie dowodzi zachowania runtime. Instrukcje architektoniczne opisują zamierzone zmiany. Nie dowodzą wydanych rezultatów. Luka dowodowa nie tworzy piątego stanu możliwości.
- available
- configurable
- custom
- integration-required
- latest public release
- current develop
- current first-party documentation
- specification or instruction
- external primary requirement
- editorial recommendation
Słownik prostym językiem
- Locale interfejsu
- język etykiet i komunikatów aplikacji
- Locale contentu
- język żądany dla wybranych pól encji
- Język klienta lub dokumentu
- zatwierdzony język artefaktu dla klienta
- Waluta transakcji
- waluta uzgodnienia kwoty handlowej
- Waluta bazowa lub funkcjonalna
- główna waluta organizacji lub rejestru
- Waluta raportowa lub prezentacyjna
- waluta prezentacji raportu
- Kierunek kursu
- uporządkowana para waluty źródłowej i docelowej
- Typ buy lub sell
- rodzaj notowania banku, odrębny od kierunku matematycznego
- Kwota przeliczona
- obliczona kwota z zachowanym dowodem konwersji
- Kwota zaksięgowana
- kwota przyjęta do journal księgowego
Język interfejsu i locale contentu to różne kontrole
14 lipca 2026 stały rejestr locale UI zawiera dokładnie en, pl, es i de; default to en. OM_FORCE_LOCALE może przypiąć jedno obsługiwane locale interfejsu i ukryć przełączanie. Nie tłumaczy contentu encji. Sprawdzone dowody nie potwierdzają kompletnego i językowo zweryfikowanego pokrycia powierzchni core, custom, email, provider, portal, export i generated.
Ustawienie obsługiwanych locale contentu jest tenant-scoped i osobne. Sprawdzony API przyjmuje od 1 do 50 dwuliterowych kodów locale ISO 639-1. Nie potwierdza obsługi locale regionalnych ani uniwersalnego wsparcia języków.
Granice rekordu tłumaczenia, deklaracji i overlay
Rekord tłumaczenia identyfikuje entity type i id, tenant, opcjonalną organization, payload JSON, timestamps i scoped uniqueness. Walidacja pozwala na maksymalnie 50 map locale; klucz locale ma od 2 do 10 znaków, nazwa pola od 1 do 100 znaków, a wartość jest null lub stringiem do 10 000 znaków. Save zastępuje cały dokument JSON.
| Obszar | Reprezentatywne rekordy | Dokładne reprezentatywne pola |
|---|---|---|
| Katalog | product, variant, offer, option schema, category, tag | title, subtitle, description, seoTitle, seoDescription, name, label |
| Słowniki | dictionary entry | label |
| Definicje pól własnych | custom field definition | label, description |
| Zasoby | resource, resource type | name, description |
| Pracownicy | staff team member | display_name, description |
| Role klientów | customer role | name, description |
| Checkout | link and template surfaces | name, title, subtitle, description, success/cancel/error titles and messages, email subject and body |
Włączone moduły dostarczają deklaracje w build time, a wybrane deklaracje core są również rejestrowane ręcznie. Deklaracja potwierdza tylko addressability. Przetestuj każdy route, page, export, document, email, custom field i integration pod kątem overlay, kompletności i ownership rozszerzeń.
Bieżący priorytet wyboru overlay to locale query, header x-locale, cookie locale, a potem właściwe rozwiązanie Accept-Language. Przetestuj każdą trasę, ponieważ walidacja może się różnić między tymi ścieżkami. Overlay używa dokładnej mapy locale, zmienia tylko klucze już obecne w rekordzie bazowym i tylko wartościami innymi niż null i undefined, a także może dodać markery _locale i _translated. Wartości bazowe pozostają, gdy overlay nie działa. Sprawdzone dowody nie potwierdzają hierarchii fr-CA do fr do en ani innej hierarchii regionalnej lub źródłowej. Bez polityki zachowanie bazy nie jest zatwierdzonym fallbackiem biznesowym.
Cykl tłumaczenia i kompletność są odpowiedzialnością operacyjną
Przypisz ownera, stan, dowód, kryteria wejścia i wyjścia, rollback i weryfikację downstream.
- 1
Utworzenie źródła i ownership
- 2
Zlecenie tłumaczenia
- 3
Draft
- 4
Review językowy
- 5
Review biznesowy lub prawny, gdy wymagany
- 6
Zatwierdzenie
- 7
Publikacja
- 8
Wykrycie zmiany
- 9
Ponowne tłumaczenie
- 10
Rollback
- 11
Wycofanie
Sprawdzony core nie zapewnia następujących kontroli workflow:
- Stan review
- Stan approval
- Stan publikacji
- Ocena kompletności
- Zarządzanie terminologią
- Pamięć tłumaczeniowa
- Tłumaczenie maszynowe
- Handoff do dostawcy
- Wymiana XLIFF lub PO
- Planowanie ponownego tłumaczenia
Używaj tych stanów editorial workflow wyłącznie w macierzy kompletności. Product enums pozostają osobną klasyfikacją:
- not required
- missing
- draft
- reviewed
- approved
- published
- stale
| Encja | Powierzchnia | Locale źródłowe | pl | de | Właściciel | Odbiór |
|---|---|---|---|---|---|---|
| Tożsamość produktu | Lista i detal katalogu | published | reviewed | missing | Właściciel contentu katalogu | Test deklarowanych pól i rendered overlay |
| Template checkout | Ekran klienta i email | published | draft | not required | Właściciel journey checkout | Test ekranu, failure message i email |
| Typ zasobu | Wybór backoffice | approved | stale | not required | Steward zasobów | Change detection i retranslation |
| Rola klienta | Powierzchnia konta portalu | published | missing | missing | Właściciel contentu portalu | Stop brakującego contentu i test użycia route |
Replacement całego dokumentu sprawia, że testy stale payload i zachowania pól są niezbędne dla współbieżnych edytorów. Current develop zapewnia scoped transaction lookup i upsert, command history i undo, events, mutation guard i opcjonalny optimistic lock, gdy podano version. Bieżące command history i undo nie wycofują efektów zewnętrznych. Bieżąca walidacja route nie potwierdza rejestracji każdego przesłanego pola ani istnienia każdego host record przed zapisem. Testuj wykrywanie orphan, field drift, cleanup po delete przez coupling query-index, restore i index rebuild.
Dostęp do tłumaczeń i segregation of duties
Bieżące feature ids to translations.view, translations.manage i translations.manage_locales. Seed defaults nadają translations.* roli admin, a view i manage roli employee. Użyj tych wartości domyślnych jako danych wejściowych do przeglądu. Domyślne granty nie definiują produkcyjnego modelu ról.
Przypisz role responsible i accountable, rozdział, zastępstwo, dowód, zabronione kombinacje i authority awaryjne.
- 1. Administracja locale
- 2. Ownership contentu źródłowego
- 3. Edycja tłumaczenia
- 4. Review językowy
- 5. Approval biznesowy lub prawny
- 6. Publikacja
- 7. Awaryjny rollback
- 8. Review audytowy
Kartoteka walut, invariant base i precyzja
Zakresowa kartoteka walut zapisuje code, name, symbol, decimalPlaces, separatory dziesiętne i tysięczne, flagi base i active, timestamps i soft deletion. Walidacja przyjmuje trzy wielkie litery. Trzy wielkie litery nie potwierdzają członkostwa w ISO 4217. Odśwież dane referencyjne i zatwierdź granicę standardu.
Ustawienie jednej waluty jako base atomowo demotuje inne aktywne base, a usunięcie base jest zablokowane. Bieżący kod może wyłączyć flagę base, a sprawdzona baza nie dowodzi dokładnie jednej base w zakresie. Dziesięć przykładów seed obejmuje USD, EUR, JPY, GBP, CHF, CAD, AUD, CNY, CNH i PLN. USD jest tylko przykładem seed base. Lista seed nie definiuje inwentarza produkcyjnego ani nie rekomenduje waluty bazowej. Przypisz ownera waluty funkcjonalnej, datę wejścia, regułę danych historycznych, migrację, immutability i test invariant.
| Warstwa | Sprawdzony dowód | Wymagana decyzja |
|---|---|---|
| Miejsca dziesiętne display | decimalPlaces od 0 do 8 | Tylko formatowanie do czasu testu każdego consumera |
| Reprezentatywne kwoty sales | numeric(18,4) | Polityka zapisu i obliczeń |
| Kurs walutowy | numeric(18,8) | Kierunek, rounding, zachowany raw value |
| Cena i podatek | Brak uniwersalnej reguły | Polityka jurysdykcji i dokumentu |
| Minor units bramki | Zależne od providera | Kontrakt i acceptance bramki |
| Księgowanie | Granica zewnętrzna | Precyzja rejestru i polityka close |
| Raport i eksport | Zależne od consumera | Prezentacja i uzgodnienie |
Konfiguracja miejsc dziesiętnych display nie zmienia sama z siebie precyzji każdej zapisanej kwoty, obliczenia, podatku, bramki, księgowości ani eksportu.
Rekord kursu i łańcuch dowodowy
Rekord kursu ma kierunkową parę walut, rate numeric(18,8), timestamp requested lub effective, wymagane source, opcjonalny typ buy lub sell, stan active, scope tenant i opcjonalnej organization, timestamps i soft deletion. Usługa może wykonać lookup exact-date, fallback na wcześniejszy dzień w konfigurowalnym limicie, opcjonalny fetch-on-miss, zwrócić wszystkie pasujące rekordy i ujawnić błędy batch per pair. Zwrócenie rekordów nie wybiera autorytatywnego źródła ani typu.
Zachowaj tę wartość z decyzją konwersji i joinem downstream.
- 1. Data żądana
- 2. Rzeczywista data fallback
- 3. Źródło
- 4. Id odpowiedzi providera, gdy dostępne
- 5. Kierunek from i to
- 6. Typ buy lub sell
- 7. Wartość raw
- 8. Wartość wybrana
- 9. Uzasadnienie wyboru
- 10. Use case i approver
- 11. Rekord downstream
Syntetyczny test kierunku: jeśli jedno EUR kosztuje 4,25 PLN, kierunek EUR do PLN używa 4,25, a PLN do EUR używa wartości reciprocal z zatwierdzonym rounding. Typ bankowy buy lub sell pozostaje odrębny od kierunku oraz od podstawy tax lub accounting wybranej przez organizację.
Macierz providerów i zewnętrzne acceptance
| Provider | Rejestracja | Base | Kierunek i typ | Wywołanie | Efekt konfiguracji | Dowód schedulingu | Właściciel walidacji |
|---|---|---|---|---|---|---|---|
| NBP | Tak, current develop | PLN | Oficjalna tabela C bid/ask mapowana do kierunkowych rekordów buy/sell | Ręczny API/CLI lub fetch usługi | Rekord może zapisać enablement i sync time; usługa go nie czyta | Nie znaleziono workera konsumującego | Właściciel accounting/tax zatwierdza fitness |
| Raiffeisen Bank Polska | Tak, current develop | PLN | Zewnętrzny endpoint banku mapowany do kierunkowych rekordów buy/sell | Ręczny API/CLI lub fetch usługi | Ta sama granica konfiguracji | Nie znaleziono workera konsumującego | Właściciel kontraktu, warunków, ciągłości i legal |
| Custom | Akceptowana wartość konfiguracji; brak sprawdzonej zarejestrowanej implementacji providera | not established | Odpowiedzialność własnej implementacji | Custom | Sama wartość nie tworzy zachowania | Niepotwierdzone | Właściciel implementacji i zewnętrznej walidacji |
NBP jest oficjalnym źródłem API, a sprawdzony provider mapuje wartości bid i ask tabeli C wokół PLN. Sprawdzony provider nie potwierdza przydatności do celów ustawowych dla kupującego. Raiffeisen używa zewnętrznego endpointu banku; nie oznacza SLA, kontraktu, trwałości ani authority tax lub accounting. Obaj providerzy zapisują pary tylko dla walut już istniejących i aktywnych w scope. Dostępność providera, warunki, semantyka, święta, korekty, ciągłość, zachowanie sieci i fitness legal lub accounting wymagają zewnętrznego acceptance.
Konfiguracja nie tworzy planowanego pobierania
Bieżąca konfiguracja fetch zapisuje isEnabled i nominalny syncTime, a UI udostępnia toggles i fetch now. Nie znaleziono sprawdzonego non-test schedulera ani workera currency konsumującego syncTime. RateFetchingService nie czyta enablement z fetch-config i domyślnie używa każdego zarejestrowanego providera, gdy nie podano listy. Auto-fetch ExchangeRateService wywołuje go obecnie bez jawnej listy providerów. Wyłączenie providera w konfiguracji nie blokuje service-level auto-fetch.
Bieżąca dokumentacja walut projektu Open Mercato używa szerszego słownictwa automatic i scheduled niż sprawdzony runtime. Traktuj ją jako dowód dokumentacji i zachowaj powyższą granicę runtime, dopóki implementacja i testy nie udowodnią zachowania cyklicznego.
Ręczny fetch z UI lub API
Jawne żądanie; sprawdź dostęp, datę, wybór providera, błędy i zapisane rekordy.
Fetch z CLI
Ścieżka wywoływana przez operatora; nie jest automatyzacją cykliczną.
Auto-fetch usługi przy braku
ExchangeRateService może wywołać fetching bez listy providerów; RateFetchingService domyślnie używa wtedy wszystkich zarejestrowanych providerów.
Cykliczny fetch planowany
Niepotwierdzone: żaden sprawdzony non-test scheduler lub worker currency nie konsumuje syncTime.
Produkcyjny model cykliczny wymaga timezone, polityki kalendarza rynku i świąt, retry, timeout, concurrency, idempotency, alertów, zachowania last-good-rate, korekt i backfill.
Selektywni konsumenci nie dowodzą uniwersalnej konwersji
CRM deal summary i aggregate są jednym selektywnym consumerem: konwertują do skonfigurowanej waluty base z wyłączonym auto-fetch i ujawniają brakującą lub częściową konwersję. Lookup kursu może zwrócić wiele rekordów, więc wybór source i type pozostaje polityką aplikacji lub biznesu. Te konsumery nie dowodzą konwersji w catalog, quotes, orders, invoices, credits, payments, checkout, shipping, reports, exports ani integrations.
Rekordy sales mają pola currency, a order może zapisać opcjonalny dostarczony exchangeRate. Dostarczony input nie jest automatycznie zamrażany jako dowód ani przeliczany. Sprawdzona konwersja quote-to-order ustawia exchangeRate order na null, więc acceptance musi określić, kiedy i jak kurs jest capture i freeze. Checkout waliduje walutę obsługiwaną przez bramkę i zapisuje walutę transakcji. Walidacja checkoutu nie potwierdza konwersji settlement ani księgowania.
| Rekord | Znaczenie kwoty | Autorytet |
|---|---|---|
| Oferta | Kwota transakcyjna oferty | Przewodnik sales i rekord oferty |
| Zamówienie | Waluta zamówienia i opcjonalny dostarczony exchangeRate | Zamówienie sales |
| Faktura | Waluta dokumentu i wynik statutory | Dokument sales i właściciel accounting |
| Korekta | Kwoty korekty i referencji | Polityka sales i accounting |
| Płatność | Kwota otrzymana lub zapisana | Rekord SalesPayment |
| Alokacja | Kwota zaalokowana | Właściciel alokacji należności |
| Transakcja checkout | Waluta transakcji zaakceptowana przez bramkę | Checkout i bramka |
| Settlement | Kwota settlementu i opłaty providera | Provider i rejestr uzgodnienia |
| Journal księgowy | Zaksięgowany wynik funkcjonalny i raportowy | Zewnętrzny system accounting |
Żadna sprawdzona uniwersalna ścieżka nie dowodzi dual transaction i base amounts, automatycznego revaluation, realized lub unrealized FX gains and losses, journals, consolidation ani statutory rate selection. Instrukcje AGENTS modułu currencies opisują reguły architektury i zmian dla date-based rates, transaction i base amounts, realized gains lub losses i atomic posting. Nie dowodzą wydanego zachowania produktu. Zewnętrzni właściciele accounting i tax muszą zatwierdzić source, type, date, rounding, posting, revaluation, settlement, correction i retention kursu.
Słabe dopasowanie i wczesne sygnały stop
- Nieobsługiwane locale UI lub hierarchia locale regionalnych: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
- Gotowy cykl translation management: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
- Dowód użycia tłumaczeń przez każdą powierzchnię: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
- Automatyzacja kursu statutory bez zewnętrznego acceptance: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
- Uniwersalne księgowanie dual-currency: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
- Automatyczne revaluation oraz realized lub unrealized FX gains and losses: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
- Konsolidacja grupowa: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
- Uniwersalna zgodność tax i accounting: zachowaj autorytet specjalistyczny albo udowodnij custom integration i acceptance.
Zapisz dowód, ownera, próg, wyjątek, recovery i obowiązkowy stop. Unknown oznacza stop.
- 1. Pokrycie wymaganych locale
- 2. Ownership źródła i tłumaczenia
- 3. Polityka kompletności i publikacji
- 4. Invariant waluty bazowej
- 5. Polityka waluty i precyzji
- 6. Źródło, data, kierunek i typ kursu
- 7. Ciągłość i legal fitness providera
- 8. Scheduler i gating fetchu
- 9. Capture i freeze kursu dokumentu
- 10. Handoff settlement i accounting
- 11. Izolacja zakresu
- 12. Recovery, korekta, close i audyt
Trzy syntetyczne scenariusze cross-border
Każdy scenariusz osobno nazywa walutę transakcji, base lub functional i reporting lub presentation; użyj same lub not applicable tylko wtedy, gdy to prawda.
Wyłącznie hipotetyczny
1. Syntetyczny katalog dla dwóch rynków
Model trzech walut: transaction: not applicable; functional: not applicable; presentation: not applicable.
- Normalny flow
- Content źródłowy jest tłumaczony, reviewed, approved, published i użyty na testowanych powierzchniach.
- Edge
- Deklarowane pole celowo nie jest wymagane w jednym locale.
- Awaria
- Brak tłumaczenia zachowuje wartość bazową lub powierzchnia ignoruje overlay.
- Recovery
- Zablokuj publikację, przypisz ownera, napraw i powtórz route-specific testy użycia.
- Właściciel
- Właściciele contentu, rynku, języka i wydania
- Dowód
- Macierz kompletności, approval, screenshots i asercje downstream
- Wniosek
- conditional
Wyłącznie hipotetyczny
2. Syntetyczna polska organizacja sprzedająca w PLN i EUR
Model trzech walut: transaction: PLN or EUR; functional: PLN; presentation: PLN or EUR.
- Normalny flow
- Zatwierdzona polityka NBP wybiera źródło, datę, kierunek i typ; dokumenty i settlement są uzgodnione.
- Edge
- Lookup weekendowy używa zatwierdzonej wcześniejszej actual date w skonfigurowanym limicie.
- Awaria
- Checkout przyjmuje EUR, lecz invoice, payment, settlement lub posting nie dają się uzgodnić.
- Recovery
- Zatrzymaj posting, zachowaj raw evidence, popraw politykę lub kurs i ponów kontrolowane uzgodnienie.
- Właściciel
- Kontroler finansowy, właściciel sales, bramki i księgowości
- Dowód
- Daty requested i actual, rekord providera, wybrany kurs, dokumenty, settlement i handoff journal
- Wniosek
- conditional
Wyłącznie hipotetyczny
3. Syntetyczne międzynarodowe środowisko wielu organizacji
Model trzech walut: transaction: organization-specific; functional: organization-specific; presentation: group reporting currency.
- Normalny flow
- Każda organizacja ma scoped locales, waluty i kursy; zewnętrzny accounting jest właścicielem group reporting.
- Edge
- Waluta transakcji, funkcjonalna i prezentacji grupowej są różne.
- Awaria
- Kurs lub locale przecieka między zakresami albo zakłada się konsolidację grupową w Open Mercato.
- Recovery
- Zatrzymaj close, odizoluj rekordy, uzgodnij dotknięte okresy i odtwórz przez zewnętrzny autorytet.
- Właściciel
- Lokalni kontrolerzy, group finance, właściciel platformy i audytorzy
- Dowód
- Testy zakresu, invariants waluty, joiny konsolidacji, close i dowody audytowe
- Wniosek
- no-go until consolidation is owned
Narzędzie lokalne
Rejestr decyzji o języku i pieniądzu
Zaczyna pusty, przyjmuje wyłącznie abstrakcyjne etykiety planistyczne i pozostaje browser-local. Służy do planowania dowodów. Rejestr nie udziela zgody językowej, podatkowej, księgowej, dostawcy, settlement, compliance ani go-live.
Nie wpisuj danych rzeczywistych: Nigdy nie wpisuj prawdziwego klienta, produktu, dokumentu, kwoty, kursu, tax treatment, poświadczenia, kontraktu, incydentu, danych osobowych, odpowiedzi providera ani konfiguracji produkcyjnej. Wyczyść przed użyciem urządzenia współdzielonego.
Prywatność: Strona nie wysyła treści arkusza i nie zapisuje jej w adresie URL ani w plikach cookie.
Pakiet odbioru i obowiązkowe stops
Podaj setup, abstrakcyjny rekord, oczekiwany stan, zabroniony wynik, dowód, ownera, recovery i kryterium pass.
- 1. Stały zestaw locale UI i default
- 2. Wymuszone locale
- 3. Kompletność słownika UI
- 4. Zakres locale contentu
- 5. Limity locale contentu
- 6. Limity payload tłumaczenia
- 7. Scoped uniqueness
- 8. Deklarowane pola katalogu
- 9. Deklarowane pola pozakatalogowe
- 10. Build-time zbieranie deklaracji
- 11. Priorytet locale query
- 12. Priorytet locale header
- 13. Priorytet locale cookie
- 14. Zachowanie Accept-Language
- 15. Overlay exact-locale
- 16. Zachowanie bazy
- 17. Tłumaczenie null
- 18. Markery overlay
- 19. Brak hierarchii regionalnej
- 20. Replacement całego dokumentu
- 21. Współbieżny stale editor
- 22. Opcjonalny optimistic lock
- 23. Historia komend i undo
- 24. Mutation guard
- 25. Wykrywanie orphan
- 26. Field drift
- 27. Cleanup po delete
- 28. Restore i reindex
- 29. ACL tłumaczeń
- 30. Segregation of duties
- 31. Granica kodu waluty
- 32. Precyzja waluty
- 33. Invariant dokładnie jednej base
- 34. Migracja zmiany base
- 35. Blokada delete base
- 36. Data requested i actual kursu
- 37. Kierunek kursu
- 38. Reciprocal inversion
- 39. Rozdział buy i sell
- 40. Wszystkie pasujące kursy
- 41. Limit fallback
- 42. Błędy batch per pair
- 43. Wymóg aktywnej scoped currency
- 44. Mapowanie NBP
- 45. Mapowanie Raiffeisen
- 46. Brak Custom providera
- 47. Ręczny fetch API
- 48. Fetch CLI
- 49. Lista providerów auto-fetch
- 50. Brak cyklicznego schedulera
- 51. Korekta providera
- 52. Częściowa konwersja CRM
- 53. Input kursu zamówienia
- 54. Null rate quote-to-order
- 55. Akceptacja waluty checkout
- 56. Uzgodnienie settlement
- 57. Handoff accounting
- 58. Izolacja cross-scope
- 59. Prywatność rejestru
- 60. No-JavaScript i print
- Stop, gdy wymagane locale UI lub hierarchia fallback nie są obsługiwane.
- Zatrzymaj publikację przy braku źródła, reviewera, approval, kompletności lub dowodu downstream.
- Zatrzymaj migrację waluty przy braku ownera waluty funkcjonalnej, daty, reguły historycznej lub invariant exactly-one.
- Zatrzymaj konwersję przy niezatwierdzonym źródle, dacie, kierunku, typie, wyborze, rounding lub polityce korekty.
- Zatrzymaj automatyzację cykliczną bez implementacji i testu harmonogramu, gating, holiday, retry, alert, backfill i last-good-rate.
- Zatrzymaj financial close przy braku ownera i dowodu settlement, journal, revaluation, consolidation lub statutory.
Praktyczne pytania
Czy brakująca treść tłumaczy się automatycznie?
Tłumaczenia interfejsu i treści biznesowych są odrębne. Mechanizm zastępczy może wyświetlić inny język, ale nie tworzy ani nie zatwierdza tłumaczenia. Wyznacz osobę odpowiedzialną za treści dla danego rynku.
Czy domyślne USD jest zalecaną walutą bazową?
USD jest przykładem w danych początkowych. Wybierz walutę właściwą dla firmy i przed przeliczeniami sprawdź, czy w danym zakresie istnieje dokładnie jedna zamierzona waluta bazowa.
Czy kursy są automatycznie pobierane codziennie?
Sama ustawiona godzina synchronizacji nie potwierdza działającego harmonogramu w opisanym kodzie. Sprawdź zadanie, dostawcę, żądaną datę, datę kursu zastępczego i powiadomienie o błędzie.
Czy przeliczenie przy płatności potwierdza rozliczenie?
Przeliczenie przy płatności wyznacza kwotę dla tego procesu. Ustal walutę rozliczenia, opłaty dostawcy, różnice kursowe i zapisy księgowe, a następnie uzgodnij je z właściwym systemem.
Kontekstowe dowody i ścieżka korekty
Zapisano claim, stan możliwości, etykietę dowodu, datę lub immutable revision, ograniczenie, confidence, external acceptance i ownera review.
- 1. Publiczne wydanie Open Mercato v0.6.5
- 2. Przypięta konfiguracja i endpoint locale UI
- 3. Przypięty moduł translations i deklaracje
- 4. Przypięte encje i usługi modułu currencies
- 5. Przypięta implementacja providera NBP
- 6. Przypięta implementacja providera Raiffeisen
- 7. Przypięci consumerzy walutowi sales
- 8. Przypięci consumerzy konwersji CRM
- 9. Przypięta ścieżka waluty checkout
- 10. Bieżąca dokumentacja first-party currencies
- 11. Dokumentacja Web API NBP
- 12. Referencja ISO 4217
- 13. Kanoniczny przewodnik katalogu
- 14. Kanoniczne przewodniki sales, payments i reporting
Najnowsze sprawdzone wydanie publiczne · Niezmienny kod translations · Niezmienny kod currencies · Web API NBP · ISO 4217
Odświeżenie dowodów porównało runtime, testy, dokumentację projektu Open Mercato, etykiety wydań, referencje NBP i ISO oraz oczekiwania wyszukiwania po angielsku i polsku 14 lipca 2026. Zgłaszaj korekty z dokładnym claimem, zastępczym primary evidence, dotkniętą rewizją, wpływem operacyjnym i ownerem.