Argentina COMPR.AR Calls for Tender - Per Process

Argentine calls for tender - the COMPR.AR procurement processes (convocatorias) across all published years as clean, per-process records. Procedure, executing unit, publication and opening dates, stage, scope, name and object, and estimated amount. Process grain - no award, no supplier, no person field.

What one record represents

The source is COMPR.AR (Sistema de Contrataciones Electronicas), Argentina's federal e-procurement system, published as yearly CSV extracts on infra.datos.gob.ar. Each record is one procurement process (call for tender): the procedure number, executing unit and organisational codes, the procedure type and modality, the publication and opening dates, the stage and scope, the procedure name and object, and the estimated amount.

Coverage and volume

The live all-years process total is about 109,914 rows.

Sol's Wave-4 index put this door at 128,951 calls for tender; measured live at build time the published all-years extracts total about 109,914 process rows - the live figure is what this listing quotes.

Licence and attribution

The data is published under CC BY 4.0. The full notice travels on every record:

Argentina open data (datos.gob.ar), CC BY 4.0. Reproduced unchanged with attribution to the source.

Person-data policy

This is the process grain - a call for tender carries no award and no supplier block, and the extract has no person field at all (confirmed at the column level). A per-record assertion rejects any person field as a matter of form. The executing unit is a government body. No natural-person data is processed.

Interpretation caveat

One record per Argentine federal call for tender (procurement process) across all published years: procedure, executing unit, publication and opening dates, stage, scope, procedure name and object, and estimated amount. Process grain - no award or supplier block, and no person field.

Values are reproduced verbatim from the extracts; the Actor never rewrites a field. The estimated amount is kept as the source's own verbatim value.

Provenance and compliance

Every run reads the door host's robots.txt at runtime; the gate result (URL, status, byte length and, where a policy is served, its SHA-256) is written to the run's RUN_RECEIPT. Where the host serves no applicable robots rule, the gate records that (flagged) and proceeds on the licence, which grants re-use. The endpoint is keyless. The Actor never bypasses a block or fetches through a mirror.

Data quality and freshness

Boolean columns are delivered as real booleans and numeric columns as real numbers. Delivery is keyed on a stable id, so the dataset is safe to diff, deduplicate or upsert. Every run re-reads the live door, so the data is as fresh as the source publishes, and each record's observed_at stamp dates the snapshot. The run's RUN_RECEIPT records the source URL and how many records were delivered and charged, and confirms charge_equals_delivered.

Billing, delivery and joins

Pricing is per record: you are billed only for records the Actor actually delivers, with the charge raised after each record is pushed (push-then-charge), so a failed or empty run costs nothing. The Maximum records cap bounds every run, so you control spend precisely - sample cheaply, then raise it. Every record is a flat, typed object keyed on a stable id, so the data loads without a cleaning pass, diffs cleanly between runs, and upserts into a table you maintain over time; re-running keeps that table current without re-paying for rows you already hold, and each receipt reconciles delivered against charged. Because the source's own identifiers are preserved verbatim, the dataset joins cleanly onto other sources keyed on the same identifier.

Scaling and scheduling

Set Maximum records low to sample the shape of the data cheaply, then raise it once the cell fits your use. The Actor delivers incrementally and streams its source, so memory stays flat regardless of how many records you request, and you are billed only for what is delivered. Because the source republishes on its own cadence, a scheduled run keeps a downstream table current: new and changed records upsert over the old ones on the stable key, and the observed_at stamp on every record tells you when each was last seen live. There is no subscription and no minimum - the per-record price and the record cap together mean the spend on any run is known in advance and matched exactly to the data you receive.

Inputs

• Maximum records (maxRecords) - hard cap on process records delivered and billed.

Output

Records land in the Actor's default dataset and export as JSON, CSV, Excel or via the Apify API. A tabular overview surfaces procedure, publication date, procedure name, type, estimated amount and stage.

Fields in detail

The record leads with procedure_number, the SAF/UOC codes, procedure_type, modality, fiscal_year, publication_date, opening_date, stage, scope, procedure_name, procedure_object, estimated_amount and operation_type. The provenance block closes every record.

Typical uses

Analysts and bid teams use this cell to track Argentine federal calls for tender - what is being procured, by which unit, when it opens - as a flat, person-free process table. Because the procedure type, dates and object are first-class fields, a filter surfaces every open process in a category, and the procedure number joins to the awards cell to follow a process through to its winner.

Award and process, joined

This cell and the COMPR.AR awards cell are the two grains of the same system: this one is the call for tender (the process - what was put out to bid), and the awards cell is the outcome (who won). They share the procedure number, so a join on procedure_number traces a process from its publication through to its award and supplier. Keeping them as two cells rather than one flattened table means each stays at its natural grain - a process has one row here even when it produced many award documents - and you assemble the funnel yourself with a join when you need it. That separation also means each cell stays cheap and fast on its own: you can track new calls for tender here on a tight schedule without ever pulling the heavier award documents, and reach for the awards cell only when you want to know who won.

Reconciling with the index

The live all-years extract total differs from the figure the research index cited, which is expected: the published CSVs are re-issued over time and the yearly files shift as records are corrected or consolidated, so the live count is the honest measure and is what this listing quotes. The cell delivers the complete published set at the process grain, keyed on the procedure and organisational codes so it upserts cleanly, and a scheduled run picks up new processes as the extracts are refreshed. Because the process grain carries no person field at all, the whole table is clean to redistribute under CC BY 4.0 with attribution, and it pairs with the awards cell to give the full procurement funnel from call to contract without ever touching personal data on either side.

Sibling Actors

It sits beside the Argentina contract-awards cell (same door, award grain - join on the procedure number) and the fleet's Brazil PNCP tender-notices cell. It shares its multi-CSV engineering with the fleet's other records Actors.