Difference between revisions of "Trading department"
m (→Interacting with the legacy financial system) |
({{legacy}}) |
||
Line 1: | Line 1: | ||
+ | {{legacy}} | ||
<noinclude>{{glossary}}{{department}} </noinclude>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 [[trust|untrusted]] customers in other Platforms or outside the [[Platform network|network]]. This department also handles the financial reporting, invoicing and notifications, budgeting, cash-flow and stock management.<noinclude> | <noinclude>{{glossary}}{{department}} </noinclude>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 [[trust|untrusted]] customers in other Platforms or outside the [[Platform network|network]]. This department also handles the financial reporting, invoicing and notifications, budgeting, cash-flow and stock management.<noinclude> | ||
Latest revision as of 14:18, 10 August 2019
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.
Contents
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
- Wikipedia:Unit of account
- Wikipedia:Accountancy
- Wikipedia:Double-entry book-keeping
- Normal balance A messy part of the double-entry system, probably overlay this on more fundamentle methodology
- Wikipedia:Accounting methods
- GnuCash (docs)
- Accounting concepts tutorial
- Wikipedia:Resource allocation
See also
- Money
- Privacy
- Bitcoin
- Triple-entry accounting
- Tradecraft
- Black & Yellow Pages - the agorist business directory