Vergiler ve faturalar için çok dövizli fiyatlandırma veri modeli

Çok dövizli faturalarla genelde ne kötü gider

Çok dövizli faturalar sıkıcı ama pahalı şekillerde bozulur. Arayüzde sayılar güzel görünür, sonra biri bir PDF alır, muhasebe içe aktarır ve toplamlar artık satır tutarlarıyla uyuşmaz.

Kök neden basit: para ile ilgili matematik sadece bir döviz kuru ile çarpmak değildir. Vergiler, yuvarlama ve oranın tam olarak ne zaman alındığı sonuca etki eder. Fiyatlandırma veri modeliniz bu seçimleri açık hale getirmezse, sisteminizin farklı parçaları "yardımseverce" yeniden hesaplayıp farklı cevaplar üretecektir.

Üç görünüm aynı fikirde olmalı, farklı para birimleri gösterse bile:

• Müşteri görünümü: müşteri para biriminde net fiyatlar, ve toplamlar satırlarla toplanıyor olmalı.
• Muhasebe görünümü: raporlama ve mutabakat için tutarlı temel tutarlar.
• Denetim görünümü: hangi oran ve yuvarlama kurallarının faturayı ürettiğini gösteren bir kağıt izi.

Uyumsuzluklar genellikle farklı yerlerde yapılan küçük kararlardan kaynaklanır. Bir ekip her satır öğesini yuvarlar; başka bir ekip yalnızca toplamı yuvarlar. Bir sayfa mevcut oranı kullanır; başka bir sayfa fatura tarihindeki oranı. Bazı vergiler indirimden önce uygulanır, bazıları sonra. Bazı vergiler fiyata dahil, bazıları üstüne eklenir.

Somut bir örnek: 19,99 EUR değerinde bir ürün satıyorsunuz, faturayı GBP düzenliyorsunuz ve raporu USD'de yapıyorsunuz. Satırı başına dönüştürüp 2 ondalığa yuvarlarsanız, vergi toplamı, önce toplayıp sonra bir kez dönüştürmekten farklı olabilir. Her iki yaklaşım da mantıklı olabilir ama yalnızca biri kuralınız olabilir.

Hedef, tahmin edilebilir hesaplamalar ve açık saklanan değerlerdir. Her fatura tahmin etmeden cevaplamalı: hangi tutarlar girildi, hangi para biriminde girildi, hangi oran kullanıldı (ve ne zaman), ne yuvarlandı (ve nasıl) ve hangi vergi kuralları uygulandı. Bu açıklık, arayüz, PDF'ler, dışa aktarmalar ve denetimler arasında toplamları sabit tutar.

Şemayı tasarlamadan önce üzerinde anlaşılması gereken temel terimler

Tabloları çizmeden önce herkesin aynı kelimeleri kullandığından emin olun. Çoğu çok dövizli hata teknik değil, "farklı şeyler kastettik" hatasıdır. Temiz bir şema, ürün, finans ve mühendisliğin kabul edeceği tanımlarla başlar.

Veritabanınızı etkileyen para birimi terimleri

Her para akışı için üç para biriminde anlaşın:

• İşlemsel para birimi: müşterinin gördüğü ve kabul ettiği para birimi (fiyat listesi, sepet, fatura gösterimi).
• Tahsilat para birimi: gerçekte ödendiğiniz para birimi (ödeme sağlayıcısının veya bankanın mutabakat yaptığı para birimi).
• Raporlama para birimi: panolar ve muhasebe özetleri için kullanılan para birimi.

Ayrıca küçük birimleri tanımlayın. USD için 2 (cent), JPY için 0, KWD için 3. Bu önemlidir çünkü "12.34" gibi ondalık bir sayıyı kayan nokta olarak saklamak sapmaya yol açar; küçük birimlerde bir tam sayı (örneğin 1234 cent) saklamak ise kesin kalır ve yuvarlamayı öngörülebilir kılar.

Toplamları değiştiren vergi terimleri

