web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics GP (Archived) / Records not going from...
Microsoft Dynamics GP (Archived)

Records not going from PO work table to PO history table

(0) ShareShare
ReportReport
Posted on by Community Member

GP 10 (10.00.1319)

I noticed something strange the other day, and I'm not sure if it is something to be concerned about or not.  I only just now noticed it because our reporting is mostly on the sales/financial series.

I have no records in my Purchase Order History table (POP30100) with a docdate after 10/31/2007.  They are all in the Purchase Order Work Table (POP10100).

This is right after our accounting user was replaced.  I know changes were made, but there is no documentation of what was changed (I was not Sys Admin at the time).

There are no errors when I run check links on the purchasing series, no PO issues have been brought to my attention and it is very well possible that this is the way things should be for our setup. Also there are records in the PM Transaction History Table (PM30200) table after this date.

Any clue as to why this?  Is it a concern?  Anything I can check further?

cheers,

brad

*This post is locked for comments

I have the same question (0)
  • Sagi88 Profile Picture
    Sagi88 2,250 on at

    Hi Brad.

    Moving purchgase orders from a Work?OPen stauts to a historical status is a manual operation.

    You need to goto Purchasing - Routines - Remove Completed Purchase Orders.

    This routines moves data from PO1000's tp POP30000's files.

    In order top complete PO quantities mus be received and/or cancelled, all receiving lines must be matched to invoices.

    Hope this helps

  • Community Member Profile Picture
    Community Member on at

     thank you so much!  think i'm gonna schedule this as an every 3 month or so regular maintenance task (moving po's older than 3 months).  I wonder if my user's will notice a signficant performance increase.  39,000 current records in POP10110.

  • Ron Wilson Profile Picture
    Ron Wilson 6,010 on at

    Brad,

    I am not sure if they will notice a performance increase or not.  It definitely couldn't hurt.  One thing I would caution you about is your reporting.  If you have any reports that are looking at the POP10100/POP10110 tables and you move everything to history then your reports will no longer show the data.  I have run into this issue when I manually move purchase orders to history.

    Just a heads up.

    Ron

  • Community Member Profile Picture
    Community Member on at
     Hmm, all seemed to work correctly I moved everything up untill the middle of last year and set up Outlook reminders to do this every six months.  I have one issue though.  My accounting user now gets an error when she goes to Inquiry>Purchasing>Purchase Order Documents screen. This only shows up when I attempt to pull a range of “all po’s”

    So she can pull a range no problem, it's only when she pull's all po's

     [Microsoft][SQL Native CLient][SQL Server]Violationof PRIMARY KEY constraint 'PK##0894706'.  Cannot insert duplicate key in object 'dbo.##0894706'.

    When they Hit Ok, they get

     

    The stored procedure popSelectPODocInquiry returned the following results: DBMS: 267, Microsoft Dyanmics GP: 0.

     Under More Info it says:

    "Plases consult the alert message documentation provided by your DBMS"

     

    Any ideas?  check links did not resolve the issue.  is the DMBS our SQL Server 2005 instance?

     

     
  • Beat Bucher GP Geek GPUG All Star Profile Picture
    Beat Bucher GP Gee... 28,058 Moderator on at

     Hi Brad,

    This error message seems to indicate that something was done on the PO tables that GP didn't really took notice. I know it sounds weird, but one thing you may try to start with is doing a reconcile of the POP documents off hours (can take some time) and also a check-links of your Purchasing module to ensure integrity of the tables (removal of orphan entries in the work tables vs. history).

    On which version of GP are you ? did you copy here the entire error message ?
    Let us know the result of the reconcile and check-links.

    Best regards,
    Beat
    Sr. Sys Admin GP10

  • Community Member Profile Picture
    Community Member on at

     We're rocking GP 10 (10.00.1319)

     Ran check links on all modules with no errors reported.  I run check links on all modules monthly.

     When you say "do a reconcile of the POP documents off hours" do you mean "tools > utilities > purchasing > reconcile" ?

    I've read this is something we should do on the regular (maybe monthly) for both sales and purchasing  but my accounting user expressed reservations about the ramifications of doing this and I just haven't had time to research it further.  Are you suggesting I should do a backup and then do this?

  • Ron Wilson Profile Picture
    Ron Wilson 6,010 on at

    It is not only a monthly process for us, but I try to reconcile INV, SOP, and POP weekly.  I typically don't backup, but if you want to you can (and I probably should).  Reconcile is going to "change" anything that doesn't need to be "changed".  If you have a problem it will fix it and let you know what it fixed.  I used to have reservations about it, but it is solid.

    Ron

  • Community Member Profile Picture
    Community Member on at

     oh and yes that is the entire error message, i just now saw the insert image and paste from word options on here

  • Community Member Profile Picture
    Community Member on at

     Thanks Ron, that was my thinking on it, especially after my brief research on it.  I don't think we need to reconcile inventory as we don't have a "real" one.  we're middlemen and do logistics and such.  I may try to run these tonight.

  • Community Member Profile Picture
    Community Member on at

    Hi Brad,

    When you open the PO Enquiry window and just select eithre Open or History and click refresh, do you get the error? Or do you only get it when both Open and History are ticked at the same time? 

    If yes, then your error message is likely caused by the same PO existing in the Open and History tables at the same time. You will need to write a sql query that searches for PO numbers in the PO History table that also exist in the PO Open table. Use the Header tables. This is an error, probably caused by something interrupting the transfer to history process. When you find the offending PO you can delete it from one of the tables. If it is a genuinely completed PO, then you can delete it from the open table.

    I think there is a utility in the Professional Sevices Tools library that finds duplicates like this...but I could be wrong!

    Hope this helps.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Congratulations to our 2025 Community Spotlights

Thanks to all of our 2025 Community Spotlight stars!

Congratulations to the February Top 10 Community Leaders

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans