[andrew alwin]

Up

0

Down

::

In most large AX 2012 → Dynamics 365 F&O upgrades, the Tier 1 partner usually handles the overall program governance, licensing, architecture, and Microsoft relationship, while Tier 2 or ISV-focused partners support specialized areas like customizations, industry add-ons, integrations, reporting, or data migration.

The success of the model usually depends on very clear ownership boundaries. Especially for testing, code migration, and gap analysis. Without that, projects can become messy fast.

A lot of companies use this approach because no single partner is always strong in every domain or industry process.

[andrew alwin]

Up

0

Down

::

403 in prod but not in other environments is almost always auth/permission or endpoint restriction, not code.

Things to check:

AAD App / Service Principal permissions

Make sure prod has the same API permissions + admin consent as UAT/dev

Endpoint / URL mismatch

Double-check the prod base URL and company name in the API call

IP restrictions / firewall

Prod endpoints may block requests if coming from different IPs

Token / auth setup

Ensure the token is generated for the correct tenant + environment

Batch service account

Check if the integration runs under a user/service account that lacks rights in prod

Also, the fact that retry/export fails suggests the initial failure is not clearing the batch state, so fix the auth first, then reprocess

In most cases like this, it ends up being missing permission or wrong app registration in production

[andrew alwin]

Up

0

Down

::

This usually points to a data volume / query timeout issue in Accounting Source Explorer, especially when selecting “All” financial dimension sets.

A few things to check:

Try filtering instead of selecting All. The query becomes very heavy with large datasets

Check if there’s data inconsistency or duplicate references in SourceDocumentAcctEventReferenceIdentity

Review batch jobs / cleanup jobs. Sometimes old accounting event data causes issues

Make sure your environment isn’t hitting SQL timeout limits (common in large production DBs)

If it started recently, check for customizations or recent data imports

If it persists, running a database consistency check and reviewing telemetry in LCS can help identify the exact query causing the timeout

In most cases, it’s not a functional issue. It’s performance + data volume combined with that “All” selection

[andrew alwin]

Up

0

Down

::

Yes, some teams are moving from Management Reporter to tools like Defacto, especially with Fabric in the mix.

That said, it depends on your goal:

If you want financial reporting inside D365 → Financial Reporter (built-in) is still solid

If you need advanced reporting + external data + analytics → Defacto / Fabric approach makes sense

What I’ve seen:

Defacto works well when you already use Fabric/Power BI heavily

It gives more flexibility, but adds architecture complexity

So:

Simple finance reporting → stay native

Cross-system analytics / data model → Defacto + Fabric

Key question:

Are you replacing reporting, or building a full data platform? That decides the direction

[andrew alwin]

Up

0

Down

::

We’ve seen similar “random permission” behavior in NAV → Business Central upgrades. In most cases, it’s not truly random. It’s usually permission evaluation + caching + object mismatch happening together.

A few things I’d specifically check:

Permission Set type (User vs System vs Extension)

If you’re still using legacy NAV-style permissions or partially migrated sets, BC can behave inconsistently. Try moving users fully to AL-based permission sets.

Indirect permissions missing

Posting often fails not on the main table but on related tables (ledger, dimensions, temp buffers). Admins bypass this, users don’t. That’s why it “works sometimes”.

Security cache issues

Restarting NST helps, but also try:

Force user re-login

Clear session via admin center / PowerShell

BC can cache permissions per session, causing inconsistent behavior.

Customization / extensions conflict

If any posting logic is extended, check if custom code is accessing tables without proper permissions. This is very common after upgrades.

License + permission mismatch

Sometimes users assigned lower-tier licenses hit permission issues during posting scenarios that worked in NAV.

Telemetry clue you mentioned

If telemetry shows inconsistent evaluation, I’d strongly suspect multiple permission sources overlapping (custom + standard + extension).

One quick test:

Create a clean test user with only standard BC permission sets, no customizations. If posting works 100%, the issue is definitely in your custom/security layer.

[andrew alwin]

Up

0

Down

::

