ERP
Microsoft Dynamics GP
Connect your AI to Microsoft Dynamics GP
Controllers, AP clerks, and warehouse managers run their operations inside GP's desktop client, but the cloud-based teams that depend on that same data have no way to reach it without VPN and RDP access. AI closes that gap, but only through a connection that is governed and enforces GP's own business rules and translates its cryptic data model into something the AI can actually use.
Why it matters
Capabilities that matter most for Microsoft Dynamics GP
01
Archive GP history to a data lake
The Data Lake Exporter copies years of GP history, attachments included, to Azure or Amazon storage as CSV or Parquet. Keep reporting on it from Popdock long after you retire the GP database.
02
Every GP table, not just reports
Build lists straight over GP tables and write calculated fields in T-SQL, so the answers that SmartLists and SSRS never covered are a filter away.
03
On-premises GP, reached safely
The Popdock gateway reaches GP servers inside your network without opening the database to the internet, so AI tools can answer from GP wherever it is hosted.
03
110 API endpoints ready to install
A full set of GP API endpoints is in the app store, covering customers, vendors, items, sales and purchasing, ready to drop into any account in a click.
Use cases
Example AI Use Cases for Microsoft Dynamics GP
scenario
-
A targeted campaign to everyone who bought a particular product starts with a sales history report in Dynamics GP, then a hunt for each buyer's email, then a check in Constant Contact before anyone is added. Most teams give up partway and send to the whole list instead.
What popdock provides
--
Give an item number, a Constant Contact list and optionally a look-back period, a year by default, and it confirms the item in Dynamics GP and totals each active customer's quantity and spend on it. Each buyer's email is checked in Constant Contact and sorted into already on the list, a contact not on the list, not a contact, or no email in GP. You see the buyers to be created with their quantity and spend, and contacts are created only after you say yes, with permission left unset. If the sales history was capped, it warns that the buyer list may be incomplete.
Business outcome
---
You can run a campaign aimed at the customers who actually bought the product, built from real sales history.
scenario
-
Customers set up in Dynamics GP rarely make it into Constant Contact on their own. Adding them means pulling active customers by class or salesperson, checking each email, and creating contacts without disturbing the ones already there or treating a customer record as an opt-in.
What popdock provides
--
Name an existing Constant Contact list, and optionally a customer class or salesperson, and it reads active Dynamics GP customers with an email, using the first address where several are stored. Each one is checked in Constant Contact and sorted into on the list, a contact not on the list, or not a contact, and customers with no email are reported. Contacts are created only for the missing ones after you confirm, with permission left unset because a customer record is not an opt-in. Existing contacts are reported but never changed, and one failure does not stop the rest.
Business outcome
---
Your GP customers become reachable in Constant Contact without touching existing contacts or overstating their consent.
scenario
-
Before collections emails go out, someone should check that overdue Dynamics GP customers can actually receive them. Addresses that bounce, contacts who unsubscribed and customers with no email on file all mean a reminder that goes nowhere while the debt ages.
What popdock provides
--
Optionally set a minimum overdue amount, and it totals each customer's past-due receivables in Dynamics GP from open, non-voided documents. Every email on file is checked in Constant Contact, and each customer is marked reachable, unsubscribed, bouncing in the last 180 days, not in Constant Contact, or no email in GP. The table is sorted by overdue amount with contact person and phone, and it ends with the total owed by customers you cannot reach by email. It notes that a marketing unsubscribe does not prevent sending an invoice, and nothing is changed.
Business outcome
---
Collections knows which overdue customers need a phone call, and how much money is tied up with them.
scenario
-
An account manager preparing for a customer conversation needs the balance, credit limit and recent orders from Dynamics GP, and the email engagement from Constant Contact. GP often stores several addresses in one field, so even finding the right contact in Constant Contact takes trial and error.
What popdock provides
--
Give a Dynamics GP customer id, and optionally a look-back period, 90 days by default, and it reads the customer's balance, credit limit, hold status, overdue amount and recent sales documents. Every stored email is tried in Constant Contact, with a careful company name fallback that accepts only a contact clearly tied to the GP contact person. You get their permission, lists, tags, opens, clicks and bounces, plus notes worth acting on, such as an unsubscribed contact with an overdue balance. If two contacts match it says which it used and why, and nothing is changed.
Business outcome
---
You see a GP customer's account health and email engagement together, before your next call or collections step.
scenario
-
After a campaign, you want to know which of your actual customers responded, but Constant Contact sees email addresses and Dynamics GP sees accounts. GP cannot search customers by email, so matching recipients to accounts and checking for orders afterwards is a manual cross-reference.
What popdock provides
--
Name a sent Constant Contact campaign, and optionally a customer class, and it collects each recipient's opens, clicks, bounces and unsubscribes. It builds a lookup of every email stored on active Dynamics GP customers and matches recipients to accounts, counting but not listing those who are not customers. For customers who clicked, it checks for sales documents placed since the send. You get a table with balance and orders since the send, clickers with orders first, plus bounced customers with their GP phone and contact so the address can be fixed. It reads and reports, and changes nothing.
Business outcome
---
You see which customers responded to a campaign and ordered afterwards, plus whose email on file needs fixing.
scenario
-
Account managers working in Dynamics GP never see that a customer clicked last week's campaign or unsubscribed with a complaint. Copying that into customer notes by hand is tedious, and a careless edit can overwrite the notes already on the record.
What popdock provides
--
Name a sent Constant Contact campaign, and it collects everyone who clicked, with their links, and everyone who unsubscribed, with their reason. Recipients are matched to active Dynamics GP customers by every email on file, and those who are not customers are only counted. You see each note before anything is written, with the campaign name, send date and what happened, and a customer who both clicked and unsubscribed gets one note saying both. Notes are appended with a date and time only after you confirm, and an existing note is never overwritten.
Business outcome
---
Campaign responses show up on the customer record in Dynamics GP, where account managers already look.
scenario
-
Over time Dynamics GP and Constant Contact drift apart: customers with no email, customers never added, contacts who unsubscribed, and names, phones or cities that no longer match. Checking every active customer means splitting GP's multi-address email field and comparing record by record.
What popdock provides
--
Optionally name a customer class or salesperson, and it reads up to 200 active Dynamics GP customers and tries every email address on file in Constant Contact. Matched pairs are compared on company, contact name, phone by digits, city and state, ignoring case, punctuation and spacing. You get four tables: no email in GP, not in Constant Contact, unsubscribed with their balance, and details that differ with both values. GP is treated as right for name and address and Constant Contact for email permission, a capped result is called out, and nothing is changed.
Business outcome
---
You get a complete gap list between your ERP and your email audience, with clear rules for which side wins.
scenario
-
After a move from Dynamics GP to Dynamics 365 Business Central, some active customers inevitably never made it across. Finding them means comparing two customer lists whose IDs differ in case and padding, then keying each missing one in by hand, with the risk of exceeding ID length limits or forgetting that open balances do not come with them.
What popdock provides
--
Name one customer or let it check every active one, and it compares Dynamics GP with Dynamics 365 Business Central, matching IDs regardless of case and spacing. IDs too long for Business Central are set aside, and customers with a GP balance are flagged because the balance does not move with them. You confirm the list, or a subset, before anything is created, and it writes only to Business Central, up to a limit you set. Each new customer is read back, and you get the GP payment terms and class for each so you can finish the setup.
Business outcome
---
Missing customers reach Business Central with their contact and credit details, and you know exactly what setup is left.
scenario
-
Proving a customer migration from Dynamics GP to Dynamics 365 Business Central is right means checking names, payment terms, credit limits, salespeople, contact details and hold status customer by customer. GP pads IDs and stores phones as padded digits, so a naive comparison flags hundreds of false differences and buries the real ones.
What popdock provides
--
Name a customer or check every active one, and it reads both Dynamics GP and Dynamics 365 Business Central, matching IDs regardless of case and padding. It compares names, terms, credit limits, salespeople, city, state, email, phones on digits only, and GP holds against Business Central blocks. When a whole group of customers has terms renamed the same way, it reports that once as a mapping. You get counts, a table of differences, missing customers, and Business Central customers created after go-live. It warns if a list may be truncated, and nothing is changed in either system.
Business outcome
---
You sign off a customer migration with every real difference listed and the formatting noise filtered out.
scenario
-
Checking that inventory arrived in Dynamics 365 Business Central from Dynamics GP means comparing descriptions, units of measure, costs, item types and quantities on hand for every item. Item types use different names in each system, GP splits quantities by site, and a long list of small differences hides the few gaps that are worth real money.
What popdock provides
--
Name one item or check all of them, and it compares Dynamics GP items with Dynamics 365 Business Central, leaving out discontinued items but counting them. It totals GP quantities across sites where needed, maps GP item types to their Business Central equivalents, and flags cost differences over one percent. Quantity gaps are ranked by their value at current cost, so the costliest come first. If Business Central shows zero for everything, it says opening quantities have not been posted yet instead of listing every item. Both systems are only read.
Business outcome
---
Inventory sign-off focuses on the quantity gaps that matter most in value, not a wall of rounding noise.
scenario
-
A vendor that is missing or set up differently in Dynamics 365 Business Central after a Dynamics GP migration can stop payments on the first day live. Checking names, terms, hold status, contacts and phone numbers vendor by vendor is slow, and the most urgent case, a missing vendor that still has an open balance, is easy to overlook.
What popdock provides
--
Name a vendor or check every active one, and it compares Dynamics GP vendors with Dynamics 365 Business Central, ignoring inactive and temporary vendors and matching IDs regardless of case. It compares names, payment terms, holds against blocks, contacts, city, state, email and phones on digits only, and reports a terms renaming once as a mapping. Missing vendors are listed with their GP balance, because one with money owed blocks the payables cutover. Vendors created after go-live are shown separately, and nothing is changed in either system.
Business outcome
---
Payables cutover goes ahead knowing every vendor with an open balance exists in Business Central and matches.
scenario
-
Proving open payables moved correctly from Dynamics GP to Dynamics 365 Business Central means comparing each vendor's balance, then digging through invoices and ledger entries to explain every difference. Signs run the opposite way in each system, some migrations post under the voucher number, and an invoice left behind will simply never get paid.
What popdock provides
--
Name a vendor or check all vendors with a balance, optionally as of the go-live date, and it compares each balance in Dynamics GP and Dynamics 365 Business Central, correcting for the opposite sign convention. For every vendor out by more than a cent it matches open documents by invoice number, then voucher number, and says which are missing, extra or different. Summary-level migrations are recognized, any unexplained remainder is stated rather than guessed, and open GP invoices due within 14 days that are missing are called out. Nothing is written.
Business outcome
---
You prove the payables carryover vendor by vendor and catch invoices that would otherwise go unpaid after go-live.
scenario
-
Purchase orders still open in Dynamics GP at go-live need to exist in Dynamics 365 Business Central, or goods arrive with nothing to receive them against. Checking means matching order numbers that may have been renumbered, comparing vendors, remaining amounts and promised dates, and allowing for tax that one side includes and the other does not.
What popdock provides
--
Name a vendor or check every vendor, and it reads open purchase orders in Dynamics GP, including those on hold, and finds them in Dynamics 365 Business Central by order number, then by vendor order number, then by vendor and amount within one percent, marking those as probable. It compares vendor, remaining amount with tax allowed for, expected date and currency. Missing orders are listed soonest receipt first, and if none were migrated it lists what buyers must re-enter. Neither Dynamics GP nor Business Central is written to.
Business outcome
---
Buyers know which open orders need re-entering before the goods turn up, soonest receipts first.
scenario
-
Proving that customer balances carried from Dynamics GP into Dynamics 365 Business Central means comparing every customer and then tracing each difference to documents. GP stores payments and credits as positive while Business Central stores them as negative, and post go-live activity muddies current balances, so manual checks take days.
What popdock provides
--
Name a customer or check all customers with a balance, optionally as of the go-live date, and it compares each balance in Dynamics GP and Dynamics 365 Business Central. For any customer out by more than a cent it lines up open documents by number, flipping signs on payments, credits and returns, and shows what is missing, extra or different. Summary-level migrations count as in balance, any unexplained remainder is reported rather than guessed, and nothing is written to either system.
Business outcome
---
Receivables carryover is proven customer by customer, with every difference traced to the documents behind it.
scenario
-
Tying out the Dynamics GP trial balance to Dynamics 365 Business Central is a standard migration check, but GP accounts carry several segments while Business Central keeps the main account and moves the rest to dimensions. Rolling up dozens of GP accounts, handling balance sheet and income statement periods correctly and matching dates is error-prone spreadsheet work.
What popdock provides
--
Give the fiscal year, period, as-of date and year start, and it builds the Dynamics GP trial balance, adding beginning balances only for balance sheet accounts, and rolls accounts up by main segment. It then totals Dynamics 365 Business Central ledger entries for each matching account and lists differences largest first, unmatched accounts on both sides, and whether each side nets to zero. It warns when dates do not line up or a total may be incomplete, and if the account mapping is custom it stops and asks rather than guessing. No record in either system is touched.
Business outcome
---
Controllers tie out the migrated general ledger account by account, with the largest differences surfaced first.
scenario
-
After moving from Dynamics GP to Dynamics 365 Business Central, a customer's history is split in two. Seeing whether they are buying more or less means pulling sales from both systems by month, and the migrated opening entries in Business Central make it easy to count the same invoices twice and overstate recent sales.
What popdock provides
--
Name the customer and the go-live date, and it reads Dynamics GP history up to go-live and Dynamics 365 Business Central activity since, leaving out migrated opening entries so nothing is counted twice. You get monthly sales running straight across go-live, totals before and after, open orders, quotes and invoices with due dates, and anything that changed at go-live, such as salesperson, terms or credit limit. GP sales posted after go-live are shown separately. If the go-live date is missing it asks, and nothing is changed.
Business outcome
---
Account managers see one honest sales trend for a customer across both systems, without double counting.
scenario
-
Adding a tracking number to a Dynamics GP sales order sounds quick, but the customer usually quotes their own PO number, not yours. You search, find an order and its invoice under the same reference, and it is easy to attach the tracking to the wrong document so the customer never sees it.
What popdock provides
--
Give the order number or the customer's PO number and the tracking number, and it finds the matching sales document in Dynamics GP, trying your number first and then the customer's. If an order and its invoice both match, it lists them with type, customer and date and asks which one you mean. You see the order, amount and tracking number before anything is written, and nothing happens without a clear yes. The tracking is added once, and a failed write is reported exactly as returned rather than retried.
Business outcome
---
Tracking numbers land on the right sales order the first time, so customers and your team can follow the shipment.
scenario
-
Customer returns in Dynamics GP are spread across RMA headers and lines, and nobody has time to total them by reason, item and customer. Working out whether an item comes back often enough to worry about means pulling its sales separately and dividing by hand, while old RMAs sit open unnoticed.
What popdock provides
--
Name a date range, and optionally a customer, and it reads every RMA and RMA line in Dynamics GP for that period. Returns are totalled by reason code, item and customer, and for the ten most returned items it reads their sales over a wider window to give a return rate. Open RMAs older than 14 days are listed with status, age and any linked service call. It only reads; nothing in Dynamics GP is changed.
Business outcome
---
You see why products come back and which RMAs are stalling, without building a returns report by hand.
scenario
-
Reviewing project expense claims in Dynamics GP line by line is slow, so duplicates across reports, weekend claims and suspiciously round amounts slip through. Billable expenses that were never billed are just as easy to miss, and they cost you money rather than a policy breach.
What popdock provides
--
Give a date range, and optionally an employee, and it reads the expense reports and their lines from Dynamics GP. It screens for likely duplicates within three days, even across reports, lines dated on a weekend or outside the report dates, round amounts of 50 or more, claims over three times the employee's own average for that type, and billable lines still unbilled after 30 days. Each flag is presented as a question to ask, not an accusation. Nothing in Dynamics GP is changed.
Business outcome
---
Finance reviews only the expense lines worth a second look and recovers billable costs that would otherwise go unbilled.
scenario
-
Stock write-offs in Dynamics GP pile up one adjustment at a time, and they are hard to see as a pattern. Spotting items adjusted again and again, large round-number write-offs or adjustments never posted means scrolling through inventory transactions and checking counts by hand.
What popdock provides
--
Give a date range, and optionally a site, and it reads adjustment and variance documents from Dynamics GP, leaving transfers out because they do not change value. It totals net quantity and cost by item and site, lists the 15 largest lines, items adjusted three or more times, unposted adjustments and round-number lines. For the ten biggest decreases it checks on hand and the last count date, so you can see whether a count explains the change. Findings are worded as items to explain, and nothing is changed.
Business outcome
---
Shrinkage and unusual write-offs surface early, with the context needed to explain them before an auditor asks.
scenario
-
Prices in Dynamics GP drift out of line with cost as purchase prices rise, and discounts given on individual orders drift further still. Finding items sold below cost or under your target margin means comparing price lists, item costs and invoice lines in separate screens.
What popdock provides
--
Choose an item class, a target margin and a lookback window, and it reads item costs and price lists from Dynamics GP and works out the margin on each currency price, saying which percent based rows it skipped. It then reads recent invoice lines to get the margin you actually achieved, the lowest price charged and to whom. You get items below cost, items under target on the list and in real sales, and items discounted more than 15 percent on average. It only reads and never changes a price.
Business outcome
---
Margin leaks are found by item and customer, so you can fix pricing before more revenue is sold below target.
scenario
-
Manual journal entries are where errors and manipulation hide, but in Dynamics GP they sit among thousands of system generated postings. Picking out the large, round, weekend or period-end entries an auditor would question takes hours of filtering and cross-checking.
What popdock provides
--
Give a date range and a size threshold, and it reads general ledger lines from Dynamics GP, keeping only the financial series where manual journals post. It screens for entries above the threshold, round thousands, weekend and last two days of the period postings, entries with no description or reference, accounts with no other activity, and the same amount posted twice to one account. Entries caught by three or more screens go to the top as a priority list. Flags are framed as questions, and nothing is posted or changed.
Business outcome
---
You get a ready audit sample of manual journal entries, ranked by how many warning signs each one shows.
scenario
-
Goods shipped back to vendors in Dynamics GP often sit in limbo: the vendor has them, but no replacement or credit has arrived. Tracking which returns are still owed means checking each RTV, its lines and the vendor's payables for a matching credit memo.
What popdock provides
--
Name a vendor, or leave it blank for all, and set how many days counts as overdue. It reads open returns to vendors in Dynamics GP, checks each line for goods shipped but not received back, and looks through each vendor's credit memos and returns since the shipment. Credits are matched only by amount or description and are labelled as possible matches, not certain ones. You get each vendor's outstanding returns, largest first, with a total awaiting recovery. Nothing is changed.
Business outcome
---
Purchasing knows exactly which vendor returns to chase and how much money is waiting to be recovered.
scenario
-
Before closing a month in Dynamics GP a controller has to check unposted batches, sales documents, receipts, timesheets, expenses and checkbook reconciliations, each in a different window. One forgotten batch or unreconciled bank account means reopening the period later.
What popdock provides
--
Give the period end date and it reads unposted batches in Dynamics GP, separating those waiting on approval from those nobody has posted. It then checks unposted sales documents, purchase receipts, project timesheets and expense reports, and any active checkbook not reconciled to the period end. You get a checklist with a ready or attention marker per area, counts, totals and the oldest items listed. Status values are reported exactly as returned, it notes what it cannot check, such as accruals, and nothing is changed.
Business outcome
---
Controllers see everything still blocking the close in one checklist, so periods close once instead of being reopened.
scenario
-
Closing a field service call in Dynamics GP while a work order is still open leaves billing and history out of step. You have to check every work order on the call, find the status code that means complete, and update the call without touching anything else.
What popdock provides
--
Give the service call number and a completion date, and it reads the call from Dynamics GP, stopping if it is already closed. It checks every work order on the call and refuses to continue while any is still open, listing them. It picks the status code that means completed, or asks you if none clearly does, then shows the call, customer, technician and new status for your confirmation. The call is updated once and read back, and the technician, priority and description are left alone.
Business outcome
---
Service calls close only when the work is really done, with the stored status confirmed afterwards.
scenario
-
Knowing which customers are buying more or less than last year means exporting two periods of sales from Dynamics GP and lining them up in a spreadsheet. Lapsed customers rarely stand out on their own, and the reason, often a hold or an inactive flag, is in another screen.
What popdock provides
--
Pick a date range and compare it with the prior period or the same dates last year. It reads invoices and returns from Dynamics GP for both, works out net sales per customer excluding tax and freight, and classes each customer as new, lapsed, growing or shrinking. For the ten largest lapsed customers it checks hold, inactive status and salesperson. The report shows totals for both periods, the top movers and how concentrated sales are in your top ten. It only reads.
Business outcome
---
Sales leaders see who is growing, slipping or gone, with the likely reason for each lapse alongside.
scenario
-
Choosing a supplier for an item in Dynamics GP usually comes down to whoever was used last. Comparing real cost trends, actual lead times and on-time delivery across vendors means matching purchase orders to receipts by hand, so the cheapest vendor and the most reliable one are rarely weighed side by side.
What popdock provides
--
Name the item and a lookback window, and it reads every vendor set up for it in Dynamics GP, setting aside vendors on hold or inactive. It reads receipts for cost history and trend, then matches purchase order lines to receipts to measure actual lead time and the share delivered on time. You get one row per vendor with stated and actual lead time, and a short recommendation that names the trade-off between cost and reliability. It says when an item is single-sourced, and nothing is changed.
Business outcome
---
Buyers choose where to source an item on evidence of cost and delivery, not habit.
scenario
-
When a prospect in Dynamics GP becomes a customer, someone retypes their name, address, contact and class into a new customer card. It is easy to create the customer twice, reuse an ID that is taken, or lose track of which prospect was converted.
What popdock provides
--
Name the prospect and the customer ID to use, and it reads the prospect from Dynamics GP and checks for an existing customer with that name or ID, stopping if either is found. It asks for a missing address, optional terms and salesperson, then shows every field to be written and where it came from. Nothing is saved until you confirm. The customer is created, the prospect gets a dated note recording the conversion, and the new customer is read back.
Business outcome
---
Prospects become customers once, with their details carried across and a clear record of the conversion.
scenario
-
Raising a customer return in Dynamics GP means checking the customer really bought the item, finding the original invoice price, and picking the right return type and reason code from setups you rarely see. Get the header in and the line fails, and you are left with an empty RMA.
What popdock provides
--
Give the customer, item, quantity and reason, and it finds the customer and address in Dynamics GP and checks their sales history, warning if they never bought the item or bought fewer than you are returning. It takes the last invoice price and reuses the return codes already in use, asking when the reason is unclear. You confirm every field before the RMA and its line are created, and the stored line is read back. If the line fails it tells you an empty RMA exists. No credit is issued.
Business outcome
---
Returns are authorized against a real sale at the right price, without guessing codes or leaving half-made RMAs.
scenario
-
Building a reorder purchase order in Dynamics GP means checking stock, allocations, open orders and recent demand for every item a vendor supplies, then applying minimum and economic order quantities. Done by hand it is slow, and items get missed or over-ordered.
What popdock provides
--
Name the vendor, and optionally an item class, and it checks the vendor is not on hold in Dynamics GP, then works out projected stock for every item they supply. Using 90 days of sales and each item's lead time it suggests quantities, rounded to order minimums, at the last receipt cost. You review, change or remove lines and confirm before the purchase order and its lines are created. If a line fails it stops and reports which exist, and the stored lines are compared with what you approved.
Business outcome
---
Reorders go out as one accurate purchase order per vendor, sized to real demand and confirmed by you.
scenario
-
Keying a sales order into Dynamics GP while checking the customer is not on hold, the stock is there, the price is right and the order will not breach the credit limit means jumping between several screens. Miss one and the order is entered, then stuck or shipped at the wrong price.
What popdock provides
--
Give the customer and the items with quantities, and it checks the customer for a hold or inactive flag in Dynamics GP, then confirms each item exists, its available stock by site and its price for the customer. It warns when the order would push the balance over the credit limit or the customer PO is already on another order. You confirm the full order before the header and lines are created, and the stored lines are read back. It never prices below the list unless you say so.
Business outcome
---
Sales orders go in right the first time, with credit, stock and price checked before you commit.
scenario
-
Entering a general journal in Dynamics GP by hand risks posting to an inactive account, an account that does not allow entry, or a journal that does not balance. A line that fails halfway through leaves an entry that is out of balance and hard to spot.
What popdock provides
--
Give a description, date and the journal lines, and it checks every account in Dynamics GP exists, is active and allows entry, and that debits equal credits to the cent. It will not add a balancing line or change an amount on its own. You confirm the entry number, batch, type and every line before the entry is created. If a line fails it stops and tells you the entry is incomplete, and afterwards it checks the entry or tells you it is waiting in its batch.
Business outcome
---
Journal entries reach Dynamics GP balanced and on valid accounts, with nothing invented or adjusted behind your back.
scenario
-
Project timesheets in Dynamics GP get rejected or misposted when time is booked to a closed project or a cost category that does not accept time. Entering a week of hours also makes it easy to double-book a day that already has time on the same project.
What popdock provides
--
Give the employee and their time entries, and it checks existing timesheet lines in Dynamics GP and warns about days already booked to the same project. Every project must be open and every cost category active and allowed for timesheets, or it stops. Days over 16 hours need your confirmation. You confirm the timesheet number, batch and every line before the timesheet and its lines are created, and the stored lines are read back. Costs and billing rates are left to the project setup.
Business outcome
---
Time lands on valid projects and categories without double-booking, ready for costing and billing.
scenario
-
Paying the same vendor invoice twice is one of the most common payables mistakes, and in Dynamics GP it often starts with keying an invoice that was already entered. Checking the vendor's status, the purchase order and the amount split takes time nobody has at month end.
What popdock provides
--
Give the vendor, invoice number and amount, and it checks the vendor's hold and status in Dynamics GP, then stops if that invoice number is already on file. It also warns about any invoice for the same amount in the last 60 days, and compares the total with a purchase order if you name one. Purchases, tax and freight must add up to the amount or it refuses to write. You confirm every field, the invoice is entered once, and the stored record and due date are read back.
Business outcome
---
Vendor invoices are entered once, matched to the right amounts, with duplicate payments stopped before they start.
scenario
-
When a GL account in Dynamics GP moves unexpectedly, explaining it means reading period balances, scrolling transactions and tracing each one back to the module and document that posted it. The period summary and the detail often disagree, and working out why takes even longer.
What popdock provides
--
Name the account and a date range, and it finds the account in Dynamics GP and reads its period balances and every transaction in the range. You get the net movement, totals by module and source document, the ten largest entries with their originating documents, and entries worth asking about, such as round amounts or weekend postings. It compares the detail with the period balances and explains likely reasons for any gap without forcing them to agree. Nothing is changed.
Business outcome
---
You can explain what moved any GL account and why, with the supporting entries in hand.
scenario
-
Installed equipment in Dynamics GP goes unserviced because nobody tracks last service dates across customers, and warranties expire without anyone offering a contract. Building an outreach list means checking each unit, its contract coverage and whether a call is already open.
What popdock provides
--
Choose a service interval, and optionally an office or customer, and it reads active equipment in Dynamics GP that is overdue for service or whose warranty ends within 60 days. Each unit is checked against the customer's contract lines to mark it covered or not, and units with an open service call already mentioning them are dropped. The list is grouped by customer, showing covered units as maintenance to schedule and uncovered ones as contract opportunities. It does not create service calls.
Business outcome
---
Service teams schedule maintenance before units fail, and sales sees which customers need a contract.
scenario
-
Late purchase orders in Dynamics GP are easy to lose track of, and the line status is not always right: some lines say open when the goods arrived weeks ago. Chasing vendors means checking receipts against every PO line and phoning the same vendor several times about different orders.
What popdock provides
--
Name a vendor, or none for all, and how many days late counts, and it reads open purchase order lines in Dynamics GP past their required date. It checks receipts for each order so only quantities still outstanding remain, and notes lines that were received but never updated. Each vendor's average lead time shows whether the required date was realistic. You get one block per vendor, worst first by outstanding value, with a suggested follow-up. Nothing is changed.
Business outcome
---
Buyers chase each vendor once with the full list of what is late, and stale statuses are spotted along the way.
scenario
-
Opening a field service call in Dynamics GP means finding the customer's equipment, checking whether a contract covers it, picking the right service type and a technician who is not already overloaded. Skip a check and you log a second call for the same fault or bill work the contract should cover.
What popdock provides
--
Give the customer and the problem, and the serial number if you know it, and it finds the customer and their equipment in Dynamics GP, asking which unit when there are several. It shows any open call that already covers the unit and asks before continuing, finds the contract covering it, and picks a service type and the least loaded active technician unless the type names a default. You confirm every field, the call is created once, and the stored call is read back.
Business outcome
---
Service calls are logged once, against the right contract and technician, so field work starts without a mix-up.
scenario
-
Setting up a new customer in Dynamics GP starts with a search, because the business may already exist as a customer or a prospect under a slightly different name. Then come the customer card, a ship-to address and an email, and an ID that follows your house style.
What popdock provides
--
Give the customer's name and details, and it searches Dynamics GP for existing customers by name, city or phone, and for a matching prospect, stopping when one looks like the same business. It validates any salesperson and proposes an unused ID in the style of your existing ones. You see every field before anything is written. The customer, any ship-to address and the email are created in order, each only if the step before worked, and the record is read back. Credit limits and holds are not set.
Business outcome
---
New customers are set up once, with addresses and email in place, and no duplicates to merge later.
scenario
-
Adding a vendor to Dynamics GP without checking first is how you end up paying the same supplier under two IDs. A proper setup also needs a remit-to address and an email, and an ID that fits your existing scheme.
What popdock provides
--
Give the vendor's name and details, and it searches Dynamics GP for a likely match by name and city, including inactive vendors, since reactivating beats duplicating. It proposes an unused ID in your house style and shows every field before anything is written. Once you confirm, the vendor, any separate remit-to address and the email are created in turn, each only if the previous step worked, and the stored vendor is read back. Bank and tax details are kept out of the conversation.
Business outcome
---
Vendors are created once, with remit-to details ready, so payments go to a single clean record.
scenario
-
Putting a customer on credit hold in Dynamics GP is a judgement call that needs evidence: how much is overdue, how old it is, and how far over the limit they are. Without a recorded reason, the hold is questioned later and nobody remembers why it was placed.
What popdock provides
--
Name the customer, and optionally a reason, and it reads their record and open transactions in Dynamics GP, aging what is overdue and comparing the balance with the credit limit. It lists unposted orders the hold will affect and says plainly if the evidence does not support a hold. You see everything and the note text before confirming. Only the hold flag is set, a dated note records why, and the stored hold is read back. Limits, terms and orders are left untouched.
Business outcome
---
Credit holds are placed on evidence and documented, so sales and finance see why an account is stopped.
scenario
-
Planning a vendor payment run in Dynamics GP means pulling everything overdue or due soon, netting vendor credits, leaving out vendors on hold and checking there is enough cash in the bank. Done in a spreadsheet, credits get missed and the run is built on a stale balance.
What popdock provides
--
Set a due window, and optionally a checkbook, and it reads open payables in Dynamics GP, putting invoices due in the window into the run and netting each vendor's credit memos and returns. Vendors on hold or inactive are set aside with what they are owed. It compares the total with active checkbook balances, warns when a checkbook has not been reconciled in 45 days, and suggests what to defer if cash is short. It is presented as a proposal for approval, it never mixes currencies, and nothing is paid or changed.
Business outcome
---
You get an approvable payment run that fits the cash you have, with credits netted and held vendors excluded.
scenario
-
Answering a question about one item in Dynamics GP can take a dozen screens: setup and cost, stock at each site, prices, vendors, open purchase orders, recent sales and adjustments. By the time you have it all, the person who asked has moved on.
What popdock provides
--
Name the item and a lookback window, and it finds the item in Dynamics GP and reads its setup, stock by site with the last count date, prices by level, vendors with lead times and last costs, and open purchase order lines. It adds sales in the window with the top five customers and average price against cost, plus adjustments, transfers and variances. The one-page profile ends with up to three observations such as thin margin or single-source supply. It only reads.
Business outcome
---
Everything about an item is on one page, so stock, pricing and supply questions get answered in one go.
scenario
-
Receiving a purchase order in Dynamics GP means working out what is still outstanding after earlier partial receipts, then keying each line at the PO cost. Receiving more than was ordered, or an item that was never on the PO, causes cost and matching problems later.
What popdock provides
--
Give the PO number and what arrived, or leave it to receive everything outstanding, and it checks the order in Dynamics GP is open and not on hold. It works out what is still outstanding per item from earlier receipts, rejects items not on the order, and refuses quantities above the outstanding amount unless you approve an over-receipt. You confirm the receipt, batch and lines before the receipt and its lines are created at PO cost. The stored lines are read back, and the purchase order itself is not changed.
Business outcome
---
Receipts match the purchase order exactly, so stock, cost and invoice matching stay correct.
scenario
-
Bank fees, interest and other one-off checkbook entries in Dynamics GP get keyed in a hurry and sometimes twice. Choosing whether it is money in or out, and the right transaction type, is easy to get backwards, which throws off the bank reconciliation.
What popdock provides
--
Give the amount, checkbook and description, and it checks the checkbook exists and is active in Dynamics GP, then warns about any transaction with the same amount and a similar description in the last 45 days. It works out whether the item is money in or out and picks the matching type, asking when unsure. You see the full transaction and the balance before and after, and nothing is written without your yes. It is recorded once and read back.
Business outcome
---
Checkbook entries are recorded once and the right way round, keeping bank reconciliations clean.
scenario
-
Correcting stock in Dynamics GP after a count or damage means checking the item and site, making sure the change will not push stock below zero or below what is allocated, and costing it correctly. Lot and serial items need extra detail that a quick adjustment cannot capture.
What popdock provides
--
Give the item, site, quantity change and reason, and it checks the item and an active site in Dynamics GP, stopping for lot or serial tracked items it cannot handle. For a decrease it refuses if on hand would fall below zero or below allocated stock. You see on hand before and after, unit cost and value, and confirm before the adjustment document and its line are created. It warns if an empty document is left, does not post to the ledger unless you ask, and reads the result back.
Business outcome
---
Stock corrections are recorded with a reason and the right value, without driving inventory negative.
scenario
-
Taking a customer off credit hold in Dynamics GP needs a quick look at what they have paid and what is still overdue, and a note saying why. Lift it on a promise alone and the account can slide straight back into arrears with no record of the decision.
What popdock provides
--
Name the customer, and optionally a reason, and it checks they really are on hold in Dynamics GP. It shows overdue amounts by age, payments received in the last 60 days and the balance against the credit limit, and says plainly if a large amount is still over 60 days overdue. You confirm the change and the note text. Only the hold flag is cleared, a dated note records the reason, and the stored value is read back. The credit limit is left alone.
Business outcome
---
Holds are lifted on a clear view of recent payments, with the decision recorded for the next person.
scenario
-
Sending faulty goods back to a vendor in Dynamics GP means working out which returned items that vendor actually supplied, finding the return address and the right RTV codes, and keying each line at cost. Items from the wrong vendor get sent back, or the paperwork never matches the customer RMA.
What popdock provides
--
Name the vendor, and optionally the customer RMA the goods came from, and it finds the vendor and return address in Dynamics GP. With an RMA it keeps only items this vendor supplies, otherwise it asks what is going back, using the last receipt cost as part cost. It reuses the RTV codes already in use, and you confirm every line before the return and its lines are created. If a line fails it says which exist, and the stored lines are read back.
Business outcome
---
Vendor returns go out against the right supplier and RMA, ready to recover the cost.
scenario
-
Before a customer meeting, getting the full picture from Dynamics GP means opening receivables, payments, sales documents, projects, service calls and contracts one by one. It is easy to walk in without knowing about an overdue balance, a late order or an open service call.
What popdock provides
--
Name the customer and a lookback window, and it finds them in Dynamics GP and reads their credit standing, open and overdue balance, recent payments with average days to pay, and sales by quote, order, invoice and return. It adds unposted documents and late orders, projects with cost against forecast, service calls and active contracts. The review ends with three points worth raising with the customer, flags an inactive account at the top, and treats a zero credit limit as no limit set. Nothing is changed.
Business outcome
---
Account managers walk into every customer conversation knowing the balance, orders, projects and service history.
scenario
-
Spotting items that are about to run out in Dynamics GP means weighing on-hand, allocated, on-order and back-ordered stock against how fast each item sells and how long the vendor takes. Without that maths, buyers either over-order or find out when a customer order cannot ship.
What popdock provides
--
Name an item class or item, and a demand window, and it reads the company-wide stock position in Dynamics GP and turns recent invoiced and ordered sales into daily demand. For items with less cover than twice their lead time it reads vendor terms and open purchase order lines, then suggests a quantity rounded to order minimums with an estimated cost. Back-ordered items with no known vendor are listed separately. It is presented as a suggestion list for a buyer, and nothing is ordered.
Business outcome
---
Buyers see what will run short and how much to order from each vendor before stock-outs hit customers.
scenario
-
Scrap in Dynamics GP manufacturing is recorded on work in process, but nobody adds it up by item and order. Without totals and rates, the orders losing the most material go unnoticed until margins slip.
What popdock provides
--
Give a date range, and optionally an item, and it reads work in process from Dynamics GP and works out scrap rate and scrap value by item and manufacturing order. For the ten orders with the highest scrap value it reads the order's description, status and dates. You get the headline scrap value and rate, the worst orders and items scrapping more than 5 percent. Because scrap reasons are not recorded, it does not invent causes, and nothing is changed.
Business outcome
---
Production sees where scrap costs the most, by item and order, so improvement starts in the right place.
scenario
-
Project contracts in Dynamics GP can quietly fall behind on billing while costs keep climbing. Seeing which contracts are under-billed, over budget or waiting on change orders means comparing contract value, billings, cost and pending invoices one contract at a time.
What popdock provides
--
Choose a customer or contract, or review all open contracts, and it reads each contract's value, billings and cost from Dynamics GP. It lists change orders not yet approved and project invoices not yet posted, then works out percent billed and percent spent. Contracts are flagged when cost runs more than ten points ahead of billing, billings exceed the contract amount or cost exceeds it, each with a one-line explanation. Nothing is changed.
Business outcome
---
Project managers catch under-billing and cost overruns on contracts while there is still time to bill or recover.
scenario
-
A project's real cost in Dynamics GP is split across timesheets, expenses, equipment logs and miscellaneous logs, each with its own billing status. Seeing how spend compares with forecast, and what has been incurred but never billed, means adding up four sources by hand.
What popdock provides
--
Name the project and a date range, and it finds the project in Dynamics GP and reads labor, expense, equipment and miscellaneous cost lines. Cost is totalled by source, cost category and billing status, alongside forecast, billings, percent spent and margin. It lists change orders, the oldest unbilled lines and categories with cost but no billing. When the lines do not add up to the project total it says so rather than forcing them to agree. Nothing is changed.
Business outcome
---
You see where project money went and which costs still need billing, without assembling four reports.
scenario
-
Building a collections list from Dynamics GP means aging every open document, netting out credits that could be applied, and then checking each customer's limit, hold status and how quickly they usually pay. Without that, collectors chase small balances while the largest, oldest debts wait.
What popdock provides
--
Set how many days overdue counts, and optionally a customer, and it reads open receivables in Dynamics GP using the unpaid remainder, not the original amount, and skips voided documents. Overdue amounts are aged into four buckets per customer, unapplied credits are shown separately, and customers are ranked by total overdue. For the top 15 it adds contact details, credit limit, hold status and average days to pay over six months. It ends with the five largest overdue documents and a suggested next step per top customer. It only reads.
Business outcome
---
Collectors start each day with a ranked worklist and the contact details to act on it.
scenario
-
Comparing salespeople in Dynamics GP takes more than an invoiced total. You need returns, open orders, commissions and whether their customers actually pay, and that means pulling sales documents, territories and each customer's balance separately.
What popdock provides
--
Pick a date range, and optionally one salesperson, and it reads active salespeople, their territories and commissions from Dynamics GP. Sales documents in the period give invoiced amounts, returns, return rate and customers sold to, and each salesperson's customers give total balances, holds and the overdue amount among the five largest. You get one table per salesperson and two lines each on strengths and concerns. Return rates and overdue balances are presented as facts to discuss, not judgements, and nothing is changed.
Business outcome
---
Sales managers get a balanced view of each rep, covering sales, returns and collectability, ready for a one-to-one.
scenario
-
Every week someone has to find out who in Dynamics GP has not submitted project time, which timesheets are still unposted and whose hours look wrong. Doing it by hand means comparing this week with previous ones employee by employee, and unbilled billable hours slip past.
What popdock provides
--
Give the timesheet period, or use last week, and it reads timesheets in Dynamics GP for that period and the four before it. Employees who submitted earlier but not now are listed as missing with their last period, and unposted timesheets are shown with status and hours. Lines in the period give hours per employee and project, with flags for over 60 hours or under half the usual amount, and unbilled billable time by project. It only reads.
Business outcome
---
Missing and unposted timesheets are chased the same week, so project costs and billing stay current.
scenario
-
Answering what you buy from a vendor and how well you pay them means opening several Dynamics GP windows: distributions for spend by account, payment applications for timing, open invoices, purchase orders and unposted receipts. Adding distributions the wrong way also double counts spend.
What popdock provides
--
Name the vendor and a date range, and it reads the vendor's balance, status and terms from Dynamics GP. Spend is summed by GL account using purchase distributions only, so offsetting entries do not double count. Payments are compared with due dates to count early, on time and late, with discounts taken. Open invoices, credits, open purchase orders and unposted receipts follow, with a note when the open items and the vendor balance disagree. Nothing is changed.
Business outcome
---
You see the full relationship with a vendor on one page before a negotiation, dispute or review.
scenario
-
Service contracts in Dynamics GP expire quietly unless someone checks end dates, and renewal conversations go better when you know what each contract covers and how much service the customer actually used. Pulling that together for every renewal is slow.
What popdock provides
--
Set a window, and optionally a customer, and it reads service contracts in Dynamics GP ending within it, plus any that have passed their end date but still look active. For each it reads the covered lines and billed amounts, and compares the customer's service calls over the last year with the contract total. Each contract gets a renewal note of renew, reprice or review, and reprice is explained as service value exceeding the contract total. Nothing is changed.
Business outcome
---
Account managers renew contracts on time and at a price that reflects the service customers really use.
scenario
-
When manufacturing orders in Dynamics GP run late, the first question is which customers are waiting, and the second is whether an outsourced step is the holdup. Answering both means tracing each order to its linked sales orders and checking outsourcing shipments one at a time.
What popdock provides
--
Optionally pick a site, and it reads manufacturing orders in Dynamics GP past their due date and not finished. Each is traced to linked sales orders for the customer and requested ship date, and orders with no link are marked build to stock. It checks outsourced steps not yet shipped and shipments still at the vendor. Customer-facing orders are listed first with days late and the likely holdup. When no outsourcing record explains a delay it says so rather than guessing, and nothing is changed.
Business outcome
---
Planners know which customers are affected by late production and where to push first.
scenario
-
Stock that has not sold in months ties up cash in Dynamics GP, but it rarely shows up on any report. Finding it means comparing on-hand quantities with recent sales item by item, and noticing which of those items you are still buying.
What popdock provides
--
Choose an item class and a no-sales window, and it reads items with stock on hand in Dynamics GP and values them at current cost. Any item invoiced in the window is dropped. For the 25 highest value items left it finds the last movement of any kind, and shows quantities on order and allocated. You get the total value tied up, a ranked table, and items still on order called out as the first to stop buying. It only reads.
Business outcome
---
You see how much cash sits in stock that is not selling and which purchases to stop first.
scenario
-
The fixed asset register in Dynamics GP drifts over time: assets fully depreciated but still in use, assets missing from a book, cost bases that no longer match acquisition cost. Reviewing it before an audit or insurance renewal means scanning every asset and book row.
What popdock provides
--
Choose an asset class and book, or let it pick the corporate book and say which it chose, and it reads assets and book values from Dynamics GP. You get net book value, cost basis and depreciation by class, assets fully depreciated but still active, active assets with no book row or no in-service date, and cost bases more than 1 percent off acquisition cost. Purchases from the last 90 days are listed too. Fully depreciated assets are presented as a review list, not errors, and nothing is changed.
Business outcome
---
Your asset register is reviewed before audit or renewal, with the exceptions that need a decision listed.
scenario
-
Unreconciled bank items in Dynamics GP build up quietly: old checks never cashed, deposits that were entered twice, checkbooks nobody has reconciled for weeks. Finding them means paging through every checkbook's transactions and comparing amounts by hand.
What popdock provides
--
Choose a checkbook, or all active ones, and an age threshold, and it reads each checkbook's balance and last reconciliation date in Dynamics GP, flagging any not reconciled in 45 days. Unreconciled, unvoided transactions older than the threshold are grouped by type, with checks over 90 days called out as stale. Pairs with the same amount and payee within seven days are listed as possible duplicates. It recommends reviewing rather than voiding any check, and nothing is changed.
Business outcome
---
Bank reconciliations stay current, with stale items and possible duplicates found before they distort cash.
scenario
-
Setting up a project in Dynamics GP means checking it does not already exist, finding the right contract for the customer or creating one, and filling in project type, accounting method and manager. Create it under the wrong contract and costs and billing land in the wrong place.
What popdock provides
--
Give the project name, customer and optionally a contract, and it finds the customer in Dynamics GP, warning if they are on hold, and stops if a matching project already exists. It uses the named contract if it is open, otherwise lists the customer's open contracts and asks which to use or whether to create one. You confirm every field before anything is written. A new contract is created only if you agreed, then the project, and the stored project is read back. Budgets and fees are not added.
Business outcome
---
Projects start under the right customer and contract, with no duplicates and nothing created you did not approve.
scenario
-
Preparing a sales tax return from Dynamics GP means totalling taxable amounts and tax by tax detail for sales and purchases, then hunting for lines that do not look right. Zero tax on taxable sales or a tax line posted outside the period can easily slip into the filing.
What popdock provides
--
Give a date range and it reads tax lines from Dynamics GP, leaving voided rows out. Lines are grouped into sales and purchases by tax detail, with document count, taxable amount, tax and the effective rate, then net tax. It flags tax with no taxable amount or the reverse, rates more than half a point off the usual, lines posted outside the period they are dated in, and tax posted to more than one account. It is labelled a working summary, not a filed return, and nothing is changed.
Business outcome
---
Tax returns are prepared from a checked summary, with odd lines found before you file.
scenario
-
Moving stock between sites in Dynamics GP means confirming the item is really available at the source after allocations, keying the transfer document and its line, and making sure nothing is left half done. A transfer from a site that does not have the stock causes problems in both places.
What popdock provides
--
Give the item, quantity and the two sites, and it asks for the batch and document number first. It checks both sites exist, are active and are different, then works out available stock at the source and stops on a shortfall, asking you to confirm when it cannot identify the site row with confidence. You see availability before and after and confirm before the transfer and its line are created. An empty transfer is reported plainly, nothing posts to the ledger unless asked, and the result is read back.
Business outcome
---
Stock moves between sites only when it is really there, with every transfer confirmed and checked.
scenario
-
Dispatchers in Dynamics GP need to know which open service calls to send next, which have no technician, and who is already overloaded. Status codes differ between setups and work orders sit apart from calls, so building that picture by hand is slow.
What popdock provides
--
Optionally pick an office or technician, and it learns your service status codes from Dynamics GP, then reads every open call and its age. Technicians are named and their open calls counted, and calls with no technician or an inactive one are flagged. Open work orders are linked to their calls. You get the next ten calls to dispatch by priority and age, a workload table and work orders older than 14 days. It says which priority direction it treated as most urgent, and nothing is changed.
Business outcome
---
Dispatchers send the right technician to the right call next, and unassigned calls stop slipping through.
scenario
-
A price increase across an item class in Dynamics GP means updating every price list row by hand, at every unit and quantity break. It is slow, easy to apply twice, and easy to push a price below cost without noticing.
What popdock provides
--
Give a percentage change and an item class or price level, and it refuses to touch every price in the company at once. It reads the price rows from Dynamics GP, skips percent based rows and says so, and calculates new prices rounded to two decimals, flagging any below current cost. Over 100 rows it asks you to narrow the scope. You approve the full before and after table, each row is updated once, and the prices are re-read to catch any that differ. Costs and list prices are left alone.
Business outcome
---
Price changes roll out across a class exactly as approved, with prices below cost caught first.
scenario
-
During a move from Dynamics GP to Sage Intacct, a vendor invoice can turn up after cutover that was already entered or even paid in the old system. Checking means searching GP payables and payments, then Intacct bills, by invoice number or amount, and invoice numbers rarely match exactly.
What popdock provides
--
Give the vendor and the invoice number or amount, and it searches Dynamics GP payables, including voided documents, and the payments applied to each match. It then searches Sage Intacct bills and payments, finding the vendor by name if the ID differs, and compares invoice numbers ignoring case, spaces, dashes and leading zeros. You get one verdict first, from safe to paid in GP or in both, followed by the evidence. Near matches are shown as possible matches but never decide the verdict, and nothing is changed in either system.
Business outcome
---
No invoice gets paid twice across the cutover, and each verdict comes with the payment evidence behind it.
scenario
-
After moving from Dynamics GP to Sage Intacct, GP main accounts that never made it into the new chart cause failed imports and postings. Creating them by hand means working out each account's type, normal balance and closing behavior from GP, one account at a time.
What popdock provides
--
Optionally choose a main segment, and it compares active Dynamics GP main accounts with the Sage Intacct chart, leaving out any that look already mapped under a similar title. For each gap it proposes the number, title, account type, normal balance and closing treatment, asks once for the retained earnings account, and flags segments whose GP descriptions differ. You confirm, edit or drop rows, up to 50 at a time. Only confirmed accounts are created, it stops on the first failure, and each new account is read back. Dynamics GP is never written to.
Business outcome
---
Your Sage Intacct chart gains the missing GP accounts with the right type and balance, each approved by you.
scenario
-
Mapping a segmented Dynamics GP chart of accounts to Sage Intacct is slow and error prone. GP accounts have to be rolled up by main segment, matched despite leading zeros, and checked for type and normal balance, while segments hiding several meanings need a decision about dimensions.
What popdock provides
--
Optionally pick a main segment, and it reads active Dynamics GP accounts grouped by main segment and the Sage Intacct chart. Segments are matched exactly, then without leading zeros, and close title matches are listed as suggestions that never count as matches. Each pair is checked for account type, normal balance and an inactive Intacct account. You get counts, mismatches, GP-only and Intacct-only accounts, and segments that may need a dimension or separate accounts. It only reads.
Business outcome
---
You know exactly how the GP chart maps to Sage Intacct, and which accounts still need a decision, before go-live.
scenario
-
Moving customers from Dynamics GP to Sage Intacct leaves gaps: some never came across, some came across under a new ID, and hold status or credit limits are lost on the way. Creating the missing ones by hand risks duplicates and wrong payment terms.
What popdock provides
--
Optionally pick a GP customer class, and it reads active Dynamics GP customers and checks each in Sage Intacct by ID, then by name. A name match under a different ID is listed as possibly migrated and never created. For the rest it proposes name, address, email, phone and a payment term you confirm the mapping for, showing credit limits as not carried. You confirm up to 25 at a time, customers on hold in GP are put on hold in Intacct, and each one is read back. Dynamics GP is never written to.
Business outcome
---
Missing customers reach Sage Intacct once, with hold status kept and credit limits listed for you to set.
scenario
-
After a Dynamics GP to Sage Intacct cutover, vendors that did not migrate block bill entry and payments. Adding them by hand risks creating a second record for a vendor that came across under a new ID, and payment terms that Intacct rejects.
What popdock provides
--
Optionally pick a GP vendor class, and it reads active Dynamics GP vendors and checks each in Sage Intacct by ID, then by name, never creating one that may have migrated under another ID. It proposes name, email, phone and a payment term only once you confirm the mapping, and lists GP addresses as not carried so you can enter them. You confirm up to 25 at a time, vendors on hold in GP are put on hold in Intacct, and each one is read back. Dynamics GP is never written to.
Business outcome
---
Every active GP vendor exists once in Sage Intacct, so bills and payments can carry on after cutover.
scenario
-
When one account in Sage Intacct does not tie to its Dynamics GP balance at cutover, someone has to work out the GP balance from period summaries, net the Intacct ledger to the same date and key a correcting entry against a clearing account. Get the sign or the period wrong and the difference doubles.
What popdock provides
--
Name the account, the cutover date and a clearing account, and it asks for the GP fiscal year and last period, then works out the Dynamics GP balance and the Sage Intacct balance at cutover. If they tie it stops. Otherwise it proposes one journal entry for the difference, saved as a draft unless you ask to post, and warns when the gap is over 10 percent, suggesting a full trial balance check first. Nothing is written until you confirm, it refuses if both accounts are the same, and it checks the account ties afterwards.
Business outcome
---
Cutover differences are corrected with one confirmed entry, and you see the account tie afterwards.
scenario
-
Proving inventory came across from Dynamics GP to Sage Intacct correctly means pairing GP sites with Intacct warehouses, then comparing quantity and value item by item. Live activity on either side since cutover muddies the comparison further.
What popdock provides
--
Optionally pick a site or item, and it pairs Dynamics GP sites with Sage Intacct warehouses, then reads GP quantities and costs by site and Intacct on-hand and costs by warehouse. Items are matched by number and compared on quantity and on value using the matching cost method. You get items missing from Intacct, quantity differences by value, cost differences over 1 percent, and totals per site. Non-inventory items are skipped and counted, and it warns that differences may reflect activity since cutover. It only reads.
Business outcome
---
Inventory is proven to match after the move, or the exact items and sites that differ are listed.
scenario
-
Confirming that every open payable in Dynamics GP came across to Sage Intacct is hard when GP stayed in use after cutover and payments have reduced what is open. Vendor IDs and invoice numbers also drift, so a simple total comparison hides missing bills.
What popdock provides
--
Give the cutover date, and optionally a vendor, and it works out what was open in Dynamics GP at cutover, adding back payments applied since. It reads open Sage Intacct bills and credit adjustments, matches vendors by ID, then by name, and matches documents by bill or reference number. You get vendors that do not tie, GP documents missing from Intacct, Intacct bills with no GP source, amount or due date mismatches and grand totals. Missing bills are listed for import, never created.
Business outcome
---
Accounts payable opens in Sage Intacct with every cutover bill accounted for, or a clear list to import.
scenario
-
After moving to Sage Intacct, finance has to prove every customer balance open in Dynamics GP at cutover arrived as an open invoice. Payments applied in GP after cutover, changed due dates and drifting customer IDs make that much harder than comparing totals.
What popdock provides
--
Give the cutover date, and optionally a customer, and it works out each customer's open Dynamics GP receivables at cutover, adding back amounts applied since. It reads open Sage Intacct invoices and credit adjustments, matches customers by ID, then by name, and matches documents by invoice or reference number. You get customers that do not tie, documents missing on either side, amount and due date mismatches and grand totals. Unapplied GP payments still count as open items, and missing invoices are listed for import. It only reads.
Business outcome
---
Receivables balances are proven complete after cutover, so aging and dunning in Sage Intacct start from the right numbers.
scenario
-
Signing off a move from Dynamics GP to Sage Intacct needs proof that every account balance matches at cutover. That means adding GP period balances differently for balance sheet and profit and loss accounts, rolling segments up to main accounts and netting the Intacct ledger to the same date.
What popdock provides
--
Give the GP fiscal year and period and the cutover date, and it builds Dynamics GP balances from beginning balance or year to date as each account requires, rolled up by main segment. It nets Sage Intacct ledger detail for each account to the same date and first checks each side nets to zero. You get totals, every difference largest first, and accounts on one side only, with a note when the differences look like an offset in one clearing account. It never compares full segmented numbers directly, and nothing is posted.
Business outcome
---
You can sign off the cutover with an account by account proof that the opening position matches.
scenario
-
After a cutover, a customer's history is split: older sales and receivables live in Dynamics GP and newer invoices and payments in Sage Intacct. Seeing the whole picture means two lookups and care not to count migrated invoices twice, and differences in terms or credit limit go unnoticed.
What popdock provides
--
Give the customer ID and how many months to look back, and it finds the customer in Dynamics GP and Sage Intacct and lists any differences in terms, credit limit, status, email or city. It reads GP receivables and sales documents and Intacct invoices, payments and orders, splitting the timeline at cutover and showing migrated invoices once. You get monthly totals tagged by system, the open balance, any GP document that did not migrate, the last ten documents and a one-line read on buying and paying. It only reads.
Business outcome
---
You see one customer's full history across both systems, with settings that did not carry across called out.
scenario
-
Keeping a Mailchimp audience in step with your Dynamics GP customers means exporting emails, comparing them with the audience, and importing the gaps. Do it carelessly and you resubscribe people who opted out, or add customers without consent.
What popdock provides
--
Name the Mailchimp audience, and optionally a GP customer class, and it reads active Dynamics GP customers with an email and every audience member, whatever their status. Only customers not in the audience at all are proposed, so anyone who unsubscribed or was cleaned is never re-added. New members are added as pending, which sends a double opt-in email, unless you state you have consent. You confirm the list or drop rows first, it stops at the first error, and each row is reported as added or failed.
Business outcome
---
Your audience covers current customers without resubscribing anyone who opted out or skipping consent.
scenario
-
Before calling a customer, you might want both sides: what they owe and order in Dynamics GP, and whether they read your Mailchimp campaigns or buy in the store. That means two systems, an email to carry across, and a lot of clicking.
What popdock provides
--
Give a Dynamics GP customer ID, name or email, and it finds the customer in GP and reads open and past-due receivables and recent sales documents. Using the customer's email it reads their Mailchimp audience status and tags, store orders, and recent opens and clicks. The profile ends with anything worth acting on, such as a customer on hold who is still clicking campaigns. If the customer has no email it says Mailchimp could not be checked, and nothing is changed in either system.
Business outcome
---
Sales and finance see a customer's account and marketing engagement together before the next conversation.
scenario
-
Marketing wants to know whether a Mailchimp campaign led to sales, but orders live in Dynamics GP. Matching recipients to customers by email and checking each one's orders in the weeks after the send is too slow to do for every campaign.
What popdock provides
--
Name a sent Mailchimp campaign and a window in days, and it reads the recipients and who clicked. Recipients are matched to Dynamics GP customers by email, and each match's orders and invoices in the window after the send are read, ignoring quotes. You get a summary of matched customers, clickers and sales value, a table per buying customer, and clickers who have not bought with their salesperson. It states that a sale after a send is correlation, not proof, and nothing is changed.
Business outcome
---
Marketing sees which campaigns are followed by real orders, and sales gets a list of interested clickers to call.
scenario
-
When a customer unsubscribes or hard-bounces in Mailchimp, sales and receivables in Dynamics GP never hear about it. They keep emailing an address that bounces, or contact someone who asked not to be, because the customer record says nothing.
What popdock provides
--
Set a lookback window, and it reads recent Mailchimp unsubscribes with their reason and campaign, plus hard bounces, and matches them to Dynamics GP customers by email. You see each proposed note, one per customer even when there are several events, and confirm or drop rows. Notes are appended with the date and time, never replacing an existing note, and each row is reported as noted or failed. It mentions that hard bounces are not limited to the window, and it never resubscribes anyone.
Business outcome
---
Your GP customer records show who opted out or bounced, so teams stop contacting them the wrong way.
scenario
-
Your Dynamics GP customer list and Mailchimp audience drift apart: new customers never get added, some have unsubscribed, and some have no email at all. Spotting the gaps means exporting both, cleaning emails and comparing them in a spreadsheet.
What popdock provides
--
Name the Mailchimp audience, and optionally a GP customer class or salesperson, and it reads active Dynamics GP customers and every audience member. Matching is on email only, never on name, and GP email fields holding several addresses are split. You get customers missing from the audience, customers in it but not subscribed with their status and reason, customers with no email, and a count of members who match no customer. It warns when the customer read may be truncated, and nothing is changed.
Business outcome
---
You know exactly where your customer list and audience disagree before planning the next campaign.
scenario
-
A Mailchimp campaign creates interest, but the clicks never reach the salespeople who own those customers in Dynamics GP. Turning a click report into a follow-up list means matching emails to customers, finding each salesperson and checking whether the account is on hold.
What popdock provides
--
Name the Mailchimp campaign, and optionally a salesperson, and it reads everyone who clicked, with click counts, dates and links. Clickers are matched by email to active Dynamics GP customers, and each customer's salesperson is looked up. You get one section per salesperson with contact details, links clicked, balance and a flag for credit hold, an unassigned section where needed, and clickers who are not customers yet as possible prospects. It sends no email and changes nothing.
Business outcome
---
Every engaged customer reaches the right salesperson for follow-up, with prospects listed alongside.
scenario
-
Customers on credit hold in Dynamics GP still receive Mailchimp promotions encouraging them to order. Keeping a segment of held accounts up to date by hand means exporting holds, matching emails and adding members one by one.
What popdock provides
--
Name the Mailchimp audience and a static segment or tag, and it checks both exist and that members can be added. It reads active Dynamics GP customers on hold and matches them by email to audience members, skipping those already in the segment. You see the proposed additions with balances, and held customers not in the audience separately, and confirm or drop rows. Only existing members are added to the segment, each row is reported, and holds in GP are never changed.
Business outcome
---
Campaigns can exclude or target held accounts, so customers on hold are not urged to place new orders.
scenario
-
Prices and costs in Shopify drift away from the item records in Dynamics GP as one side is updated and the other is not. Finding the differences means comparing every variant's price and cost against the GP list price and current cost by hand.
What popdock provides
--
Optionally filter by product title or vendor and set a tolerance, and it reads Shopify variants with their price and unit cost. Each SKU is looked up as the Dynamics GP item number for current cost and list price, saying which price level it used. You get variants that differ beyond the tolerance, largest first, with the margin at the Shopify price, plus variants with no SKU and SKUs not found in GP. Missing prices are shown as missing, currency differences are flagged, and nothing is changed.
Business outcome
---
Store prices and costs stay in line with your ERP, so you do not sell online at the wrong margin.
scenario
-
Shopify orders that are fulfilled get tracking numbers in Shopify, but the matching sales document in Dynamics GP stays blank. Copying them across means finding the GP document by customer PO and keying each tracking number by hand.
What popdock provides
--
Give the Shopify order name, and it collects every distinct tracking number from the order's fulfillments. It finds the Dynamics GP sales document by customer PO number, preferring one that is not yet posted when there are several. You see the GP document and tracking numbers and confirm before anything is written. Each tracking number is added once, numbers over 40 characters are skipped rather than cut short, and any failures are reported. Shopify is not changed.
Business outcome
---
Tracking from Shopify appears on the GP sales document, so your team can answer shipping questions from one place.
scenario
-
Shopify B2B companies need to be tied to the right Dynamics GP customer so orders and credit can be checked. Doing it by hand means searching GP by name, creating the customer if it is missing, and pasting the ID into Shopify without overwriting an existing link.
What popdock provides
--
Name the Shopify B2B company, and optionally the GP customer ID, and it reads the company, its location and main contact, stopping if it is already linked unless you ask to replace it. It finds candidate Dynamics GP customers and shows them with city and balance. You confirm whether to link an existing customer or create one from the Shopify details before anything is written. The GP ID is then written to the Shopify company, both sides are read back, and if a step fails it says exactly what exists.
Business outcome
---
Each B2B company in Shopify is linked to one GP customer, ready for order posting and credit checks.
scenario
-
Refunds issued in Shopify should show up in Dynamics GP as credit memos or returns, but the two are rarely checked against each other. A missed refund overstates revenue and receivables, and finding it means matching order names across systems by hand.
What popdock provides
--
Set a lookback window, and it reads Shopify refunds and totals each one's lines and tax. It reads Dynamics GP credit memos and sales returns for the same period and matches them to refunds by order name in the customer PO field, summing when a refund is split across documents. You get refunds with no GP credit and the SKUs involved, amount mismatches, GP credits that matched no refund and a count of clean matches. It only reads.
Business outcome
---
Every Shopify refund is accounted for in Dynamics GP, so revenue and receivables stay accurate.
scenario
-
Rekeying a Shopify order into Dynamics GP means finding the right customer, checking every SKU exists as an item, applying discounts and freight, and making sure the order was not already entered. A duplicate or a missing line goes straight through to fulfilment and billing.
What popdock provides
--
Give the Shopify order name, batch and document type, and it reads the order, lines and shipping, stopping on a canceled order or one already in Dynamics GP. It finds the GP customer through the linked B2B company or by name and matching email, and confirms every SKU is a GP item, stopping rather than creating anything. You confirm the document with discounts folded into prices before the sales order and lines are created. The GP total is compared with Shopify, and a failed line is reported with the order number.
Business outcome
---
Shopify orders reach Dynamics GP once and complete, with totals checked against the store.
scenario
-
Every Shopify order should end up as a sales document in Dynamics GP, but checking means looking up each order's name in the customer PO field and comparing totals. Orders that never made it across go unbilled until a customer complains.
What popdock provides
--
Set a lookback window, and it reads Shopify orders, setting canceled ones aside. Each order is looked up in Dynamics GP by its name as the customer PO number, retrying without the hash and with the plain number, and preferring the invoice when there are several. You get orders missing from GP, total and tax mismatches, a count of clean matches and the canceled orders skipped. Differences under one cent count as a match, and nothing is changed.
Business outcome
---
No Shopify order goes unbilled, because missing and mismatched orders are found within days.
scenario
-
When Shopify shows stock that Dynamics GP does not have, you oversell, and when GP has stock Shopify hides, you lose sales. Comparing them means adding up Shopify locations and subtracting GP allocations for every SKU.
What popdock provides
--
Name a SKU, or check every tracked SKU, and set a tolerance. It totals Shopify available stock across locations, then reads Dynamics GP on hand and allocated for the same item number and works out GP available. You get SKUs that differ beyond the tolerance, largest first, SKUs missing from GP, and a count of Shopify rows with no SKU. SKUs that only matched in upper case are noted. It suggests adjustments but never makes them.
Business outcome
---
Online stock matches your warehouse, so you stop overselling or hiding items you actually have.
scenario
-
Shopify B2B buyers can keep placing orders while their Dynamics GP account is on hold, over its limit or overdue. Checking each company means finding its linked GP customer and reading balance, limit and open invoices one by one.
What popdock provides
--
Name a Shopify B2B company, or review them all, and it reads each company's linked Dynamics GP customer ID. For each it reads the GP balance, credit limit, hold and inactive flags and terms, and open invoices past their due date. You get available credit, overdue amount and Shopify spend per company, with flags for hold, inactive, over limit or overdue, plus companies that are unlinked or linked to a missing customer. A zero limit is treated as no limit, and nothing is changed.
Business outcome
---
Finance spots B2B buyers who are over limit or on hold before more online orders ship.
scenario
-
Customers who sign up and pay through Stripe often never get a customer record in Dynamics GP, so invoices and reporting fall behind. Creating them by hand means checking GP for each name, inventing an ID that fits, and remembering to add the email separately.
What popdock provides
--
Give a start date, and optionally a GP customer class, and it reads Stripe customers created since then and checks Dynamics GP by name and email. A matching email means the customer exists, and a name match with a different email is listed as a possible duplicate and never created. For the rest it proposes an unused GP ID and shows the details, and nothing is created until you confirm which rows to add. Each customer is created and then given its email address, and the report shows any row that failed.
Business outcome
---
New Stripe customers appear in Dynamics GP without duplicates, ready to invoice and report on.
scenario
-
A customer who is delinquent in Stripe or has opened a chargeback can still look fine in Dynamics GP, so collections and sales carry on as normal. Passing those signals across means checking Stripe, matching each person to a GP customer and writing a note by hand.
What popdock provides
--
Give a date, and it reads delinquent Stripe customers and disputes opened since then that are still undecided, with amount, reason and evidence due date. Each customer is matched to a Dynamics GP customer only when the email agrees, and uncertain ones are shown as unmatched. You see GP balance, hold status and the exact note text, and nothing is written until you confirm which rows to add. Notes are appended, never overwriting existing ones, and no customer is put on hold.
Business outcome
---
Collections and sales see Stripe payment risk on the GP customer record before they extend more credit.
scenario
-
Stripe pays out in lump sums after fees, so each bank deposit in Dynamics GP has to be matched to a payout by amount and date. When several payouts share an amount or a deposit was recorded a few days late, matching by hand gets confusing and some payouts are never recorded.
What popdock provides
--
Give a date range, and optionally a checkbook, and it reads paid Stripe payouts that arrived in the range. Each is looked for in Dynamics GP bank deposits by exact amount within three days, then in bank transactions, including by payout ID in the description. Each payout matches at most one GP record, ties are paired by nearest date, and amount-only matches outside the window are listed as possible. Currency differences are reported, unmatched payouts are listed for recording, and nothing is changed.
Business outcome
---
Every Stripe payout is tied to a GP deposit or listed for recording, keeping cash reconciliations complete.
scenario
-
Getting Stripe invoices into Dynamics GP receivables means exporting from Stripe, checking each number against GP so nothing goes in twice, and finding the right GP customer for every invoice. Pick the wrong customer or miss one already keyed and the receivables ledger is wrong until someone spots it.
What popdock provides
--
Give a date range and a GP batch, and it reads the finalized Stripe invoices for that period and skips any whose number Dynamics GP already holds. Each remaining invoice is matched to a GP customer by name and email, and anything with no single clear match is held back rather than guessed. You see a table of what will be posted and nothing is written until you confirm, then each confirmed invoice goes into the batch once. Invoices in another currency or with numbers too long for GP are reported, not posted.
Business outcome
---
Stripe billing reaches Dynamics GP receivables without duplicates or misassigned customers, ready for you to post the batch.
scenario
-
Keeping customer records in step between Dynamics GP and Stripe means searching Stripe for each GP customer, deciding whether a name match is really the same company, and comparing balances by hand. Customers missing from one side and balances that quietly drift apart go unnoticed for months.
What popdock provides
--
Name the GP company, and optionally a customer class, and it looks up each active Dynamics GP customer in Stripe by email first and by name only when there is no email match. Names that match several Stripe customers are listed as ambiguous instead of picked. For every match it totals the open Stripe invoices and sets that against the GP balance, noting differences of any size and which are under 1.00. Nothing is changed in either system.
Business outcome
---
You see which customers exist in only one system and whose balances disagree, with email matches kept separate from guesses.
scenario
-
Reconciling Stripe invoices with Dynamics GP receivables means hunting each invoice by number, then by PO number, then by customer and amount when the number was keyed differently. The ones that really matter, paid in Stripe but still open in GP, are buried among hundreds of rows that agree.
What popdock provides
--
Give a date range and it reads every finalized Stripe invoice in it, then looks for each one in Dynamics GP by invoice number, then customer PO number, then customer, date and exact amount. A fallback match counts only when exactly one GP document fits, and it is labelled as probable. Totals and outstanding balances are compared, currency mismatches and amounts out by a factor of 100 are called out separately, and invoices paid in one system but open in the other get their own group. Nothing in Dynamics GP or Stripe is changed.
Business outcome
---
Month-end receivables reconciliation shrinks to a short list of invoices someone actually needs to act on.
scenario
-
Every Stripe refund and lost dispute should have a credit memo or return in Dynamics GP, but they are recorded by different people at different times. Checking means tracing each refund back to its original invoice and then searching GP for the matching credit, and a missed one leaves receivables overstated.
What popdock provides
--
Give a date range and it reads the successful Stripe refunds and lost disputes in it, then follows each back through its charge to the original Stripe invoice number. It looks in Dynamics GP for credits and returns applied to that invoice, and falls back to customer, date and the refund amount when there is no invoice link, saying when it did. Partial refunds are compared to the refund amount, never the invoice total. Open disputes are counted but not chased, and nothing in GP is changed.
Business outcome
---
Refunds and lost disputes missing from Dynamics GP surface with their amounts, so receivables stay accurate at close.
scenario
-
When a customer calls about their account, the answer is split between Dynamics GP and Stripe. You check the GP balance, credit limit and hold status, then switch to Stripe for subscriptions, open invoices, failed charges and disputes, and it is easy to miss that GP has them on hold while Stripe keeps billing.
What popdock provides
--
Give a GP customer ID, an email or a name, and it finds the customer in Dynamics GP and in Stripe, stopping to list candidates if more than one matches on either side. It gathers the GP balance, credit limit and open documents alongside Stripe subscriptions, open invoices, failed charges from the last 90 days and disputes. The report ends with the points where the two systems disagree. If the customer exists in only one system it says so plainly. It reads from Dynamics GP and Stripe but writes nothing back.
Business outcome
---
You get one account picture across both systems before you talk to the customer, with conflicts spelled out.
scenario
-
Orders sit in processing in WooCommerce long after Dynamics GP has invoiced them, because someone has to check each one in GP and update the store by hand. Customers wait for a completed notice, and an order marked complete before its invoice is posted causes its own confusion.
What popdock provides
--
Give a start date and a maximum number of orders, and it reads the WooCommerce orders still in processing and looks for a posted Dynamics GP invoice carrying each order number as the customer PO. Only orders with a posted invoice qualify, totals that differ by a cent or more are set aside, and two posted invoices for one order are flagged as a possible duplicate. You confirm the list, warned that customers usually get a completed email, and then each order is completed with a private note naming the GP invoice. GP is never changed.
Business outcome
---
Store orders move to completed as soon as GP invoices them, with a note tying each one to its invoice.
scenario
-
Keying a web order into Dynamics GP means checking it is not already there, finding the right GP customer, matching every store SKU to a GP item and retyping prices and freight. One wrong item number or a second copy of the same order and fulfilment or billing goes wrong.
What popdock provides
--
Give a WooCommerce order number, a batch and a document ID, and it first checks Dynamics GP for an existing sales document with that order number and stops if one exists. It resolves the GP customer by email, matches each line SKU exactly to a GP item and stops if any line has no match. You see the full sales order, with a warning when discounts may already be in the prices, and nothing is created until you confirm. The order and lines are then read back and the GP total compared to the store. It never creates GP customers.
Business outcome
---
Web orders arrive in Dynamics GP once, with the right customer and items, and a total you can check.
scenario
-
Products get added to the WooCommerce store without a matching item in Dynamics GP, and store prices drift away from the GP list price. Checking means opening each product and variation, finding its SKU in GP and comparing prices one by one, which rarely happens until an order fails.
What popdock provides
--
Name a category, or leave it open, and it reads the store's products and their variations, then looks up each SKU in Dynamics GP by exact item number. For matched items it compares the store regular price with the GP list price for the item's selling unit of measure. You get store SKUs missing from GP, price differences sorted by size, and products with no SKU at all. Where GP holds several price rows and no currency was named, it lists them rather than flagging a difference. Nothing in Dynamics GP or WooCommerce is changed.
Business outcome
---
Catalog gaps and price drift between the store and Dynamics GP show up before they turn into failed or mispriced orders.
scenario
-
Every WooCommerce order should reach Dynamics GP as a sales document, but imports fail quietly and totals change after edits. Checking a week of orders means searching GP by PO number for each one and working out which of its quote, order or invoice to compare.
What popdock provides
--
Give a date range, and optionally an order status, and it reads the WooCommerce orders and looks for each in Dynamics GP by customer PO number, trying the order ID as well when it differs. When an order has several GP documents it compares the store total with the most advanced one, an invoice ahead of an order ahead of a quote. You get orders missing from GP, total differences, and GP documents whose customer name looks nothing like the buyer. Currency mismatches are reported without being called differences. It reads from Dynamics GP and WooCommerce but writes nothing back.
Business outcome
---
Orders that never made it into Dynamics GP, or arrived with the wrong total, are caught in one pass.
scenario
-
The store says an item is in stock while Dynamics GP has nothing available, or the reverse, and customers order goods you cannot ship. Comparing means reading each product and variation, finding the SKU in GP and subtracting allocated from on hand for the right site.
What popdock provides
--
Name a category and optionally a GP site, and it reads WooCommerce stock for each product and variation, then reads Dynamics GP quantities by exact SKU. Available quantity is on hand less allocated, for the chosen site or all sites combined, with negative figures treated as zero for comparison but shown as they are. You get differences sorted by size, items in stock online but not in GP, items available in GP but out of stock online, and SKUs not in GP or not stock managed. No record in Dynamics GP or WooCommerce is touched.
Business outcome
---
Overselling and hidden stock are spotted early, with each difference tied to a SKU and a GP site.
scenario
-
Before approving a large web order you need the customer's Dynamics GP standing, but GP cannot search by email. You guess at the company name, check the email on each candidate, then look at holds, credit limit and overdue invoices while the order waits.
What popdock provides
--
Give the customer's email, or their GP customer ID, and it reads their WooCommerce record or recent orders, including guest checkouts. It finds the GP customer by company or last name and accepts only a candidate whose email matches, listing the candidates and asking when none or several do. You see hold and inactive flags, balance against credit limit, overdue documents, address and phone differences, and recent store spend, with one line on anything that needs action. It is read-only in Dynamics GP and WooCommerce.
Business outcome
---
You know whether a web customer is on hold or overdue in Dynamics GP before you ship their next order.
scenario
-
When list prices change in Dynamics GP, someone has to update the same SKUs in WooCommerce, product by product and variation by variation. Mistakes are easy: the wrong unit of measure, a price that drops below a running sale price, or a zero price published by accident.
What popdock provides
--
Give a list of SKUs, and optionally a currency and unit of measure, and it finds each SKU in the store and reads its Dynamics GP list price. You see current and new regular prices side by side, SKUs already matching are left out, and any new price at or below the sale price is flagged. SKUs with several or no GP price rows, or a zero price, are skipped rather than guessed. Nothing changes until you confirm, and then only the regular price is written. Sale prices, stock and GP are never touched.
Business outcome
---
Store prices follow Dynamics GP list prices with every change reviewed first and no accidental zero prices.
scenario
-
Keeping WooCommerce stock levels in line with Dynamics GP means reading available quantities in GP, subtracting what is already allocated, and typing the result into each product and variation. It is slow, so it gets done weekly at best, and the store sells stock that is already allocated.
What popdock provides
--
Give a list of SKUs and optionally a GP site, and it reads each SKU's Dynamics GP available quantity, on hand less allocated, rounded down and never below zero. You see current and new store stock side by side, with SKUs that already match left out and missing SKUs listed separately. Nothing is written until you confirm, then only the stock quantity changes. If a product does not manage stock it says so rather than switching that on, and GP is never changed.
Business outcome
---
Online stock matches what Dynamics GP can actually ship, updated in minutes with every change approved.
scenario
-
When a customer asks where their order is, the answer runs from WooCommerce through Dynamics GP sales documents into receivables. Following it means matching lines by SKU, finding the invoice, and checking which payments were applied, across several screens.
What popdock provides
--
Give a WooCommerce order number and it reads the store order, its lines and any refunds, then finds the Dynamics GP sales documents by customer PO number. Lines are matched by SKU and compared on quantity and price, and any invoice is followed into receivables for the amount still owed and the payments applied. It flags invoices not yet in receivables, refunds with no matching GP credit, and duplicate documents. It closes with one sentence on where the order stands. Dynamics GP and WooCommerce stay exactly as they were.
Business outcome
---
You can tell a customer exactly where their order stands, from cart to cash, in one answer.
scenario
-
When a new vendor is set up in Ramp, someone has to retype it into Dynamics GP by hand. They search GP to see whether the vendor is already there, invent a vendor id, and key in the name and country. A missed search creates a duplicate vendor, and a typo in the name or id means bills and payments go to the wrong record.
What popdock provides
--
Give the Ramp vendor name, and optionally the Dynamics GP company and a vendor id. It reads the vendor from Ramp, then checks Dynamics GP for an existing vendor with the same name or id and stops if one is found. You see the exact vendor id, name, country and status it will send, and if you gave no id it proposes one and asks. Nothing is written until you say yes, then it creates the GP vendor with a single write and reads it back. It does not invent addresses or payment terms and never changes anything in Ramp.
Business outcome
---
New Ramp vendors reach Dynamics GP once, with the right name and id, and no duplicate vendor records to clean up later.
scenario
-
Ramp users code spend to GL accounts, and those accounts are meant to match the Dynamics GP chart of accounts. Over time accounts are added, renamed, made inactive or switched to non-posting in GP while Ramp still offers the old ones. Nobody notices until coded spend fails to post, often at month end, and the account formats differ between the two systems, so comparing by eye is slow.
What popdock provides
--
Optionally name a Dynamics GP company and an account type. It reads the GL accounts from Ramp and the chart of accounts from Dynamics GP, then matches them by account number and tells you if it had to normalise the codes, for example dashes between segments. The report lists active Ramp accounts with no GP account, matched accounts that are inactive, closed to entry or not posting accounts, names that differ materially, and active GP posting accounts missing from Ramp. It only reads, changes nothing in either system, and stops if either side returns no accounts.
Business outcome
---
Account mismatches are found and fixed before coded spend fails to post, without a manual comparison of two charts.
scenario
-
Purchase orders live in Ramp and again in Dynamics GP, and nobody confirms that the two agree. A PO can exist in one system only, carry a different amount, or show as fully received in Ramp while GP has no receipt. Checking means opening both systems, matching PO numbers whose formats differ, and comparing receipts line by line.
What popdock provides
--
Give a start date, and optionally a vendor and a Dynamics GP company. It reads the Ramp purchase orders created since that date, finds the matching Dynamics GP purchase orders by PO number and reads the GP receipts for the vendors involved. You get a table with each PO, the Ramp and GP amounts, the difference, the status on both sides and the number of receipts found. It flags POs missing on either side, differing amounts and receipt disagreements, and flags a currency mismatch instead of comparing. It only reads and never changes either system.
Business outcome
---
Purchase order and receipt differences between Ramp and Dynamics GP surface in one review, before they turn into payment disputes.
scenario
-
Once a bill is approved in Ramp, someone rekeys it into Dynamics GP payables. They look up the vendor id, check the invoice was not already entered, then copy the amount, dates and batch details across. A missed check gives a duplicate invoice, and a copied figure or currency that is wrong means the payable is wrongly valued in the live company database.
What popdock provides
--
Give the invoice number, and optionally the Dynamics GP company and batch number. It reads the bill from Ramp and stops unless it is approved, finds the vendor in GP and checks the invoice is not already there. It also stops on a missing vendor or a currency mismatch. You see the vendor id, document number, dates, amounts, batch and voucher number it will use, and nothing is written until you say yes. It then creates the payables invoice with a single write and reads it back. It never writes to Ramp.
Business outcome
---
Approved Ramp bills reach Dynamics GP payables once, with the right values, and no duplicate or mis-valued invoices to reverse.
scenario
-
Accounts payable checks Ramp bills against Dynamics GP payables invoices by hand. They list bills due in a period, search GP for each invoice number, and compare amounts. Missing invoices and wrong amounts are often found only at month end, when closing is already under pressure, and voided or non-invoice GP transactions clutter the search.
What popdock provides
--
Give a due-date range, and optionally a vendor and a Dynamics GP company. It reads the Ramp bills due in that range and finds the matching Dynamics GP payables transactions by invoice number, confirmed by vendor. Where there is no match by number it looks for the same vendor and amount and marks it probable. You get one table with each bill, the Ramp and GP amounts, the difference and a status of Matched, Amount differs, Probable or Missing, then GP invoices with no Ramp bill and totals. Voided GP transactions are ignored, amounts in different currencies are flagged, and a missing bill is never assumed to be a sync failure. Nothing is changed.
Business outcome
---
Missing and wrong-amount invoices are found during the month, in one table, instead of during the close.
scenario
-
Ramp and Dynamics GP share no vendor id, so keeping the two vendor lists aligned means comparing names by hand. Suffixes like Inc or LLC and differences in punctuation hide real matches. Vendors with spend in Ramp can be missing from GP, and a vendor can be inactive in Ramp while still active or on hold in GP, which only shows up when a payment goes wrong.
What popdock provides
--
Optionally give a Dynamics GP company and a minimum Ramp spend over the last 365 days. It reads the vendors from Ramp and the payables vendors from Dynamics GP, then matches them by name after normalising case, punctuation and suffixes. Near matches are listed as probable, never confirmed, and when a name matches several vendors every candidate is listed. The report shows Ramp vendors missing from GP by spend, GP vendors with a balance that are not in Ramp, and matched vendors whose status disagrees, with counts. It stops if either side is empty and never creates or changes a vendor.
Business outcome
---
Vendor gaps and status conflicts between Ramp and Dynamics GP are visible in one review, with spend to show which ones matter most.
scenario
-
Answering what we owe a vendor means opening Ramp for the bills and payment status, then Dynamics GP for the balance, invoices and payment applications, and lining them up by hand. Vendor names are not identical across systems, and an invoice that looks paid in one place can still be open in the other.
What popdock provides
--
Give a vendor name, and optionally a Dynamics GP company. It finds the vendor in both Ramp and Dynamics GP and stops to ask which one if either name is ambiguous. It then reads the Ramp bills with their approval and payment status, and the GP open balance, recent invoices and the payments applied to each document. The report shows the vendor identity on each side, then lists invoices that look paid in one system and unpaid in the other, matching invoice numbers to document numbers. Amounts in different currencies are shown side by side and not netted. It only reads and changes nothing.
Business outcome
---
One view of what is owed to and paid to a vendor across Ramp and Dynamics GP, with disagreements flagged, in place of two screens and a spreadsheet.
scenario
-
A tax manager cross-checks the states where Dynamics GP customers are located against the states where the company has nexus in Avalara AvaTax. Sales into states with no registration are found late.
What popdock provides
--
Name a state and it checks Avalara AvaTax nexus for that state, lists the Dynamics GP customers located there and shows the largest customers' recent sales and tax collected. It never says the company has no obligation just because no nexus is on record, and it treats ended nexus separately. It does not give tax advice, and nothing is changed in either system.
Business outcome
---
Customers in states with no or ended nexus are found with their recent sales, so the review starts from facts rather than a hunch.
scenario
-
An ERP administrator compares Dynamics GP inventory items against the Avalara AvaTax item catalog by hand. Items with no tax code are taxed at the wrong rate, and the gap is found only when a customer queries an invoice.
What popdock provides
--
Name an item class and it lists the Dynamics GP items in it, then looks each one up in the Avalara AvaTax item catalog. It reports items that are missing, have no tax code or map to an inactive one. It caps the number of items checked, and it does not conclude that everything is missing when the item code scheme differs between the systems. Nothing is changed in either system.
Business outcome
---
Items with missing or inactive tax codes are found without exporting either catalog, and nothing is changed in either system.
scenario
-
A tax accountant matches a Dynamics GP invoice to its Avalara AvaTax transaction line by line across two screens. A difference in tax or lines is often found only after the return has been filed.
What popdock provides
--
Name a sales document and it reads the Dynamics GP document and its lines, finds the AvaTax transaction with the same code and reports differences in tax, totals and lines. It stops when there is no match or several, ignores sub-cent rounding and flags AvaTax transactions that are not yet committed. It never says which side is right, and nothing is changed in either system.
Business outcome
---
Differences between a GP document and its AvaTax transaction are found before filing, with neither system changed.
scenario
-
An AP clerk checks a Dynamics GP vendor against the Avalara AvaTax vendor record by hand. Missing taxpayer IDs and address differences tend to surface only at year-end reporting, when fixing them is urgent.
What popdock provides
--
Name a vendor and it reads the vendor and its addresses from Dynamics GP, finds the matching AvaTax vendor and reports field by field where they disagree and whether a taxpayer ID is on file. It never prints the taxpayer ID, only whether one exists. It stops if either side has no record or several match, and it never decides which value is correct. Nothing is changed.
Business outcome
---
Vendor differences and missing taxpayer IDs are found well before year-end reporting, without exposing the ID itself.
scenario
-
A controller checking tax completeness exports a customer's Dynamics GP invoices and searches Avalara AvaTax for each one by hand. Missing or uncommitted transactions go unnoticed until an audit.
What popdock provides
--
Name a customer and a date range and it lists that customer's Dynamics GP sales documents, then looks each up in Avalara AvaTax. It reports documents that are missing, not yet committed or carrying a different tax amount. It warns when results may be truncated and sets quotes and orders apart from invoices instead of calling them errors. It never creates or commits AvaTax transactions.
Business outcome
---
Missing and uncommitted AvaTax transactions for a customer are found before an audit, without creating or changing anything.
scenario
-
An AR or tax analyst compares a customer in Dynamics GP with its Avalara AvaTax customer record by hand. Mismatched addresses or emails are missed until a tax calculation goes wrong.
What popdock provides
--
Name a customer and it reads the customer and its addresses from Dynamics GP, finds the matching AvaTax customer and reports field by field where they disagree. It separates formatting differences from real mismatches, stops if either side has no record or several match, and never states which value is correct. Nothing is changed in either system.
Business outcome
---
Customer differences between Dynamics GP and AvaTax are found before they affect tax, with the decision left to you.
scenario
-
Credit notes issued in Chargebee are not always mirrored as credit memos in Dynamics GP, so customer balances disagree. Finding the missing ones means listing credit notes, listing GP credit memos and matching them by amount and date by hand.
What popdock provides
--
Give a customer id, and optionally a start date and GP company, and it reads that customer's Chargebee credit notes. It then reads the credit memos in Dynamics GP, including returns raised as sales documents. It matches by amount within five days or by the credit note or invoice number in the GP document, and reports matched pairs, credit notes missing from GP, GP credit memos with no credit note and unapplied credit. It writes nothing to either system and does not compare amounts across currencies.
Business outcome
---
Finance sees which credit notes never reached GP and how much credit is still unapplied, with no records changed.
scenario
-
New Chargebee customers are not set up in Dynamics GP, so invoices cannot be posted until someone notices. Finding the gap means listing recent customers and searching GP for each by id, name and email.
What popdock provides
--
Give a start date, or use the last 90 days, and optionally a GP company, and it reads up to 100 recent Chargebee customers. For each it looks in Dynamics GP by customer id and then by company name, and treats a GP customer with the same email as a certain match. You get three lists: customers with no GP record, customers with a probable match for a person to confirm, and a count of exact matches. It warns if the list was cut short and never treats two customers as a match on name alone when their emails differ. It creates nothing in GP.
Business outcome
---
Operations knows which new billing customers still need setting up in GP, before invoices are blocked.
scenario
-
Billing status from Chargebee is copied into Dynamics GP customer notes by hand, and the notes go stale or overwrite what was already there. Someone has to read the subscription and invoices, find the GP customer and type a summary.
What popdock provides
--
Give a Chargebee customer id, and optionally a GP company, and it reads the customer, their subscription and their unpaid invoices from Chargebee. It summarises subscription status, next billing date, MRR, amount due, oldest overdue date and dunning status, and finds the matching GP customer, stopping unless exactly one matches. You see the exact note text and the customer it will go on, and nothing is saved until you say yes. It then adds the note once, always appending to the existing note, and reports that it was saved.
Business outcome
---
GP customer notes carry a current billing status that you approved, without overwriting existing notes or retyping from Chargebee.
scenario
-
Billing staff tick Chargebee invoices against Dynamics GP receivables line by line, and missing or mismatched invoices are found only at month end. Matching depends on purchase order numbers, document numbers and amounts.
What popdock provides
--
Give a customer id, and optionally a date range and GP company, and it reads the Chargebee invoices for the period and the customer's receivables transactions in Dynamics GP. It matches by purchase order number, then by the invoice id appearing in the GP document, then by equal total on a nearby date, and never matches one GP transaction to two invoices. You get matched invoices with any amount difference, Chargebee invoices missing from GP and GP invoices with no Chargebee invoice, ending with totals per system and the net difference. Voided GP rows are counted separately and nothing is added to GP.
Business outcome
---
Billing finds missing and mismatched invoices in GP during the month, not at close.
scenario
-
Payments settled in Chargebee are not always applied to invoices in Dynamics GP, leaving cash unapplied and balances wrong. Checking means listing payments, then finding each receipt and its application in GP.
What popdock provides
--
Give a customer id, and optionally a start date and GP company, and it reads the successful payments from Chargebee, skipping and counting failed ones. It reads the GP payment applications and receivables transactions for the same customer, then matches each payment to a cash receipt by amount within five days or by reference number in the document number. You get payments applied in both systems, payments with no GP receipt, GP payments with no Chargebee transaction and payments received but still unapplied. Nothing is written to either system and amounts are not compared across currencies.
Business outcome
---
Finance finds missing and unapplied cash in GP quickly, with no records changed on either side.
scenario
-
Someone compares a customer in Chargebee with the same customer in Dynamics GP by hand, and contact details, balances and holds drift apart unnoticed. The two systems use different ids and name spellings, so finding the match is part of the job.
What popdock provides
--
Give an email, customer id or company name, and optionally a GP company, and it finds the Chargebee customer, stopping with a list if several match. It finds the Dynamics GP customer by company name, then by id, choosing among several only when the email matches, and reads the Chargebee subscriptions and open invoices. You get a side by side table of name, email, phone, payment terms, balances, credit limit and GP hold and inactive flags, then every difference and which system looks wrong. It never compares across currencies and calls no GP write tools.
Business outcome
---
Finance sees where one customer's details and balances disagree between billing and GP, and which side to correct.
scenario
-
Collectors cross check overdue Chargebee invoices against Dynamics GP balances and holds in two systems. Deciding who to chase means looking up every customer twice, and customers on hold in GP can still have active subscriptions.
What popdock provides
--
Give a minimum overdue amount, or use 1, and optionally a GP company, and it reads the overdue Chargebee invoices and groups them by customer with the oldest due date and dunning status. For the top 15 customers by amount it looks up their Dynamics GP record by id, falling back to company name, and reads the balance, credit limit and hold and inactive flags. You get a table ranked by Chargebee overdue amount, with customers over their credit limit, customers on hold with active subscriptions and customers with no GP record flagged. It changes nothing and does not total across currencies.
Business outcome
---
Collectors start with a ranked list that combines billing and GP positions and shows where a hold and a live subscription clash.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.