Code too large

[hortegag91]

Buenas, Estoy terminando de implementar la versión 3.3, solo que me estoy topando con un problema bastante grave. Al generar los catálogos a través de los archivos XSD, me estoy tomando con catálogos garrafalmente enormes, y me está marcando un error en la compilación de "code too large" (al compilar el archivo .java, porque las clases si las genera). Alguien ya tiene implementada esta versión o sabe como solucionar esto?

[ingtemix]

Hola amigo yo agregue algo en los xsd de estos catalogos que es lo siguiente:

Donde agrego el máximo de valores que tenga el catalogo. Saludos!!!

[hortegag91]

Gracias por contestar, solo que hay un problema, no se si tengamos catálogos distintos o que, pero el catálogo que yo traigo tiene algunos con máximos de 93k (si bien recuerdo), ahora, lo que yo hice fue agregar básicamente lo mismo pero en el bindings.xjb (que en teoría debería tener el mismo resultado) el problema básicamente es a la hora de compilar, ya que si me genera las clases con todo el catálogo pero Java no puede compilar métodos mayores a 64kb, y dicho catálogo pesa muuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucho más que eso. Te agredecería si pudieras hacer un push en tu fork para ver si el tuyo si lo está pudiendo compilar, y como lo crea, porfa Saludos.

[ingtemix]

Dame oportunidad de rehacerlo dado que ya estoy reorganizando el codigo, yo creo que la siguiente semana entre Lunes y Martes lo tengo listo y te busco te parece???

Saludos!!!

[ingtemix]

Amigo tengo mi listo mi ambiente cuando lo podemos revisar???

Saludos!!!

[camarillo]

Hola! Yo lo voy a empezar a revisar para integrarlo a la librería, les comento como me va.

[hortegag91]

Yo con suerte hoy termino el mío y le hag un push @ingtemix podrías hacerle el push a tu fork? no tiene actualizaciones recientes

[ingtemix]

Me explicas nunca lo he hecho @hortegag91

[ingtemix]

Solo encontre un detalle a la hora de verifucar el sello que estoy verificando.

[hortegag91]

@ingtemix te recomiendo leer sobre git. Si todo está bien configurado, debería ser suficiente con poner los siguientes comandos desde consola y dentro de la carpeta git add . git commit -m "Actualizacion a CFDi3.3" git push

[Erilas]

Me tope con tu mismo detalle @hortegag91 el catalogo de SAT esta pesando 6MB (http://www.sat.gob.mx/sitio_internet/cfd/catalogos/catCFDI.xsd), no seria mas optimo modificar dicho catalogo de manera local para que pese menos... en mi caso siempre facturo hacia la misma empresa por lo que un catalogo de localidades no me es útil al momento de crear una factura. En fin ojala exista otra solución

[ingtemix]

Hola @hortegag91 nos ponemos de acuerdo y me explicas mediante un acceso remoto y de igual revisamos el tema del metodo verificar.

Saludos!!!

[hortegag91]

@Erilas Asi es, se me pasó comentar que en su momento averigüe y el problema es que Java no puede compilar métodos que pesen más de 64kb, desgraciadamente hay catálogos que pesan varios muchos) mb. Definitivamente dejé eso por la paz y dejé los campos como String, es decir, no habrá enums para seleccionar simplemente quedará el String y habrá que implementar métodos "por fuera" para dicha validación. Cerraré el tema. @ingtemix Seguro, igual puedes ir revisando algunos tutos en youtube sobre Git. Saludos.

[ingtemix]

@hortegag91 pregunta no has tenido tema con la validación puedo ver que el XSLT enviado por el SAT no es correcto dado que están mal direccionado los impuestos de los conceptos.

Saludos!!!

[hortegag91]

Disculpa @ingtemix para ser sincero lo XSLT se podría decir que ni siquiera los toqué (para ser sincero ni los revise jaja) solo coloqué las nuevas rutas para los archivos a importar y dejé todo tal cual, ya que es la definición que el SAT da para generar la cadena y hasta donde tengo entendido, no debemos moverla bajo ninguna circunstancia. Saludos.

[ingtemix]

Estimados ya corregí el XSLT y además corregí el problema para la versión 3.3 la cual consiste en que ahora dentro del sello se incluye el No. de Certificado por lo que hay que setear antes dicho dato de generar el sello.

