web

You’re offline. This is a read only version of the page.

Dynamics 365 CommunityForums Small and medium business | Business Central, N... Why has Microsoft made...

Small and medium business | Business Central, N...

Answered

Why has Microsoft made so many of the EDocument tables and codeunits "internal"?

(1) Share

Report

Report

Posted on by SB-30050252-0

34

I do love the extensibility of BC, but sometimes I wonder if the programmers are purposely cruel to those of us who have to write extensions.

eg.

Why is this table Internal only? What is the benefit of doing that?

Pretty much makes it impossible to create a codeunit that implements "E-Document" if you want to use the data exchange definitions.

Is this an oversight or is there a good reason?

Thanks

Categories:

Dynamics 365 Business Central

I have the same question (0)

All responses Img

All responses (5)

Answers Img

Answers (1)

Verified answer

Saif Ali Sabri

2,351 Super User 2025 Season 2 on at

Like (1)

Report

Report

Why has Microsoft made so many of the EDocument tables and codeunits "internal"?

You're right to question the use of Access = Internal; in Microsoft’s E-Document (EDoc) tables like 6139 "E-Doc. Service Data Exch. Def.". It's a common point of frustration for developers working with Business Central extensibility. Here's a breakdown of the why and how to work around it.

💡 Why Did Microsoft Make These Objects Internal?

1. Encapsulation of Incomplete or Volatile Features

Many E-Document components are considered part of internal application infrastructure. Microsoft marks objects as Internal when:

The functionality is not yet stabilized.
It’s not intended for direct use or extension by partners or ISVs.
Future changes to these objects are likely, and Microsoft wants to avoid breaking your extensions.

2. Licensing & Compliance Constraints

Some E-Document features are tied to regulatory compliance or third-party services. Restricting direct access helps ensure that:

Data is handled according to compliance requirements.
The implementation stays within a validated workflow.

3. Protection Against Incorrect Usage

Allowing unrestricted access could result in:

Inconsistent or unsupported implementations.
Data corruption or invalid transmissions to external services (e.g., PEPPOL, XML providers).

🚧 Why Is This a Problem for Developers?

You’re correct that it makes writing extensions around E-Documents very hard, especially if you want to:

Read/modify definitions in table 6139.
Extend the data exchange logic.
Interact with the E-Doc flow in a custom way.

Since the table is Internal, you can't reference it directly from your own extensions. This breaks many common extensibility patterns.

✅ Recommended Workarounds

Here’s what you can do:

🔹 1. Use Public Facade Codeunits (If Available)

Check if Microsoft has provided public wrappers or facades to interact with the internal tables/codeunits. Look for codeunits like:

Codeunit 1651 "E-Doc. Management"
Codeunit 1650 "E-Doc. Data Exchange"
These may expose controlled ways to interact with the internal data.

🔹 2. Request Microsoft to Expose via AL GitHub

Microsoft tracks community requests on the AL App Extensions GitHub. You can:

Submit a request to expose this specific table or codeunit.
Include your business case and technical needs.

They often respond to partner feedback and gradually open up internals.

🔹 3. Replicate Minimal Table Structure

If your use case is read-only, you can:

Use SqlConnection via Azure Functions or OData to read internal table values externally (not best practice, but sometimes necessary).
Or define a buffer table that mimics the structure and gets populated via events.

🔹 4. Leverage Integration Events

Explore if event publishers exist on the internal codeunits. You can subscribe to these to hook into the processing pipeline without direct table access.

🧩 Is This an Oversight?

It’s not an oversight, but rather a deliberate architectural constraint. That said, Microsoft often underestimates partner needs for customization, especially in niche regulatory or EDI-heavy markets. This creates a gap between what’s technically possible and what’s officially supported.

✅ Summary

Aspect	Explanation
Why Internal?	Encapsulation, stability, compliance
Problem?	Blocks access to key E-Document functionality
Solutions	Use public facades, submit GitHub request, use integration events, or create buffer workaround
Next Step	Log a GitHub issue to expose table 6139, or use `Codeunit 1650/1651` if they cover your use case

Was this reply helpful? Yes No

SB-30050252-0 34 on at

Like (1)

Report

