Hello — the Dynamics 365 community, live

New jobs, articles and questions as they happen. Join free to say hello and start earning points.

New job 2w ago

Senior D365 Finance Consultant

Remote Full Time

Lead the finance workstream on Dynamics 365 Finance & Operations implementations. As a Senior D365 Finance Consultant you'll run requirements workshops, configure the financial modules, design solutions for complex finance processes, and guide clients toward standard best practice, owning documentat…

Lead the finance workstream on Dynamics 365 Finance & Operations implementations. As a Senior D365 Finance Consultant you'll run requirements workshops, configure the financial modules, design solutions for complex finance processes, and guide clients toward standard best practice, owning documentation, testing, and go-live support along the way. You'll work on multi-entity, multi-currency, internationally regulated finance landscapes where a strong accounting foundation meets hands-on D365 craft. Ideal for a consultant who can sit with a CFO's team in the morning and configure the GL in the afternoon.

Requirements

5+ years as a D365 F&O (or AX) finance consultant with full-cycle implementations. Strong accounting foundation and the ability to map finance processes to D365 standard functionality. Experience with multi-entity, multi-currency, consolidations, and localization/tax scenarios. Comfortable authoring FDDs and leading client workshops in English. Nice to have: qualified/part-qualified accountant (ACCA, CIMA, or equivalent); e-invoicing and regulatory localization; financial reporting (Financial Reporting/Management Reporter, Power BI); tax-engine or finance ISV exposure. Certification valued: MB-310 (Dynamics 365 Finance Functional Consultant Associate).

Responsibilities
  • Lead finance requirements workshops and translate them into configuration and FDDs.
  • Configure and deliver General Ledger, Accounts Payable, Accounts Receivable, Cash & Bank, Fixed Assets, Budgeting, and Cost Accounting.
  • Design solutions for intercompany, multi-currency, consolidations, and tax/VAT across legal entities.
  • Support financial dimensions, chart-of-accounts design, and period-end/close processes.
  • Author functional design documents and collaborate with developers on extensions.
  • Drive UAT, build test scripts, and validate finance master/transactional data migration.
  • Provide go-live and hypercare support; train key users.
What's on offer
  • Competitive senior-level compensation
  • Permanent role with an established international Microsoft Dynamics partner
  • Remote-first working with flexible hours
  • Complex multi-entity, multi-country finance landscapes for enterprise clients
  • Work alongside experienced architects on full-cycle implementations
  • A mature delivery methodology and strong in-house consulting practice
  • Structured career progression within a global consultancy
  • Funded Microsoft certifications and ongoing professional development
Like 0 comments
New job 2w ago

Senior D365 Solution Architect (Finance & Operations)

Remote Full Time

Job Description Own the end-to-end solution design for Dynamics 365 Finance & Operations programs. As Senior Solution Architect you'll translate complex business requirements into secure, scalable, and maintainable architectures, lead fit-gap analysis, govern design decisions, and act as the techni…

Job Description Own the end-to-end solution design for Dynamics 365 Finance & Operations programs. As Senior Solution Architect you'll translate complex business requirements into secure, scalable, and maintainable architectures, lead fit-gap analysis, govern design decisions, and act as the technical authority across functional and development teams. You'll shape integration and data-migration strategy, set ALM and environment standards, and be the person other consultants turn to when a cross-module decision has ripple effects. It's a role for an architect who likes both the whiteboard and the detail — defining the blueprint and making sure it survives contact with delivery.

Requirements

8+ years in the Dynamics ecosystem (D365 F&O / AX), with 3+ programs in a lead architect capacity. Deep cross-module knowledge of F&O (Finance + Supply Chain minimum) and how decisions in one area affect the whole solution. Strong integration and data-migration architecture experience (OData, dual-write, Data Management Framework, Logic Apps, Service Bus); Power Platform/Dataverse fluency where relevant. Solid grasp of ALM, environment strategy, DevOps repos, branching/merging, and One Version lifecycle. Ability to write and review clear design documentation and lead design-authority forums. Nice to have: industry vertical depth (manufacturing, distribution, project-based); multi-entity/multi-repo consolidation experience; Copilot/AI agents in F&O and agentic architecture patterns. Certifications valued: MB-700 (F&O Solution Architect Expert — existing holders fully credited), underlying MB-310/MB-330, and the forward-looking AB-100 (Agentic AI Business Solutions Architect).

Responsibilities
  • Lead solution design across F&O modules; produce and govern architecture artifacts, design-decision logs, and solution blueprints/FDDs.
  • Run fit-gap and fit-to-standard analysis; drive configuration-first decisions and justify extensions where standard falls short.
  • Define integration architecture and data-migration strategy (ETL, staging, reconciliation).
  • Own environment and ALM strategy: branching, DevOps pipelines, One Version cadence, build/release, and code-merge governance.
  • Review functional and technical designs for feasibility, performance, security (segregation of duties), and supportability.
  • Guide functional consultants and developers; resolve cross-stream design conflicts.
  • Align solution scope with business value and program timeline through stakeholder engagement.
What's on offer
  • Competitive senior/expert-level compensation with an established international Microsoft Dynamics partner
  • Remote-first working with flexible hours
  • Design authority on greenfield and transformation programs for enterprise clients
  • Freedom to set architecture, ALM, and environment standards across programs
  • Hands-on exposure to Copilot and emerging agentic AI architecture in F&O
  • Structured career progression and a senior peer group of architects
  • A peer network of senior architects and consultants through Dynamics Hub
Like 0 comments
New job 2w ago

Senior Project Manager (Dynamics 365)

Remote Contract

Job Description Lead end-to-end delivery of Microsoft Dynamics 365 implementations (F&O and/or CE) for international clients. As Senior Project Manager you'll own scope, budget, timeline, and stakeholder relationships from kick-off through go-live and hypercare, working hand-in-hand with solution a…

Job Description Lead end-to-end delivery of Microsoft Dynamics 365 implementations (F&O and/or CE) for international clients. As Senior Project Manager you'll own scope, budget, timeline, and stakeholder relationships from kick-off through go-live and hypercare, working hand-in-hand with solution architects and functional leads. This is a high-ownership role on enterprise-grade programs, multi-stream, often multi-country, where strong methodology, commercial awareness, and steady stakeholder leadership genuinely move the outcome. If you enjoy running complex transformation programs end-to-end rather than just tracking tasks, this is for you.

Requirements

7+ years managing ERP/CRM implementations, including at least 3 full-cycle Dynamics 365 (or AX/CRM) programs. Strong command of a structured delivery methodology (Success by Design, Sure Step, PRINCE2, or PMI) plus agile frameworks (Scrum/SAFe). Hands-on Azure DevOps for backlog, sprints, and release management. Proven budget, margin, and stakeholder ownership on programs of meaningful scale. Excellent written and spoken English; confident in client-facing steering forums. Nice to have: large manufacturing/supply-chain or finance transformation experience; multi-partner or program-rescue/takeover scenarios; Power BI delivery dashboards. Certifications valued (not required): PMP, PRINCE2, PMI-ACP, Scrum Master (PSM/CSM), D365 Fundamentals (MB-910/MB-920).

Responsibilities
  • Own the full delivery lifecycle across analysis, design, build, test, deploy, and operate phases.
  • Manage scope, budget, resourcing, and timeline; maintain RAID logs, status reporting, and steering-committee communication.
  • Run sprint planning, backlog grooming, and release cadence; coordinate Azure DevOps boards.
  • Manage client and partner stakeholders, including change requests, escalations, and commercial conversations.
  • Coordinate cutover and go-live planning, mock data migrations (ETL), UAT, and hypercare transition.
  • Track and forecast project financials (T&M and fixed-fee), margin, and resource utilization.
What's on offer
  • Competitive senior-level compensation with an established international Microsoft Dynamics partner
  • Remote-first working with flexible hours
  • Full ownership of international, multi-stream D365 programs end-to-end
  • Steering-committee-level client exposure and real decision-making authority
  • A mature delivery methodology and strong in-house architecture practice behind you
  • Structured career progression within a global consultancy
  • Continuous Microsoft certification support and renewals
  • Access to the Dynamics Hub practitioner network and knowledge sharing
Like 0 comments
Question 3w ago +10 pts

Stock Variation Issue while posting

When making a GRN in system my entries are getting posted in the stock variance account. I want to know the reason for t…

