…c module for aeat models, 347 module was portedto v6.0 and adds new module to print AEAT model 349.

…ueñas mejoras generales (vistas, traducciones, código) y corrección pequeño bug por un olvido en la adaptación de la v5 a la v6

* Only use the first four digits of fiscal year's code to determine fiscal year's number and also give a decent message to the user if it's not a number instead of simply crashing.
* Hacer opcional el campo Operation Key en las facturas, permitiendo que esté en blanco.
* Ser un poco menos rigurosos con que el año esté en el código del año fiscal. Atención: deberíamos añadir un campo con este valor en lugar de hacer este hack.

* FIX: Corregimos una serie de errores que había en las rectificaciones a la hora de obtener las declaraciones originales, si había alguna que cumplía los requisitos pero sin pertenecer a un modelo. Quizás se solucionara mejor con un on_delete='cascade'.
* RFR: Cambio de licencia de GPL3 a AGPL3 en el resto de módulos de localización española, con el consentimiento de todos los autores expresado vía lista de correo del equipo de localización openerp-spain@googlegroups.com

* Only use the first four digits of fiscal year's code to determine fiscal year's number and also give a decent message to the user if it's not a number instead of simply crashing.
* Resolve a problem with python isinstance which considers 'False' is an integer and which makes OpenERP create operation_key field as integer instead of char.
* Convert a return None to return False, because the XML-RPC protocol doesn't support returning None.

…or: global name 'pooler' is not defined" al iniciar el calculo.

… sólo uno y arrelgar un bug en la generación del modelo cuando el partner tiene el campo title lleno.

…y H que son respectivamente Entregas intracomunitarias con exención de tasas y Entregas intracomunitarias con exención de tasas por un representante fiscal oficial fueron publicadas el 26/11/2011 en el boe. Se puede ver el artículo en: http://planartus.blogspot.es/1309888740/

…ron marcados como no instalables mientras no se compruebe que funcionan o migren, para poder usarlos o probarlos se debería poner el atributo installable de los ficheros __openerp__.py de cada módulo a True

…n os import de objetos de OpenERP, el namespace openerp, refactorizado a PEP-8 y adaptacion vistas a formato 7

…n_es_aeat.

* Traducciones.
* Vista del wizard BOE
* Vistas de facturas mejoradas
* Icono
* Asignar una clave a las facturas ya existentes.

…49 y l10n_es_payment_order

…turas rectificativas a declarar.

…e o2m

[FIX] l10n_es_aeat_mod349: Añadida restricción que impide eliminar facturas que aparezcan en registros de detalle

* IMP: Fiscal position onchange in new API + speed imp + refactoring
* FIX: l10n_es_aeat_mod349: Remove check of names

  There's no need of a check about the name validity, because l10n_es_aeat
  already transform all the exported strings to valid ASCII characters
  (though unidecode), so I remove it entirely this check.

* FIX: Use first period year in export

  Relying in fiscal year code for getting the fiscal year is not safe,
  because you can use that code for defining your journal sequences (for
  example, with the module account_auto_fy_sequence).

  We can't use also the year of the fiscal year, because you can have
  split fiscal years (i. e. like the academic courses). What we uses then
  is the year of the first period of the declaration, as there's no
  legal possibility of having mixed periods from different years.

…xport

…er calcular el 349 en períodos distintos de los fiscales

* Pylint
* Use new API

[skip ci]

* Mejora del rendimiento.
* Apuntes contables como fuente de datos. El motor del informe se construye a partir de apuntes
  contables, y la información de facturas se consulta cuando se necesita. De este modo aseguramos que
  los resultados serán consistentes con los otros modelos de AEAT, que también toman como fuente de
  datos los apuntes contables. Así evitamos posibles inconsistencias.
* Nuevo informe Qweb, que sustituye al antiguo RML
* Correcciones para exporación a formato BOE. Permite importar el modelo a la web de hacienda.
* Permite borrar operaciones que no se quiere declarar. El usuario puede eliminar las operaciones que
  no desee incluir en la presentación. Esto será especialmente útil en el caso de presentaciones
  complementarias.
* En declaraciones normales y complementarias se excluyen automáticamente operaciones ya
  presentadas anteriormente.
* Script de migración para tener en cuenta los cambios en el modelo de datos.

* Save in account.move.line directly the 349 export key via a selection field, so you are not bound to a map line record instead of mapping changes.
* Field renamings for better understanding.
* Map data with command `4` instead of `6` for allowing custom mappings.
* Added constraint for avoiding duplicated mapping lines with the same operation key.
* Fix tests asserts and code
* Fix refund records computation
* Complete behavior for imported move lines declarations
* Switch certain fields to computed ones, for avoiding extra code that can be handled easily with ORM, but without performance penalty thanks to norecompute ORM option.
* Remove useless check for invalid characters, as export now removes them

