transmitToSocialFactoring

Uploads a residential park's invoices to SozialFactoring.

The invoices are split into one FactoJson file per IK they were billed under, because SozialFactoring accepts exactly one IK per file. A park billing both ambulant and Tagespflege therefore uploads two files, and the payload carries one entry per file.

The transmission is all or nothing. Only if every file comes back UPLOADED do the invoices become TRANSMITTED and transmitted is true. If any file is REJECTED or FAILED, the files already accepted are deleted from SozialFactoring again and become WITHDRAWN, and no invoice changes its status. A withdrawal that fails leaves its file UPLOADED: the file is then still at SozialFactoring, while transmitted stays false and the refusal remains the outcome.

A file SozialFactoring refuses is **not** an error of this mutation. Their API answers a refusal with its reasons, which arrive as the file's validationErrors. Only a refusal on our side — e.g. a park without a SozialFactoring account — fails the mutation.

Upload only. The file is approved afterwards in SozialFactoring's own app, not by us.

Invoices already TRANSMITTED are skipped rather than sent again. All invoices must belong to parkId, and the park must have SozialFactoring switched on.

Requires authorization features: billing:factoring:send

transmitToSocialFactoring(
  input: TransmitToSocialFactoringInput!
): TransmitToSocialFactoringPayload!

Directives

auth

Requires authorization features: billing:factoring:send

Arguments

transmitToSocialFactoring.input ● TransmitToSocialFactoringInput! non-null input

Type

TransmitToSocialFactoringPayload object

Payload of the transmitToSocialFactoring mutation.