When making a GRN in system my entries are getting posted in the stock variance account. I want to know the reason for this issue. My current item model group is FIFO. Thanks in advance!
Like 1 comment
B
Blerina Kaloti 3w ago
Hi, Since you're seeing postings to the Stock Variance account during the GRN/Product Receipt, I'd first check whether Fixed receipt price is enabled on the Item Model Group assigned to the item. Even when the inventory model is FIFO, this setting can cause differences between the receipt value and the inventory value to be posted to a variance account. I'd also review the accounting entries and Inventory Posting setup to see which posting type is driving the Stock Variance transaction. The offset account and posting type usually make the root cause much easier to identify.
New job 27 Jul

Senior Data Engineer / Migration Specialist (Dynamics 365)

Remote Contract

Own data migration and data engineering for Dynamics 365 programs. As a Senior Data Engineer / Migration Specialist you'll design ETL pipelines, build and validate migrations into D365 F&O and Dataverse, and engineer the data flows that feed analytics and integrations. You'll work across DMF, Azure…

Own data migration and data engineering for Dynamics 365 programs. As a Senior Data Engineer / Migration Specialist you'll design ETL pipelines, build and validate migrations into D365 F&O and Dataverse, and engineer the data flows that feed analytics and integrations. You'll work across DMF, Azure Data Factory, SQL and the Microsoft data stack on complex, high-volume landscapes. For an engineer who treats data quality and reconciliation as first-class concerns.

Requirements

5+ years in data engineering/migration, with Dynamics 365 (F&O/Dataverse) experience. Strong ETL/ELT skills: Azure Data Factory, SSIS, and SQL. Deep experience with the Data Management Framework (DMF) and data entities. Solid data-modelling, cleansing, mapping, and reconciliation practice. English working proficiency. Nice to have: Microsoft Fabric/Synapse; Synapse Link for Dataverse; KingswaySoft; Python for data work. Certification valued: DP-203/DP-700 or MB-500 where held.

Responsibilities
  • Design and build data-migration strategy: staging, mapping, transformation, and load.
  • Implement migrations into D365 F&O (DMF) and Dataverse with repeatable pipelines.
  • Build ETL/ELT in Azure Data Factory, SSIS, and SQL.
  • Establish data quality, cleansing, deduplication, and reconciliation processes.
  • Support analytics and integration data flows (Synapse Link, Lakehouse).
  • Document mappings and migration runbooks; lead mock migrations and cutover.
  • Collaborate with functional consultants and architects across delivery.
What's on offer
  • Competitive senior-level compensation
  • Long-term, multi-phase engagements with an established international Microsoft Dynamics partner
  • Remote-first working with flexible hours
  • High-volume migration and data-engineering work on enterprise D365 programs
  • Hands-on with Azure Data Factory, Fabric, and the Microsoft data stack
  • Clean engineering standards and strong reconciliation discipline
  • Structured career progression and a senior peer group of engineers
  • Funded Microsoft certifications and ongoing professional development
Like 0 comments
New job 27 Jul

Senior Azure Integration Specialist (Dynamics 365)

Remote Contract

Design and build the integration layer for Dynamics 365 programs using Azure integration services. As a Senior Integration Specialist you'll architect and implement robust, secure integrations between D365, third-party systems and Azure, owning patterns, error handling and monitoring. You'll work ac…

Design and build the integration layer for Dynamics 365 programs using Azure integration services. As a Senior Integration Specialist you'll architect and implement robust, secure integrations between D365, third-party systems and Azure, owning patterns, error handling and monitoring. You'll work across OData, dual-write, Logic Apps, Functions and Service Bus on enterprise-grade landscapes. For an engineer who cares about resilient, observable, well-governed integrations.

Requirements

5+ years building integrations in the Microsoft/Azure ecosystem, with D365 experience. Strong hands-on with Logic Apps, Azure Functions, Service Bus, and API Management. Deep knowledge of D365 integration options: OData, custom services, DMF, dual-write. C#/.NET and messaging/eventing patterns; secure auth (OAuth, managed identities). English working proficiency. Nice to have: Azure Integration Services landing zones; SSIS/KingswaySoft; event-driven architecture; monitoring with Application Insights. Certification valued: AZ-204/AZ-305 or MB-500 where held.

Responsibilities
  • Design integration architecture and patterns between D365, Azure, and third-party systems.
  • Build and maintain Logic Apps, Functions, Service Bus, and API Management solutions.
  • Implement D365 integrations via OData, custom services, DMF, and dual-write.
  • Establish error handling, retry, idempotency, logging, and monitoring standards.
  • Secure integrations with OAuth, managed identities, and key management.
  • Author technical designs and conduct code reviews.
  • Collaborate with architects and functional teams across delivery.
What's on offer
  • Competitive senior-level compensation
  • Long-term, multi-phase engagements with an established international Microsoft Dynamics partner
  • Remote-first working with flexible hours
  • Enterprise integration architecture across D365 and Azure
  • Clean engineering standards with real CI/CD and monitoring
  • Opportunity to shape integration patterns across programs
  • Structured career progression and a senior peer group of engineers
  • Funded Microsoft certifications and ongoing professional development
Like 0 comments
New job 27 Jul

Senior D365 Field Service Consultant

Remote Contract

Lead the field service workstream on Dynamics 365 Field Service implementations. As a Senior D365 Field Service Consultant you'll configure work orders, scheduling, assets, inventory and mobile experiences, and design solutions that get the right technician to the right job with the right parts. You…

Lead the field service workstream on Dynamics 365 Field Service implementations. As a Senior D365 Field Service Consultant you'll configure work orders, scheduling, assets, inventory and mobile experiences, and design solutions that get the right technician to the right job with the right parts. You'll work across dispatch, resource scheduling and IoT-driven service scenarios on the Power Platform/Dataverse. Ideal for a consultant who understands service operations as well as the system.

Requirements

5+ years as a D365 Field Service / CE functional consultant with full-cycle implementations. Strong configuration knowledge of work orders, the schedule board, Resource Scheduling Optimization (RSO), and assets. Experience with the Field Service mobile app and inventory/RMA processes. Solid Power Platform and Dataverse foundation. Comfortable authoring FDDs and leading client workshops in English. Nice to have: Connected Field Service/IoT; integration to ERP for parts and finance; Copilot for Service. Certification valued: MB-240 (Field Service Functional Consultant Associate — existing holders credited).

Responsibilities
  • Lead Field Service requirements workshops and map service processes to D365 standard.
  • Configure work orders, incident types, the schedule board, RSO, and the mobile app.
  • Design asset management, inventory, purchasing/RMA, and agreement/entitlement scenarios.
  • Solution dispatch, resource scheduling, and IoT-driven proactive service.
  • Build supporting model-driven apps, business process flows, and security roles.
  • Author FDDs and collaborate with developers on plug-ins and integrations.
  • Drive UAT, data migration, key-user training, and go-live/hypercare.
What's on offer
  • Competitive senior-level compensation
  • Long-term, multi-phase engagements with an established international Microsoft Dynamics partner
  • Remote-first working with flexible hours
  • Field Service and connected/IoT programs for enterprise clients
  • Power Platform, Dataverse, and Copilot for Service hands-on work
  • A mature delivery methodology and strong in-house consulting practice
  • Structured career progression within a global consultancy
  • Funded Microsoft certifications and ongoing professional development
Like 0 comments
Article 21 Jul +150 pts

The Trust Gap in Supply Chain Data

Every company wants real time visibility into their supply chain. Fewer companies actually trust that visibility enough to act on it. I've noticed this pattern again and…

Every company wants real time visibility into their supply chain. Fewer companies actually trust that visibility enough to act on it. I've noticed this pattern again and again around Dynamics 365 Supply Chain Management implementations. The system is set up, inventory is tracked, demand forecasting is running, planners have a dashboard that shows exactly what's on hand, what's in transit, and what's projected to be needed next month. And yet, in a lot of warehouses and planning offices, someone is still keeping a personal spreadsheet, still calling a supplier directly to double check a number, still adjusting the system's forecast based on gut feel built up over years on the job. That gap between what the software shows and what people actually rely on is worth paying attention to. It rarely comes from the technology being wrong. Dynamics 365 Supply Chain Management can genuinely pull together procurement, inventory, warehouse, and manufacturing data in a way that legacy point systems never managed. The gap comes from trust, and trust in supply chain data is earned slowly and lost quickly. One bad forecast during a demand spike, one inventory count that didn't match reality during a physical audit, and a planner remembers that moment for years. After that, the system becomes a reference point instead of a decision maker, and the spreadsheet on the side quietly becomes the real source of truth. This matters more now than it used to, because supply chains have spent the last several years absorbing shocks that made careful planners even more cautious. Disruption after disruption taught a lot of supply chain professionals that clean historical data does not always predict what happens next, and that lesson does not disappear just because a new planning engine got implemented. So the honest challenge for any Dynamics 365 Supply Chain Management rollout isn't only technical configuration. It's proving, transaction by transaction, that the numbers hold up when it counts, and that takes longer than any go live date usually allows for. There's also an organizational layer to this. In many companies, the people closest to physical inventory, warehouse staff, floor supervisors, receiving teams, are the ones whose daily actions determine whether the data in the system stays accurate. If those teams see data entry as a task imposed on them rather than something that protects their own planning decisions later, small inaccuracies creep in constantly, and no amount of forecasting sophistication can fix data that was wrong at the source. What this points to is a simple but often overlooked truth about supply chain platforms. The value of a system like Dynamics 365 Supply Chain Management isn't determined at the moment of implementation. It's determined months later, in the quiet decision of whether a planner opens the dashboard first or the spreadsheet first when something urgent comes up. Getting the software right is the easier half of the work. Getting an en…
Like 0 comments
Article 17 Jul

