Uzlaşan fatura defteri şeması: faturalar ve ödemeler

Neden fatura verileri uzlaşmaz\n\nFinans için “uzlaşmak” basit bir vaat demektir: raporlardaki toplamlar kaynak kayıtlara uyuyor ve her sayı izlenebiliyor. Ayda 12.430 $ toplandıysa, tam olarak hangi ödemelerin (ve iadelerin) buna denk geldiğini göstermeli, hangi faturaya uygulandığını görmeli ve her farkı tarihli bir kayıtla açıklayabilmelisiniz.\n\nFatura verileri genellikle sonuçları gerçekler yerine sakladığında uzlaşmayı bırakır. paid_amount, balance veya amount_due gibi sütunlar uygulama mantığıyla zaman içinde güncellenir. Bir hata, bir yeniden deneme veya bir elle “düzeltme” tarihi sessizce değiştirebilir. Haftalar sonra fatura tablosu bir faturayı “ödenmiş” gösterir, ama ödeme satırları tutmaz veya eşleşen bir kredi olmadan bir iade vardır.\n\nBir başka yaygın neden farklı belge türlerini karıştırmaktır. Bir fatura bir ödeme değildir. Bir kredi notu bir iade değildir. Bir düzeltme indirimle aynı şey değildir. Bunlar tek bir “transactions” satırına çok sayıda isteğe bağlı alanla sıkıştırıldığında, raporlama tahmin işine dönüşür ve denetimler tartışma haline gelir.\n\nTemel uyumsuzluk basittir: uygulamalar genellikle mevcut durumla ilgilenir (“erişim aktif mi?”), finans ise izle ilgili ayrıntıyla ilgilenir (“ne oldu, ne zaman ve neden?”). Bir fatura defteri şeması her ikisini de desteklemeli fakat izlenebilirlik öncelikli olmalıdır.\n\nBuna göre tasarlayın:\n\n- Müşteri, fatura ve muhasebe dönemi başına net toplamlar\n- Her değişiklik yeni bir satır olarak kaydedilir (üzerine yazılmaz)\n- Fatura ile ödemeler, krediler, iadeler ve düzeltmeler arasındaki eksiksiz zincir\n- Ham girdilerden toplamları yeniden hesaplayabilme ve aynı sonuca ulaşma kabiliyeti\n\nÖrnek: bir müşteri 100 $ ödüyorsa, sonra 20 $ kredi alıyorsa, raporlar 100 $ tahsilat, 20 $ kredi ve 80 $ net göstermeli; orijinal fatura tutarı düzenlenmemelidir.\n\n## Faturaları, ödemeleri, kredileri ve düzeltmeleri ayırın\n\nUzlaşan bir fatura defteri şeması istiyorsanız, her belge türünü farklı bir olay türü gibi ele alın. Hepsini tek bir “transactions” tablosuna koymak düzenli görünür, ama anlamı bulanıklaştırır.\n\nBir fatura bir talep niteliğindedir: “müşteri bize borçlu.” Bunu başlık (müşteri, fatura numarası, düzenleme tarihi, vade tarihi, para birimi, toplamlar) ve ayrı satır öğeleri (ne satıldı, miktar, birim fiyat, vergi kategorisi) olarak saklayın. Hız için başlık toplamlarını saklamak sorun değil, ama her zaman bunları satırlardan açıklayabilmelisiniz.\n\nBir ödeme para hareketidir: “nakit müşteri tarafından bize geldi.” Kart akışlarında yetkilendirme (banka onayı) ve tahsilat (paranın çekilmesi) ayrı ayrı görülür. Birçok sistem yetkilendirmeleri operasyonel kayıtlar olarak tutar ve deftere yalnızca tahsil edilmiş ödemeleri koyar, böylece nakit raporlaması şişirilmez.\n\nBir kredi notu müşterinin borcunu azaltır ama mutlaka para geri gönderilmez. Bir iade nakit çıkışıdır. Genellikle birlikte olur, ama aynı şey değildir.\n\n- Fatura: alacak ve gelir (veya ertelenmiş gelir) artar\n- Ödeme: nakit artar ve alacak azalır\n- Kredi notu: alacak azalır\n- İade: nakit azalır\n\nBir düzeltme gerçeklik kayıtlarla uyuşmadığında ekibinizin yaptığı bir düzeltmedir. Düzeltmelerin finans tarafından güvenilir olması için bağlam gereklidir. Kim oluşturdu, ne zaman gönderildi, sebep kodu ve kısa bir not saklayın. Örnekler: “yuvarlama nedeniyle 0.03 silindi” veya “eski bakiye taşındı.”\n\nPratik bir kural: “Birisi hata yapmasaydı bu var olur muydu?” diye sorun. Faturalar, ödemeler, kredi notları ve iadeler hâlâ var olur. Düzeltmeler nadir, açıkça etiketli ve gözden geçirilmesi kolay olmalıdır.\n\n## Finansın denetleyebileceği bir defter modeli seçin\n\nUzlaşan bir fatura defteri şeması tek bir fikirle başlar: belgeler ne olduğunu anlatır, defter gönderimleri ise toplamları kanıtlar. Bir fatura, ödeme veya kredi notu bir belgedir. Defter, toplamları toplayan girdiler kümesidir.\n\n### Belgeler vs gönderimler (her ikisini de saklayın)\n\nBelgeleri (fatura başlığı ve satırları, ödeme makbuzu, kredi notu) saklayın çünkü insanlar bunları okumak ister. Ama uzlaşma için sadece belge toplamlarına güvenmeyin.\n\nBunun yerine her belgeyi bir veya daha fazla değiştirilemez giriş olarak bir defter tablosuna gönderin. Böylece finans, hesap, müşteri, para birimi ve gönderim tarihine göre girdileri toplayıp her seferinde aynı cevabı alabilir.\n\nDenetime uygun basit bir model birkaç kural izler:\n\n- Değiştirilemez girdiler: yayınlanmış tutarlar asla düzenlenmez; değişiklikler yeni girdilerdir.\n- Açık gönderim olayı: her belge benzersiz bir referansla bir gönderim partisi oluşturur.\n- Dengeli mantık: girdiler doğru şekilde netleşir (genellikle şirket düzeyinde borç alacak eşitlenir).\n- Ayrı tarihler: belge tarihi (müşterinin gördüğü) ve gönderim tarihi (raporları etkileyen) ayrı tutulur.\n- Sabit referanslar: dış referansı (fatura numarası, ödeme sağlayıcı ID'si) iç ID'lerle birlikte saklayın.\n\n### Doğal anahtarlar vs yerel ID'ler\n\nJoin ve performans için yerel (surrogate) ID'ler kullanın, ama göçler ve yeniden içe aktarmalar karşısında kalan sabit bir doğal anahtar da saklayın. Finans, “Invoice INV-10483” diyerek veri tabanı ID'leri değiştikten sonra bile sizden bunu isteyecektir. Fatura numaralarını ve sağlayıcı ID'lerini (ör. bir ödeme işlemcisi charge ID'si) birinci sınıf alanlar gibi ele alın.\n\n### Tarihi silmeden ters kayıtlar\n\nBir şey geri alınmalıysa silmeyin veya üzerine yazmayın. Bir ters kayıt gönderin: orijinal tutarları zıt işaretle yansıtan yeni girdiler, orijinal gönderime bağlanmış şekilde.\n\nÖrnek: yanlış fatura üzerine uygulanan 100 $ ödeme iki adım olur: hatalı uygulamayı ters gönderimle iptal edin, sonra doğru faturaya yeni bir uygulama gönderin.\n\n## Adım adım şema taslağı (tablolar ve anahtarlar)\n\nBelge türü başına ayrı bir tablo ve bunları açık tahsis kayıtlarıyla bağlamak (sonradan ilişki tahmin etmek yerine) fatura defterinin daha güvenilir uzlaşmasını sağlar.\n\nTemel bir çekirdek tablo setiyle başlayın; her biri net bir birincil anahtar (UUID veya bigserial) ve gerekli yabancı anahtarlar içersin:\n\n- customers: customer_id (PK), ayrıca external_ref gibi kalıcı tanıtıcılar (unique)\n- invoices: invoice_id (PK), customer_id (FK), invoice_number (unique), issue_date, due_date, currency\n- invoice_lines: invoice_line_id (PK), invoice_id (FK), line_type, description, qty, unit_price, tax_code, amount\n- payments: payment_id (PK), customer_id (FK), payment_date, method, currency, gross_amount\n- credits: credit_id (PK), customer_id (FK), credit_number (unique), credit_date, currency, amount\n\nArdından toplamların denetlenebilir olmasını sağlayan tabloları ekleyin: tahsisler. Bir ödeme veya kredi birden fazla faturayı karşılayabilir; bir fatura da birden fazla ödemeyle kapatılabilir.\n\nJoin tablolarını kendi anahtarlarıyla kullanın (sadece bileşik anahtarlar değil):\n\n- payment_allocations: payment_allocation_id (PK), payment_id (FK), invoice_id (FK), allocated_amount, posted_at\n- credit_allocations: credit_allocation_id (PK), credit_id (FK), invoice_id (FK), allocated_amount, posted_at\n\nSon olarak, düzeltmeleri ayrı tutun ki finans ne değiştiğini ve nedenini görebilsin. Bir adjustments tablosu hedef kayda invoice_id (nullable) ile referans verebilir ve geçmişi yeniden yazmadan delta tutarını saklayabilir.\n\nPara gönderdiğiniz her yere denetim alanları ekleyin:\n\n- created_at, created_by\n- reason_code (tahsil edilememe, yuvarlama, iyiniyet, chargeback)\n- source_system (manual, import, Stripe, support tool)\n\n## Kırılmadan krediler, iadeler ve silinmeler\n\nÇoğu uzlaşma sorunu, krediler ve iadelerin “negatif ödeme” olarak kaydedilmesi veya silinmelerin fatura satırlarına karıştırılmasıyla başlar. Temiz bir fatura defteri şeması her belge türünü kendi kaydı olarak tutar ve bunların etkileşimi yalnızca açık tahsislerle olur.\n\nBir kredi, müşterinin borcunu neden azalttığınızı göstermelidir. Tek bir faturaya uygulanıyorsa tek bir kredi notu kaydedin ve onu o faturaya tahsis edin. Birden fazla faturaya dağıtılması gerekiyorsa aynı kredi notunu birden çok faturaya tahsis edin. Kredi tek bir belge olarak kalır, birden çok tahsisi olabilir.\n\nİadeler ödeme benzeri olaylardır; negatif ödeme değildir. İade nakit çıkışı olduğundan kendi kaydı olmalıdır (çoğunlukla referans olarak orijinal ödemeyle ilişkilendirilir), sonra bir ödeme gibi tahsis edilir. Bu, banka ekstresinde hem gelen ödemeyi hem de çıkan iadeyi gördüğünüzde denetim izini net tutar.\n\nKısmi ödemeler ve kısmi krediler aynı şekilde çalışır: ödeme veya kredi toplamını kendi satırında tutun ve her faturaya ne kadar uygulandığını tahsis satırlarıyla gösterin.\n\n### Çift sayımayı önleyen gönderme kuralları\n\nBu kurallar çoğu “gizemli farkı” ortadan kaldırır:\n\n- Asla negatif ödeme saklamayın. Bir iade kaydı kullanın.\n- Gönderdikten sonra fatura toplamını azaltmayın. Kredi notu veya düzeltme kullanın.\n- Belgeleri bir kez gönderin (posted_at zaman damgası ile) ve gönderimden sonra tutarları düzenlemeyin.\n- Bir faturanın bakiyesini değiştiren tek şey gönderilmiş tahsislerin toplamı olsun.\n- Bir silme (write-off) sebep kodlu bir düzeltmedir ve fatura gibi tahsis edilir.\n\n## Vergiler, ücretler, para birimi ve yuvarlama seçimleri\n\nÇoğu uzlaşma problemi yeniden oluşturamadığınız toplamlarla başlar. En güvenli kural basittir: faturayı oluşturan ham satırları saklayın ve ayrıca müşteriye gösterdiğiniz toplamları da saklayın.\n\n### Vergiler ve ücretler: satır düzeyinde tutun\n\nVergi ve ücret tutarlarını sadece fatura düzeyinde özet olarak değil, satır başına saklayın. Farklı ürünler farklı vergi oranlarına tabi olabilir, ücretler vergilendirilebilir veya değil olabilir ve muafiyetler genellikle faturanın sadece bir kısmına uygulanır. Sadece tek bir tax_total saklıyorsanız açıklanamaz bir vaka ile karşılaşırsınız.\n\nSaklayın:\n\n- Ham satırlar (ne satıldı, miktar, birim fiyat, indirim)\n- Hesaplanmış satır toplamları (line_subtotal, line_tax, line_total)\n- Fatura özet toplamları (subtotal, tax_total, total)\n- Kullanılan vergi oranı ve vergi türü\n- Ücretleri kendi satırları olarak (ör. “Ödeme işlem ücreti”)\n\nBu, finansın toplamları yeniden kurup verginin her seferinde aynı şekilde hesaplandığını doğrulamasını sağlar.\n\n### Çoklu para birimi: ne olduğunu ve nasıl raporladığınızı saklayın\n\nBirden fazla para birimini destekliyorsanız, işlem para birimi ve raporlama para birimi değerlerini kaydedin. Pratik en az: her parasal belgeye currency_code, gönderim zamanında kullanılan fx_rate ve kapanış defteriniz bir para birimindeyse ayrı raporlama tutarları (ör. amount_reporting).\n\nÖrnek: bir müşteri 100.00 EUR ve 20.00 EUR KDV ile faturalandırıldıysa, bu EUR satırlarını ve toplamları saklayın, ayrıca faturayı gönderirken kullanılan fx_rate ve raporlama için çevrilmiş toplamları kaydedin.\n\nYuvarlama ayrı bir muamele gerektirir. Bir yuvarlama kuralı seçin (satır başına veya fatura başına) ve buna bağlı kalın. Yuvarlama farkı oluştuğunda, bunu bir yuvarlama düzeltme satırı (veya küçük bir düzeltme girdisi) olarak açıkça kaydedin; toplamları sessizce değiştirmeyin.\n\n## Durumlar, gönderim tarihler ve neyi gerçek olarak saklamamalı\n\nUzlaşma, bir “durum”u muhasebe gerçeği olarak kestirme yolla kullandığınızda karışır. Durumu iş akışı etiketi olarak görün; gönderilmiş defter girdilerini muhasebe gerçeği olarak görün.\n\nDurumları sıkı ve sıkıcı yapın. Her biri şu soruyu yanıtlamalı: bu belge artık toplamları etkileyebilir mi?\n\n- Draft: sadece dahili, gönderilmemiş, raporlara dahil edilmemeli\n- Issued: final ve gönderildi, gönderilmeye hazır (veya zaten gönderilmiş)\n- Void: iptal; gönderildiyse terslenmeli\n- Paid: gönderilmiş ödemeler ve kredilerle tamamen kapatılmış\n- Refunded: para gönderilmiş bir iade ile geri verilmiş\n\nTarihler çoğu ekip tarafından beklenenden daha önemlidir. Finans "Bu hangi aya aitti?" diye soracaktır ve cevabınız UI etkinlik günlüklerine dayanarak değişmemelidir.\n\n- issued_at: fatura ne zaman final olur\n- posted_at: ne zaman muhasebe raporlarına dahil olur\n- settled_at: fonlar ne zaman tahsil edildi veya ödeme onaylandı\n- voided_at / refunded_at: ters kaydın ne zaman etkili olduğu\n\nGerçek olarak saklamayın: defterden yeniden oluşturulamayan türetilmiş sayılar. balance_due, is_overdue ve customer_lifetime_value gibi alanlar sadece önbellek görünümü olarak uygundur; eğer bu değerleri her zaman invoices, payments, credits, allocations ve adjustments'dan yeniden hesaplayabiliyorsanız.\n\nKüçük bir örnek: bir ödeme yeniden denemesi ödeme ağ geçidine iki kez gönderildi. Bir idempotency anahtarınız yoksa iki ödeme saklarsınız, faturayı "ödenmiş" olarak işaretlersiniz ve finans fazladan 100 $ nakit görür. Her dış işlem denemesi için benzersiz bir idempotency_key depolayın ve veritabanı seviyesinde kopyaları reddedin.\n\n## Finansın ilk günden beklediği raporlar\n\nBir fatura defteri şeması kendini kanıtladığında finans temel soruları hızlıca sorup her seferinde aynı toplamları alabilir.\n\nÇoğu ekip şunlarla başlar:\n\n- Alacak yaşlandırması: müşteri bazında ve yaş aralıklarına göre açık tutarlar (0-30, 31-60 vb.)\n- Alınan nakit: ödeme gönderim tarihlerine göre günlük, haftalık, aylık toplanan nakit\n- Gelir vs nakit: gönderilmiş faturalar vs gönderilmiş ödemeler\n- Dışa aktarma için denetim izi: bir GL dışa aktarma satırından o satırı yaratan belge ve tahsis satırlarına geri geçiş yolu\n\nYaşlandırma tahsislerin en çok önem taşıdığı alandır. Yaşlandırma “fatura toplamı eksi ödemeler toplamı” değildir. “Belirli bir tarihte her faturada ne kadar açık bırakıldı”dır. Bu, her ödemenin, kredinin veya düzeltmenin hangi faturalara uygulandığını ve bu tahsislerin ne zaman gönderildiğini saklamayı gerektirir.\n\nAlınan nakit ödemeler tablosundan türetilmelidir, fatura durumundan değil. Müşteriler erken, geç veya kısmi ödeyebilir.\n\nGelir vs nakit, faturalar ve ödemelerin ayrı kalmasının nedenidir. Örnek: 30 Mart'ta 1.000 $ fatura düzenlersiniz, 5 Nisan'da 600 $ alırsınız ve 20 Nisan'da 100 $ kredi yaparsınız. Gelir Mart'a aittir (fatura gönderim tarihi), nakit Nisan'a (ödeme gönderim tarihi) ve kredi gönderildiğinde alacakları azaltır. Tahsisler bunları birbirine bağlar.\n\n## Örnek senaryo: bir müşteri, dört belge türü\n\nBir müşteri, bir ay, dört belge türü. Her belge bir kez saklanır ve para bir tahsis tablosu üzerinden akar (bazen “applications” olarak adlandırılır). Bu, nihai bakiyeyi yeniden hesaplamayı ve denetlemeyi kolaylaştırır.\n\nVarsayalım müşteri C-1001 (Acme Co.).\n\n### Oluşturduğunuz kayıtlar\n\ninvoices\n\n| invoice_id | customer_id | invoice_date | posted_at | currency | total |\n|---|---|---|---|---|---:|\n| INV-10 | C-1001 | 2026-01-05 | 2026-01-05 | USD | 120.00 |\n\npayments\n\n| payment_id | customer_id | received_at | posted_at | method | amount |\n|---|---|---|---|---|---:|\n| PAY-77 | C-1001 | 2026-01-10 | 2026-01-10 | card | 70.00 |\n\ncredits (kredi notu, iyiniyet kredisi vb.)\n\n| credit_id | customer_id | credit_date | posted_at | reason | amount |\n|---|---|---|---|---|---:|\n| CR-5 | C-1001 | 2026-01-12 | 2026-01-12 | service issue | 20.00 |\n\nadjustments (sonradan düzeltilmiş, yeni satış değil)\n\n| adjustment_id | customer_id | adjustment_date | posted_at | note | amount |\n|---|---|---|---|---|---:|\n| ADJ-3 | C-1001 | 2026-01-15 | 2026-01-15 | underbilled fee | 5.00 |\n\nallocations (aslında bakiyeyi uzlaştıran şey)\n\n| allocation_id | doc_type_from | doc_id_from | doc_type_to | doc_id_to | posted_at | amount |\n|---|---|---|---|---|---|---:|\n| AL-900 | payment | PAY-77 | invoice | INV-10 | 2026-01-10 | 70.00 |\n| AL-901 | credit | CR-5 | invoice | INV-10 | 2026-01-12 | 20.00 |\n\n### Fatura bakiyesi nasıl hesaplanır\n\nINV-10 için bir denetçi açık bakiyeyi kaynak satırlardan yeniden hesaplayabilir:\n\nopen_balance = invoice.total + sum(adjustments) - sum(allocations)\n\nYani: 120.00 + 5.00 - (70.00 + 20.00) = 35.00 borçlu.\n\n"35.00"ı geri izlemek için:\n\n- Fatura toplamından başlayın (INV-10)\n- Aynı faturaya bağlı gönderilmiş düzeltmeleri ekleyin (ADJ-3)\n- Faturaya uygulanan her gönderilmiş tahsisi çıkarın (AL-900, AL-901)\n- Her tahsisin gerçek bir kaynak belgeye işaret ettiğini doğrulayın (PAY-77, CR-5)\n- Zaman çizelgesini açıklamak için tarihleri ve posted_at değerlerini kontrol edin\n\n## Uzlaşmayı bozan yaygın hatalar\n\nÇoğu uzlaşma sorunu "matematik hatası" değil. Kurallar eksik—aynı gerçek dünya olayı, kime dokunulursa farklı kaydediliyor.\n\nYaygın bir tuzak, negatif satırları kestirme çözüm olarak kullanmaktır. Negatif fatura satırı, negatif ödeme ve negatif vergi satırı farklı şeyler ifade edebilir. Negatiflere izin veriyorsanız tek bir ters politika tanımlayın (ör. yalnızca orijinal satıra referans veren bir ters satır kullanın ve tersleme anlamını indirimlerle karıştırmayın).\n\nBir diğer sık neden geçmişi değiştirmektir. Bir fatura düzenlendiyse onu daha sonra yeni fiyat veya düzeltilmiş adrese uydurmak için düzenlemeyin. Orijinal belgeyi saklayın ve değişikliği açıklayan bir düzeltme veya kredi belgesi gönderin.\n\nGenellikle toplamları bozan kalıplar:\n\n- Bir referans olmadan negatif satırları kullanmak ve katı bir tersleme kuralı olmaması\n- Düzenlendikten sonra eski faturaları düzenlemek yerine düzeltme veya kredi göndermemek\n- Ağ geçidi işlem ID'lerini iç ID'lerle karıştırmak ve net bir kaynak belirlememek\n- Uygulama kodunun toplamları hesaplamasına izin verip destekleyici satırlar (vergi, ücret, yuvarlama, tahsisler) eksik bırakmak\n- "Para hareketi"(nakit hareketi) ile "paranın hangi faturaya uygulandığı"(tahsis) arasında ayrım yapmamak\n\nSon madde en çok karışıklığa yol açar. Örnek: bir müşteri 100 $ öder, sonra 60 $ Fatura A'ya, 40 $ Fatura B'ye uygulanır. Ödeme tek bir nakit harekettir, ama iki tahsis oluşturur. Eğer sadece “ödeme = fatura” saklarsanız kısmi ödemeleri, fazla ödemeleri veya yeniden tahsisi destekleyemezsiniz.\n\n## Kontrol listesi ve sonraki adımlar\n\nDaha fazla özellik eklemeden önce temel kuralların sağlam olduğundan emin olun. Bir fatura defteri şeması, her toplamın belirli satırlara izlenebildiği ve her değişikliğin denetim izi olduğu zaman uzlaşır.\n\n### Hızlı uzlaşma kontrolleri\n\nBunları küçük bir örnekte (bir müşteri, bir ay) ve sonra tüm verisetinde çalıştırın:\n\n- Bir rapordaki tüm gönderilmiş sayılar kaynak satırlara (fatura satırı, ödeme, kredi notu, düzeltme) gönderim tarihi ve para birimi ile izlenebiliyor mu?\n- Tahsisler uygulandıkları belgeyi aşmıyor mu (ödeme tahsisleri ödeme toplamından büyük değil; kredi için de aynı)?\n- Hiçbir şey silinmiyor. Yanlış girdiler sebep ile tersleniyor, sonra düzeltilmiş yeni bir gönderim yapılıyor.\n- Açık bakiye saklanmıyor, türetiliyor (fatura açık = fatura toplamı eksi gönderilmiş tahsisler ve krediler).\n- Belge toplamları satırlara uyuyor (fatura başlık toplamı satırların, vergilerin ve ücretlerin toplamına yuvarlama kuralınız uygulandıktan sonra eşit).\n\n### Kullanılabilir bir şeyi yayınlamak için sonraki adımlar\n\nŞemanız sağlam olduğunda, etrafına operasyonel iş akışını kurun:\n\n- Fatura, ödeme, kredi ve düzeltmeleri oluşturma, gönderme ve tersleme için gerekli notlarla yönetici ekranları\n- Belgeleri ve tahsisleri yan yana gösteren, kim ne zaman gönderdiğini içeren bir uzlaşma görünümü\n- Finansın beklediği dışa aktarmalar (gönderim tarihine göre, müşteriye göre, eğer varsa GL eşlemesi)\n- Dönem kapatma iş akışı: kapalı aylar için gönderim tarihlerini kilitleyin ve geç sapmalar için ters kayıt gerektirin\n- Beklenen sonuçlara uyan test senaryoları (iadeler, kısmi ödemeler, silinmeler)\n\nDaha hızlı bir yol istiyorsanız, AppMaster (appmaster.io) PostgreSQL şemasını modellemenize, API'ler üretmenize ve yönetici ekranlarını aynı kaynaktan oluşturmanıza yardımcı olabilir; böylece gönderme ve tahsis kuralları uygulama evrildikçe tutarlı kalır.",

"meta_description": "Ayrı faturalar, ödemeler, krediler ve düzeltmelerle finansın toplamları kolayca uzlaştırıp denetleyebileceği bir fatura defteri şeması nasıl tasarlanır öğrenin.", "slug": "uzlasan-fatura-defteri-semasi", "title": "Uzlaşan fatura defteri şeması: faturalar ve ödemeler" } oudste.