SUMINISTRO INMEDIATO DE INFORMACIÓN DEL IVA (SII)

[AlbertCabedo]

Definición: Nuevo sistema de llevanza de los libros registro del Impuesto sobre el Valor Añadido a través de la Sede electrónica de la AEAT, mediante el suministro cuasi inmediato de los registros de facturación.

Información teórica: Real Decreto 596/2016, de 2 de diciembre: suministro inmediato de información del IVA (SII), libros registros y otras obligaciones en materia de IVA http://www.agenciatributaria.es/static_files/AEAT/Contenidos_Comunes/Diversos/Novedades/2015/Noviembre/Suministro_informacion_IVA.pdf http://www.agenciatributaria.es/static_files/AEAT/Contenidos_Comunes/La_Agencia_Tributaria/Le_Interesa/2016/bolinform_SII.pdf http://www.boe.es/buscar/doc.php?id=BOE-A-2016-11575

Información técnica:

[infobit]

@acysos Pues creo que definitivamente se han malinterpretado nuestras palabras y, sobre todo, nuestras intenciones. Vuelvo a reiterar que nuestra intención era la de COLABORAR. Es cierto que para cuando tú dijiste que te ponías a ello nosotros ya estábamos avanzando, ERROR MIO no entrar aquí para verlo ( no me volverá a pasar), de hecho, al ver que tomabas la iniciativa lo más cómodo hubiera sido parar y ofrecer colaboración, pero como antes citaba, no lo vimos, y cuando lo vimos, ya estábamos metidos y decidimos terminar la fase de la conexión.

Llegados a este punto tú tomas la decisión de "pausar" el proyecto y nosotros la decisión de continuar con él. Además también tenemos clientes que lo necesitan pero no tenemos un compromiso de entrega tan cercano (final de febrero nos parece inasumible por la magnitud y sobre todo las incógnitas del mismo). Así que, creo que no vale la pena seguir con este cruce de "comentarios" y lo que vamos a hacer es mirar hacia adelante y trabajar.

Hemos probado la nueva versión y de momento todo ok. También hemos subido el primer script que envía altas y modificaciones ( cambiando el valor ). Seguimos trabajando y en los prox días iremos añadiendo. Respecto al control de la documentación enviada también somos partidarios de controlar los estados. Lo que no tenemos claro es si vamos a utilizar el "connector".

https://github.com/infobit/SII

[pedrobaeza]

Buenas a tod@s,

No creo que se busque aquí pisar unos a otros, si no que es más bien que todo el mundo está nervioso por el escaso tiempo que se tiene, y se quiere avanzar en la materia.

De todas formas, veo el alcance es totalmente distinto. Lo que ha hecho Infobit es un script hardcodeado como prueba de concepto, que te puede servir Ignacio como base. Tal vez ése es el valor añadido: que ellos puedan establecer un caso de uso de cada comunicación que funciones con código que tú luego puedas transportar al proceso de Odoo. ¿Hay trato? :wink:

[infobit]

Por nosotros ok.

[acysos]

Al final son exactamente los pasos que indicamos que estábamos haciendo, hardcore con zeep de la parte de conexión, para luego pasar al módulo. Por lo tanto, lo que hemos hecho se ha duplicado, es lo que quiero evitar a toda costa. Se propone que sigamos con la parte del módulo, estoy de acuerdo, aunque tenemos lo mismo de otra forma.

Espero que se acaben las duplicaciones, porque realmente es un tiempo perdido de todos.

Saludos

[JMLOSP]

Buenas tardes, he estado buscando por curiosidad en gitHub proyectos relacionado con esto y me he encontrado con esta issue, recalcar primero que el desarrollo que estamos haciendo no tiene nada que ver con vuestro proyecto, pero me he encontrado con una pregunta con la que nos hemos topado hoy mismo y me gustaría facilitaros la contestación si aún os es necesaria ya que no he encontrado la contestación en este hilo:

@infobit

_2.11. ¿Cómo se modifica o anula una factura emitida por error o con errores en los datos de identificación (ej. operación inexistente)?

El registro de la factura enviada previamente y que no procede se dará de baja identificando el número de la factura original.

