2026-02-22 - Commerce and Accounting notes

Development - Izara Commerce

Development - Izara Commerce to Accounting

Development - Izara Accounting

General

• one account can have multiple organizations

General Ledger

• summary grouped into 5 categories: assets, liabilities, equity, revenue, and expenses
• each summary value is called a GL Account or Control Account (this is the total/balance of all Subsidiary Ledgers)
• Each GL category can be split into any number of control accounts, eg accounts receivable is under assets

Subsidiary Ledgers

• detailed parts of General Ledger summary. total balance of subsidiary ledgers matches balance of its corresponding control account in general ledger
• Accounts Receivable Ledger: owed by customers
• Accounts Payable Ledger: owed to vendors
• ?Inventory Ledger
• ?Asset Ledger
• ?Payroll Ledger

Financial Statements

balance sheet

• classed as temporary: balances carry over from one period to the next

1. Assets
2. Liabilities
3. Equity (owners equity, retained earnings(earnings from previous years))

income statement

• classed as permanent: closed at the end of each period with their balance transferred to equity

1. Revenue
2. Expenses

locking records

new idea

• have period object instance
• all journals are connected to their period
• if the period is locked then must unlock before can change or add child journal entry
• if unlock and change, reports will no longer be valid and must be regenerated
• perhaps have saved report objType, (optionally?) connected to period, if unlock period invalidate those reports
• if unlocked, all adjustments/clearings would need to be updated -> need to warn and record this somehow
• each time try to change something in Commerce that affects records in Accounting, must check if record is locked

considering multiple periods, eg VAT per month, end of year

• if journal is in any locked period must unlock that period before can make any changes
• if add journal check any periods locked, if yes cannot add until unlock
• maybe have consolidated accounting periods, eg year which combines multiple (full) child accounting periods

• periodConfig object that is parent for individual periods
• sets the period length, eg locking into end of year/month
• can have additional settings, eg automated reports when period is locked

old idea

• each account can lock transactions at periods
• simply a timestamp locked up to
• if locked, cannot change/add/delete any transaciton before that time
• eg after tax return complete

ledger - account hierarchy

• really a ledger or financial report could be pulled at any level to show totals of each child account, or all the transactions in a child account at any level
• there is specific terminology used when pulling the GL report/s:

1. a ledger has multiple totals, never individual transactions
2. an account has either individual transactions or a (subsidiary)ledger
3. A subsidiary ledger has many accounts, each of which can be transactions or a ledger
4. When exporting a ledger report, eg the General Ledger,

new idea

• Organization can create multiple ledgers, each has a hierarchy of accounts
• Maybe can generate a default ledger which places all accounts into the general ledger as their own control account
• A general ledger is a hierarchy that includes all accounts, grouped in a hierarchy of ledgers (which roll up to the top GL ledger)
• Each ledger is a rolled up total
• for generating report can set ledger totalOnly to true to not show lower detail, if false report lists all entries per account as well
• possible to create a report at any level of the ledger hierarchy
• I could allow accounts at any level to be shown as a total, but warn that only top level accounts are traditionally allowed this status

old idea

• have a general ledger, top level
• have the option of creating subsidiary ledgers under the general ledger, when you do this in accounting terms there is a control account that points to subsidiary ledger
• a subsidiary ledger moves the transaction out of being reported in the general ledger
• subsidiary ledgers have accounts underneath it
• transaction are only placed in accounts, not ledgers, ledgers total accounts, a subsidiary ledger pushes it's total up to the control account which is then one account in the general ledger
• by accounting standards subsidiary ledgers only exist at top level, but maybe allow at any level

credit/debit

Assets: credit decreases, debit increases Liabilities: credit increases, debit decreases Equity: credit increases, debit decreases Revenue: credit increases, debit decreases Expenses: credit decreases, debit increases

sale accounts

• a sale total amount can point to

1. accountsReceivable (not yet paid)
2. paymentApplication (amount paid)

• combined these should add up to the sale amount
• a sale total amount can point to

1. deferredRevenue
2. service Revenue (moves amount to income statement)
3. any other income statement revenue account below

Income Statement accounts

• service Revenue
• sales revenue (goods)
• profession fees
• tuition fees
• subscription fees
• advertising fees
• commission
• interest
• rent
• dividend
• royalty
• gain on sale of asset
• misc revenue

accountsReceivable

• each sale creates a link to an accountsReceivable instance which has a relationship as outstanding or paid
• records the functionalCurrencyAmount and exchangeRate used to calculate it (if saleCurrencyId not match business functionalCurrencyId)
• also the amount remaining to be paid

deferredRevenue

• payments from customers not yet applied to accountsReceivable
• paymentApplications (parts of a customerPayment) are linked to deferredRevenue instance to record the amount for accounting
• a sale can link to both an accountsReceivable and a deferredRevenue
• deferredRevenue can be moved to accountsReceivable as it is reported/changed to revenue (eg over time services)
• accountsReceivable remaining amount reduces as paymentApplications point to it
• deferredRevenue can be changed to

