Ajustes de Fiscal Requirements para que se adapte a la nueva forma en como openerp trata a los objetos de negocio

Se comenzara por ajustar los objetos que en fiscal requirements estan vinculados con el antiguo res.partner.address

Tomaremos en consideracion que dado que ahora res.partner tiene de primera instancia
tiene toda la informacion necesaria para comenzar a facturar.

con este nuevo enfoque openerp nos indica que ahora se le puede vender a cualquier
ente, sea una empresa o sea este un contacto, lo que intentamos es determinar
cual seria la mejor aproximacion que debemos tomar en la localizacion venezolana (ovl)
para intentar en lo minimo romper el funcionamiento que ha agregado openerp,
y de igual manera que la ovl se aproveche de esta nueva caracteristica.

Revisando la funcionalidad del seniat_url, verifique, que es posible que no sea
necesario forzar el uso de un country en el registro de la direccion del partner
puesto que el VAT ya lleva intrinseco el pais asociado al RIF [1]

Existe tambien una funcionalidad que me gustaria utilizar, seria mezclar
el funcionamiento de la actualizacion del RIF con la revisiones de VIES
de tal forma utilizariamos los mismos metodos que ya usa Openerp y
el mismo boton, de check_validity,

La funcionalidad original de openerp, permite dejar el campo vat en blanco
para el caso de la OVL, debemos establecer un mecanismo que permita
en un ambiente multicompany / multicountry, que funcione normalmente
como openerp establece la funcionalidad pero que en el caso de tratarse
de una empresa en Venezuela, el VAT no pueda estar vacio, ni los campos
de Street, City, Country

para esto tengo la idea de que una de las validaciones se haga cuando
se intente generar una factura para una compañia VE, pero esto seria
la funcionalidad correctiva,
debemos buscar la funcionalidad preventiva, que es cuando se
esta creando el partner, esto se podria hacer usando el uid.company_id.res_partner.vat
si el usuario que esta creando los partners esta cargado ocn una empresa
venezolana, entonces al crear partners debera estar obligado a capturar
el VAT / RIF, si no es venezolana pasarlo por alto

en la revision al codigo de update_rif, considero que el metodo, se llama de forma
inadecuada, puesto que antes de llamarse el metodo, debe verificarse previamente
si el valor del VAT / RIF es estandar del base_vat_ve,
considero que esto se podra solucionar al integrar update_rif con el enfoque de
button_check_vat de openerp.

hay que tener pendiente la consideracion de que en Venezuela no solo es legal
usar el RIF, sino tambien la C.I. y el No. de Pasaporte.
entonces check_vat_ve debe tener en cuenta estas situaciones.

Se me ha puesto cuesta arriba encontrar una manera en la que usando los mismos
argumentos que ha utilizado openerp, para consolidar empresas, en la v6, teniamos
el campo parent_id, cuyo concepto, era que la compañia con dicho atributo pertenecía
a otro grupo mas grande, esto nos permitia, flexibilizar la restriccion de unicidad del
RIF, pues era la unica excepcion en la cual una empresa podia repetir el rif de otra
siempre y cuando la otra fuera su padre/madre.
En el enfoque nuevo de openerp, este campo se usa con el siguiente concepto,
todo res.partner que tenga un parent_id es una persona, si le factura a dicha persona
las facturas apareceran con dicha persona pero contablemente iran a la empresa
matriz. esto suena fabuloso, hasta vuelvo a la realidad de las implementaciones,
donde se tienen empresas que han fragmentado a sus clientes por sectores geograficos
o por sectores de mercado, y cada uno de estos sectores es una entidad independiente,
para razones contables, o para el pago de comisones por ejemplo, realmente alli
se encuentra todo el meollo del asunto.

El huevo antes de la Gallina (porque primero fue la gallina, hay evidencia cientifica)
=================================================================
./wizard/account_invoice_refund.py:123: awi_obj=self.pool.get('account.wh.iva')
./wizard/account_invoice_refund.py:129: wf_service.trg_validate(uid, 'account.wh.iva', ret_iva_id, 'wh_iva_confirmed', cr)
./wizard/account_invoice_refund.py:130: wf_service.trg_validate(uid, 'account.wh.iva', ret_iva_id, 'wh_iva_done', cr)

./wizard/account_invoice_refund.py:112: ret_islr_id=False
./wizard/account_invoice_refund.py:119: if i.name == 'islr_wh_doc_id':
./wizard/account_invoice_refund.py:120: if invoice.islr_wh_doc_id:
./wizard/account_invoice_refund.py:121: ret_islr_id = invoice.islr_wh_doc_id.id
./wizard/account_invoice_refund.py:124: iwd_obj=self.pool.get('islr.wh.doc')
./wizard/account_invoice_refund.py:132: if ret_islr_id:
./wizard/account_invoice_refund.py:133: iwd_obj.action_confirm1(cr,uid,[ret_islr_id],context=context)
./wizard/account_invoice_refund.py:134: wf_service.trg_validate(uid, 'islr.wh.doc', ret_islr_id, 'act_done', cr)

