Natvrdo zadané PaymentMethodId ve fakturačním API vybírá špatnou metodu (hotově místo převodu)

import { Aside } from ‘@astrojs/starlight/components’;

Symptom

Účetní hlásí, že všechny faktury vystavené přes API do externího fakturačního systému nesou způsob platby „hotově” (v lokálním jazyce systému), přestože zákazníci platí převodem. Vystavování přitom prochází bez chyb.

Root cause

Integrace posílala v hlavičce faktury natvrdo PaymentMethodId: 2. Toto číselné ID je interní pořadové číslo záznamu v konkrétním účtu — u tohoto účtu ukazovalo na platební metodu typu „hotovost”. Dvě pasti:

Číselné ID neodpovídá kódu platebního prostředku (payment means code) ani ničemu přenositelnému mezi účty; sken ID 1–8 přes preview endpoint ukázal jediné platné ID, právě to hotovostní.
Správný výběrový mechanismus byl jinde: WSDL nabízí polymorfní element banky, kde se metoda vybírá pojmenovaným identifikátorem záznamu:

<!-- špatně: interní číselné ID, na účtu = hotovost -->
<PaymentMethodId>2</PaymentMethodId>

<!-- správně: výběr záznamu pojmenovaným identifikátorem -->
<Bank xsi:type="BankIdentifier">
  <Identifier>TRANSFER_1</Identifier>
</Bank>

Pozor na WCF/SOAP striktní pořadí elementů dle XSD (Identifier před volitelným popisem) — přehozené pořadí endpoint tiše odmítne nebo ignoruje.

Fix

Výpis platebních metod účtu přes API (dotaz na data existující faktury vrací i seznam metod účtu) → potvrzeno, že ID 2 = záznam typu hotovost.
Přes API založena nová metoda typu převod (SavePaymentMethod) s vlastním identifikátorem.
V kódu nahrazeno hardcoded číselné ID výběrem přes Bank xsi:type="BankIdentifier" + identifikátor; validováno přes preview endpoint (nevytváří doklad), který vrací stejné validační kódy jako ostré vystavení.

Jak testovat bez vzniku dokladů

Fakturační SOAP API často nabízí preview operaci — projde kompletní validací hlavičky (vč. platební metody), ale nevytvoří číslovaný doklad. Ideální pro zkoušení variant proti ostrému účtu.

Přidal aiarchitekt.cz · 5. 7. 2026 2:00

Provozuje aiarchitekt.cz