Add conversion transaction examples #63
Conversation
| "security_id": "2936wa8yefhdsvcn", | ||
| "date": "2022-01-20", | ||
| "comments": ["comment-one", "comment-two", "..."] | ||
| }, |
There was a problem hiding this comment.
The general approach I took was to have two versions of each transaction, a -minimal and a -all-fields example.
| "security_id": "test-security-id", | ||
| "date": "2019-01-31", | ||
| "amount": { | ||
| "amount": "53.09", | ||
| "currency": "USD" | ||
| }, | ||
| "reason_text": "for testing", | ||
| "comments": ["just a comment"] | ||
| "balance_security_id": "new-security", | ||
| "comments": ["comment-one", "comment-two", "..."] |
There was a problem hiding this comment.
Optional fields are always added after the required fields to hopefully make maintaining the two easier.
I am curious if some kind of generator exists.
| "rounding_type": "NORMAL", | ||
| "description": "Trigger", | ||
| "converts_to_future_round": false | ||
| } |
There was a problem hiding this comment.
For complex sub-objects like this one, I put in minimal examples -- figuring that more complex examples of more complex sub-types would come later.
Although I did find myself wondering if conversion triggers might possibly be a reference-able object with its own ID, instead of a type? It seems likely some of these things are going to be repeated over and over again.
There was a problem hiding this comment.
@pjohnmeyer, I agree, but why don't we add that as a discussion point for the comment period? Don't think we have the bandwidth to change this right now unless someone wants to volunteer ;-)
| } | ||
| ], | ||
| "seniority": 1, | ||
| "interest_rate": "3.11", |
There was a problem hiding this comment.
The schema does not specify if interest rate should be 3.11 for 3.11%, or 0.0311 for 3.11%.
There was a problem hiding this comment.
Use percentage schema here as well
| "pro_rata": "2500", | ||
| "conversion_valuation_cap": { "amount": "8000000", "currency": "USD" }, | ||
| "conversion_discount": "0.1", | ||
| "conversion_fixed_ownership": "0.05", |
There was a problem hiding this comment.
For conversion_discount and conversion_fixed_ownership, the schema does specify the representation:
(as decimal percent - e.g. .12 for 12%, - if applicable)
However, I found myself wondering if we need a different schema for percentages, at least when the value should be constrained to 0-100.
There was a problem hiding this comment.
We should create a different schema for percentages and use it here and in other similar places.
| "pro_rata": "2500", | ||
| "conversion_valuation_cap": { "amount": "8000000", "currency": "USD" }, | ||
| "conversion_discount": "0.1", | ||
| "conversion_fixed_ownership": "0.05", |
There was a problem hiding this comment.
Does it make sense to have a discount and a fixed ownership, or should it really be one or the other?
There was a problem hiding this comment.
Unclear if this should be a oneof relationship. Need to create issue for this.
| "date": "2018-06-07", | ||
| "resulting_security_ids": ["new-security-1", "..."], | ||
| "amount": { | ||
| "amount": "-867.53", |
There was a problem hiding this comment.
Notice the negative amount here. Do we need to allow negatives in the schema? Or, do we need to be more precise about when positives and negatives are allowed?
There was a problem hiding this comment.
A lot of work to support positive and negative currencies as specific schemas. Won't change this to anything else for now
| "date": "2021-03-15", | ||
| "quantity": "100", | ||
| "balance_security_id": "new-security", | ||
| "reason_text": "for testing" |
There was a problem hiding this comment.
This isn't actually new, just moved down as I order the transactions in the same order they are in ObjectType.
Niiicce. I needed example transactions for the JSONL work, so I can take a closer look at these. |
Part 1 of #55