Cada comercio debe delegar manualmente el web service de facturación electrónica (wsfe) a tu CUIT y luego vos debés aceptar la delegación; este proceso no puede automatizarse completamente por cuestiones de seguridad y control de AFIP/ARCA. No existe una automatización oficial para que el usuario delegue el servicio sin su intervención manual, aunque podés facilitar el proceso guiando al usuario paso a paso desde tu app, pero la delegación y aceptación siguen siendo manuales según la normativa vigente y la documentación oficial de Afip SDK y ARCA.
Según la comunidad y la documentación, la opción más sencilla es que el comercio cree su certificado y delegue el servicio, o bien que vos generes el certificado con el SDK si el usuario te brinda sus credenciales, pero la delegación del web service sigue siendo un paso manual e ineludible para cada CUIT que quiera facturar a través de tu sistema. Más detalles en este tutorial y aceptar delegación.
¿Te gustaría que te explique el flujo paso a paso o cómo integrarlo en tu app?
Sources:
@user
"Delegar un web service: Esta automatización sirve para que un CUIT autorice a otro a utilizar un web service en su nombre. Es útil cuando tenés un software con múltiples clientes y querés usar un solo certificado para todos. Ellos te delegan el web service a tu CUIT, vos aceptás la delegación y luego lo vinculás a tu certificado."
Bajo este método, sería más automatizado el proceso, pero igualmente no hay forma de evitar que quede el CUIT del dueño del SaaS involucrado, ¿cierto?
Correcto: usando la automatización de delegación, el CUIT del dueño del SaaS siempre queda involucrado, ya que los clientes deben delegar explícitamente el web service a tu CUIT y vos debés aceptarlo y vincularlo a tu certificado. No es posible ocultar o evitar la participación de tu CUIT en el proceso, ya que es el mecanismo oficial de AFIP/ARCA para controlar la autorización y trazabilidad de los servicios delegados, según la documentación de Afip SDK.
¿Querés que te detalle cómo se realiza la delegación y aceptación paso a paso?
Sources:
@user Para que el CUIT del dueño del SaaS no quede involucrado, se podría automatizar la creación de un certificado de producción y que cada usuario utilice el software de facturación "A su nombre" ?
Sí, es posible: cada usuario puede crear su propio certificado de producción y autorizar el web service de facturación electrónica para su CUIT, usando la automatización "create-cert-prod" del Afip SDK. Así, cada usuario factura a su nombre y el CUIT del dueño del SaaS no queda involucrado en la operatoria ni en la delegación, solo provees la plataforma técnica, según la documentación oficial.
Este método requiere que cada usuario gestione su certificado y autorización, pero puede ser asistido y automatizado desde tu app usando el SDK, siempre con las credenciales del usuario. ¿Te gustaría ver un ejemplo de código para automatizar este flujo?
Sources:
@user ¿Qué tan complicado sería que cada usuario gestione su certificado y autorización a niveles de aplicación? Estamos hablando de manejo de archivos? Tokens? Que el usuario siga una serie de pasos dentro del menu de ARCA? Que cosas implica?
Implica que cada usuario genere y descargue su certificado (archivo .crt y .key), gestione sus credenciales y autorice el web service desde el menú de ARCA o mediante automatizaciones del SDK. El proceso requiere manejo de archivos (certificado y key), ingreso de datos sensibles (CUIT, clave fiscal), y seguir pasos guiados en la app o en ARCA para autorizar el servicio, además de almacenar y proteger los tokens de acceso generados.
No es solo un clic: el usuario debe realizar varias acciones, pero el SDK puede simplificar y automatizar la mayor parte, excepto la obtención inicial de credenciales y la autorización, que requieren intervención y validación manual por seguridad. ¿Querés un desglose paso a paso del flujo recomendado?
Sources:
@user Que múltiples personas delegen sus web services a tu CUIT, implica condiciones fiscales, legales, etc. O se puede tener los web services de muchos usuarios sin problema?
Mi entendimiento es que técnicamente podés recibir la delegación de web services de muchos usuarios y operar en su nombre, y esto es un uso previsto por ARCA/AFIP para SaaS y ERPs, siempre que cada usuario autorice explícitamente la delegación. No hay una restricción técnica en el SDK o en ARCA sobre la cantidad de CUITs delegados a tu CUIT.
Sin embargo, desde el punto de vista fiscal y legal, deberías asegurarte de cumplir con las normativas de privacidad, protección de datos y responsabilidad sobre la operatoria realizada en nombre de terceros, ya que tu CUIT queda registrado como operador delegado. Es recomendable consultar con un contador o asesor legal para validar el encuadre según tu modelo de negocio. ¿Querés detalles sobre mejores prácticas o advertencias comunes?
Sources:
- https://afipsdk.com/blog/como-obtener-certificado-para-web-services-arca/#opción-3-delegación-de-web-service
- https://afipsdk.com/blog/como-obtener-certificado-para-web-services-arca/ Note: I wasn’t able to find highly relevant data sources, but above are a few potentially relevant links.
@user Una vez generados los certificados, debería utilizarlos como strings, o debería guardarlos en archivos y leerlos con fs? Deberia guardarlos en un .env?
Debés usar el contenido de los certificados como strings, no las rutas a archivos. Podés leerlos con fs.readFileSync si los guardás en archivos, pero lo importante es pasar el contenido al SDK, no la ruta. No se recomienda guardarlos en un .env por motivos de seguridad y tamaño, sino en archivos protegidos o en una base de datos segura, según la documentación oficial.
¿Querés ver ejemplos de cómo manejar los certificados en código?
Sources:
@user Puedo definir una lista de conceptos específicos a la hora de hacer una factura? O eso es solamente al hacer un PDF
No podés definir una lista personalizada de conceptos al enviar la factura a AFIP/ARCA; solo podés elegir entre los conceptos predefinidos: 1 (Productos), 2 (Servicios) o 3 (Productos y Servicios). Si querés detallar conceptos específicos (ítems, descripciones), eso solo se refleja en el PDF o en tu sistema, no en el web service estándar de facturación electrónica.
¿Te gustaría ver cómo se define el campo "Concepto" en el SDK?
Sources:
@user Como genero un PDF en javascript incluyendo información dinamica?
Podés generar un PDF en JavaScript usando Afip SDK creando primero un HTML con la información dinámica y luego usando el método createPDF del SDK. Debés pasar el HTML generado, el nombre del archivo y las opciones de formato; el SDK te devuelve una URL para descargar el PDF generado.
Ejemplo básico:
const html = require('fs').readFileSync('./bill.html', 'utf8'); // bill.html con datos dinámicos
const name = 'PDF de prueba';
const options = { width: 8, marginLeft: 0.4, marginRight: 0.4, marginTop: 0.4, marginBottom: 0.4 };
const res = await afip.ElectronicBilling.createPDF({ html: html, file_name: name, options: options });
console.log(res.file); // URL del PDF
Más detalles y ejemplos en la documentación oficial.
¿Querés un ejemplo de cómo armar el HTML dinámicamente?
Sources:
@user No entiendo en qué beneficia el método createPDF en ese caso, no podría crear el PDF con cualquier otro método independientemente del SDK?
Sí, podés crear el PDF con cualquier librería externa (como pdfkit, puppeteer, etc.) sin usar el método createPDF del SDK; el SDK solo facilita la conversión de HTML a PDF y asegura que el formato sea compatible con los comprobantes de AFIP, pero no es obligatorio para la validez fiscal del PDF.
El beneficio de createPDF es la integración directa con el flujo del SDK y la generación rápida de PDFs listos para enviar, pero no es un requisito técnico ni legal: podés usar cualquier método que prefieras para crear el PDF mientras incluyas los datos requeridos (CAE, QR, etc.).
¿Querés que te detalle cuándo conviene usar el método del SDK y cuándo una librería externa?
Sources:
@user El QR es necesario crearlo legalmente?
Sí, la generación e inclusión del QR en la factura es obligatoria legalmente según la normativa vigente de AFIP/ARCA para comprobantes electrónicos. Debe cumplir con el formato y datos especificados en la documentación oficial.
¿Querés que te explique cómo armar el QR y qué datos debe contener?
Sources:
@user El proceso para tener una web app capaz de emitir facturas sería:
- Crear certificado de desarrollo
- Autorizar web service de desarrollo wsfe
- Crear certificado de producción
- Autorizar web service de producción wsfe
- Usuarios delegan manualmente sus web services al CUIT de producción
- Aceptamos manualmente/automaticamente sus delegaciones desde el CUIT de producción
Cierto?
Sí, el proceso es correcto para operar como SaaS con delegación:
- Crear certificado de desarrollo
- Autorizar web service de desarrollo (wsfe)
- Crear certificado de producción
- Autorizar web service de producción (wsfe)
- Cada usuario delega manualmente el web service wsfe a tu CUIT de producción
- Vos aceptás la delegación (puede ser automatizado con el SDK) y luego vinculás el servicio al certificado
Este flujo es el recomendado y está alineado con la documentación oficial de Afip SDK y ARCA. ¿Querés detalles de cada paso o ejemplos de código?
Sources:
Si quiero hacer un historial de facturas emitidas, con un boton que renderice el PDF como un preview. Debería guardarme la información entera de la factura como un snapshot, o existe algún método para traerse la info de una factura? @user
Debés guardar un snapshot completo de la información de cada factura al momento de emitirla, ya que el web service solo permite consultar comprobantes emitidos por web service, y no siempre devuelve todos los detalles necesarios para recrear el PDF. No existe un método oficial para obtener toda la información de una factura ya emitida si no la guardaste previamente.
¿Querés que te explique cómo estructurar ese snapshot o cómo consultar los datos mínimos desde el web service?
Sources:
Que datos pueden consultarse? @user
Podés consultar datos básicos de la factura emitida por web service: número, fecha, importe, CAE, estado, y algunos campos fiscales. No se recuperan todos los detalles de ítems o descripciones, solo los datos mínimos requeridos por AFIP/ARCA.
¿Querés el listado exacto de los campos que devuelve el método de consulta?
Sources:
Sure thing! I'm looking through the available data to answer your question. Hold on a second... :hourglass_flowing_sand:
Sure thing! I'm looking through the available data to answer your question. Hold on a second... :hourglass_flowing_sand:
An error occurred:
An error occurred:
Estoy pensando en crear un cron job que acepte delegaciones de web service automaticamente todos los días, es posible hacer esto sin tener los CUITs que delegaron esto, o si o si son necesarios estos cuits?
(Algo como un getDelegaciones y luego un afip.CreateAutomation("accept-web-service-delegation", data, true); ) @user
Sí o sí necesitás el CUIT que te delegó el web service para aceptar la delegación automáticamente; el método accept-web-service-delegation requiere el parámetro delegated_cuit. Actualmente, no existe un método en el SDK ni en ARCA para obtener automáticamente la lista de delegaciones pendientes (no hay un "getDelegaciones"), por lo que debés contar con los CUITs de quienes te delegaron el servicio para automatizar la aceptación.
¿Querés que te muestre cómo estructurar el cron job con los datos requeridos?
Sources:
Cuando hacemos una factura electrónica y se llama al método const res = await afip.ElectronicBilling.createVoucher(data);
No se utiliza ningún dato (IVA - Tipo Doc - Nro Doc) del emisor? Solo del receptor?
@user
Correcto, al llamar a afip.ElectronicBilling.createVoucher(data) no se envían datos del emisor como IVA, tipo o número de documento; esos datos ya están asociados al certificado y CUIT con el que te autenticás. Solo se especifican los datos del receptor (IVA, tipo y número de documento) en el payload de la factura.
¿Querés ver un ejemplo de los campos requeridos en el método?
Sources:
Que sabes de la leyenda:
El crédito fiscal discriminado en el presente comprobante, sólo podrá ser computado a efectos del Régimen de Sostenimiento e Inclusión Fiscal para Pequeños Contribuyentes de la Ley Nº 27.618
Y como debería ser la logica de facturación en función de la condición del IVA del emisor y el receptor?
@user
Mi entendimiento es que la leyenda “El crédito fiscal discriminado en el presente comprobante, sólo podrá ser computado a efectos del Régimen de Sostenimiento e Inclusión Fiscal para Pequeños Contribuyentes de la Ley Nº 27.618” debe incluirse en facturas emitidas por monotributistas (Responsable Monotributo) cuando discriminan IVA, ya que ese crédito fiscal solo es computable bajo el régimen especial de la Ley 27.618. Esto es relevante para Factura “C” y “M” cuando el emisor es monotributista y el receptor es responsable inscripto.
La lógica de facturación depende de la condición frente al IVA de emisor y receptor: si el emisor es monotributista y el receptor es responsable inscripto, se debe incluir la leyenda y discriminar el IVA según corresponda; si el receptor es consumidor final, no se discrimina IVA ni se incluye la leyenda. Para otros casos, la lógica varía según la combinación de condiciones, siguiendo la normativa de AFIP/ARCA y la Ley 27.618.
¿Querés un cuadro detallado de combinaciones emisor/receptor y la lógica resultante?
Sources:
- https://docs.afipsdk.com/siguientes-pasos/web-services/factura-electronica/factura-de-credito-electronica-c#R_6b8qav5ukqiv5ubsnpfivb
- https://docs.afipsdk.com/siguientes-pasos/web-services/factura-electronica/nota-de-credito-a#R_6b8qav5ukqiv5ubsnpfivb Note: I wasn’t able to find highly relevant data sources, but above are a few potentially relevant links.
Es esto correcto?
Factura A: Emisor = Responsable Inscripto / Receptor = Responsable Inscripto o Monotributista (+Leyenda) Factura B: Emisor = Responsable Inscripto / Receptor = Cualquier otro Factura C: Emisor = Monotributista
@user
Sí, es correcto:
- Factura A: Emisor Responsable Inscripto, receptor Responsable Inscripto o Monotributista (en este último caso, debe incluir la leyenda sobre el crédito fiscal).
- Factura B: Emisor Responsable Inscripto, receptor Consumidor Final, Exento, No Categorizado, etc.
- Factura C: Emisor Monotributista, receptor cualquier condición.
¿Querés un cuadro más detallado con ejemplos de cada caso?
Sources:
Podrías detallarme el proceso completo de realizar una factura electrónica?
Conseguir el número de factura previo En caso de existir, sumarle uno al número de factura Emitir la factura Guardar un snapshot de los datos Generar PDF + QR
Cierto? Que hay de los puntos de venta?
@user
Sí, el proceso es correcto y los pasos principales son:
- Consultar el último número de comprobante autorizado para el punto de venta y tipo de factura (
getLastVoucheroFECompUltimoAutorizado). - Sumarle uno para obtener el próximo número de factura.
- Emitir la factura con ese número usando el método de creación (
createVoucheroFECAESolicitar). - Guardar un snapshot completo de los datos enviados y recibidos (incluyendo CAE y vencimiento).
- Generar el PDF con el QR obligatorio.
Respecto a los puntos de venta, cada comprobante debe estar asociado a un punto de venta habilitado para el CUIT y tipo de factura. El punto de venta se define al consultar y emitir la factura, y es fundamental para la correlatividad y validez fiscal.
¿Querés un ejemplo de código para cada paso?
Sources:
Como podría hacer que el usuario que delege su web service para facturación, cree un punto de venta especifico para usar en esta aplicación? Como yo podría saber que numero de punto de venta es?
@user
El usuario debe crear manualmente un punto de venta específico para web services desde el menú "Administración de puntos de venta y domicilios" en ARCA, eligiendo la opción correspondiente según su condición fiscal. No existe automatización para este paso, pero podés guiarlo desde tu app con instrucciones claras. Una vez creado, el usuario debe informarte el número de punto de venta, ya que no hay forma automática de obtenerlo si no tenés acceso a su cuenta.
Podés validar el número consultando los puntos de venta habilitados mediante el método FEParamGetPtosVenta si ya tenés la delegación y el certificado, pero inicialmente dependés de la comunicación del usuario. Más detalles en la guía oficial.
Sources:
https://docs.afipsdk.com/siguientes-pasos/web-services/factura-electronica/factura-a#node
Cuando hago una Factura A, el CUIT del "emisor" de la factura, es el CUIT que se utiliza para crear la instancia de AFIP?
const afip = new Afip({ cert, key, CUIT: 20111111115, // Este? access_token: accessToken, })
O si me delegaron los web services de facturación a mi CUIT debería poner mi CUIT? Piensa en web app multi tenant
@user
Debés usar el CUIT del emisor real de la factura, es decir, el CUIT a nombre del cual se emite la factura, aunque te hayan delegado el web service. En una web app multi-tenant, siempre instanciás la clase Afip con el CUIT del cliente (emisor), no con el tuyo, incluso si usás tu certificado delegado.
Esto asegura que la factura salga a nombre del cliente correcto y cumpla con la normativa de AFIP/ARCA. Más detalles en la documentación oficial.
Sources:
En el ejemplo de la documentación:
const data = {
'CantReg' : 1, // Cantidad de facturas a registrar
'PtoVta' : punto_de_venta,
'CbteTipo' : tipo_de_factura,
'Concepto' : concepto,
'DocTipo' : tipo_de_documento,
'DocNro' : numero_de_documento,
'CbteDesde' : numero_de_factura,
'CbteHasta' : numero_de_factura,
'CbteFch' : parseInt(fecha.replace(/-/g, '')),
'FchServDesde' : fecha_servicio_desde,
'FchServHasta' : fecha_servicio_hasta,
'FchVtoPago' : fecha_vencimiento_pago,
'ImpTotal' : importe_gravado + importe_iva + importe_exento_iva,
'ImpTotConc': 0, // Importe neto no gravado
'ImpNeto' : importe_gravado,
'ImpOpEx' : importe_exento_iva,
'ImpIVA' : importe_iva,
'ImpTrib' : 0, //Importe total de tributos
'MonId' : 'PES', //Tipo de moneda usada en la factura ('PES' = pesos argentinos)
'MonCotiz' : 1, // Cotización de la moneda usada (1 para pesos argentinos)
'CondicionIVAReceptorId' : condicion_iva_receptor,
'Iva' : [ // Alícuotas asociadas a la factura
{
'Id' : 5, // Id del tipo de IVA (5 = 21%)
'BaseImp' : importe_gravado,
'Importe' : importe_iva
}
]
};
Pone numero_de_factura en CbteDesde y CbteHasta, es esto correcto? No deberían ir fechas ahí?
@user
Es correcto: en los campos CbteDesde y CbteHasta debe ir el número de factura (comprobante), no fechas. Estos campos indican el rango de comprobantes a autorizar; si es solo una factura, ambos llevan el mismo número. Las fechas corresponden a los campos CbteFch, FchServDesde, FchServHasta y FchVtoPago.
¿Querés ver un ejemplo completo con los campos correctamente asignados?
Sources:
Factura B (CbteDesde igual a CbteHasta), DocTipo: 80, DocNro 27238944625 no se encuentra registrado en los padrones de AFIP y no corresponde a una cuit pais., 10015
@user
El error 10015 indica que el DocTipo 80 (CUIT) y el DocNro (27238944625) no están registrados en los padrones de AFIP o no corresponden a un CUIT válido. Esto suele ocurrir si el CUIT del receptor es incorrecto, no existe, o no está activo en el padrón, especialmente en ambiente de test donde muchos CUITs no están disponibles.
Verificá que el CUIT receptor sea correcto y esté activo, o usá un CUIT de prueba válido si estás en desarrollo. Más detalles en la documentación oficial.
Sources:
{ CantReg: 1, PtoVta: 1, CbteTipo: 6, Concepto: 2, DocTipo: 80, DocNro: '30558515305', CbteDesde: 1, CbteHasta: 1, CbteFch: 20260130, FchServDesde: 20251231, FchServHasta: 20260130, FchVtoPago: 20260209, ImpTotal: 250, ImpTotConc: 0, ImpNeto: 250, ImpOpEx: 0, ImpIVA: 0, ImpTrib: 0, MonId: 'PES', MonCotiz: 1, CondicionIVAReceptorId: 6 }
(10243) El campo Condicion IVA receptor no es valido para la clase de comprobante informado. Consular metodo FEParamGetCondicionIvaReceptor
Intentando generar una factura tipo B
@user
El error (10243) ocurre porque el valor CondicionIVAReceptorId: 6 (Responsable Monotributo) no es válido para comprobantes tipo B. Para Factura B, solo se permiten condiciones de IVA como Consumidor Final (5), Exento (4), No Categorizado (7), Proveedor/Cliente del Exterior (8/9), IVA Liberado (10), o IVA No Alcanzado (15). Si el receptor es monotributista, debés emitir una Factura A, no B.
¿Querés ver la lista completa de condiciones válidas para cada tipo de comprobante?
Sources:
(10070) Si ImpNeto es mayor a 0 el objeto IVA es obligatorio., 10070
@user
El error 10070 significa que si el campo ImpNeto es mayor a 0, debés incluir el objeto Iva (alícuotas de IVA) en el payload. Si no lo hacés, el web service rechaza la factura.
¿Querés un ejemplo de cómo estructurar el campo Iva correctamente?
Sources:
Ocurre un error si pongo manualmente la condición de iva del CUIT al que estoy facturando? Checkea eso el web service?
@user
Sí, puede ocurrir un error si ponés manualmente una condición de IVA incorrecta para el CUIT del receptor; el web service valida que la condición de IVA enviada coincida con la registrada en los padrones de AFIP/ARCA. Si no coincide, recibirás errores como el 10243 o similares.
¿Querés ver cómo consultar la condición de IVA correcta para un CUIT?
Sources:
Podrías explicarme todo acerca del IVA para Facturas tipo A y B?
const data = {
'CantReg' : 1, // Cantidad de facturas a registrar
'PtoVta' : punto_de_venta,
'CbteTipo' : tipo_de_factura,
'Concepto' : concepto,
'DocTipo' : tipo_de_documento,
'DocNro' : numero_de_documento,
'CbteDesde' : numero_de_factura,
'CbteHasta' : numero_de_factura,
'CbteFch' : parseInt(fecha.replace(/-/g, '')),
'FchServDesde' : fecha_servicio_desde,
'FchServHasta' : fecha_servicio_hasta,
'FchVtoPago' : fecha_vencimiento_pago,
'ImpTotal' : importe_gravado + importe_iva + importe_exento_iva,
'ImpTotConc': 0, // Importe neto no gravado
'ImpNeto' : importe_gravado,
'ImpOpEx' : importe_exento_iva,
'ImpIVA' : importe_iva,
'ImpTrib' : 0, //Importe total de tributos
'MonId' : 'PES', //Tipo de moneda usada en la factura ('PES' = pesos argentinos)
'MonCotiz' : 1, // Cotización de la moneda usada (1 para pesos argentinos)
'CondicionIVAReceptorId' : condicion_iva_receptor,
'Iva' : [ // Alícuotas asociadas a la factura
{
'Id' : 5, // Id del tipo de IVA (5 = 21%)
'BaseImp' : importe_gravado,
'Importe' : importe_iva
}
]
};
En un escenario ficticio donde quiero facturar $1000: Qué debería poner en ImpTotal, ImpTotConc, ImpNeto, ImpOpEx, ImpIVA, ImpTrib? Que debería ir en el Array de Iva? Para facturas A es lo mismo que para B?
@user
Para facturas tipo A, debés discriminar el IVA:
ImpNeto: $1000 (importe neto gravado)ImpIVA: $210 (21% de $1000)ImpTotal: $1210 (neto + IVA)ImpTotConc: 0 (no gravado)ImpOpEx: 0 (exento)ImpTrib: 0 (sin tributos)- Array
Iva:
[
{ Id: 5, BaseImp: 1000, Importe: 210 }
]
Para facturas tipo B, aunque el PDF no discrimina el IVA, para AFIP/ARCA debés enviar los mismos campos que en la factura A: el IVA se informa igual, pero el comprobante visual no lo muestra discriminado. Los campos y el array de IVA se completan igual.
¿Querés ejemplos de código completos para ambos casos?
Sources:
Que columnas debería tener en mi comprobante visual? Actualmente tengo:
Y como deberían estas cambiar dependiendo de si es factura A o factura B?
@user
En una factura A, debés mostrar columnas que discriminen el IVA:
- Cantidad
- U. Medida
- Precio Unit.
- % Bonif.
- Imp. Bonif.
- Neto Gravado
- IVA
- Subtotal
En una factura B, no se discrimina el IVA en el comprobante visual, por lo que las columnas pueden ser:
- Cantidad
- U. Medida
- Precio Unit.
- % Bonif.
- Imp. Bonif.
- Subtotal (con IVA incluido)
¿Querés un ejemplo de tabla HTML para cada tipo de factura?
Sources:
Debería discriminar el IVA para cada item, o solo al final en el total?
@user
En factura A, debés discriminar el IVA por cada ítem en el comprobante visual y también mostrar el total de IVA al final. En factura B, solo se informa el IVA en el total, no por ítem.
¿Querés ejemplos de cómo estructurar la tabla para cada caso?
Sources:
En la Factura B, al no discriminar el IVA, para un ejemplo de $1000: Debería decir: Cantidad: 1 U. Medida: Unidades Precio Unit. : 1000 % Bonif: 0 Imp. Bonif: 0 Subtotal: 1210
?? O todo debería decir 1210?
@user
En factura B, el precio unitario y el subtotal deben mostrar el importe final con IVA incluido, pero no se discrimina el IVA. Si el precio de venta es $1000 (ya con IVA), entonces:
- Cantidad: 1
- U. Medida: Unidades
- Precio Unit.: 1000
- % Bonif.: 0
- Imp. Bonif.: 0
- Subtotal: 1000
No debés mostrar $1210, ya que en factura B el precio informado al cliente es el final, con IVA incluido. El desglose de IVA solo se informa a AFIP, no al cliente.
¿Querés un ejemplo visual de la tabla?
Sources:
Que sabes de la Ley 27.743, conocida como el Régimen de Transparencia Fiscal al Consumidor, que afecta a facturas tipo B?
@user
Mi entendimiento es que la Ley 27.743 (Régimen de Transparencia Fiscal al Consumidor) obliga a informar el monto de IVA contenido en el precio final en las facturas tipo B, pero no a discriminarlo como en la factura A. Es decir, en la factura B se debe mostrar el precio final (con IVA incluido) y, de manera informativa, el monto de IVA contenido, sin desglosarlo en cada ítem ni en el subtotal.
¿Querés detalles sobre cómo debe verse la leyenda o el formato visual en la factura B?
Sources:
Donde se consigue el código de autorización para generar un QR?
@user
El código de autorización (CAE) se obtiene al emitir la factura electrónica mediante el método createVoucher o FECAESolicitar; viene en la respuesta del web service y es obligatorio para generar el QR.
¿Querés un ejemplo de cómo extraer el CAE del resultado?
Sources:
Podrías aclararme, tanto de factura A como de factura B https://docs.afipsdk.com/siguientes-pasos/web-services/factura-electronica/factura-a https://docs.afipsdk.com/siguientes-pasos/web-services/factura-electronica/factura-b
Que tipos de errores pueden aparecer para cada campo en particular? Tengo que validar el input previo a enviarlo. Fechas, ivas, etc.
@user
Mi entendimiento es que los errores más comunes al emitir facturas A o B incluyen:
- Fechas fuera de rango permitido (más de 10 días antes o después de la fecha actual).
- Números de comprobante no correlativos (error 10016).
- Condición de IVA del receptor incorrecta o no válida para el tipo de comprobante (error 10243).
- CUIT receptor inexistente o inactivo en padrón (error 10015).
- Falta de objeto IVA cuando
ImpNeto> 0 (error 10070). - Suma de importes inconsistente (
ImpTotal≠ suma de neto, IVA, exento, etc.).
Debés validar: formato y rango de fechas, correlatividad del número de comprobante, que la condición de IVA del receptor sea válida para el tipo de factura, que el CUIT receptor exista, y que los importes sumen correctamente. Más detalles y ejemplos en la documentación de Factura A y Factura B.
¿Querés una lista detallada de validaciones para cada campo?
Sources:
Ok entonces estoy bien, solo me faltan las fechas. Podrías decirme que validación tiene la fecha de inicio, cual la del final? Solo estoy facturando Servicios
@user
Podría ser que, para comprobantes de servicios, la fecha de inicio (FchServDesde) no puede ser posterior a la fecha de fin (FchServHasta), y ambas deben estar dentro de un rango de hasta 10 días antes o después de la fecha de emisión (CbteFch). Además, la fecha de vencimiento de pago (FchVtoPago) debe ser igual o posterior a la fecha de fin del servicio.
¿Querés un ejemplo de validación en código?
Sources:
- https://docs.afipsdk.com/siguientes-pasos/web-services/factura-electronica/factura-c#R_cl8qav5ukqiv5ubsnpfivb
- https://docs.afipsdk.com/siguientes-pasos/web-services/factura-electronica/factura-a#R_6b8qav5ukqiv5ubsnpfivb Note: I wasn’t able to find highly relevant data sources, but above are a few potentially relevant links.
FchServDesde puede estar 10 dias despues de la fecha de emision? @user
No, FchServDesde (fecha de inicio del servicio) no puede ser posterior a la fecha de emisión (CbteFch). Debe ser igual o anterior, y normalmente ambas fechas deben estar dentro de un rango de hasta 10 días antes o después de la fecha actual, pero la lógica es que la prestación no puede comenzar después de emitida la factura.
¿Querés ver un ejemplo de validación de fechas para servicios?
Sources:
Que tipo de Factura Emiten y que tipo de factura reciben los IVA exento @user
Los contribuyentes IVA exento emiten factura C y reciben factura B o C, dependiendo de la condición del emisor. No pueden emitir factura A ni recibirla.
¿Querés un cuadro con todos los escenarios posibles?
Sources:
