Difference between revisions of "Trading department"

From Organic Design wiki
(proxy-merchant - Interacting with the legacy financial system)
m (Interacting with the legacy financial system)
Line 9: Line 9:
  
 
== Interacting with the legacy financial system ==
 
== Interacting with the legacy financial system ==
A proxy-merchant is a bridge connecting the [[Second Realm]] to the [[First Realm]] while keeping risks at bay. Many ways of bridge-building are conceivable, from people that handle exchanges between Second Realm money and official currencies to shopping and trading agents. We leave it to the reader to invent his own niche.
+
A proxy-merchant is a bridge connecting [[The Second Realm]] to [[The First Realm]] while keeping risks at bay. Many ways of bridge-building are conceivable, from people that handle exchanges between Second Realm money and official currencies to shopping and trading agents. We leave it to the reader to invent his own niche.
 
 
  
 
== Notes from old Accounts article ==
 
== Notes from old Accounts article ==

Revision as of 14:54, 29 May 2012

Glossary.svg This page describes a concept which is part of our glossary

This is a department in the OrganicDesign system which is common by default to all Platforms by being included in the platform specification. The Trading department maintains tools such as payment methods, invoicing and subscriptions management for its Platform which allow it to trade products and services with untrusted customers in other Platforms or outside the network. This department also handles the financial reporting, invoicing and notifications, budgeting, cash-flow and stock management.

Exchange of value

Trading is basically the exchange of different kinds of resource between two parties which are of equivalent value to both. A medium of exchange such as money is then used to make these exchanges possible without requiring a coincidence of needs amongst the people in the local region. Trading becomes complex when exchange needs to occur between untrusted parties.

If only trusted parties were involved (i.e. members of a trust group), then it could all be handled by any kind of medium such as sea-shells or IOU's written on post-it notes, because people who trust each other wouldn't take advantage of the fact that they could adjust the figures on their IOU's or fill their shell-bags with shells they didn't receive in payment for their resource.

For a medium of exchange to be able to work for exchanging value between untrusted parties, a third party is used that both original parties agree is trustworthy when it comes to issuing the medium or maintaining account balances. But in the informational age another option is available. Instead of relying of a trusted third party to back the medium (and good luck finding any kind of money backed by a trusted third party in this day and age!), we now have the option to use a trustworthy algorithm to back information money such as the decentralised encrypted Bitcoin currency.

Interacting with the legacy financial system

A proxy-merchant is a bridge connecting The Second Realm to The First Realm while keeping risks at bay. Many ways of bridge-building are conceivable, from people that handle exchanges between Second Realm money and official currencies to shopping and trading agents. We leave it to the reader to invent his own niche.

Notes from old Accounts article

Ultimately we'd like to have a complete accounting system integrated into our organisational interface, but we need to have a fully functional system in place initially by tying existing applications into our current wiki-based system. GnuCash as our application of choice and to integrate it into our system requires the following:

  • Adding manual jobs into the workflow system
  • Exporting current spreadsheet data into QIF format for importing into GnuCash accounts
  • Creating custom NZ tax reports which are built on a regular cycle and stored with history in the wiki
  • Handling time management in GnuCash (preferably this would be done by adding HH:MM as a non-decimal currency)

Also we require a minimum level of functionality from the our workflow system with respect to accounts, it must include at least the following procedures:

  • Tax returns
  • Invoicing (regular and manual) and accounts payable/receivable
  • Statement reconciliation
  • Financial reporting for budgeting and other decision making

NZ Tax

  • What are the details of accounting for overseas income wrt IR3 (form) (guide) / IR4 (form) (guide) and GST?
  • We can't claim PayPal fees as expenses because they're a financial institution, but what about cuts that RAC take?

OODA

  • Observe: Import from whole (in current way global state means the bank statements)
  • Orient: Reconcile (make the local state match the global)
  • Decide: Budget (allocate resources to internal roles based on updated local state)
  • Act: Book (schedule work for roles based on updated resource)

Standards

External articles

See also