NPX is a budget-centric accounting system for tracking the currency activity of independent brands. It can handle multiple ledgers belonging to different organizations. Through its support of the Inter-entity Payment Protocol (IPP), previously unacquainted entities may transact without having to share a common ledger or accountant. It encourages participants to self-organize into a diversity of specialized entities that provide goods and services to the market.
To scroll through content, press on the left mouse button then slide-release in the direction you want the page to scroll. Icon pages scroll horizontally. Other pages, such as account statements, scroll up and down.
The top bar displays information relevant to the User's current task. If there is a backbutton arrow to the right of an icon image in the top bar, clicking it will bring the User to the first page of the home section. If there is no backbutton, the User is already at home. Clicking the 'NPX' logo will cause a pop up to display options for refreshing the session, logging out, or cancelling out of the pop up.
The bottom bar is referred to as the task bar. The User may switch tasks without having to change the active account or ledger.
To enter text data, the user may Use either a hardware keyboard or the pop-up virtual keyboard.
New User registration in the accounting system is open to anyone. This is different from being included as a member of a particular currency brand, which is handled independently by each currency brand admin.
Once the User has logged in, the User is presented with icon pages representing ledgers that the user has access to, and revenue and expense accounts that the User is assigned to as an owner. The last page contains icons for setting User options.
If there are no ledgers and accounts in the User's home page, the User may apply for membership in currency brands (recommended) or establish a new currency brand (for advanced Users.) A brand admin would add a User who is accepted or hired as a member. The brand admin should also assign at least one personal expense account to a new member. Search the discussion group for the keyword 'ad'.
NPX identifies a currency brand by domain name and distinguishes unique subdomains or path names under a generic domain. If an organization does not have a website or does not wish to use its official website to declare its currency brand, the NPX accounting system will host a simple website as a service to a client brand. The default website demonstrates how to declare the manifest URL in the source code. To register a brand:
Click on any of the User option icons to view and edit information.
When a User clicks on an account icon, the top bar displays the account alias and balance. The taskbar has four task icons including the Options task. The User may change account alias, icon image source and the number of rows to display in the review table. The other tasks are described in the Transactions section.
The from-account owner initiates a transaction process by making a payment offer.
In general, the 'to' account owner has to provide relay information to the payment offerer. The relay information may be provided as follows:
The recipient should receive payment notification. The default option is for the system to auto-approve the payment. Alternatively, the recipient could hold, approve manually, void, or reset the payment. For refunds, the recipient has an option to reverse a previously approved record.
Transaction history lists the most recent record first. Click on the date to open a more detailed view of a transaction record. In case of a just completed transaction, a 'to' account owner will see an advisory on the payor's currency brand. The payment recipient can make the following decisions based on the payment status.
If the payment record is still pending, the recipient has the option to override the auto-approval of a payment. The payment status will remain pending indefinitely until the recipient manually approves, voids or resets a payment.
The recipient can approve a pending transaction by clicking on the 'DIY' ->'Approve Now' buttons. OR, if the payment is on hold, the 'Approve' button should be displayed instead of the 'DIY' button.
The recipient can reset a pending transaction. The recipient could decrease (but not increase) the payment amount, a feature that might be useful in scenarios such as gas fill-ups or instant rebates. If the recipient indicates the same amount, only the transaction time will be reset.
The recipient can void a pending transaction based on a currency brand's reputation or inaccuracy in the payment notification. Voidance cancels a payment in whole. Voided transactions will not be included in an entity's periodic reports.
Approved payments less than 30 days old may be reversed by the 'to'-account, in partial or full amount. Unlike voidance, reversals are included in periodic reports.
An account user should be informed of potential restrictions on transaction capability, by brand membership and by account. (For a more thorough discussion of account types, refer to OCAUP document.)
This will cause an equivalent increase in the revenue and expense budgets of an entity. Transacting member(s) and accounts must have a 'c' authcode to create or add to a budget.
Budget assignments may occur between two revenue (n-type) accounts or two expense (p-type) accounts within the same ledger. The 'from' user/account must have an 'f' authcode and the 'to' user/account must have a 't' authcode.
This will cause an equivalent decrease in the revenue and expense budgets of an entity. Transacting member(s) and accounts must have an 'i' authcode to participate in an internal budget use.
This will cause a decrease in the revenue budget and a decrease in the 'External' account balance of an entity. The transacting member and account must have an 'x' authcode to receive payment from another entity.
This will cause a decrease in the expense budget and an increase in the 'External' account balance of an entity. The transacting member and account must have an 'x' authcode to pay another entity.
A brand may have one or more ledgers, one for each accounting unit used. Any brand member can view ledger information, but only Admins could make changes to it. Click on a ledger icon to view related information.
The default page, unless the User changed it, should display periodic tallies and budget-related charts. Click on the chart and while pressing down on the right mouse button, drag the grayed-out edge to zoom into a more detailed view of a narrower date range. To zoom out, double-click on the chart.
The summary page displays all active accounts and members in an entity. Click on the account or user id to view details. Certain fields, such as authcodes or roles, are made editable by clicking on it. Refer to the next section for making edits.
This view displays ledger entries that should be considered atypical. Click on the date to view details, which are mostly for information only. The purpose of this page is to help an Admin detect unusual or potentially suspicious trends in ledger activity.
This page displays basic brand information. An Admin may click on a data field to edit any of the basic information value.
An Admin may add new accounts and members, as well as edit current account and member information. While in the detailed view of an account or member in the Ledger Summary page, an Admin may click on an editable field to change its value. More than one change could be submitted when the 'Save' button is clicked. To cancel the change(s), click 'Revert'.
To add a new account or member, click on the '+New' prompt at the bottom of the applicable table. For new accounts, enter an account name that is unique for the applicable account-type within the active ledger. In order to add a new member, the User must have previously registered in the accounting system. The Admin enters the user number to add that user as a member.
Account names other than MainRevenue and MainExpense are editable. This is the official account name as recorded in the database. The account name may be overridden with a User-specific alias.
Account and member authorization codes for each transaction type are also editable. An account and its User must have the appropriate authcode for a transaction to proceed. The presence of any of the following letters in the authcode string authorizes an account or user to participate in the corresponding activity:
An Admin may delete current account-User assignments in the account or member table by clicking on the data field. These changes are synchronized between the two views for convenience. Conversely, an Admin could create new account-User assignments by clicking on the 'Assign' prompt and then clicking on the applicable account or user id. To automatically scroll back to the table row that is being edited, the Admin may click on the top bar 'Assign' display.
A member may have an 'admin', 'member', 'kin' or 'none' role. A 'kin' is a dependent of a brand member, someone that does not work for a brand but gets assigned credits by the responsible member.
In contrast to changes that require a user to have an Admin role, only the member may change his or her hours per week in the members table. This requirement ensures that mutual consent exists between an admin and a User with regards to the validity of a membership claim.