Przejdź do treści

Payment

Payment (płatność) to dedykowany dokument reprezentujący realizację płatności za zobowiązanie (najczęściej Invoice). Zawiera informacje o płacącym, odbiorcy płatności, kwocie, dacie, metodzie (przelew, karta, gotówka) oraz statusie (pending, autoryzacja, wykonana, rozliczona). Może zawierać flagi dla wymogów AML/CFT (anti-money laundering/combating financing of terrorism) oraz MPP (mechanizm podzielonej płatności). Jest połączonym dokumentem między Invoice a LedgerEntry (bank account debited/credited). Identyfikacja przez Identifier, strony przez PartyRole, rachunki bankowe przez BankAccount. Wzorowany na SAP (F-28, Check/Payment), Oracle (AP Payments, AR Cash Receipts), UBL 2.3 (PaymentMeans).

Rozszerza DomainResource. Zasób z pakietu Kamsoft.FAIR (Fast Adaptive Interoperable Resources).

1. Zakres i zastosowanie

Payment = jeden dokument reprezentujący jedną operację pieniężną (wpłynięcie lub wypłynięcie). Cykl życia:

  • pending → przygotowana, oczekiwanie na autoryzację
  • authorized → zatwierdzona przez właściwą Duty (approve-payment, approve-large-payment)
  • posted → zaksięgowana (wpływ na GL: Dr./Cr. Bank Account, Cr./Dr. Accounts Payable/Receivable)
  • settled → pomyślnie wykonana z potwierdzeniem banku
  • cancelled → anulowanie (jeśli błąd lub cofnięcie)

Jeden Payment może dotyczyć: - Single Invoice – pełna/częściowa płatność jednej faktury - Multiple Invoices – konsolidacja (zapłata wielu faktur jednym przelewem) - Advance Payment – wpłata zaliczki bez powiązania do konkretnej faktury

2. Zawartość (struktura)

Oprócz elementów DomainResource (id, meta, text, comment, category, status, type, contained, attribute):

Nazwa Kard. Typ Opis
identifier 1..* Identifier ID płatności (np. PYMT-2026-001); system = uuid, value = numer
type 1..1 CodeableConcept payment-out (wydanie), payment-in (wpłynięcie) (system: payment-type)
date 1..1 date Data wykonania/realiza płatności (dzień transakcji bankowej)
party 2..* Reference(PartyRole) [0] = płacący (Role: payer), [1] = odbiorca (Role: payee)
amount 1..1 Money Kwota płatności (waluta + wartość)
paymentMethod 1..1 CodeableConcept bank-transfer, cash, card, check, mandate (system: payment-method)
paymentAccount 0..1 Reference(BankAccount) Rachunek płacącego (z którego płaci)
recipientAccount 0..1 Reference(BankAccount) Rachunek odbiorcy (na który wpłynięcie)
status 1..1 CodeableConcept pending, authorized, posted, settled, cancelled
sourceDocument 0..* Reference(Invoice) Powiązana faktura/y (może być wiele dla konsolidacji)
splitPayment 0..1 boolean AML/MPP: true jeśli dotyczy mechanizmu podzielonej płatności (art. 119a VAT)
reconciliationStatus 0..1 CodeableConcept unmatched, partially-matched, fully-matched, over-paid
amlCheckStatus 0..1 CodeableConcept AML Screening: pending, passed, flagged, failed (sanctions check)
amlCheckDate 0..1 dateTime Data wykonania sprawdzenia AML (sanctions list verification)
attribute 0..* Attribute Dodatkowe atrybuty (np. bank-fee, exchange-rate)
relatedPayment 0..* Reference(Payment) Płatności powiązane (np. reversal, amendment)

3. Przepływ biznesowy

1. Invoice posted (status=settled) → Outstanding Payable
   ↓
2. Finance team tworzy Payment (status=pending)
   - Wybiera Invoice(s) do zapłaty
   - Wybiera payment method (bank transfer, cash, etc.)
   - Wprowadza paymentAccount (z którego konto) + recipientAccount (docelowo)
   ↓
3. System automatycznie:
   - Sprawdzanie AML (sanctions screening) – jeśli skipPayment=true, sprawdzenie obowiązkowe
   - Validacja kwot (nie przekraczają outstanding)
   - Approve routing (RBAC Duty: approve-payment < €10k, approve-large-payment > €10k)
   ↓
4. Approval chain (jeśli kwota powyżej threshold)
   status → authorized
   ↓
5. Posted to GL:
   - Dr. Accounts Payable (zmniejszenie zobowiązania)
   - Cr. Bank Account (zmniejszenie gotówki)
   ↓
6. Bank processing (external):
   - Wysłanie do banku (MT103, SEPA, etc.)
   - Bank potwierdza: executed, bounce, etc.
   ↓
7. Bank reconciliation (daily):
   - Match against bank statement
   - status → settled (jeśli fully matched)
   ↓
8. End of period → Ready for financial reporting

