Create transactions

[ekoskent]

As a: business owner / user of a business system
I wish to: create accounting entries (business transactions) in another system outside the actual accounting system and record them in the accounting system.

[ekoskent]

For instance POS systems transfer the accounting entries generated from sales at the end of business day directly as accounting entries including already the account details etc (not by using indivudual sales receipts as vouchers although this is also possible)

[ekoskent]

We should create add to the transaction API "Create transaction" (similar than the update transaction). Once the transactions are posted to the system (as xbrl gl) the internal transaction ID should be assigned to them. Should we require that some voucher(pdf) should be posted in the system before the transactions may be created (would it violate the data base logic if there would be no voucher/business document)?

[frodegill]

FWIW, you should now be able to upload an XBRL GL document (to /document/{companyId}) and have a transaction created for it.

[ekoskent]

FWIW, you should now be able to upload an XBRL GL document (to /document/{companyId}) and have a transaction created for it.

Should it not be by the transaction API (not document) to create a new transaction by posting XBRL GL data?

[frodegill]

No? You post a document (which happens to be an XBRL GL document).

[ekoskent]

No? You post a document (which happens to be an XBRL GL document).

Aa ok, so the XBRL GL data then becomes the voucher document as well? This is ok, but I am able to use the "regular" business document formats still? There was some issues when I tried to add a UBL invoice as a new doc.

[frodegill]

The XBRL GL document will be the one document that creates the transaction, but it will not be split up and/or parsed. Just remember to use correct(/matching) mime-types

[ekoskent]

The XBRL GL document will be the one document that creates the transaction, but it will not be split up and/or parsed. Just remember to use correct(/matching) mime-types

Will do. Speaking of which, should the options be listed also in the API .yaml definitions? I noticed that the response notification from the bad request was not always matching to what the yaml file was saying and also in the notification there was some issue with the provided mime type list, the quote marks were in the correct place etc..

[frodegill]

There are two places where I have to specify "/" as mime-type in the OpenAPI spec, but the code implementing it generates a list of valid(/expected) mime-types. I've tried to get this into Swagger, but so far failed. Are there any other issues you feel is present? Quote marks in incorrect place, I presume? Do you have a screenshot or a way for me to recreate it?

[ekoskent]

Hi, here is the printscreen where the mimetype list has the " errors. Or I see it's not really an error but it makes you look like the entire contents between the "" is the mime type (there are extra \ chars in both ends). [image: image.png] ma 9. maalisk. 2020 klo 11.35 Frode Roxrud Gill ([email protected]) kirjoitti:

…

There are two places where I have to specify "*/*" as mime-type in the OpenAPI spec, but the code implementing it generates a list of valid(/expected) mime-types. I've tried to get this into Swagger, but so far failed. Are there any other issues you feel is present? Quote marks in *incorrect* place, I presume? Do you have a screenshot or a way for me to recreate it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#26?email_source=notifications&email_token=AJXWFCMVSV5ESKYFNGGIQ4DRGSZ7VA5CNFSM4KMQRVO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOGLJXQ#issuecomment-596423902>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJXWFCNOBSLQM22SMMMPAQLRGSZ7VANCNFSM4KMQRVOQ> .

[ekoskent]