[Event Request] Allow Extensions to Authorize Additional SII Endpoint URLs
Nobody has claimed this yet.
- 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:
- Test:
https://siihacienda.navarra.es/SII_PRUEBAS.proxy/SiiMensajesXsdHandlet.ashx - Production:
https://siihacienda.navarra.es/SII_PRODUCCION.proxy/SiiMensajesXsdHandlet.ashx - Official source: Suministro Inmediato de Información del IVA (SII) - Gobierno de Navarra
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
ValidateEndpointUrlrejects every host outside the four hard-coded AEAT base URLs. - No event is currently published by
ValidateEndpointUrlorIsAllowedEndpointUrlthat 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
IsHandledis alreadytrue, a subscriber must exit without changingIsAllowedorIsHandled. - A subscriber should set
IsHandled := trueonly 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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