Files
vssa-clients/references/cvp-is-organization-route.md
T
jarvis-at-skic fd33a2144a
Validate skill / validate (push) Successful in 7s
feat: publish vssa-clients skill
2026-08-14 12:10:47 +00:00

8.9 KiB

CVP IS organization-first procurement discovery

Use this route as an additional discovery path for Lithuanian public-procurement evidence. It is not a complete procurement history.

Validated route

  1. Open https://viesiejipirkimai.lt/epps/viewOrganisations.do and search the exact client legal name, then former-name and abbreviation variants where needed. The live organization form uses POST /epps/viewOrganisations.do with lowercase field names, including within=template.group.ca, name=<exact legal name>, and optional shortName, city, and street; preserve the session cookie and normal referrer when reproducing the form request. Do not invent a GET query parameter or capitalize name from the input element's id="Name". If a byte-exact authoritative name yields no row, retry only bounded typography/legal-form variants such as removing Lithuanian quotation marks or using the portal's likely AB, VšĮ, or expanded legal-form rendering. Record which query matched.
  2. Identity-check the returned legal name and available profile details. Parse complete organization-result table rows and bind each displayed legal name to the prepareViewCAOrganisation.do?id=... link in that same row. Do not collect every profile link from a wide HTML context and then substring-match the query: one result page or surrounding fragment can contain multiple organization/profile links, producing a false “exact” match or an ambiguous pair. Preserve the query variant, portal-displayed organization name, registration number/domain when available, and organization ID. If an exact-name query still yields multiple distinct exact rows, keep the identity unresolved until registration number, domain, or another authoritative identifier distinguishes them; never select the first result. A variant match is discovery only until reconciled with the authoritative client identity. Treat near-identical domains as a collision risk: open the homepage and corroborate its institution name/contact domain against the CVP IS profile before using any system link found there.
  3. Open https://viesiejipirkimai.lt/epps/prepareViewCAOrganisation.do?id=<organizationId>.
  4. Extract the real target of PERŽIŪRĖTI VISUS PASKELBTUS SKELBIMUS. It has the shape: https://viesiejipirkimai.lt/epps/notices/viewPublishedNotices.do?authorityId=<authorityId>&orgGroupId=<orgGroupId>
  5. Read both IDs from that link. Never assume they match or derive one arithmetically.
  6. Review all result pages, preferably at the largest supported page size. The live list exposes pagination through a query key shaped d-<table-id>-p=<page>; derive the exact key and last-page value from the returned page's own navigation or writePageSelection(...) call rather than hard-coding the observed table ID. Preserve title, notice type/stage, status, language, upload date, and publication date.
  7. Parse each HTML table row as a record. The notice type is commonly an anchor in the first cell, while the procurement title is plain text in the second cell—not an anchor. Therefore, anchor-text extraction alone can falsely report zero IT candidates even when a relevant title is visible. Extract and normalize all cells, keep the first-cell attachment URL, then keyword-filter the second-cell title.
  8. Open promising notice-type links. They can be forced PDF attachments rather than HTML pages.

Direct PDF behavior

A notice link commonly has this form:

viewPublishedContractNotice.do?resourceId=<id>&documentId=<id>&noticeType=<id>&extId=<uuid>&lang=lt&noticeId=<id>&isNational=false

Browser navigation may report ERR_ABORTED because the response is a download. This is not evidence of failure. Fetch the exact URL directly and verify:

  • HTTP success;
  • Content-Type: application/pdf;
  • non-trivial size;
  • %PDF- header;
  • extractable text, or OCR when it is scanned.

Preserve organization ID, authorityId, orgGroupId, resourceId, documentId, noticeId, noticeType, extId, procedure identifier, exact title/authority, dates, status, direct URL, supporting quotation, and access date.

Evidence semantics

Classify the PDF from its body, not from the filename or result snippet:

  • market consultation/RFI → planned scope and market engagement only;
  • tender/RFP/technical specification → intended procurement only;
  • supplier offer → bid only;
  • award notice or signed contract → selected supplier and bounded contractual role;
  • amendment → only the change stated;
  • implementation, production use, hosting, and acceptance/completion each require their own direct evidence.

An award that covers multiple explicitly named information systems can support one observation row per materially distinct system even when the systems share one lot and supplier. Keep the shared contract value and role clearly scoped to the joint award—do not imply that the full value belongs independently to every row. Bootstrap unknown canonical lifecycle-analysis entries for each new stable system identity before running strict registry validation; then keep hosting, original kickoff, and latest production release unknown unless separately evidenced.

For an award PDF, extract the exact buyer and system title, procedure identifier, winner, contract value, winner-selection date, contract-signature date, duration when stated, and subcontracting fields. If the body explicitly names a subcontractor together with its share or value, record that entity separately as a subcontractor, not as a co-winner, generic contractor, or inferred implementation partner. Preserve the award's own legal-entity spelling in the evidence record, then reconcile it conservatively with the existing contractor registry before creating a new identity. Do not treat an award's signature date or service duration as system kickoff, production release, acceptance, completion, or hosting evidence.

Map a notice to a canonical system only when it explicitly names the system/acronym or the scope is otherwise unambiguous. Similar IT terminology is insufficient.

Confirmed examples and pitfalls

  • A validated exact-name search can identify an organization even when external search is poor: organization 3350 exposed authorityId=3350 and distinct orgGroupId=3432. This reinforces that both IDs must come from the profile link, not arithmetic or equality assumptions.
  • An exact organization match and an opened notice list can legitimately yield no relevant IT procurement. Record the checked IDs and negative outcome for rotation continuity, but do not add a dossier row or claim procurement coverage; the organization route is incomplete.
  • When rotating several organizations, preserve each exact organizationId and the profile-derived (authorityId, orgGroupId) pair in the durable rotation log—even when the notice scan yields no claim. This gives the next run a reproducible identity checkpoint without converting discovery metadata into dossier evidence.
  • If an exact authoritative organization name returns no byte-exact result, state that explicitly and do not force a near-name profile. Continue bounded legal-form/former-name checks and direct system/procurement routes; absence from the organization search is not evidence that the organization has no procurement history.
  • Organization/profile IDs and group IDs can differ (for example, authorityId=1297, orgGroupId=1298).
  • Organization notice lists may contain hundreds of records and include unrelated purchases; scan exact system names/acronyms plus IT terms, then open candidates.
  • One organization can expose separate canonical systems in adjacent notices. Do not merge them merely because the same authority procured both.
  • The organization list may omit predecessor organizations, parent-authority purchases, older migrations, contracts, amendments, or other procurement stages. Continue direct procurement searches and former-name checks.
  • Award and tender notices with the same title are distinct evidence objects. Open both; do not infer the award supplier from the tender.
  • A directly extracted award PDF can bind a public-facing portal label to a formal backend name and bounded supplier role. Preserve both labels rather than silently renaming the client observation. For example, the title may say only “Informacinio portalo palaikymas ir vystymas” while the body explicitly scopes the work to a named information system's portal, states the contract duration, winner, value, and signature date. Use the client page to retain the public service label and the award body to state the formal system scope and maintenance/development role. This still does not prove production hosting, original development, or release dates.
  • When a command-line PDF extractor is unavailable, use an isolated dependency invocation such as uv run --with pymupdf python ... and verify the downloaded file begins with %PDF-, has non-trivial size, and yields text before relying on it. This is a portable extraction fallback, not a reason to weaken document classification.