OCA modules for Odoo

UN/EDIFACT United Nations rules for Elec­tronic Data Interchange for Administration, Commerce and Transport This module plugs EDIFACT/D96A ORDER in sale_order_import process. https://www.stedi.com/edi/edifact/D96A/messages/ORDERS

This module extends the sale_order_import module to help on importing the packaging information into the sales order line. If for a sale line the product is detected by the code on one of its packaging, then this corresponding packaging will be set on the order line. Also the quantity received during the import will be set as the quantity of packaging and not as the product quantity on the line.

This module implements correct parsing of partners' ID Nums from files when importing sale orders. It extends the default behavior to handle street name and number according to module partner_identification.

This module adds support for the import of electronic RFQ and orders that comply with the Universal Business Language (UBL) standard. The UBL standard became the ISO/IEC 19845 standard in December 2015 (cf the official announce http://www.prweb.com/releases/2016/01/prweb13186919.htm). Two file formats are supported by this module: · UBL XML file, · PDF file with an embedded UBL XML file. You can use the OCA module purchase_order_ubl to generate RFQs or purchase orders in PDF…

This is a glue module between sale_order_import_ubl and sale_order_customer_free_ref. It extracts the CurstomerReference, from the XML received.

This module extends the sale_order_import_ubl module to allow for importing sales order automatically. To do so it adds a HTTP endpoint ubl_api/sales accepting a POST requests containing the XML UBL formatted order. On reception the endpoint will check the validity of the XML received and if ok creates a queue.job that will import the sale.order and set it as confirmed. By default the endpoint uses the api key authentication method. For security reason the api key is not…

This is a glue module between sale_order_import_ubl and sale_stock_line_customer_ref. It extracts customer references for specific lines from the XML received. Since there's no specific element for customer reference in the UBL line, the module will look into cac:OrderLine/cbc:Note and cac:OrderLine/cac:LineItem/cbc:Note for a string prefixed with customer_ref:.

This is a glue module between sale_order_import_ubl and sale_order_requested_delivery. It extracts the RequestedDeliveryPeriod from the UBL order.

This module deos the following: · Add the "Incoterm Place" field to sales order as supplementary information of the selected incoterm. The input value will show in the printed sales order / pro-forma invoice.

This module adds the amount_invoiced and amount_to_invoice fields to the sale order views: · In the form view, those fields are added in the tax totals summary, above the total order amount. · In the list view, the fields are added as user optional fields.

Display the invoice date on Sales Order analysis reports. The invoice date is considered to be the latest invoice date linked to fully invoiced sales.

This module brings the possibility to indicate if a task is available to be invoiced or not, within the task itself. Moreover, even if the task is not finished yet, it can be set as invoiceable. As an option, you can relate this control to a Project Stage ( project.task.type ). For example, if you want to assign 'Invoiceable' to Done stage always.

This module allows to use custom criteria for grouping sales orders to be invoiced. Default criteria for grouping (invoicing partner, company and used currency) will be always applied, as if not respected, there will be business inconsistencies, but you can add more fields to split the invoicing according them.

This modules allows to create invoices from sale orders based on the products in pickings related to the order.

This module allows to invoice a percentage of the sales order, modifying invoiced quantities according such percentage. Example: You have a service line to invoice 10 hours. You choose to invoice a 50% of the quantity, so the generated invoice line has 5 hours.

This module allows to enqueue in several jobs the sales orders invoicing process to be executed in paralell on background, which is normally done serially and on foreground. Jobs are split following the same criteria as standard Odoo: grouping by order invoicing address and order currency.

This module allows you to cancel the remaining quantity on sale order by adding a dedicated action to sale lines. It also add two new fields to track canceled and remaining to deliver quantities. This module differs from the original odoo behavior in the following way: · In odoo, if the update of the quantity ordered is allowed on the sale order at the confirmed state, odoo will recompute the required stock operations according to the new quantity. This change is possible…

This module cancels only the stock moves for the remaining qty to deliver. Also it will track the canceled qty if a order line's stock move is canceled but only if there are not other started operations for this sale order line. When the base addon is configured to also decrease the original ordered qty it ensures that there are now new moves created. Because by default, odoo will recompute the required stock operations if the ordered qty is changed. By canceling the…

This module defines a technical field to store the related sale order line on stock move level in order to get all chained moves on sale order line side. In case the stock move contains multiple lines of the same product, Odoo's default behaviour is to merge those lines into the same one. With this module, there is the option of preserving one move for each sale order line, which enables correct tracing of each move back to its source. Each stock rule can define how the…

This module provides the following features: · Adds a Customer Order Number to sale order lines and propagates the value to invoice lines. · Allows the Customer Order Number to be displayed in both sale and invoice reports. This module is useful in cases where a single sales order represents multiple customer orders.