Hardik Gupta
Forum Replies Created
-
GP has been heavily affected by recent Microsoft updates, especially post-CAD Tax Table changes. Your diagnostic approach is solid (data is clean = report-level issue).
Quick fixes to try:
- Rebuild RW files: Export affected reports ā Delete ā Reimport
- Reindex GL tables (GL00100/GL00101) in SQL
- Clear report cache: Delete C:\Program Files\Microsoft Dynamics\GP\Data\Reports
- Rebuild report dictionary: Admin > Reports > Rebuild All
- Verify GL Account segment configuration matches post-update CAD table setup
Root cause: Post-update, reports reference old segment indices, which drops the main Segment from account strings.
Let me know if any of these work for you.
-
This reply was modified 2 weeks ago by
Kerry Hataley.
-
Here’s what actually works:
Real-Time Integration:
- Copilot for Sales/Service surfaces insights from emails and interactions
- Predictive analytics scores leads/opportunities in real-time
- Power Automate triggers workflows on customer actions (email opens, web visits, chat)
- AI processes sentiment/intent, updates CRM, notifies the rep
Simple Architecture:
Customer Action ā Power Automate ā AI Processing ā CRM Update ā Rep NotifiedKeep humans in the loop, AI surfaces intelligence, people decide.
Real Use Cases:
- Insurance: Lead scoring + Copilot reduced sales cycle 3-4 weeks, 15% win rate improvement
- B2B SaaS: Real-time sentiment analysis + auto-routing improved CSAT 12%
- Financial Services: Customer login triggers smart recommendations, 18% cross-sell increase
Key Takeaways:
- Start with ONE use case (don’t do everything at once)
- Data quality matters, clean your CRM first
- Change management is critical, train your team
- Use Dataverse + Power Automate + Azure OpenAI
Think of Copilot as a co-pilot, not autopilot. Best results come when AI augments human judgment.
What process are you looking to optimize first?
-
Quick guide on enabling in-app notifications in Power Apps:
- Sign in to Power Apps
- Open your solution and select the model-driven app
- Edit ā Settings ā Features
- Enable In-app notifications
- Save and Publish
Quick note: @mentions in notes trigger notifications. @mentions in timeline posts don’t, use notes for notifications to work.
That’s it! Let me know if you hit any snags.
-
High-volume posting with 50k+ records needs smart architecture. Here’s what works:
Performance & Batch Jobs:
– Use
SetAutoCalcFields(false)at the start, callCalcFields()only when needed– Use QUERY objects instead of looping, optimized at DB layer
– Break batches into chunks via Job Queue (1000 records/job) instead of one massive batch
– Separate custom logic from posting using Codeunit.Run(), keeps transactions clean
Locking & Deadlocks:
– Only use
FindSet(UpdateLock)when modifying. Use read-onlyFindSet(false, false)otherwise– Keep transactions SHORT. Commit frequently, don’t wrap entire batch in one transaction
– Avoid nested events, use a “processing flag” to prevent chain reactions
Data Integrity with Temp Tables:
– Use temp tables for staging/validation (isolated, no locking)
– Validate first in temp table, commit only if all checks pass
– Use StartSession() for background work with explicit error handling
Events vs Code Mods:
– Keep event subscribers lightweight, heavy logic = slow posting
– Put business logic in separate Codeunits, call from events
– Use
OnAfterevents for critical logic (order is predictable)CalcFields Optimization:
– Don’t call inside loops, calculate once, store in variable
– FlowFields are expensive at scale; consider denormalizing with a cache table if needed
For 50k+ records, architecture looks like:
Batch Job ā Temp Table Validation ā Background Sessions (chunked) ā Event Subscribers ā External API (async)
Happy to review your posting routine specifics if you want to dig deeper!
-
GP 10.0 registration keys. Here are some practical options:
1. Microsoft Direct – Contact them with proof of purchase. They sometimes retrieve keys for old versions.
2. Check Your Files – Search your GP installation folder and Windows registry for .lic files or key info.
3. Look for Documentation – Original purchase agreement, license certificate, old emails from your VAR.
4. VAR Again – Ask if they have physical filing records from 2007-2010 era.
5. Test PSTL Anyway – Some versions work in limited mode without full registration.
6. Workarounds – If keys are truly lost, use alternative tools for what you need outside GP.
GP 10.0 is very old, so some features may not work regardless.
But these options should help you recover or work around the issue.
Good luck!
-
This reply was modified 2 weeks ago by Kerry Hataley.
-
This reply was modified 2 weeks ago by
-
Hi @donald-mccreadytheschaefergroup-com
Box 14 data lives in three places: UPR00400 (Pay Codes), UPR00500 (Deductions), and UPR00600 (Benefits). Also check UPR10101 if you’ve already done year-end.
Quick approach:
1. First, back up your database
2. Identify which codes have Box 14:
SELECT EMPLOYID, PAYRCORD, W2BXLABL FROM UPR00400 WHERE W2BXNMBR = '14'3. Remove Box 14 assignment:
UPDATE UPR00400 SET W2BXNMBR = NULL, W2BXLABL = NULL WHERE W2BXNMBR = '14'(do same for UPR00500 and UPR00600)4. Re-enter the correct Box 14 label manually in Payroll Setup
5. If year-end is closed, you’ll need to reverse and recreate the year-end wage file
Key thing: Always test in non-production first.
If you hit issues with this or need help reversing year-end, let me know. We work with GP cleanup like this regularly and can help guide you through it. Finding solid GP support is getting harder these days, so I’m happy to assist.
Good luck!
-
Hi @mmeierapothecaryproducts-com
Great question, this is a common pain point during NAV ā BC migrations.
For Engineering Change management, here are the top ISV options:
CADTALK ā Best for those with CAD/PDM/PLM systems (SolidWorks, AutoCAD). Automatically converts engineering BOMs to manufacturing BOMs and tracks all changes.
Insight Works ā Strong for complex BOMs with frequent updates. Provides hierarchical BOM views and impact analysis.
Cost Control Engineering Change Management ā If you need formal ECR ā ECO workflows with approval routing and inventory impact checks (~$6/user/month).
Don’t overlook native BC features either – built-in BOM versioning and approval workflows may handle many scenarios without an ISV.
The right choice depends on your current NAV process, BOM complexity, and whether you integrate with external engineering systems.
If you’d like help evaluating which fits your specific workflow, happy to discuss further. Good luck with the upgrade!
-
Good idea. The problem is you’re filtering too much, you’re getting all old documents instead of just the new one you’re posting.
The good news: you already have what you need. The GLRegister data has only the entries from this posting batch. Just get the document number from there instead of getting all document numbers.
Something like this:
</p><p>Get the document number from GLRegister entries</p><p>Filter your report by that one document number</p><p>That’s it. Your report will only print the current document, not all the old ones.
You’re using the right event (OnBeforeGLRegPostingReportPrint), so don’t change it. Just fix the filtering inside.
-
Key thing: don’t let external systems hit BC directly. Use a queue as a buffer, external systems drop messages, and you process in batches every 5-10 minutes. Prevents throttling when dealing with high volume.
For retries, do exponential backoff (1s, 2s, 4s) and set Job Queue to retry 5-10 times. Log everything so you can debug.
BC throttles at 6,000 requests per user per 5 minutes, so batch your requests (20 items per batch), use filtering, and prefer REST over OData.
For integration logic, use AL event subscribersāpublish events, let extensions hook in. This way, you’re not modifying BC’s base code, so upgrades won’t break anything.
Basic flow: queue ā background job ā event subscribers ā other systems. No direct API calls, no throttling issues. The buffering is the real game-changer.
-
Can you check the user have this required permission – notification table.
-
Hi Rod,
Glad we could help clarify the situation! You’re right, custom workflow customization seems to be the practical approach here.
Since exposing those quantity/amount fields in the workflow condition builder requires some customization work, we’d be happy to help if you need it.
We have solid expertise in D365 F&O customizations, and this kind of workflow extension is definitely something we’ve done before. We can help you:
- Expose the fields you need in the workflow conditions
- Build the threshold logic to validate before approval kicks off
- Test and deploy the solution safely
If you do decide to move forward, we’ve got an experienced team across time zones who can work efficiently on the implementation, no pressure at all, just know we’re here if you need a hand.
Feel free to reach out whenever, even just to discuss further or bounce ideas around.
Looking forward to hearing from you!
-
Good morning, Rod
Let me be clearer about what actually works:
Definitely works:
- Workflow Approvals – Exist in D365 F&O, but the condition builder may not expose quantity/amount fields for inventory adjustments
- Posting Validation Rules – Real feature, but uncertain how seamless it is for this specific scenario
- Custom Code Extensions – Always reliable and gives full control
Since you’ve done something similar for a customer, did you find workflow conditions worked for threshold checking, or did you need to go the custom code route?
That would help determine if native features are practical here or if custom development is the better solution.
What was your approach?
