[Sebastián Gurpegui]

Estimados,

En la empresa estuvimos intentando hacer funcionar la factura electrónica pero no damos con la solución al siguiente problema:

Luego de clickear en el botón “Completar”, el sistema procesa y al instante me da el mensaje “La AFIP no aprueba el envio. Por favor corrobore los datos (CUIT, Categoria de IVA, Etc).”

Lo primero que hicimos fue verificar los datos ingresados de nuestra compañía y son todos correctos. El cliente es un consumidor final, con lo cual no tiene CUIT. La misma prueba hicimos con una factura A y el resultado es el mismo.

Por otro lado, el certificado digital es correcto puesto que la validación en línea de comando según el instructivo en el punto 8 fue satisfactoria.

El instructivo menciona el archivo “xmlresponse.xml” como archivo de registro en caso de errores. Lamentablente, allí no encontramos ninguna respuesta.

Seguimos al pie de la letra el instructivo provisto (ServidorOXPdatafacturaElectronicaLBY – Factura Electronica – Puesta en Marcha.pdf) y aún así no logramos hacer funcionar la factura electrónica.

Sistema operativo: Windows Home Basic x64 (se probó también en Windows Server 2008 y Windows Server 2008 R2)
Versión de Libertya: 13.01

Adjunto 3 imágenes:
– El error de la ventana de log
– La pantalla de la factura que da cuenta del error mencionado.
– La prueba satisfactoria del certificado digital (punto 8 del instructivo)

Quisiera saber si alguien tuvo este inconveniente y cómo lo solucionó.

http://i42.tinypic.com/a9q0ir.png
http://i41.tinypic.com/14j9s43.png
http://i40.tinypic.com/2eeh75z.png

[Mario Mauprivez]

Será necesario revisar que sucede localmente con su instalación, ya que la documentación existente sobre FE cubre todos los tópicos necesarios para dejar funcionando la opción. Es probable que exista algo en el stack actual de su servidor que este interfiriendo de alguna forma en la configuración.

Para tener una pista de lo que sucede al menos es necesario revisar los arhivos de la carpeta “pyafipws”, viendo como mínimo: salida.txt ; wsaa.log ; wsfev1.log ; xmlrequest.xml y xmlresponse.xml

Por la naturaleza del trabajo a realizar dificilmente podremos ir más allá en este foro, ya que este proceso puede llevar varias horas, por lo que le sugiero contacte alguno de los partners del producto para solicitar un servicio específico para su instalación.

[Sebastián Gurpegui]

mmaupr wrote:

Será necesario revisar que sucede localmente con su instalación, ya que la documentación existente sobre FE cubre todos los tópicos necesarios para dejar funcionando la opción. Es probable que exista algo en el stack actual de su servidor que este interfiriendo de alguna forma en la configuración.

Para tener una pista de lo que sucede al menos es necesario revisar los arhivos de la carpeta “pyafipws”, viendo como mínimo: salida.txt ; wsaa.log ; wsfev1.log ; xmlrequest.xml y xmlresponse.xml

Por la naturaleza del trabajo a realizar dificilmente podremos ir más allá en este foro, ya que este proceso puede llevar varias horas, por lo que le sugiero contacte alguno de los partners del producto para solicitar un servicio específico para su instalación.

La instalación del software ha sido satisfactoria en todas las instancias de prueba que usamos, con lo cual dudo que el inconveniente venga por ese lado.
En cuanto a los archivos a revisar:
– salida.txt no existe en la carpeta
– wsaa.log ha sido actualizado la última vez el 30/06/2011
– wsfev1.log

Code:

pysimplesoap.__version__ = 1.03f
CERTIFICADO: TLINE3.crt

KEY: TLINE3.key

CUIT: 30710936826

URL_WSFE: https://servicios1.afip.gov.ar/wsfev1/service.asmx?WSDL
LOG: Conectando a wsdl=https://servicios1.afip.gov.ar/wsfev1/service.asmx?WSDL cache=c:pyafipwscache proxy={}