En el caso de que proceda emitir una nueva factura correcta se deberá registrar con un alta (A0) y con un número de factura diferente._

Lo hemos probado y hay que hacerlo como dicen, pero en este caso, SE NOS QUEDARÍA UN HUECO EN LA NUMERACIÓN , ya que no nos deja volver a usar el mismo número de factura ( nos devuelve "factura duplicada" aunque en la consulta al SOAP nos aparece como "anulada".

Es decir :

Mando por error ( se me va el dedo ) la factura 1500. Me doy cuenta y mando la baja, el sistema la borra ok. La vuelvo a mandar rectificada y el sistema me dice que tengo que utilizar otro número porque ese ya existe, y si lo hago, tengo que cancelar una factura en odoo y crear una nueva con otro número ( ya tengo un hueco )

Si alguien quiere el script para ir haciendo pruebas, lo mandamos. En proximos días añadiremos algo más visible al repositorio.

Cuando tengais esta situación en la cual se anula una factura emitida/recibida para dar de alta de nuevo con el mismo numero de registro de factura es necesario mandarla con el tipo modificación no con el nuevo de alta. Siendo la ClaveTipo A1 en vez de A0. A0 unicamente cuando el registro es totalmente nuevo y no procede de ninguna anulación. Esto está probado y contrastado con la version 0.5.

Espero que os sea de utilidad sin aún teniais la consulta.

Saludos.

[infobit]

@JMLOSP Gracias. Sí ya lo hemos probado, pero la duda nos surgía cuando NO quieres volver a mandar la factura. En ese caso nos han confirmado que no se puede volver a utilizar ese número de factura y en la AEAT constará como "anulada". También lo hemos probado y así consta cuando la consultas. En ese caso, como ya no se puede usar el número me genera un hueco el la numeración de la facturación. También nos han confirmado algunos asesores que así debe constar en el ERP, ya que más que hueco lo que hay es una factura "cancelada" en el ERP con ese número.

[newsages]

Si la anulas. El registro sigue estando en sus servidores. Si realizas una consulta veras en el resultado de la consulta el numero de factura con estado "Anulada". Anular no es borrar.

[acysos]

No hemos retrasado, debido a que hacienda tenía un error que era bastante problemático, no aceptaba un certificado personal para presentar facturas de una empresa. Esto es un problema porque ya no se emiten certificados de empresa. Solo se podían presentar facturas emitidas por el NIF del certificado.

En el último mail con hacienda ya lo han solucionado, podemos acabar el desarrollo. La semana que viene estará la beta que no tendrá todos los modelos de facturas posibles pero si los más importantes (emitidas, recibidas, rectificativas).

Saludos

[guadaltech]

Hola a todos, por nuestra parte tenemos un cliente en la 6.1, por lo que nos encargaremos de hacer la adaptación a esa versión.

[acysos]

Yo tengo 2 en la 8.0 y uno en la 6.0, @guadaltech vamos por el mismo camino, cuando tengáis la 6.1, podemos partir de esa, casi seguro sea la misma. El mayor problema de bajar a estas versiones es el connector, que no esta.

Saludos

[guadaltech]

@acysos sin problemas

[infobit]

Nosotros tenemos a un cliente en la 7. Si no hay inconveniente lo llevaremos a esa versión.

[acysos]

@infobit adelante. La semana que viene publicamos la versión 8, se puede partir de esa. La 7.0 si que tiene connector, eso facilitará.

[infobit]

Perfecto!!

[guadaltech]

Buenas a todos, ¿alguien lo va a migrar a la .10? o hay algún otro plan.

[acysos]

@AngelCamacho indico que se iba a encargar de la 9.0, que pasará algo parecido a la 6.1 y la 6.0 que serán muy similares. Pero nadie ha indicado nada específicamente de la 10.0.

[AngelCamacho]

@acysos Si, en cuanto tengamos testeada la 8.0, nos ponemos a trabajar para pasarlo a la 9.0. Nosotros de la 10.0 no tenemos nada.

[anajuaristi]

@acysos Nos unimos a testear V8. Gracias!!

[Shide]

Buenas a todos, trabajo con un OpenERP 7.0 y me gustaría saber dónde se va a publicar el código para la versión 7.0/8.0 para modificar, adaptar y testear código.

Un saludo!

[acysos]

@anajuaristi gracias.

@Shide Se va a publicar aquí.

Saludos

[lanestic]

Hola. Yo trabajo con la version 6.1 He estado echando una ojeada a un fichero que ha publicado infobit y hace referencia a un par de ficheros que son Direccionclaveprivada.pem y direccionclavepublica.crt Estos ficheros se obtienen de la Agencia Tributaria ?

Saludos

[infobit]

@lanestic En ambos casos son los archivos de tu firma digital ( clave pública y privada). Si tienes instalada en tu navegador la puedes exportar y guardarla en formato crt. . El formato .pem tienes que transformarlo a partir del .crt con el openssl ( comando linux). La clave, obviamente te le tiene que proporcionar hacienda o el organismo correspondiente.

[lanestic]

Infobit, gracias.

[jalzaga]

Nos unimos a testear V8 y el resto.

[acysos]

Hemos publicado el PR #464

[liebana]

Hola @acysos

De cara a las pruebas, ¿hacienda dispone de un entorno test para realizar las validaciones? ¿Nos das pistas de como se solicita? ¿Es configurable en el propio módulo el entorno contra el que se conecta?

Gracias.

[acysos]

@liebana El entorno de prueba se activa con el checkbox "Test" en configuración de la compañía. El entorno es abierto lo puede usar cualquier que tenga firma autorizada. Esta firma es la misma que puedas usar para presentar los modelos fiscales estándar.

Saludos

[liebana]

Pero si o si es con la firma de producción, entendido. Gracias, lo probamos y comentamos.

[acysos]

El certificado tiene que ser con uno válido por la FMNT, no tienen acceso sin certificado para probar. De todas formas actualmente es imposible equivocarse porque en los wdsl hacienda tiene quitada las urls que no sean de pruebas.

Saludos

[acysos]

@anajuaristi si vas a hacer pruebas ten en cuenta las url de los wdsl en Navarra y el Pais Vasco son otras. Por eso lo he puesto como configurables desde la compañia y, por defecto, utiliza las estatales.

Saludos

[anajuaristi]

Genial. Gracias por el aviso!!

Cuando tengamos alguna conclusión os digo

El 13 de marzo de 2017, 11:53, Odoo - OpenERP - Acysos S.L. < notifications@github.com> escribió:

@anajuaristi https://github.com/anajuaristi si vas a hacer pruebas ten en cuenta las url de los wdsl en Navarra y el Pais Vasco son otras. Por eso lo he puesto como configurables desde la compañia y, por defecto, utiliza las estatales.

Saludos

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-spain/issues/412#issuecomment-286074670, or mute the thread https://github.com/notifications/unsubscribe-auth/AALY306ONW-C-eEqR4cZPLRKs2x6v6WAks5rlSAOgaJpZM4LKyys .

-- CEO Avanzosc, S.L http://www.avanzosc.es/ : Office phone / Tfono oficina: (+34) 943 02 69 02 Ana Juaristi Olalde http://www.anajuaristi.com/: Personal phone: 677 93 42 59. User/usuario skype: Avanzosc www.avanzosc.es www,odoomrp.com http://odoomrp.com/ www.pymeserp.com www.agroalerp.com

*El contenido de esta comunicación y de toda su documentación anexa es confidencial y se dirige exclusivamente a su destinatario. El uso no autorizado de esta información está prohibido por la legislación vigente. Si usted no es el destinatario le rogamos nos lo indique, no comunique su contenido a terceros y proceda a su destrucción. Disculpe las molestias que le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse para ejercer sus derechos de acceso, rectificación, cancelación y oposición en Klara Donea 13, 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02 - *administracion@avanzosc. soporte@avanzosc.eses

Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu egiten du bertan eskainitako informazioa baimenik gabe erabiltzea. Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez, guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu. Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: Klara Donea 13 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02 - administracion@avanzosc. soporte@avanzosc.eses This message and all documents attached to it are confidential and intended only for the person or entity to which it is addressed. Any use of this information by unauthorised persons is prohibited under current legislation. If you received this message by error, please advise us, destroy it and refrain from communicating its contents to third parties. We apologise for any inconvenience receiving this email improperly may cause to you. Your personal data are included in a file owned by Avanzosc, S.L. If you want to exercise your rights of access, correction, erasure and objection you can contact the Controller at Klara Donea 13 20720, Azkoitia (Gipuzkoa), T: 943 02 69 02 – administracion@avanzosc. soporte@avanzosc.eses

[AlbertCabedo]

Ponencia 5-Rosa Ma Prieto del Rey.pdf Adjunto una ponencia sobre el SII realizada por la agencia tributaria, es teoría, pero puede resolver alguna duda al respecto.

[AngelCamacho]

Estoy haciendo las primeras pruebas de conectividad y me encuentro que me devuelve el error:

SII Return: 336265225 [SSL] PEM lib (_ssl.c:2603)

He comprobado las rutas de los certificados, los dos ficheros de certificados y parece ser todo correcto. Alguna idea de donde pueda estar el problema?

[acysos]

@AngelCamacho nosotros metimos el certificado con los comandos indicados y nos funciona sin problemas.

Prueba este archivo directamente sin el módulo. Es un script 100% operativo con SII, pero que no depende de Odoo, por descartar el certificado. Solo tienes que poner el script en la misma carpeta que los certificados y cambiar el CIF

https://www.dropbox.com/s/yaqfw6oazjiwove/SuministroFacturasEmitidas.py?dl=0

Saludos

[AngelCamacho]

@acysos Gracias, me ha sido de gran ayuda para detectar el problema. El problema era de las librerias me faltaba actualizar estas dos:

Django==1.10.6 requests==2.5.3

Continuaremos las pruebas a ver que tal.

Saludos!

[acysos]

@AngelCamacho Perfecto, voy a poner esas versiones en el módulo.

[siscoCasasempere]

Buenos días, Gracias por el esfuerzo!! Hemos hecho unas cuantas pruebas y nos funciona correctamente. Estamos interesados en esta funcionalidad y queremos colaborar en el testeo y/o en el desarrollo. ¿Como podemos ayudar?

Tal vez, podamos coger alguna tarea del roadmap como la de la carga del certificado desde Odoo y subirla para colaborar.

Saludos.

[acysos]

@siscoCasasempere Sin problemas adelante.

Encontré esta información hace tiempo que puede que te ayude https://gist.github.com/erikbern/756b1d8df2d1487497d29b90e81f8068

La idea que tenía es lanzar un asistente que suba el certificado y pida la contraseña pero que no almacene la contraseña. Convierte el certificado en los dos archivos necesarios y que los guarde en el filestore.

Saludos

[coloradito]

hay algun foro para plantear dudas tecnicas sobre SII. yo me estoy encontrando problemas con facturas que me devuelve un "ParcialmenteCorrecto" con el error de factura duplicada

Incorrecto 3000 Factura duplicada no lo entiendo porque la factura anterior me la acepta, pero la siguiente no y lo unico que hago es aumentar en un digito el codigo de la factura de xT/18-300021 a xT/18-300022 xT/18-300021

[infobit]

@acysos gracias por el trabajo. Ya hemos migrado el módulo a la 7.0 y estamos con las pruebas y algunos flecos. De momento todo ok, salvo que cuando encuentra facturas con varias líneas de IVA sólo mete la primera que encuentra. Lo estamos rectificando, pero ¿Le ocurre al alguien más?

[infobit]

Al que pueda interesar...igual esta información ya está publicada por ahí, pero... Ayer tuvimos una reunión con una empresa que está en contacto permanente con la AEAT y nos confirmaron que a partir del 1 de Junio la AEAT va a poner en marcha los servidores reales en producción para todos, de forma que el que quiera voluntariamente comenzar un mes antes podrá hacerlo. Posteriormente, la AEAT hará un "borrado" de esos registros para hacer borrón y cuenta nueva a partir del 1 de Julio. Es una forma de estar conectado un mes antes y hacer pruebas reales.

También van a publicar una plataforma ( más decente que la existente) en la que además de consultar se podrán "modificar" registros presentados.

[siscoCasasempere]

Buenos días @acysos

Os hemos hecho un PR en vuestra rama, con el tema de la Subida del certificado.

Echadle un ojo y nos decís si lo véis correcto.

Saludos

[lanestic]

@infobit Vais a publicar lo que tengáis hecho para la versión 7 y la 6.1 a fin de que podamos depurar y sugerir mejoras ?

Gracias

[acysos]

@infobit Las funciones def _get_sii_tax_line y def _update_sii_tax_line se encarga de buscar los impuestos, estas funciones devuelve un array con los diferentes tipos que luego en las lineas 201 a 209 se leen para indicaren el desglose los diferentes tipos y se añaden. Así nos indico Haciendo que había que hacerlo en un mail que nos mando.

En las pruebas que hemos hecho nosotros nos ha mandado ambos impuestos. Si puedes indicar algo más sobre el problema.

[AngelCamacho]

Buenos dias,

Hemos realizado pruebas sobre el envio del SII y la conexión nos la hace correctamente. Lo que si nos encontramos son problemas con la definición de los tipos impositivos. Actualmente la presentación se base en los Tax Code indicados en el tipo impositivo (S_IVA21B, S_IVA10B, S_IVA4B, S_IVA0...). Deberiamos ver como reconsideramos este aspecto para que sea configurable a nivel de interface y poder indicar cada tipo impositivo a que apartado del SII corresponde (DesgloseIVA Servicios / Bienes, Exento, Intracomunitario, etc...).

Ya que cualquier tipo impositivo nuevo que cree el cliente o que varie el Tax Code daria problemas en la presentación. Es màs añadiria un control en la validación para que no permitiera validar la factura si los tipos impositivos especifcados en el documento no estan correctamente clasificados para el SII.

Es un tema a hablar para partiendo del trabajo de @acysos implementar una seguridad en cuanto a los datos enviados y evitar errores innecesarios.

Otro punto a realizar es limitar las posiciones de los campos a pasar. Nosotros tambien nos encontremos que no acceptaba el XML porque el nombre de la compañia era superior a 40 caracteres.

[acysos]

@AngelCamacho Sería cambia muchos modelos de la AEAT, no solo el SII se basa el tax code del l10n_es, también el 111 y el 115. Creo que puede ser un punto a debatir, pero creo que mejor en otra Issue ya que no solo afecta al SII.

Respecto a limite de 40 caracteres, lo ponemos para una versión nueva.

[pedrobaeza]

Buenas, la propuesta que hace Ángel es sólo para el SII y me parece correctísima. Ignacio, vuelve por favor a leerla, ya que aquí nada tiene que ver los modelos 111 y 115. Eso sí, yo lo haría con una tabla intermedia, no en account.tax.code, por dos razones:

• Así no hay que requerir account_chart_update para tener los datos.
• En v9 no hay códigos de impuestos, y es más fácil cambiar la columna de código por la de impuesto que poner todo de nuevo en otro modelo.

[AngelCamacho]

Tal como indica @pedrobaeza si lo separamos de dichos modelos evitaremos muchos problemas incluso nos darà margen de actuación en clientes especificos, que hayan creados tipos impositivos nuevos o diferenciados (como puede ser el caso de tipos impositivos con iva incluido o no, etc...).

[infobit]

@lanestic Sí, claro. Lo estamos ultimando y en breve ( semana próxima si no pasa nada) lo publicamos. De todos modos, lo que hemos hecho es para la 7.0. Creo que Guadaltech se encargaba de la 6.1.

[acysos]

@pedrobaeza Debo estar interpretando algo mal, porque la función _get_tax_code_lines con _get_move_line_domain de l10n_es_aeat también utiliza directamente los códigos, si cambia el código de uno de los impuestos o crean un nuevo ya no lo encontraría. Esta función la utilizan el 111, 115, 296 y 216. https://github.com/OCA/l10n-spain/blob/8.0/l10n_es_aeat_mod111/models/mod111.py#L279

Otra cosa es que se pueda plantear un mapping como el 303. Que puede ser la mejor solución a lo que plantea @AngelCamacho. De hecho el mapping me parece el más correcto, creo que evitaría recorrer las lineas de factura. Vamos a hacer una prueba de laboratorio.