Skip to content
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

Open
DeanFirkelj opened this issue Mar 7, 2024 · 2 comments
Open

A buyer can not be a service provider #856

DeanFirkelj opened this issue Mar 7, 2024 · 2 comments
Assignees
Labels
validation Related to notice validation.

Comments

@DeanFirkelj
Copy link

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

@YvesJo
Copy link
Contributor

YvesJo commented Mar 8, 2024

Hi,
Thanks for reporting this, we'll remove the constraint on the e-Sender

@YvesJo YvesJo added the validation Related to notice validation. label Mar 8, 2024
@YvesJo YvesJo self-assigned this Mar 8, 2024
@mdewinne
Copy link

mdewinne commented Mar 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
validation Related to notice validation.
Projects
None yet
Development

No branches or pull requests

3 participants