Master Production Schedule
Master Production Schedule
==========================

Sometimes you need to create the purchase orders for the components of
manufacturing orders that will only be created later. Or for production orders
where you will only have the sales orders later. The solution is to predict
your sale forecasts and based on that you will already create some production
orders or purchase orders.

You need to choose the products you want to add to the report. You can choose
the period for the report: day, week, month, ... It is also possible to define
safety stock, min/max to supply and to manually override the amount you will
procure.

<p>Account Consolidation Demo Data using a Belgium and a US company<br>
Account Consolidation Demo Data<br>
==================================</p>

Manage work entries

Manage work entries

Manage work entries

Assets management
=================
Manage assets owned by a company or a person.
Keeps track of depreciations, and creates corresponding journal entries.

360 Feedback
This module adds an integration with Survey to ask feedbacks to any employee, based on a survey to fill.

Record time
This module implements a timer.
==========================================

It adds a timer to a view for time recording purpose

Track employee time on tasks
This module implements a timesheet system.
==========================================

Each employee can encode and track their time spent on the different projects.

Lots of reporting on time and employee tracking are provided.

It is completely integrated with the cost accounting module. It allows you to set
up a management by affair.

Convert Tickets from/to Leads
Convert business inquiries that have ended up in the Helpdesk pipeline by mistake,
or generate a ticket from a business inquiry

Add extra fields on addresses
Extended Addresses Management
=============================

This module holds all extra fields one may need to manage accurately addresses.

For example, in legal reports, some countries need to split the street into several fields,
with the street name, the house number, and room number.

Add a many2one field city on addresses
City Management in Addresses
============================

This module allows to enforce users to choose the city of a partner inside a given list instead of a free text field.

Landed Costs
Landed Costs Management
=======================
This module allows you to easily add extra costs on pickings and decide the split of these costs among their stock moves in order to take them into account in your stock valuation.

Inventory, Logistic, Valuation, Accounting
WMS Accounting module
======================
This module makes the link between the 'stock' and 'account' modules and allows you to create accounting entries to value your stock movements

Key Features
------------
* Stock Valuation (periodical or automatic)
* Invoice from Picking

Dashboard / Reports for Warehouse Management includes:
------------------------------------------------------
* Stock Inventory Value at given date (support dates in the past)

LATAM Identification Types
Add a new model named "Identification Type" that extend the vat field functionality in the partner and let the user to identify (an eventually invoice) to contacts not only with their fiscal tax ID (VAT) but with other types of identifications like national document, passport, foreign ID, etc. With this module installed you will see now in the partner form view two fields:

* Identification Type
* Identification Number

This behavior is a common requirement for some latam countries like Argentina and Chile. If your localization has this requirements then you need to depend on this module and define in your localization module the identifications types that are used in your country. Generally these types of identifications are defined by the government authorities that regulate the fiscal operations. For example:

* AFIP in Argentina defines DNI, CUIT (vat for legal entities), CUIL (vat for natural person), and another 80 valid identification types.

Each identification holds this information:

* name: short name of the identification
* description: could be the same short name or a long name
* country_id: the country where this identification belongs
* is_vat: identify this record as the corresponding VAT for the specific country.
* sequence: let us to sort the identification types depending on the ones that are most used.
* active: we can activate/inactivate identifications to make it easier to our customers

In order to make this module compatible for multi-company environments where we have companies that does not need/support this requirement, we have added generic identification types and generic rules to manage the contact information and make it transparent for the user when only use the VAT as we formerly know.

Generic Identifications:

* VAT: The Fiscal Tax Identification or VAT number, by default will be selected as identification type so the user will only need to add the related vat number.
* Passport
* Foreign ID (Foreign National Document)

Rules when creating a new partner: We will only see the identification types that are meaningful, taking into account these rules:

* If the partner have not country address set: Will show the generic identification types plus the ones defined in the partner's related company country (If the partner has not specific company then will show the identification types related to the current user company)

* If the partner has country address : will show the generic identification types plus the ones defined for the country of the partner.

When creating a new company, will set to the related partner always the related country is_vat identification type.

All the defined identification types can be reviewed and activate/deactivate in "Contacts / Configuration / Identification Type" menu.

This module is compatible with base_vat module in order to be able to validate VAT numbers for each country that have or not have the possibility to manage multiple identification types.

Be able to see Identification Type and AFIP Responsibility in ecommerce checkout form.

Functional
----------

Be able to create journals in CBMS ODOO to create electronic customer invoices and report then to AFIP (via webservices).
The options available are:

* Electronic Invoice - Web Service
* Export Voucher - Web Service
* Electronic Fiscal Bond - Web Service

