The trade view

A trade is filed in one book, and a book hangs from exactly one portfolio. The tree on the left therefore holds both, and the tree and the list are one request.

• A party nests under its parent party, so a holding company shows the operating companies beneath it. A party holds its own root portfolios; a portfolio nests under a portfolio; a book hangs from its portfolio. Each row is followed by its children portfolios and then by its books, and a party's portfolios come before the parties it holds, as the legacy tree drew them.
• A party that holds nothing is drawn as a shell with a count of 0, rather than left out, because a holding company is a real row of the tree.
• The three rows are told apart by their icon, never by their words. A party takes the hierarchy glyph, a portfolio the briefcase and a book the book, which are the icons the icon guidelines name for the concepts: ic_fluent_organization_20_regular, ic_fluent_briefcase_20_regular and ic_fluent_book_20_regular. No new icon is drawn for this screen.
• Choosing a party keeps the trades of every book of the parties under it, choosing a portfolio the books under it, and choosing a book that book's trades. The choice marks the row and moves the accent onto its icon.
• Each row states how many trades sit in its subtree, so a person sees where the population is before opening a folder.
• A sandbox's portfolios are virtual and are drawn in italics. The trades in a sandbox leave the list as soon as a portfolio or a book outside the sandbox is chosen.
• The tree keeps its shape while the list shows loading, empty or error, so a portfolio that holds nothing is not a trap.
• The address carries the choice as ?party, ?portfolio or ?book. A party is a filter of its own, party_id, and the other two are a book filter, because a book of the tree is a book of the trade and a portfolio is the books under it. One book is an equals member, book_id, and many are a one-of member, book_id_one_of. The book combo box of the filter row and the tree stay in step, and choosing one clears the other.

The trade summary read model already carries book_id, so the tree needs no column it lacks. It does not honour the other portfolios a trade may be reported in, which ores_trading_trade_portfolios_tbl records beside the book. A list that must show those is a later decision, and it is recorded in the task.

The list mixes three things, and each states what it is beside its type:

• A trade. One instrument. It states no marker.
• A composite trade. Its instrument is a composition: ores_trading.composite_instrument carries the product and ores_trading.composite_leg holds the constituent trades. The row states composite · 2 constituent trades.
• A structure or a package. A deal assembled from several trades: ores_trading.structure carries the deal and ores_trading.structure_member holds the trades with the role each plays. The row states structure or package, and its parent deal when it is nested.
• A trade that a deal holds states leg of STR-0007 beside its type, so a leg is never mistaken for a trade standing on its own.

A composite instrument is not a structure. A structure is a deal of several trades and belongs to no instrument. A composite instrument belongs to one trade and holds constituent trades inside it. The two compose at different levels, and a trade may be both: its instrument is composite, and the trade is also a leg of a structure.

The first column states an identifier, never the internal uuid. A trade's uuids are internal, so the column shows one of the trade's identifiers, which ores_trading.trade_identifier records with a type: Internal, UTI, USI or ORE. The read model holds no identifier of its own, so the page reads them for the rows it shows.

The save sends a standard put with the version the edit started from as its precondition, and the reason and the commentary as its change intent. The dialog shows it. The kind of change comes first, as Trade Versioning says. The dialog offers only the activity types the card allows. An economic amendment unlocks the economic fields, a change of reference details unlocks the rest, and a null amend locks all of them and is saved only when nothing changed. Under the fields the dialog says what the save will do: which version moves, and whether a confirmation is issued.

Open the exercise prices card of ACME-100202 and change the strike. The dialog says the external version stays, because the digest does not read that table. This is the defect filed as a capture. Add ?digest=fixed to see it closed.

• A notional. An earlier revision of this prototype drew one Notional column. That column was wrong and is gone. A trade has no notional: notional is a property of the instrument, and not every instrument has one. ores.trading.bond_instrument, ores.trading.fra_instrument and the equity option instruments carry one; ores.trading.vanilla_swap_instrument carries none, because each leg states its own, and a leg's notional may step or amortise. A single number for a row cannot be read faithfully, so the list states the trade type and leaves the size to the Instrument tab of the page.

• The data. The prices, the counterparties and the books are mock, and so are the parties, the portfolios and the three joins the tree rests on: the party each root portfolio sits in, the portfolio each book sits in, and the constituent trades of the one composite trade. The root portfolio of a party carries the party's own name, as the seeder lays it out, so two rows of the tree read "Acme London".
• The server. A save waits in the browser until Refresh. State does not survive a reload, except trades booked or imported in the other prototypes. A saved table of rows comes back as text, without its links.
• The activity type codes, except the ones the model documents (new booking, draft capture, amendment, novation, termination, cancellation).

doc/prototypes/trades/trade-page/. prototype.js is this prototype. common.js and prototype.css are the same in all four prototypes of the group.