Handle failure to manually create E-Document from posted doc with no …

[georgepomazkov]

Fixes message 'The e-document has been created.' being shown to user when the e-document was not in fact created.

What & why

In cases when the e-document could not be manually created from a posted document page with no explicit error, the system would still tell the user that 'The e-document has been created.'.

The fix implements propagating the result of creating E-Document back to the calling procedure CreateEDocumentFromPostedDocumentPage() which returns true if the e-document was created and false otherwise, in which case message 'The e-document could not be created.' is shown to user.

Linked work

Fixes #8181

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required ΓÇö be specific: scenarios, commands, screenshots for UI changes)

Manually tested the case for posted sales invoice described in the issue, the system showed the following message when the e-document was not created due to the document type not being supported by the E-Document Service and no explicit error being thrown.

Risk & compatibility

None.

Fixes AB#636180

[georgepomazkov]

@microsoft-github-policy-service agree

[Groenbech96]

Minor, otherwise great change.

[Groenbech96]

Would be possible to return a bool from the CreateEDocumentFromPostedDocument.
Then exit(EDocumentSubscribers.CreateEDocumentFromPostedDocument(PostedRecord, DocumentSendingProfile, DocumentType)).

Less load, since we have the information inside the function call.

[georgepomazkov]

Done in 149fa44

[Groenbech96]

@copilot Please pull main into this branch.

[Groenbech96]

@copilot Fix the merge conflict

[Groenbech96]

@copilot Fix the merge conflict

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Workflow misconfiguration shown as creation failure

When GetServicesFromEntryPointResponseInWorkflow returns false (no E-Document services on the workflow entry point), the call chain returns false and every page extension shows 'The e-document could not be created.' This is a setup/configuration issue, not a creation failure, so the message is misleading and unhelpful to the user.

Recommendation:

• Return a more specific error or raise an informative Error() call when no services are found in the workflow, e.g. 'No E-Document services are configured for the active workflow. Please check E-Document workflow setup.'

Suggested change

	exit(false);
	if not EDocWorkFlowProcessing.GetServicesFromEntryPointResponseInWorkflow(WorkFlow, EDocumentService) then begin
	// Optionally log or raise a specific error so the user can diagnose the configuration issue
	exit(false);
	end;

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟠\ High\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

False return when E-Doc already exists misleads user

When an E-Document already exists for the record and AllowReExport is false, CreateAndExportEDocument returns false. The page extensions propagate this all the way to Message(EDocumentNotCreatedMsg), so the user sees 'The e-document could not be created' even though the document was previously created successfully.

Recommendation:

• Distinguish between 'E-Document already exists' and a genuine creation failure. Return a dedicated status or check for an existing E-Document before calling CreateEDocumentFromPostedDocumentPage, and show an informational message like 'An e-document already exists for this record.' instead.

if not EDocument.FindFirst() then
    CreateEDocumentRecord(EDocument, DocumentHeader, EDocumentType, WorkflowCode, DocumentSendingProfileCode, SupportedServices)
else begin
    if not AllowReExport then
        exit(false);  // Caller should check for existing E-Document and show appropriate message
    PopulateEDocument(EDocument, DocumentHeader);
    EDocument.Modify();
end;

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

New label missing Comment attribute for translation

The EDocumentNotCreatedMsg label is added without a Comment attribute. In Business Central, the Comment field on a Label is used by translators to understand the context; omitting it reduces translation quality and violates the AL coding guidelines for translatable strings.

Recommendation:

• Add a Comment attribute describing context for translators, consistent with similar labels in the codebase.

EDocumentNotCreatedMsg: Label 'The e-document could not be created.', Comment = 'Message shown when creating an e-document from a posted document page fails.';

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

New label missing Comment attribute for translation

Same as the analogous label in EDocIssuedFinChargeMemo: EDocumentNotCreatedMsg is declared without a Comment, reducing translation quality across all eight affected page extensions.

Recommendation:

• Add Comment = 'Message shown when creating an e-document from a posted document page fails.' to EDocumentNotCreatedMsg in all eight page extension files.

EDocumentNotCreatedMsg: Label 'The e-document could not be created.', Comment = 'Message shown when creating an e-document from a posted document page fails.';

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Unsupported document type shows vague creation error

When SupportedServices.Count() = 0 (no configured service supports this document type), the function returns false and the page shows 'The e-document could not be created.' The root cause—no service supports the document type—is not communicated to the user.

Recommendation:

• Raise a specific error before returning false so the user understands why creation is not possible, e.g. 'No E-Document service supports this document type.'

if SupportedServices.Count() = 0 then begin
    // Consider: Error('No E-Document service is configured to support this document type.');
    exit(false);
end;

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

Bare exit in Boolean procedure triggers error message

exit; (without a value) in an AL Boolean-returning procedure implicitly returns false. If PostedRecord.IsRecord() is false, the procedure returns false and all page extensions show 'The e-document could not be created.' This edge case previously exited silently; now it misleads the user.

Recommendation:

• Return early with no message when the record variant is invalid, or validate the variant before calling this procedure.

Suggested change

	EDocumentSubscribers.CreateEDocumentFromPostedDocument(PostedRecord, DocumentSendingProfile, DocumentType);
	if not PostedRecord.IsRecord() then
	exit(false); // Document not applicable; caller should guard before invoking

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}