Putting Copilot Agents into Production in Dynamics 365: Security Roles, Data Boundaries, and the Day-2 Work Nobody Demos

The demo always goes the same way. Someone types "create a purchase requisition for 200 units of the steel bracket from our usual vendor and route it for approval" into a…

The demo always goes the same way. Someone types "create a purchase requisition for 200 units of the steel bracket from our usual vendor and route it for approval" into a chat pane, and the AI agent finds the item, picks the vendor, fills the form, and submits the workflow. But three weeks later, that agent is in production, and the questions start: Why can this thing see payroll? Who approved it, touching the ledger? It just edited a record nobody asked it to; was that allowed? I've now deployed enough Copilot agents for Dynamics 365 Finance & Operations to say the quiet part out loud. Building the agent is only 20% of the journey. The remaining 80%, which entails deploying, governing, monitoring, and running it safely at scale, is where the real complexity begins. This article is about the 80%. The Demo Problem Demos optimize for the happy path. A scripted prompt, clean data, one user, no edge cases, and a presenter who knows exactly what the agent will do because they rehearsed it. Production is the opposite of all of that. You get prompts nobody anticipated, users with wildly different permissions, dirty data, and an agent that's now allowed to act, not just answer. The business challenge isn't "can the agent do the task?" It demonstrably can. The challenge is ownership: who is accountable for what the agent is permitted to see and do, who watches it, who gets paged when it misbehaves, and who can prove to an auditor that it stayed inside its lane. That's an operations discipline, and it's one most teams haven't built yet because the technology only made autonomous action practical very recently.  What Actually Changed  If you wired an agent to F&O over the last year, you probably used the static Dynamics 365 ERP MCP server, a fixed set of 13 tools built on the Dataverse connector framework. It worked, but it was rigid, and Microsoft is retiring it during the 2026 calendar year. The replacement, the “dynamic” Dynamics 365 ERP MCP server, went generally available in February 2026. Instead of a frozen tool list, it exposes living tool categories: data tools for create/read/update/delete against entities, action tools that invoke business logic, and metadata tools the agent uses to discover your schema, including custom entities and extensions. Per Microsoft's documentation, this surfaces hundreds of thousands of ERP operations across tens of thousands of forms, without a custom connector or bespoke API. The data tools also moved off chatty form-level interactions toward direct, optimized entity operations, which is why agent responses got both faster and more reliable. Here's the line from Microsoft Learn that matters more than any of that: when you add the MCP server to an agent, it gets access to data and business logic that matches the agent's security role and environment context. This means it gets exactly the permissions you assign it, no more, no less.  The Security Role is the Whole Ballgame Treat the agent like a new employee on day o…
Like 0 comments
Discussion 16 Jul +10 pts

How to put agents to work without breaking what already runs the business?

Two years ago, Copilot in Dynamics 365 was essentially a helpful colleague who could summarize a record or draft an emai…

Two years ago, Copilot in Dynamics 365 was essentially a helpful colleague who could summarize a record or draft an email. The 2026 release wave 1 marks the point where that changed. Microsoft now ships agents across Sales, Customer Service, Finance and Supply Chain that do not simply answer questions. They take a business goal expressed in plain language, break it into concrete steps, and carry those steps out inside the system.  The clearest example is the Contact Center, which Microsoft is turning into a fully agentic environment. Cases get triaged, routed, drafted and in many instances resolved before a human ever opens them. Containment rates, the share of inquiries handled entirely without human involvement, have become a headline metric in customer service projects. On the finance side, the new autonomous Payflow Agent takes over payment processing tasks that used to consume hours of accounts payable time every week. Anyone who has sat through a Dynamics implementation knows the traditional shape of the work: requirements, configuration, data migration, training, support. Agents add a layer that behaves differently from anything consultants have deployed before. An agent is not a workflow. It does not follow a fixed path, and its behavior depends on the quality of the data and knowledge it can reach.  That has practical consequences. Data hygiene, long treated as a cleanup task to squeeze in before migration weekend, is now a precondition for the headline features working at all. An agent drafting customer responses from a knowledge base full of outdated articles will confidently produce outdated answers. Teams that skipped the unglamorous work of curating their content are discovering that the bill has arrived.  Scoping also changes. Clients increasingly arrive with expectations set by consumer AI tools and assume the same fluency will appear in their ERP on day one. Part of the consultant's job in 2026 is expectation management: being clear about what agents do well today, where they still need human review, and which processes are genuinely ready to hand over.
142 Read more
Like 0 comments
Article 14 Jul +150 pts

From Assistant to Agent: What Agentic AI Really Means for Dynamics 365

The conversation in the Dynamics world has changed. Nobody is asking whether to adopt AI anymore. The question on every project board is how to put agents to work without…

The conversation in the Dynamics world has changed. Nobody is asking whether to adopt AI anymore. The question on every project board is how to put agents to work without breaking what already runs the business.  Two years ago, Copilot in Dynamics 365 was essentially a helpful colleague who could summarize a record or draft an email. Useful, certainly, but nobody would have trusted it to act on its own. The 2026 release wave 1 marks the point where that changed. Microsoft now ships agents across Sales, Customer Service, Finance and Supply Chain that do not simply answer questions. They take a business goal expressed in plain language, break it into concrete steps, and carry those steps out inside the system.  The clearest example is the Contact Center, which Microsoft is turning into a fully agentic environment. Cases get triaged, routed, drafted and in many instances resolved before a human ever opens them. Containment rates, the share of inquiries handled entirely without human involvement, have become a headline metric in customer service projects. On the finance side, the new autonomous Payflow Agent takes over payment processing tasks that used to consume hours of accounts payable time every week.  What this changes for implementation work  Anyone who has sat through a Dynamics implementation knows the traditional shape of the work: requirements, configuration, data migration, training, support. Agents add a layer that behaves differently from anything consultants have deployed before. An agent is not a workflow. It does not follow a fixed path, and its behavior depends on the quality of the data and knowledge it can reach.  That has practical consequences. Data hygiene, long treated as a cleanup task to squeeze in before migration weekend, is now a precondition for the headline features working at all. An agent drafting customer responses from a knowledge base full of outdated articles will confidently produce outdated answers. Teams that skipped the unglamorous work of curating their content are discovering that the bill has arrived.  Scoping also changes. Clients increasingly arrive with expectations set by consumer AI tools and assume the same fluency will appear in their ERP on day one. Part of the consultant's job in 2026 is expectation management: being clear about what agents do well today, where they still need human review, and which processes are genuinely ready to hand over.  Augmentation, not replacement  A theme that came through strongly at this year's community events is that the organizations getting real value from agents are not using them to cut headcount. They are using them to remove repetitive work so that sales teams sell, service teams solve the difficult cases, and finance teams spend their time on analysis rather than data entry. The productivity gain is real, but it shows up as better output from the same people, not as an empty desk.  That framing matters for adoption too. Users who believe an agent is bei…
Like 0 comments
New job 11 Jul

D365 SCM Lead /Senior functional consultant (Dominos)

Onsite Full Time

• Strong expertise in Advanced Warehouse Management and other core SCM areas. • Ready to work in support projects. • Excellent communication skills, both verbal and written. • Flexibility to work in shifts (rotational basis) minimum 3 days’ work in night shifts. • Willingness to learn and take o…

• Strong expertise in Advanced Warehouse Management and other core SCM areas. • Ready to work in support projects. • Excellent communication skills, both verbal and written. • Flexibility to work in shifts (rotational basis) minimum 3 days’ work in night shifts. • Willingness to learn and take ownership of additional modules such as MRP and Electronic Reporting post onboarding.

Requirements

• Minimum 8+ years of experience in D365 SCM. Strong expertise in Advanced Warehouse Management and other core SCM areas. Planning, Sourcing, Manufacturing/Production, Delivery (logistics), Returns (Reverse logistics) • Proven track record of handling end-to-end SCM processes. • Ability to collaborate effectively with cross