En el wizard de notas de credito aparecen unas llamadas a modelo que en momento de la instalacion de este modulo aun no estan declarados, debemos sacar estas declaraciones al modulo de retenciones iva, y en el momento adecuado realizar la herencia para incluir este comportamiento, lo mismo va para islr.

En la tarea (12.1) hablo acerca de que debemos estructurar el wizard para que cuando se muestren las facturas a las que se ven a hacer referencia, el dominio de las mismas este relacionado con el partner en consideracion, la compañia padre, si el padre en cuestion es parte de un grupo mas grande, y mostrar a sus compañias hermanas, de no hacerlo asi, considero que entonces podremos estar perdiendo algunos registros que pudieran estar relacionados con la factura considerada.

Fiscal Requirement no tendra mas el control sobre la existencia de las notas de debito
porque se considera que este es un modulo mucho mas generico, y no especifico, de la localizacion venezolona, por lo tanto el mantenimiento de las notas de debito y sus funcionalidades
mas generales estaran fuera del ambito de este modulo.

Existen consideraciones que son propias de la legislacion venezolana donde se debe
ajustar a la legalidad algunas caracteristica de las notas de credito que se esta proponiendo
como modulo generico en addons-vauxoo, por lo que en el futuro se haran ajustes dentro de este
modulo para dichas situaciones especificas.

Estamos muy cerca de alcanzar un buen algoritmo para unicidad y obligatoriedad del RIF,
necesitamos un poco de ayuda para alcanzar el objetivo de la tarea (3).

durante el dia de mañana es muy posible que culminemos el algoritmo y sobremarchemos las vistas

Los wizards y sus revisiones, los dejaremos en POSTPONED, con excepcion de aquellos relacionados con las notas de credito. son muy importantes.

[1] en otro punto de vista, es posible que podamos usar en conjuncio el pais,
para otras funcionalidades, pero no considero que para la validacion del RIF
sea necesario incluir el pais, para ese caso

