[ADD] l10n_es_facturae_face #577

etobella · 2017-07-12T13:15:26Z

Este módulo depende del PR #576.
Nos permite gestionar el envío de facturas a FACe (seleccionando producción o desarrollo en la configuración) y su gestión (anulación, actualización de estados, etc.)
Cómo que la firma de SOAPs no acaba de funcionar correctamente, se ha realizado la firma en un código Java de mi repositorio que se ejecuta por llamada.
Para que funcione, debe utilizarse un certificado aceptado por FACe para firmar las facturas y los envíos. Además, debemos registrarnos en FACe como proveedores con la parte pública del certificado:

https://se-face.redsara.es/es/proveedores : Testeo
https://face.gob.es/es/proveedores : Producción

pedrobaeza · 2017-07-12T14:26:07Z

Por qué se separa en dos módulos distintos?

etobella · 2017-07-12T15:07:17Z

Lo separé debido a que no es el único modo de envío (e.Fact en Cataluña por ejemplo) y me pareció mejor a nivel de escalabilidad. Si lo queréis unir se puede unir sin muchos problemas.

pedrobaeza · 2017-07-12T15:58:57Z

Uhm, en parte está mejor separado pero en parte junto. Me explico:

El módulo base debería tener código genérico para realizar el envío, junto con campos para almacenar log, respuesta, estado de envío, etc (lo que se considere).
Los distintos métodos de envío deberían entonces añadir la opción a nivel de compañía para seleccionar ese método, y que los métodos genéricos de envío se sobreescriban y si el método seleccionado es éste, entonces desencadene el código correspondiente. Si no, que llame a super para seguir la cadena.
Entonces, este método de envío que ponéis aquí, si es el más genérico a nivel español, podría ser interesante de integrarlo en el módulo base a modo de referencia, pero dejando el sistema preparado fácilmente para otros posibles métodos de envío.

etobella · 2017-07-12T16:27:38Z

Normalmente el sistema de envío no viene definido por la compañía, sinó por el cliente, que es el que define como quiere recibir la documentación.
Además, los diferentes sistemas de envío no se parecen excesivamente. Por ejemplo, el sistema de envío a FACe es mediante soap y en cambio todo el procedimiento de e.Fact se realiza a nivel de SSH. A nivel de Log podemos tener como fué el envío y los cambios de estado detectados, pero no mucho más. Además, los campos de estado entre unos y otros no se parecen demasiado. En un principio iba a separarlo, debido a que los clientes con e.Fact no usan FACe y su comportamiento es muy diferente.
De todas formas, podemos crear un sistema de integración de facturas base (que no es ni e.Fact ni FACe) y montamos ambos encima de este.
Por otro lado, integrar FACe dentro del módulo de facturae para mi no tiene sentido. Existen clientes en España que utilizan la facturación electrónica sin ninguno de los sistemas de integración, debido a que les permite integrar de forma automática las facturas en su sistema. De hecho, nosotros tenemos proveedores que nos envían la factura en PDF y en xsig.
Si os parece bien, creo un módulo de envío genérico y lo extiendo para que se pueda enviar a FACe. ¿Ok?

pedrobaeza · 2017-07-12T16:39:19Z

Normalmente el sistema de envío no viene definido por la compañía, sinó por el cliente, que es el que define como quiere recibir la documentación.

Vale, pues igualmente nos vale, pero movemos el selector de método de envío al res.partner y es lo que chequeamos cuando pulsemos enviar.

Además, los diferentes sistemas de envío no se parecen excesivamente. Por ejemplo, el sistema de envío a FACe es mediante soap y en cambio todo el procedimiento de e.Fact se realiza a nivel de SSH. A nivel de Log podemos tener como fué el envío y los cambios de estado detectados, pero no mucho más. Además, los campos de estado entre unos y otros no se parecen demasiado. En un principio iba a separarlo, debido a que los clientes con e.Fact no usan FACe y su comportamiento es muy diferente.

Aunque sean diferentes, se activan de la misma forma (pulsando a "Enviar"), y lo que no quiero es que cada uno añada sus propias cosas (botones, vistas, campos...). Sí que pueden compartir campos genéricos como datos enviados, datos recibidos, etc, a los que acoplar esas peculiaridades de cada uno.

