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:

[rafaelbn]

Hola @albertgafic se corta cuando dices "información técnica"

[AngelCamacho]

Hola,

Dispuesto a col.laborar a ver como lo enfocamos ya que creo que al enviar la información hacienda vamos a tener que restringir la opción de cancelar / modificar una factura.

[AlbertCabedo]

Adjunto información técnica del SII y global http://www.agenciatributaria.es/AEAT.internet/Inicio/La_Agencia_Tributaria/Campanas/Suministro_Inmediato_de_Informacion_en_el_IVA__SII_/Suministro_Inmediato_de_Informacion_en_el_IVA__SII_.shtml

[acysos]

Nosotros nos vamos a poner a ello, tenemos un cliente que esta obligado a presentarlo.

[liebana]

¿Con el módulo connector?

2016-12-29 17:53 GMT+01:00 Odoo - OpenERP - Acysos S.L. < notifications@github.com>:

Nosotros nos vamos a poner a ello, tenemos un cliente que esta obligado a presentarlo.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-spain/issues/412#issuecomment-269658754, or mute the thread https://github.com/notifications/unsubscribe-auth/AHbDgHNHAnSiiDr--CbU101ueR3mF5FAks5rM-WYgaJpZM4LKyys .

--

CARLOS LIÉBANA ANERO Director | factorlibre.com +34 635 86 67 92 @carlosliebana

[acysos]

@liebana Aún no se decirte que módulo se usará, hay que analizarlo, pero lo tendré en cuenta

[Jortolsa-S73]

@acysos @albertgafic Hola, tenemos varios clientes que están obligados a presentarlo y vamos a empezar ya el desarrollo. Si queréis que desarrollemos juntos organizamos un Hangouts para analizarlo.

[acysos]

@Jortolsa no se debería realizar doble trabajo, creo que es mejor que tengamos disponible una beta para luego poder sugerir mejoras o cambios

@liebana al final no se ha usado el módulo connector, esta en la versión 8.0, y tienen un crowfunding para la 9.0, al ser un tema legal obligatorio, depender de un módulo que de momento no esta claro que este en la 9.0 o 10.0 y que además su migración es muy compleja para las necesidades de este módulo, se esta integrando SOAP directamente en el módulo

[pedrobaeza]

Bueno, eso no es en realidad cierto. El módulo connector está desde el 2 de marzo del año pasado para 9.0: https://github.com/OCA/connector/commit/2987f9825bc827e138b7c30db28231e994235fc8. Incluso ya se ha migrado a la versión 10 y extraído la parte para encolar trabajos como un módulo separado (para que no se tan pesado): https://github.com/OCA/queue/tree/10.0/queue_job

[acysos]

@pedrobaeza la web del proyecto esta muy desactualizada en este aspecto y siguen pidiendo crowdfunding para la 9.0, de ahí la confusión. De todas formas la conexión se puede hacer directamente con librería soap de python, no depender de un módulo tan complejo para mandar los pocos datos que solicitan. En argot mi opinión es que se estaría "matando moscas a cañonazos", pero si queremos usar connector lo podemos hacer, el trabajo realizado hasta ahora no imposibilita hacerlo ya que nos hemos centrado en la conexión SOAP.

[pedrobaeza]

La verdad es que yo siempre utilizo GitHub como referencia porque muchas veces pasa esas cosas: la documentación no es el fuerte en el entorno Odoo. Yo veo lo del connector como algo bastante necesario, por varias razones:

• Te olvidas de gestionar las ejecucciones en paralelo. Lo hace el conector con los hilos que tú quieras.
• Tienes directamente un panel de estado, para saber si algo no ha ido bien.
• Puedes gestionar prioridades y retrasos en los trabajos.

