Turnover

data class Turnover(@Json(name = id) id: String?, @Json(name = transaction_id) transactionId: String?, @Json(name = booking_date) bookingDate: OffsetDateTime, @Json(name = amount) amount: Float, @Json(name = currency) currency: CurrencyId, @Json(name = purpose) purpose: List<String>, @Json(name = counter_iban) counterIban: String?, @Json(name = counter_bic) counterBic: String?, @Json(name = counter_holder) counterHolder: String?, @Json(name = prebooked) prebooked: Boolean?, @Json(name = canceled) canceled: Boolean?, @Json(name = tags) tags: List<Tag>?, @Json(name = category_id) categoryId: Category?, @Json(name = creditor_id) creditorId: String?, @Json(name = new) new: Boolean?)

Parameters

ID if feature is enabled always null otherwise.

transactionId

Transaction ID of this turnover if the bank supports it.

bookingDate

The booking date.

amount

The turnover amount. Negative for expenditures.

currency

The two-letter currency ID, e.g. 'EUR'

purpose

A string array of purpose lines. The contents vary from bank to bank.

counterIban

The counter IBAN of the booking. This is not always present.

counterBic

The counter BIC of the booking. This is not always present.

counterHolder

The counter holder of the booking. This is not always present.

prebooked

True, if the turnover has not been booked yet

canceled

True, if the turnover has been canceled.

tags

An array of strings of tags for this turnover. Find all possible tags here: https://manage.xs2a.com/documentation/tags

categoryId

The ID of the category found for this turnover. The structure of this category_id string is hierarchical, meaning, the more numbers there are, the more detailed the category is. For example, while K.1 means \"expenses for wholesale and retail trade\", some turnovers might be categorized more detailed as K.1.1 (\"expenses in retail stores\"), or even as K.1.1.1 (\"groceries full-range trader\"). You can find the complete list of categories here. NOTE: As new categories are introduced and the categorization itself is improved constantly, it is possible that the same turnover can be categorized with a different (more detailed) category_id at a future point in time. You should develop your application in such a way, that, for example, if your logic relies on something happening when a category_id is K.1.1, but you get K.1.2 for which no logic is in place (because it might be a new category_id or the turnover is now categorized more detailed), you should always fall back to the next higher level category, in this case K.1. This way, your logic can still handle the turnover based on a more general category, while not throwing an error.

creditorId

The ID of the creditor.

new

True, if this turnover is new since the last sync.

Constructors

Turnover

fun Turnover(@Json(name = id) id: String? = null, @Json(name = transaction_id) transactionId: String? = null, @Json(name = booking_date) bookingDate: OffsetDateTime, @Json(name = amount) amount: Float, @Json(name = currency) currency: CurrencyId, @Json(name = purpose) purpose: List<String>, @Json(name = counter_iban) counterIban: String? = null, @Json(name = counter_bic) counterBic: String? = null, @Json(name = counter_holder) counterHolder: String? = null, @Json(name = prebooked) prebooked: Boolean? = null, @Json(name = canceled) canceled: Boolean? = null, @Json(name = tags) tags: List<Tag>? = null, @Json(name = category_id) categoryId: Category? = null, @Json(name = creditor_id) creditorId: String? = null, @Json(name = new) new: Boolean? = null)

ID if feature is enabled always null otherwise.