Basic stock accounting skills mixed with years of experience in both logistics and accounts payable do help.
>From an accounting point of view, a few obvious things need to be done soon, ASAP in fact. 1 Open a test firm and restore current firms backup as TESTfirm 2 Using TESTfirm, check results of previous years, both on COGS basis as on the manual readjustments basis, to see if OVER THE YEARS the total result of sales minus COGS is reported correctly. Seeing the current COGS is too low, previous COGS might have been too high, but if theu even out over the years the final result might be corredt. Then again, it might not, so be sure to check. 3 Take inventory of all parts in stock and check current values, per invoice seems best 4 Correct stock manually if needed, as well as the field `latest purchase price` I mentoned previously 5 Do some test dales and see if correct COGS are taken into account Use of assemblies is not sane if you use different aticles every time. Would make sense if you sell eg the same blade server in 5 varieties to hundreds of customers. In your case, skip it. As for the free memory, my suspicion is, seeing that memory was taken for the right number but for zero value, it was either in the opening balance, which was NOT entered via invoice but in another way, or the purchase invoice/order was entered incorrectly. Use of reports like overview current stock / overview all sales for period (leave blank for all) might be very helpfull to give clues as to where things went wrong. Hth, Paul. 2010/7/15 Jeff Kaminsky <[email protected]> > Paul, > You bring up a lot of interesting thoughts. The invoice to our customer, > does not use assemblies, we simply invoice each part on its own on the > invoice. So I checked each part in our system for any differences in the > way we set them up, and as far as I can tell, they all seem identical, other > than costs and name of the part. I need to know if this is an isolated > event, where, not every part on my invoice is being picked up in COGS, or if > this is potentially a universal problem. > > Should I be using assemblies? Most every server we well to our customers is > very customized for them. We don't have a standard server that we sell. > > Jeff > > > On 7/15/2010 10:56 AM, Paul Tammes wrote: > >> AFAIK it is FIFO indeed, documented that way as well iirc. Assemblies are >> a whole other ballgame again i seem to recall. >> >> Unless you work with serial numbers for all parts and scan the parts per >> sale, I do not see any simple way around the FIFO method. >> Unless you need other figures, it is a solid and approved method of stock >> valuation.So no real problem apart from maybe a like or dislike of this >> specific accounting method. >> At one point in time, you bought a hard disk for price x1. Now you sell a >> hard drive, COGS x1 is taken into account. >> Suppose you bought a total of three hard disks, next time, COGS x2 will be >> used. Leaving the x3 still in stock at the right x3 COGS. >> >> >> You did not CHECK the COGS before? Just changed the values to what seems >> right? >> >> Manually adjusting the level of inventory value means either taking a >> profit or a loss on that specific balance day. Say you re-valued X2 to X2 >> minus 200. >> Two thing happen: >> 1) ALTHOUGH NO SALE WAS MADE, you book a profit / loss. >> 2) since nothing was actually sold, and no new disk of type x1 was bought, >> cogs x1 has not changed. So cogs of X1 will still be used in any future >> sale. >> >> Now when you really DO sell a server or two, the booked prices are off. >> Well, seeing this method of valuation it would be very strange if they where >> right to be honest. >> >> *Note *I think the ´last purchase price´ field might be manually updated >> and maybe that would fix the drive to use the COGS you would like to see. >> But imho there IS nothing to be fixed, as the accounting method used and >> the COGS you would like to see is not correct. >> >> Just because I am interested in the total picture, the two servers, where >> they put together as an assembly before the sale, or did you enter all parts >> used on the invoice? >> That again might be of impact. >> If no amount was used for the memory, it may indeed be set up wrong. Eg. >> as as a non-tracking item, or as a non-stock item. >> Compare to the items that did register a COGS, although it may not be the >> one you would like to see, in order to find out the reason it did not pick >> up a cogs.. >> >> HtH, >> Paul >> >> >> 2010/7/15 Jeff Kaminsky <[email protected] <mailto:[email protected]>> >> >> >> Since 2002, I have been adjusting the dollar value of our cost of >> goods sold to reduce inventory to what we believe the correct >> inventory level should be. Every time, I'm increasing COGS and >> decreasing Inventory. Recently since we've become a larger company >> and face higher levels of scrutiny I have become more interested >> in this particular phenomenon. So I ran a test case, we sold 2 >> expensive servers to a customer, and I immediately went into COGS >> and Inventory to see if the correct figures were adjusted. >> >> Quantities seem correct >> Dollar amounts are not correct. >> >> We sold >> 2 chassis, Inventory was decremented by 2, but COGS shows only the >> cost of one of them >> 12 hard drives, Inventory was decremented by 12, but COGS does not >> show the actual costs of the hard drives we bought, but took costs >> based on obviously a FIFO (first in, first out basis), >> 16 pieces of memory, Inventory was correct, but... nothing shows >> in COGS!! >> >> There is more, but, the recorded costs for this sale were 9,613.50 >> and according to our purchase receipts it actually cost us >> 12,486.00. So I was wondering if anyone has seen this before, did >> we set up some parts wrong, or use an odd character somewhere that >> would make COGS react in this way? >> >> Jeff >> >> -- >> Jeff Kaminsky >> Sr. Accountant >> IX Systems >> 408-943-4100 ext 122 >> >> _______________________________________________ >> SQL-Ledger mailing list >> [email protected] <mailto:[email protected]> >> >> http://lists.ledger123.com/mailman/listinfo/sql-ledger >> >> >> >> _______________________________________________ >> SQL-Ledger mailing list >> [email protected] >> http://lists.ledger123.com/mailman/listinfo/sql-ledger >> >> > > > -- > > Jeff Kaminsky > Sr. Accountant > IX Systems > 408-943-4100 ext 122 > > _______________________________________________ > SQL-Ledger mailing list > [email protected] > http://lists.ledger123.com/mailman/listinfo/sql-ledger >
_______________________________________________ SQL-Ledger mailing list [email protected] http://lists.ledger123.com/mailman/listinfo/sql-ledger