Si necesitas que te oriente en cómo funciona, te cuento rápidamente, pero ya verás que es muy sencillo de manejar. La clave está en crear un método decorado (ejemplo https://github.com/OCA/bank-payment/blob/3f4f29b318f8a302606a7d392cd0eda87a3227ba/account_payment_transfer_reconcile_batch/models/bank_payment_line.py#L38) y luego llamarlo con el método delay (https://github.com/OCA/bank-payment/blob/3f4f29b318f8a302606a7d392cd0eda87a3227ba/account_payment_transfer_reconcile_batch/models/bank_payment_line.py#L35). El ejemplo te lo pongo en la v9 pero para v8 es igual. En la v10 la API ha cambiado un poco para ser más sencillo de utilizar, directamente llamando a cualquier método del modelo con with_delay.

[liebana]

Yo también lo haría con el módulo connector, la verdad. Es la manera más estandarizada de realizar el desarrollo. Idem en lo de la ayuda.

[acysos]

@pedrobaeza Se como funciona, en 8.0 lo usamos para conectar a magento. El planteamiento que tenemos con el módulo SII es que no se quede bloqueado en una versión, no solo hacia adelante, sino que también hacia versiones anteriores, aún hay empresas que lo usan, de momento espero no tener que bajarlo hasta la 6.0 que sería el peor caso ya que connector no esta en esa versión.

Aunque la primera batalla es el SOAP de hacienda, como siempre usan sus peculiaridades.

[liebana]

Creo que debería de ser la última prioridad plantear algo para la versión 6 en estos momentos. Ya hay muchas cosas que para la versión 6 no se han trasladado desde versiones posteriores.

No es por levantar polémica, Ignacio, pero cuando nos presionen a nosotros y tengamos que dar por bueno algún desarrollo al respecto, seguramente lo planteemos sobre la base del connector que conocemos bien. Me parecería un error no hacerlo así.

[acysos]

@liebana No he dicho nada de eso, solo he dicho que sería el peor caso, pero te sorprenderías. Pero tu frase es la típica del software libre, como yo conozco esto es lo que vale y si no lo conozco no vale. Creo que hay que mirar más posibilidades, igual que yo lo estoy haciendo. Porque no estoy negando usar el connector al contrario.

[ozono]

@acysos @albertgafic Si es posible, nos gustaría sumarnos al desarrollo de este módulo. También lo vamos a necesitar y nos gustaría compartir esfuerzos con la comunidad: bien participando directamente en el desarrollo o bien probando / sugiriendo correcciones a la beta. Estamos a vuestra disposición.

[guadaltech]

Nosotros tenemos un par de clientes que nos lo requieren, y ya estamos analizando como abordarlo, por lo que estamos abiertos a colaborar y compartir esfuerzos.

[AlbertCabedo]

Nosotros os ayudamos en la validación sin problemas.

[AngelCamacho]

Nosotros tenemos ya 3 clientes que requieren dicha implantación 2 con V8 y uno con V9. Por lo que tambien nos apuntamos a la col.laboración, desarrollo y validación correspondiente.

[acysos]

Nosotros ya lo tenemos analizado y esta ya desarrollándose. Creo adecuado esperar a que saquemos un primer PR, sino veo que al final tenemos un desarrollo cada uno.

[AngelCamacho]

Por nosotros perfecto. Si es mejor trabajar ya sobre una base inicial. Sobre que versión de Odoo lo desarrollais? y si no es mucho pedir teneis alguna previsión de cuando estara ese primer PR?

[acysos]

@AngelCamacho Sobre la 8.0 con nueva API para que sea fácil pasarla a versiones posteriores, si queréis encargaros de la versión 9.0 por mi perfecto, de momento no tenemos casos en la 9.0. Sobre previsión es complicada, trabajamos sobre un SOAP que es nuevo, vamos testando contra el entorno de pruebas cada fase, pero mi intención es que tengamos una PR beta a finales de febrero, para que de tiempo a pasarlo a otras versiones y que también se propongan mejoras.

[AngelCamacho]

@acysos Perfecto, pues si cuando tengais el PR a parte de testear la 8.0, podemos encargarnos de pasarla a la 9.0.

[pedrobaeza]

Ignacio, sería importante que compartieras lo antes posible aunque sea la versión súper-alpha para ir revisando la solución técnica. Recuerda que para @liebana y para mí es muy importante confiar en tecnologías ya asentadas como el módulo connector.

[acysos]

Actualmente no existe aún módulo instalable en Odoo, porque ya tenemos experiencia a conectar Odoo a automatas, balanzas, otros programas especificos... y nuestra forma de trabajar es primero realizar a python directo los protocolos de comunicación con datos estátitos ya que es más rápido que crear primero el módulo, una vez que se comprueba que la parte del protocolo de conexión opera correctamente creamos un módulo Odoo con ese código.

No tengo ningún problema en debatir las tecnologías como ha pasado con el connector a petición de dos personas, porque ya hay malas experiencias en esta comunidad con sobreescribir el código porque a uno no le gusta y romper los módulos del otro, sin ni siquiera debatirlo.

Para la conexión SOAP se esta usando Zeep, ya que las otras librerias de python llevan años sin actualizarse, y aunque el servicio SOAP de hacienda no es el más moderno creo conveniente usar una libreria actualizada que soporte tanto SOAP 1.1 como el 1.2 aunque solo se use el 1.1. Para enviar el certificado se esta utiliza un transporte http (HttpTransport). Como he comentado, estamos en esta fase con python estatico.

El siguiente paso se creara el módulo usando connector y el código obtenido en la fase anterior. En la fase inicial de implantación del SII hacienda permitirá que se manden los datos en 8 dias hasta 2018, a posteriori serán en 48 horas. Al inicio pensamos enviar las facturas en el momento que se validaban con un subproceso en segundo plano, pero si hacienda sigue funcionando como ahora que se satura con mucha facilidad creo que no es el mejor camino. De aquí que si queréis abrimos un debate que aún tengo dudas, y que pensaba abrirlo en cuanto estuviese la parte SOAP acabada. Creo que puede haber dos métodos, a lo mejor se os ocurre otro:

1º Enviar la factura en cuanto se valida y marcarla como enviada a hacienda, ya que hay que diferenciar si es alta o modificación. 2º Debido a que hacienda permite comunicar multiples facturas en bloque, enviar a la noche todas las del día, y marcarlas como enviadas.

A mi personalmente me gusta más que se lance a la noche y no enviar constantemente. Que opináis?

[ozono]

Voto por un cron de Odoo que envíe todas aquellas facturas marcadas como no enviadas. De este modo, puedes programarlo para cuando quieras: cada minuto, una vez al día, etc.

También habría que tener en cuenta que avisase / lo reintentase automáticamente en caso de problemas: es posible que, por alguna razón o error, no pueda enviar un bloque de facturas y se pase del límite inicial de 8 días (2 en el futuro) sin que el cliente se percate.

[pedrobaeza]

Siento decirlo, @ozono, pero el cron es de las peores soluciones, ya que no tienes feedback de posibles errores si no es mirando el log de servidor, y cualquier otro mecanismo de reintento debes ponerlo por tu cuenta, además de la gestión de errores.

Lo mejor es encolar ese trabajo de envío a Hacienda en el connector, pudiéndose poner un delay de a lo mejor 10/20 minutos para dejar tiempo a un posible arrepentimiento. Hay que tener en cuenta también que una factura ya enviada no se puede cancelar, por lo que habrá que incorporar ese mecanismo. Si se puede cancelar porque aún no se ha enviado, entonces hay que eliminar automáticamente el trabajo de la cola. La gestión de errores será tan sencilla como revisar el estado del trabajo (si es excepción o no). Incluso se podría añadir una pestaña en la propia factura para ver esa información. Esto además se hace fácilmente si se tiene bien atomizados los métodos para cada cosa: se decora ese método y se accede al entorno por la variable session.env en lugar de self.env (en v10 ya se ha unificado esto, por cierto).

[ozono]

@pedrobaeza para el feedback se puede usar el propio sistema de mensajería de Odoo mediante el cual el proceso que se ejecute puede enviar un reporte del éxito/fracaso de la acción realizada incluyendo todos los detalles al responsable del proceso: el reporte aparecería en el panel de mensajería del usuario; además también se le enviaría un e-mail. Ya lo hacemos así en otros procesos de alguno de nuestros clientes y funciona a la perfección.

Además, entiendo, que el proceso podría hacer uso de connector igualmente. Mi opinión es acerca de cuándo se dispara y no de cómo se hace.

[pedrobaeza]

Como digo, @ozono, ya tienes que montar más y más cosas que connector te da "de fábrica".

La cola no require de cron para activarse. Como digo, puedes programar un delay específico, o una fecha y hora hasta la que no se puede ejecutar, así que lo de por la noche podría ser que se le ponga esa hora.

[ozono]

@pedrobaeza si con la solución que comentas se puede configurar cuando lanzar el proceso y se obtiene el suficiente feedback activo acerca de cómo ha ido la ejecución para arreglar posibles errores, entonces, estamos de acuerdo: es válida cualquiera de las dos soluciones.

+1 para poder controlar el momento de ejecución.

[acysos]

Un tema tal vez no se sepa, pero el SII permite modificar facturas, y comunicarlas. Lo que no permite es mandar en bloque altas y modificaciones juntas. Tienen que ir siempre separadas.

Respecto a la noche, me refería con delay, ya que el connector no tiene cron como tal, como ha comentado @pedrobaeza eliminando el trabajo y creando uno nuevo. Pero si ya se ha dado de alta y que mandarla como modificación.

[pedrobaeza]

Anda, pues efectivamente no sabía yo que se podían enviar modificaciones! Bueno, mejor en cierto modo, aunque hay que ver si bajo algunas condiciones. Además, eso me suena a trampa para pillar ciertas modificaciones sospechosas a principios de año sobre facturas del año pasado :stuck_out_tongue:

[acysos]

Podría ser una trampa, a mi lo que más me mosquea del SII es que también se puede dar de baja, esto es lo que dejaré para el final porque no tengo muy claro en que condiciones, que no las aclaran bien, además que sería un problema de secuencias y fechas.

[newsages]

Se pueden enviar altas A0. Modificaciones A1 y bajas en los libros. Yo tengo creada una api en laravel para todo eso y navision se conecta y envia. El soap de respuesta se procesa y se sabe la situacion de cada envio[registros].

[Paquinyo]

Me interesa la api en laravel.

Saludos

[pedrobaeza]

Si esa API no es abierta, es un comentario que no cabe aquí. Si lo es, incluid enlace al código fuente. Si no, borraré los mensajes correspondientes para no ensuciar el hilo con "publicidad".

[AngelCamacho]

En principio por lo que me parece que lei las Modificaciones irian aquellas facturas que se han enviado en el fichero de altas y no han sido aceptadas. Por lo que toca al usuario corregir la info y volverla a enviar. Por eso considero que serà importante tener un registro de cada factura y su situació (enviada, con errores, etc...).

[newsages]

Paquinyo, esta en mis repositorios, newnav se llama, esta adaptada para nav, fijate en la carpeta Api, alli tienes el controller de envio y respuesta soap. Pedrobaeza, es abierta pero no es para ooooddo, eso si es un motivo para que no este aqui. BeFree.

[pedrobaeza]

@newsages, siempre se puede buscar una librería común a la que luego se añada una capa para cada programa (si merece la pena ese nivel de abstracción, claro). En cualquier caso, como mínimo siempre viene bien para consultar entre proyectos la implementación concreta. Gracias por tu espíritu abierto :wink:

[wsandoya]

Hola,

A modo resumen, trabajo en empresa A y soy propietario de una empresa B.

Estoy haciendo un módulo para la empresa A, en la que trabajo, donde realizaré la siguiente estructura:

• Objeto sii.envio, donde guardaré el estado de todo el envío, la acción a realizar y las facturas enviadas (diferenciando entre facturas enviadas y facturas recibidas). La webservice del SII devuelve 3 estados, Procesado completo, procesado parcial y rechazado totalmente.
• Objeto sii.envio.factura, donde guardaré el estado de esta factura en el envío "equis", la acción, el estado y el error o los errores que devuelva la webservice del SII.

En principio empezaré con el alta, modificación y baja de las facturas emitidas y luego continuaré por las facturas recibidas. No tengo en cuenta los cobros, al menos en esta primera etapa.

Actualmente he hecho esta estructura en SQL Server y .Net, pero para mi empresa B, donde soy propietario, necesito hacerla en Odoo. Conforme vaya avanzando os iré informando y dejando información.

Saludos.

[acysos]

@AngelCamacho es correcto, es lo mismo que lei yo. Que si modificas la factura la comunicas como un nuevo archivo pero nunca pueden ir mezcladas modificaciones y altas. De hecho vamos a controlar el estado, porque sino no se podría saber el estado y mandar de forma separada.

@wsandoya haremos doble trabajo, creo que es lo que se debería evitar, de todas formas SQL Server y .Net no deberíamos usar, no va a funcionan correctamente en ningún servidor linux. Nosotros seguiremos con Zeep que es libreria python y funcionará en todos los entornos

[AngelCamacho]

@acysos Sip, eso tambien lo lei yo y evidentemente esto es lo que nos indican en la documentación oficial. Perfecto si tenemos el registro del estado de cada una de las facturas ya que serà essencial por lo que indicabamos del envio de forma separada, a parte del control por parte del usuario saber posteriormente que facturas no han sido aceptadas y por lo tanto tiene que modificar y reenviar.

Vemos que lo tienes todo controlado. Enhorabuena.

[newsages]

A ver. Envias un tipo. Te responde del estado del ENVIO. Mal . Correcta o correcta con errores.

Luego consultas por ejercicio periodo y opcional documento.de ese mismo tipo. Y te da el estado en la aeat.

[infobit]

Hola, también estamos dispuestos a colaborar. Tenemos varios clientes en diferentes versiones y estamos avanzando bastante, pero se nos plantean algunas dudas.

Por lo que comenta @acysos parece que estamos en la misma fase : estamos utilizando Zeep y ya estamos mandando altas, bajas y consultas por medio de scripts en python y todo ok (salvo algún mensaje sin sentido por parte del SOAP). Estamos esperando a mañana día 7 para probar la nueva versión 05 para ver si se subsanan algunos errores y los citados mensajes.

Respecto al envío de información, todavía estamos analizando la mejor forma de hacerlo, ya que estamos estudiando toda la información que proporciona la aeat y nos surgen dudas.

Esta cuestión nos tiene un poco mosqueados :

copio y pego :

---

_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.

[acysos]

Aquí parece que todo el mundo lo quiere hacer, me parece muy bien, pero yo no quiero duplicar trabajo, así que nosotros paramos el desarrollo y les dejamos a los demás.

Saludos

[pedrobaeza]

Ignacio, tú fuiste el que antes lo dijo, así que creo que deberías seguir con él. Dentro de los que lo han dicho que están haciendo algo, tú eres el más experimentado en OCA (dentro de que haya guidelines que se te resistan, jeje). Pero bueno, ya lo que tú veas.

[Roodin]

Pues sí que resulta curioso cuanta gente quiere trabajar en esto , sí.... Todo un tema a estudiar, con la cantidad de cosas que se podría hacer.

Ignacio, un consejo, siqgue con él pero ya sabes, Release early, release often. Publica tu modulo como WIP y aunque se una versión muy, muy previa y no funcional, da igual
Y para todos los que quereis contribuir hacedlo sobre esa revisión y si tan impacientes estais, haced también un PR con vuestro trabajo y los demás podremos contibuir eligiendo, corrgiendo o aportando.

Menos hablar y más código ;)

