Incorrect unit activity/sales histories

[Nancy Workman]

I just 'closed' 2001 to prepare for opening 2003 (we keep two years open at a time) and I've found some odd and very wrong data showing up in both the Unit Activity Report and Customer Sales History. It appears as though it is adding the number of an item sold in a given month (i.e. 2 widgets in November of 2001) to the number of widgets sold in November of 2002 - even though the year is closed. Not only that, but if I look at that same report for a period that hasn't even happened yet (i.e, how many of that same widget was sold in December 2002 - remember we aren't there yet) it gives me the number sold in December 2001. Does anyone know what is causing this problem and how I can fix it? Peachtree's usual answer 'Run an Integrity Check' comes up with no problems, but something is obviously wrong. The same adding data from the prior year happens when you look at the Customer Sales History tab in their maintenance file. Help!

[TheWolf]

Integrity checks should correct. Make sure you rin them from period 1 and I would try the customer/journal sync and if that doesn't fix try the inventory/journal sync.

[Nancy Workman]

I ran the integrity check once and it 'fixed' very little according to the results. But I'm wondering if I need to go back to 2001/2002 backup of BEFORE I closed 2001 and run it from there. Thoughts? Gosh, I hate bad data! Anyone know why this happens? Is it preventable?

[YOUNGBLOODLTD]

I logged onto this site because we are experiencing the same problem: our inventory activity and sales histories are all messed up. We actually don't use inventory the same way most people do: we track income on oil and gas wells with it, so we didn't notice any problem until someone wanted to purchase a well and we went to look up it's income (sales).

We have determined that the problem started in July of 2001, stopped for the first six months of 2002, and has now restarted this past July. We think we may have closed out the year in July of 2001.

From Nancy's response to Wolf's integrity check suggestion, it doesn't seem worthwhile to try. My question to Wolf would be whether or not he has seen this problem himself.

Surely, someone else has had this problem. Any other ideas?

[ELLIE]

First I would like to say how glad I am to have found this site.
I have the same exact problem with the unit activity history and the Peachtree tech people told me they had never encountered this problem before. I also ran the integrity check and it did get rid of the customer sales history duplication, but the unit activity continued to add prior year's sales to current.
I also found that this only occurs from July 1 through December 31. From Jan. 1 thru June 30, the data is correct. I hope someone can offer a solution to this problem and I guess I'm glad to hear that I'm not the only one with "gripes" which cannot seem to be explained!!!!

[YOUNGBLOODLTD]

Could you give a clue as to how many items is too many for Peachtree's inventory? The number of inventory items in our database has remained pretty static for the last five years, but I guess we could have been near the threshhold and hit the proverbial "straw that broke the camel's back".

Each inventory item is classified the same way, so if this is a hierarchical database I guess I'd want to know what the threshold is for child segments.

By the way, our inventory activity is minimal. We receive income against our inventory items which are oil and gas wells. So, at most, that's once a month per well.

Having said all that, I still don't see how the clues to this problem point to damaged data. For both Ellie and myself, the error occurs only in the second half of the year. Nancy Workman has not inidicated whether or not this is true for her also. It also appears that the additional activity and sales history are actually old data for that specific inventory item.

I'm hoping that someone out there discovered this problem long ago and has a real fix. In the meantime, I, too, will report this to Peachtree Tech Support.

[Nancy Workman]

Well, I tried running the integrity check again, this time from an 'unclosed' backup...now it won't run at all (File Error 100), so I am going to reload the last backup. It bothers me that the GL foots and there are no apparent problems until you look at certain reports or past histories, which means you can have the problem for a long time and not realize it. I'm a little hesitant to send my financial data to someone who I can't go down and actually meet and talk to, but I'm going to try one more purge, close and integrity check before I admit defeat. To "Youngblood" - I have exactly the same problem. The data all looks correct in the first half of BOTH years that I have open (2001, 2002), but from July on it seems to pick up data from the year before. Doesn't sound promising to me....

[ELLIE]

Just last night I spoke to someone who is also running Peachtree but has only TWENTY inventory items, generates maybe 20 to 25 invoices a week yet is faced with the same exact problem. I, myself do not have a very large data base so it would seem that neither one of us has "overwhelmed" the system.

Also, closing the year does not help. My system, (installed Dec 1999) is addding 2000, 2001 and 2002 July thru Dec. There must be some explanation as to what is triggering this duplication.

[YOUNGBLOODLTD]

Well, thanks again to Chicamic for telling us that our data is damaged. Frankly, as someone with 30 years tech experience(yep, old big iron as well as PC's) I find it astonishingly coincidental that there are three people whose data has been corrupted in exactly the same manner as to produce the exact same result (bad data for only the second half of the year).

Clearly, the answer has nothing to do with database size or activity.

Unless someone out there has had this problem and it has been unconditionally fixed by spending $400, I think I will continue to pursue other answers.

Since we only use inventory tracking for inventory out, I'm wondering if Ellie and Nancy use it for both in and out? I thought maybe we could get as many clues as possible to this problem before we all hit Peachtree for a solution.

[Nancy Workman]

I have discussed this problem with Peachtree "support" and was told that the issue was not inventory activity, nor number of items, but the size of the entire database. According to them, my file sizes are well within limits and that an integrity check will fix my problem (NOT!).

If I have reached some sort of 'ceiling' on Peachtree with regard to my inventory activities, I need to know - I don't exactly have a lot of time to be deciding to switch accounting packages this late in the year. It'll be nearly impossible to get all my data re-entered in a a new program by January 1st. Peachtree also told me that they had never heard of this problem (even though I myself have called them a minimum of 9 times). Assuming I can get the data 'repaired' by one of these companies that do this sort of thing, what happens if I discover after all this that Peachtree simply can no longer handle my data? If Peachtree will not give my the data to determine if I have outgrown them....how can I determine a course of action? Thoughts?

[chikamic]

Well guys, I am backing out of this one. I do this for a living and was trying to give advice based on the cases I have seen and have solved.

Good Luck to you all.

[Nancy Workman]

First, I would like to say to Chikamic - I think we all appreciate and understand that you are trying to help - Thank you! But we are frustrated and it's not exactly a minor glitch.

To Youngblood: I do use the inventory portion of Peachtree pretty heavily. We purchase and inventory many parts (we manufacture electronics) and we build assemblies and subassemblies into finished goods which are sold. We also make frequent inventory adjustments to account for parts that are 'lost' by the manufacturing equipment. Again, I've been lead to believe by Peachtree support that the issue is more related to the overall size of your data files and I'm starting to wonder if we just haven't hit the proverbial wall. It would be nice if that's the case for the Peachtree folks to admit it and not create any additional problems.

[Nancy Workman]

Just remembered one thing I wanted to mention: about two or three years ago I saw this problem for the first time. At that time, the Peachtree solution was to download a 'patch' for what at that time was Version 7.0. It fixed the problem at that time, but there has not been a similar patch since unless I missed it. Don't know if this is useful or not, but it says to me that Peachtree IS aware of the problem despite their claims to the contrary.

[ELLIE]

Thanks Youngblood for your support, yes I do use the inventory both to receive and of course to bill, but since I import products from Italy, I only enter receipts, (against purchase orders) on an average of once a month. Also, as I mentioned earlier, I found a FOURTH "sufferer". Lets see if this list keeps on growing...As far as the patch mentioned by Nancy, I hope someone out there knows something about it..and yes, I agree, we should demand some "intelligent" answeres from Peachtree, after all, it should be their responsibility to address this situation

[TheWolf]

Many of my customers have had corruption issues with their data, exactly as many of you have described. This would be a data issue, not a program issue. I have been pretty successful with the integrity checks correcting this and I love the new Data Verification feature in release 2003.

[chikamic]

Thanks Wolf, I thought I was going to get tarred and feathered on this thread for insisting that this is a data corruption issue (that I have seen MANY times myself as well).

[ELLIE]

Hi chikamic and The wolf,
I really appreciate the fact that you "guys" are out there trying to help all of us out and you have no idea as to how glad I am to have found this site.

Before discovering your site, I was assured by Peachtree that all my problems were "unique". Now I see that many of us share the same problems!!!

I did run the integrity check and the data verification check many times, both with peachtree techs on the line and additional times on my own.

GUESSS WHAT? Nada!!!!!Niente!!!!!Nicht!!!!!In other words:NOTHING

I'm not expecting miracles from you guys, just the fact that you are out here is reassuring.

One other thing you may be willing to explain is what exactly is "corrupt data" and where does it come from.

[chikamic]

Here is a link to a Pervasive (the vendor of the Btrieve database Peachtree is built on) library article that gives good insight into the reasons for btrieve data corruption.

ftp.pervasive.com/support/refshelf/Corpt1.txt

Hope this sheds a little light.

[ELLIE]

To chikamic

I will try and let you know how I make out. Tks so much

[TheWolf]

Corruption is a term to describe the damage to a file. Not all corruption can be corrected with the integrity checks. You may want to click on the data damaged banner and see if they can assist further.

[Robert Walraven]

Database problems in Peachtree are almost never the direct fault of Peachtree itself but result from system or network problems. I've successfully repaired about 60 damaged Peachtree databases in the last few months and have seen two classes of problems

o Physically damaged files that need to be rebuilt outside of Peachtree, and

o Physically ok files that have inconsistent data in them.

The problem you are experiencing sounds like it falls in the second category since you are not getting any hard errors in Peachtree. This kind of problem can result from any number of causes depending on your configuration. For example, one of your computers that accesses Peachtree might have crashed in a middle of an operation where Peachtree was in the process of updating several files, only some of which got modified.

You were wondering why several people seem to have the same problem. Some of the causes of corruption can only occur when Peachtree is doing a particular operation and is interrupted in the process. This means that there are just a few standard ways in which the data tends to get corrupted.

Check out the "Data Damaged?" link at the top of this page. It won't cost you anything to have your data looked at to determine whether it is fixable.

[chikamic]

Thanks Robert,

It is always kind of hard to get the customer to understand what data corruption is and how it occurs. It is nice to have an expert who actually deals with Peachtree corruption on a regular basis to weigh in.

[ELLIE]

To Robert and chicamik

I will certainly try...thanks so much!

[slushi99]

I had this error message as well and it is almost always due to large sets of data, espcially if there is a lot of inventory activity. After excuting the rel7reg.reg update from the peachtree home page, my problems were vanished, or at least so far as to say. I reccomend ALL you guys to download this if you havent already espically if your having inventory issues. Also I plan on going to upgrade to MAS90 since we have a lot of Inventory in our database, tech support at peachtree is currently setting me up for this and the cool thing is that everything can be customized. wooppiee!

[YOUNGBLOODLTD]

We fixed our inventory history problem!

Truth is, we used a little bit of info from several of the senior contributors and together it all seemed to work. I'm going to recount our steps, although I think our beginning steps really didn't do anything to help.

1. Quantity on Hand - Our QOH's had become really weird numbers. We decided that maybe our inventory was getting too large since we had never purged any inactive items. We used inventory adjustments date December 31, 2001 to set all inactive items to QOH zero so they would purge.

2. We closed 2001.

3. We purged 2001. Those inventory items that we had made sure had quantities of zero did NOT purge because, by using inventory adjustment, we created a journal entry. As we all know, anything with any journal entry for that year will not purge. So, database was only slightly reduced in size by other "normal" data that was purged.

4. We ran Data Verification. No errors were found, therefore, no fixes were applied.

5. We ran Integrity Check (without the help of tech support) and checked only Inventory/Journal under Data Synchronizaton.

It worked! Our hisotry balances were back and correct. I can't wait to see if it goes wrong again in July.

If this helps anyone else, let us know. Good Luck!

[allkem]

I am as well glad as Ellie mentioned to have come across this site by chance. And thanks to Nancy for starting this thread. We are using Peachtree Complete Accounting version 7.0
The first year was year 2000. There was no problem in 2001. Then came 2002 and I close year 2000. It worked well till June and from July 2001 the problem is same as mentioned by Nancy, Ellie and Youngblood ltd. However in my case the collection amount (Receipt) from customers are as well being accumulated together with last year as had been the case with sales figure and inventory.

To Nancy: You mentioned of patch for version 7.0
As I said we are using version 7.0 and I searched the peachtree site and couldn't find it. Any idea where can I download it from? If as you said it solves the problem i will be greatly relieved.

I once again thank you all.

[TheWolf]

Originally posted by allkem
I am as well glad as Ellie mentioned to have come across this site by chance. And thanks to Nancy for starting this thread. We are using Peachtree Complete Accounting version 7.0
The first year was year 2000. There was no problem in 2001. Then came 2002 and I close year 2000. It worked well till June and from July 2001 the problem is same as mentioned by Nancy, Ellie and Youngblood ltd. However in my case the collection amount (Receipt) from customers are as well being accumulated together with last year as had been the case with sales figure and inventory.

To Nancy: You mentioned of patch for version 7.0
As I said we are using version 7.0 and I searched the peachtree site and couldn't find it. Any idea where can I download it from? If as you said it solves the problem i will be greatly relieved.

I once again thank you all.

www.peachtree.com/update7

You will have to set up a Peachtree passport account to download the file.

[Diane Koers]

Well...I also support PT for a living and I have two different clients with the exact same problem. I've been running all kinds of tests on their data to clean it up but so far I've not been able to isolate nor fix the problem.

My clients are furious not being able to trust their data. Both instances occured after updating or closing.

[chikamic]

Diane,

I find that this error occurs in my clients that have large datasets and the activity that occurs during the close or updates has a problem completing due the amount of data in the dataset. I have also found that if Inventory/Journal data synch does not work my only course of action has been to have the client have the database repaired.

I am sure, due to the amount of expertise that you have in Peachtree, you know that the product is based on a 10 year old database (that the vendor does not even support anymore). I am also a MCSE and will say that under normal circumstances, I would advise my clients against running a 10 year old database. But we all know that this is all we have to work with at this time. Unfortunately, I have not been able to come up with an acceptable explanation for my customers either. So, until Peachtree upgrades the database structure we are stuck with some of these messes, that we are unable to expain to our clients (at least to their satisfaction)

PS, I deleted several posts giving advice on this issue from this thread because it got rather hostile, so the post that remains makes almost no sense .

[allkem]

Thanks a lot "The wolf"

I will try it.

[mikemapa]

Originally posted by YOUNGBLOODLTD
We fixed our inventory history problem!

Truth is, we used a little bit of info from several of the senior contributors and together it all seemed to work. I'm going to recount our steps, although I think our beginning steps really didn't do anything to help.

1. Quantity on Hand - Our QOH's had become really weird numbers. We decided that maybe our inventory was getting too large since we had never purged any inactive items. We used inventory adjustments date December 31, 2001 to set all inactive items to QOH zero so they would purge.

2. We closed 2001.

3. We purged 2001. Those inventory items that we had made sure had quantities of zero did NOT purge because, by using inventory adjustment, we created a journal entry. As we all know, anything with any journal entry for that year will not purge. So, database was only slightly reduced in size by other "normal" data that was purged.

4. We ran Data Verification. No errors were found, therefore, no fixes were applied.

5. We ran Integrity Check (without the help of tech support) and checked only Inventory/Journal under Data Synchronizaton.

It worked! Our hisotry balances were back and correct. I can't wait to see if it goes wrong again in July.

If this helps anyone else, let us know. Good Luck!

I just want to let you know that I came here with the exact same problem you folks mentioned--inventory items of July-Dec in one year being repeated in the next--and the above procedure was the solution to my problem. Thank you so much!

[ELLIE]

The integrity check has to unpost all related transactions. One of the problems that some of us run into is that the system cannot find certain transactions, such as "non-existing" invoices and therefore cannot complete its function!

PS: The invoices do in fact exist, were entered and paid for properly and the so called "fix" that the PT techs recommend does NOT work! Futhermore, these "non-existing" invoices surely do exist when I print my statements for the affected cusomers, and unfortunately, show up as still open (unpaid).

[mikemapa]

Originally posted by mikemapa


I just want to let you know that I came here with the exact same problem you folks mentioned--inventory items of July-Dec in one year being repeated in the next--and the above procedure was the solution to my problem. Thank you so much!

I forgot to add a question: will this happen every year? Will I have to do this every time I close a fiscal year? What's your experience?

[ELLIE]

Yes, it does seem to happen every year... in my experience it also affects sales under the customer profile. That I can resolve by running the customer/journal integrity check. It is a relatively painless operation that only takes a few minutes.
Since I operate on a calendar year and always keep 24 periods open, I do not have to close nor purge since the errors show up in July.
I have performed this operation for the last two years without any adverse effects....that I'm aware of.

[lilguy]

I am so relieved to find that I am not the only one having this problem. I have been running Peachtree for over 10 years. I have had this same problem every year for the last 5 years. In the past I have successfully fixed this problem with reindexing files and running a synch of the inv/journ. This year I was unable to fix the problem, I received a file system error 100. I contacted PT they gave me the standard response DB to big 450 before purge 220 after closing 2003 and purge. Still no fix I am currently waiting for the DB to be fixed sent it to acct users. What I dont understand is in the past I was able to fix a DB this size with less of a computer. Any suggestions as to why I can't fix now. System (win nt peer to peer server - 3.2 ghz proc 1 g ram 2 - 160 ghz sata hard drives running in raid) Speed is not an issue I can Reindex 650,000 record journal.dat in less than two hours with no problems. Please Help!!!!!!!

[TheWolf]

Originally posted by mikemapa


I forgot to add a question: will this happen every year? Will I have to do this every time I close a fiscal year? What's your experience?

It should not happen every year. Keep your database streamlined by closing old years as soon as possible and running a purge. This should keep the history from getting unsynced.

Someone in this forum mentioned this problem was a defect and I asked they contact me privately about the information but they never did. Since this does not happen with all customers or even a majority of them, it does not seem like a defect.

[TheWolf]

Originally posted by lilguy
I am so relieved to find that I am not the only one having this problem. I have been running Peachtree for over 10 years. I have had this same problem every year for the last 5 years. In the past I have successfully fixed this problem with reindexing files and running a synch of the inv/journ. This year I was unable to fix the problem, I received a file system error 100. I contacted PT they gave me the standard response DB to big 450 before purge 220 after closing 2003 and purge. Still no fix I am currently waiting for the DB to be fixed sent it to acct users. What I dont understand is in the past I was able to fix a DB this size with less of a computer. Any suggestions as to why I can't fix now. System (win nt peer to peer server - 3.2 ghz proc 1 g ram 2 - 160 ghz sata hard drives running in raid) Speed is not an issue I can Reindex 650,000 record journal.dat in less than two hours with no problems. Please Help!!!!!!!

The FSE 100 you are getting, happens usually during the unpost or repost of the transactions. I have corrected this problem in many databases by closing previous years, purging the data down to a smaller size and then running the inventory/journal sync test. The two customers that had this problem last year, still do not have the problem this year.

[fl7464]

Has the problem of data being brought from last years month totals into this years month totals been solved or figured out? This happens every July to our customer data and now this year it has happened to our unit activity in the inventory.

Terry

[ttran]

I have dealt with this problem since "Peachtree 5". I am now up to Premium 2006. I was hoping that by now they (meaning Peachtree or Sage) would have figured it out.
But, low and behold, we once again find ourselves having to correct our data with "integrity check". Fortunately, it has worked over the years. As a side comment, we start getting this problem in July. I suspect that it may have something to do with fiscal year or??? We don't use the fiscal year. I can't tell you what a godsend this forum is. Peachtree has never been any help.