Inventory Handling

Transferred from http://linuxwiki.de/GnuCash/DevelTexts

Multi-Currency vs. Multi-Commodity (Inventory) Handling

With the new multi currency handling gnucash can handle foreign currencies great now. Accounting for other commodities like inventory is officially not supported yet.

Most users have a preferred currency they use as their point of view (report currency). Relative to that, other currencies can come in, traded, lost etc. and be subjected to price/exchange rate changes. Those things that are now well handled with accounts denominated in currencies are the same things that can also happen with other commodities like stocks for example.

The very good job gnucash does with the currency subset of commodities may not need to be limited to currencies only.

At the moment if one wants to account for stocks, or as a workaround for another type of commodity, one uses a special stock/mutual account and defines the denomination (stock name, code, etc.) for it. Such special stock/mutual account types are similar to the old currency account type that is now deprecated:

• With the stock/mutual accounts it is not possible to transfer stocks from one gnucash account (i.e. read broker, location or storage place) to another without " virtually selling" them in gnucash. (Just like it had to be done with currencies before.)
• Stock option plans (Or anything else where income/expense is not denominated in ISO currencies) can't be accounted for at the moment. Same as the old gnucash currency handling did not support to earn other currencies than your current (and assumed to be static) home currency.

Those things have been solved in the course for multi currency handling and the solution seems applicable for other commodity types too. (Stocks are just another subset of of commodities.)

All the necessary accounting is done by recording transactions properly (in the future optionally "lot-ed" in some accounts). The method for transactions between accounts with different denominations has already been successfully implemented. It's only that currently the method is only applied to transactions with foreign currencies.

The transaction accounting method should not imply anything about different properties or valuation and be the same for all.

The difference between stocks and other types of commodities, or between commodities in general, lies in the reporting needs. It may be higher for stocks than for other commodities or vice versa. The reporting needs are on a level finer than just account-balances though, they're based on individual transactions (buy/sell) and time. This ties in with the proposed support for "lots" in accounts and more complex transaction reports. However on the underlying transaction level the proper accounting method is the same.

The difference between most of the national currencies in use today and commodities in general lies in their designs.Yet the difference has no implication on the way transactions need to be accounted for and handled in gnucash or elsewhere. In gnucash, same as in other accounting systems, monetary differences are represented correctly just by entering adequate transactions.

<economics> The significant difference, which sets them apart from all other things in the world, is that they are guaranteed to be medium of exchange and value safe-keeping at the same time. Currencies that are designed with such extra superiority to all known goods besides their convertibility do imply ever positive income for money ownership, or otherwise the money withdraws from the market. Its a typical monopoly situation in which it is possible that money owners realize a net income beyond the wear-out (zero in the case of money), the risk surcharge and the transaction costs when lending it out. So when used in its value-keeping function, ownership of such currencies is able to either generate income to compensate the cash preference or can choose to circulate less. This is detrimental to its function as a medium of exchange. It prevents transactions that could bring together supply and demand but don't render gains drawn from somewhere (one or both of the persons involved in the transaction, other persons, the economy as a whole, or the environment) that exceed at least the risk-less money market's interest rate. On the bottom line only individuals or organizations that collect more interests then they pay realize gains. This is possible for individuals or organizations with a lot of money or which can successfully add the capital costs (interests they have to pay) to their sales prices. Even individuals or organizations without any loans will pay the capital costs that incurred during the production of the goods and services they buy. </economics> (ChristianGatzemeier)

> gnucash _does not support inventory_.BR
>BR
> FWIW, inventory accounts SHOULD be more similar to stock/mutual thanBR
> to Asset.  You want to keep track of the number of widgets in yourBR
> inventory, and AT THE SAME TIME you want to keep track of how much youBR
> PAID for those widgets.

Absolutely, from the user side, yes, and additionally you'd probably also want to see what your inventory is worth denominated in say your local currency currently.

Generally the accounting system needs to keep track of all those things for *any* commodity though. Yes not only for stocks, also for any other inventory of a commodity and even or especially for currencies. The difference seems to be the level of detail the user may want to *see* at the same time in the registrar for accounts he has stocks, other commodities or foreign currency in. For example currently the register of an account denominated in a foreign currency does not show exchange rates or price in report currency, only the quantities of foreign currency is shown. This behavior may only sometimes be what is desired.

By introducing different "views" that do include for example values in the report currency and the exchange rates in registers (similar as seen in stock/mutual accounts at the moment) the special stock/mutual, commodity or inventory accounts could become obsolete just like the old currency accounts. The differences in presenting the accounts and available features can be based upon the commodity type in which the accounts are denominated.

This account type clean-up will leave behind only account types that categorize by objective (considered for report generation or program behavior). This lessens the confusion of having special denomination-type accounts mixed in there besides having a separate denomination property.

Account types (and their report generating or program relevance):

• asset
  • cash
  • bank (relevant for online connectivity)
  • accounts receivable

• liability
  • equity (for gain/loss calculation)
    • income
    • expense
  • credit card
  • accounts payable

Example list of commodity types:

• currency (ISO-4717)
• securities (security accounts could show extended information by default (prices, value in report currency)
  • stocks/mutual (can have dividends, reinvestment, etc.)
  • bonds (interest rates, term etc.)
  • ...
• inventory
  • products (items for sale (useful when generating regular invoices, )
  • means of production/machinery
  • real estate
  • ...
• user-defined commodity