Why has Microsoft made so many of the EDocument tables and codeunits "internal"?

Thanks for your response, that makes some sense, but I do think they have made it difficult to extend the existing eDoc functions. I will try to use the EventSubscribers in "PEPPOL Validation" but it definitely is not a "nice code" solution.

Was this reply helpful? Yes No
Suggested answer

RockwithNav 8,335 Super User 2025 Season 2 on at

Like (1)

Report
Why has Microsoft made so many of the EDocument tables and codeunits "internal"?

Could be many reasons from MS side which we cant anticipate but for guess purpose

Yet in under dev mode and more logics to be added may be from certain regulation point of view.

For MS to make it easier for upgrade purpose.

Purposely they don't want developers to use the codeunit directly.

Blog - rockwithnav.wordpress.com/
Twitter - https://twitter.com/RockwithNav
Facebook - https://facebook.com/rockwithnav/

Was this reply helpful? Yes No
Suggested answer

Saif Ali Sabri 2,351 Super User 2025 Season 2 on at

Like (1)

Report
Why has Microsoft made so many of the EDocument tables and codeunits "internal"?

You're absolutely right — it's not a nice or clean extensibility story, especially for a system that prides itself on being extensible like Business Central.
The PEPPOL Validation codeunits (like Codeunit 1657 "PEPPOL Validation") do expose some events, but the structure is tightly controlled, which means you end up writing indirect logic that feels like a workaround rather than a supported integration.

🔧 Some Practical Tips for Working with PEPPOL and E-Doc Logic
Here are a few practical suggestions that may help make the most of what's available:
✅ 1. Check for Protected Procedures
Even though objects are Internal, sometimes they contain protected procedures or events that you can still subscribe to. Review PEPPOL Validation and related codeunits to see what hooks are actually usable.
✅ 2. Use Available Events in E-Document Flow
Key places to look for event subscribers:

Codeunit 1651 "E-Doc. Management"

Codeunit 1652 "E-Doc. Document Handling"

Codeunit 1650 "E-Doc. Data Exchange"

Some of these contain integration events like:
al
CopyEdit
[IntegrationEvent(false, false)]
local procedure OnBeforeSendDocument(...)
You can use these to inject or alter behavior at specific points.
✅ 3. Consider Wrapping Calls via Your Own Service Layer
If you have to use the functionality but can’t directly access tables/codeunits, consider creating:

A wrapper codeunit that handles interaction with facades or events.

An interface pattern where you implement custom logic cleanly, even if the internal logic isn't clean.

📢 Submit GitHub Issues Anyway
Even though you’ve found workarounds, definitely open a request on GitHub. Microsoft has responded to many partner requests to remove Internal restrictions in recent releases (especially in baseapp).
Here’s the repo:
👉 https://github.com/microsoft/ALAppExtensions/issues
Make it specific:
"Expose table 6139 E-Doc. Service Data Exch. Def. or provide a public method to retrieve exchange definitions by name/type. Needed for extending PEPPOL integrations."

Final Thought
You’re not alone — many partners struggle with this “internal lock-in” problem in areas like e-Invoicing, banking integrations, and DMS connectors. It’s not ideal, but with creative use of events, wrappers, and GitHub pressure, you can usually get there without unsupported hacks.

Was this reply helpful? Yes No
Suggested answer

Ramesh Kumar 7,511 Super User 2025 Season 2 on at

Like (1)

Report

Why has Microsoft made so many of the EDocument tables and codeunits "internal"?

Totally valid frustration but I think its Preserve upgrade safety and Hide unstable or low-level implementations but they might not aware of its impact E-Document + Data Exchange Definitions, where access to certain core tables (like DataExch, E-Invoice, etc.)

Thanks, Ramesh

If this was helpful, please check the "Does this answer your question?" box and mark it as verified.

Was this reply helpful? Yes No

Join the conversation

Helpful resources

News and Announcements

Join experts in person to explore low code and AI agents at the Power Platform Community Conference sponsored by Microsoft

Quick Links

Leaderboard > Small and medium business | Business Central, NAV, RMS

#1

Rishabh Kanaskar 4,232

#2

Nimsara Jayathilaka. 2,863

#3

Sumit Singh 2,819

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans