On Sat, Dec 29, 2012 at 9:00 PM,
<..hidden..> wrote:
On Sat, 29 Dec 2012, Erik Huelsmann wrote:
>
>
> If you don't mind me asking: what's the problem with the old volumes?
> The fact that there's too much storage taken up by the data? Or does
> your server get slower due to the amount of data it has to sift through?
Oh, a lot of little things which make working through day to day
operations a pain. The biggest pain is that I seldom have repeat
customers and with used books every book is unique even if you have two
copies of the same book-- so I build up a lot of cruft. Also, since the
data has been moved through three different accounting systems it has
weird inconsistencies.
Right, because condition etc may vary. One reason I would like to get discrete part handling (maybe we can do this in 1.5?) is that this would allow you to track COGS by serial number (which you could assign) rather than FIFO of comparable objects. Since COGS is now at least generally modular, I think building this in as an add-on during 1.4 would be doable. If that would help solve a number of your problems long-term let's talk about this off-list. There are a number of other cases where discrete COGS handling would be required (configure to order manufacturing for example or other highly configured devices where one cannot assume comparability).
This issue of management of old data (including the ability to purge it) is something I think we need to devote a fair bit more effort towards. We made some changes in 1.3 so that you will never have to aggregate 10 years of data to get the current checking account balance (at least if you close your books occasionally!) and the solutions there need to be fleshed out a lot more and further developed before we can safely support a purge operation but I think that will eventually have to come. As businesses continue for decades and decades it is unlikely that they will want to continue to maintain all that data whether for legal or practical reasons and we will eventually need to have a safe way of supporting that. It is not within arm's reach now, but it could be in the future. We are, however, missing a number of important pieces to that, and there are cases where older data cannot be purged (like unpaid invoices or the like).
I'm thinking I'd like to start clean when 1.4 goes stable.
If you are looking at this, the best option is to import initial inventory as a vendor invoice at COGS. If you are moving from an existing LSMB installation I would be happy to help you through looking at how to export this data. This would probably be best discussed on the -devel list or you could hire a consultant to work with you on an as-needed basis.
After the vendor invoice is imported, then the next step is to bring the accounts current. That means that if you have other AR/AP open transactions those need to be imported (without inventory) and then a GL transaction to adjust chart of accounts entries to bring them current. In that process of course you will need to import all interesting customer and vendor accounts. From that point you should be golden (keep the old books around as long as you need them of course).
Best Wishes,
Chris Travers
>
> In case of the latter, maybe we can alleviate the problem until the
> older data has been archived? The thing is that if you don't use period
> closes, then I can imagine the database having become too heavy.
> However, if you close your books (enter a closed period) as of some
> rather recent date (e.g. 2011-12-31) then the server can create a
> "snapshot" to optimize queries for balances after that date.
>
> Bye,
>
> Erik.
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL,
ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, _javascript_ and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
http://p.sf.net/sfu/learnmore_123012