Dynamics GP Purchase Order Tables: POP10100 and POP10110

Dynamics GP stores purchase orders in two main tables: POP10100 holds the purchase order header (one row per PO) and POP10110 holds the line items (one row per line). Both are work tables. Once an order is fully received, invoiced, and closed, GP moves it to the history tables POP30100 and POP30110. Any query that reads only the POP101xx tables will silently miss every completed order.

Last updated August 2026.

The work-versus-history split is the thing that catches people first. You write a report against POP10100, it looks right for a week, and then a controller asks why last quarter's orders vanished. They did not vanish. They moved. Everything below is the map: which table holds what, how they join, what the status codes mean, and where the same data lives if you are actually on Business Central or Dynamics 365 Finance and Operations rather than GP.

What table are purchase orders stored in Dynamics GP?

Purchase orders live in the Purchase Order Processing module, whose tables all carry the POP prefix. The header is POP10100 and the lines are POP10110 while the order is active. When the order is closed or canceled it is moved to POP30100 and POP30110. Four tables, and you almost always need all four.

The naming convention holds across the whole GP database, not just purchasing: a 10 in the third and fourth position means work, 20 means open, 30 means history. Sales Order Processing uses SOP10100 and SOP30200 the same way. Once you internalize that, you can guess table names in modules you have never touched.

How to join POP10100 to POP10110

The join key is PONUMBER on both tables. That is the whole relationship for a simple header-to-lines query:

SELECT h.PONUMBER, h.VENDORID, h.DOCDATE, h.POSTATUS,
       l.ORD, l.ITEMNMBR, l.ITEMDESC,
       l.QTYORDER, l.QTYCANCE, l.UNITCOST, l.EXTDCOST
FROM   POP10100 h
JOIN   POP10110 l ON l.PONUMBER = h.PONUMBER
ORDER  BY h.PONUMBER, l.ORD

ORD is the line sequence number, and it is worth understanding rather than ignoring. GP does not number lines 1, 2, 3. It increments the sequence by 16384, so the first three lines of an order are 16384, 32768, and 49152. The gap exists so that a line inserted between two existing ones gets a value in between without renumbering anything. If you order lines by ORD you get the correct on-screen sequence; if you order by anything else you will eventually hand somebody a PO printout with the lines shuffled.

To see the full life of an order, including closed ones, you have to union the work and history tables rather than joining them. A PO exists in one pair or the other, never both:

SELECT PONUMBER, VENDORID, DOCDATE, POSTATUS, 'WORK' AS SRC
FROM   POP10100
UNION ALL
SELECT PONUMBER, VENDORID, DOCDATE, POSTATUS, 'HISTORY' AS SRC
FROM   POP30100

POSTATUS and POLNESTA: the purchase order status codes

POP10100 carries POSTATUS, the status of the order as a whole. POP10110 carries POLNESTA, the status of each individual line. They use the same set of values, which is convenient, and they can legitimately disagree with each other, which is the part that confuses people. An order sitting at Released can easily contain one line that is already Received and two that are not.

Because the line status is independent, "is this order open?" is usually a line-level question, not a header-level one. The reliable test for an outstanding quantity is QTYORDER minus QTYCANCE minus QTYSHPPD on POP10110, filtered to lines whose POLNESTA is not 5 or 6. Reading POSTATUS alone tends to overstate what is genuinely still coming, which is exactly how an open purchase order report drifts away from reality.

Receipts and invoices: the POP10300 and POP30300 families

Receiving does not write back into the PO tables. It creates its own documents, which then reference the order. That is why a receipt quantity and a PO quantity can disagree and why matching is a join rather than a lookup.

Receipt lines carry both POPRCTNM (the receipt number) and PONUMBER with ORD, so you can tie a posted receipt line back to the exact PO line it satisfied. POP10600 is the table you need when an invoice arrives separately from the shipment and you are trying to reconstruct a three-way match after the fact.

The supporting POP tables worth knowing

Comments are a common source of surprise. They are not columns on the PO line; they sit in POP10550 keyed by PONUMBER and ORD, so a report that needs the note a buyer typed against line three requires an extra join that nobody remembers until the output looks empty.

Dynamics GP vs Business Central vs Dynamics 365 purchase order tables

Three products carry the Dynamics name and none of them share a purchasing schema. If you searched for Dynamics purchase order tables and the POP names look nothing like your database, you are probably on one of the other two.

Business Central is the important one to get right, because a purchase order there is not a separate table from an invoice. Purchase Header holds all four document types in one place, distinguished by the Document Type enum: Order, Invoice, Credit Memo, and Return Order. Every query needs Document Type in the where clause or you will pull credit memos into a purchase order report. Purchase Line works the same way, joined on Document Type plus Document No., with a Type field that separates Item lines from G/L Account, Resource, Fixed Asset, and Charge lines, plus a blank value used for comment lines.