4. Wymagania prawne

Ustawa o podatku od towarów i usług (VAT), Art. 119a (Mechanizm Podzielonej Płatności – MPP): - Pola flagi: Jeśli transakcja podlegała MPP, Payment musi zawierać splitPayment = true - Segregacja: Kwota VAT kierowana na dedykowane konto VAT (Obcy) w banku - Raportowanie: Informacja o MPP w raporcie do KSeF - Obligatoryjność: MPP obowiązkowa dla B2B transakcji od 1 czerwca 2024 r. (z wyjątkami)

EU Directive 2015/849 (Anti-Money Laundering) as amended by 2018/843: - AML Screening: Dla Payment > €10.000 (lub równowartość) – obowiązkowe sprawdzenie kontrahenta against: - OFAC (US Specially Designated Nationals List) - EU sanctions list (FSB, ścieżka westwardna) - UN Security Council sanctions - Krajowa lista ścieżki - Record Retention: Dokumentacja AML przez minimum 5 lat - Beneficial Owner Verification: Dla party kwoty > €10.000 – wymagana identyfikacja rzeczywistego beneficjenta

Kodeks Handlowy (ustawa o ochronie konkurencji i konsumentów): - Prawo do zwrotu pieniędzy (w case of defects) – Payment może być reversed

COSO / IIA (Internal Controls): - Payment segregacja: approver ≠ processor ≠ reconciler (three-way control) - Audit trail (metadata: kto, kiedy, zmiana)

5. AML/CFT Integration (Advanced)

Scenario AML Check Decision Action
Payment < €10k Automatic (low-risk countries) passed → proceed Auto-authorise
Payment > €10k Full sanctions screening passed → proceed Require manual approval
Payment to Russia (post-2022) High-risk jurisdiction flagged → hold Hold + escalate to Compliance
Payment party listed (OFAC) Critical hit failed → block Reject + alert authority
Payment to unknown entity Medium risk flagged → review Manual review by compliance team

6. Relacje do pozostałych zasobów

  • party[0] (payer) → PartyRole (Role: payer) → Party (płacący)
  • party[1] (payee) → PartyRole (Role: payee) → Party (odbiorca)
  • paymentAccount → BankAccount (rachunek płacącego)
  • recipientAccount → BankAccount (rachunek odbiorcy)
  • sourceDocument → Invoice (powiązana faktura/y)
  • Creates LedgerEntry (2 entries):
  • Dr. Accounts Payable / Cr. Bank Account (payment-out)
  • Or: Dr. Bank Account / Cr. Accounts Receivable (payment-in)
  • reconciliationStatus aktualizuje się based on bank reconciliation (daily)

7. Zgodność z systemami wzorcowymi

System Odpowiednik Uwagi
SAP F-28 (Payment Run), Check Register REGUH (rund), ZBA (treasury)
Oracle AP Payments, AR Cash Receipts Payment instrument (check, EFT)
UBL 2.3 PaymentMeans + PaymentTerms Party role: payer/payee
D365 Vendor Payment, Customer Payment BankTransactionType

8. Przykład

{
  "resourceType": "Payment",
  "id": "pymt-2026-001",
  "identifier": [
    {
      "system": "urn:uuid:kamsoft-erp",
      "value": "PYMT-2026-001"
    },
    {
      "system": "urn:bank:swift",
      "value": "MT103:2026030512345"
    }
  ],
  "type": {
    "coding": [{
      "system": "https://api-erp.kamsoft.pl/ns/payment-type",
      "code": "payment-out"
    }]
  },
  "status": "settled",
  "date": "2026-03-05",
  "party": [
    {
      "reference": "PartyRole/role-payer-kamsoft",
      "display": "KAMSOFT sp. z o.o. (Payer)"
    },
    {
      "reference": "PartyRole/role-payee-techsupply",
      "display": "TechSupply Ltd (Payee)"
    }
  ],
  "amount": {
    "value": 50000,
    "currency": "EUR"
  },
  "paymentMethod": {
    "coding": [{
      "system": "https://api-erp.kamsoft.pl/ns/payment-method",
      "code": "bank-transfer"
    }]
  },
  "paymentAccount": {
    "reference": "BankAccount/ba-kamsoft-mbank",
    "display": "KAMSOFT – mBank Enterprise (PLN)"
  },
  "recipientAccount": {
    "reference": "BankAccount/ba-techsupply-natixis",
    "display": "TechSupply – Natixis (EUR)"
  },
  "sourceDocument": [
    {
      "reference": "Invoice/INV-2026-5001",
      "display": "Invoice INV-2026-5001"
    }
  ],
  "splitPayment": false,
  "amlCheckStatus": {
    "coding": [{
      "code": "passed"
    }]
  },
  "amlCheckDate": "2026-03-05T08:30:00Z",
  "reconciliationStatus": {
    "coding": [{
      "code": "fully-matched"
    }]
  }
}

9. Odniesienia