-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A buyer can not be a service provider #856
Comments
Hi, |
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: