You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an issue with this case when eSender also acts as a contracting authority. If we create just one organization node, this validation rule prevents such situation:
<svrl:failed-assert id="BR-OPT-00300-0254" location="/cn:ContractNotice" test="every $sps in cac:ContractingParty/cac:Party/cac:ServiceProviderParty/cac:Party/cac:PartyIdentification/cbc:ID/normalize-space(text()) satisfies not($sps = cac:ContractingParty/cac:Party/cac:PartyIdentification/cbc:ID/normalize-space(text()))" role="ERROR" xmlns:svrl="http://purl.oclc.org/dsdl/svrl">
svrl:textA buyer can not be a service provider</svrl:text>
<svrl:diagnostic-reference diagnostic="ND-Root_OPT-300-Procedure-Buyer" see="field:OPT-300-Procedure-Buyer">
svrl:textcac:ContractingParty/cac:Party/cac:PartyIdentification/cbc:ID</svrl:text>
</svrl:diagnostic-reference>
</svrl:failed-assert>
In case when we create two organizations with same Company ID, then (OFC) another validation kicks in requiring to have unique company IDs.
We created a workaround in this case, but please try to solve it in the future versions.
P.S. Additionally the same eSender will surely act as tenderer in some other future procurements (where they will also be eSenders), so please keep in mind also this scenario.
KR,
Dean
The text was updated successfully, but these errors were encountered:
In Belgium we had the same problem. Our organisation is the national TED eSender, but at the same time it (or certain other divisions within our org) can act as a contracting authority.
We "solve" it by creating two organisations with two different company IDs. The CA org uses the regular VAT number from the national business registry as company ID, whereas the eSender org uses our TED account identifier ("eSender ID") as company ID.
Hi,
SDK v1.10
We have an issue with this case when eSender also acts as a contracting authority. If we create just one organization node, this validation rule prevents such situation:
<svrl:failed-assert id="BR-OPT-00300-0254" location="/cn:ContractNotice" test="every $sps in cac:ContractingParty/cac:Party/cac:ServiceProviderParty/cac:Party/cac:PartyIdentification/cbc:ID/normalize-space(text()) satisfies not($sps = cac:ContractingParty/cac:Party/cac:PartyIdentification/cbc:ID/normalize-space(text()))" role="ERROR" xmlns:svrl="http://purl.oclc.org/dsdl/svrl">
svrl:textA buyer can not be a service provider</svrl:text>
<svrl:diagnostic-reference diagnostic="ND-Root_OPT-300-Procedure-Buyer" see="field:OPT-300-Procedure-Buyer">
svrl:textcac:ContractingParty/cac:Party/cac:PartyIdentification/cbc:ID</svrl:text>
</svrl:diagnostic-reference>
</svrl:failed-assert>
In case when we create two organizations with same Company ID, then (OFC) another validation kicks in requiring to have unique company IDs.
We created a workaround in this case, but please try to solve it in the future versions.
P.S. Additionally the same eSender will surely act as tenderer in some other future procurements (where they will also be eSenders), so please keep in mind also this scenario.
KR,
Dean
The text was updated successfully, but these errors were encountered: