dansanti / l10n_cl_invoice

Sistema de apoyo a la facturación localización Chilena
https://globalresponse.cl
GNU Affero General Public License v3.0
1 stars 5 forks source link

Id_xml no existe pero se hace referenia en onchange #8

Closed celm1990 closed 6 years ago

celm1990 commented 7 years ago

En la funcion _check_vat se hace referencia a unos id_xml pero estos no existen, el error no aparece porque el campo sii_document_class_id no esta en la vista form, pero si agregaramos ese campo a la vista, empiezan a aparecer esos errores, en donde se crean esos registros o no son necesarios en ese onchange???

dansanti commented 7 years ago

Hola!

los id no son de xml, son de csv y sí están no había visto esa parte viene de original odoochile, pero la condición debiera ser if self.sii_document_class_id.id not in boleta_ids de lo contrario se compara un objeto contra un integer, cuano haya un poco de tiempo lo revisaré con tiempo

Danisan commented 7 years ago

Veo este comentario, y en el orginal de odoochile, no se maneja la lista boleta_ids. Ese análisis es posterior.. En el original se usa un modelo que se llama sii.document_letter que es el que fija los comportamientos en cuanto a los tipos de documento, y estaba modelado para poder incorporar distintos tipos de comportamiento, de acuerdo a los contribuyentes y que no haga falta hardcodear cosas. Por ejemplo el comportamiento de la boleta, se maneja(ba) con el external_id "dl_b", el comportamiento de factura con el "dl_a", el comportamiento de boletas de honorarios con el "dl_m", la factura de exportación con el "dl_e", y el liquidación factura estaba pensado para el dl_l.

No estaba del todo terminado el código, pero esa era la idea. Al no tener una interconsulta de como estaba pensado, se fué desviando para otro lado la idea original.

dansanti commented 7 years ago

Ok, el asunto es que la emisión de factura enbase al giro , comenzó a tornarse complejo, por el hecho de que hay contribuyentes que tienen actecos con y sin emisión, unidos en una sola glosa, entonces para facilitar la emisión se quitó la dependencia entonces, hay código que hay que actualizar, ahora recuerdo qe había dado la exención de la boleta, para permitir emisiones sin neceariamente usar rut, para que tomase el rut genérico.

Mantendré abierto para ver lo que hay que modificar, pero es algo que es necesario, a pesar de que en DTE se hace la validación también, pero acá almenos antes de que le pongan validar.

Danisan commented 7 years ago

Como te había dicho por md el otro día, que contabilizo todos los comprobantes de venta como invoice, el criterio que yo siempre había tenido con el tema boletas, inclusive usando el pos, es que las ventas se ingresan a un contribuyente denominado "Consumidor Final" o en algunos casos, para operadores más triviales "Cliente Boleta". De esa forma el responsability_id es siempre "consumidor final" o "cliente boleta" por defecto, (se puede poner al parnter el rut 6666666-6 entonces en ese caso el cl_invoice siempre seleccionaba como opción por defecto la emisión de un doc tipo "boleta", el cual se puede configurar en el mismo diario de ventas que las facturas.

dansanti commented 7 years ago

En invoice , claramente te obliga a usar un contacto, no he probado ese caso, a que mayormente las boletas salen por pos, y ahí es opcional seleccionar un cliente ( y que sga así, para no hacer tantos pasos), lo que tengo que agregar es el hecho , de que si no se ingresa rut, pero si se selecciona el cliente, poner el id interno que tiene en odoo ( creo que en este caso, el id en db), ya que para boleta el sii lo permite