Ali Raza Zaidi

A practitioner’s musings on Dynamics 365 Finance and Operations

Blog

A Model with the same name already exists in the Metadata Store

by

I learned a tough life lesson—greatness isn’t about doing big things. True greatness lies in doing small things with excellence.

Haha, this sounds familiar! I remember reading a quote from Napoleon Hill:

“If you cannot do great things, do small things in a great way.”

So here is small tip from my Personal Knowledge Management

I was importing a model to dev environment to built a common package for deployment. I found following error,

A Model with the same name already exists in the Metadata Store. Please delete the existing model if you want to install this model.

So I need to delete existing one and then import it again through command line

k:\AOSService\PackagesLocalDirectory\bin\ModelUtil.exe -delete -metadatastorepath=k:\AOSService\PackagesLocalDirectory -modelname="RanjahJogi"

After you can import model in some temp table in c drive.

k:\AOSService\PackagesLocalDirectory\bin\ModelUtil.exe -import -metadatastorepath=k:\aosservice\packageslocaldirectory -file=c:\temp\RanjahJogi.axmodel

Service Item with Stocked Item Model

by

I conducted an experiment to see what happens when we create a service item but select the item group as stocked.

To test this, I created an item called “Service 101” using the FIFO model, which is typically used for stocked items.

Next, I purchased it as a normal item.

When I checked the inventory transactions, I noticed that transactions were recorded—this happened because the FIFO item model treats it as a stocked item.

Inventory transactions

Why would we need such an item?

If we define an item as a service and assign it to a non-stocked item group, it means we can use it as a service charge—either as a service received or provided to a customer. In this case, no inventory transactions would be recorded.

However, in production orders, when defining the Bill of Materials (BOM), there are certain non-physical costs (such as floor charges) that need to be accounted for. The problem is that BOM does not support service items.

To work around this, we need to create a service item using a stocked item model, ensuring that it can be included in BOM calculations while still serving its intended purpose as a service-related charge.

BRD, Requirement Register, Fit GAP, FDD, TDD

by

1. BRD (Business Requirements Document):

  • Purpose: Captures high-level business requirements and objectives. It focuses on what the business needs, not how to implement it.
  • Key Components:
    • Project objectives and scope
    • Business processes to be supported by the ERP
    • Functional requirements (features and capabilities needed)
    • Non-functional requirements (performance, security, compliance)
    • Stakeholder roles and responsibilities
  • Audience: Business stakeholders, project sponsors, and the implementation team.

2. Requirement Register:

  • Purpose: A detailed log of all requirements gathered during the project. Acts as a central repository for tracking requirements throughout the ERP lifecycle.
  • Key Components:
    • Unique ID for each requirement
    • Description and category (functional, non-functional, technical)
    • Priority (high, medium, low)
    • Status (proposed, approved, implemented, tested, etc.)
    • Ownership (who requested and who is responsible)
  • Audience: Project managers, business analysts, and the implementation team.

3. Fit-GAP Analysis:

  • Purpose: Assesses how well the ERP system’s out-of-the-box features match the business requirements. Identifies gaps that need customization or process changes.
  • Key Components:
    • Fit: Requirements that the ERP system meets without modification.
    • GAP: Requirements that need customization, integration with other systems, or process adjustments.
    • Recommendations for handling gaps (customization, workaround, process change).
  • Audience: Functional consultants, business analysts, and decision-makers.

4. FDD (Functional Design Document):

  • Purpose: Provides a detailed description of how the business requirements will be implemented functionally in the ERP system.
  • Key Components:
    • Functional workflows and use cases
    • Screen layouts, fields, and user interactions
    • Business rules and validations
    • Integration points with other systems
  • Audience: Functional consultants, developers, and QA teams.

5. TDD (Technical Design Document):

  • Purpose: Describes the technical implementation details for the requirements specified in the FDD. Focuses on how to build the solution technically.
  • Key Components:
    • System architecture and data models
    • Detailed specifications for customizations (code, scripts, reports)
    • Database schemas and API details
    • Security and compliance considerations
  • Audience: Technical consultants, developers, and system architects.

Summary:

  • BRD: What the business needs.
  • Requirement Register: Tracks all requirements.
  • Fit-GAP: Matches requirements with ERP capabilities.
  • FDD: Functional solution design.
  • TDD: Technical implementation plan.

Simple PKM with Obsidian

by

Hello friends, welcome to this video!

In this video, I’m sharing a simple Personal Knowledge Management (PKM) System in Obsidian. It consists of three main folders:

1. Inbox

This is where all your notes are initially stored—whether it’s your daily journal, work-related notes, ideas, or anything else you capture throughout the day.

2. MOC (Map of Content)

This folder contains Table of Contents (TOC) notes—a central hub where all notes related to a specific category are linked. Think of it as a gateway to easily access and organize your knowledge.

3. Specific Folders

Once a note is finalized, it gets moved into a relevant category folder. Examples include D365, Excel, and Consulting—but you can create folders based on your own needs.

This is my simple yet effective PKM system in Obsidian. I hope you find it helpful!