Por otro lado, integrar FACe dentro del módulo de facturae para mi no tiene sentido. Existen clientes en España que utilizan la facturación electrónica sin ninguno de los sistemas de integración, debido a que les permite integrar de forma automática las facturas en su sistema. De hecho, nosotros tenemos proveedores que nos envían la factura en PDF y en xsig.

OK, lo seguimos dejando separado entonces.

Si os parece bien, creo un módulo de envío genérico y lo extiendo para que se pueda enviar a FACe. ¿Ok?

Pero y por qué no integrarlo en el propio módulo base y que el método de envío por defecto sea "Ninguno". Lo digo por evitar tener tantos módulos para una tarea que es común. Aquellos usuarios que no necesiten ningún método de envío, pues ese "trozo" de código no estará en uso, pero será mínimo.

etobella · 2017-07-12T16:52:47Z

Ok!
Creo el módulo base de envío sin ningún método en el módulo l10n_es_facturae y crearé la extensión de FACe en este.

pedrobaeza · 2017-07-12T16:57:48Z

Gracias, Enric! Te has integrado genial con el flujo de la comunidad / OCA 😉

etobella · 2017-07-13T15:58:54Z

@pedrobaeza ya he subido un módulo funcional y he añadido dos sistemas de envío. Uno de testeo que sólo funciona en Demo y el de FACe.
En principio funcionan ambos correctamente.
Aún me falta definir los testeos.+
cc: @jbeficent

pedrobaeza · 2017-08-08T14:24:47Z

l10n_es_facturae_face/README.rst

+
+.. image:: https://odoo-community.org/website/image/ir.attachment/5784_f2813bd/datas
+   :alt: Try me on Runbot
+   :target: https://runbot.odoo-community.org/runbot/189/8.0


pedrobaeza · 2017-08-08T14:27:34Z

.travis.yml

@@ -15,6 +15,10 @@ addons:
      # needed because server-tools is loaded in the dependency chain
      - unixodbc-dev
      - python-mysqldb
+      - libxml2-dev


A eliminar cuando se mergee el otro PR

pedrobaeza · 2017-08-08T14:28:05Z

l10n_es_facturae_face/__manifest__.py

