Recurring D365 Requirements, Bundled in JGS Agile Package

Sit in on D365 implementation project meetings and you keep hearing the same requirements.

“We want to register a partner that is both a customer and a vendor in one go.”
“Please make changes to main accounts or items go through approval.”
“We want to see order lines in one list, without opening each order.”

The companies differ, but similar requirements come in every time. Even so, on every project we analyze the requirements again, check what standard features can cover, and then design and develop whatever is missing.

JGS analyzed these recurring requirements, developed the extensions they need on top of the standard features of Microsoft Dynamics 365 Finance & Operations (D365 F&O), and assembled them as JGS Agile Package.

This post explains why we built the package, how it relates to standard features, and what changes in an actual implementation. The individual features are covered one by one from the next post onward.

Why is it needed?

In an ERP implementation, a gap generally means a difference between the customer's business requirements and the ERP's standard features that needs an additional solution. The recurring requirements JGS has seen across implementation projects fall into three broad groups.

1. Features that reflect Korean business practice: validating the business registration number (the tax ID every Korean business holds), an inventory movement ledger organized by opening, receipts, issues and closing, separate debit and credit columns in Korean won, and other features Korean companies often ask for in daily work.
2. Control over master data changes: a process in which creating or changing key master data, such as main accounts or items, goes through review and approval by the people responsible.
3. Unified line-level inquiry: seeing data from different business documents, such as orders, receipts, shipments and journals, in one line-based list instead of opening each document header.

The package also includes other features that come up for review again and again during implementations, such as number sequence templates, costing setup, and fixed asset split and disposal. Features built on a newer concept, such as the menu editor, public API integration and dashboards, will be introduced in separate posts.
This is not to say that standard D365 cannot handle any of these requests.
Use standard wherever it solves the problem, and extend only where an additional feature is needed.
That is the basic direction of JGS Agile Package.

What standard D365 F&O covers and what needs additional development

Before developing the package, we first review whether standard features, configuration or a change in the business process can solve the requirement. D365 already has a wide range of master data management features, number sequences, security management and workflow.

For example, in the global address book a single party can hold both the customer role and the vendor role. And for business processes that standard workflow supports, features such as approval, rejection, delegation and notification are available.

JGS reused these standard features as much as possible.
The question is what happens when an actual project brings requirements for additional features.

• A unified page that registers the customer and the vendor together from one entry and links the information they need
• Applying company-specific approval rules to the creation and change of specific master data, such as main accounts and items
• Seeing the line data of many orders together with their header information in one list

For requirements like these, the scope that standard features alone can meet has to be separated from the scope that needs additional implementation. Master data approval in particular is designed to supplement D365's workflow and change management features after reviewing how far they apply, to fit the target master data and each company's control requirements. For unified line-level inquiry, we could not find a standard page that meets the whole requirement within the business scope JGS analyzed, so it was developed as an extension.

Analysis status as of October 12, 2026
The package currently manages 25 gaps in total.
Broken down into detailed requirement elements, they come to 297, classified during analysis and design as follows.

Classification	Requirement elements
Met by standard features	68
Partly met by standard features	51
Needs extension development	143
Standard behavior to be confirmed further	35
Total	297

The 35 items still need further confirmation of standard behavior, so their final classification may change. The result of separating what standard can solve from what needs additional development is reflected in the package's analysis and design documents.

How the implementation process changes

What is different when JGS Agile Package is applied, compared with a conventional project?
The key is to increase the share of analysis, design, development and testing work, repeated on every project, that can be reused in common.

1. Analysis: reuse common requirements.
Until now, inquiry criteria, validation rules and approval targets had to be defined again in meetings, and the scope that standard features could cover had to be reviewed as well. With the package, the documented requirements and the standard feature review results become the starting point. On that basis, the work focuses on the differences between the company's business requirements and the existing analysis.

2. Design: reduce repeated design work.
Common pages, processing rules and security design reuse the existing design documents.
The team sets the values and roles that fit the company's business, and designs only the requirements that differ from the existing design.

3. Development: reuse common features.
Instead of developing similar pages and processing logic from scratch on every project, the features included in the package are applied and the necessary settings are configured. Where a company's requirement goes beyond the package's scope, the difference is reviewed and additional development is focused on that part.

4. Testing: use predefined verification criteria.
The acceptance criteria (the conditions for accepting a feature as done) and test cases written earlier serve as common verification material. Company-specific settings, integrations with external systems and additional development still get their own supplementary test cases and verification.

Operation and updates are different too.
JGS Agile Package is built with extensions and does not modify Microsoft's standard source code directly. Compared with the older approach of changing standard code, this helps reduce code conflicts and the maintenance burden when the version is updated. Of course, using extensions does not make updates impact-free. Compatibility checks and regression testing for each new version are still needed. JGS plans to carry out this verification systematically as well, by reusing the predefined test cases.

Expected benefits

1. Less repeated analysis of common requirements
As of October 12, 2026, the following analysis materials have been prepared.

• 110 requirements
• 660 business rules
• 1,892 acceptance criteria

A new project can review common requirements against these materials and confirm what differs for that company.

2. Company-specific requirements handled through configuration
Items that can vary from company to company, such as type classifications, approval groups, number formats and whether a feature is enabled, are designed to be managed through setup pages and parameters where possible.
Within the configuration scope built in advance, a company's requirement can be met without changing code.

3. An extension structure that keeps standard features
The features are added as extensions without changing D365 standard source code directly. This structure makes the most of standard features while extending the parts the business needs.

4. Reuse of design and test assets prepared in advance
Along with the design materials, 1,021 test cases are currently prepared.
Of these, 105 are regression test cases, and the test cases as a whole cover 21 of the gaps.
For the remaining gaps and each company's additional requirements, verification materials need to be supplemented to fit the scope.
We expect this preparation to reduce the scope that has to be newly analyzed and developed, and to help predict the workload and verification scope early in a project.

So how much shorter will an implementation be?
It is still too early to state a specific reduction in time or a ratio.
We are currently in the internal development and testing phase, and not enough performance data has built up from applying the package repeatedly to actual customer projects. Even so, because common requirements, design, developed features and test cases can be reused, we expect the potential to reduce implementation time and effort. Once results from actual projects are available, we will share the actual time saved and the ratio in numbers.

Progress so far and what comes next

As of October 12, 2026, the 25 gaps of JGS Agile Package have finished the work in their currently planned development scope and are in the test phase. No feature has received a final test pass verdict yet. Analysis of the 35 items set aside for further confirmation of standard behavior is also being supplemented. The package is updated continuously, and the figures and status in this post are as of October 12, 2026.

Starting next week, we will introduce individual features every Monday.
The first feature is unified customer and vendor registration together with the unified transaction inquiry.
We will start by explaining why the feature is needed, how far standard D365 goes, and how the actual work changes when the JGS package is applied.
For features that have completed testing, we will also share the actual pages and the test results.

Who it is for

• Companies implementing D365 F&O for the first time or moving from AX 2012 that need master data management and inquiry features suited to Korean practice
• Companies that want to apply an approval process to the creation and change of key master data, such as main accounts and items
• Finance and logistics teams that gather transaction line data scattered across several pages into Excel to compare it

What would change if, instead of developing recurring requirements from scratch on every ERP implementation, you could reuse features and design materials that have already been reviewed?
JGS is testing that possibility through actual development and testing.
If you have similar requirements in a D365 implementation or enhancement, please feel free to contact us.

JGS Consulting: designing the future of your business.

한국어버전은 네이버 블로그에서 보실 수 있습니다: blog.naver.com/jgsconsulting