wsfev1.client.help: FECAESolicitar(Auth=*{u’Token’: , u’Sign’: , u’Cuit’: }*, FeCAEReq=*{u’FeCabReq’: *{u’CantReg’: , u’PtoVta’: , u’CbteTipo’: }*, u’FeDetReq’: [*{u’FECAEDetRequest’: *{u’Concepto’: , u’DocTipo’: , u’DocNro’: , u’CbteDesde’: , u’CbteHasta’: , u’CbteFch’: , u’ImpTotal’: ‘>, u’ImpTotConc’: ‘>, u’ImpNeto’: ‘>, u’ImpOpEx’: ‘>, u’ImpTrib’: ‘>, u’ImpIVA’: ‘>, u’FchServDesde’: , u’FchServHasta’: , u’FchVtoPago’: , u’MonId’: , u’MonCotiz’: ‘>, u’CbtesAsoc’: [*{u’CbteAsoc’: *{u’Tipo’: , u’PtoVta’: , u’Nro’: }*}*], u’Tributos’: [*{u’Tributo’: *{u’Id’: ‘>, u’Desc’: , u’BaseImp’: ‘>, u’Alic’: ‘>, u’Importe’: ‘>}*}*], u’Iva’: [*{u’AlicIva’: *{u’Id’: , u’BaseImp’: ‘>, u’Importe’: ‘>}*}*], u’Opcionales’: [*{u’Opcional’: *{u’Id’: , u’Valor’: }*}*]}*}*]}*)
-> **{u’FECAESolicitarResult’: *{u’FeCabResp’: *{u’Cuit’: , u’PtoVta’: , u’CbteTipo’: , u’FchProceso’: , u’CantReg’: , u’Resultado’: , u’Reproceso’: }*, u’FeDetResp’: [*{u’FECAEDetResponse’: *{u’Concepto’: , u’DocTipo’: , u’DocNro’: , u’CbteDesde’: , u’CbteHasta’: , u’CbteFch’: , u’Resultado’: , u’Observaciones’: [*{u’Obs’: *{u’Code’: , u’Msg’: }*}*], u’CAE’: , u’CAEFchVto’: }*}*], u’Events’: [*{u’Evt’: *{u’Code’: , u’Msg’: }*}*], u’Errors’: [*{u’Err’: *{u’Code’: , u’Msg’: }*}*]}*}**:

Solicitud de Código de Autorización Electrónico (CAE)

– xmlrequest.xml ha sido actualizado la última vez el 30/06/2011
– xmlresponse.xml ha sido actualizado la última vez el 30/06/2011

En cuanto al ofrecimiento de soporte, nosotros hemos abonado los cursos funcionales y de parametrización y en ninguno se mencionaba la facturación electrónica.

Como mencioné, hemos seguido al pie de la letra todos los instructivos. Es más, la instalación en la cual se hizo esta ultima prueba es nueva. Simplemente cargamos nuestros datos impositivos, los del cliente, un producto a facturar y nada más. Con esto quiero decir que, en caso de ser un problema de instalación, habría que analizar si los instructivos están bien claros.

[Franco Bonafine]

Hola Tline

En base a tus comentarios tenemos que:

Quote:

– salida.txt no existe en la carpeta

Esto implica que nunca se está generando la respuesta. Es lógico debido al error del WS.

Quote:

– wsaa.log ha sido actualizado la última vez el 30/06/2011

Según este dato no has tenido fallas en la autenticación contra AFIP desde esa fecha. Estamos OK aquí.

Quote:

– wsfev1.log

El log no muestra nada extraño. OK.

Quote:

– xmlrequest.xml ha sido actualizado la última vez el 30/06/2011
– xmlresponse.xml ha sido actualizado la última vez el 30/06/2011

Aquí tenemos el problema. Se supone que en cada invocación al WS de AFIP estos dos archivos se actualizan, y sobre todo el response es el que muestra el código de error de AFIP que luego se puede googlear o consultar con el Ente.

Verificá si el archivo bat “run.bat” tiene el siguiente script adentro:

Code:

cd c:pyafipws
c:Python25python.exe wsfev1.py –archivo [b]–debug[/b] > wsfev1.log

Es importante la línea “–debug” dado que es la que indica al python que genere y cree los archivos xml en el directorio.

Luego de verificar esto, eliminá los dos xml del directorio y probá emitir nuevamente la factura. Ambos archivos deberían ser creados.

[Sebastián Gurpegui]

fbonafine wrote:

Hola Tline

En base a tus comentarios tenemos que:

