odoo-colombia / l10n-colombia

Localización de Odoo para Colombia

Colombian localization

*To do.

Translation Status

---

OCA, or the Odoo Community Association, is a nonprofit organization whose mission is to support the collaborative development of Odoo features and promote its widespread use.

l10n-colombia's Issues

Mover y volver principal el repositorio

No aplica

12.0 Cuando trato de instalar el módulo l10n_co_account_e_invoicing ocurre el siguiente error

Estoy tratando de instalar odoo 12 en mi equipo local, creo la BD desde cero y empiezo a instalar módulos nativos, como el de CONTACTOS, CRM, COMPRAS, VENTAS, FACTURACIÓN, ENTRE OTROS... luego trato de instalar el módulo de facturación electrónica versión 12.0 que tienen disponible en el repositorio, pero me aparece el siguiente error.

En el addons_path, tengo relacionados todos los módulos de los que depende el módulo 12 para su instalación.

10.0 Construir módulo para clasificación de impuestos (l10n_co_account_tax)

Se requiere desarrollar el siguiente módulo para el manejo de la clasificación de impuestos:

Nombre Propuesto:
l10n_co_account_tax

Campos mínimos requeridos descritos a lo largo del anexo para fe:

• name (char) | Modelo: account.tax.scheme
• code (char) | Modelo: account.tax.scheme
• tax_scheme_id (many2one) | Modelo: account.tax.group

Notas:
Realizar es te modulo, teniendo en cuenta lo que aporta el modulo l10n_co_tax_extension y otras consideraciones que tengan que ver con los impuestos

10.0 Construir módulo la información de la resolución de facturación (l10n_co_sequence_resolution)

Se requiere desarrollar el siguiente módulo para el manejo de la información de la resolución de facturación:

Nombre:
l10n_co_sequence_resolution

Notas:
La idea general es usar como base la información sobre sequencias y resoluciones del módulo existente l10n_co_tax_extension.

Campos mínimos requeridos descritos a lo largo del anexo para fe:

• number_from (integer) corresponde a la etiqueta sts:From de los xml
• prefix (char) corresponde a la etiqueta sts:Prefix de los xml
• number_to (integer) corresponde a la etiqueta sts:To de los xml
• resolution_number (char) corresponde al valor de la etiqueta sts:InvoiceAuthorization de los xml
• active_resolution (boolean) hay que hacer algunos cambios, el campo como tal no tiene que ver con la facturacion, pero hay que establecer una regla que permita verificar que resoluciones estan activas y cuales no

Modelo:
ir.sequence.date_range

10.0 Construir módulo para responsabilidades fiscales (l10n_co_partner_tax_level_code)

Hola @camilozuluaga y @BrayhanJC
Tal como hablamos ahora la idea es que empecemos a documentar y realizar las mejoras a los módulos que hemos propuesto y faltantes para reemplazar el l10n_co_res_partner para tener este módulo en recomendaciones OCA.

Para reemplazarlo totalmente hace falta:

1. Agregar un tipo a las posiciones fiscales "tipo DIAN" a las posiciones fiscales:

Inicialmente estaba así en el módulo:

Tributate regime

x_pn_retri = fields.Selection(
    [
        (6, "Simplified"),
        (23, "Natural Person"),
        (7, "Common"),
        (11, "Great Taxpayer Autorretenedor"),
        (22, "International"),
        (25, "Common Autorretenedor"),
        (24, "Great Contributor")
    ], "Tax Regime"

)

Pero en el anexo técnico, página 230, numeral 6.2.7 aparecen otras responsabilidades fiscales y la semana pasada la DIAN publicó esta información:

https://www.dian.gov.co/Paginas/Conozca-las-nuevas-responsabilidades-que-la-DIAN-ha-dispuesto-en-el-Rut-con-ocasion-de-la-ley-de-financiamiento.aspx

@hivam requerimos de tu apoyo contable para que nos ayudes a validar si la facturación electrónica con validación previa, debe incluir estos cambios indicados por la DIAN la semana pasada, ya que modifican información del anexo técnico.

Anexo t�cnico de factura electr¢nica de venta.pdf

10.0 e-invoicing-vp modules (Módulos para facturación con vp)

Módulos identificados acorde a la revisión del anexo técnico DIAN:
NP: Nombre Propuesto
R/: Responsable

• NP l10n_co_e_invoicing | R/ _ @JoanMarin y @camilozuluaga _ #10
• NP l10n_co_account_discrepancy_response | R/ _ @camilozuluaga _ #9
• NP l10n_co_account_tax | R/ _ @JoanMarin _ #8 Desagregado en:

1. • account_invoice_tax_fiscalunit
2. • account_tax_group_menu
3. • account_tax_group_type
4. • l10n_co_account_tax_group_type
5. • purchase_order_tax_fiscalunit
6. • sale_order_tax_fiscalunit

• NP l10n_co_account_payment_means | R/ _ @camilozuluaga _ #7
• NP l10n_co_sequence_resolution | R/ @JoanMarin #6
• l10n_co_base_location | R/ @JoanMarin ver
• NP l10n_co_account_position_list_name | R/ _ @camilozuluaga _ #5
• NP l10n_co_partner_tax_level_code | R/ _ @camilozuluaga _ #3
• l10n_co_partner_vat | R/ EXA - ver
• partner_other_names | R/ EXA - ver
• partner_second_lastname | R/ OCA - ver
• partner_firstname | R/ OCA - ver
• l10n_co_partner_isic | R/ EXA - ver
• base | R/ OCA - ver
• base_location | R/ OCA - ver
• base_iso3166 | R/ OCA - ver

10.0 Construir módulo para corrección de notas (l10n_co_account_discrepancy_response)

Se requiere el desarrollo de módulo para la corrección de notas crédito y débito

Nombre Propuesto:
l10n_co_account_discrepancy_response

Campos Requeridos:
NP: type | Modelo: account.invoice.discrepancy.response.code | Sección Anexo: 6.2.5, 6.2.6 | cac:DiscrepancyResponse/cbc:ResponseCode, out_refund y in_refund
NP: code | Modelo: account.invoice.discrepancy.response.code | Sección Anexo: 6.2.5, 6.2.6 | cac:DiscrepancyResponse/cbc:ResponseCode
NP: name | Modelo: account.invoice.discrepancy.response.code | Sección Anexo: 6.2.5, 6.2.6 | cac:DiscrepancyResponse/cbc:ResponseCode
NP: discrepancy_response_code_id | Modelo: account.invoice | Sección Anexo: 6.2.5, 6.2.6 | cac:DiscrepancyResponse/cbc:ResponseCode. Si es in_refund, debe solo permitir escoger opciones de in_refund, si es out_refund, debe solo permitir escoger opciones de out_refund.

10.0 Construir módulo para formas de pago (l10n_co_account_payment_means)

Se requiere desarrollar el siguiente módulo para el manejo de la información de las formas de pago de la factura

Nombre Propuesto:
l10n_co_account_payment_means

Campos mínimos requeridos descritos a lo largo del anexo para fe:

• payment_mean_code_id (many2one-->account.payment.mean.code) | modelo: account.invoice | Ubicación Anexo: 6.3.4
• payment_mean_id (many2one -->account.payment.mean) | modelo: account.invoice | Ubicación Anexo: 6.3.4.1
• code (char) | modelo: account.payment.mean.code | Ubicación Anexo: 6.3.4.2
• name (char) | modelo: account.payment.mean.code | Ubicación Anexo: 6.3.4.2
• code (char) | modelo: account.payment.mean | Ubicación Anexo: 6.3.4.1
• name (char) | modelo: account.payment.mean | Ubicación Anexo: 6.3.4.1

Como recuperar la información fiscal previa a la instalación del modulo

Antes de instalar el modulo se tiene la informacion fiscal del cada contacto asi:

Despues de instalar el modulo se pierde esta información

Por favor su ayuda para recuperar los NIT de los contactos ingresados antes de la instalacion.

10.0 Construir módulo para manejo de responsable de IVA o no (l10n_co_account_position_list_name)

En este caso es necesario realizar:

Nombre Propuesto Módulo: l10n_co_account_position_list_name

Campo(s):

• list_name_id (many2one) | Modelo: account.position.fiscal
• code (char) | Modelo: account.position.fiscal.list.name
• name (char) | Modelo: account.position.fiscal.list.name

Modelo: account.position.fiscal

Información detallada: Punto 6.2.4 del anexo tecnico DIAN

10.0 Construir un módulo para facturación electrónica con validación previa (l10n_co_e_invoicing)

Se requiere el desarrollo de un módulo para la facturación electrónica con validación previa. (Este es el módulo de facturación ensí, por lo que los camposo descritos abajo son el primer borrador que se irá complementando a medida que el desarrollo avance:

Nombre propuesto:
l10n_co_e_invoicing

CAMPOS:

• NP: qr_code | Modelo: dian.document | Sección Anexo: 10.3 | Guía:
• NP: test_set_id | Modelo: res.company | Sección Anexo: 11.9 | Campo nuevo para validacion previa
• NP: profile_execution_id | Modelo: res.company | Sección Anexo: 6.1.1 | Campo nuevo de validación previa. Etiquetas: cbc:ProfileExecutionID y cbc:UUID.@schemeID
• NP: track_id | Modelo: dian.document | Sección Anexo: 6.1.2, 10 | Valor correspondiente con el CUFE, se encuentra en los xml como UUID, y en otros como TrackId
• NP: software_pin | Modelo: res.company | Sección Anexo: 6.1.2, 10 | La base del modulo es l10n_co_e-invoice, haciendo los cambios correspondientes.
• NP: technical_key | Modelo: ir.sequence.date_range | Sección Anexo: 6.1.2, 10.2, 10 | La base del modulo es l10n_co_e-invoice, haciendo los cambios correspondientes.
• NP: dian_document_ids | Modelo: account.invoice | Campo para relacionar solicitudes a la Dian con la factura, podrian existir varias, ya que pueden resultar solucitudes rechazadas, que no se necesitan modificar y sirven de historial, se debe crear una nueva solicitud con las correcciones hasta que sea validada correctamente
• NP: type | Modelo: account.invoice | El campo type, nos indica que el valor "out_refund" es una nota crédito
• NP: is_export_invoice | Modelo: account.invoice | En las facturas de proveedor hay que saber cuando es una factura de exportacion, se debe realizar el proceso correspondiente con ese tipo de facturas
• NP: invoice_note | Modelo: account.invoice | El valor correspondiente a la etiqueta cbc:Note
• NP: invoice_id | Modelo: dian.document | Se deben relacionar solicitudes a la Dian con la factura, podrian haber varias ya que pueden resultar solucitudes rechazadas, que no se necesitan modificar y sirven de historial, se debe crear una nueva solicitud con las correcciones hasta que sea validada correctamente.
• NP: validation_response_name | Modelo: dian.document | En el modulo l10n_co_e-invoice el campo response_document_dian tiene una lista de posibles mensajes recibidos, tanto como para errores como para ejecuciones exitosas, se debe consultar para ver si se reciben los mismo mensajes; podria ser muy útil a la hora de cambios de la Dian que podamos recibir cualquier error, y almacenar, el código y el mensaje, si se elige tener la lista fija de errores, shipping_response_code y shipping_response_name se deben volver solo un campo "shipping_response"
• NP: validation_response_code | Modelo: dian.document | En el modulo l10n_co_e-invoice el campo response_document_dian tiene una lista de posibles mensajes recibidos, tanto como para errores como para ejecuciones exitosas, habria que averiguar si recibiriamos los mismo mensajes. aunque podria ser mas util a la hora de cambios de la dian que podamos recibir cualquier error, y almacenar, el codigo y el mensaje, si se elige tener la lista fija de errores, validation_response_code y validation_response_name se deben volver solo un campo "validation_response"
• NP: shipping_response_code | Modelo: dian.document | En el modulo l10n_co_e-invoice el campo shipping_response tiene una lista de posibles mensajes recibidos, tanto como para errores como para ejecuciones exitosas, se debe consultar para ver si se reciben los mismo mensajes; podria ser muy útil a la hora de cambios de la Dian que podamos recibir cualquier error, y almacenar, el código y el mensaje, si se elige tener la lista fija de errores, shipping_response_code y shipping_response_name se deben volver solo un campo "shipping_response"
• NP: shipping_response_name | Modelo: dian.document | En el modulo l10n_co_e-invoice el campo shipping_response tiene una lista de posibles mensajes recibidos, tanto como para errores como para ejecuciones exitosas, se debe consultar para ver si se reciben los mismo mensajes; podria ser muy útil a la hora de cambios de la Dian que podamos recibir cualquier error, y almacenar, el código y el mensaje, si se elige tener la lista fija de errores, shipping_response_code y shipping_response_name se deben volver solo un campo "shipping_response"
• NP: send_date | Modelo: dian.document | Para la fecha de envio de la solicitud, lo más seguro es que no haya mucha diferencia entre la fecha de envio y la de validación, pero es bueno saber, cual es el tiempo transcurrido entre el envío y la validación, asi sean segundos. Y para contingencias en la transmisión estos tiempos pueden ser distintos.
• NP: validation_date | Modelo: dian.document |Para la fecha de validación en la que se recibe la aprobación por la Dian, lo más seguro es que no haya mucha diferencia entre la fecha de envio y la de validación, pero es bueno saber, cual es el tiempo transcurrido entre el envio y la validacion, asi sean segundos. Y para contingencias en la transmisión estos tiempos pueden ser distintos.
• NP: file_name_sent | Modelo: dian.document | Nombre del archivo que se envio a la dian
• NP: file_name_received | Modelo: dian.document | Nombre del archivo que se recibio de a la dian
• NP: state | Modelo: dian.document | Se debe revisar el módulo y complementar l10n_co_e-invoice
• NP: type | Modelo: dian.document | Tipo de solicitud, ej: invoice, credit note, etc
• NP: certificate_password | Modelo: res.company | Requerido para módulo
• NP: sotfware_id | Modelo: res.company | Se debe tener el campo para el valor de la etiqueta sts:SoftwareID de los xml
• NP: files_path | Modelo: res.company | El módulo l10n_co_e-invoice funciona con la ruta donde se almacenan los diferentes tipos de archivos que se envian y los que se reciben de la DIAN.
• NP: certificate_path | Modelo: res.company | En el módulo l10n_co_e-invoice funciona con la ruta, lo que hace que un paso de configuracion sea almacenar el certificado en una ruta que se establezca en este campo, otra opción es cambiar el campo a certificate_file de tipo binario donde se cargue el archivo desde el campo.
• NP: email_einvoice | Modelo: res.company | Posiblemente haya que establecer un correo desde donde se envien los correos correspondientes con facturación electrónica, que podría ser diferente al configurado para tareas normales
• NP: email_einvoice | Modelo: res.partner | El correo lo tiene almacenado ya el campo email del tercero, es bueno tener en cuenta si tal vez tengamos que tener un correo almacenado solo para envío de correos de facturación electrónica.