Like 0 comments
New job 11 Jul

D365 F&O Finance Lead (10+ Years Experience)

Onsite Full Time

Role Overview: We are seeking a highly experienced professional with over 10 years of expertise in Microsoft Dynamics 365 Finance & Operations (F&O), specializing in Finance module implementation. The candidate will lead end-to-end ERP implementation projects, ensuring successful delivery aligned…

Role Overview: We are seeking a highly experienced professional with over 10 years of expertise in Microsoft Dynamics 365 Finance & Operations (F&O), specializing in Finance module implementation. The candidate will lead end-to-end ERP implementation projects, ensuring successful delivery aligned with business requirements.

Requirements

10+ years of experience in ERP implementations, with a strong focus on D365 F&O Finance. Deep expertise in Finance modules GL, AP, AR, Fixed Assets, Budgeting, Cash & Bank, Taxation) Electronic Reporting Intercompany Credit and collections Cost management Asset leasing Strong knowledge of business processes and financial reporting. Experience in preparing functional documentation and conducting workshops. Excellent communication and stakeholder management skills. Preferred Qualifications Microsoft Dynamics 365 certifications in Finance & Operations. Experience working with global clients and multi-country rollouts.

Like 0 comments
New job 11 Jul

Sr Technical Consultant

Remote Contract

Azure AI Search, Azure OpenAI, Machine Learning and Modeling, Azure Machine Learning, Advanced Machine Learning Techniques, Responsible AI, Operations for Machine Learning, Adaptive Grammar Engine (AGE/NADM), Generative AI. Seeking a senior Generative AI Consultant with deep expertise in Prompt Eng…

Azure AI Search, Azure OpenAI, Machine Learning and Modeling, Azure Machine Learning, Advanced Machine Learning Techniques, Responsible AI, Operations for Machine Learning, Adaptive Grammar Engine (AGE/NADM), Generative AI. Seeking a senior Generative AI Consultant with deep expertise in Prompt Engineering, Azure OpenAI Service, Azure AI Search, Azure AI Foundry, RAG (Retrieval-Augmented Generation), Agentic AI, Microsoft Copilot, Power Platform (Power Apps), Azure Container Apps, Azure Key Vault, API integration, and enterprise AI solution architecture.

Requirements

Responsibilities
  • The ideal candidate should have experience delivering complex enterprise-scale AI transformation programs, establishing AI governance frameworks, implementing DevOps/MLOps practices, managing stakeholders, and driving end-to-end AI solution design, development, and deployment.
Like 0 comments
New job 11 Jul

D365 HRM Functional Consultant – (Compensation & Benefits)

Onsite Full Time

Experience: 13+ Years Role Summary: Looking for an experienced D365 Functional Consultant with strong expertise in HRM Compensation & Benefits to drive end-to-end implementation of compensation cycles including planning, budgeting, approvals, payroll integration, and analytics. Key Responsibiliti…

Experience: 13+ Years Role Summary: Looking for an experienced D365 Functional Consultant with strong expertise in HRM Compensation & Benefits to drive end-to-end implementation of compensation cycles including planning, budgeting, approvals, payroll integration, and analytics. Key Responsibilities: Lead requirement gathering and translate business needs into D365 HRM solutions Configure compensation plans, eligibility rules, and benefit structures Implement full compensation cycle (budgeting → planning → approvals → payout) Design approval workflows, governance, and compliance controls Support global compensation frameworks (multi-country, multi-currency) Work closely with HR, Finance, Payroll, and Business stakeholders Lead UAT, go-live support, and post-implementation enhancements.

Requirements

Required Skills: Hands-on experience in D365 Finance & Operations / HR module Strong domain expertise in Compensation & Benefits (C&B) Knowledge of compensation cycles, budgeting, proration, and approvals Understanding of payroll integration and HR processes Strong stakeholder communication and leadership skills Good to Have: Experience in global HR implementations Exposure to Power BI / analytics. Microsoft D365 certifications

Like 0 comments
New job 11 Jul

D365 Technical Architect – HRM Compensation & Benefits (15+ Years)

Onsite Full Time

We are hiring a seasoned D365 Technical Architect with 15+ years of experience to design and lead enterprise-scale HRM Compensation & Benefits solutions within Dynamics 365 F&O/HR.

We are hiring a seasoned D365 Technical Architect with 15+ years of experience to design and lead enterprise-scale HRM Compensation & Benefits solutions within Dynamics 365 F&O/HR.

Requirements

Architect end-to-end Compensation & Benefits solutions (merit cycles, incentives, TRS, approvals) Design scalable, configurable solutions supporting multi-country and compliance requirements Lead technical design, development, and integration (X++, Azure, APIs) Define data models, workflows, and approval frameworks for compensation cycles Ensure governance, audit compliance, and pay equity controls Collaborate with functional architects to translate business requirements into robust technical designs.

Responsibilities
  • 15+ years in D365 F&O / AX technical architecture
  • Strong expertise in X++, D365 extensions, integrations, and Azure
  • Hands-on experience in full lifecycle D365 implementations, Minimum 3–5 full lifecycle D365 implementations
  • Experience in HRM Compensation & Benefits domain
  • Knowledge of compensation cycles, budgeting, and approval workflows.
  • Good to Have:
  • Experience with global HR/localization solutions
  • Power Platform, Dataverse, and analytics exposure
Like 0 comments
New job 11 Jul

D365 F&O Finance Functional Consultant

Onsite Full Time

F&O Finance FC •Having 5-10 years of experience as a D365 Finance Functional Consultant on D365 F&O Implementation projects. •Expertise on D365 F&O Finance Modules - Finance skills (functional). AP, AR, GL, VAT, Sales order, invoicing and electronic reporting, Integrations, Functional Design Docum…

F&O Finance FC •Having 5-10 years of experience as a D365 Finance Functional Consultant on D365 F&O Implementation projects. •Expertise on D365 F&O Finance Modules - Finance skills (functional). AP, AR, GL, VAT, Sales order, invoicing and electronic reporting, Integrations, Functional Design Documents FDD/IDD’s. Experience on Azure Devops for Day-to-Day for functional tasks/activities.

Requirements

5+ years into D365 F&O Finance functional consultant. Electronic Reporting AP, AR, GL, Integrations, Azure Devops, VAT, Sales order, Invoicing.

Required skills
Accounts Payable (AP)Accounts Receivable (AR)Advanced Warehouse Management (WMS)Azure DevOpsD365 FinanceD365 Supply Chain ManagementElectronic Reporting (ER)
Like 0 comments
Article 10 Jul +150 pts

Why Dynamics 365 Could Quietly Transform the EV Charging Industry

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion tha…

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion that is a missed opportunity, because the operational problems holding back charging networks today are exactly the kind of problems this platform was designed to solve. I believe integrating Dynamics 365 into the EV world would shape it in a clearly positive way, and this article explains why. The industry has an operations problem, not a technology problem EV charging has grown fast, and the software behind it has not kept up. Most operators run on a patchwork of systems. Asset records sit in one platform, fault tickets in another, contractor management in a spreadsheet, and customer support somewhere else entirely. None of these talk to each other properly. The result is familiar to anyone who has dealt with public charging. A charger goes down, nobody notices until a driver complains, an engineer is sent out with the wrong information, and the fix takes days instead of hours. Every one of these failures’ chips away at public confidence in EVs. If drivers cannot trust that a charger will work, they hesitate to switch from petrol. So poor operations are not just a cost issue, they slow down the energy transition itself. One view of the asset changes everything The core value of Dynamics 365 in this industry would be a single view of every asset. One record per charger that holds its installation details, maintenance history, fault patterns, contractor visits and customer complaints. Today that information is scattered, and decisions suffer for it. With a unified view, an operator can spot that a particular charger model fails twice as often in coastal locations, that a certain contractor closes jobs faster than others, or that a site with repeated complaints also has a grid connection issue. These insights exist in the data already, they just cannot surface when the data lives in five places. Field service is where the biggest gains sit Field work is one of the largest cost centres for any charging operator, and slow charging makes it worse. The assets are cheap and spread across hundreds of small sites, so a single wasted site visit can wipe out months of revenue from the unit it was meant to fix. Dynamics 365 Field Service brings intelligent scheduling, route optimisation, automated work orders and mobile workforce management. None of this is exotic technology but applied across thousands of chargers it changes the economics of a network. Fewer wasted visits, faster repairs, better contractor accountability, higher uptime follows, and uptime is the single metric that matters most to drivers, site hosts and councils. The path from reactive to predictive The most exciting part is what becomes possible once operations run on one platform. Chargers already produce telemetry. Combine that with maintenance history and machine learning, and failures can be predicted before they hap…
Like 0 comments
Article 8 Jul

