|
|
| Author |
Reply to Topic | Show CCP posts - 0 post(s) |
Drab Cane
Carbenadium Industries
    |
Posted - 2009.10.26 21:28:00 -
[1] - Quote
 Originally by: Chingyz
The best way to get around this is to have several layers/pages in your program. Use one for profit calculations, based on the FIFO principle. One for assets based on current prices. This can also be used as a tool for setting sale price of your items.
I believe Chingyz has raised the correct question. If you're just creating an accounting package to tie out all the numbers, FIFO makes complete sense.
If you're trying to provide information related to current valuation of the operation's assets, then you'll want to record current value and show that value on a separate set of reports.
I've been toying with the same idea, an acctng package for mfg/trade - the concept I came up with would record the API information (Transactions and Journal Entries) in their own table, then link each API transaction and journal entry to entries in a second set of tables that would handle the GL Journal, AR/AP Journals and the Inventory system. This way I can handle all the logic and records in the accounting tables, including posting correcting entries.
The downside of this for the auditors, is that the accounting information is a step removed from the API data. However, by using the book value for all assets, the auditor should be able to tie out the operation's assets between the financials and the API. Also, there should be reports/features that allow the auditor to inspect that individual book transactions are linked to existing API transactions and such.
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.26 21:52:00 -
[2] - Quote
Originally by: Hexxx
I'd imagine I would use FIFO for the Income statement and then asset valuation on current market prices for the Balance Sheet.
Clair Voyant beat me to the post 
In that case, you'll want to place a separate line just before your total net profit/loss, stating a profit/loss from mark-to-market (or whatever the correct term is). This way your income statement and balance sheet will match up, and you've accurately called out where the profits came from. This would be especially useful if you're playing the minerals market (stocking up when minerals are low, etc).
This could be difficult to calculate (totalling all the differences between your assets' market- and book-value) or easy (calculate the net profit/loss from the balance sheet, and use the difference between that and the actual profit/loss on the income statement).
Your auditor will probably be most happy with a solid inventory report - regardless of what the current value of the assets, the auditor should be able to confirm your inventory.
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.26 22:21:00 -
[3] - Quote
Regarding the FIFO calculation, I've seen this handled before by using an Inventory Transaction Log. Every input and every output from inventory is added to the transaction log, with a datestamp. Every input includes the per item cost it was purchased/booked at. Much like any other account ledger, initial entries are made for starting inventory counts, along with their book value.
The transaction log can then be used for calculating the FIFO amounts.
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.27 00:01:00 -
[4] - Quote
Edited by: Drab Cane on 27/10/2009 00:04:39
Can someone explain again why it would be advantageous (sp?) to show the assets at market value on the balance sheet?
In a period of rising mineral prices (and savvy purchasing), the book value of raw materials would be undervalued, and therefore so would the NAV. But is that a bad thing? Based on book value, the NAV would be more accurate, and so would the Return on Equity (ROE). In fact, the ROE would look slightly better when based on book value.
Edit: I think Sencnes has a valid point regarding the mark-to-market causing an unrealized gain/loss. Financial markets are one thing, but manufacturing/retail is not the same.
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.27 04:03:00 -
[5] - Quote
Wyehr, its a shame you've only seen the 'external' side of accounting. Yes, the tax laws and public securities laws place many requirements on how things are handled. Yes, it was the need for audited financial for public corporations that really spurred the accounting profession. Yes, the math involved in accounting is relatively simple - its mostly about where to put the numbers. And yes, the numbers can (and often are) manipulated. And fund accounting (used by government and non-profits) is a really strange world.
That said, accounting is very important for internal use. Owners and managers need to know where the money is going, where the money is coming from, what's selling, what's not, what expenses are getting out of control, what trends are appearing, how much reserve cash (or line of credit) is necessary to make it through the lean months, etc, etc, and so forth.
A successful operation can (and sometimes will) relax their recordkeeping and still turn a profit. But if the managers go too long without watching their numbers, expenses creep up, revenues creep downward, and suddenly there's no profit, no reserves, and eventually no business.
I believe this is why Hexx is trying to automate a true accounting system, so his operations have a solid system of reporting and tracking for the managers running the operations. And so the auditors can make sense of it all.
And yeah, I'm guilty of having a background in accounting. :)
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.27 22:57:00 -
[6] - Quote
Edited by: Drab Cane on 27/10/2009 23:00:44
Hexx, you're going to have to manually record the 'magic bucket' items.
Record the items at whatever market price you would reasonably pay for them. It will constitute an increase to your assets, and an increase to your revenue. Show the revenue as "Revenue from . . ." whatever the source was (mining, salvage, loot) on the income statement.
Edit: In our mfg operation, the operation buys the minerals from the characters that mine them, at Jita's current high buy price. Any reasonable standard will do just as well, as long as you're consistent.
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.27 23:08:00 -
[7] - Quote
Another option is to actually have the mining characters put the minerals up on a buy order and have the corp purchase them immediately. That way you're pushing the mineral transaction through the API. Same with other items that can be sold through the market.
Have the characters donate the proceeds from the mineral sale - that will show on the API as well.
This is assuming that you're only capturing the corporate wallets.
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.28 00:04:00 -
[8] - Quote
Along the same vein as Wyehr's question, Hexxx, are you looking at building a system for your operations only, or are you looking at a system that could be rolled out for other, interested players?
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.28 00:20:00 -
[9] - Quote
Again, regarding recording items that have not been obtained through the EVE market (and thus through the API):
Would it be safe to say that an NAV worksheet is pretty much the standard financial statement for EVE? I would think that assets are relatively easy for an auditor to tie out with the NAV, and any liabilities would just have to be confirmed.
My point is, your balance sheet and income statement could be used as internal reports, and the NAV would be used for external purposes (auditors and investors).
You could reflect whatever asset value seems reasonable for your internal accounting, and reflect market value on your NAV. As long as your accounting system correctly tracks how many assets (inventory, etc.) you have, and how much cash you have in your wallet(s), producing both the internal and external reports should be straightforward.
-----------------------------------------------
- Who Dares, Wins
|
Drab Cane
Carbenadium Industries
|
Posted - 2009.10.28 00:51:00 -
[10] - Quote
It sounds like you do want to have an auditor confirm not just the value of the operation, but its profits and expenses as well. I don't think you'll find a shortcut, you'll have to go 'all in'. The API simply does not track enough information to properly track most asset transactions, and you will need to generate your own records that fill the gaps (as I believe someone suggested above already).
Why is grouping alts that much of a challenge? As far as I know, all transaction/journal/asset IDs are system-wide. Track individual alts as their own 'department'. Add a 'department' field to your import tables, and fill it with either the ID of the character you're importing from, or the number of the corp wallet.
You should be able to code the 'department' field in such a way that you can automatically handle 'inter-departmental' transactions (at least, that's the theory).
-----------------------------------------------
- Who Dares, Wins
|
|
| |
Reply to Topic |