Agrego como quedo el metodo corregido.

@Override public void sellar(PrivateKey key, X509Certificate cert) throws Exception { cert.checkValidity(); BigInteger bi = cert.getSerialNumber(); document.setNoCertificado(new String(bi.toByteArray())); String signature = getSignature(key); document.setSello(signature); byte[] bytes = cert.getEncoded(); Base64 b64 = new Base64(-1); String certStr = b64.encodeToString(bytes); document.setCertificado(certStr); }

@hortegag91 realiza la corrección del metodo sino los PAC te lo rechazaran como Sello Mal Formado.

Cualquier duda y/o comentario me comentan.

Saludos!!!

[hortegag91]

Disculpa @ingtemix a que corrección te refieres, no entendí bien que hacia falta. Por otro lado, hay más campos a demás del no. de certificado, como lo son el RFC del PAC que timbró y una leyenda adicional. Hay que colocarlos en la nueva clase que TFDv11c33 (asi la llamé yo, puedes revisarlo en el branch "version33" del proyecto principal) Saludos.

[ingtemix]

OK tratare de explicarlo.

Yo para sellar un documento lo hago de la siguiente forma:

CFDv33 fact = new CFDv33(is); fact.sellar(key, cert); (Sella la factura) fact.validar(); (Valida la factura con el esquema) fact.verificar(); (Valida el sello generado con la informacion de la factura) OJO AQUI ESTA EL ERROR. fact.guardar(new FileOutputStream(pathFiles + "sellado_" + archivo)); (Guarda el XML sellado).

En el metodo 3.2 cuando se genera el sello y se verifica la factura no existe error debido a que el NoCertificado no se agrega en la cadena Original.

Actualmente en la versión 3.3 primero generamos el sello y luego seteamos al XML los campos NoCertificado y Certificado lo que es incorrecto porque en el Sello no llevará el campo No.Certificado y cuando verificas el XML te mandara Sello Incorrecto debido a que el sello que lleva la factura no contiene el campo No.Certificado y el sello generado ya lo contiene.

LA SOLUCION es antes de generar el sello primero setear el atributo NO.Certificado. y posterior generar el sello. A continuación agrego ambos metodos para que vean la diferencia.

INCORRECTO @Override public void sellar(PrivateKey key, X509Certificate cert) throws Exception { cert.checkValidity(); String signature = getSignature(key); document.setSello(signature); byte[] bytes = cert.getEncoded(); Base64 b64 = new Base64(-1); String certStr = b64.encodeToString(bytes); document.setCertificado(certStr); BigInteger bi = cert.getSerialNumber(); document.setNoCertificado(new String(bi.toByteArray())); }

CORRECTO INCORRECTO @Override public void sellar(PrivateKey key, X509Certificate cert) throws Exception { cert.checkValidity(); BigInteger bi = cert.getSerialNumber(); document.setNoCertificado(new String(bi.toByteArray())); String signature = getSignature(key); document.setSello(signature); byte[] bytes = cert.getEncoded(); Base64 b64 = new Base64(-1); String certStr = b64.encodeToString(bytes); document.setCertificado(certStr); }

Saludos!!!!

[hortegag91]

Ya capté, no se porqué creí que te referías al complemento Timbrado. Enterado, no me había dado cuenta de eso!! Muchísimas Gracias @ingtemix es un error garrafal que dejé pasar. En unos minutos hago la correción y la subo al branc version33 del proyecto principal. Saludos!

[ingtemix]

De nada @hortegag91 ya saben cualquier cosa hazmela saber.

Yo ya verifique y en efecto es correcta la versión con la nueva implementación. Ahora estoy analizando si la matriz de validaciones las realizo desde la misma lib o en otro lugar.

Les mantengo al tanto.

Saludos!!!

[hortegag91]

Normalmente se ha manejado afuera (no se exactamente el porqué), yo las he venido manejando desde una librería externa que contiene muchas herramientas para muchos proyectos personales, pero quizá podríamos incluirla dentro. Sería cuestión de consultar con el creador si hubo alguna razón en especial para no incluirlo.

[hortegag91]

Hay que abrir un nuevo tema en donde mantengamos estos cambios, ya que este hilo es del error que marca el catálogo tan grande liberado por el SAT.