I decorated an X++ class with an attribute — and Copilot started answering questions with my code

What actually happened The 2026 pattern for this is the "AI tool" (Microsoft's word for it — you'll also hear "AI plugin"). You write a normal X++ class, deploy it, and d…

What actually happened The 2026 pattern for this is the "AI tool" (Microsoft's word for it — you'll also hear "AI plugin"). You write a normal X++ class, deploy it, and decorate it with a couple of attributes. AIPluginOperationAttribute marks the class as something an agent is allowed to call. CustomAPIAttribute ties it to a Dataverse Custom API. Your inputs and outputs are just data contract members with plain-language descriptions: X [CustomAPIRequestParameter('The customer account number', true), DataMember('accountNumber')] public CustAccount parmAccountNum(CustAccount _accountNum = accountNum) That description string is the part I want you to notice. It's not a comment — the orchestrator actually reads it to decide when to call your action and how to fill the parameter from someone's messy sentence. You're basically writing prompt hints in your method signatures now. Weird. Kind of great. Why this matters to you and me Here's the shift. These are headless operations — no form context, no client. Once your class is deployed with the right menu-item security, the Dynamics 365 ERP MCP server picks it up automatically through its find_actions / invoke_action tools. Same code, reachable from the in-app sidecar, from a custom Copilot Studio agent, or from any agent speaking MCP. You write the logic once; the surface area is enormous. The honest catch: it's still preview, you need the unified developer environment, and there's Dataverse plumbing (the Custom API, request params, response props) plus the classic flush the cache with SysFlushAOD or nothing works gotcha that cost me twenty minutes. My takeaway: stop thinking of your X++ classes as things only a form can call. Pick one small, useful calculation you already trust — a balance, an eligibility check, a status lookup — wrap it as an AI tool, and let Copilot reach it. It's the most direct line I've found from "code I already have" to "AI that does something real."
Like 1 comment
E
Egel Pjetri 2w ago
AI is powerful
Article 6 Jul

Why Dynamics 365 Could Quietly Transform the EV Charging Industry

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion tha…

When people talk about Microsoft Dynamics 365, the conversation usually stays within CRM, sales or ERP territory. The EV industry almost never comes up. In my opinion that is a missed opportunity, because the operational problems holding back charging networks today are exactly the kind of problems this platform was designed to solve. I believe integrating Dynamics 365 into the EV world would shape it in a clearly positive way, and this article explains why. The industry has an operations problem, not a technology problem EV charging has grown fast, and the software behind it has not kept up. Most operators run on a patchwork of systems. Asset records sit in one platform, fault tickets in another, contractor management in a spreadsheet, and customer support somewhere else entirely. None of these talk to each other properly. The result is familiar to anyone who has dealt with public charging. A charger goes down, nobody notices until a driver complains, an engineer is sent out with the wrong information, and the fix takes days instead of hours. Every one of these failures’ chips away at public confidence in EVs. If drivers cannot trust that a charger will work, they hesitate to switch from petrol. So poor operations are not just a cost issue, they slow down the energy transition itself. One view of the asset changes everything The core value of Dynamics 365 in this industry would be a single view of every asset. One record per charger that holds its installation details, maintenance history, fault patterns, contractor visits and customer complaints. Today that information is scattered, and decisions suffer for it. With a unified view, an operator can spot that a particular charger model fails twice as often in coastal locations, that a certain contractor closes jobs faster than others, or that a site with repeated complaints also has a grid connection issue. These insights exist in the data already, they just cannot surface when the data lives in five places. Field service is where the biggest gains sit Field work is one of the largest cost centres for any charging operator, and slow charging makes it worse. The assets are cheap and spread across hundreds of small sites, so a single wasted site visit can wipe out months of revenue from the unit it was meant to fix. Dynamics 365 Field Service brings intelligent scheduling, route optimisation, automated work orders and mobile workforce management. None of this is exotic technology but applied across thousands of chargers it changes the economics of a network. Fewer wasted visits, faster repairs, better contractor accountability, higher uptime follows, and uptime is the single metric that matters most to drivers, site hosts and councils. The path from reactive to predictive The most exciting part is what becomes possible once operations run on one platform. Chargers already produce telemetry. Combine that with maintenance history and machine learning, and failures can be predicted before they hap…
Like 0 comments
Article 23 Jun

Maintenance Work Orders in D365 Asset Management: Scheduling, Parts, Labour, and Cost

Over the last two articles I built the asset management picture from the ground up: first the foundation of functional locations, assets, and asset types , then the preve…

Over the last two articles I built the asset management picture from the ground up: first the foundation of functional locations, assets, and asset types, then the preventive side, where maintenance plans, rounds, and triggers project a forecast of work. I kept making the same promise at the end of each one, that the work order is the thing that finally posts cost when it is ended, and I kept deferring the detail. Today I pay that debt. I want to follow a maintenance work order all the way through execution and into money: where it comes from, how it schedules against the people and the equipment, how it picks up labour hours and spare parts from the same inventory the shop floor draws on, and the exact moment the cost becomes a financial fact that finance can see. WHERE THE WORK ORDER COMES FROM A maintenance work order in Dynamics 365 has two parents. The first is preventive: the forecast I described last time generates work orders from due plan lines, so a calendar trigger or a counter reading quietly turns into a scheduled job without anyone typing it in. The second is corrective: something breaks or someone notices a problem, a maintenance request is raised, and that request is converted into a work order. Either way you land on the same object, and that is the design intent. Whether the work was planned a year out or reported five minutes ago, it flows through one consistent lifecycle so the maintenance team has a single backlog to schedule and a single place where cost accumulates. A work order carries one or more work order jobs, and each job names a job type and a trade, exactly the controlled vocabulary the plan lines use, which is why the taxonomy decisions from the foundation article keep paying off here. THE WORK ORDER LIFECYCLE The work order moves through a sequence of lifecycle states, and the states are not cosmetic. They gate what you are allowed to do and, crucially, when cost is recognised. A new order is created, then scheduled, then it goes in progress while the work is actually done, then it is completed when the technician is finished on the floor, and finally it is ended. That last transition is the one that matters financially. Until the order is ended, the hours and parts on it are estimates and commitments; they show you what the job is expected to consume and they let you plan, but they have not yet hit the ledger. Ending the order is the act that posts the real cost. I labour this point because it is the single most common source of confusion I see: people look at an in-progress order, see numbers, and assume finance has them, when in fact nothing has posted until the order reaches the ended state. Each lifecycle state is configurable, so an implementation can add intermediate states or control which user groups may move an order forward. That is useful for governance, for example requiring a supervisor to push an order from completed to ended so there is a review step before cost is committed. The principle to hold…
Like 0 comments
Article 22 Jun

Preventive Maintenance in D365 Asset Management: Maintenance Plans, Rounds, and Triggers

In my last article on the Asset Management foundation I laid out the structure that everything in Dynamics 365 Asset Management hangs from: functional locations as the st…

In my last article on the Asset Management foundation I laid out the structure that everything in Dynamics 365 Asset Management hangs from: functional locations as the stable places, assets installed into them, asset types as the maintenance taxonomy, and the work order as the thing that finally posts cost when it is ended. I closed with a promise to go a level deeper into the preventive side, and that is where I want to spend today. Preventive maintenance is the part of the module that earns its keep, because it is the difference between equipment that fails on its own schedule and equipment that gets attention before it fails on yours. I will walk through maintenance plans and maintenance rounds, the two ways preventive work is defined, how time-based and counter-based triggers actually generate a forecast of work, and how to keep that forecast from either burying your technicians or quietly drying up. WHY PLAN PREVENTIVE WORK AT ALL Corrective maintenance is reactive: something breaks, someone raises a request, a work order follows. It is necessary, but if it is all you do then your maintenance team lives in a permanent state of firefighting and your production schedule inherits every surprise breakdown as an unplanned gap. Preventive maintenance flips the timing. Instead of waiting for failure, you decide in advance that a given asset needs a given task at a given cadence, and Dynamics 365 projects those tasks into the future as a forecast you can see, resource, and schedule. The payoff is twofold: fewer unplanned outages, and a maintenance workload you can level and staff for rather than one that arrives in unpredictable spikes. The whole preventive apparatus exists to turn "we should probably service that every so often" into a concrete, dated, costed stream of work orders. MAINTENANCE PLANS: THE BUILDING BLOCKS The maintenance plan is where preventive work is defined. A plan is attached either to an asset type, so it applies to every asset of that type, or to an individual asset when something is special enough to deserve its own rules. Attaching to the asset type is the move that scales: define the plan once for "hydraulic press" and every press inherits it, which is exactly why the asset type taxonomy from the foundation article matters so much here. A plan that is too granular, written asset by asset, becomes a maintenance burden in its own right. Inside the plan sit one or more plan lines, and the line is where the real configuration lives. Each line names a maintenance job type (the controlled vocabulary I argued for last time: inspection, lubrication, calibration, replacement), the trade or worker capability the job needs, an interval that says how often, a start date that anchors the cadence, and the trigger rule that decides whether the interval is counted in calendar time or in usage. One plan can carry several lines, so a single press might have a monthly visual inspection, a quarterly lubrication, and an annual overhaul all defi…
Like 0 comments
Article 22 Jun