Quote:

– salida.txt no existe en la carpeta

Esto implica que nunca se está generando la respuesta. Es lógico debido al error del WS.

Quote:

– wsaa.log ha sido actualizado la última vez el 30/06/2011

Según este dato no has tenido fallas en la autenticación contra AFIP desde esa fecha. Estamos OK aquí.

Quote:

– wsfev1.log

El log no muestra nada extraño. OK.

Quote:

– xmlrequest.xml ha sido actualizado la última vez el 30/06/2011
– xmlresponse.xml ha sido actualizado la última vez el 30/06/2011

Aquí tenemos el problema. Se supone que en cada invocación al WS de AFIP estos dos archivos se actualizan, y sobre todo el response es el que muestra el código de error de AFIP que luego se puede googlear o consultar con el Ente.

Verificá si el archivo bat “run.bat” tiene el siguiente script adentro:

cd c:pyafipws
c:Python25python.exe wsfev1.py --archivo --debug > wsfev1.log

Es importante la línea “–debug” dado que es la que indica al python que genere y cree los archivos xml en el directorio.

Luego de verificar esto, eliminá los dos xml del directorio y probá emitir nuevamente la factura. Ambos archivos deberían ser creados.

Fui a buscar el archivo run.bat y efectivamente estaba mal hecho. Dice lo siguiente:

Code:

cd c:pyafipws_prod
c:Python25python.exe wsfev1.py –archivo –debug > wsfev1.log

Esta modificación no está explicada en el instuctivo de facturación electrónica. Dicho de otro modo, sin esta modificación del archivo .bat el aplicativo no iba a funcionar puesto que va a buscar una carpeta inexistente.

Realicé los cambios sugeridos en el archivo run.bat (y runwsaa.bat que también vi que presentaba el mismo error en el directorio) e intenté realizar nuevamente una factura.
– Archivo entrada.txt

Code:

3
3
null
80
23131029829
0.01
0.01
20130529
0
PES
1
5:0.01:0.00

– Archivo salida.txt, xmlresponse.xml y xmlrequest.xml no fueron creados.

[Juan Manuel Martínez]

Estimado,

El error proviene de la tercera línea del archivo “entrada.txt”. En ese campo, la interfaz de Python espera el código de comprobante según las tablas de AFIP (01 factura A, etc); si te fijás en lo que está generado tu instalación, en esa línea aparece un valor “null”.

Consulto ¿la razón social que emite el comprobante es monotributista? Tuve exactamente el mismo problema y lo tuve que solucionar modificando el código de Libertya y el módulo wsfev1.py.

Avisame cualquier cosa y te paso las modificaciones.

Saludos cordiales,
Juan Manuel.

[Sebastián Gurpegui]

funkytorino wrote:

Estimado,

El error proviene de la tercera línea del archivo “entrada.txt”. En ese campo, la interfaz de Python espera el código de comprobante según las tablas de AFIP (01 factura A, etc); si s¡te fijás en lo que está generado tu instalación, en esa línea aparece un valor “null”.

Consulto ¿la razón social que emite el comprobante es monotributista? Tuve exactamente el mismo problema y lo tuve que solucionar modificando el código de Libertya y del módulo wsfev1.py.

Avisame cualquier cosa y te paso las modificaciones.

Saludos cordiales,
Juan Manuel.

No, somos RI y tenemos la facturación electrónica funcionando en otro sistema, de código cerrado.
A mí también me llamó la atención el “null”, pero no se me ocurre a qué puede deberse.

[Juan Manuel Martínez]

Es raro lo que comentás. Con las facturas A o B no tuve el problema que apunté antes; sí apareció cuando quise emitir comprobantes C (en realidad, por lo que encontré, el sistema no está preparado para facturación electrónica en Monotributistas).

Aunque estimo ya lo habrás hecho, te recomendaría que revises la configuración del comprobante (debe aparecer como subtipo Electrónico).

Saludos cordiales,
Juan Manuel.

[Sebastián Gurpegui]

funkytorino wrote:

Es raro lo que comentás. Con las facturas A o B no tuve el problema que apunté antes; sí apareció cuando quise emitir comprobantes C (en realidad, por lo que encontré, el sistema no está preparado para facturación electrónica en Monotributistas).