Dynamics 365 Finance and Operations keeps a single PurchTable regardless of state and tracks progress through two separate enums. PurchStatus describes where the order is in the receiving and invoicing lifecycle, while DocumentState describes where it is in approval: Draft, then Approved. People routinely read one and mean the other, and a report filtered on the wrong enum is a genuinely hard bug to spot because it returns plausible rows.

Getting data into these tables rather than out of them

Everything above is about reading. The harder job is usually writing, because purchase orders arrive as documents. A customer emails a PDF, a vendor mails a paper order, somebody photographs one on a loading dock, and the fields have to reach POP10100 and POP10110 somehow.

You should not insert directly into these tables. GP maintains index tables, sequence values, and distribution records alongside them, and hand-written inserts leave the database in a state the application cannot reconcile. The supported paths are eConnect, which exposes the taPoHdr and taPoLine stored procedures under the POPTransactionType document, or a tool such as Integration Manager or SmartConnect layered on top of eConnect.

Two eConnect details cost people a lot of time. The taPoHdr node requires TAXAMNT, and eConnect validates it by summing the tax on every line plus related freight and miscellaneous tax, so a header total that does not reconcile to the lines fails the whole document. And if you omit ORD from taPoLine, eConnect treats a repeated item number as an update to the existing line rather than a new line, which quietly collapses a five-line order into three. Supply the sequence number explicitly.

None of that solves the first problem, which is turning the document into fields at all. That is the step our Dynamics GP purchase order import page covers: read the PDF, scan, or photo, get the header and the full line-item table back as Excel, CSV, or JSON, then feed that to eConnect or Integration Manager instead of typing it. The general pattern across systems is in how to import purchase orders to an ERP, and if you are reporting off these tables downstream it is worth mapping where each field ends up, since a column that three warehouses depend on is a data lineage question long before it is a purchasing one.

Common questions about Dynamics GP purchase order tables

What is the difference between POP10100 and POP30100?

POP10100 is the work table and holds purchase orders that are still active: new, released, change order, or partially received. POP30100 is the history table and holds orders that have been closed or canceled. A purchase order exists in one or the other, never both, so reports that need all orders must union the two.

Why can I not find a purchase order in POP10100?

Because it has been closed or canceled and moved to POP30100. This is the single most common cause of a GP purchasing report showing fewer orders than expected. Check POP30100 before assuming the record was deleted. In POP30100 the STATGRP column separates the two cases: voided orders carry 1 or 0, while normally closed orders carry 2.

What is the ORD field in POP10110?

ORD is the line sequence number, and it controls display order on the purchase order. GP increments it by 16384 rather than by 1, so lines are numbered 16384, 32768, 49152 and so on. The gaps let a user insert a line between two existing lines without renumbering. Always sort by ORD to get the on-screen sequence.

How do I find open purchase order lines in Dynamics GP?

Query POP10110 for lines where QTYORDER minus QTYCANCE minus QTYSHPPD is greater than zero and POLNESTA is not 5 (closed) or 6 (canceled). Header status alone is not enough, because POSTATUS describes the order as a whole while individual lines can be at different stages.

Can I insert purchase orders directly into POP10100?

No. GP keeps index tables, next-number sequences, and distribution records in step with the PO tables, and a direct insert bypasses all of it, leaving records the application will not open correctly. Use eConnect (taPoHdr and taPoLine), Integration Manager, or SmartConnect, all of which run the same validation the screen does.

Which table holds purchase order line comments?

POP10550 holds line item comments and POP10150 holds header-level comments. Neither is a column on the PO line itself, so a report that needs comment text requires a join on PONUMBER and, for line comments, ORD.

Is Dynamics GP still supported?

It is supported, but on a published clock. Microsoft ends product support and updates for Dynamics GP on December 31, 2029, with security patches continuing until April 30, 2031, and new subscription sales stopped on April 1, 2026. Existing installations keep running and the table structure described here is unchanged. Teams planning the move to Business Central should expect the purchasing schema on the other side to look like Purchase Header and Purchase Line rather than POP10100 and POP10110.

Quick reference

If you remember four things: the header is POP10100 and the lines are POP10110, closed orders move to POP30100 and POP30110, the join is PONUMBER plus ORD, and ORD counts in steps of 16384. Nearly every GP purchasing report problem is one of those four not being accounted for. For the fields that appear on the order itself rather than in the database, see purchase order fields, and for the equivalent schema on other systems there is purchase order history in SAP and Oracle purchase order tables.