Asset Management in D365 SCM: Functional Locations, Assets, and the Maintenance Foundation

I am stepping sideways from master planning for a few articles, at Joni's request, into a corner of Dynamics 365 Supply Chain Management that production-heavy shops lean…

I am stepping sideways from master planning for a few articles, at Joni's request, into a corner of Dynamics 365 Supply Chain Management that production-heavy shops lean on but that gets far less airtime than manufacturing or warehousing: Asset Management, the module Microsoft used to call Enterprise Asset Management. If you run lines, presses, ovens, conveyors, or any equipment that has to keep running, this is where Dynamics 365 tracks what you own, where it sits, what condition it is in, and the maintenance work that keeps it alive. This first article lays the foundation, the structure everything else hangs from, because almost every problem I see in an Asset Management rollout traces back to the structure being rushed. WHY ASSET MANAGEMENT EARNS ITS PLACE Maintenance is the quiet partner of production. A finite-capacity schedule is only honest if the resources it schedules are actually available, and a resource that is down for an unplanned repair makes a liar of the plan. Asset Management gives you a structured way to record assets, plan preventive maintenance so failures happen less often, capture corrective work when they happen anyway, and post the cost of all that work where finance can see it. It is fully inside Supply Chain Management rather than bolted on, so a maintenance asset can be tied to the same resource your production orders consume, and the maintenance work order can draw spare parts from the same inventory your shop floor draws from. That integration is the reason to use it instead of a standalone CMMS, and it is also why getting the structure right matters: the structure is what connects maintenance to the rest of the system. THE ASSET HIERARCHY: FUNCTIONAL LOCATIONS AND ASSETS There are two foundational objects, and people constantly blur them. A functional location is a place in your operation where an asset can sit: a site, an area, a production line, a cell, a room. Functional locations are arranged in a parent and child hierarchy, so a line sits under an area, which sits under a site. An asset is the physical thing itself: the specific pump, the specific press, the specific forklift. The asset is installed at a functional location, and that relationship is the hinge of the whole module. The reason to separate the two is that places outlast equipment. A pump fails for good and you replace it; the slot on the line where it lived does not change. If you have built your history around the functional location, you can ask "how much has this position on the line cost me over five years" across every asset that has ever occupied it, and you can swap the physical asset in and out without losing that thread. Build everything around the asset alone and you lose continuity every time you replace a machine. So I model the places first, as a stable skeleton, and then install assets into them. Two settings shape the skeleton. A functional location type classifies what kind of place each node is, and the functional location structu…
Like 0 comments
Article 19 Jun

Landed Cost in D365: Voyages, Apportionment, and Inventory Valuation

A question I get from finance and operations alike is some version of "what does this item actually cost us once it is sitting on our shelf?" For domestically sourced goo…

A question I get from finance and operations alike is some version of "what does this item actually cost us once it is sitting on our shelf?" For domestically sourced goods the purchase price is close enough. For anything imported it is not, because freight, insurance, customs duty, brokerage and handling can add up to a large fraction of the product price, sometimes rivalling it. Carrying inventory at the bare purchase price quietly overstates your margin and distorts every decision downstream. Today I want to walk through landed cost in Dynamics 365: the dedicated Landed Cost module that captures these charges against a shipment, and, just as important, how that cost actually lands in your inventory valuation depending on the costing method you run. The first part is configuration; the second is where finance either trusts the numbers or does not. WHAT LANDED COST ACTUALLY MEANS Landed cost is the fully burdened unit cost of getting an item to your location and ready to sell or consume. It is the product price plus every incremental cost incurred along the way: ocean or air freight, inland haulage, marine insurance, import duty, customs brokerage, port handling, demurrage, and agent fees. The goal is simple to state and harder to do well: take all of those charges, attach them to the goods that incurred them, and spread them fairly across the units so that each unit carries its true cost. Once you have that, your inventory value is honest, your margin reporting is real, and your sourcing decisions (make versus buy, this vendor versus that one, near versus far) are made on the right numbers. THE LANDED COST MODULE: VOYAGES AND JOURNEYS The dedicated Landed Cost module in D365 is built for import-heavy operations and introduces a vocabulary worth learning. The central object is the voyage, which represents a physical shipment, typically a container or a consolidation of purchase order lines travelling together. A voyage groups the goods that share the same transport and therefore should share the same transport costs. A journey template describes the route and the legs that voyage travels (for example origin port, ocean leg, destination port, inland leg), and it carries the structure that drives which costs apply and when milestones are expected. You set up the templates once to mirror how your goods actually move, then create voyages against them as shipments happen, attaching the relevant purchase order lines. The reason this structure exists, rather than just dumping a freight charge on a purchase order, is that real import costs are incurred at the shipment level and must be apportioned down to many order lines and items. A single container might hold lines from several purchase orders; the ocean freight is one invoice for the whole box, and it needs to be split across everything inside. The voyage is the container for that logic. COST TYPES AND AUTO CHARGES Each kind of cost is defined as a cost type: freight, duty, insurance, and so on, ea…
Like 0 comments
Article 18 Jun

Firming Planned Orders in D365: Action and Futures Messages

In my last article on static and dynamic master plans I settled where master planning writes its results and why most setups run two plans. I closed with a promise to fol…

In my last article on static and dynamic master plans I settled where master planning writes its results and why most setups run two plans. I closed with a promise to follow the planned orders forward: how you turn those suggestions into real purchase and production orders, and how to read the action and futures messages that tell you what to reschedule before the warehouse ever feels it. That is today. The planned order is the most underrated object in D365 planning, because it is the hinge between a calculation and a commitment, and the habits a team builds around firming and messages decide whether planning is a tool people trust or a list they ignore. WHAT A PLANNED ORDER ACTUALLY IS A planned order is a suggestion and nothing more. When master planning runs, it nets demand against supply for each item and, where it finds a shortfall, it proposes an order to cover it: a planned purchase order for a bought item, a planned production order for a manufactured one, a planned transfer order to move stock between warehouses, or a planned kanban depending on your setup. None of these touch the real world yet. They carry no purchase order number, they place no demand on a vendor, and they consume no shop floor capacity beyond the plan. The crucial consequence of this is that planned orders are disposable. On the next regeneration the engine throws them away and recreates them from scratch, so anything you change on a planned order that you do not firm is lost. That disposability is a feature, not a flaw, but it catches people who spend an hour tidying planned orders and then watch the overnight run erase the lot. Because planned orders are tied to the plan, the question of which plan you are looking at, from the previous article, matters here. You firm from the static plan of record, not the dynamic plan, precisely because the static plan holds still long enough for the firming decision to mean something. FIRMING: TURNING A SUGGESTION INTO A COMMITMENT Firming is the act of converting a planned order into a real order. When you firm a planned production order you get an actual production order with a number, a BOM and route attached, and a real claim on capacity. Firm a planned purchase order and you get a purchase order ready to confirm and send to the vendor. The moment of firming is the moment planning stops being advisory and starts creating obligations, so it deserves a deliberate process rather than a reflex click. There are three broad ways to firm. The first is manual, one order at a time, from the planned orders list page: you review a suggestion, you agree with it, you firm it. The second is selective and batched: you mark a set of planned orders, often filtered to a buyer or a production unit or a date window, and firm them together. The third is automatic, governed by the firming time fence. Inside that fence the engine treats near-term suggestions as reliable enough to firm without a human in the loop, which is sensible for stable, fast-…
Like 0 comments
Article 17 Jun

The Master Plan in D365: Static vs Dynamic Plans and Why You Run Two

Last time I wrote about coverage groups and the core planning parameters , the per-item settings that decide how master planning turns demand into planned orders. I promi…

