# Homologación vs producción en ARCA: diferencias

ARCA (ex AFIP) mantiene dos ambientes completamente separados: homologación, para probar, y producción, donde los comprobantes tienen validez fiscal. Entender en qué difieren, y dónde se decide a cuál apunta tu cuenta, evita emitir de más en producción o probar contra un ambiente que no corresponde.

## Los dos ambientes en una tabla

|  | Homologación | Producción |
| --- | --- | --- |
| Para qué sirve | Probar la integración | Emitir comprobantes con validez fiscal |
| CAE | De prueba, **sin validez fiscal** | Válido ante ARCA |
| WSAA | `wsaahomo.afip.gov.ar` | `wsaa.afip.gov.ar` |
| WSFEv1 | `wswhomo.afip.gov.ar` | `servicios1.afip.gov.ar` |
| Certificado | El de homologación, emitido por separado | El de producción |
| Punto de venta | No exige alta previa en ARCA | Debe estar dado de alta y habilitado |
| Receptor con CUIT | Se valida contra el padrón propio de homologación | Se valida contra el padrón real |

## Dónde se decide el ambiente de tu cuenta

En YoFacturo el ambiente es una **configuración de la cuenta**, no un parámetro de cada request. Vive en el contribuyente activo, en el campo `afip_environment`, que vale `testing` (homologación) o `production`. Si el campo falta, se toma `production`. Ningún cuerpo de un request puede forzar el ambiente: todos los comprobantes se autorizan contra el que tiene configurado la cuenta. Es una decisión deliberada, para que un error en un script no emita un comprobante real por accidente.

- Para leerlo: `GET /bill/tax_info/taxpayer/` (scope `accounting:read`) devuelve `afip_environment`.
- Para cambiarlo: `POST /bill/tax_info/afip-environment/` (scope `accounting:write`) con el cuerpo `{"environment": "testing"}` o `{"environment": "production"}`.

Las cuentas de prueba que la plataforma marca como bloqueadas **no pueden pasar a producción** con ese endpoint: el pedido se rechaza y hay que solicitarlo al equipo de YoFacturo. Las rutas son relativas a `https://api.yo-facturo.com/api/v1`.

## Qué CUIT y qué certificado se usan en homologación

En homologación no necesitás tener tu propio certificado ni haber delegado nada. Una cuenta en `testing` siempre emite con el **CUIT de homologación de la plataforma** y su certificado de homologación, aunque tengas tu CUIT real cargado en el perfil fiscal. Seguís viendo tu CUIT en la interfaz y en los payloads; el intercambio con ARCA es interno. Esto se aplica solo en `testing`: en producción emitís como tu CUIT, con la delegación aceptada (ver [delegación](https://yo-facturo.com/dev/arca/delegar-web-service-facturacion/)).

## Puntos de venta y numeración: la trampa de compartir CUIT

Como todas las cuentas de homologación comparten el CUIT de la plataforma, también comparten la numeración: ARCA lleva la secuencia por combinación de CUIT, punto de venta y tipo de comprobante. Dos equipos probando el mismo punto de venta y el mismo tipo se pisan los números. La salida es simple y está permitida: **elegí un punto de venta que no usen otros**. En homologación no hace falta registrarlo en ARCA. En una prueba real, una Factura B emitida sobre un punto de venta inexistente obtuvo CAE igual.

En producción es al revés: el punto de venta tiene que estar dado de alta como de tipo web service. Si no lo está, ARCA responde `11002` o `501`, y YoFacturo consulta los puntos de venta habilitados para decirte cuáles sí funcionan. El alta se explica en la guía de punto de venta.

Hay una excepción: el punto de venta de **CAEA** debe estar registrado como tal en ARCA aun en homologación. Si no, los informes fallan con `1204`. Se cuenta en la guía de CAEA por API.

La numeración local de YoFacturo también distingue ambientes: el contador es por cliente, CUIT, punto de venta, tipo y ambiente. Emitir en `testing` no mueve el contador de producción.

## Un error típico de homologación: el receptor

Si emitís una factura A con el CUIT de un receptor y ARCA responde `10069`, el motivo es que homologación valida el CUIT del receptor contra **su propio** padrón. Un CUIT con el dígito verificador correcto no alcanza. Para probar, usá un documento que exista en ese padrón o un DNI (`tipo_documento` 96).

## Checklist antes de pasar a producción

1. La delegación del web service de facturación da `delegation_verified: true` (`POST /bill/tax_info/verify-delegation/`).
2. El punto de venta de tipo web service existe y `POST /bill/tax_info/verify-punto-venta/` lo marca como válido.
3. `GET /bill/receipts/supported-types/` lista los tipos de comprobante que vas a emitir para tu condición fiscal.
4. Cambiás la cuenta con `POST /bill/tax_info/afip-environment/`.
5. Antes de emitir, consultás el último número autorizado con `GET /afip_ws/ws/voucher-last/{sale_point}/{voucher_type}/`. La respuesta incluye el campo `environment`, para que no compares contra un ambiente que no es el tuyo.

Mientras integrás y probás, mantené la cuenta en `testing`. Para ver qué cubre la API, mirá la página de [facturación electrónica por API](https://yo-facturo.com/api-facturacion/).

## Seguí leyendo

- [WSAA de ARCA explicado](https://yo-facturo.com/dev/arca/wsaa-explicado/)
- [Certificado digital para web services](https://yo-facturo.com/dev/arca/certificado-web-service/)
- [API de facturación electrónica de YoFacturo](https://yo-facturo.com/api-facturacion/)

Fuente: https://yo-facturo.com/dev/arca/homologacion-vs-produccion/