Yes, but it depends on what exactly has been registered. If the production order registration is in “Registered” (product receipt) status, you generally can’t directly unregister it like picking or route transactions. Instead, you need to reverse it through the correction process. Go to the Production order and use the Report as finished (RAF) journal or end job process, then post a reversal or negative quantity to offset the receipt. Also make sure any related inventory transactions are reversed if needed. One thing to check is whether it was financially posted. If yes, the reversal must follow accounting rules. If serial or batch numbers are involved, the same dimensions must be used during correction. And if the production order is already ended, it may need to be reopened before making changes.

[andrew alwin]

Up

0

Down

::

You don’t need all connections, but AI agents in D365 FO do rely on a combination of services working together.

In most setups:

D365 FO is the core system

Dataverse is used for data exposure and interaction

Power Platform (especially Power Automate) handles workflows and triggers

Azure (AI services / OpenAI / Cognitive Services) powers the intelligence layer

So it’s not every service individually, but the ecosystem needs to be connected properly.

For examples like finance reconciliation or supplier communication agents, Dataverse + Power Platform + Azure integration is typically required. Without that, the agents won’t function as expected.

Also, documentation is still evolving, so a lot of this depends on how the solution is implemented rather than a fixed checklist.

[andrew alwin]

Up

0

Down

::

This is an interesting direction from Microsoft, and I think the key for organizations is not to anchor planning to a specific future feature set.

In asset-heavy and rental-driven businesses, ERP challenges are rarely caused by missing functionality alone. They usually come from fragmented processes. Contracts living in one place, assets tracked in another, maintenance managed separately, and finance trying to reconcile everything at the end of the month.

With Dynamics 365 evolving toward a more connected and intelligent platform, the real question becomes.<br data-start=”1028″ data-end=”1031″> Are current processes ready to be connected?

A few practical thoughts based on what I’ve seen:

<ul data-start=”1128″ data-end=”1896″>

[andrew alwin]

Up

0

Down

::

In standard Business Central, there is no out-of-the-box report that shows all purchase order lines (open or fully received) with detailed received vs invoiced quantities once the outstanding quantity is zero.

That behavior is expected. The Purchase Order Status report only shows lines with remaining quantity.

Standard alternatives you can use:

<ul data-start=”475″ data-end=”731″>

[andrew alwin]

Up

0

Down

::

To keep it short and simple, here are the essential cleanup steps and the primary sources of truth for AX 2012 Master Planning.

The Cleanup Checklist

1. Delete Stalled Plans: Go to Master planning > Periodic > Cleanup > Master planning deletion. This clears out “ghost” data from failed runs.

2. Check BOM Levels: Go to Inventory management > Setup > Bills of materials > Check BOM levels. This identifies circular dependencies (where Item A requires Item A) that cause the engine to loop.

3. Run Consistency Check: Go to System administration > Periodic > Database > Consistency check. Select “Inventory management” to fix orphaned records caused by the import.

4. Process Guide Cleanup: Go to Master planning > Periodic > Cleanup > Process guide cleanup to remove execution history that can bloat the database.

[andrew alwin]

Up

0

Down

::

This is not a new PU44 feature. The Excel driver limitation has always existed in Data Management. Microsoft has only made the warning visible now.

Excel imports and exports share a single driver. Long-running jobs can block others and cause failures, which is why CSV is now recommended for scheduled or large jobs.

These warning messages are usually not listed in release notes.

[andrew alwin]

Up

0

Down

::

Yes, the Dynamics 365 SCM and Power BI integration works, but its effectiveness depends on how you connect and model the data.

Dynamics 365 SCM is not designed for heavy analytics directly. Power BI sits on top to handle aggregation, trends, and visualization.

Data is usually pulled via data entities or exported to a data lake. Because of this, insights are near-real-time, not truly real-time. There will always be some lag unless custom pipelines are built.

For KPIs like inventory turnover, fulfillment rate, supplier performance, and production efficiency, the integration is effective only if:

– KPIs are clearly defined at the data level

– Historical data is modeled correctly

– Transactional tables are not queried directly for visuals

The biggest benefit in practice is replacing manual Excel reporting with a consistent, centralized view. The biggest risk is poor data modeling, not the tools themselves.