+    ],
+    "external_dependencies": {
+        "python": [
+            "OpenSSL"


Por qué no pones aquí el resto de dependencias Python?

La tuve que poner por un problema con la verificación de Travis. Al tener un nombre distinto al que se instala (instalas PyOpenSSL pero se llama como OpenSSL en el código), daba problemas la verificación (detectaba que intentabas poner un elemento que luego no añadías en las dependencies)

Me refiero al resto de dependencias.

pedrobaeza · 2017-08-08T14:29:17Z

l10n_es_facturae_face/data/face_data.xml

+    </record>
+    <record id="account_invoice_face_certificate" model="ir.config_parameter">
+        <field name="key">account.invoice.face.certificate</field>
+        <field name="value">-----BEGIN CERTIFICATE-----


¿Este certificado para qué es? No debería venir como un archivo del módulo que se cargue en lugar de tenerlo como un parámetro de sistema. ¿Alguien lo va a cambiar manualmente? (no creo...)

Este certificado es el certificado de FACe en el entorno de desarrollo. Zeep solicita tener la parte pública del certificado de respuesta para verificarlo. Por lo tanto, debemos saber cual es el certificado. Además, cuando caduce este certificado (en 2020), deberemos cambiarlo.
Por lo general, cuando integras con FACe lo recomendable es probarlo primero en el entorno de desarrollo y luego passar al entorno de producción.

Vale, pero repito, ¿no tiene más sentido ponerlo como archivo y no sobrecargar los parámetros de sistema? En 2020, se actualiza el módulo con el nuevo certificado (o a las malas, copias el nuevo certificado en los archivos del módulo).

pedrobaeza · 2017-08-08T14:31:21Z

l10n_es_facturae_face/models/res_company.py

+class ResCompany(models.Model):
+    _inherit = 'res.company'
+
+    facturae_email = fields.Char()


Mejor que utilices un contacto de la propia compañía y cojas el mail de ese contacto.

¿No debería ser además face_email (cambiando de enfoque, face_partner)?

pedrobaeza · 2017-08-08T14:34:29Z

l10n_es_facturae_face/models/res_partner.py

+                lambda r: r.id == self.env.ref(
+                    'l10n_es_facturae_face.integration_face').id
+            ):
+                if not record.facturae:


No creo que sea necesario limitar tanto. Tú puedes desmarcar la casilla de Factura-E, pero que no te obligue además a quitar el método de integración, porque si no si luego tienes que volver a activarlo, hay que rellenar de nuevo el método de integración. Lo que debe tener prioridad es si tienes la casilla general marcada. Si no la tienes, pues da igual qué métodos de integración tengas puestos.

pedrobaeza · 2017-08-08T14:36:30Z

l10n_es_facturae_face/views/res_config_views.xml

+<odoo>
+    <record id="view_general_configuration" model="ir.ui.view">
+        <field name="name">General Settings</field>
+        <field name="model">base.config.settings</field>


Por qué aquí y no en la configuración de contabilidad?

Pues en su momento me pareció una buena solución, pero tiene más sentido en contabilidad. Realizo los cambios.

pedrobaeza · 2017-08-08T14:36:49Z

oca_dependencies.txt

@@ -3,7 +3,9 @@
 account-financial-tools
 account-financial-reporting
 account-payment
+community-data-files


A eliminar cuando se mergee el otro PR

pedrobaeza · 2017-08-08T14:36:55Z

oca_dependencies.txt

 bank-payment
 bank-statement-import
 partner-contact
 reporting-engine
+l10n-spain-facturae https://github.com/etobella/l10n-spain 10.0-mig-facturae


A eliminar cuando se mergee el otro PR

pedrobaeza · 2017-08-08T14:37:00Z

requirements.txt

@@ -3,3 +3,5 @@ unidecode
 unicodecsv
 requests
 xlrd
+zeep


A eliminar cuando se mergee el otro PR

etobella · 2017-12-29T11:23:59Z

Lo doy de baja debido a que ya se ha creado el PR directamente a 11.0

etobella mentioned this pull request Jul 12, 2017

10.0 Migration of Facturae #576

Closed

etobella force-pushed the 10.0-add-facturae-face branch from 10b91d7 to 8206cf4 Compare July 13, 2017 15:57

etobella force-pushed the 10.0-add-facturae-face branch 2 times, most recently from 22a5d2d to b25896c Compare July 31, 2017 12:07

pedrobaeza requested changes Aug 8, 2017

View reviewed changes

etobella force-pushed the 10.0-add-facturae-face branch 4 times, most recently from eb0e6c4 to b0d32b6 Compare August 10, 2017 06:51

etobella added 2 commits October 19, 2017 15:11

[ADD] l10n_es_facturae_face

db11aa8

Dependencies - To be deleted

db4acd6

etobella force-pushed the 10.0-add-facturae-face branch from 0251732 to 0be85eb Compare October 19, 2017 13:15

No travis wait

7578c3b

etobella force-pushed the 10.0-add-facturae-face branch from 0be85eb to 7578c3b Compare October 19, 2017 13:21

etobella mentioned this pull request Dec 29, 2017

[add] l10n es facturae face #733

Merged

etobella closed this Dec 29, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ADD] l10n_es_facturae_face #577

[ADD] l10n_es_facturae_face #577

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 13, 2017

pedrobaeza Aug 8, 2017

pedrobaeza Aug 8, 2017

pedrobaeza Aug 8, 2017

etobella Aug 9, 2017

pedrobaeza Aug 9, 2017

pedrobaeza Aug 8, 2017

etobella Aug 9, 2017

pedrobaeza Aug 9, 2017

pedrobaeza Aug 8, 2017

pedrobaeza Aug 8, 2017

pedrobaeza Aug 8, 2017

etobella Aug 9, 2017

pedrobaeza Aug 8, 2017

pedrobaeza Aug 8, 2017

pedrobaeza Aug 8, 2017

etobella commented Dec 29, 2017

[ADD] l10n_es_facturae_face #577

[ADD] l10n_es_facturae_face #577

Conversation

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 12, 2017

pedrobaeza commented Jul 12, 2017

etobella commented Jul 13, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etobella commented Dec 29, 2017