Payment
Payment (płatność) to zasób reprezentujący operację płatności za dokument (najczęściej fakturę). Niesie datę, kwotę, sposób zapłaty, rachunki oraz powiązanie z dokumentem źródłowym; model przewiduje też pola statusu rozliczenia, kontroli AML i mechanizmu podzielonej płatności (MPP). Identyfikacja przez Identifier, strony przez Party / 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 w standardzie Kamsoft.FAIR (Fast Adaptive Interoperable Resources).
1. Zakres i zastosowanie
Payment = jedna operacja pieniężna (wpływ lub wypływ) powiązana z dokumentem. Zasób jest tylko do odczytu: API udostępnia płatności zarejestrowane w księgowości; nie ma operacji tworzenia ani zmiany statusu.
Jeden Payment może dotyczyć:
- jednej faktury – pełna lub częściowa płatność,
- wielu dokumentów – konsolidacja (wiele elementów sourceDocument),
- zaliczki – bez powiązania z konkretnym dokumentem.
2. Zawartość (struktura)
Oprócz elementów DomainResource (id, resourceType, meta, owner[], comment, category[], status, type, contained[], attribute[]):
| Nazwa | Kard. | Typ | Opis |
|---|---|---|---|
| identifier | 0..* | Identifier | Identyfikatory płatności; w odczycie id płatności w księgowości w przestrzeni PaymentReconciliation.Id (urn:oid:1.2.616.1.113769.4.<instalacja>.61) |
| date | 0..1 | date | Data operacji płatności |
| party | 0..* | Reference(Party | PartyRole) | Uczestnicy płatności (płacący, odbiorca) |
| amount | 0..1 | Money | Kwota (w odczycie w PLN) |
| paymentMethod | 0..1 | CodeableConcept | Sposób zapłaty; system finance/payment-method — kody nadaje wdrożenie |
| paymentAccount | 0..1 | Reference(BankAccount) | Rachunek płatnika |
| recipientAccount | 0..1 | Reference(BankAccount) | Rachunek odbiorcy |
| sourceDocument | 0..* | Reference | Dokumenty źródłowe (np. faktura); w odczycie referencja po numerze dokumentu (identifier w przestrzeni DocumentReference.Id) |
| splitPayment | 0..1 | boolean | Mechanizm podzielonej płatności (MPP) |
| reconciliationStatus | 0..1 | CodeableConcept | Status rozliczenia; system finance/payment-reconciliation-status — kody nadaje wdrożenie |
| amlCheckStatus | 0..1 | CodeableConcept | Status kontroli AML; system finance/payment-aml-check-status — kody nadaje wdrożenie |
| amlCheckDate | 0..1 | dateTime | Data kontroli AML |
| relatedPayment | 0..* | Reference(Payment) | Płatności powiązane (np. storno) |
Pola dziedziczone: type i status — CodeableConcept, kody nadaje wdrożenie; attribute[] (Attribute: code + value[]) w systemie finance/payment-attribute-type — w odczycie atrybut issue-date (data wystawienia dokumentu płatności, valueString).
Żadne pole nie jest wymagane przez schemat JSON.
3. Operacje
| Metoda | Ścieżka | Opis |
|---|---|---|
| GET | /v1/payments |
Płatności dokumentów (tylko odczyt) |
Odpowiedź: { "items": [...], "nextToken": null }; paginacja count (domyślnie 20) i offset (domyślnie 0).
| Parametr | Wymagany | Format | Opis |
|---|---|---|---|
identifier |
nie | system\|value |
Id płatności w przestrzeni PaymentReconciliation.Id |
owner |
nie | system\|value |
Firma po NIP: https://gov.pl/nip\|<NIP> |
attribute |
nie | code\|value |
symbol\|<symbol> — symbol bufora dokumentu, którego dotyczą płatności |
Błędny format parametru → 400 Problem Details (type = https://httpstatuses.com/400).
4. Wymagania prawne
Ustawa o podatku od towarów i usług (VAT), art. 108a (mechanizm podzielonej płatności – MPP):
- jeśli transakcja podlegała MPP, splitPayment = true,
- kwota VAT kierowana na dedykowany rachunek VAT.
Dyrektywa (UE) 2015/849 (AML) ze zmianami 2018/843:
- dla płatności powyżej progu – obowiązkowe sprawdzenie kontrahenta na listach sankcyjnych; wynik w amlCheckStatus, data w amlCheckDate.
5. Relacje do pozostałych zasobów
- party[] → Party / PartyRole (płacący, odbiorca)
- paymentAccount, recipientAccount → BankAccount
- sourceDocument[] → dokument płacony (Invoice lub dokument w buforze księgowym — PostingInstruction)
6. Zgodność z systemami wzorcowymi
| System | Odpowiednik | Uwagi |
|---|---|---|
| SAP | F-28 (Payment Run), Check Register | REGUH (run), 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 |
7. Przykład (odczyt)
{
"resourceType": "Payment",
"identifier": [
{
"system": "urn:oid:1.2.616.1.113769.4.<instalacja>.61",
"value": "48213"
}
],
"date": "2026-03-05",
"amount": { "value": 12300.00, "currency": "PLN" },
"attribute": [
{
"code": { "coding": [{ "system": "https://api-erp.kamsoft.pl/vs/finance/payment-attribute-type", "code": "issue-date" }] },
"value": [{ "valueString": "2026-02-20" }]
}
],
"sourceDocument": [
{
"identifier": { "system": "urn:oid:1.2.616.1.113769.4.<instalacja>.62", "value": "FV/2026/0567" },
"display": "Nr dokumentu"
}
]
}
Przestrzenie OID w przykładach niosą placeholder <instalacja> — gotową przestrzeń przekazuje KAMSOFT w parametrach wdrożenia.
8. Odniesienia
- DomainResource, Invoice, PartyRole, Party
- BankAccount
- Identifier, CodeableConcept, Reference, Money
- Attribute
- Ustawa o VAT, art. 108a (MPP – mechanizm podzielonej płatności)
- Dyrektywa (UE) 2015/849 (AML/CFT, ze zmianami 2018/843)