Last time I wrote about coverage groups and the core planning parameters, the per-item settings that decide how master planning turns demand into planned orders. I promised to keep going with master planning, and before we follow planned orders forward into firming and messages, there is a structural question worth settling: the plan itself. When you run master planning, what is it writing into, and why do almost all real setups run not one plan but two? The answer is the difference between a static plan and a dynamic plan, and getting it right is the difference between a planner who trusts the plan and one who watches it change every time someone enters a sales order. WHAT A MASTER PLAN ACTUALLY IS A master plan in D365 is two things at once. It is a named configuration, a header that carries settings about how the run behaves, and it is the container that holds the results of the run: the planned orders, the action messages, and the futures messages. So when I say "the static plan" I mean both a set of parameters and the body of suggestions sitting under it. You can have several master plans defined, and you nominate which ones play which role in the Master planning parameters. Two roles matter: the current static master plan and the current dynamic master plan. Those two nominations are the quiet decision that shapes everyone's daily experience of planning. STATIC VERSUS DYNAMIC PLANS A static plan is the plan of record. It is recalculated on a controlled schedule, typically a full regeneration in an overnight batch, and then it sits still until the next run. That stillness is the point. A planner can open the static plan in the morning, see a coherent set of planned orders, and work through them (reviewing, adjusting, firming) without the ground shifting because someone three desks away just keyed a large order. The static plan is stable precisely because it does not react to every transaction the moment it happens. A dynamic plan is the opposite by design. It updates continuously as supply and demand change, so it always reflects the very latest picture. The moment a sales order line is entered, the dynamic plan rebalances net requirements for that item. This is exactly what you want behind order entry and delivery date promising, where the business needs an up-to-the-minute answer to "if I sell this today, when can I have it." The dynamic plan is volatile, and that is fine, because nobody is firming orders from it; they are reading availability from it. WHY MOST SETUPS RUN TWO PLANS The reason two plans exist is that one plan cannot be both stable and live at the same time, and a healthy operation needs both qualities. Planners need stability to make decisions; order entry needs currency to make promises. Run a single plan and you are forced to choose which group to disappoint. There is a specific trap here that catches people. If you nominate a current static plan but leave the current dynamic plan blank, D365 will update that single stat…
Like 0 comments
Article 16 Jun

Master Planning in D365: Coverage Groups and the Core Planning Parameters

For two weeks I have been deep in the warehouse: wave templates, cycle counting, replenishment, inbound flows, and last time the mobile device menu in the operator's hand…

For two weeks I have been deep in the warehouse: wave templates, cycle counting, replenishment, inbound flows, and last time the mobile device menu in the operator's hand. I promised at the end of that article to step back from the floor and into planning, because everything the warehouse moves has to be made or bought first, and the thing that decides what to make and buy, and when, is master planning. This is the first of a few articles on it, and I want to start where the behaviour actually lives: the mobile device menu was the doorway to warehouse work; coverage groups are the doorway to planning. Get them right and the plan is sensible. Get them wrong and you spend your days explaining strange planned orders. WHAT MASTER PLANNING IS ACTUALLY DOING Strip master planning down to its core and it is a comparison. On one side it gathers demand: sales order lines, the demand forecast, transfer and production requirements, and any safety stock you have asked it to hold. On the other side it gathers supply that already exists: on-hand inventory plus open purchase, production, and transfer orders. It nets the two together, item by item and warehouse by warehouse, across the timeline, and wherever demand outruns available supply it raises a planned order to cover the gap. Those planned orders are suggestions, not commitments, until somebody firms them into real purchase, production, or transfer orders. That loop is the whole engine. What makes two companies running the same engine get completely different plans is the configuration that decides how the gap gets covered, and that configuration is mostly the coverage group. COVERAGE GROUPS: WHERE THE BEHAVIOUR LIVES A coverage group is a reusable bundle of planning settings that you attach to items so the engine knows how to treat them. You do not configure planning item by item from scratch; you build a handful of coverage groups that describe the patterns you have, then point each item at the group that fits. A fast-moving stocked component, an expensive made-to-order assembly, and a cheap consumable each want different treatment, and a coverage group is how you express that difference once and reuse it. The single most important field on the group is the coverage code, because it decides how individual requirements get grouped into planned orders and therefore how many orders you get and how much buffer they carry. THE FOUR COVERAGE CODES There are four coverage codes, and choosing among them is the first real decision you make for any item. • Requirement. The engine raises one planned order for each demand line, sized exactly to that line. This is lot-for-lot planning: the tightest possible inventory and the most orders. It suits high-value or made-to-order items where you never want stock sitting idle. • Period. The engine groups all demand that falls inside a defined period (for example a week) into a single planned order. You get fewer, larger orders and a little more buffer, which suits items w…
Like 0 comments
Article 15 Jun

The Warehouse Mobile Device Menu in D365 Advanced WMS: Menu Items and Work Classes

In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Mana…

In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Management. Menu items, work classes, and how to design handheld flows that the floor will actually use without fighting the device. Every piece of physical movement I have written about in this series, picking, replenishment, cycle counting, receiving, put-away, reaches the operator through one screen: the mobile device menu. You can have immaculate work templates and location directives behind the scenes, but if the menu the picker sees is a deep, confusing tree of half-relevant options, the floor will be slow, error-prone, and quietly inventing workarounds. The menu is where all that back-end design either becomes usable or gets in the way. WHAT THE MOBILE DEVICE MENU ACTUALLY IS The warehouse mobile device menu is the tree of options an operator navigates on the handheld, from the top-level menu down through submenus to the individual actions they tap to do a job. Each leaf in that tree is a mobile device menu item, and each menu item is a small piece of configuration that decides exactly what happens when the operator selects it. Menus can contain other menus, so you can group actions by function and keep any single screen short. The whole structure is assigned to operators through their work user setup, which means different roles can see completely different menus: a receiver does not need to scroll past picking and packing options, and a picker should not be one mis-tap away from a counting flow. Designing the menu well is mostly about two questions: what is each menu item, and how is the tree arranged. TWO MODES: WORK AND INDIRECT The single most important setting on a menu item is its mode, and there are two. A work-mode menu item drives warehouse work: it either processes work that already exists (an operator picks up directed picking or put-away work) or it creates work as the operator acts (receiving a purchase order line generates the put-away work). Work-mode items are the ones wired to the work templates and location directives I covered in the two tables that run your warehouse; the menu item is simply the doorway through which that work reaches the floor. An indirect-mode menu item is for everything that is not warehouse work: an item or location inquiry, a pause or break, a cleaning task, switching the active user. These do not create or process work; instead each maps to an indirect activity code, which is what lets you measure how much of the shift was spent off productive work. Getting the mode right is the first decision, because almost everything else about the item follows from it. The mistake I see most often is people reaching for complex configuration when the real problem is simply that an action was modelled as the wrong mode. WORK CLASSES: THE GUARD RAIL ON WORK ITEMS For a work-mode item, the work class is the setting that keeps it pointed at the righ…
Like 0 comments
Article 15 Jun

The Warehouse Mobile Device Menu in D365 Advanced WMS: Menu Items and Work Classes

In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Mana…

In my last article on inbound flows I closed with a promise to come to the device in the operator's hand: the warehouse mobile device menu in D365 Advanced Warehouse Management. Menu items, work classes, and how to design handheld flows that the floor will actually use without fighting the device. Every piece of physical movement I have written about in this series, picking, replenishment, cycle counting, receiving, put-away, reaches the operator through one screen: the mobile device menu. You can have immaculate work templates and location directives behind the scenes, but if the menu the picker sees is a deep, confusing tree of half-relevant options, the floor will be slow, error-prone, and quietly inventing workarounds. The menu is where all that back-end design either becomes usable or gets in the way. WHAT THE MOBILE DEVICE MENU ACTUALLY IS The warehouse mobile device menu is the tree of options an operator navigates on the handheld, from the top-level menu down through submenus to the individual actions they tap to do a job. Each leaf in that tree is a mobile device menu item, and each menu item is a small piece of configuration that decides exactly what happens when the operator selects it. Menus can contain other menus, so you can group actions by function and keep any single screen short. The whole structure is assigned to operators through their work user setup, which means different roles can see completely different menus: a receiver does not need to scroll past picking and packing options, and a picker should not be one mis-tap away from a counting flow. Designing the menu well is mostly about two questions: what is each menu item, and how is the tree arranged. TWO MODES: WORK AND INDIRECT The single most important setting on a menu item is its mode, and there are two. A work-mode menu item drives warehouse work: it either processes work that already exists (an operator picks up directed picking or put-away work) or it creates work as the operator acts (receiving a purchase order line generates the put-away work). Work-mode items are the ones wired to the work templates and location directives I covered in the two tables that run your warehouse; the menu item is simply the doorway through which that work reaches the floor. An indirect-mode menu item is for everything that is not warehouse work: an item or location inquiry, a pause or break, a cleaning task, switching the active user. These do not create or process work; instead each maps to an indirect activity code, which is what lets you measure how much of the shift was spent off productive work. Getting the mode right is the first decision, because almost everything else about the item follows from it. The mistake I see most often is people reaching for complex configuration when the real problem is simply that an action was modelled as the wrong mode. WORK CLASSES: THE GUARD RAIL ON WORK ITEMS For a work-mode item, the work class is the setting that keeps it pointed at the righ…
Like 0 comments
Article 14 Jun