In the electronic journals if you validate an invoice this one will be validated in both CBMS ODOO and AFIP. This validation is
made at the instant and we recieve and "approved/approved with observation/rejected" state from AFIP. If the invoice has
been rejected by AFIP will not be post in the system and a pop up message will be shown with both the error detail (reject reasons)
we recieve and a HINT about what the problem could be.

For auditing and troubleshooting purposes we also add a menu "Consulit Invoice in AFIP" that let us to consult invoices previously
sent to AFIP and last number used as support for any possible issues on the sequences synchronization between CBMS ODOO and AFIP.

NOTE: From the Journal's form view we are able to force a sync between the CBMS ODOO sequences to each of the document types in
with the last numbers registered in AFIP.

From vendor bills, we have added a functionality that can be configured in the accounting settings to be able to verify
vendor bills in AFIP to check if the vendor bills are real (more information please review the setting description).

Configuration:

1. Go to the Accounting Settings > Argentinean Localization section

1.1. Configure the AFIP Web Services mode:

* Testing environment in order to use demo certificates that will be use to test the instance and to make NOT
real invoices to AFIP. is just for testing. For demo instaces is already pre-defined you will not need to configure
it (commonly named in AFIP as Homologation environment).
* Production environment in order to generate real certificates and legal invoices to AFIP,

1.2. Configure your AFIP Certificate: If you are in a demo instance this one will be have been set by default. If you
are in production instance just need to go to upload your AFIP Certificate

1.3. Optionally you can define if you like to be eable to verify vendor bills in AFIP.

2. Create Sales journals that will represent each one of your AFIP POS (Available in AFIP Portal) you want to use in CBMS ODOO.

2.1. Use Documents field is set by default please dont change
2.2. Set AFIP POS System for one of the electronic ones.

* Electronic Invoice - Web Service'
* Electronic Fiscal Bond - Web Service'
* Export Voucher - Web Service'

2.3. Set the AFIP POS Number and AFIP POS Address taking into account what you have configured in your AFIP Portal.

NOTE: You can use the "Check Available AFIP POS" button in Journal's form to corroborate the to use to create the journals.

For more information about Argentinean Electronic invoicing please go to http://www.afip.gob.ar/fe/ayuda.asp

Technical
---------

The web services that are implemented are the ones that are the most common:

* wsfev1 - "Factura Electrónica" (Electronic Invoice)
* wsbfev1 - "Bono Fiscal Electrónico" (Electronic Fiscal Bond)
* wsfexv1 - "Factura de Exportación Electrónica" (Electronic Exportation Invoice - same as Export Voucher)
* wscdc - "Constatación de Comprobantes" (Invoices Verification)

For Development information go to http://www.afip.gob.ar/fe/documentos/WSBFEv1 - Manual para el desarrollador.pdf

The delivery guide (guia de despacho) is needed as a proof
that you are sending goods between A and B.

It is configurable on the partner if prices are needed on the
delivery guide and if they need to come from the sale order
or the product itself.

It is only when a delivery order is validated that you can create the delivery
guide. Then it will follow the same flow as for the invoices, sending it to
the SII.

Purpose of the Module:
======================

As part of the SII requirements (Legal requirement in Chile),
beginning on March 2021 boletas transactions must be sent to the SII under the
electronic workflow using a different web service than the one used for electronic Invoices.
Previously, there was no need to send the boletas to the SII, just a daily report.

Additionally of sending the Boleta individually (with the EDI workflow),
at the end of the day, a daily summary with all the Boletas transactions
should be sent to the SII - electronically (also a legal requirement).
This is called "Libro de ventas diarias" (former "reporte de consumo de folios" or RCOF).


Differences between Electronic boletas vs Electronic Invoicing Workflows:
=========================================================================

These workflows have some important differences that lead us to do this PR with the specific changes.
Here are the differences:

* The mechanism for sending the electronic boletas information needs dedicated servers, different from those used at the reception electronic invoice ("Palena" for the production environment - palena.sii.cl and "Maullin" for the test environment - maullin.sii.cl).
* The authentication services, querying the status of a delivery and the status of a document will be different.
* The authentication token obtained
* The XML schema for sending the electronic boletas was updated with the incorporation of new tags
* The validation diagnosis of electronic boletas will be delivered through a "REST" web service that has as an input the track-id of the delivery. Electronic Invoices will continue to receive their diagnoses via e-mail.
* The track-id ("identificador de envío") associated with the electronic boletas will be 15 digits long. (Electronics Invoice is 10)

Highlights from this SII Guide:
https://www.sii.cl/factura_electronica/factura_mercado/Instructivo_Emision_Boleta_Elect.pdf