Para ve fatura

Tahsilat, cari ve belge

Siparişin bedeli üç yerde izlenir: ödeme kaydı, cari bakiye, fatura. Bunlar aynı tutarın kopyası değil, farklı sorulara cevap verir.

Ödeme: “Kart / havale bu sipariş için geçti mi?”
Cari: “Bu kullanıcının bu depodaki bakiyesi nedir?”
Fatura: “Yasal belge kesildi mi?”

`payment`

Görevi: Ödeme sağlayıcıları ve Mongo payments belgesi.

Yollar herkese açıktır (sağlayıcı geri bildirimi): payment, payment/magicpay, payment/paytr, payment/paywall.

Sipariş üzerindeki ödeme bloğu (purchase) sipariş belgesinin içindedir. payments koleksiyonu sağlayıcı işleminin kendisidir: platform, tutar, durum, işlem no, sipariş id.

Başarılı veya başarısız güncelleme payment.updated olayını üretir; dinleyici siparişi ödenmiş veya başarısız yapar. Akış: Ödeme.

`financial`

Görevi: Cari.

Yol	Erişim
`financial/user`	Kimliği doğrulanmış (depo erişimi olan)
`financial/admin`	Yönetici
`financial/officer`	Yetkili

Bakiye Prisma FinancialAccount tablosundadır: kullanıcı + isteğe bağlı depo, balance, creditLimit, kasa (boxBalance) ve palet (palletBalance) sayaçları. Pozitif bakiye alacak, negatif borç anlamına gelir (şema yorumu).

Hareket Mongo accountTransactions koleksiyonundadır: tutar, işlem sonrası bakiye, tip, referans, vade, onay durumu. Tip listesi ve Türkçe etiketler Cari ve fatura sayfasındadır.

Sipariş, iade, kapı tahsilatı ve stok alımı sistem tiplerini otomatik üretir. Kampanya ödülleri (REWARD) kayıt, teslim ve günlük taramayla da yazılır. Elle girilebilen çekirdek tipler kodda ayrı listedir (transfer, ödül, telafi, düşüm); ödül hem elle hem kampanya akışında kullanılabilir.

v2 `finance` domain'i

Yeni /finance/* yüzeyi cariyi tek modülün ötesine genişletir:

LedgerService, v2 içindeki accountTransactions ve FinancialAccount.balance yazmalarının kapısıdır. v1 de geçiş boyunca aynı kayıtlara kendi yollarından yazabilir.
MoneyBookService, MoneyAccount bakiyesiyle ilişkili MoneyMovement ve ödemeyi aynı işlemde yazar.
Expense genel gideri, PayablePayment gider veya cari satırına yapılan ödemeyi tutar.
POS mutabakatı ve kasa devri ayrı Prisma modelleriyle izlenir.

Yeni yazma/onay uçlarının çoğu @FinanceRoles() ve depo kapsamı kullanır; bazı okuma ve taşınmış v1 uçlarının rol sınırı farklıdır. Mimari ayrım: v2 mimarisi. Veri modelleri: Cari, kasa ve fatura numarası.

Ödül tanımları

Ödül kartı Prisma tablosu değildir. RewardDefinition alanları kod listesindedir: id, code, name, amount, isteğe bağlı warehouseId, dependsOn, groupId, tarama eşikleri, startDate, endDate, isActive.

Alıcı kaydı doğrudan servis çağırmaz; buyer.signup-reward olayını yayınlar. İlk/ikinci teslim buyer-order.changed üzerinden, geri kazanım 09:00 cron’u ile yazılır. Sepet önizlemesi son hareketlerden hediye bakiyesi mesajı kurabilir. Tam tablo: Ödüller.

`invoice`

Görevi: Kesilmiş veya gelen e-belge kaydı.

Yol	Niyet edilen rol
`invoice/buyer`	Alıcı (rol bekçisi var)
`invoice/admin`, `invoice/officer`	Yönetici / yetkili (etiket var, rol bekçisi yok)

Giden fatura invoices, gelen tedarikçi belgesi platformInvoices. Sağlayıcı enum’u yalnız IZIBIZ. Belge tipi: e-fatura, e-arşiv, makbuz. Numara üretimi Prisma InvoiceSequence (tip + önek + yıl).

Sipariş belgesine gömülen invoice özeti, yasal belgenin kısa kopyasıdır. Asıl UBL / sağlayıcı yanıtı fatura koleksiyonundadır.

Akış: Fatura ve HKS.

Siparişteki ödeme kırılımı

Satın alma, sipariş belgesine purchase nesnesini yazar. Burada yöntem (CARD, TRANSFER, ACCOUNT; enum’da duran CASH / CHECK alıcıya sunulmaz), çevrimiçi/çevrimdışı tipi, satır kalemleri, kargo, taksit, cari kullanımı, grup indirimi kopyası ve net toplam durur. Kapıda tahsilat transfer belgesindeki collectedPayments ile de izlenir. Nakit kapı tahsilatı kabul edilmez.

payment

financial