Work items:
(1) Usar el mismo metodo button_check_vat de openerp para que actualice la informacion fiscal de los partner cuyos VAT / RIF son de VE: DONE
(1.1)This should only work for VE VAT CODES. : DONE
(1.2)FIX update fiscal information method so that it could be possible to update the fiscal informacion of people with ID, i.e, those who has no RIF, PARCIALMENTE Solucionado, cuando se introduce una Cedula, y la persona tiene un RIF, se actualiza con el RIF. : DONE
(1.3)FIX update fiscal information method so that it could be possible to update the fiscal informacion of people with PASSPORT, i.e, those who has no RIF. Se puede vivir sin esta caracteristica, cuando se solucione se introduce como un FIX, Si tienes la solucion propon un merge: POSTPONED
(2) Cambiar en la vista de res.partner la ubicacion del campo vat la parte de arriba para su facil visibilidad: DONE
(3) Hacer que se marquen como requeridos los campos Street Citiy country_id y VAT cuando el user_id.company_id.partner_id.country_id.code == 'VE' [YANI] : DONE
(4) Determinar logica de cuando un se puede repetir un VAT y cuando no, en el caso de que el user_id.company_id.partner_id.country_id.code == 'VE' y el partner que se esta registrando tiene 'VE' in VAT[2] => True [KTY]: DONE
(5) Determinar si se debe restablecer restriccion de unicidad de direccion fiscal en el partner cuando user_id.company_id.partner_id.country_id.code == 'VE (Aun no consigo armar una idea solida, para determinar una manera de como se deberia establecer la unicidad de RIF/DIRECCION FISCAL)': [YANI]: DONE
(5.1) Determinar que se debe hacer con el metodo copy de res.partner, para dar cumplimiento con la unicidad del RIF.: POSTPONED
(5.2) Determinar que se debe hacer con el metodo create de res.company si llegara a verse en la necesidad de violar la restriccion de unicidad del RIF, : POSTPONED
(5.3) Restriccion de Unicidad del RIF [YANI]: DONE
(5.4) Restriccion de Obligatoriedad del RIF [YANI] : DONE
(5.5) Revisar metodo vat_change_fiscal_requirements en modelo res.partner del modulo l10n_ve_fiscal_requirements: POSTPONED
(6) cambiarle el nombre al modulo de 'Requirements for Venezuela' to 'Venezuelan Fiscal Requirements': [YANI]: DONE
(7) Revisar donde se esta incorporando la clave al context 'all_rif', y que otro modelo la usa, esta clave se usa cuando se envia a actualizar su RIF a un lote completo de partners, con este valor se evita que se salga del ciclo cuando encuentra un RIF invalido: DONE
(7.1) Escribir en cada partner en la mensajeria cuando se actualizo, y cuando no se pudo actualizar: TODO
(8) Cambiar la firma que se llama en esta linea, ya que el metodo ha cambiado de firma ./l10n_ve_withholding_iva/model/partner.py:58 wh_rate = su_obj._buscar_porcentaje(rif,url_seniat) : TODO
(9) Revisar que funcione el wizard para consulta de RIF con el SENIAT (URGENTE): DONE
(9.1) Agregar la funcionalidad de mostrar los partners que existen para el RIF consultado en la vista del Wizard (PRIORIDAD BAJA): TODO
(9.2) Agregar la funcionalidad de mostrar los partners en una vista en tree de los partners del resultado anterior (9.1) (PRIORIDAD BAJA): TODO
(10) Arreglar wizard para actualizar todos los partners de la localizacion: DONE
(11) Revisar Wizard de Papeles Dañados (wizard_invoice_nro_ctrl.py): TODO
(11.1) Actualizar Vista de res.company ya que no se muestran los campos que se necesitan en la misma, [HBTO]: DONE
(12) Actualizar el Wizard de cambio de padre, account_invoice_parent.py, se queda atascado, en un ciclo.: TODO
(12.1) Dado que en Openerp ahora a cualquiera se le puede facturar, en el wizard ahora se debe mostrar las facturas del partner en cuestion, su padre y sus hermanos. : TODO
(12.2) Usemos _check_recursion del ORM y dejemos de usar check_incest, check_grandfather, en account_invoice_parent.py, dejemos que el ORM trabaje por nosotros, (PRIORIDAD BAJA) : TODO
(13) Las notas de debito no cuentan con un diario para las operaciones de las mismas, se esta usando el mismo de las compras o ventas, segun sea el caso, discutir la reinstauracion de los diarios para las notas de debito, mi razon es que las mismas deben llevar un correlativo propio, tal como las facturas y las notas de credito: TODO
(13.0) SACAR DE ESTE MODULO TODO LO QUE TENGA QUE VER CON LAS NOTAS DE DEBITO, Y SOLO DEJAR UN SOCKET PARA SU INSTALACION EN __OPENERP__.PY, TODAS LAS TAREAS DE LA 13. EXTRAERLAS A OTRO BRANCH PARA FUTURAS REFERENCIAS, el socket puede ser la instalacion de un modulo que ya existe en vauxoo-addons, sea dummy o real : TODO
(13.1) Agregar las opciones de diario de notas de debito al modelo de account.journal [HBTO] : DONE
(13.2) Revisar el modelo para que se considere los nuevos tipos de diario cuando se haga referencia a las notas de debito [HBTO]: DONE
(13.4) Crear data para diarios de notas de debito, las secuencias de los diarios debe ser sin gaps: TODO
(13.5) En metodo compute_debit en el bloque if not form['period'], sustituir por el apropiado metodo de buscar un period dado una fecha, añadir en el proceso la company_id: DONE
(13.6) El wizard de notas de debito esta usando un diario de venta/compras, no esta usando los que se establecieron en el mismo para crear la factura.: DONE
(13.7) Agregar Menu para Notas de Debito de Venta y Compra, asi como sus vistas: DONE
(13.8) Cuando se termine el wizard de Nota de Debitos, enviar a la vista antes generada, y no la vista de las facturas | Se genero una accion, en la que el journal_type del context es el correspondiente a cada tipo de transaccion.: DONE
(13.9) Quitar el metodo _get_period, o marcarlo para obsoletizacion, y dejar de usarlo en la clase. El modulo account en el modelo account.period ya cuenta con un metodo para encontrar un periodo para una fecha dada o sin dar una fecha, siendo la fecha no dada la del dia de hoy, : DONE
(14) revision de posibles errores: POSTPONED
(14.1) error en el campo account en la vista para crear una customer invoice. Dice que no hay cuenta cuando si hay cuentas creadas y estas deberia de mostrarse, creo que tiene que ver con la compañia: POSTPONED
(14.2) en el wizard de account.invoice.debit _get_journal se calcula con la compañia del usuario actual, deberia de calcularse con la compañia del account.inovice: POSTPONED
(14.3) filtrado de periodos en la vista del wizad account.inovice.debit. muestra todo los periodos sin distinguir que compañia es la nota de debito, pero sucede que esto es un error porque se podria elegir un periodo que realmente no aplica a esa compañia: POSTPONED
(14.4) No se estaba almacenando el periodo en la tabla account.invoice.debit [KTY]: DONE
(15) Revision de las pruebas YAML: DONE
(16) En la factura account.invoice, dependendiendo si es venezuela o no, se pide que el valor ref, sea obligatorio.: TODO
(17) Todo usuario es un PARTNER, hay que agregar un context en el write y create de res.users para poder saltarse la validacion de unicidad y obligatoriedad: TODO
(17.1) Agregar luego los campos adecuados a las vistas de res.users para que se llenen los campos requeridos existente en res.partners: TODO
(1000) Cambiar la herencia de las clases del antiguo osv.osv => osv.Model / osv.osv_memory => osv.Transcient ESTA TAREA ES IMPORTANTE PERO NO IMPRESCINDIBLE: TODO