microsoft / microsoft/BCApps

[Event Request] Allow Extensions to Authorize Additional SII Endpoint URLs

Open
#10,968 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

missing-info Team: Finance
Dominant language
AL
Stars
683
Forks
459
Avg merge
3d 26m
Merged PRs (30d)
633

Description

Why do you need this change?

A Business Central customer that files VAT through the Suministro Inmediato de Información (SII) service of Hacienda Foral de Navarra needs to use the standard SII submission flow with the endpoints published by that tax authority.

The official Navarra SII page confirms that taxpayers filing monthly VAT returns in Navarra are required to use SII and provides separate web service endpoints for testing and production:

In Business Central 28, codeunit 10752 "SII Doc. Upload Management" calls ValidateEndpointUrl from table 10751 "SII Setup" before submitting the request. Although the endpoint URL is configurable, the validation only accepts four hard-coded AEAT base URLs.

As a result, the Navarra test and production endpoints cannot be configured without replacing or duplicating part of the standard SII submission flow. There is currently no integration event that allows partners to extend the list of trusted endpoint URLs.

Describe the request

This is the current standard code - table 10751 "SII Setup", procedure IsAllowedEndpointUrl:

procedure IsAllowedEndpointUrl(Url: Text): Boolean
var
    LowerUrl: Text;
begin
    LowerUrl := LowerCase(Url);
    if StrPos(LowerUrl, 'https://www1.agenciatributaria.gob.es/') = 1 then
        exit(true);
    if StrPos(LowerUrl, 'https://www2.agenciatributaria.gob.es/') = 1 then
        exit(true);
    if StrPos(LowerUrl, 'https://prewww1.aeat.es/') = 1 then
        exit(true);
    if StrPos(LowerUrl, 'https://prewww2.aeat.es/') = 1 then
        exit(true);
    exit(false);
end;

The procedure validates the configured URL against a fixed list of AEAT hosts. There is no way for partners to authorize an additional trusted SII endpoint while continuing to use the standard submission flow.

Could you please add an integration event similar to the following:

[IntegrationEvent(false, false)]
local procedure OnBeforeIsAllowedEndpointUrl(Url: Text; var IsAllowed: Boolean; var IsHandled: Boolean)
begin
end;

The modified procedure would look like:

procedure IsAllowedEndpointUrl(Url: Text): Boolean
var
    IsAllowed: Boolean;
    IsHandled: Boolean;
    LowerUrl: Text;
begin
    //:: --- ::: BEGIN CHANGES :: --- :::
    OnBeforeIsAllowedEndpointUrl(Url, IsAllowed, IsHandled);
    if IsHandled then
        exit(IsAllowed);
    //:: --- ::: END CHANGES :: --- :::

    LowerUrl := LowerCase(Url);
    if StrPos(LowerUrl, 'https://www1.agenciatributaria.gob.es/') = 1 then
        exit(true);
    if StrPos(LowerUrl, 'https://www2.agenciatributaria.gob.es/') = 1 then
        exit(true);
    if StrPos(LowerUrl, 'https://prewww1.aeat.es/') = 1 then
        exit(true);
    if StrPos(LowerUrl, 'https://prewww2.aeat.es/') = 1 then
        exit(true);
    exit(false);
end;

This would allow partners to subscribe to the event and provide the validation result before the standard allowlist is evaluated. When IsHandled remains false, the existing standard validation continues unchanged.

For the Navarra scenario, a subscriber would set IsAllowed and IsHandled to true only for URLs under the expected https://siihacienda.navarra.es/ base URL. The subscribing extension would remain responsible for validating the endpoint and ensuring that the target service is compatible with the standard SII message flow.

Provide an implementation (optional)
  • I will provide the implementation for this extensibility request
Updated missing information
Existing alternatives considered
  • The endpoint fields in "SII Setup" are already configurable, but ValidateEndpointUrl rejects every host outside the four hard-coded AEAT base URLs.
  • No event is currently published by ValidateEndpointUrl or IsAllowedEndpointUrl that would let an extension add another trusted tax-authority endpoint.
  • Replacing the standard SII submission flow would duplicate certificate handling, request generation, response processing, and related standard behavior solely to change the endpoint allowlist.
  • Adding the Navarra host directly to the standard allowlist would solve this specific case, but it would not provide an extension point for other trusted and compatible SII authorities. The proposed event keeps that decision in the installed extension.
Justification for IsHandled

The subscriber must be able to return true for an additional trusted URL even though the standard allowlist returns false. A notification-only event cannot change that result. An OnAfter event with var IsAllowed could also extend the result, but the proposed OnBefore pattern follows the existing override convention and allows the subscriber to complete validation without running logic that is known not to recognize the additional host.

The override is limited to the Boolean result of IsAllowedEndpointUrl; it does not bypass certificate handling, request creation, response processing, or the SII submission flow. If IsHandled remains false, the current validation executes unchanged.

Performance considerations

This validation runs when an endpoint is validated and before an SII request uses that endpoint. It is not a high-volume record-processing event, but it can run for each submission request. The intended subscriber performs only an in-memory, case-insensitive HTTPS host or URL-prefix comparison. It does not require database access, network calls, or file operations, so the expected overhead is negligible. Subscribers should avoid external calls or other expensive work in this event.

Multi-extension interaction

Multiple subscribers should follow a cooperative first-handler-wins convention:

  • If IsHandled is already true, a subscriber must exit without changing IsAllowed or IsHandled.
  • A subscriber should set IsHandled := true only when it recognizes and has fully validated the supplied URL.
  • A subscriber that does not recognize the URL must leave both values unchanged so that another subscriber or the standard validation can evaluate it.

AL event subscriber execution order is not guaranteed. If two extensions intentionally claim the same URL and return different results, their configurations are in conflict and no event signature can resolve the business ownership automatically. Such overlapping subscribers should not be enabled together; the first subscriber that handles the URL establishes the result, and later subscribers must respect IsHandled.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in table 10751 "SII Setup", procedure IsAllowedEndpointUrl, and trace its use from codeunit 10752 "SII Doc. Upload Management". Review existing integration-event conventions in the surrounding AL code, then verify that standard AEAT URLs remain accepted and that an extension can handle an additional Navarra URL without changing the standard path.

Written by the indexing model from the issue text.

Assessment

Domain
api, backend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.