* Raise error with amount zero records (invoices+refunds=0.0)
* l10n_es_aeat_mod349: Missed by name param assignation precision_rounding

…ontables

asociados a una factura que no apuntan directamente a una línea de factura.

Fix readme

* If views are not restricted to invoicing users, salesman won't be able to see the invoices.
* Current code doesn't share anything with original one, in approach nor lines of code, so
  original authors shouldn't be in the manifest key. I keep the copyright any way for
  historical reasons.

* Standard procedure
* README by fragments

Copy/paste operation left out one needed tax.

This way, we don't initially see all the subconfigs for each model and we can concentrate
on main export configurations. This is got through `active` field default behaviour.
Archived config are still directly searchable through the subconfig selector in the
configuration line.

All models export configs have been adapted to this new approach.

As the VAT number should start with 'EL', not the country code 'GR'.

Currently translated at 100.0% (146 of 146 strings)

Translation: l10n-spain-12.0/l10n-spain-12.0-l10n_es_aeat_mod349
Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-12-0/l10n-spain-12-0-l10n_es_aeat_mod349/es/

… refund link

Code was not adapted to new v12 date fields with Python objects.

Courtesy of Jesús Ramoneda

* Include chatter (mail.thread)
* Include activities (mail.activity.mixin)
* Track AEAT report state change
* Include new admin user in AEAT group by default

…od_type needs 2

…s del apunte.

…port to draft

This way, we allow things like cancelling invoices that are included in the report.

Continuation of 611c24b and later commits. This way, we can decouple tax label from
the matching, thanks to the XML-ID that Odoo gives to created taxes. We also
simplifies the code thanks to this.

Currently translated at 82.5% (146 of 177 strings)

Translation: l10n-spain-12.0/l10n-spain-12.0-l10n_es_aeat_mod349
Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-12-0/l10n-spain-12-0-l10n_es_aeat_mod349/es/

**Steps to reproduce**

- Create an intra-community invoice with several lines in May.
- Create a 349 AEAT report for May and calculate it.
- Refund the invoice in June.
- Create a 349 report for June and calculate it.

**Current behavior**

You get double origin amount in the refund record.

**Expected behavior**

Get proper origin amount.

**Solution**

We have to pre-group refund details by origin invoice, and then process them in
batch for getting the total amount.

It includes regression test.

- General procedure
- In report change type > statement_type + migration script
- Computation adapted
- Adapt account.invoice > account.move in logic + migration script
- Adapt tests

The calculation that was being done until now in the field origin_amount is incorrect since the total of the lines of the invoice to rectify was being added. The correct way is to add all the lines of the invoices of the period where the lines of the invoice to rectify are. Also, we must keep in mind that if there are intermediate periods between the original period and the period where the rectification is taking place, it's necessary to check if there is any rectification of the original period in between these periods. This happens in this way because the right original_amount  will be the value of the total_operation_amount corresponding to the last period found in between the periods

This commit has been based from this OCA#1579

There's a VAT formatting method that adds country code if not present
in the partner vat. This method is not useful at all, as all European
VAT numbers should have country prefix for being validated in invoices,
so there's not too much sense to try to reformat it. There are also
cases where a big company has one country VAT number, but has fiscal
address in other country, resulting in an incorrect reformating.

Not even that, there are old style onchanges that are not ever
triggered, as the XML declaration disappeared or is not effective as the
view is readonly, becoming dead code.

This commit removes all this stuff, with no expected side effects.

Currently translated at 100.0% (177 of 177 strings)

Translation: l10n-spain-14.0/l10n-spain-14.0-l10n_es_aeat_mod349
Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-14-0/l10n-spain-14-0-l10n_es_aeat_mod349/es/

The sum of the untaxed amount of the refunds might be not rounded, which
leads to having a fake partner_refund_ok = False, although all refund
data is correct.

With this preventive rounding, we avoid the problem and have the awaited
total_operation_amount.

The same detail from here: OCA#2129 (comment)

Just same name as other AEAT modules

Currently translated at 84.1% (143 of 170 strings)

Translation: l10n-spain-15.0/l10n-spain-15.0-l10n_es_aeat_mod349
Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-15-0/l10n-spain-15-0-l10n_es_aeat_mod349/ca/

Currently translated at 99.4% (169 of 170 strings)

Translation: l10n-spain-15.0/l10n-spain-15.0-l10n_es_aeat_mod349
Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-15-0/l10n-spain-15-0-l10n_es_aeat_mod349/ca/

Currently translated at 100.0% (170 of 170 strings)

Translation: l10n-spain-15.0/l10n-spain-15.0-l10n_es_aeat_mod349
Translate-URL: https://translation.odoo-community.org/projects/l10n-spain-15-0/l10n-spain-15-0-l10n_es_aeat_mod349/ca/

Fixing subtree width not responsive. See odoo/odoo#90946 for a similar situation where a similar fix was needed.

Took the chance to make more columns optional.

@moduon MT-1267

…the records to be sorted.