Vergiler aynı düzeyde anlaşma gerektirir. Fiyatların vergi dahil (gösterilen fiyat vergiyi zaten içerir) mi yoksa vergi hariç (vergi üstüne eklenir) mi olduğunu kararlaştırın. Ayrıca verginin satır bazında (sonra toplanır) mı yoksa fatura bazında (önce toplanır, sonra vergi) mı hesaplanacağını seçin. Bu seçimler yuvarlamayı etkiler ve nihai ödenecek tutarı birkaç küçük birim değiştirebilir.

Son olarak, hangi bilgilerin saklanması gerektiğini ve hangilerinin türetilebileceğini kararlaştırın:

• Yasal ve finansal olarak önemli olanları saklayın: üzerinde anlaşılmış fiyatlar, uygulanan vergi oranları, nihai yuvarlanmış toplamlar ve kullanılan para birimi.
• Güvenle yeniden hesaplayabileceğinizleri türetin: biçimlendirilmiş dizeler, yalnızca gösterim amaçlı dönüşümler ve çoğu ara matematik.

Temel para alanları: ne saklanmalı ve nasıl

Hangi sayıların birer gerçek (saklanması gereken) olduğunu ve hangi sayıların yeniden hesaplanabilecek sonuçlar olduğunu önce belirleyin. İkisini karıştırmak, faturaların ekranda bir toplam gösterip dışa aktarmada farklı bir toplam göstermesine yol açar.

Parayı küçük birimlerde tam sayılar olarak saklayın (örneğin cent) ve her zaman yanında para birimi kodunu saklayın. Para birimi olmayan bir miktar eksik veridir. Tam sayılar ayrıca pek çok satırı topladığınızda ortaya çıkan küçük kayan nokta hatalarını önler.

Pratik bir desen, hem ham girdileri hem de hesaplanmış çıktıları tutmaktır. Girdiler kullanıcının ne girdiğini açıklar. Çıktılar ne faturalandırıldığını açıklar. Birisi aylar sonra bir faturaya itiraz ederse ikisine de ihtiyacınız olur.

Fatura satırları için temiz ve kalıcı bir alan seti şöyle görünebilir:

• unit_price_minor + unit_currency
• quantity (ve gerekirse uom)
• line_subtotal_minor (vergi/indirim öncesi)
• line_discount_minor
• line_tax_minor (veya vergi türüne göre ayrılmış)
• line_total_minor (satır için nihai tutar)

Yuvarlama sadece bir arayüz detayı değildir. Hesaplamalarda kullanılan yuvarlama yöntemi ve duyarlılığını persist edin, özellikle farklı küçük birimlere sahip para birimlerini (JPY vs USD) veya nakit yuvarlama kurallarını destekliyorsanız. Küçük bir "hesaplama bağlamı" kaydı calc_precision, rounding_mode ve yuvarlamanın her satırda mı yoksa yalnızca fatura toplamında mı yapıldığını yakalayabilir.

Gösterim biçimlendirmesini saklanan değerlerden ayrı tutun. Saklanan değerler düz sayılar ve kodlar olmalı; biçimlendirme (para birimi sembolleri, ayırıcılar, yerelleştirilmiş sayı formatı) sunum katmanındadır. Örneğin 12345 + EUR saklayın; UI "€123.45" mı yoksa "123,45 €" mı göstereceğine karar versin.

Döviz kurları: tablolar, zaman damgaları ve denetim izi

Döviz kurlarını belirli bir kaynağı olan zaman bazlı veriler olarak ele alın. "Bugünün kuru" daha sonra güvenle yeniden hesaplayabileceğiniz bir şey değildir.

Pratik bir döviz kuru tablosu genellikle şunları içerir:

• base_currency (dönüştürülen kaynak, ör. USD)
• quote_currency (dönüştürülen hedef, ör. EUR)
• rate (1 base için quote, yüksek hassasiyetli ondalık olarak saklanmalı)
• effective_at (oranın geçerli olduğu zaman damgası)
• source (sağlayıcı) ve source_ref (onların kimliği veya bir payload hash'i)

Bu kaynak bilgisi denetimlerde önemlidir. Bir müşteri bir tutara itiraz ederse, sayının nereden geldiğini tam olarak gösterebilirsiniz.

Sonra, bir faturanın hangi oranı kullandığına dair tek bir kural seçin ve ona bağlı kalın. Yaygın seçenekler sipariş zamanı, sevkiyat zamanı veya fatura zamanı oranıdır. En iyi seçim iş modelinize bağlıdır. Önemli olan tutarlılık ve dokümantasyondur.

Hangi kuralı seçerseniz seçin, faturada kullanılan tam oranı saklayın (çoğu zaman her fatura satırında da). Daha sonra bakıp yeniden hesaplamanıza güvenmeyin. Faturanın tam olarak yeniden üretilebilmesi için fx_rate, fx_rate_effective_at ve fx_rate_source gibi alanlar ekleyin.

Eksik oranlar (hafta sonları, tatiller, sağlayıcı kesintileri) için yedek davranışı açıkça belirtin. Tipik yaklaşımlar: en yakın önceki oranı kullanmak, faturalamayı oran gelene kadar engellemek veya bir onay bayrağı ile manuel orana izin vermektir.

Örnek: bir sipariş Cumartesi verildi, Pazartesi sevk edildi, Pazartesi faturalandı. Kuralınız fatura zamanı ise ama sağlayıcınız hafta sonları oran yayımlamıyorsa, Cuma'nın son oranını kullanabilirsiniz ve effective_at = Cuma 23:59 ile birlikte source_ref kaydedebilirsiniz.

Tutarlı kalan para birimi dönüşüm ve yuvarlama kuralları

Yuvarlama problemleri nadiren bariz hatalar gibi görünür. Fatura toplamı ile satırların toplamı arasında 1 cent farkı veya gösterdiğiniz ile ödeme sağlayıcınızın beklediği arasında küçük vergi farkları olarak ortaya çıkarlar. İyi modeller yuvarlamayı açıklanabilir bir kural haline getirir; sonradan yamalanan bir sürpriz değil.

Yuvarlamanın tam olarak nerede gerçekleşeceğine karar verin

Yuvarlamaya izin verdiğiniz noktaları seçin ve her şeyi daha yüksek hassasiyette tutun. Yaygın yuvarlama noktaları:

• Satır uzantısı (miktar x birim fiyatı, indirim sonrası)
• Her vergi tutarı (satır başına veya fatura bazında, yargı yetkisine bağlı olarak)
• Nihai fatura toplamı

Bu noktaları tanımlamazsanız, sisteminizin farklı parçaları uygun olduğunda yuvarlama yapar ve toplamlar kayar.

Bir yuvarlama modu kullanın, vergi kuralları için açık istisnalarla

Bir yuvarlama modu seçin (yakınlaştırma: half-up veya bankers rounding) ve tutarlı uygulayın. Half-up müşterilere açıklaması daha kolaydır. Bankers rounding büyük hacimler üzerinden önyargıyı azaltabilir. Her ikisi de işe yarar ama API'nız, UI'nız, dışa aktarmalarınız ve muhasebe raporlarınız aynı modu kullanmalı.

Dönüşüm ve ara adımlarda ekstra hassasiyeti koruyun (örneğin, FX oranlarını birçok ondalıkla saklayın), sonra yalnızca seçtiğiniz yuvarlama noktalarında yuvarlayın.

İndirimler için de tek bir kural gerekir: indirimleri vergi öncesi mi uygularsınız (kuponlar için yaygın) yoksa vergi sonrası mı (bazı ücretler için gerekli olabilir). Bunu yazılı hale getirin ve bir kez kodlayın.

Bazı yargı bölgeleri vergiyi satır bazında, vergi bazında veya fatura toplamı üzerinden yuvarlamayı zorunlu kılar. Kod tabanınız boyunca tek-off vakalar sabitlemek yerine, ülke/eyalet/vergi rejimine göre bir "yuvarlama politikası" ayarı saklayın ve hesaplamalar o politikayı izlesin.

Basit bir kontrol: aynı faturayı yarın saklanan aynı oranlar ve politika ile yeniden oluşturursanız, her seferinde tam olarak aynı centleri almalısınız.

Vergi alanları: KDV, satış vergisi ve birden çok vergi için kalıplar

Vergiler hızla karışık hale gelir çünkü alıcının nerede olduğu, ne sattığınız ve fiyatların net mi brüt mü gösterildiği gibi koşullara bağlıdır. Temiz bir model vergileri açık tutar, ima etmeye izin vermez.

Vergi esasını açık hale getirin. Vergilenen fiyatın net (vergi üstüne eklenen) mi yoksa brüt (vergi dahil) mi olduğunu saklayın. Ardından uygulanan oranı ve hesaplanan vergi tutarını anlık görüntü (snapshot) olarak saklayın ki sonraki kural değişiklikleri geçmişi değiştirmesin.

Her fatura satırında, yıllar sonra bile net kalan asgari set:

• tax_basis (NET veya GROSS)
• tax_rate (ondalık, örneğin 0.20)
• taxable_amount_minor (gerçekte vergilenen temel)
• tax_amount_minor
• tax_method (PER_LINE veya ON_SUBTOTAL)

Birden fazla vergi uygulanabiliyorsa (örneğin KDV artı şehir ek vergisi), her uygulanan vergi için InvoiceLineTax gibi ayrı bir döküm tablosu ekleyin. Her satır tax_code, tax_rate, taxable_amount_minor, tax_amount_minor, para birimi ve hesaplama zamanında kullanılan yargı bilgileri (ülke, bölge, posta kodu gerektiğinde) içermelidir.

Uygulanan kural ayrıntılarının bir anlık görüntüsünü faturada veya fatura satırında saklayın; örneğin rule_version veya karar girdilerinin JSON blob'u (müşteri vergi durumu, ters yükümlülük, muafiyetler). KDV kuralları gelecek yıl değişirse eski faturalar yine de gerçekten aldığınızla eşleşmelidir.

Örnek: Almanya'daki bir müşteriye satılan bir SaaS aboneliği NET satır fiyatına %19 KDV uygular ve artı %1 yerel vergi olabilir. Satır toplamlarını faturalandığı şekilde saklayın ve her vergi için bir döküm satırı tutun.

Tabloları adım adım nasıl tasarlamalısınız

Bu akıllı matematikten çok doğru zamanda doğru gerçekleri dondurmaktır. Amaç, bir faturanın aylar sonra yeniden açılıp aynı sayıları göstermesidir.

Gerçeğin ürün fiyatlarında nerede yaşadığına karar vererek başlayın. Birçok ekip ürün başına bir temel-para birimi fiyatı tutar ve isteğe bağlı olarak pazar başına geçersiz kılma ekler (örneğin USD ve EUR için ayrı fiyat satırları). Ne seçerseniz seçin, bunu şemada açık hale getirin ki "katalog fiyatı" ile "dönüştürülmüş fiyat"u karıştırmayın.

Anlaşılır tabloları koruyan basit bir sıra:

• Ürünler ve fiyatlandırma: product_id, price_amount_minor, price_currency, effective_from (fiyatlar zamanla değişiyorsa).
• Sipariş ve fatura başlıkları: document_currency, customer_locale, billing_country ve zaman damgaları (issued_at, tax_point_at).
• Satır öğeleri: unit_price_amount_minor, quantity, discount_amount_minor, tax_amount_minor, line_total_amount_minor ve her saklanan para alanı için para birimi.
• Döviz kuru anlık görüntüsü: kullanılan kesin oran (rate_value, rate_provider, rate_timestamp) sipariş veya faturadan referansla.
• Vergi döküm kayıtları: verginin bir satırı (tax_type, rate_percent, taxable_base_minor, tax_amount_minor) artı bir calculation_method bayrağı.

Daha sonra yeniden hesaplamaya güvenmeyin. Bir faturayı oluşturduğunuzda, final birim fiyatlarını, indirimleri ve toplamları fatura satırlarına kopyalayın, bunlar bir siparişten gelmiş olsa bile.

İzlenebilirlik için faturada bir calculation_version (veya calc_hash) ve kim yeniden hesaplamayı tetiklediğini ve nedenini kaydeden küçük bir calculation_log tablosu ekleyin (örneğin "düzenlemeden önce oran güncellendi").

Yerelleştirilmiş fatura gösterimi, ama sayıları bozmadan

Yerelleştirme bir faturanın nasıl göründüğünü değiştirmeli, ne anlama geldiğini değil. Tüm hesaplamaları saklanan sayısal değerlerle (küçük birimler veya sabit hassasiyetli ondalıklarla) yapın, sonra nihai adımda yerel biçimlendirmeyi uygulayın.

Fatura sunum ayarlarını sadece müşteri profilinde değil, faturanın kendisinde saklayın. Müşteriler ülke, fatura irtibatı ve tercihlerini zamanla değiştirir. Bir fatura yasal bir anlık görüntüdür. invoice_language, invoice_locale ve biçimlendirme bayrakları (örneğin sondaki sıfırları gösterme) gibi bilgileri belge ile saklayın ki altı ay sonra yeniden yazdırma orijinaliyle eşleşsin.

Para birimi sembolleri gösterim meselesidir. Bazı yereller sembolü miktarın önüne koyar, bazıları sonuna. Bazıları boşluk ister, bazıları istemez. Sembol yerleşimini, boşluklandırmayı, ondalık ayırıcıyı ve binlik gruplamayı render zamanında, fatura yereli ve para birimine göre ele alın. Sembolü saklanan para alanlarına gömülmeyin ve biçimlendirilmiş dizeleri tekrar sayılara parse etmeyin.

İkinci bir para biriminde raporlama gerekiyorsa (genellikle ev para birimi gibi USD veya EUR), bunu bir ikincil toplam olarak açıkça gösterin, ana para biriminin yerine koymayın. Belge para birimi yasal gerçeğin kaynağı olmaya devam eder.

Pratik bir çıktı düzeni:

• Satır öğelerini ve toplamları belge para biriminde, fatura yereli biçimlendirmesiyle gösterin.
• İsteğe bağlı olarak oran kaynağı ve zaman damgası etiketli ikincil raporlama toplamı gösterin.
• Vergi dökümünü ayrı satırlar halinde gösterin (vergilenen temel, her vergi, toplam vergi), tek karışık bir tutar olarak değil.
• PDF ve e-posta renderlarını aynı saklanan toplamlardan üretin ki sayılar kayamasın.

Örnek: Fransız bir müşteri CHF cinsinden faturalandırılıyor. Fatura yereli virgül ondalık kullanır ve para birimini miktardan sonra koyar; ancak hesaplamalar hala saklanan CHF tutarları ve saklanan vergi toplamlarını kullanır. Biçimlenmiş çıktı değişir; sayılar değişmez.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Çok dövizli faturaları bozmanın en hızlı yolu parayı normal bir sayı gibi işlemektir. Fiyatlar, vergiler ve toplamlar için kayan nokta tipleri küçük hatalara yol açar ve daha sonra "0,01 $ yanlış" problemleri ortaya çıkar. Tutarları küçük birimlerde tam sayılar olarak saklayın (cent) veya net bir ölçekli sabit ondalık tipi kullanın ve bununla tutarlı olun.

Başka klasik bir tuzak, kazara geçmişi değiştirmektir. Eski bir faturayı bugünün döviz kuru ile veya güncellenmiş vergi kurallarıyla yeniden hesaplarsanız, müşterinin gördüğü ve ödediği belgeyi kaybedersiniz. Faturalar değişmez olmalıdır: düzenlendikten sonra kullanılan tam döviz kuru, yuvarlama kuralları ve vergi yöntemi saklanmalı ve saklanan toplamlar yeniden hesaplanmamalıdır.

Tek bir satır öğesinin içinde birden fazla para birimi karıştırmak da sessiz bir şema hatasıdır. Birim fiyat EUR ise indirim USD, vergi GBP ise, daha sonra matematiği açıklayamazsınız. Bir gösterim ve tahsilat para birimi seçin ve gerekirse dahili raporlama için bir temel para birimi belirleyin. Her saklanan tutarın açık bir para birimi olmalı.

Yuvarlama hataları genellikle çok sık yuvarlamadan kaynaklanır. Birim fiyatta yuvarlama, sonra satır toplamında, sonra satır başı vergide, sonra yeniden ara toplamda yuvarlarsanız, toplamlar satırların toplamıyla eşleşmeyi bırakabilir.

Dikkat edilmesi gereken yaygın tuzaklar:

• Fiyatlar veya döviz kurları için sabit bir hassasiyet olmadan kayan nokta kullanmak
• Eski faturalar için dönüşümleri yeniden çalıştırmak yerine saklanan oranları kullanmamak
• Bir satır öğesinde birden fazla para birimine izin vermek
• Birçok adımda yuvarlama yapmak yerine belirlenmiş noktalarda yuvarlamak
• Her belge için oran zaman damgası, yuvarlama modu ve vergi yöntemini saklamamak

Örnek: Bir faturayı CAD olarak oluşturdunuz, EUR fiyatlı bir hizmeti dönüştürdünüz, sonra oran tablonuzu güncellediniz. Sadece EUR tutarını sakladıysanız ve gösterim için dönüştürme yapıyorsanız, CAD toplamı gelecek hafta değişir. EUR tutarını, uygulanan FX oranını (ve zamanı) ve faturada kullanılan nihai CAD tutarlarını saklayın.

Yayınlamadan önce hızlı kontrol listesi

Çok dövizli faturaları "tamamlandı" ilan etmeden önce tutarlılığa odaklanmış son bir geçiş yapın. Buradaki çoğu hata karmaşık değildir. Sakladığınız, görüntülediğiniz ve topladığınız şeyler arasındaki uyuşmazlıklardan kaynaklanır.

Bunu bir sürüm kapısı olarak kullanın:

• Her faturanın başlığında tam olarak bir belge para birimi olsun ve faturada saklanan her toplam o para biriminde olsun.
• Sakladığınız her parasal değer küçük birimlerde bir tam sayı olsun; satır toplamları, vergi tutarları, indirimler ve kargo dahil.
• Fatura uygulanan kesin döviz kurunu (kesin ondalık), zaman damgasını ve oran kaynağını saklasın.
• Yuvarlama kuralları belgelenmiş ve tek bir paylaşılan yerde uygulanmış olsun.
• Birden fazla vergi uygulanabiliyorsa, satır başına vergi dökümü saklayın (ve gerekirse yargıya göre), sadece başlıkta tek bir vergi toplamı değil.

Şema kontrolünü geçtikten sonra, bir denetçinin yapacağı gibi matematiği doğrulayın. Fatura toplamları saklanan satır toplamları ve saklanan vergi tutarlarının toplamına eşit olmalı. Gösterilen değerlerden veya biçimlendirilmiş dizelerden toplamları yeniden hesaplamayın.

Pratik bir test: en az üç satırı olan bir fatura seçin, bir indirim uygulayın ve bir satırda iki vergi olsun. Sonra farklı bir yerelde yazdırın (farklı ayırıcılar ve para birimi sembolü) ve saklanan sayıların değişmediğini doğrulayın.

Örnek senaryo: bir sipariş, üç para birimi ve vergiler

Bir ABD müşterisi USD ile faturalandırılıyor, AB tedarikçiniz size EUR ile fatura ediyor ve finans ekibiniz GBP'de raporluyor. Bu model ya sükûnetini korur ya da 1 cent eşitsizlikleriyle bir yığın haline gelir.

Sipariş: 3 adet ürün.

• Müşteri fiyatı: $19.99 birim başına (USD)
• İndirim: satırda %10
• ABD satış vergisi: %8.25 (indirim sonrası vergilendirilir)
• Tedarikçi maliyeti: EUR 12.40 birim başına (EUR)
• Raporlama para birimi: GBP

Yürüyüş: ne olur ve ne zaman dönüştürürsünüz

Bir dönüşüm anı seçin ve ona bağlı kalın. Pek çok faturalama sisteminde güvenli bir seçim fatura düzenleme zamanında dönüştürmek ve kullanılan kesin oranı saklamaktır.

Fatura oluşturulurken:

1. USD satır ara toplamını hesaplayın: 3 x 19.99 = 59.97 USD.
2. İndirimi uygulayın: 59.97 x %10 = 5.997, 6.00 USD'ye yuvarlanır.
3. Satır net: 59.97 - 6.00 = 53.97 USD.
4. Vergi: 53.97 x %8.25 = 4.452525, 4.45 USD'ye yuvarlanır.
5. Toplam: 53.97 + 4.45 = 58.42 USD.

Yuvarlama yalnızca tanımlı noktalarda (indirim, her vergi tutarı, satır toplamları) gerçekleşir. Bu yuvarlanmış sonuçları saklayın ve her zaman saklanan değerleri toplayın. Bu, PDF'inizde 58.42 gösterilip bir dışa aktarmada 58.43 hesaplanması gibi klasik problemi önler.

Faturayı daha sonra birebir yeniden üretebilmek için ne saklamalısınız

Fatura (ve fatura satırları) üzerinde para birimi kodunu (USD), küçük birimlerde tutarları (cent), vergi dökümünü vergi türüne göre ve USD'den GBP'ye raporlama için kullanılan döviz kuru kayıt kimliklerini saklayın. Tedarikçi maliyeti için EUR maliyeti ve bunu GBP'ye dönüştürmek için kullanılan ayrı oran kaydını da saklayın.

Müşteri temiz bir USD faturası görür (fiyatlar, indirim, vergi, toplam). Finans USD tutarlarını artı donmuş GBP karşılıklarını ve kesin oran zaman damgalarını dışa aktarır, böylece ay sonu rakamları yarın oranlar değişse bile eşleşir.

Sonraki adımlar: uygulayın, test edin ve sürdürülebilir tutun

Minimum şemanızı kısa bir sözleşme olarak yazın: hangi tutarların saklandığı (orijinal, dönüştürülmüş, vergi), her tutarın hangi para biriminde olduğu, hangi yuvarlama kuralının uygulandığı ve hangi zaman damgasının bir faturadaki döviz kurunu kilitlediği. Sıkıcı ve spesifik tutun.

UI ekranlarını inşa etmeden önce testleri yazın. Sadece normal faturaları test etmeyin. Yuvarlama gürültüsünü ortaya çıkaracak kadar küçük ve toplama problemlerini ifşa edecek kadar büyük kenar durumları ekleyin.

Başlangıç test seti:

• Yüksek miktarlarla çarpılan çok küçük birim fiyatlar (ör. 0.01)
• Dönüştürmeden sonra tekrar eden ondalıklara yol açan indirimler
• Sipariş tarihi ile fatura tarihi arasındaki döviz kuru değişiklikleri
• Aynı fatura türünde karışık vergi kuralları (vergi dahil vs vergi hariç)
• Orijinal yuvarlamayla eşleşmesi gereken iadeler ve kredi notları

Destek taleplerini kısa tutmak için, faturadaki her sayıyı açıklayan bir denetim görünümü ekleyin: saklanan tutarlar, para birimi kodları, döviz kuru ID'si ve zaman damgası, ve kullanılan yuvarlama yöntemi. Birisi "neden bu toplam farklı?" diye sorduğunda saklanan gerçeklerden cevap verin.

Eğer dahili bir faturalama aracı inşa ediyorsanız, AppMaster (appmaster.io) gibi kodsuz bir platform, şemayı tek bir yerde tutup hesaplama mantığını yeniden kullanılabilir bir iş akışına koyarak web ve mobil ekranların her birinin kendi matematiğini yapmasını engellemenize yardımcı olabilir.

Son olarak, sahiplenme atayın. Kurları kim günceller, vergi kurallarını kim günceller ve düzenlenmiş faturaları etkileyen değişiklikleri kim onaylar karar verin. Kararlılık bir süreçtir, sadece bir şema değil.