# Romanian public procurement (SEAP/SICAP) > Romanian public procurement as it is published day by day in SEAP/SICAP, down to the line items and the signed contracts. Four families of summary row: the finalised direct awards, the DA award notices that announce the direct purchases made OUTSIDE the electronic catalogue and appear nowhere else, the contract notices that open a tender and the award notices that close one. Underneath each of them is the detail that makes the spending answerable rather than merely countable: the catalogue lines a direct award actually bought, with their unit prices and quantities; the contracts actually signed under an award notice, each with its winning operators, their fiscal codes and their addresses; and the lots a procurement was competed in, advertised and awarded, cancellations included. The contracting authority and the supplier are split into a fiscal code and a name so a join is an equality rather than a text search, the CPV code is split into code, label and division, and every amount is an exact decimal. The source caps any query at 2000 rows, so a day is split recursively — by CPV category, contract type and acquisition state — until each piece fits, and the coverage table records exactly what was reached and what was not. - Dataset id: `sicap-procurement` - Update cadence: daily - Upstream source: https://e-licitatie.ro/pub - Tags: romania, procurement, public-spending, contracts, tenders, government, transparency, anap, sicap, seap, cpv - Current version: ingest `01M599ZAHW4YP8VH5DQ5QHJR1T`, snapshot 2026-10-19, generated 2026-10-19T05:31:28.647Z ## Licence and attribution - Licence: Romanian official acts and public-interest information — outside copyright (`ro-official-acts-public-domain`) - Licence text: https://legislatie.just.ro/Public/DetaliiDocument/7816 - Required attribution: Date privind achizițiile publice publicate în SEAP/SICAP de ANAP — e-licitatie.ro - Notes: Legea 8/1996 privind dreptul de autor, art. 9, excludes from copyright both official texts of an administrative nature and simple facts and data. A procurement notice is both: Legea 98/2016 and Legea 99/2016 REQUIRE contracting authorities to publish these notices in SEAP/SICAP, so the publication is an official act, and the contents — a code, a value, a date, the name of the winner — are facts. They are also public-interest information under Legea 544/2001 and re-usable public-sector information under Legea 179/2022, which transposes the EU Open Data Directive. Note honestly that 179/2022 grants a RIGHT of reuse rather than a copyright licence, and names no attribution form — so the attribution line above is this project’s own convention, not a form the law prescribes. HOWEVER, and a reuser must weigh this: ANAP/SICAP publishes NO dataset-specific licence. https://e-licitatie.ro/robots.txt returns 404, so nothing is disallowed to a crawler, and the site’s terms page is a client-rendered shell with no retrievable text — there is no grant to point at and no prohibition to point at either. This dataset therefore rests on the legal position above rather than on any permission from ANAP, and anyone republishing it should make their own assessment. About the source: the API is UNDOCUMENTED and reverse-engineered from the SICAP web client. It has no version header and no changelog, and field names can change without notice — which is why every field path in this connector is hard-coded, so a change breaks loudly instead of filling a column with NULL. What is published here: the notice and award metadata itself, re-typed into a canonical schema. What is deliberately NOT republished: the tender documentation, the attachments and the PDF renditions SICAP hosts alongside each procedure. One completeness caveat belongs in any reuse: the source truncates every query at 2000 rows, and the coverage table is where this dataset admits which slices hit that ceiling. Do not quote a daily total without checking it. Reproduce the attribution line verbatim anywhere you republish this data. ## Manifest - Start here for how this directory works: https://date-deschise.bunnytech.app/llms.txt - This dataset: https://date-deschise-s3.bunnytech.app/public/sicap-procurement/manifest.json - All datasets: https://date-deschise-s3.bunnytech.app/public/index.json - Human page: https://date-deschise.bunnytech.app/datasets/sicap-procurement The manifest is the contract: file URLs, row counts, column types, min/max statistics and example queries all live there. Re-read it to discover a new version. ## Fastest path — Parquet exports Immutable, physically sorted snapshot exports. No catalog fetch, best row-group pruning, safe to cache forever. Register one view per table: ```sql INSTALL httpfs; LOAD httpfs; CREATE OR REPLACE VIEW direct_acquisitions AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/direct_acquisitions.parquet'); CREATE OR REPLACE VIEW direct_acquisition_items AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/direct_acquisition_items.parquet'); CREATE OR REPLACE VIEW da_award_notices AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/da_award_notices.parquet'); CREATE OR REPLACE VIEW contract_award_notices AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/contract_award_notices.parquet'); CREATE OR REPLACE VIEW award_notice_contracts AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/award_notice_contracts.parquet'); CREATE OR REPLACE VIEW award_notice_winners AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/award_notice_winners.parquet'); CREATE OR REPLACE VIEW award_notice_lots AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/award_notice_lots.parquet'); CREATE OR REPLACE VIEW contract_notices AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/contract_notices.parquet'); CREATE OR REPLACE VIEW tender_lots AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/tender_lots.parquet'); CREATE OR REPLACE VIEW parties AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/parties.parquet'); CREATE OR REPLACE VIEW cpv_codes AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/cpv_codes.parquet'); CREATE OR REPLACE VIEW cpv_categories AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/cpv_categories.parquet'); CREATE OR REPLACE VIEW coverage AS SELECT * FROM read_parquet('https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/coverage.parquet'); ``` Example queries: -- The month’s direct awards, biggest first: The date range is what prunes: finalization_date leads the sort order, so this reads only the row groups that overlap the month. ```sql ATTACH IF NOT EXISTS 'ducklake:https://date-deschise-s3.bunnytech.app/catalog/catalog.ducklake' AS "datadirectory" (READ_ONLY); SELECT finalization_date, name, supplier_name, authority_name, closing_value_ron FROM datadirectory.sicap_procurement.direct_acquisitions WHERE finalization_date BETWEEN DATE '2026-09-01' AND DATE '2026-09-30' ORDER BY closing_value_ron DESC LIMIT 25 ``` -- Who sold the most to the Romanian state in a month: The join to parties is what makes this a company-level answer instead of a text aggregation over inconsistently spelled names. ```sql ATTACH IF NOT EXISTS 'ducklake:https://date-deschise-s3.bunnytech.app/catalog/catalog.ducklake' AS "datadirectory" (READ_ONLY); SELECT p.cui, p.name, count(*) AS awards, sum(d.closing_value_ron) AS total_ron FROM datadirectory.sicap_procurement.direct_acquisitions d JOIN datadirectory.sicap_procurement.parties p ON p.cui = d.supplier_cui WHERE d.finalization_date BETWEEN DATE '2026-09-01' AND DATE '2026-09-30' GROUP BY 1, 2 ORDER BY total_ron DESC LIMIT 20 ``` ## Live lake — DuckLake catalog with time travel Attach the published catalog read-only over plain https. This works in native DuckDB AND in duckdb-wasm in the browser — the reader catalog resolves its data files through public https URLs, so no credentials and no backend are involved. ```sql INSTALL ducklake; LOAD ducklake; ATTACH 'ducklake:https://date-deschise-s3.bunnytech.app/catalog/sicap-procurement/catalog.ducklake' AS sicap_procurement (READ_ONLY); SELECT * FROM sicap_procurement.main.direct_acquisitions LIMIT 5; USE sicap_procurement; ``` - Latest catalog: https://date-deschise-s3.bunnytech.app/catalog/sicap-procurement/catalog.ducklake - This exact version: https://date-deschise-s3.bunnytech.app/catalog/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/catalog.ducklake (sha256 dfe09b163540152ec196920bfcf83405da34b6fee14d18341743f7e3d1b50a62) - Written by DuckDB v1.5.5 - Time travel: this ingest is snapshot 13 — e.g. `SELECT * FROM sicap_procurement.direct_acquisitions AT (VERSION => 13)` ## Wholesale — S3 access For bulk downloads, read the bucket prefix directly over S3 with httpfs: ```sql INSTALL httpfs; LOAD httpfs; CREATE SECRET hetzner ( TYPE s3, ENDPOINT 'fsn1.your-objectstorage.com', URL_STYLE 'path', KEY_ID '', SECRET '' ); SELECT * FROM read_parquet('s3://date-deschise-s3/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/**/*.parquet'); ``` ## Schema ### direct_acquisitions One row per finalised direct award (achiziție directă) — the low-value purchases Romanian public bodies may make without running a tender, published in SICAP as they are concluded. This is the highest-volume table in the dataset: an ordinary weekday carries eight to nine thousand awards. The row is the award as SICAP published it: who bought, who sold, what CPV code it was filed under, the estimated value and the value it closed at. - 8,744 rows · 832 KB · write mode `snapshot_history` - Physically sorted by: `finalization_date`, `cpv_division`, `direct_acquisition_id` - Primary key: `direct_acquisition_id` - Text search columns: `name`, `supplier_name`, `authority_name` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/direct_acquisitions.parquet (8,744 rows) Columns: - `direct_acquisition_id` BIGINT NOT NULL — SICAP's own internal id for the award. Stable, and the primary key of this table. (range: "121349385" … "123267665") (~7997 distinct) - `unique_identification_code` VARCHAR — The public "DA…" code SICAP shows on the award screen. This is the code a human quotes; direct_acquisition_id is the one the API uses. - `finalization_date` DATE NOT NULL — The calendar day the award was finalised, exactly as the source writes it (Europe/Bucharest, the zone every SICAP timestamp carries). This is the snapshot key: re-running a day replaces precisely that day, which is what makes corrections and backfills idempotent. It is also the field the crawl filters on, so a row whose day disagrees with the day it was fetched for is skipped rather than published. (range: "2026-09-03" … "2026-10-18") (~3 distinct) - `finalization_at` TIMESTAMPTZ — The full instant the award was finalised. TIMESTAMPTZ, so it is an absolute point in time: SICAP states it in Europe/Bucharest local time with the offset attached (+03:00 in summer, +02:00 in winter), and nothing is converted or guessed here. - `publication_at` TIMESTAMPTZ — When the award was first published in SICAP, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. Routinely earlier than finalization_at, and often on the previous day, which is why this connector slices on the finalization date and not on this one. - `ca_decision_deadline_at` TIMESTAMPTZ — Deadline by which the contracting authority must decide on the offer, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. - `supplier_decision_deadline_at` TIMESTAMPTZ — Deadline by which the supplier must respond, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. - `name` TEXT NOT NULL — What was bought, in the contracting authority’s own words. - `name_lc` VARCHAR NOT NULL — name, lowercased and accent-folded (NFD, combining marks stripped), so a case- and diacritic-insensitive search is a plain string comparison rather than a function of the column — which would defeat row-group statistics entirely. - `cpv_code` VARCHAR — The CPV code split off the combined string the API sends, including its check digit. Joins to cpv_codes.cpv_code. - `cpv_label` TEXT — The CPV label, the remainder of the same combined string. - `cpv_division` VARCHAR — The first two digits of the CPV code — the CPV division, i.e. the broad sector. Split out as its own column and placed second in the sort order so "everything in division 45 (construction works)" is a range predicate that prunes row groups, instead of a LIKE over a free-text field that cannot prune at all. (range: "03" … "98") - `state_id` INTEGER — sysDirectAcquisitionState.id — the award’s lifecycle state. Also one of the axes the crawl splits a truncated day along; see the coverage table. - `state_label` VARCHAR — The state’s Romanian label as SICAP writes it. - `supplier_cui` VARCHAR — Fiscal identification code (CUI/CIF) of the supplier, taken from the leading token of the supplier string. Stored as TEXT and never as a number: leading zeros occur and are meaningful, and the source writes the fiscal prefix on some rows and not on others — the current VAT form ("RO15151621"), the pre-2007 form ("R1890420") and the same with a space ("R 10625635") all occur. The prefix is stripped so every spelling of one company lands on one code. NULL when the string carries no recognisable Romanian code at all, which is also where a foreign VAT number ("SE559406327201") ends up on purpose. - `supplier_name` TEXT — The supplier’s name, the remainder of the supplier string. - `supplier_name_lc` VARCHAR — supplier_name, lowercased and accent-folded. - `authority_cui` VARCHAR — Fiscal identification code of the contracting authority, parsed exactly like supplier_cui. Joins to parties.cui. - `authority_name` TEXT — The contracting authority’s name. - `authority_name_lc` VARCHAR — authority_name, lowercased and accent-folded. - `estimated_value_ron` DECIMAL(18,2) [RON] — The value the authority estimated, in Romanian lei. Exact decimal, never a float. - `estimated_value_other_currency` DECIMAL(18,2) — The same estimate in the other currency SICAP displays alongside it — in practice euro, converted at the rate of the day. The source does not name the currency in the payload, so this column does not claim one. - `closing_value_ron` DECIMAL(18,2) [RON] — The value the award actually closed at, in Romanian lei. Equal to the estimate on most rows, because a direct award is usually accepted at the offered price. - `is_open_for_correction` BOOLEAN — Whether the award was still open for correction when the row was captured. The source sends null far more often than true or false. - `is_open_for_contract_correction` BOOLEAN — Whether the resulting contract was still open for correction when the row was captured. - `description` TEXT — The full purchase description the authority wrote — the specification behind the one-line name: what exactly is being delivered, over what period, under what obligations. It runs to whole paragraphs and is the most informative free text about a direct award anywhere in this dataset. Only the per-award detail endpoint carries it; the list endpoint the crawl pages through does not, so it is NULL on any award whose detail was not fetched. - `description_lc` VARCHAR — description, lowercased and accent-folded (NFD, combining marks stripped), so a case- and diacritic-insensitive search over the specification text is a plain string comparison rather than a function of the column. - `contract_id` BIGINT — The id of the contract record SICAP generated when the award closed, when one was generated at all. Null on awards that never reached a contract — a direct acquisition can be concluded on an order or an invoice instead. - `da_award_notice_id` BIGINT — The direct-acquisition award notice this award was rolled into, when the source names one. In practice it is NULL on effectively every row, and that is a finding rather than a gap: probing the award-notice list across whole years returns nothing at all for online acquisitions, so the DAN family covers only purchases made OUTSIDE the electronic catalogue. This column is carried because the source publishes it — a non-null value would mean SICAP had begun linking the two, which is worth seeing — but do not plan a join on it: da_award_notices is a disjoint population, not a parent of this table. - `authority_entity_id` BIGINT — contractingAuthorityID — SICAP’s internal entity id for the buyer, which is a different key from its fiscal code. It is what Entity/getCAEntityView is addressed by, so it is how parties.entity_id and the address and contact columns beside it get filled. The authority and supplier id spaces are SEPARATE: the same number means two different organisations in the two roles. - `supplier_entity_id` BIGINT — supplierId — SICAP’s internal entity id for the seller, addressed through Entity/getSUEntityView. A distinct id space from authority_entity_id, and the other source of the enriched columns on parties. - `delivery_condition` TEXT — The delivery terms, as free text in the authority’s own words. Not a coded field — the source lets the buyer type anything, and "conform contract" ("as per the contract") is by far the commonest value, which says nothing at all. - `payment_condition` TEXT — The payment terms, as free text. Same caveat as delivery_condition: usually "conform contract", occasionally a real payment schedule. - `economy_value` DECIMAL(18,2) [RON] — The saving the source recorded against the estimate, in lei, when the award closed below the estimated value. Null far more often than not: SICAP fills it only where the catalogue negotiation actually moved the price. - `economy_percent` DOUBLE [percent] — The same saving as a percentage of the estimated value. DOUBLE rather than an exact decimal because it is a derived ratio, not an amount of money — the house rule about exact decimals protects sums of currency, and a percentage is neither summed nor currency. - `loss_value` DECIMAL(18,2) [RON] — The mirror of economy_value: the amount by which the closing value EXCEEDED the estimate, in lei. Null on the overwhelming majority of rows. - `loss_percent` DOUBLE [percent] — The overrun as a percentage of the estimated value. - `second_currency_estimated_value` DECIMAL(18,2) — The estimate converted into the second currency SICAP displays (euro in practice, at the day’s rate), as the DETAIL endpoint reports it. It is the same figure the list endpoint lands in estimated_value_other_currency; both are kept because they are two separate observations, and the two disagreeing means the award was corrected between the list read and the detail read. - `second_currency_closing_value` DECIMAL(18,2) — The value the award actually closed at, converted into that same second currency. The list endpoint publishes no equivalent, so this exists only on rows whose detail was fetched. - `ca_decision_at` TIMESTAMPTZ — When the contracting authority actually decided on the offer, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. Compare it with ca_decision_deadline_at, which is the deadline it had to decide by. - `supplier_decision_at` TIMESTAMPTZ — When the supplier actually responded, as an absolute instant with the source’s Europe/Bucharest offset attached. Together with ca_decision_at and finalization_at it is the whole timeline of a direct award, which on a catalogue purchase is usually minutes rather than days. - `correction_reason` TEXT — The reason recorded when the award was corrected after publication, in free text. Null unless a correction was actually made, which is rare — and a non-null value here is the signal that an earlier snapshot of this row said something different. - `supplier_rejection_reason` TEXT — The reason the supplier gave for refusing the order, in free text. Present only on awards a supplier declined — a state that leaves the acquisition published and finalised but unfulfilled, so a spending total that ignores it counts money that was never spent. - `ca_rejection_reason` TEXT — The reason the contracting authority gave for rejecting the offer, in free text. The mirror of supplier_rejection_reason, with the same warning: a rejected award is published like any other. - `contract_type_id` INTEGER — sysAcquisitionContractType.id: 1 Furnizare (supplies), 2 Servicii (services), 3 Lucrări (works) — the same three-way split every other table in this dataset uses. The list endpoint FILTERS on it (it is one of the crawl’s splitting axes; see coverage) but does not return it, so it lands only on rows whose detail was fetched. - `contract_type_label` VARCHAR — The contract type’s Romanian label, as SICAP writes it. - `european_fund_id` INTEGER — sysEuropeanFund.id — which EU programme financed the purchase, when one did. Read from the nested object rather than from the sysEuropeanFundID sibling scalar, because SICAP leaves that scalar null on payloads where the object is populated. - `european_fund_label` VARCHAR — The programme’s name. Beware: SICAP frequently sends an EMPTY string here and puts the only readable token in a localeKey field this connector does not publish ("Common.Clasiff.SysEuropeanFund.PIDS"), so a blank label does NOT mean there was no fund — check european_fund_id. - `financing_type` BOOLEAN — financingType — a bare boolean SICAP publishes without documenting it anywhere. Observed true on EU-financed awards and false on ordinary ones, which suggests "financed from an external programme", but the source states nothing: treat it as a raw flag rather than a fact. - `item_count` INTEGER — How many catalogue lines the award has, i.e. how many direct_acquisition_items rows belong to it. DERIVED by counting the detail payload’s items, not a field the source publishes. It is carried for one specific reason: it is NULL exactly when the detail was never fetched, so it is how a genuinely single-line purchase is told apart from an award whose lines are simply absent. - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC) — when this copy was taken, as opposed to finalization_date, which is when the award happened. - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### direct_acquisition_items One row per catalogue line inside a direct award — the actual thing bought, with its price, its quantity and its unit of measure. This is the table that makes "what did the Romanian state actually buy" answerable: direct_acquisitions carries a title and a total, while a single award can bundle several catalogue entries from the same supplier, each with its own CPV code, its own quantity and its own price. The lines exist only on the per-award detail endpoint, so this table covers the awards whose detail was fetched and nothing else — join on direct_acquisition_id and compare against direct_acquisitions.item_count, which is NULL exactly where the detail was never read. - 331 rows · 67 KB · write mode `snapshot_history` - Physically sorted by: `finalization_date`, `direct_acquisition_id`, `direct_acquisition_item_id` - Primary key: `direct_acquisition_item_id` - Text search columns: `catalog_item_name`, `catalog_item_description` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/direct_acquisition_items.parquet (331 rows) Columns: - `direct_acquisition_item_id` BIGINT NOT NULL — SICAP’s id for this line of this award, and the primary key. It identifies the LINE, not the catalogue product: the same product bought on two awards gets two of these. Use catalog_item_id to follow the product. (range: "131256329" … "134026198") (~320 distinct) - `direct_acquisition_id` BIGINT NOT NULL — The award this line belongs to, joining to direct_acquisitions.direct_acquisition_id. Not published on the line itself — it is the id the detail endpoint was fetched by, carried down so the line stands on its own without a join. (range: "121349385" … "123267665") - `catalog_item_id` BIGINT — The id of the entry in the supplier’s electronic catalogue that this line was bought from. The same id across different awards means the same listed product, so this is what to group by for "who else bought this exact item, and at what price" — the price-comparison question a catalogue is supposed to make answerable and that no summary table can answer. - `catalog_item_history_id` BIGINT — The id of the specific VERSION of that catalogue entry as it stood when the purchase was made. Suppliers edit their catalogue entries — price, description, quantity — freely and without notice, so catalog_item_id alone does not pin down what was actually on offer at the moment of the purchase; this does. - `catalog_item_state_id` INTEGER — sysCatalogItemStateID — the lifecycle state of the catalogue entry at the time of purchase (published, suspended, withdrawn). SICAP publishes no dictionary for it on this endpoint, so it is carried as the source’s own number rather than given a label this connector would be inventing. - `catalog_item_code` VARCHAR — The supplier’s own product code for the catalogue entry ("EBC052026"), typed by the supplier. It is not a standard of any kind and it is not unique across suppliers — two firms may use the same string for entirely different things — so it is useful within one supplier and meaningless across them. - `catalog_item_name` TEXT — The product or service name as the SUPPLIER listed it in the catalogue. This is the seller’s wording, where direct_acquisitions.name is the buyer’s: the two describing different things is often how a mismatched or repurposed purchase first shows up. - `catalog_item_name_lc` VARCHAR — catalog_item_name, lowercased and accent-folded (NFD, combining marks stripped), so a case- and diacritic-insensitive product search is a plain string comparison rather than a function of the column, which would defeat row-group statistics entirely. - `catalog_item_description` TEXT — The supplier’s full description of the catalogue entry — frequently the complete technical specification, running to dozens of lines, with the supplier’s own contact details appended at the end. It is the most detailed free text about a purchase anywhere in this dataset, and it is written by the seller rather than the buyer. - `catalog_item_price` DECIMAL(18,2) [RON] — The unit price standing on the catalogue entry, in lei — the list price the supplier advertised, before anything specific to this award. Compare it with item_closing_price to see whether the purchase was made at the advertised price. - `item_estimated_price` DECIMAL(18,2) [RON] — The value the buyer estimated for this line, in lei. On most rows it is the catalogue price applied to the requested quantity, because a direct award is usually taken as listed. - `item_closing_price` DECIMAL(18,2) [RON] — What the line actually closed at, in lei. THIS is the column to sum for "what was spent": the difference from item_estimated_price is whatever negotiation happened, and it is zero on the great majority of rows. - `second_currency_estimated_price` DECIMAL(18,2) — The same estimate converted into the second currency SICAP displays alongside it — euro in practice, at the day’s rate. The payload does not name the currency, so this column does not claim one either. - `item_quantity` DOUBLE — How many units were actually bought, in the unit named by item_measure_unit. DOUBLE rather than an integer because the source publishes fractional quantities freely — hours, kilograms, square metres — and it is a count of things rather than an amount of money, so the exact-decimal rule does not apply. - `item_requested_quantity` DOUBLE — How many units the buyer originally asked for. Where it differs from item_quantity the order was changed before it closed, and has_quantity_correction is the flag that says so explicitly. - `item_measure_unit` VARCHAR — The unit of measure, in the supplier’s free text ("pachet servicii", "buc", "ore", "luna"). It is typed, not chosen from a dictionary, so quantities are only comparable between rows that happen to spell the unit the same way — do not sum item_quantity across different spellings. - `is_rejected_by_supplier` BOOLEAN — Whether the supplier refused THIS line. An award can close with some of its lines rejected, so a spending total built from item_closing_price without filtering on this counts money that was never spent. - `has_quantity_correction` BOOLEAN — Whether the quantity on this line was corrected after the order was placed — the flag that explains a gap between item_requested_quantity and item_quantity. - `cpv_code` VARCHAR — The CPV code of the LINE, split off the combined string the source sends, including its check digit. It can differ from the parent award’s code: the award is filed under one CPV while its lines may be classified more precisely, which is why a sector analysis done on this table and one done on direct_acquisitions will not agree. Joins to cpv_codes.cpv_code. - `cpv_label` TEXT — The CPV label, the remainder of the same combined string. - `cpv_division` VARCHAR — The first two digits of the line’s CPV code — the CPV division, i.e. the broad sector. - `finalization_date` DATE NOT NULL — The Europe/Bucharest calendar day the PARENT award was finalised, copied down from direct_acquisitions — the source’s own day, not a UTC day. A line carries no date of its own, and without the parent’s day this table could neither be re-run idempotently nor pruned by date — so it is both the snapshot key and the lead sort column here, exactly as on the parent. (range: "2026-10-17" … "2026-10-18") (~2 distinct) - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### da_award_notices One row per direct-acquisition award notice ("DAN…") published in SICAP — and every one of them is an OFFLINE direct acquisition: a purchase concluded outside SEAP’s electronic catalogue, which the authority then announces after the fact. That is not a guess. Probing the source’s own list filter for online acquisitions returns zero rows for 2018, for 2022 and with no date filter at all, while the offline filter returns the same rows as no filter at all; roughly a thousand notices are published on an ordinary day. So this table is the other half of Romanian direct-award spending, and it overlaps direct_acquisitions nowhere: those purchases exist in NO other table here, and without this one they are simply missing public money. There is deliberately no join between the two families, because there is no link to join on. - 41 rows · 13 KB · write mode `snapshot_history` - Physically sorted by: `publication_date`, `cpv_division`, `da_award_notice_id` - Primary key: `da_award_notice_id` - Text search columns: `contract_object`, `supplier_name`, `authority_name` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/da_award_notices.parquet (41 rows) Columns: - `da_award_notice_id` BIGINT NOT NULL — SICAP’s internal id for the notice, and the primary key. It is the handle the API uses; notice_no is the one a human quotes. (range: "101972341" … "101972400") (~43 distinct) - `notice_no` VARCHAR — The public notice number ("DAN2844495") shown on the SICAP screen and quoted in correspondence and in the press. Stable and human-readable — this is the string to search for when someone hands you a reference. - `publication_date` DATE NOT NULL — The Europe/Bucharest calendar day the notice was published — the source’s own day, not a UTC day. This is the snapshot key: re-running a day replaces exactly that day. Unlike the two notice families in this dataset, the DA award-notice list both filters on a publication date and returns one, so this day is the source’s own statement rather than the crawl window’s. (range: "2026-10-17" … "2026-10-18") (~2 distinct) - `publication_at` TIMESTAMPTZ — The full publication instant, as an absolute point in time — stated by the source in Europe/Bucharest local time with its offset attached (+03:00 in summer, +02:00 in winter). Nothing is converted or guessed here. - `contract_object` TEXT — What was bought, in the contracting authority’s own words — the object of the contract as free text, usually a full sentence naming the works or services and their scope. It is the only description this family carries: an offline acquisition has no catalogue entry behind it, so there is nothing like direct_acquisition_items to fall back on. - `contract_object_lc` VARCHAR — contract_object, lowercased and accent-folded (NFD, combining marks stripped), so a case- and diacritic-insensitive search is a plain string comparison rather than a function of the column. - `notice_state_id` INTEGER — sysNoticeState.id — the notice’s own publication state. Every row a public reader can see carries 2 ("Publicat"): the public API exposes published notices only, which was confirmed by filtering a full day on that state and getting the same count as with no filter. It is still one of the axes the crawl splits a truncated day along, because a splitting axis has to be exhaustive rather than useful. - `notice_state_label` VARCHAR — The state’s Romanian label as SICAP writes it. - `supplier_cui` VARCHAR — Fiscal identification code (CUI/CIF) of the economic operator awarded the contract, split off the party string the source sends. The fiscal prefix is stripped, so "RO6545775", "R6545775" and "6545775" are one code and every spelling of a company lands on one row in parties. NULL when the string carries no recognisable Romanian code, which is where a foreign VAT number deliberately ends up. - `supplier_name` TEXT — The awarded operator’s name. - `supplier_name_lc` VARCHAR — supplier_name, lowercased and accent-folded. - `authority_cui` VARCHAR — Fiscal identification code of the contracting authority that published the notice, parsed exactly like supplier_cui. Joins to parties.cui. Note it comes from the LIST row: the per-notice detail payload names the authority only by its internal entity id. - `authority_name` TEXT — The contracting authority’s name, from the list row. - `authority_name_lc` VARCHAR — authority_name, lowercased and accent-folded. - `cpv_code` VARCHAR — The CPV code the notice was filed under, split off the combined string, including its check digit. Joins to cpv_codes.cpv_code. - `cpv_label` TEXT — The CPV label, the remainder of the same combined string. - `cpv_division` VARCHAR — The first two digits of the CPV code — the sector. Second in the sort order so a sector cut inside a day is a contiguous range rather than a scan. (range: "09" … "98") - `cpv_category` VARCHAR — The SICAP CPV category the notice falls under — one of the twelve broad sectors in cpv_categories, which are SICAP’s own grouping rather than part of the EU vocabulary. It matters here for a second reason: it is the FIRST axis the crawl splits a truncated day of this family along, so a value here is also a statement about how the row was reached. Join to cpv_categories.label. - `awarded_value_ron` DECIMAL(18,2) [RON] — The value the contract was awarded at, in Romanian lei — the number this table exists to publish, and for offline acquisitions the only place it appears at all. DECIMAL(18,2), like every amount in this dataset: DECIMAL(12,4) tops out just under a hundred million and would raise decimal_overflow and kill the whole ingest rather than lose a cent, and every figure this source publishes carries exactly two decimals. - `second_currency_awarded_value` DECIMAL(18,2) — The same awarded value converted into the second currency SICAP displays alongside it — euro in practice, at the day’s rate. The payload does not name the currency, so this column does not claim one. - `is_online` BOOLEAN — isOnlineAcquisition — whether the purchase went through the electronic catalogue. It is FALSE on every notice observed, at every date probed, which is what makes this family the offline half of direct-award spending; a TRUE here would be genuinely notable and would mean SICAP had started publishing award notices for catalogue purchases too. It was tried as a candidate third axis for the crawl’s day-splitting and dropped: sending isOnline as a list-body filter returns either the whole day (false) or nothing (true) at every date probed, so it never narrows a truncated slice the way CPV category and notice state do — the crawl always sends isOnline: null, and this column is filled from each notice’s own detail fetch instead. - `acquisition_type` VARCHAR — The same distinction in the source’s own word — "Offline" on every row observed, "Online" being the value that has never appeared. It is kept beside is_online because it is what the SICAP screen actually shows, and because a THIRD value appearing here would be a change in the source’s model that a boolean would silently swallow. - `contract_date` TIMESTAMPTZ — When the underlying contract was signed, as an absolute instant with the source’s Europe/Bucharest offset attached. On an offline acquisition it is frequently the same minute as the publication, because the authority fills the form and publishes in one sitting after the purchase has already happened. - `finalization_date` TIMESTAMPTZ — When the acquisition itself was finalised, as an absolute instant with the source’s Europe/Bucharest offset. This is the ECONOMIC date and it can be days before the notice appeared — 2026-08-27 against a publication on 2026-09-01 in the sample — while publication_date, which this table is partitioned and sorted on, is the ADMINISTRATIVE one. A spending report by month has to choose, and should say which. Note it is a full instant here, not a calendar day, and is a different column from direct_acquisitions.finalization_date despite the shared name. - `authority_entity_id` BIGINT — contractingAuthorityID — SICAP’s internal entity id for the buyer, the key Entity/getCAEntityView is addressed by and one of the two sources of the enriched columns on parties. A different id space from supplier_entity_id. - `supplier_entity_id` BIGINT — supplierID — SICAP’s internal entity id for the awarded operator, addressed through Entity/getSUEntityView. - `contract_type_id` INTEGER — sysAcquisitionContractType.id: 1 Furnizare (supplies), 2 Servicii (services), 3 Lucrări (works). - `contract_type_label` VARCHAR — The contract type’s Romanian label. This endpoint writes it WITHOUT diacritics ("Lucrari", not "Lucrări"), which is the source’s own spelling and is preserved. - `doc_type_id` INTEGER — sysDirectAcqDocType.id — what kind of document the acquisition was concluded with: a contract, an order, an invoice. This is the distinction that actually matters for an offline direct acquisition, where a purchase may legally amount to nothing more than an accepted invoice, and there is no equivalent anywhere else in this dataset. - `doc_type_label` VARCHAR — The document type’s Romanian label ("Contract", "Comanda", "Factura"). - `european_fund_id` INTEGER — sysEuropeanFund.id — the EU programme that financed the purchase, when one did. Read from the nested object; SICAP leaves the sibling scalar null on payloads where the object is populated. - `european_fund_label` VARCHAR — The programme’s name. SICAP often sends it as an EMPTY string with the only readable token in a localeKey field this connector does not publish, so a blank here does NOT mean there was no fund — check european_fund_id. - `financing_type` BOOLEAN — financingType — a bare boolean the source publishes without documenting it, observed true on EU-financed notices and false on ordinary ones. Carried as a raw flag rather than a fact, because SICAP defines it nowhere. - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### contract_award_notices One row per contract award notice (anunț de atribuire) published in SICAP — the notice a contracting authority publishes once a tender has been awarded, stating who won and for how much. These are the large contracts: values in the hundreds of millions of lei are ordinary here, where direct_acquisitions is capped by law at the direct-award threshold. One row is one notice as it stood when the run captured it, keyed on the notice id. - 258 rows · 52 KB · write mode `snapshot_history` - Physically sorted by: `publication_date`, `cpv_division`, `ca_notice_id` - Primary key: `ca_notice_id` - Text search columns: `contract_title`, `authority_name` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/contract_award_notices.parquet (258 rows) Columns: - `ca_notice_id` BIGINT NOT NULL — SICAP’s internal id for the award notice. Primary key. (range: "100609884" … "100653209") (~221 distinct) - `notice_id` BIGINT — The id of the underlying notice document, shared with the versions and errata of the same notice. - `procedure_id` BIGINT — The id of the procurement procedure this notice belongs to. Joins an award notice to the contract notice that opened the same procedure. - `notice_no` VARCHAR — The public notice number a human quotes ("CAN…", "SCNA…"). - `publication_date` DATE NOT NULL — The Europe/Bucharest calendar day the notice was published — the source’s own day, not a UTC day. It comes from the crawl window rather than from the payload, because the list endpoint filters on publication date but does not return it, and that filter is what defines which day a notice belongs to. This is the snapshot key: re-running a day replaces exactly that day. (range: "2026-09-03" … "2026-09-03") (~1 distinct) - `notice_type_id` INTEGER — sysNoticeTypeId — which kind of award notice this is. The crawl asks for types 3, 13, 18, 16 and 8, the same set the SICAP web client requests for its award-notice screen. - `notice_state_id` INTEGER — sysNoticeState.id — the notice’s own publication state. - `notice_state_label` VARCHAR — The notice state’s Romanian label. - `procedure_state_id` INTEGER — sysProcedureState.id — the state of the procedure behind the notice. - `procedure_state_label` VARCHAR — The procedure state’s Romanian label. - `authority_cui` VARCHAR — Fiscal code (CUI/CIF) of the contracting authority, split off the combined "CUI - name" string. The fiscal prefix is stripped, so "RO1590120", "R1590120" and "1590120" are one code. Joins to parties.cui. NULL when the string carries no recognisable code. - `authority_name` TEXT — The contracting authority’s name. - `authority_name_lc` VARCHAR — authority_name, lowercased and accent-folded. - `contract_title` TEXT — The contract title, in the authority’s own words. - `contract_title_lc` VARCHAR — contract_title, lowercased and accent-folded. - `contract_type_id` INTEGER — sysAcquisitionContractType.id: 1 Furnizare (supplies), 2 Servicii (services), 3 Lucrări (works). - `contract_type_label` VARCHAR — The contract type’s Romanian label. - `procedure_type_id` INTEGER — sysProcedureType.id — which procurement procedure was run (open tender, restricted, negotiated, …). - `procedure_type_label` VARCHAR — The procedure type’s Romanian label. - `contract_assignment_type_id` INTEGER — sysContractAssigmentType.id — whether the award is a plain public contract, a framework agreement, and so on. The misspelling is the source’s; the column name is not. - `contract_assignment_type_label` VARCHAR — The assignment type’s Romanian label. - `cpv_code` VARCHAR — The CPV code split off cpvCodeAndName. Joins to cpv_codes.cpv_code. - `cpv_label` TEXT — The CPV label, the remainder of the same string. - `cpv_division` VARCHAR — The first two digits of the CPV code — the sector. Second in the sort order so a sector cut inside a day is a contiguous range rather than a scan. (range: "03" … "98") - `ron_contract_value` DECIMAL(18,2) [RON] — The awarded contract value in Romanian lei. DECIMAL(18,2) rather than the platform’s usual DECIMAL(12,4) because a single day of this table carried 2,149,454,481.75 RON, which does not fit in twelve digits. - `highest_offer_value` DECIMAL(18,2) [RON] — The highest offer received for the contract. 0 when the source published none. - `lowest_offer_value` DECIMAL(18,2) [RON] — The lowest offer received for the contract. 0 when the source published none. - `currency_code` VARCHAR — The currency the notice states its values in; RON in practice. - `estimated_value_export` VARCHAR — The value as SICAP renders it for display, amount and currency in one string ("366296 RON"). Kept verbatim because it is what a reader sees on the site; use ron_contract_value for arithmetic. - `is_online` BOOLEAN — Whether the procedure was run online. - `is_utility` BOOLEAN — Whether the authority is a utility (sectorial) contracting entity under Legea 99/2016 rather than a classic one under Legea 98/2016. - `is_ppp` BOOLEAN — Whether the award is a public-private partnership. - `has_subsequent_contracts` BOOLEAN — Whether the award carries subsequent contracts — the mark of a framework agreement being drawn down. - `notice_state_at` TIMESTAMPTZ — When the notice last entered its current state, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. The closest thing the payload carries to a publication instant. - `errata_no` INTEGER — How many errata have been published against this notice; 0 for none. - `notice_version_id` INTEGER — sysNoticeVersionId — which version of the notice this row describes. - `version_no` VARCHAR — versionNo as the source sends it, coerced to text. Every row observed so far carries null; the column is kept so a value the source starts sending is captured rather than discarded. - `min_tender_receipt_deadline_at` TIMESTAMPTZ — Earliest tender receipt deadline of the procedure, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. Usually null on an award notice, because the deadline has long passed by the time the award is published. - `max_tender_receipt_deadline_at` TIMESTAMPTZ — Latest tender receipt deadline, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. - `tender_receipt_deadline_export` VARCHAR — The tender deadline as SICAP renders it for display ("08.10.2026 15:00"), day-first and in Bucharest local time. Kept verbatim; use the timestamptz columns for arithmetic. - `joue_publication_number` VARCHAR — The number this notice carries in the Official Journal of the European Union, for the contracts large enough that EU-wide publication is compulsory. The source writes an EMPTY STRING rather than null on a notice never sent to the OJEU, which is most of them, so treat blank and null alike as "not published in the OJEU". - `ca_publication_at` TIMESTAMPTZ — When THIS award notice was published, as an absolute instant with the source’s Europe/Bucharest offset attached. Do not confuse it with the sibling publication instant in the same block of the document, which belongs to the CONTRACT notice that opened the procedure and can be months earlier — 2026-07-27 against an award published 2026-09-01 on the sample notice. This is the one that agrees with publication_date. - `authority_entity_id` BIGINT — SICAP’s internal entity id for the contracting authority, taken from the authority address block of the notice document. The same id space as direct_acquisitions.authority_entity_id and the join to parties.entity_id — though note the enriched columns on parties are only ever filled from direct-acquisition and DA award-notice detail, so an authority that only ever publishes tenders will have an id here and nothing on its parties row. - `authority_address` TEXT — The authority’s street address as typed into THIS notice ("Strada: Gădinţi, nr. 4"). It is the address on the notice, not a registry address: the same authority spells it differently across notices and nothing is normalised here. - `authority_city` VARCHAR — The town the authority gave on this notice. Free text and unnormalised — "Bucuresti" and "București" both occur, so group on authority_nuts_code rather than on this. - `authority_county` VARCHAR — The county (județ) from the notice’s authority address. Very often NULL even where a city is given — the sample notice names Bucharest as its city and leaves the county empty — so authority_nuts_code is the reliable geography here. - `authority_email` VARCHAR — The contact e-mail printed on the notice: where an interested economic operator writes with questions. Published deliberately by the source on a public procurement screen, and it is an organisational contact rather than a private address. - `authority_phone` VARCHAR — The contact telephone number printed on the notice, in the source’s own formatting. That formatting is frequently wrong in the same way — "+40 0212521795" carries both the country code and the national trunk zero — and it is preserved rather than corrected. - `authority_url` VARCHAR — The authority’s own website, as given on the notice. Distinct from the buyer-profile URL in the same block, which on essentially every Romanian notice is just e-licitatie.ro and carries no information. - `authority_nuts_code` VARCHAR — The NUTS region code of the authority, split off the source’s combined "RO321 Bucuresti" string. This is the dependable geography on an award notice: a coded dictionary value, where authority_city and authority_county are free text somebody typed. Note that the document’s own nutsCode field is unusable — SICAP leaks an Entity Framework proxy class name into it — so the code comes from the readable item beside it. - `reference_number` VARCHAR — The authority’s own internal reference for the procurement ("12579039/2026/21") — normally its fiscal code, the year and a sequence number. It is the string the authority uses in its own files, so it is how a notice is matched to an internal record or to the answer to a freedom-of-information request. - `short_description` TEXT — The notice’s summary of what is being procured, written by the authority and usually several paragraphs long. It routinely also carries procedural boilerplate — the deadline for clarification requests, the legal articles relied on — so read it as a description of the PROCUREMENT rather than a clean description of the goods. - `has_lots` BOOLEAN — Whether the procurement was actually divided into lots. Note that SICAP creates one lot record for every procedure regardless, titled "Lot implicit", so counting rows in award_notice_lots is NOT how to answer this question — this flag is. - `number_of_lots` INTEGER — How many lots the notice DECLARES in its own document. Frequently NULL even where has_lots is true; lot_count, which this connector counts from the lots endpoint, is the dependable figure, and the two disagreeing is itself worth looking at. - `total_awarded_value` DECIMAL(18,2) [RON] — The total value the notice states across all its lots, in the currency named in the same section. On notice 100652594 it reads 375,200.00 and matches that notice’s single signed contract in award_notice_contracts exactly — that equality is the cross-check to run. But beware the zeroes: notice 100652596 publishes 0.0 here while its one lot is estimated at 49,173.60 lei, so a 0 means "the authority left the field empty", not "nothing was awarded". Sum award_notice_contracts.default_currency_contract_value when you need a number you can defend. - `framework_contract_value` DECIMAL(18,2) [RON] — The total value of the framework agreement the notice establishes, as distinct from total_awarded_value, which is what is being bought now. Only a framework notice carries a real figure; on an ordinary contract the source writes 0.0 rather than leaving it empty, so 0 here does not distinguish "not a framework" from "not filled in". - `total_ron_value_for_paap` DECIMAL(18,2) [RON] — The notice’s value in lei as it is booked against the authority’s annual procurement plan (PAAP — programul anual al achizițiilor publice). It is the figure the authority’s own budget planning uses, which is why the source states it separately and always in lei, even for a contract denominated in another currency. 0.0 where it was left empty. - `award_criteria_type_label` VARCHAR — The criterion the award was decided on ("Cel mai bun raport calitate – cost", "Pretul cel mai scazut") — the answer to "was this bought on price alone, or on price plus quality", which is the first question anyone asks about a Romanian award. award_notice_lots carries the same thing per lot, with its dictionary id alongside, and on a multi-lot notice the lots are what to read. - `is_eu_funded` BOOLEAN — Whether the procurement is financed from EU funds, as the notice declares it. This is the flag that puts a contract inside the reach of the EU audit bodies — and it is DECLARED by the authority, not verified by anyone. It is stated per lot in the document, so on a notice with lots it is true when any lot is EU-funded. - `eu_project` TEXT — The EU project the procurement belongs to, in free text — usually the project title, its financing contract number and its SMIS code in one string, which is what makes a contract traceable to a specific programme. Null when is_eu_funded is false, and sometimes null even when it is true. - `lot_count` INTEGER — How many lots the notice has, i.e. how many award_notice_lots rows belong to it. Counted from the lots endpoint the detail pass reads, not published by the source. NULL when the detail was not fetched, which is emphatically not the same as 0. - `contract_count` INTEGER — How many contracts were actually signed under the notice, i.e. how many award_notice_contracts rows belong to it. A notice with lots and zero contracts is one where nothing was awarded — most often because no admissible offer arrived. Counted, not published. - `cancelled_lot_count` INTEGER — How many of the notice’s lots were cancelled, from the cancelled-lots endpoint. Non-zero is the signal that part or all of the procedure fell through; award_notice_lots.is_cancelled says which lots, and its cancellation_reason_comment says why. - `detail_fetched` BOOLEAN — Whether the per-notice detail pass actually ran for this row and succeeded. FALSE means every detail column above is NULL because nothing was read — not because the source published nothing. This is the column that stops a skipped or failed fetch from being read as an empty notice, and it is the one to filter on before drawing any conclusion from a NULL up there. - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### award_notice_contracts One row per contract actually signed under a contract award notice — the number a citizen means by "how much did this cost". contract_award_notices publishes what the notice DECLARED; this publishes what was CONTRACTED, contract by contract, and the two routinely disagree: notice 100652596 states a total acquisition value of 0 while carrying a lot estimated at 49,173.60 lei, and notice 100652594 states 375,200.00 and matches its single contract exactly. A notice with lots and no rows here awarded nothing — usually because no admissible offer arrived; award_notice_lots.is_cancelled says whether the lot was formally cancelled. Read from the notice’s contracts endpoint during the detail pass, so it covers the notices whose detail was fetched and nothing else. - 0 rows · 783 B · write mode `snapshot_history` - Physically sorted by: `publication_date`, `ca_notice_id`, `ca_notice_contract_id` - Primary key: `ca_notice_contract_id` - Text search columns: `contract_title`, `winner_caption`, `contract_no` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/award_notice_contracts.parquet (0 rows) Columns: - `ca_notice_contract_id` BIGINT NOT NULL — SICAP’s id for this contract line on the notice, and the primary key. It identifies the contract AS ANNOUNCED on this notice; contract_id is the separate id of the contract record itself, when one was ever created. (range: null … null) (~0 distinct) - `ca_notice_id` BIGINT NOT NULL — The award notice this contract was signed under, joining to contract_award_notices.ca_notice_id. (range: null … null) - `contract_id` BIGINT — The id of the contract record in SICAP’s own contract module, when the contract was actually registered there. NULL on the sample and on many rows: announcing a contract on a notice and registering it as an electronic contract are two separate acts, and only the first is compulsory. - `notice_no` VARCHAR — The public notice number the contract was announced under ("CAN1173674"), repeated on every contract of the notice. Carried so this table reads on its own without joining back to the notice. - `contract_no` VARCHAR — The authority’s OWN contract number ("SSC-R-3759") — the reference printed on the paper contract and the string an auditor or a journalist will be handed. Free text, and unique only within one authority, so never join on it across authorities. - `contract_at` TIMESTAMPTZ — The date the contract was signed, as an absolute instant with the source’s Europe/Bucharest offset attached. The source states it at midnight local time, so it carries a day rather than a time of day. It is usually WEEKS EARLIER than the notice’s publication_date — 2026-07-31 against a notice published 2026-09-01 in the sample — because the notice announces a contract already signed, and that lag is precisely why this table is partitioned on the notice’s day and not on this one. - `contract_title` TEXT — The contract’s title, in the authority’s own words ("Contract de prestări servicii"). Frequently generic; contract_award_notices.short_description and award_notice_lots say far more about what was actually procured. - `winner_caption` TEXT — The winner or winners as the notice renders them for display, in one string. It is what the SICAP screen shows; award_notice_winners breaks the same winners out one row apiece with their fiscal codes and addresses, and that is what to join on rather than this. - `lots_caption` TEXT — The lots this contract covers, as one display string. Empty when the notice was never divided into real lots. Not parsed here — the structure is in award_notice_lots. - `lots_no_caption` VARCHAR — The lot NUMBERS this contract covers, as one display string ("1, 3, 4"). Same caveat as lots_caption: it is rendering meant for a screen, not structure meant for a join. - `contract_value` DECIMAL(18,2) — The contract value in the currency named by currency_code — the headline amount. DECIMAL(18,2): amounts here reach billions of lei, and DECIMAL(12,4) would raise decimal_overflow and kill the whole ingest rather than lose a cent. Do NOT sum this column across rows; sum default_currency_contract_value, which is in one currency. - `currency_code` VARCHAR — The currency the contract was signed in; RON on almost every row, but euro-denominated contracts do occur — which is exactly why default_currency_contract_value exists. - `default_currency_contract_value` DECIMAL(18,2) [RON] — The same amount converted into the platform’s default currency, Romanian lei, at currency_rate. THIS is the column to sum across contracts: contract_value cannot be added up when rows carry different currencies, and nothing in the source stops them from doing so. - `currency_rate` DOUBLE — The exchange rate used for that conversion; 1.0 on a contract already in lei. A ratio rather than an amount of money, so DOUBLE rather than an exact decimal. - `contract_value_min_offer` DECIMAL(18,2) — The lowest offer received for this contract, in the contract’s currency, where the notice states one. NULL far more often than not — the source publishes an offer range only for procedures that had a real competition, so a value here is itself informative. - `contract_value_max_offer` DECIMAL(18,2) — The highest offer received. Together with contract_value_min_offer it is the only evidence in this dataset of how much competition a contract actually attracted, which is the question behind most procurement analysis. - `contract_type` INTEGER — The source’s own contractType integer on the contract line, carried verbatim. CAUTION: it is NOT the sysAcquisitionContractType dictionary used everywhere else in this dataset. The sample carries 1 on a contract titled "Contract de prestări servicii", and under that dictionary 1 is Furnizare (supplies), not Servicii. SICAP publishes no dictionary for this field on this endpoint, so it is stored as a raw number and must not be read as a contract type without checking against the source. - `has_modified_versions` BOOLEAN — Whether the contract has been amended since it was announced. A true here is the entry point to the contract-modification notices (McNotice), a family this dataset does not yet cover — so it is currently a flag pointing outside the lake rather than a join. - `modified_count` INTEGER — How many amended versions exist; 0 when the contract stands as signed. A high count on a large contract is the classic signal of scope creep, and it is one of the few things here that can be ranked without any further data. - `has_electronic_contract` BOOLEAN — Whether the contract was concluded through SICAP’s electronic contract module rather than on paper. Where it is true, contract_id points at that record. - `publication_date` DATE NOT NULL — The Europe/Bucharest calendar day the parent award notice was published, copied down — the source’s own day, not a UTC day. It is the snapshot key and the lead sort column: a contract line has no publication day of its own — contract_at is the signature date, which lags by weeks — and without the parent’s day this table could neither be re-run idempotently nor pruned by date. (range: null … null) (~0 distinct) - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### award_notice_winners One row per winning economic operator per contract. This is the table that answers "who won", which contract_award_notices deliberately cannot: that table records the BUYER, and the winner lives on the contracts underneath it. A contract is normally won by one operator, but an association or consortium bidding jointly wins as several, so this is a genuine one-to-many on ca_notice_contract_id — and a contract’s value must never be multiplied by its winners when the two tables are joined. Built from the contracts endpoint’s winners array, falling back to its single winner object when the array is empty. - 0 rows · 475 B · write mode `snapshot_history` - Physically sorted by: `publication_date`, `ca_notice_id`, `ca_notice_contract_id`, `winner_id` - Primary key: `ca_notice_contract_id`, `winner_id` - Text search columns: `winner_name` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/award_notice_winners.parquet (0 rows) Columns: - `ca_notice_contract_id` BIGINT NOT NULL — The contract this operator won, joining to award_notice_contracts.ca_notice_contract_id. Half of the primary key. (range: null … null) (~0 distinct) - `winner_id` BIGINT NOT NULL — SICAP’s id for this winner record on this contract — the other half of the primary key. It identifies the winner ENTRY, not the company: the same firm winning two contracts gets two ids. Follow a company through winner_cui, or through winner_entity_id. (range: null … null) (~0 distinct) - `ca_notice_id` BIGINT NOT NULL — The award notice the contract belongs to, joining to contract_award_notices.ca_notice_id. Carried down so "every winner on this notice" needs no join through the contracts table. (range: null … null) - `winner_cui` VARCHAR — Fiscal identification code (CUI/CIF) of the winning operator, split off the fiscal-number string the source sends. That string is written inconsistently — the sample carries "RO 5831590", with the VAT prefix AND a space inside it — so the prefix and the spacing are stripped and every spelling of one company lands on one code. Joins to parties.cui. NULL when the string carries no recognisable Romanian code, which is where a foreign VAT number deliberately ends up rather than corrupting the join key. - `winner_name` TEXT — The operator’s name as the notice records it. - `winner_name_lc` VARCHAR — winner_name, lowercased and accent-folded (NFD, combining marks stripped), so a case- and diacritic-insensitive search for a company is a plain string comparison rather than a function of the column. - `winner_entity_id` BIGINT — SICAP’s internal entity id for the winning operator, from the winner record — the key Entity/getSUEntityView is addressed by, and the join to parties.entity_id on the parties this dataset has managed to enrich. - `is_sme` BOOLEAN — Whether the winner is a small or medium enterprise — the classification EU procurement reporting is built on, and the basis of every "how much went to SMEs" statistic. WARNING: the source carries this TWICE and the two copies disagree — in the sample the winner record says null while the address block inside the very same record says true. Treat a value here as the source’s claim rather than a fact, and treat NULL as "not stated" rather than as "no". - `city` VARCHAR — The winner’s town, from the address block on the winner record. Free text as the operator gave it, and not normalised. - `county` VARCHAR — The winner’s county (județ). The source sends it as an id-and-text pair and the readable text is what is stored here. Bucharest is written as its own county, which is how Romanian administrative geography works. - `country` VARCHAR — The winner’s country. "Romania" on the overwhelming majority of rows; anything else is worth noticing, because it means a genuinely cross-border award. - `postal_code` VARCHAR — The winner’s postal code, from the same address block. - `email` VARCHAR — The contact e-mail printed on the winner record — the address the authority itself published on the notice for the awarded operator, on a public procurement screen. - `phone` VARCHAR — The contact telephone number on the winner record, in the source’s own formatting ("+40 743126445"). - `publication_date` DATE NOT NULL — The Europe/Bucharest calendar day the award notice this contract belongs to was published, copied down two levels — the source’s own day, not a UTC day. It is the snapshot key and the lead sort column: a winner row has no date of its own, and without the parent notice’s day this table could neither be re-run idempotently nor pruned by date. (range: null … null) (~0 distinct) - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### award_notice_lots One row per lot on a contract award notice — the unit a large procurement is actually divided into, and therefore the unit at which it is estimated, located, financed, judged and cancelled. A notice with three lots is three separate competitions announced together, and reading only the notice hides that: the notice’s own total is frequently 0 while its lots carry the real estimates. Cancelled lots are a FLAG on this table rather than a table of their own, because a cancelled lot is the same lot: is_cancelled and the three cancellation columns are filled from the notice’s cancelled-lots endpoint, matched to the lot by its id. A notice whose lots are all cancelled is a procedure that produced nothing. - 0 rows · 1.1 KB · write mode `snapshot_history` - Physically sorted by: `publication_date`, `ca_notice_id`, `notice_lot_id` - Primary key: `notice_lot_id` - Text search columns: `lot_title`, `short_description`, `eu_project` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/award_notice_lots.parquet (0 rows) Columns: - `notice_lot_id` BIGINT NOT NULL — SICAP’s id for the lot, and the primary key. It is the same id the cancelled-lots endpoint reports back, which is how the cancellation columns below are matched to the right lot. (range: null … null) (~0 distinct) - `ca_notice_id` BIGINT NOT NULL — The award notice the lot belongs to, joining to contract_award_notices.ca_notice_id. (range: null … null) - `lot_number` VARCHAR — The lot’s number within the notice ("1", "2", …), stored as text because authorities also write forms like "1A". It is the number quoted in the tender documents and the one that appears in award_notice_contracts.lots_no_caption. - `lot_title` TEXT — The lot’s title, in the authority’s words. "Lot implicit" ("default lot") on a notice that was never actually divided: SICAP creates one lot record for every procurement, so a single lot with that title means "this procurement has no lots" rather than "it has one". - `short_description` TEXT — What THIS lot procures, in prose — the description at the level a bidder actually needs. On a multi-lot notice this is where the real content is, because the notice’s own summary covers every lot at once and therefore describes none of them precisely. - `main_cpv_code` VARCHAR — The lot’s main CPV code, split off the combined string this endpoint sends ("30213200-7 Tablet PC (Rev.2)"). Note the shape differs from the direct-acquisition endpoint, where the code sits in a separate field rather than inside the text. Joins to cpv_codes.cpv_code, and it can differ from the notice’s own CPV: a notice is filed under one code while its lots are classified individually. - `main_cpv_label` TEXT — The CPV label, the remainder of the same combined string. - `main_cpv_division` VARCHAR — The first two digits of the lot’s CPV code — the sector. - `nuts_code` VARCHAR — The NUTS region code where the lot is to be performed, split off the source’s combined "RO321 Bucureşti" string. This is the coded, comparable geography of an award notice, where main_location is whatever the buyer happened to type. - `nuts_label` VARCHAR — The region’s name, the remainder of the same string. Written WITH diacritics on this endpoint ("Bucureşti"), unlike most SICAP text, so string-comparing it with a county name from elsewhere in this dataset will not match. - `main_location` TEXT — Where the contract is to be performed, in free text as the authority typed it ("Str. Intrarea Gadinti nr. 4, sector 1, Bucuresti") — a street address, a town, or a whole county depending on who filled in the form. Use nuts_code for anything that has to aggregate. - `estimated_value` DECIMAL(18,2) — The value the authority estimated for this lot, in the currency named by currency_code. This is the number that actually matters on a multi-lot notice: the notice-level total is often left at 0 while the lots carry the real figures. DECIMAL(18,2) because national-scale estimates overflow DECIMAL(12,4), and an overflow kills an ingest rather than losing a cent. - `min_estimated_value` DECIMAL(18,2) — The bottom of the estimated range, where the authority gave a range instead of a single figure — normal on a framework agreement, whose volume is not known in advance. NULL on a lot estimated at one value. - `max_estimated_value` DECIMAL(18,2) — The top of that range. On a framework agreement this, and not estimated_value, is the ceiling a supplier could actually be asked to deliver against. - `framework_contract_value` DECIMAL(18,2) — The total value of the framework agreement this lot establishes, as distinct from estimated_value, which is what is being bought now. Only a framework lot carries a real figure; on an ordinary contract it is NULL or 0. - `currency_code` VARCHAR — The currency the lot’s values are stated in. CAREFUL: on this endpoint SICAP sends the currency’s Romanian NAME rather than its ISO code — the sample reads "Leu", not "RON" — so this column is not directly comparable with currency_code on award_notice_contracts, which does send the ISO code. - `award_criteria_type_id` INTEGER — sysAwardCriteriaType.id — how the lot is to be decided: lowest price, best price-quality ratio, and so on. Read from the nested object, because the source leaves the sibling scalar null on payloads where the object is populated, so reading the scalar would lose the value entirely. - `award_criteria_type_label` VARCHAR — The criterion’s Romanian label ("Cel mai bun raport calitate – cost", "Pretul cel mai scazut") — the answer to "was this bought on price alone", which is the first question anyone asks about a Romanian award and the one that decides whether a low bid could have lost. - `month_duration` INTEGER — How many months the resulting contract runs for. The source expresses a duration in months OR in days, never both, so a NULL here usually means day_duration carries it. - `day_duration` INTEGER — How many days the resulting contract runs for, where the authority expressed the duration in days rather than months. - `start_date` DATE — The planned start day of the lot’s contract, where the authority gave fixed dates instead of a duration — the Europe/Bucharest calendar day the source states, not a UTC day. Very often NULL, because a duration is the commoner way of stating it. - `completion_date` DATE — The planned completion day — the Europe/Bucharest calendar day the source states, not a UTC day — on the same terms as start_date. - `is_eu_funded` BOOLEAN — Whether THIS lot is financed from EU funds, as the authority declares it. It is declared at lot level, so one notice can mix EU-funded and nationally funded lots — which is exactly why a notice-level flag is not good enough for any serious question about EU money. - `eu_project` TEXT — The EU project the lot belongs to, in free text: normally the project title, its financing contract number and its SMIS code in one string, which is what makes a lot traceable to a specific programme and to that programme’s own reporting. - `european_fund_id` INTEGER — sysEuropeanFund.id — which EU programme funds the lot. Read from the nested object: the source leaves the sibling scalar null on payloads where the object is populated, so reading the scalar would silently lose every value. - `european_fund_label` VARCHAR — The programme’s name, spelled out ("PS - Programul Sanatate 2021-2027"). On this endpoint it is normally populated, unlike the direct-acquisition endpoint where it is often an empty string. - `financing_type_id` INTEGER — sysFinancingType.id — how the lot is financed (own budget, programme or project, loan, …). Read from the nested object for the same reason as european_fund_id. - `financing_type_label` VARCHAR — The financing type’s Romanian label ("Program / Proiect", "Buget de stat"). - `has_options` BOOLEAN — Whether the lot carries options — extensions or additional quantities the authority may call off later without running a new procedure. A true means the announced value is a floor rather than a ceiling, which is a common source of understated spending. - `lot_info` VARCHAR — The lot’s status as SICAP renders it on the screen ("Anulat" for a cancelled lot). It is display text rather than a coded field, so filter on is_cancelled instead; this is kept because it sometimes carries a state the structured columns do not express. - `notice_lot_ted_uid` VARCHAR — The lot’s identifier in the EU eForms/TED scheme ("LOT-0000") — how this lot is addressed in the Official Journal publication of the same notice, and therefore the join key to any TED-derived dataset. - `is_cancelled` BOOLEAN — Whether the lot was cancelled. Set from the notice’s CANCELLED-LOTS endpoint rather than from the lot record itself, matched on the lot id — so FALSE means "this lot was not in that response", which on a notice whose detail pass failed is not the same as "not cancelled". Check contract_award_notices.detail_fetched before relying on a false. - `cancellation_reason` VARCHAR — The coded reason the procedure gave for cancelling the lot. Frequently NULL even on a genuinely cancelled lot — the sample cancels a lot with no coded reason at all and only free text — so read cancellation_reason_comment alongside it rather than instead of it. - `cancellation_reason_comment` TEXT — The cancellation reason in the authority’s own words, and where the real reason actually is. It is often one of a handful of standard sentences: the sample reads "Aceasta procedura a fost anulata automat deoarece la data limita de depunere oferta nu au existat ofertanti care au depus oferta" — cancelled automatically because nobody bid, which is the single commonest failure mode of a Romanian tender. - `cancellation_date` DATE — The day the lot was cancelled. The source states it as a full instant at midnight Europe/Bucharest, so only the day is kept — that is all it actually carries. - `publication_date` DATE NOT NULL — The Europe/Bucharest calendar day the parent award notice was published, copied down — the source’s own day, not a UTC day. It is the snapshot key and the lead sort column: a lot has no publication day of its own, and without the parent’s day this table could neither be re-run idempotently nor pruned by date. (range: null … null) (~0 distinct) - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### contract_notices One row per contract notice (anunț de participare) published in SICAP — the notice that opens a tender and invites offers. Where contract_award_notices records the end of a procedure, this records its start, with the estimated value and the deadline for offers. Join the two on procedure_id to follow one procedure from invitation to award. - 105 rows · 30 KB · write mode `snapshot_history` - Physically sorted by: `publication_date`, `cpv_division`, `c_notice_id` - Primary key: `c_notice_id` - Text search columns: `contract_title`, `authority_name` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/contract_notices.parquet (105 rows) Columns: - `c_notice_id` BIGINT NOT NULL — SICAP’s internal id for the contract notice. Primary key. (range: "100029144" … "100244354") (~120 distinct) - `notice_id` BIGINT — The id of the underlying notice document. - `procedure_id` BIGINT — The id of the procurement procedure. This is the join key to contract_award_notices.procedure_id — the same procedure seen from the other end. - `notice_no` VARCHAR — The public notice number a human quotes ("CN…"). - `publication_date` DATE NOT NULL — The Europe/Bucharest calendar day the notice was published — the source’s own day, not a UTC day — taken from the crawl window rather than from the payload, because the list endpoint filters on publication date but does not return it. The snapshot key. (range: "2026-09-03" … "2026-09-03") (~1 distinct) - `notice_type_id` INTEGER — sysNoticeTypeId — which kind of contract notice this is. - `notice_state_id` INTEGER — sysNoticeState.id — the notice’s publication state. - `notice_state_label` VARCHAR — The notice state’s Romanian label. - `procedure_state_id` INTEGER — sysProcedureState.id — the state of the procedure. - `procedure_state_label` VARCHAR — The procedure state’s Romanian label. - `authority_cui` VARCHAR — Fiscal code (CUI/CIF) of the contracting authority, split off the combined "CUI - name" string with any fiscal prefix ("RO", "R") stripped. Joins to parties.cui. - `authority_name` TEXT — The contracting authority’s name. - `authority_name_lc` VARCHAR — authority_name, lowercased and accent-folded. - `contract_title` TEXT — The contract title. SICAP allows newlines inside it and they are preserved verbatim. - `contract_title_lc` VARCHAR — contract_title, lowercased and accent-folded. - `contract_type_id` INTEGER — sysAcquisitionContractType.id: 1 Furnizare, 2 Servicii, 3 Lucrări. - `contract_type_label` VARCHAR — The contract type’s Romanian label. - `procedure_type_id` INTEGER — sysProcedureType.id — which procurement procedure is being run. - `procedure_type_label` VARCHAR — The procedure type’s Romanian label. - `contract_assignment_type_id` INTEGER — sysContractAssigmentType.id — public contract, framework agreement, and so on. - `contract_assignment_type_label` VARCHAR — The assignment type’s Romanian label. - `cpv_code` VARCHAR — The CPV code split off cpvCodeAndName. Joins to cpv_codes.cpv_code. - `cpv_label` TEXT — The CPV label, the remainder of the same string. - `cpv_division` VARCHAR — The first two digits of the CPV code — the sector, and the second sort column. (range: "03" … "90") - `estimated_value_ron` DECIMAL(18,2) [RON] — The estimated value of the contract in Romanian lei, as stated in the notice. DECIMAL(18,2) for the same reason as in contract_award_notices: national-scale tenders do not fit in twelve digits. - `estimated_value_export` VARCHAR — The estimated value as SICAP renders it for display, amount and currency in one string. - `is_online` BOOLEAN — Whether the procedure is being run online. - `has_lots` BOOLEAN — Whether the tender is divided into lots. - `has_appeal` BOOLEAN — Whether an appeal (contestație) has been lodged against the procedure. - `notice_state_at` TIMESTAMPTZ — When the notice last entered its current state, as an absolute instant — stated by the source in Europe/Bucharest local time with its offset attached. - `errata_no` INTEGER — How many errata have been published against this notice; 0 for none. - `notice_version_id` INTEGER — sysNoticeVersionId — which version of the notice this row is. - `min_tender_receipt_deadline_at` TIMESTAMPTZ — Earliest instant an offer may be received — stated by the source in Europe/Bucharest local time with its offset attached. This is the deadline that matters on a live tender. - `max_tender_receipt_deadline_at` TIMESTAMPTZ — Latest instant an offer may be received — stated by the source in Europe/Bucharest local time with its offset attached. - `tender_receipt_deadline_export` VARCHAR — The tender deadline as SICAP renders it for display ("08.10.2026 15:00"), day-first and in Bucharest local time. - `sad_id` BIGINT — sadId — the dynamic purchasing system (sistem de achiziție dinamic) the notice belongs to, when it belongs to one. Null on an ordinary tender. - `notice_contract_object_id` BIGINT — The id of the "contract object" record the notice hangs off — SICAP’s internal handle for the thing being procured, as distinct from the notice announcing it. It is what the source’s own client addresses the tender sections with, and it is kept so a reader can reproduce those calls. - `tender_receipt_deadline_at` TIMESTAMPTZ — The single offer deadline the notice screen itself shows, as an absolute instant with the source’s Europe/Bucharest offset attached. The list endpoint instead publishes a minimum and a maximum across the whole procedure (min_tender_receipt_deadline_at / max_tender_receipt_deadline_at); where this value falls outside that pair, the notice was amended between the two reads. - `sent_to_joue` BOOLEAN — Whether the notice was transmitted to the Official Journal of the European Union. A tender above the EU thresholds must be advertised Union-wide, so this is the flag that separates the contracts a foreign bidder was ever realistically told about from the ones advertised in Romania only. - `has_errata` BOOLEAN — Whether at least one erratum has been published against this notice. The list read gives the count in errata_no; this is the detail document’s own flag, and where the two disagree an erratum was published between the list read and the detail read. - `has_eforms_documents` BOOLEAN — Whether the notice carries eForms documents — the EU’s standard machine-readable notice format, mandatory for the procurements published in the OJEU. It usually tracks sent_to_joue, and it is the marker for a notice whose structured EU version can be matched against a TED-derived dataset. - `has_notice_changes` BOOLEAN — Whether the notice has been changed since it was first published — a broader flag than has_errata, which counts only formal errata. A true means the version this dataset captured is not the version bidders first saw. - `df_docs_zip_url` VARCHAR — Absolute URL of the ZIP archive holding the tender documentation and the published clarifications — the caiet de sarcini, the model contract, the bidder Q&A. The source sends it as a path relative to the API root ("api-pub/files/c-dfdoc-clar/ede014c5290f495a98532afcb4ff8d4d"); the absolute URL is stored so the value is usable on its own. THIS IS A REFERENCE, ON PURPOSE, AND THE ONE PLACE IN THIS DATASET WHERE THAT IS THE RIGHT ANSWER: the archive holds PDFs and Word files, which the rule that says "ingest the data, not a link to it" explicitly exempts because they are not tabular. Nothing behind this URL is in the lake, and no query over this dataset can reach it — fetching it is the reader’s own step. Everything the source publishes as a table, including the lots, IS ingested; see tender_lots. - `lot_count` INTEGER — How many lots the tender is divided into, i.e. how many tender_lots rows belong to this notice. Counted from the lot list the detail pass reads, not published by the source. NULL when the detail was not fetched; has_lots is the cheap flag from the list read that says whether to expect more than the one default lot. - `detail_fetched` BOOLEAN — Whether the per-notice detail pass ran for this row and succeeded. FALSE means every detail column above is NULL because nothing was read, not because the notice is empty — and it also means this notice has no tender_lots rows for the same reason. - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### tender_lots One row per lot on a contract notice (anunț de participare) — the tender as it was ADVERTISED, lot by lot, before anyone bid. It is the mirror image of award_notice_lots: this is what was asked for, that is what was awarded, and the gap between the two is the whole story of a procurement. It also carries the estimate that matters: a notice advertising "200000 RON" may in fact be five lots of very different sizes, and only this table shows them. Read from the tender-lot endpoint during the detail pass, so it covers the notices whose detail was fetched and nothing else. Deliberately narrower than award_notice_lots, because a contract notice publishes far less per lot than an award notice does. - 0 rows · 529 B · write mode `snapshot_history` - Physically sorted by: `publication_date`, `c_notice_id`, `notice_lot_id` - Primary key: `notice_lot_id` - Text search columns: `lot_title` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/tender_lots.parquet (0 rows) Columns: - `notice_lot_id` BIGINT NOT NULL — SICAP’s id for the lot, and the primary key. It is a DIFFERENT id from the one on award_notice_lots: a tender lot and the award lot that follows it are separate records, and this dataset holds no key linking them directly — go through the procedure, joining contract_notices.procedure_id to contract_award_notices.procedure_id and matching on lot_number. (range: null … null) (~0 distinct) - `c_notice_id` BIGINT NOT NULL — The contract notice this lot belongs to, joining to contract_notices.c_notice_id. (range: null … null) - `notice_id` BIGINT — The id of the underlying notice document — contract_notices.notice_id, carried down from the list row. It is NOT the id the tender-lot endpoint is addressed with, even though the request parameter for that endpoint is named `initNoticeId`: measured 2026-09-07, sending `initNoticeId = noticeId` returned null for every notice tried (101391496, 101391492), while sending `initNoticeId = c_notice_id` (the value on this same row) with the same sysNoticeTypeId returned the lots (100244296 -> 5 lots, 100211654 -> 1, 100244295 -> 1, 100244293 -> 1). Kept anyway because it is still a real identifier for the notice document, just not the one this fetch used. - `lot_number` VARCHAR — The lot’s number within the tender ("1", "2", …), stored as text because authorities also write forms like "1A". This is the number a bidder quotes when submitting an offer for part of a tender, and the only handle for matching a tender lot to the award lot that follows it. - `lot_title` TEXT — The lot’s title, in the authority’s words. "Lot implicit" ("default lot") on a tender that was never actually divided: SICAP creates one lot record for every procedure, so a single lot with that title means the tender has no lots rather than exactly one. - `cpv_code` VARCHAR — The lot’s CPV code. This endpoint sends the code and the label as two separate fields rather than as one combined string, so nothing is split here. Joins to cpv_codes.cpv_code, and it can be more specific than the notice’s own code. - `cpv_label` TEXT — The CPV label, the source’s own cpvName for the same lot. - `cpv_division` VARCHAR — The first two digits of the lot’s CPV code — the sector. - `estimated_value` DECIMAL(18,2) [RON] — The value the authority estimates for this lot, in the currency named by currency_code. This is the money a bidder is competing for, and summing it across a notice’s lots is the honest way to size a tender. DECIMAL(18,2) because tenders at national scale run well past what DECIMAL(12,4) holds — the single sample lot is already 7,973,210.88 lei — and an overflow kills the ingest rather than losing a cent. - `min_estimated_value` DECIMAL(18,2) — The bottom of the estimated range, where the authority gave a range rather than a single figure — normal on a framework agreement whose volume is not known in advance. NULL on an ordinary lot. - `max_estimated_value` DECIMAL(18,2) — The top of that range. On a framework agreement this, not estimated_value, is the ceiling a supplier could actually be asked to deliver against. - `currency_code` VARCHAR — The currency the estimate is stated in. This endpoint sends the ISO code ("RON"), unlike award_notice_lots, which sends the currency’s Romanian name — so the two columns cannot be compared directly. - `notice_lot_ted_uid` VARCHAR — The lot’s identifier in the EU eForms/TED scheme ("LOT-0000") — how the lot is addressed in the Official Journal publication of the same tender, and therefore the join key to any TED-derived dataset. - `publication_date` DATE NOT NULL — The Europe/Bucharest calendar day the parent contract notice was published, copied down — the source’s own day, not a UTC day. It is the snapshot key and the lead sort column: a lot has no publication day of its own, and without the parent’s day this table could neither be re-run idempotently nor pruned by date. (range: null … null) (~0 distinct) - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ### parties One row per fiscal code (CUI/CIF) this dataset has ever seen, whether as a supplier winning direct awards or as a contracting authority publishing them. This is the company bridge: it is what turns "who sold to the Romanian state" into a join rather than a text search, and what connects this dataset to any other keyed on a Romanian CUI. A code that appears in both roles gets one row with both flags set. first_seen_date and last_seen_date are maintained by the framework across runs, so they describe the whole history rather than the last run. The address, contact and entity_id columns are enriched from SICAP’s own entity records (Entity/getCAEntityView and Entity/getSUEntityView) and carry a KNOWN REACH LIMIT: those records are only ever reached through the detail pass on direct acquisitions and on direct-acquisition award notices, so a contracting authority that publishes tenders but never transacts a direct acquisition keeps its CUI and its name and gets NULL for every one of them. A NULL there means "never reached", never "the organisation has no address". When two observations of the same CUI disagree, the LAST one seen wins. - 7,817 rows · 209 KB · write mode `upsert` - Physically sorted by: `name_lc` - Primary key: `cui` - Text search columns: `name` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/parties.parquet (7,817 rows) Columns: - `cui` VARCHAR NOT NULL — The fiscal identification code, digits only. TEXT rather than a number because leading zeros occur and are meaningful, and because the source writes the fiscal prefix on some rows and not on others — "RO15151621", "R1890420" and "R 10625635" all occur alongside the bare digits. The prefix is stripped here so every spelling of one company is one row. A party string carrying a FOREIGN VAT number instead is deliberately not given a row: it is not a Romanian fiscal code, and forcing one would corrupt the join key. (~8546 distinct) - `name` TEXT NOT NULL — The party’s name. SICAP spells the same company several ways across rows; when a run sees more than one spelling for a code, the LONGEST is kept, on the reasoning that the longer string is the one that was not truncated. Later runs overwrite it the same way. - `name_lc` VARCHAR NOT NULL — name, lowercased and accent-folded. This is the sort column: the dimension grows past a single row group, so a prefix search ("name_lc >= 'alpha' AND name_lc < 'alphb'") is a range predicate that prunes, where lower(name) would be a function of the column and prune nothing. (range: "\"climax\"" … "”centrul cultural municipal ramnicu valcea”") - `is_supplier` BOOLEAN — True if this code has ever appeared as the supplier on a direct award. - `is_authority` BOOLEAN — True if this code has ever appeared as the contracting authority on an award or a notice. - `first_seen_date` DATE — The earliest crawled day this code was seen on, as a Europe/Bucharest calendar day — the same day the fact tables are keyed on, not a UTC day. Maintained by the framework: an upsert takes the LEAST of the stored and the incoming value, so it only ever moves backwards. - `last_seen_date` DATE — The latest crawled day this code was seen on, as a Europe/Bucharest calendar day. Maintained by the framework as the GREATEST of the stored and the incoming value. A party that stops appearing keeps the date it was last seen rather than being deleted. - `entity_id` BIGINT — SICAP’s internal entity id for this fiscal code — the key Entity/getCAEntityView and Entity/getSUEntityView are addressed by, and what every column below is read with. Two warnings. The authority and supplier id spaces are SEPARATE, so the same number means different organisations in the two roles; and a CUI seen in both roles keeps whichever id the run saw last, so on a row with both is_supplier and is_authority set this is one of the two and not necessarily the one you want. - `address` TEXT — The registered address as the SICAP entity record states it, in the source’s own single-string format ("Strada: …, Nr. …, Judet: …, Localitate: …, Cod postal: …"). It is the address the organisation gave SICAP, not a companies-registry address, and it is not parsed into parts here. - `city` VARCHAR — The town from the entity record. Written without diacritics, in the source’s own spelling ("Bucuresti", "Arad"), and not normalised here. - `county` VARCHAR — The county (județ) from the entity record. Bucharest is written as its own county, which is how Romanian administrative geography actually works and not a data error. - `country` VARCHAR — The country from the entity record — "Romania" on essentially every row, since a party without a recognisable Romanian fiscal code is deliberately given no row here at all (see cui). - `postal_code` VARCHAR — The postal code from the entity record. Frequently NULL even where the same code appears inside the address string — the sample authority leaves it null while its address ends "Cod postal: 310091" — so parse address if you must have it. - `email` VARCHAR — The contact e-mail on the entity record: the address SICAP itself publishes for the organisation on its public entity screen. An organisational procurement contact, not a private one. - `phone` VARCHAR — The contact telephone number on the entity record, in the source’s own formatting ("+40 732445050"). - `url` VARCHAR — The organisation’s website, as it gave it to SICAP. Often a domain that no longer resolves: the field is maintained by the organisation itself and nothing revalidates it. - `is_utility` BOOLEAN — Whether SICAP classifies the organisation as a utility (sectorial) contracting entity under Legea 99/2016 rather than a classic contracting authority under Legea 98/2016 — a different legal regime with different thresholds. It is only ever set from the AUTHORITY entity record, so it is NULL on a party seen only as a supplier: NULL means "unknown", not "not a utility". ### cpv_codes The Common Procurement Vocabulary dictionary as SICAP itself serves it — 9,455 codes with their Romanian labels. This is the lookup table for cpv_code on every fact table, and the way to turn a division number into a sector a human recognises. Reloaded whole on every run, because it is small reference data with no history worth keeping. - 9,455 rows · 212 KB · write mode `replace` - Physically sorted by: `cpv_code` - Primary key: `cpv_id` - Text search columns: `label` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/cpv_codes.parquet (9,455 rows) Columns: - `cpv_id` INTEGER NOT NULL — SICAP’s own internal id for the code. Stable, and the primary key — the CPV code itself is the join key, but the id is what the API addresses. (~7464 distinct) - `cpv_code` VARCHAR NOT NULL — The CPV code including its check digit, exactly as the EU vocabulary writes it. Joins to cpv_code on every fact table. (range: "00000000" … "98910000-5") - `label` TEXT — The code’s Romanian label, including the vocabulary revision marker. - `label_lc` VARCHAR — label, lowercased and accent-folded, for case-insensitive lookup. - `division` VARCHAR — The first two digits of the code — the CPV division, i.e. the broad sector. The same value the fact tables carry as cpv_division. ### cpv_categories The twelve broad sectors SICAP groups CPV codes into on its own search screens ("AGRICULTURA SI ALIMENTATIE", "CONSTRUCTII", …). They are not part of the EU vocabulary — they are SICAP’s own grouping — and they matter here for a second reason: they are the first axis this connector splits a truncated day along, so coverage.cpv_category_id points at this table. - 12 rows · 1.1 KB · write mode `replace` - Physically sorted by: `category_id` - Primary key: `category_id` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/cpv_categories.parquet (12 rows) Columns: - `category_id` INTEGER NOT NULL — SICAP’s id for the sector, 1 to 12. Primary key. (range: 1 … 12) (~13 distinct) - `label` VARCHAR NOT NULL — The sector name exactly as SICAP writes it — upper case and without diacritics, which is the source’s own spelling and is preserved rather than tidied. - `label_lc` VARCHAR NOT NULL — label, lowercased and accent-folded. ### coverage One row per crawl slice whose rows were actually fetched — the audit trail of the API’s 2000-row cap. Every SICAP list endpoint truncates a result set at 2000 rows and flags it as searchTooLong, so this connector splits a day until each piece fits: by CPV category, then by contract type, then by acquisition state for the direct-acquisition crawl, and by CPV category, then by notice state for the DA award-notice crawl — a third candidate axis, isOnline, was measured and dropped, because splitting on it never narrows a truncated day: it returns either every row or none, at every date this connector probed. This table records the pieces: what was asked for, what the server said the total was, how many rows came back, and whether the piece was STILL truncated after every axis for that crawl was exhausted. A run with no truncated = true row covered its days completely; one with such a row did not, and says exactly where. Only fetched slices are recorded — an intermediate probe that was split rather than fetched is a log line, not a row, so the totals here sum to the rows published. The second thing this table exists for is the shortfall column: a slice that quietly handed back fewer rows than the server said it had is the most dangerous outcome available to a paginated crawl, and it is published here as a number rather than left in a log nobody reads. - 36 rows · 2.4 KB · write mode `snapshot_history` - Physically sorted by: `slice_date`, `endpoint`, `cpv_category_id` - Primary key: `slice_date`, `endpoint`, `cpv_category_id`, `contract_type_id`, `state_id` - Files: 1 - https://date-deschise-s3.bunnytech.app/public/sicap-procurement/v/01M599ZAHW4YP8VH5DQ5QHJR1T/coverage.parquet (36 rows) Columns: - `slice_date` DATE NOT NULL — The Europe/Bucharest calendar day the slice covers — the finalization day for direct acquisitions, the publication day for notices, in the source’s own zone rather than in UTC. On the "cpv_codes" row, which covers no day at all, it is the last day of the run’s crawl window, so that re-running that day replaces that record too. The snapshot key: re-running a day replaces its whole coverage record. (range: "2026-09-03" … "2026-10-18") (~3 distinct) - `endpoint` VARCHAR NOT NULL — Which read the slice belongs to: "direct_acquisitions", "da_award_notices", "contract_award_notices" or "contract_notices" for the four day-sliced list endpoints, and "cpv_codes" for the one row per run that records the CPV dictionary read. "da_award_notices" is the direct-acquisition award notice list, which is split along its own two axes (CPV category, then notice state) rather than the ones the direct-acquisition crawl uses — a third candidate axis, isOnline, was measured and dropped, because it never narrows a truncated day either; the cap is the same 2000 rows and the accounting is the same. The dictionary is not a day slice, but it is paginated and it is a replace table, so a short read would shrink the dimension silently — it is held to the same accounting as everything else. (range: "contract_award_notices" … "direct_acquisitions") (~4 distinct) - `cpv_category_id` INTEGER NOT NULL — The CPV category the slice was narrowed to, joining to cpv_categories.category_id. 0 is a sentinel meaning "not split on this axis" — it is not a category id, and it is used rather than NULL because this column is part of the primary key. (range: 0 … 12) (~14 distinct) - `contract_type_id` INTEGER NOT NULL — The contract type the slice was narrowed to: 1 Furnizare, 2 Servicii, 3 Lucrări. 0 means "not split on this axis", and it is always 0 on a "da_award_notices" row, whose crawl has no contract-type axis at all. (~4 distinct) - `state_id` INTEGER NOT NULL — The state the slice was narrowed to. It holds TWO different dictionaries depending on the endpoint, which is the price of one shared coverage table: on a "direct_acquisitions" row it is a sysDirectAcquisitionStateId (7 = Oferta acceptata), and on a "da_award_notices" row it is a sysNoticeStateId (2 = Publicat), which is a different code space entirely — do not compare the two, and read endpoint first. It is always 0 on the two contract-notice endpoints, which have no state axis, and 0 anywhere else means "not split on this axis". (~10 distinct) - `reported_total` INTEGER — The total the server reported for the slice. Trustworthy only when truncated is false; when it is true this is exactly 2000, which is the cap rather than a count. - `rows_fetched` INTEGER — How many rows the crawl actually read for the slice, before any were skipped as unusable. Equal to reported_total for a healthy, untruncated slice. - `shortfall` INTEGER — Rows the server said the slice had that never actually arrived — min(reported_total, 2000) minus rows_fetched, floored at zero. 0 on a healthy slice, and it is 0 on a truncated one too: truncation is the cap being reached, which this column deliberately does not confuse with a short read. Anything above zero means a page came back with fewer rows than the server’s own total implied, which is the quiet failure this dataset refuses to hide: it is published as data rather than left in a log line. - `truncated` BOOLEAN NOT NULL — True when the server still answered searchTooLong for this slice after every splitting axis had been used — i.e. rows exist that this run could not reach. This is the flag that makes the cap visible instead of silent; a reader aggregating a day should check it before quoting a total. - `snapshot_date` DATE NOT NULL — The ingest run’s own snapshot day (UTC). - `ingested_at` TIMESTAMP NOT NULL — When this row was produced by the ingest run (UTC). ## Performance notes - There are no indexes in a lakehouse. The physical sort order plus Parquet row-group min/max statistics ARE the index. Predicates on the leading sort columns prune whole row groups; everything else is a full column scan. - `direct_acquisitions` prunes on `finalization_date` → `cpv_division` → `direct_acquisition_id`. - `direct_acquisition_items` prunes on `finalization_date` → `direct_acquisition_id` → `direct_acquisition_item_id`. - `da_award_notices` prunes on `publication_date` → `cpv_division` → `da_award_notice_id`. - `contract_award_notices` prunes on `publication_date` → `cpv_division` → `ca_notice_id`. - `award_notice_contracts` prunes on `publication_date` → `ca_notice_id` → `ca_notice_contract_id`. - `award_notice_winners` prunes on `publication_date` → `ca_notice_id` → `ca_notice_contract_id` → `winner_id`. - `award_notice_lots` prunes on `publication_date` → `ca_notice_id` → `notice_lot_id`. - `contract_notices` prunes on `publication_date` → `cpv_division` → `c_notice_id`. - `tender_lots` prunes on `publication_date` → `c_notice_id` → `notice_lot_id`. - `parties` prunes on `name_lc`. - `cpv_codes` prunes on `cpv_code`. - `cpv_categories` prunes on `category_id`. - `coverage` prunes on `slice_date` → `endpoint` → `cpv_category_id`. - `ILIKE '%needle%'` cannot prune: it decompresses that whole column. Prefer prefix predicates on the lowercased search companion columns where they exist. - Every file URL under `/v//` is immutable. Cache it as aggressively as you like. - Files are never rewritten in place — a new ingest writes a new version path. Re-read the manifest to pick up updates rather than polling the file URLs. - Pull only the columns you need. Parquet is columnar and the reader range-GETs what it reads. ## Do not - Do not scrape https://date-deschise.bunnytech.app HTML. Every number on those pages comes from the manifest above. - Do not hit the upstream source (https://e-licitatie.ro/pub) in bulk. This mirror exists so you do not have to. - Do not read DuckLake internal data files with a plain Parquet reader. They come with positional delete files, and ignoring those silently returns deleted rows. Use the ducklake extension, or use the published exports above. - Do not republish without the attribution line, and do not imply endorsement.