Inbound Flows in D365 Advanced WMS: Receiving and Put-Away Directives

In my last article on replenishment I closed with a promise to turn around and face the other direction: inbound flows in D365 Advanced Warehouse Management. Purchase ord…

In my last article on replenishment I closed with a promise to turn around and face the other direction: inbound flows in D365 Advanced Warehouse Management. Purchase order and load-based receiving, license plate receiving on the mobile device, and how put-away location directives decide where received stock actually lands. Outbound gets most of the attention because it is where the orders ship, but everything outbound depends on inbound having done its job. If receiving puts stock in the wrong place, or records the wrong quantity, or leaves a license plate stranded with no put-away, then every wave, every replenishment, and every cycle count downstream is working from a lie. Inbound is the quiet half of the warehouse where inventory accuracy is either won or lost. THE TWO WAYS STOCK ARRIVES D365 gives you two main entry points for inbound stock, and the right choice depends on how much you know before the truck arrives. The first is purchase order receiving. You receive directly against the lines of a purchase order, item by item, and the system already knows what was ordered, so it can validate quantities against the expectation. This is the simplest model and it suits operations where receiving is driven straight off the PO and there is no separate advance notice from the supplier. The second is load-based receiving. Here an inbound load is created, often from an advance shipping notice (ASN) sent by the supplier, and the load carries the expected contents ahead of the physical arrival. Receiving then happens against the load rather than the raw PO. Load-based receiving is the better fit when you want to plan dock and labour around known arrivals, when one shipment spans several purchase orders, or when the supplier sends structured ASN data you want to receive against. The mental model is the mirror image of the outbound load I wrote about in the outbound wave and load strategy article: a load is just a planned container of work, and inbound loads let you treat receiving with the same discipline you give shipping. Both routes converge on the same next step. Once stock is received, the warehouse no longer cares whether it came from a PO line or a load line; it cares about the license plate that now exists and needs to be put away. THE LICENSE PLATE IS THE UNIT OF RECEIVING In Advanced WMS the license plate is the handle the whole system grabs onto. A license plate is a tracked unit of stored inventory, usually a pallet or a container, identified by a single ID that travels with the goods. When you receive, you are almost always receiving onto a license plate: the act of receiving creates or populates a plate, records the item, quantity, unit, and inventory status on it, and parks it at a receiving location. From that moment the plate is the thing that moves. Put-away work moves a plate, not a loose quantity; picking later can pull from a plate; cycle counting counts a plate. Getting the license plate right at receipt, one plate per physical p…
Like 0 comments
Article 13 Jun

Replenishment in D365 Advanced WMS: Min/Max, Wave Demand, and Load Demand

In my last article on cycle counting I promised to come back to replenishment in D365 Advanced Warehouse Management: minimum and maximum replenishment, demand-based and l…

In my last article on cycle counting I promised to come back to replenishment in D365 Advanced Warehouse Management: minimum and maximum replenishment, demand-based and load demand strategies, and how to keep pick faces stocked without burying the warehouse in unnecessary moves. Replenishment is the quiet engine behind a fast pick operation. Get it right and pickers walk short distances to locations that are always stocked; get it wrong and they either stand waiting for stock to arrive or the warehouse spends half its labour shuffling pallets that nobody needed moved. It is the same balancing act I keep coming back to in this series: the system will happily create work, and the skill is in creating only the work that earns its keep. THE PICK FACE AND THE RESERVE Almost every efficient warehouse splits storage into two roles. Bulk or reserve locations hold inventory in its most compact form: full pallets and license plates, stacked high, optimised for density rather than access. Pick faces, often fixed picking locations assigned to a specific item, hold a small working quantity at floor level where a picker can reach it quickly. Outbound picking should pull almost entirely from the pick faces, because that is where the travel is short and the work is predictable. Replenishment is simply the discipline of moving stock from the reserve to the pick face before the picker needs it, so that the fast path stays fast. Everything that follows is about deciding when that move happens and how big it is. THREE WAYS REPLENISHMENT GETS TRIGGERED D365 gives you three practical mechanisms, and a mature operation usually runs more than one of them at once. • Min/max replenishment. The workhorse for fixed pick locations. You define a minimum and a maximum quantity for the location, and a scheduled batch job tops it back up to the maximum whenever on-hand falls below the minimum. It is wave-independent: it does not care what orders are in the system, only that the pick face should never run dry. This is what keeps your high-velocity items permanently stocked. • Wave demand replenishment. Configured as a step on the wave template, this looks at the actual demand in a wave and, if the pick locations cannot cover it, creates replenishment work as part of wave processing. It is demand-based and precise: it only moves what the orders in front of you actually require. This is the safety net for items that do not warrant a permanent min/max, or for demand spikes that outrun the scheduled top-up. • Load demand replenishment. Triggered for a specific load, this stages the stock a known shipment will need ahead of releasing the work to the floor. It suits operations that plan in loads and want the pick faces primed before a big outbound run, rather than discovering shortfalls mid-wave. THE REPLENISHMENT TEMPLATE Whichever trigger you use, the rules live in a replenishment template, and it is worth understanding what that object actually does. The template defines the demand…
Like 0 comments
Article 12 Jun

Cycle Counting in D365 Advanced WMS: Thresholds, Count Plans, and Mobile Count Work

I closed the cost to complete article with a promise to come back to the warehouse: cycle counting in D365 Advanced Warehouse Management. Inventory accuracy is one of tho…

I closed the cost to complete article with a promise to come back to the warehouse: cycle counting in D365 Advanced Warehouse Management. Inventory accuracy is one of those metrics nobody talks about until it is bad, and by then every downstream process is paying for it: master planning ordering material you already have, waves releasing picks against stock that is not in the location, and month-end variances nobody can explain. A well-built cycle counting program is the cheapest insurance the module offers, and Dynamics gives you everything you need; the catch is that the pieces are scattered across half a dozen forms and only behave well together if you set them up as one system. WHY CYCLE COUNTING INSTEAD OF THE ANNUAL COUNT The traditional wall-to-wall count has three problems: it stops the operation, it is staffed by tired people counting unfamiliar stock at speed, and the accuracy it buys starts decaying the morning after. Cycle counting inverts the model: count a small slice of the warehouse continuously, with the people who work in it, while it runs. Errors get caught weeks after they happen instead of months, which means the root cause is still findable. And in most jurisdictions auditors will accept a robust cycle count program in place of the full physical count, provided you can demonstrate coverage: every item and location counted at a defined frequency, with documented variance handling. That word, demonstrate, drives a lot of the setup decisions below. THREE WAYS COUNT WORK IS BORN Everything in this process produces the same object: warehouse work of type cycle counting, queued and routed like any other work, which is why the work template and work pool plumbing I covered earlier matters here too. The differences are in the trigger. 1. Cycle count plans. The scheduled backbone. A plan holds selection criteria for locations and items, a maximum number of counts to generate per run, and the number of days that must pass before a location or item is counted again. A batch job executes the plan on its schedule and creates the work. This is the instrument that gives you provable coverage. 2. Cycle count thresholds. The opportunistic counter. A threshold watches on-hand in a location, by quantity or by percentage, and when a pick drops the location below the limit, the system creates count work for it automatically. The logic is simple economics: the best moment to count a location is when it is nearly empty, because the count takes seconds and is hard to get wrong. 3. Spot counting. The judgement call. A supervisor who distrusts a location creates count work for it directly, or a worker initiates a spot count from the mobile device. No schedule, no trigger, just suspicion, and a healthy program leaves room for it. BUILDING PLANS THAT COVER THE WAREHOUSE The classic structure is frequency by velocity. Fast-moving A items are touched constantly, so they accumulate errors fastest and earn the tightest cadence; slow C items barely move an…
Like 0 comments

New here?

Dynamics Hub is where D365 consultants and the companies that need them actually talk to each other. Jobs are free, the community is open, and the daily challenges are dangerously addictive.

Join free Sign in

Why sign in?

See who's winning the daily challenges, ask questions with your name on them, and get a feed that knows what you care about.