JSON Import / Export - Schema Definition
See original GitHub issueZiel
Definition eines JSON Import und Export Formats für Buchungen.
Die Idee
- Strukturierter Input für den man dann (vielleicht) einfacher Scripts schrieben kann #1184
- Besseres Format als CSV um komplexere Buchungen mit Fremdwährungen abzubilden
- Konto-/ und Depotbuchungen nicht unterscheiden (die Unterscheidung im Programm ist historisch so gewachsen und mit den “CrossEntry” fühlt sie sich umständlich an. Dass will ich nicht nach außen exponieren).
JSON Schema
{
"title": "JSON schema for Portfolio Performance Transactions",
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "array",
"items": {
"description": "Transaction",
"type": "object",
"additionalProperties": false,
"required": [
"type",
"date",
"amount",
"currency"
],
"properties": {
"type": {
"type": "string",
"enum": [
"PURCHASE",
"SALE",
"INBOUND_DELIVERY",
"OUTBOUND_DELIVERY",
"SECURITY_TRANSFER",
"CASH_TRANSFER",
"DEPOSIT",
"REMOVAL",
"INTEREST",
"DIVIDEND",
"TAX",
"FEE"
]
},
"account": {
"type": "string"
},
"portfolio": {
"type": "string"
},
"target-account": {
"type": "string"
},
"target-portfolio": {
"type": "string"
},
"date": {
"type": "string",
"pattern": "^[1-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]$"
},
"time": {
"type": "string",
"pattern": "[0-2][0-9]:[0-5][0-9]$"
},
"amount": {
"type": "number"
},
"currency": {
"type": "string",
"pattern": "^[A-Z]{3}$"
},
"note": {
"type": "string"
},
"shares": {
"type": "number"
},
"security": {
"type": "object",
"additionalProperties": false,
"minProperties": 1,
"properties": {
"uuid": {
"type": "string"
},
"isin": {
"type": "string"
},
"wkn": {
"type": "string"
},
"name": {
"type": "string"
}
}
},
"units": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"type",
"amount"
],
"properties": {
"type": {
"type": "string",
"enum": [
"GROSS_VALUE",
"FEE",
"TAX"
]
},
"amount": {
"type": "number"
},
"exchange-rate": {
"type": "number"
},
"forex": {
"type": "number"
},
"currency": {
"type": "string",
"pattern": "^[A-Z]{3}$"
}
}
}
}
}
}
}
Beispieldatei
[
{
"type" : "PURCHASE",
"account" : "Cash Account",
"portfolio" : "Security Account",
"target-account" : "Other Cash Account",
"target-portfolio" : "Other Securities Account",
"date" : "2019-01-01",
"time" : "15:06",
"amount" : 345.43,
"currency" : "EUR",
"note" : "free note",
"shares" : 1.2929293,
"security" : {
"uuid" : "YZW",
"isin" : "DE...",
"wkn" : "A0YDZE",
"name" : "Name"
},
"units" : [
{
"type" : "FEE",
"amount" : 224.17,
"exchange-rate" : 1.120202,
"forex" : 200.12,
"currency" : "USD"
},
{
"type" : "TAX",
"amount" : 12.34
}
]
}
]
Pflichtfelder / Optional Felder
R = Required / Pflichtfeld
O = Optional
- = nicht erlaubt
O* = Optional mit oder ohne Fremdwährung
C? = Pflichtfeld Wertpapie/Kontowährung unterschiedlich sind
PURCHASE, SALE | SECURITY TRANSFER | INBOUND, OUTBOUND DELIVERY | CASH TRANSFER | DEPOSIT, REMOVAL | INTEREST | TAX, FEE | DIVIDEND | |
---|---|---|---|---|---|---|---|---|
type | R | R | R | R | R | R | R | R |
account | R | - | - | R | R | R | R | R |
portfolio | R | R | R | - | - | - | - | - |
target-account | - | - | - | R | - | - | - | - |
target-portfolio | - | R | - | - | - | - | - | - |
date | R | R | R | R | R | R | R | R |
time | O | O | O | - | - | - | - | - |
amount | R | R | R | R | R | R | R | R |
currency | R | R | R | R | R | R | R | R |
note | O | O | O | O | O | O | O | O |
shares | R | R | R | - | - | - | - | O |
security | R | R | R | - | - | - | O | R |
unit GROSS_VALUE | C? | - | C? | C? | - | - | - | C? |
unit FEE | O* | - | O* | - | - | O | - | - |
unit TAX | O* | - | O* | - | - | O | - | O* |
- Natürlich sind
account, portfolio, target-account, target-portfolio
optional, d.h. sie könnten in dem “ReviewImportedItems” vervollständigt werden - Bei den Konten/Depots würde man eine Mustererkennung machen - wenn der Name stimmt, dann nimmt man den Namen.
- Analog beim Wertpapier - mindestens ein Feld muss angegeben werden und damit wird nach existierenden Wertpapiere gesucht.
Andere Überlegungen
- FEE, TAX, INTEREST würde man Minuszeichen festmachen, ob es eine Gebühr oder eine Gebührenerstattung ist
- Ähnlich könnte man Kauf/Verkauf am Minuszeichen festmachen - ich tendiere aber dazu, dass ebenfalls als separate Buchungstypen zu definieren (analog zu Einlage/Entnahme)
- Man könnte PURCHASE und INBOUND_DELIVERY nicht an einem separaten Typ unterscheiden, sondern einfach daran ob ein Konto angegeben ist (Kauf) oder nicht (Einlieferung). Ich tendiere aber dazu, dass separate Typen zu machen.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:13 (7 by maintainers)
Top Results From Across the Web
Schema export and import
Exporting schema downloads a JSON file containing the entity metadata on your local machine. You may share the file to be imported by...
Read more >JSON Schema | The home of JSON Schema
JSON Schema is a declarative language that allows you to annotate and validate JSON documents. JSON Schema enables the confident and reliable use...
Read more >Import/export JSON schema for models - DatoCMS community
I noticed that dato uses a json-schema definition for validating the structure of your own API.
Read more >Schema Definition Export and Import - RabbitMQ
Definition import on node boot is the recommended way of pre-configuring nodes at deployment time. Definition Export. Definitions are exported as a JSON...
Read more >Data I/O: JSON Import and Export - RAI Documentation
Importing Local JSON Files · Upload the file as a string to a named relation, for example, mydata . · Use def config:data...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Nein. Erstens bestehen schon viele Importer - die müssen bestehen bleiben. Zweitens glaube ich, dass man bei komplexeren Importen trotzdem mit Java, mit Tests, etc. arbeiten möchte. Ich sehe das als eine weitere Möglichkeit.
Vielleicht sollten wir das in einem anderen Issue diskutieren. Was mir nicht klar ist: wenn Du nur einen Betrag hast, kannst Du den dann nicht so berechnen und dann setzen, dass der passt. Ansonsten muss PP später umrechnen - und dann entstehen die Rundungsfehler. Wir können auch die Prüfung ein bisschen auflockern - es stimmt schon, dass bei kleinen Werten sehr leicht Abweichungen entstehen können.
Verwandtes Thema: #2085