[newsages]

mañana,, version 0.5 de SII, cambian puntos de entrada y modificaciones de esquemas.

[infobit]

Disculpad, creo que no me expresé bien o no se me entendió. La intención no es subirlo a OCA ( sobre todo por como dice Pedro por nuestra inexperiencia en su uso ) . La intención es subir lo que tenemos en nuestro git, a disposición de todos para que quien quiera se lo baje y vaya haciendo pruebas contra el SOAP de hacienda. Nos ha costado bastante trabajo entender el funcionamiento y hacerlo funcionar y entendemos que ahorramos bastante trabajo al que quiera comenzar a colaborar.

Nuestra intención no es otra que colaborar ( de la forma que sea ) con quien tome la iniciativa.

Hoy cambian la versión, hacemos las pruebas y publicaremos el script adaptado a la nueva versión ( en nuestro git )

[acysos]

@pedrobaeza Sin duda a veces somos más pragmáticos que puristas, pero contaba contigo a que recalcarías ciertas guidelines o harías PR con ellas ;)

@Roodin No vamos a hacer doble trabajo, anunciamos que lo estábamos haciendo y que a finales de febrero estaría, porque estaba comprometido así con nuestro cliente, pero esta claro que hay gente nueva que quiere su hueco en la localización y poner que son colaboradores y miembros, por eso de repente muchos quieren hacerlo y no ha respetado a la empresa que indico que lo iba a realizar. Me parece bien y los entiendo pero creo que como pasa en muchos sitios de software libre si alguien ya esta invirtiendo tiempo debería respetarse.

@infobit Nadie ha interpretado que puedas presentarlo en OCA, el tema es que ya había indicado otra empresa que lo estaba haciendo y nos hemos pisado el trabajo que hemos hecho, y el esfuerzo que ha costado como tu indicas, solo por no leer que ya había otra empresa o querer hacerlo vosotros. Por lo tanto, nosotros lo hemos parado, obviamente tengo clientes que lo necesitan, por lo tanto, no abandonamos simplemente lo paramos, si al final los demás no cumplen o no son capaces lo retomaremos.