Aunque estimo ya lo habrás hecho, te recomendaría que revises la configuración del comprobante (debe aparecer como subtipo Electrónico).

Saludos cordiales,
Juan Manuel.

Que lo hayas probado y te haya funcionado me deja bastante tranquilo.
Adjunto una screenshot de cómo está configurada la Factura A, por ejemplo.
http://i39.tinypic.com/jziq06.jpg

[Fabrizio Ravagli]

Hola funkytorino,
justo cuando terminaba de implementar el LIBERTYA en la empresa … el contador me dijo que la Factura Electrónica paso a ser obligatoria por el rubro !!!
Mas complicaciones …
Estoy siguiendo los pasos del pdf Puesta en Marcha y hasta ahora no tuve problema.
Lo único no encuentro por ningún lado el archivo M2Crypto.0.18.2.win32.py2.5.exe.
Me lo podrias pasar ?
Gracias.
Salu2

[Jose Fuglistaler]

Buenas:
Estamos tratando de implemetar la facturación electronica y se ha presentado el problema de que en el archivo entrada.txt la tercera linea contiene el valor null

1
4
null
80
20136581024
3630.00
3000.00
20140804
0
PES
1
5:3000.00:630.00

Seguimos todos los pasos descripto en la guia para la configuración. Somos RI, en los archivos log mencionados anteriormente no encontramos ninguna referencia por lo cual no se genera el valor esperado en dicha linea.

Si nos pueden guiar que punto de la configuración reveer o bien las clases del código fuente para hacer un debug.

Adjunto el log generado por LY:

ProcessorWSFE.callProcess: caeErrorCallProcess:null [64]

---

===========> MInvoice.completeIt: CAE Error: La AFIP no aprueba el envio. Por favor corrobore los datos (CUIT, Categoria de IVA, Etc). [64]

---

Saludos
Muchas Gracias

[Juan Manuel Martínez]

Hola,

verificá en la tabla c_doctype que la columna docsubtypecae contenga los códigos de los comprobantes establecidos por AFIP (01 factura A, etc).

Saludos,
Juan Manuel.

[Diego Sanchez]

Gracias funkytorino, con josefu estamos tratando de implementar la FE y efectivamente el null se debia a lo que nos dijiste. Ahora otra pregunta, espero que sea la ultima asi ponemos en marcha todo, nos conectamos a los servidores de homologacion de afip, al completar la factura se completa correcta mente, se genera el archivo salida.txt, pero en el campo CAE sigue el valor 0 (cero) no se actualiza, vimos en la DB y el campo cae tiene un valor distinto de 0 como asi vtocae. Alguna idea para orientarnos en la busqueda.

Desde ya muchas gracias.

[WS Biz]

El módulo pyafipws, al ir y volver de la AFIP, si todo sale bien modifica tanto el salida.txt y TA.xml. Fijate si ambos están modificados para, por lo menos, saber si desde la AFIP dio todo OK.

En mi caso en particular, peleé bastante para configurar la FAE ya que los instructivos no estaban completos. Logré hacerla funcionar, pero en modo producción, con lo cual desconozco cómo trabaja en modo homologación. Sé que la AFIP devuelve un CAE “trucho”, pero no sé si Libertya lo toma cuando es homologación o simplemente te deja como completada la factura.

[Juan Manuel Martínez]

Hola,

Fijate en la configuración del comprobante, porque probablemente no hayas habilitado los campos para que sean visibles (esos pasos están explicados en el manual).

Con respecto a los servidores de homologación son una copia exacta de los de producción, sólo que los CAE que devuelven no tienen validez fiscal. Por lo tanto, no tiene ninguna implicancia en el funcionamiento de la FE de Libertya si usás uno u otro (por lógica, en bases de datos de prueba deberías usar homologación de AFIP).

Por último, el archivo TA.xml es un “tiquet de acceso” a los servidores seguros de AFIP y lo genera el módulo wsaa. Si existe o está modificado solamente quiere decir que se pudo obtener un token para realizar la conexión, y no es suficiente para asegurar el funcionamiento del circuito. Para probar la funcionalidad de los servidores se debe usar el método –dummy del módulo wsfev1 que es el que usa Libertya.

Espero haberme explicado bien.

Saludos,
Juan Manuel.

[Autor]

Entradas