[Hardik Gupta]

Up

0

Down

::

Hi Rod,

Yes, there are built-in options:

1. Posting Validation Rules – Set quantity/amount limits at the inventory or GL account level to block transactions exceeding thresholds.

2. Workflow Approvals – Configure approval workflows for adjustments above a certain value.

3. GL Account Posting Restrictions – Restrict posting based on transaction amounts.

Check your Inventory Management setup and Posting Validation Rules first—they likely have what you need.

Hope this helps!

[Hardik Gupta]

Up

0

Down

::

Hi @praspras6360gmail-com

We’ve seen this across multiple production deployments post-deployment. It’s almost always a service principal re-authentication issue; the integration carries cached credentials from lower environments and loses its active token in production.

Quick Fix (Tested):

1. Clear & Re-authenticate

– Data Integration > Edit project > Remove Connection

– Re-establish connection with fresh OAuth flow in production

2. Verify Azure AD Permissions

– Confirm service principal has “Dynamics 365 Finance and Operations” permission

– Grant admin consent if needed

3. Reset Batch & Reprocess

– Check Activity Monitor for failed batches

– Restart job with fresh authentication

The 403 error means invalid token/insufficient scope. Re-authenticating in production generates a fresh token and resolves it.

Let us know if this works or if you need to explore other approaches.

[Hardik Gupta]

Up

0

Down

::

Hi @larrycarrethers

This one trips up a lot of people because of how GP stores kit data in SOP30300.

The key thing to know: revenue sits on the kit header row (CMPNTSEQ = 0), and cost sits on the component rows (CMPNTSEQ > 0). Miss that, and your COGS will be all over the place.

The fix is straightforward: pull revenue from the header row, aggregate costs from components using LNITMSEQ as the link, and filter IV00101 for ITEMTYPE = 3 (Kits). There’s no native GP report for this, so SQL/SSRS is your best bet.

sql

SELECT
    h.SOPNUMBE, h.DOCDATE, h.CUSTNMBR,
    l.ITEMNMBR, l.XTNDPRCE AS Revenue,
    ISNULL(comp.Total_Cost, 0) AS COGS,
    l.XTNDPRCE - ISNULL(comp.Total_Cost, 0) AS Gross_Profit
FROM SOP30200 h
INNER JOIN SOP30300 l
    ON h.SOPNUMBE = l.SOPNUMBE AND h.SOPTYPE = l.SOPTYPE
    AND l.CMPNTSEQ = 0
INNER JOIN IV00101 iv ON l.ITEMNMBR = iv.ITEMNMBR AND iv.ITEMTYPE = 3
LEFT JOIN (
    SELECT SOPNUMBE, SOPTYPE, LNITMSEQ, SUM(EXTDCOST) AS Total_Cost
    FROM SOP30300 WHERE CMPNTSEQ > 0
    GROUP BY SOPNUMBE, SOPTYPE, LNITMSEQ
) comp ON l.SOPNUMBE = comp.SOPNUMBE
      AND l.SOPTYPE = comp.SOPTYPE
      AND l.LNITMSEQ = comp.LNITMSEQ
WHERE h.SOPTYPE = 3 AND h.VOIDSTTS = 0;

• This reply was modified 2 weeks ago by  Kerry Hataley.

[Hardik Gupta]

Up

0

Down

::

Hi Djon,

DCA accounts are NOT meant to zero out. They’re throughput accounts, not traditional contra accounts.

When you post labour or materials, BC routes the cost through DCA into WIP. The WIP account is what eventually clears when the finished good is sold and COGS gets hit. DCA just reflects cumulative direct costs that flowed through production.

At period end, your DCA balance should mirror what’s sitting in WIP/COGS on the other side. That’s your reconciliation check.

If your team wants a deeper walkthrough on the full cost flow from raw material to COGS in BC, we’re happy to help. Sometimes one focused session clears up months of confusion!

[Hardik Gupta]

Up

0

Down

::

Hi @asmiley4ptcsolutions-com

You’re not alone in finding this confusing, BC’s assembly posting under standard cost does look messy at first.

What you’re seeing is actually correct. BC posts the actual cost first ($13K), then adjusts to standard in separate steps rather than netting it cleanly. The end result should still be $10K in inventory and $3K to variance; it just takes a few journal lines to get there.

Best way to make sense of it: filter your G/L entries by the assembly order’s Document No. and read them in sequence. It becomes much clearer that way.

Happy to help further if you can share the entries.

[Hardik Gupta]

Up

0

Down

::

Hi Brianna,

Thanks for sharing this. If the requirement is still open, we do have experienced resources who can support both on-site and offshore, depending on the skills and setup you’re looking for. Our team works across Microsoft Dynamics BC/NAV/GP/F&O, along with CRM and Power Platform.

Happy to share a few references or connect if that’s helpful.

[Hardik Gupta]

Up

0

Down

::

Hi @vshelkeycompasshn-org

This comes up a lot for NFPs moving from GP to BC, especially with heavy use of GP variable allocations. We’ve actually helped someone recently through a GP-to-BC migration with a similar challenge, where the key was upgrading the allocation approach and aligning the right data using dimension filters.

BC does handle dimensions differently, but it’s usually more about design and how the allocations are reviewed than a hard limitation. Once the physical vs reporting dimensions and audit trail are clear, it tends to fall into place. Happy to walk through an example if helpful.

[Hardik Gupta]

Up

0

Down

::

Hi @cfarmeresprigas-com

I’ve run into this a few times over the years, and it’s usually not the No. series itself, but something around timing, integrations, or custom logic touching the number assignment. If you’re able to share a bit more context around where it’s happening (document type, posting vs creation, any integrations/customizations), it’ll be easier to narrow down.

Happy to take a quick look or jump on a short call if that helps.

[Hardik Gupta]

Up

1

Down

::

Hi Laresa,

I’ve seen the Finance Charge Memo error come up before, and it usually relates to how a few setups connect

Customer Posting Group and Interest Account mapping

Finance Charge Terms linked with the right posting groups

Customer Card settings that sometimes override defaults

When these are aligned, the process works smoothly. We had to adjust these areas for one of our clients, and it solved the issue; it might be worth checking on your side too.

[Hardik Gupta]

Up

0

Down

::

Hi Lori,

I’ve seen this come up a few times with Business Central 26.3, especially when subscriptions don’t behave the way we expect. From experience, the areas that usually need a closer look are:

[Hardik Gupta]

Up

0

Down

::

Hi Jeff,

This lines up with what we’ve seen as well. The shift from GP distributions to BC’s dimension-first approach is usually the biggest mindset change, especially during finance review when things don’t “look” the way they did in GP.

We’ve helped teams recently moving from GP to BC, where the system was technically fine, but the challenge was aligning the original GP intent with how BC handles postings, allocations, and audits. We also have a bench of GP-experienced resources who work alongside BC environments to keep things aligned, so the setup holds up cleanly as things evolve.

Appreciate you sharing your experience, it’s a helpful context for anyone going through this transition.