ComAcc PlugIn

• plug in will be handling a lot of the linking
• almost need a copy of all connecting data from both projects, or subscribe to actions such as create/update on both and ensure all data lines up
• for example if an account connects two accounts, maybe can only do this when no data exists on both, must be set from virgin accounts
• if connected, certain objects can only created/updated on one side of the connection, eg the Commerce side, Accounting cannot create/update entries. This can ensure that all data aligns
• plugIn keeps a record of the connection between Commerce identifiers and Accounting identifiers
• Commerce will probably have to break things down to the same granular level as Accounting, eg a payment(AR-asset/cash-asset)
• must be able to split across multiple vendorInvoices(AR-asset)
• units are tracked at unit level
• Receipts(inventory-asset/Accrued Liability-liability) can match multiple vendorInvoices(Accounts Payable-liability)
• dispatches(inventory-asset) can match multiple customer invoices(AR-assets)

• plugIn records which Subsidiary Ledgers is used for each :

1. work in progress
2. inventory
3. .. everything else

quering relationships accros PlugIns

• create a method of adding available links across plugins
• eg: a sale (revenue) could like to the financial statement that the revenue was 'cleared out' in (moved to equity)

Commerce

inventory attributes

• re-consider attribute tree for controller replacement, does it work for the cases I need
• hierarchy of settings to match attributeTree in Market
• ability to create code for generating a value per product/sellOffer (consider translations)

non stock inventory

• how to handle digital asset that does not control stock level
• each Inventory (handlers) receives request about reserving stock, Inventory Intangible Asset has a setting if it manages stock (no stock location), if yes it has a stock level, if not it can be sold any number of times
• if Intangible Asset does not manage stock level, it has one unit that receives all COGS and Intangible Asset handles allocation of COGS
• so adjustment of stock and allocation of COGS is handled by the InventoryHandler, however remaining COGS for an inventoryUnit is saved in inventory manager, so must update this each time allocate COGS to a saleLineItem/AccountsReceivable

BusinessDetail

• record eg base timezone for all tasks
• functionalCurrencyId for business

CurrentLiability

• eg: deferredRevenue (Liability)

currentAsset

• eg: accountsReceivable

Stock Adjustment

• when selling, the invoice does not immediately adjust stock, that is a separate action
• when purchasing a purchase order does not immediately adjust stock, that is a separate action (Receiving Report) * allow for uploading media to the Receiving Report

Vendor Payments

• often with "Three-Way Match": PO/Receiving Report/Vendor Invoice(documentation) must match before payment is made, try to implement this into the system. Eg a PO is not an accounting entry, so nothing in accounts, but Commerce can have this object and link it to receiving report/s and vendor invoice/s. all 3 point to inventory, an inventory lineItem should exist in all 3, if not all line items in a PO are accounted for then it is invalid, same for vendor Invoice.. not sure this is the correct way to handle it, or force all 3 to match (seems too restrictive)

1. PO: no accounting entry made
2. Receiving Report: debit(increase) in inventory[asset], credit(increase) in Accrued Liability[liability]
3. Vendor Invoice: debit(decrease) in Accrued Liability[liability], credit(increase) in Accounts Payable[liability]
4. Payment: debit(decrease) in Accounts Payable[liability], credit(decrease) in cash account[asset]

paymentApplication

• customerPayments link to paymentApplications, which is each part of the payment that links to an accountsReceivable
• the total paymentApplications for a customerPayment should add up to the total customerPayment

CustomerSegmentation

• group customers into grouping for running an accountsReceivable per segment

CustomerPayment

• When receiving a payment the full amount is recorded and connects to cr/dr in an account
• parts of the payment are applied as paymentApplications

VendorPayment

• One VendorPayment may be for many purchases (vendor invoices), each invoice may have different types of line items
• When paying for a nontanglible bill, can apply line items as COGS to a range of inventory units (tangible or intangible)
• each paymentLineItem links to many

VendorPaymentApplication

• VendorPayment links to many VendorPaymentApplications
• segements the payment into each use case,

PrepaidExpense

• when pre-pay Purchase an Expense from a Vendor, ie: not yet received the item or service (eg over-time services)

AccountsPayable

• when Purchase an Expense from a Vendor before completing payment

Manufacturing

• manufacturing has it's own ledger related trasactions:

1. raw materials are purchased and counted in a Raw Material Inventory Ledger
2. when start manufacturing raw materials are moved to a Work In Progress Inventory Ledger
3. once complete the WIP ledger moves to Finished Goods Inventory Ledger, value includes raw material/labour/manufacuring overhead
4. when sold the finished goods value gets moved to COGS expense ledger

manufacturing overhead

• costs that are spread over the units produced
• need to estimate what portion of these costs get applied to each unit produced