[IMP] *: standardize spelling of “cancelled” across documentation
In https://github.com/odoo/odoo/pull/129722, we settled on using the spelling “cancelled”, and removed all occurrences of “canceled” from the codebase. This commit does the same for the documentation. Task-3951276 closes odoo/documentation#9494 Signed-off-by: Vincent Larcin (vila) <vila@odoo.com>
This commit is contained in:
Vincent Larcin
parent
88880b8915
commit
59afd5062d
@ -758,9 +758,9 @@ Cancel an own check
|
||||
*******************
|
||||
|
||||
To cancel an own check created in Odoo, navigate to :menuselection:`Accounting --> Vendors --> Own
|
||||
Checks` and select the check to be canceled, then click on the :guilabel:`Void Check` button. This
|
||||
Checks` and select the check to be cancelled, then click on the :guilabel:`Void Check` button. This
|
||||
will break the reconciliation with the vendor bills and the bank statements and leave the check in a
|
||||
**canceled** state.
|
||||
**cancelled** state.
|
||||
|
||||
.. image:: argentina/empty-check-button.png
|
||||
:align: center
|
||||
|
||||
@ -549,7 +549,7 @@ A range of sequences that are assigned to sales journals can be invalidated with
|
||||
they are not currently used, **and** will not be used in the future. To do so, navigate to the
|
||||
journal, and click the :menuselection:`⚙️ (gear) icon --> Invalidate Number Range (BR)`. On the
|
||||
:guilabel:`Invalidate Number Range (BR)` wizard, add the :guilabel:`Initial Number` and
|
||||
:guilabel:`End Number` of the range that should be canceled, and enter an invalidation
|
||||
:guilabel:`End Number` of the range that should be cancelled, and enter an invalidation
|
||||
:guilabel:`Reason`.
|
||||
|
||||
.. image:: brazil/range-number-invalidation.png
|
||||
@ -563,7 +563,7 @@ journal, and click the :menuselection:`⚙️ (gear) icon --> Invalidate Number
|
||||
(NF-e).
|
||||
|
||||
.. note::
|
||||
The log of the canceled numbers along with the XML file are recorded in the chatter of the
|
||||
The log of the cancelled numbers along with the XML file are recorded in the chatter of the
|
||||
journal.
|
||||
|
||||
Vendor bills
|
||||
|
||||
@ -617,7 +617,7 @@ Note` and select :guilabel:`Full Refund`, in this case the :abbr:`SII (Servicio
|
||||
Internos)` reference code is automatically set to :guilabel:`Anula Documento de referencia`.
|
||||
|
||||
.. image:: chile/credit-note-cancel-ref-doc.png
|
||||
:alt: Credit note canceling the referenced document.
|
||||
:alt: Credit note cancelling the referenced document.
|
||||
:align: center
|
||||
|
||||
Correct referenced document
|
||||
@ -742,7 +742,7 @@ vendor.
|
||||
:align: center
|
||||
|
||||
If you claim a vendor bill, the status changes from :guilabel:`Draft` to :guilabel:`Cancel`
|
||||
automatically. Considering this as best practice, all the claimed documents should be canceled as
|
||||
automatically. Considering this as best practice, all the claimed documents should be cancelled as
|
||||
they won't be valid for your accounting records.
|
||||
|
||||
Electronic purchase invoice
|
||||
@ -1196,7 +1196,7 @@ on the client's original order.
|
||||
:alt: Selection of order for the refund process.
|
||||
|
||||
When the return payment is validated, Odoo generates the necessary credit note, referencing the
|
||||
original receipt or invoice, partially or fully canceling the document.
|
||||
original receipt or invoice, partially or fully cancelling the document.
|
||||
|
||||
.. seealso::
|
||||
`Smart tutorial - Electronic invoicing for point of sale
|
||||
|
||||
@ -102,18 +102,17 @@ The following codes are available when generating an e-Faktur.
|
||||
Correct an invoice that has been posted and downloaded: Replace Invoice feature
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Cancel the original wrong invoice in Odoo. For instance, we will change the Kode Transakski from 01
|
||||
to 03 for the INV/2020/0001.
|
||||
#. Create a new invoice and set the canceled invoice in the *Replace Invoice* field. In this field,
|
||||
#. Cancel the original wrong invoice in Odoo. For instance, we will change the Kode Transakski from
|
||||
01 to 03 for the INV/2020/0001.
|
||||
#. Create a new invoice and set the cancelled invoice in the *Replace Invoice* field. In this field,
|
||||
we can only select invoices in *Cancel* state from the same customer.
|
||||
#. As you validate, Odoo will automatically use the same e-Faktur serial number as the canceled and
|
||||
#. As you validate, Odoo will automatically use the same e-Faktur serial number as the cancelled and
|
||||
replaced invoice replacing the third digit of the original serial number with *1* (as requested
|
||||
to upload a replacement invoice in the e-Faktur app).
|
||||
|
||||
.. image:: indonesia/indonesia-replace-invoice.png
|
||||
:align: center
|
||||
|
||||
|
||||
.. _localization_indonesia/reset_e-faktur:
|
||||
|
||||
Correct an invoice that has been posted but not downloaded yet: Reset e-Faktur
|
||||
|
||||
@ -379,7 +379,7 @@ TD04 - Credit notes
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is the standard scenario for all **credit notes** issued to **domestic** clients, when we need to
|
||||
formally acknowledge that the seller is reducing or canceling a previously issued invoice, for
|
||||
formally acknowledge that the seller is reducing or cancelling a previously issued invoice, for
|
||||
example, in case of overbilling, incorrect items, or overpayment. Just like invoices, they must be
|
||||
sent to the :abbr:`SdI (Sistema di Interscambio)`, their :guilabel:`Document Type` `TD04`
|
||||
|
||||
|
||||
@ -467,11 +467,11 @@ there are two requirements for this:
|
||||
There are four different cancellation reasons. In Odoo, you can cancel invoices with the reasons *01
|
||||
Invoices sent with errors with a relation*, and *02 Invoices sent with errors without a relation*.
|
||||
|
||||
The following sections break down the process of canceling invoices for each cancellation reason in
|
||||
The following sections break down the process of cancelling invoices for each cancellation reason in
|
||||
Odoo.
|
||||
|
||||
.. important::
|
||||
Odoo has certain limitations to canceling invoices in the |SAT|: The reasons 03 and 04
|
||||
Odoo has certain limitations to cancelling invoices in the |SAT|: The reasons 03 and 04
|
||||
(*Operation did not take place* and *Nominative transactions related to a global invoice*,
|
||||
respectively) are not currently supported by Odoo. For this, you need to cancel the invoice
|
||||
directly in the |SAT|, and press :guilabel:`Retry` in the :guilabel:`SAT Status field`.
|
||||
@ -490,12 +490,12 @@ of the old invoice after the value. Finally, sign the new document.
|
||||
Next, navigate back to the old invoice, and notice the :guilabel:`Substituted By` field is now
|
||||
available. Click the :guilabel:`Request EDI Cancellation` button on the old invoice, and then click
|
||||
:guilabel:`Process Now` in the blue section that appears. The invoice status changes to
|
||||
:guilabel:`Canceled`, and a confirmation is logged in the chatter.
|
||||
:guilabel:`Cancelled`, and a confirmation is logged in the chatter.
|
||||
|
||||
Now, the invoice should be canceled in the |SAT| as well. You can confirm this was done correctly,
|
||||
Now, the invoice should be cancelled in the |SAT| as well. You can confirm this was done correctly,
|
||||
by pressing :guilabel:`Retry` in the |SAT| status field.
|
||||
|
||||
If the document was canceled more than 24 hours after its creation, you may need to ask the client
|
||||
If the document was cancelled more than 24 hours after its creation, you may need to ask the client
|
||||
to accept the cancellation in their “Buzón Tributario” directly from the `SAT website
|
||||
<https://www.sat.gob.mx/home>`_.
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ If you selected :guilabel:`Pending` as **payment outcome**, you can change the s
|
||||
transaction straight from its form view. To access a transaction's form view, activate the
|
||||
:ref:`developer mode <developer-mode>`, and go to :menuselection:`Accounting / Website -->
|
||||
Configuration --> Payment Transactions`. Then, change the status of a transaction by clicking on the
|
||||
state bar (:guilabel:`Draft, Pending, Authorized, Confirmed, Canceled, Error`).
|
||||
state bar (:guilabel:`Draft, Pending, Authorized, Confirmed, Cancelled, Error`).
|
||||
|
||||
.. image:: demo/demo-view-form.png
|
||||
:align: center
|
||||
|
||||
@ -204,7 +204,7 @@ Each appraisal card displays the following information:
|
||||
- :guilabel:`Manager`: the employee's manager, indicated by the profile icon in the bottom-right
|
||||
corner of an appraisal card.
|
||||
- :guilabel:`Status banner`: the status of the appraisal. A banner appears if an appraisal is
|
||||
marked as either :guilabel:`Canceled` or :guilabel:`Done`. If no banner is present, that means the
|
||||
marked as either :guilabel:`Cancelled` or :guilabel:`Done`. If no banner is present, that means the
|
||||
appraisal has not happened, or has not been scheduled yet.
|
||||
|
||||
To view the details of any appraisal, click on the card to open the appraisal form.
|
||||
@ -225,7 +225,7 @@ dashboard to load a blank appraisal form. Then, enter the following information
|
||||
auto-populates after the employee is selected, if they have a manager set on their employee
|
||||
profile.
|
||||
- :guilabel:`Appraisal Date`: the current date is automatically entered in this field. This field is
|
||||
automatically updated once the appraisal is completed or canceled, with the corresponding date of
|
||||
automatically updated once the appraisal is completed or cancelled, with the corresponding date of
|
||||
completion or cancellation.
|
||||
- :guilabel:`Department`: select the employee's department from the drop-down menu. This field
|
||||
auto-populates after the employee is selected, if they have a department set on their employee
|
||||
|
||||
@ -278,7 +278,7 @@ Each service listed displays the following information:
|
||||
add clarification.
|
||||
- :guilabel:`Cost`: the total cost of the service, or repair.
|
||||
- :guilabel:`Stage`: the status of the service, or repair. Options are :guilabel:`New`,
|
||||
:guilabel:`Running`, :guilabel:`Done`, or :guilabel:`Canceled`.
|
||||
:guilabel:`Running`, :guilabel:`Done`, or :guilabel:`Cancelled`.
|
||||
|
||||
At the bottom of the :guilabel:`Cost` column, the total cost of all services and repairs are listed.
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ in:
|
||||
- :guilabel:`Duration`: the amount of time the guest has been checked in for.
|
||||
- :guilabel:`Station`: the location of where the guest checked in.
|
||||
- :guilabel:`Status`: the status of the guest. The options are :guilabel:`Checked-In`,
|
||||
:guilabel:`Planned`, :guilabel:`Checked-Out`, or :guilabel:`Canceled`.
|
||||
:guilabel:`Planned`, :guilabel:`Checked-Out`, or :guilabel:`Cancelled`.
|
||||
- :guilabel:`Email`\*: the guest's email address.
|
||||
|
||||
\* These fields are not visible in the default :guilabel:`Visitor` list. These must be enabled
|
||||
|
||||
@ -6,7 +6,7 @@ In Odoo's *Lunch* application, it is required to have someone manage the orders,
|
||||
products. In addition, someone must be responsible for the orders, and notifying employees when
|
||||
their orders have arrived. This can be the same person.
|
||||
|
||||
Orders can be :ref:`canceled <lunch/cancel>`, :ref:`sent to the vendor <lunch/send-orders>`,
|
||||
Orders can be :ref:`cancelled <lunch/cancel>`, :ref:`sent to the vendor <lunch/send-orders>`,
|
||||
:ref:`confirmed <lunch/confirm-orders>` upon arrival, and :ref:`employees can be notified
|
||||
<lunch/notify>`, either from the :ref:`Today's Orders <lunch/todays-orders>` dashboard, or the
|
||||
:ref:`Control Vendors <lunch/control_vendors>` dashboard.
|
||||
@ -58,14 +58,14 @@ Cancel orders
|
||||
|
||||
All users can cancel an order, not just managers of the *Lunch* app.
|
||||
|
||||
To cancel an order from a vendor, individual products **must** be canceled one at a time.
|
||||
To cancel an order from a vendor, individual products **must** be cancelled one at a time.
|
||||
|
||||
On the :guilabel:`Today's Orders` dashboard, a :guilabel:`✖️ Cancel` button is shown at the
|
||||
far-right of each product line that can be canceled. Click the :guilabel:`✖️ Cancel` button to
|
||||
far-right of each product line that can be cancelled. Click the :guilabel:`✖️ Cancel` button to
|
||||
cancel the order for that individual product.
|
||||
|
||||
.. note::
|
||||
Only products with a red :guilabel:`Status` tag of :guilabel:`Ordered` can be canceled.
|
||||
Only products with a red :guilabel:`Status` tag of :guilabel:`Ordered` can be cancelled.
|
||||
|
||||
.. image:: management/cancel.png
|
||||
:align: center
|
||||
@ -171,7 +171,7 @@ The following information appears in the list:
|
||||
- :guilabel:`Company`: the company under which the order was placed. This only appears in a
|
||||
multi-company database.
|
||||
|
||||
Orders can be :ref:`canceled <lunch/cancel>`, :ref:`sent to the vendor <lunch/send-orders>`,
|
||||
Orders can be :ref:`cancelled <lunch/cancel>`, :ref:`sent to the vendor <lunch/send-orders>`,
|
||||
:ref:`confirmed <lunch/confirm-orders>` upon arrival, and :ref:`employees can be notified
|
||||
<lunch/notify>` using the same method as on the :ref:`Today's Orders <lunch/todays-orders>`
|
||||
dashboard.
|
||||
|
||||
@ -193,7 +193,7 @@ the list, beneath all the lines, the overall total amount paid for all the order
|
||||
|
||||
At the end of each product line with a status of :guilabel:`Ordered` or :guilabel:`Sent`, an
|
||||
:guilabel:`X Cancel` button appears. Click :guilabel:`X Cancel` to cancel that product order. Once a
|
||||
product order has been canceled, the money paid for that product is refunded, and appears in the
|
||||
product order has been cancelled, the money paid for that product is refunded, and appears in the
|
||||
user's account.
|
||||
|
||||
At the end of each product line with a status of :guilabel:`Received`, a :guilabel:`Re-order` button
|
||||
@ -219,7 +219,7 @@ Entries with a negative figure listed in the :guilabel:`Amount` column represent
|
||||
in the *Lunch* app. These appear in a `$-XX.XX` format.
|
||||
|
||||
Entries with a positive balance either represent funds added to the user's lunch account, or
|
||||
canceled orders that were eventually refunded to the user. These appear in a `$XX.XX` format.
|
||||
cancelled orders that were eventually refunded to the user. These appear in a `$XX.XX` format.
|
||||
|
||||
.. image:: orders/my-account.png
|
||||
:align: center
|
||||
|
||||
@ -214,7 +214,7 @@ bank account, an error appears in a pop-up window, stating, *The employee bank a
|
||||
untrusted.* If this error appears, update the employee's bank account information on their
|
||||
:ref:`Employee Form <employees/private-info>`.
|
||||
|
||||
If a payment needs to be canceled or refunded, click the corresponding :guilabel:`Cancel` or
|
||||
If a payment needs to be cancelled or refunded, click the corresponding :guilabel:`Cancel` or
|
||||
:guilabel:`Refund` button, located at the top-left of the screen.
|
||||
|
||||
.. tip::
|
||||
|
||||
@ -276,7 +276,7 @@ eliminates the need to redo work entries, cancel paychecks, and reissue paycheck
|
||||
The most common scenario when this situation occurs, is when payslips are processed a day or two
|
||||
before the pay period ends, and an employee is unexpectedly sick on one of the last days of the pay
|
||||
period. The employee puts in a time off request for a day that was already processed on a payslip as
|
||||
a regular work day. Instead of canceling the payslip, modifying the work entries, and reissuing the
|
||||
a regular work day. Instead of cancelling the payslip, modifying the work entries, and reissuing the
|
||||
paycheck, Odoo allows for those time off requests to be applied to the following pay period,
|
||||
instead.
|
||||
|
||||
|
||||
@ -168,11 +168,11 @@ After configuring and saving the form, follow these steps to load the shipping p
|
||||
.. tip::
|
||||
Sendcloud does not provide test keys when a company tests the sending of a package in Odoo. This
|
||||
means if a package is created, the configured Sendcloud account will be charged, unless the
|
||||
associated package is canceled within 24 hours of creation.
|
||||
associated package is cancelled within 24 hours of creation.
|
||||
|
||||
Odoo has a built-in layer of protection against unwanted charges when using test environments.
|
||||
Within a test environment, if a shipping method is used to create labels, then those labels are
|
||||
immediately canceled after the creation — this occurs automatically. The test and production
|
||||
immediately cancelled after the creation — this occurs automatically. The test and production
|
||||
environment settings can be toggled back and forth from their respective smart buttons.
|
||||
|
||||
.. _inventory/shipping_receiving/sendcloud-shipping-info:
|
||||
|
||||
@ -172,7 +172,7 @@ The chosen delivery service will populate in the :guilabel:`Service Name` field.
|
||||
|
||||
Odoo has a built-in layer of protection against unwanted charges when using test environments.
|
||||
Within a test environment, if a shipping method is used to create labels, then those labels are
|
||||
immediately canceled after creation — this occurs automatically. Please note that depending on
|
||||
immediately cancelled after creation — this occurs automatically. Please note that depending on
|
||||
the shipping provider being used, the account might be charged for printing label, unless the
|
||||
order is cancelled manually on the couriers’s portal.
|
||||
|
||||
|
||||
@ -123,7 +123,7 @@ icon to add the following products to the app:
|
||||
services.
|
||||
- :guilabel:`Paperless Documents`: Enables the upload of document images to link to shipments.
|
||||
- :guilabel:`Shipping`: Enables UPS shipping services, such as preparing packages for shipment,
|
||||
managing returns, and canceling scheduled shipments.
|
||||
managing returns, and cancelling scheduled shipments.
|
||||
- :guilabel:`Rating`: Compare delivery services and shipping rates.
|
||||
|
||||
Finally, click :guilabel:`Save` and accept UPS's terms and conditions.
|
||||
|
||||
@ -26,7 +26,7 @@ pop-up window. In the :guilabel:`Name:` field, assign a title to the new request
|
||||
:alt: New event creation pop-up window.
|
||||
|
||||
Clicking :guilabel:`Create` on the pop-up window saves the new request with no additional details.
|
||||
If the request's creation should be canceled, click :guilabel:`Cancel`.
|
||||
If the request's creation should be cancelled, click :guilabel:`Cancel`.
|
||||
|
||||
To add more details and schedule the request for a specific date and time, click :guilabel:`Edit`.
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ the production |BOM| by enforcing at least one review of suggested changes befor
|
||||
a production |BOM|.
|
||||
|
||||
For best practice, there should be at least one *verification* stage, which is a stage with a
|
||||
required approver, and one *closing* stage, which stores |ECOs| that have been either canceled or
|
||||
required approver, and one *closing* stage, which stores |ECOs| that have been either cancelled or
|
||||
approved for use as the next production |BOM|.
|
||||
|
||||
Create stage
|
||||
|
||||
@ -32,15 +32,15 @@ pre-configured filters are:
|
||||
|
||||
#. All *Requests for Quotation*
|
||||
|
||||
#. All *Purchase Orders*, except canceled ones
|
||||
#. All *Purchase Orders*, except cancelled ones
|
||||
|
||||
#. *Confirmation Date Last Year* includes all orders that were confirmed the previous year,
|
||||
canceled purchase orders included
|
||||
cancelled purchase orders included
|
||||
|
||||
#. *Order Date* includes all orders - request for quotations and purchases orders (canceled ones
|
||||
#. *Order Date* includes all orders - request for quotations and purchases orders (cancelled ones
|
||||
included) - depending on their date of creation
|
||||
|
||||
#. *Confirmation Date* includes all confirmed orders, canceled ones included, depending on their
|
||||
#. *Confirmation Date* includes all confirmed orders, cancelled ones included, depending on their
|
||||
date of confirmation
|
||||
|
||||
.. note::
|
||||
|
||||
@ -95,9 +95,9 @@ Selection Type` can be changed, as well. There are two options that can be activ
|
||||
selection:
|
||||
|
||||
- :guilabel:`Select only one RfQ (exclusive)`: when a purchase order is confirmed, the remaining
|
||||
purchase orders are canceled.
|
||||
purchase orders are cancelled.
|
||||
- :guilabel:`Select multiple RfQ (non-exclusive)`: when a purchase order is confirmed, remaining
|
||||
purchase orders are **not** canceled. Instead, multiple purchase orders are allowed.
|
||||
purchase orders are **not** cancelled. Instead, multiple purchase orders are allowed.
|
||||
|
||||
Under the :guilabel:`Data For New Quotations` section, the :guilabel:`Lines` and
|
||||
:guilabel:`Quantities` fields can be edited. Doing so sets how new quotations should be populated
|
||||
|
||||
@ -251,17 +251,17 @@ Cancel (or keep) alternatives
|
||||
=============================
|
||||
|
||||
Once the desired products have been chosen from the :guilabel:`Compare Order Lines` page, the
|
||||
remaining |RfQs|, from which no products were chosen, can be canceled.
|
||||
remaining |RfQs|, from which no products were chosen, can be cancelled.
|
||||
|
||||
The cost in the :guilabel:`Total` column for each product that wasn't chosen is automatically set to
|
||||
`0`, indicated at the far-right of each corresponding row.
|
||||
|
||||
Although they haven't been canceled yet, this indicates that each of those orders can be canceled
|
||||
Although they haven't been cancelled yet, this indicates that each of those orders can be cancelled
|
||||
without having an effect on the other live orders, once those orders have been confirmed.
|
||||
|
||||
.. image:: calls_for_tenders/calls-for-tenders-zero-total.png
|
||||
:align: center
|
||||
:alt: Canceled quotations in the Purchase app overview.
|
||||
:alt: Cancelled quotations in the Purchase app overview.
|
||||
|
||||
To confirm an |RfQ| for which products were selected, click into one, and click :guilabel:`Confirm
|
||||
Order`.
|
||||
@ -305,7 +305,7 @@ Alternatives` to cancel all other alternative |RfQs| linked with this order.
|
||||
Finally, click :guilabel:`Requests for Quotation` (in the breadcrumbs, at the top of the page) to
|
||||
navigate back to an overview of all |RfQs|.
|
||||
|
||||
The canceled orders can be seen, greyed out and listed with a :guilabel:`Cancelled` status, under
|
||||
The cancelled orders can be seen, greyed out and listed with a :guilabel:`Cancelled` status, under
|
||||
the :guilabel:`Status` column at the far-right of their respective rows.
|
||||
|
||||
Now that all product quantities have been ordered, the purchase process can be completed, and the
|
||||
|
||||
@ -176,7 +176,7 @@ A new :guilabel:`Forecasted` column appears on the product lines under the :guil
|
||||
displaying the availability of all components needed for the repair.
|
||||
|
||||
Once ready, click :guilabel:`Start Repair`. This moves the |RO| to the :guilabel:`Under Repair`
|
||||
stage (in the upper-right corner). If the |RO| should be canceled, click :guilabel:`Cancel Repair`.
|
||||
stage (in the upper-right corner). If the |RO| should be cancelled, click :guilabel:`Cancel Repair`.
|
||||
|
||||
Once all products have been successfully repaired, the |RO| is completed. To register this in the
|
||||
database, click :guilabel:`End Repair`.
|
||||
|
||||
@ -117,7 +117,7 @@ Upon selecting an attendee, Odoo reveals that specific attendee's detail form.
|
||||
|
||||
From here, event badges can be sent manually, by selecting :guilabel:`Send By Email`. The
|
||||
:guilabel:`Attendee` can also be marked as :guilabel:`Attended`, or the registration can be
|
||||
canceled altogether via the :guilabel:`Cancel Registration` button.
|
||||
cancelled altogether via the :guilabel:`Cancel Registration` button.
|
||||
|
||||
.. image:: track_manage_talks/events-send-email-button.png
|
||||
:align: center
|
||||
|
||||
@ -34,8 +34,8 @@ The following table lists capabilities provided by Odoo when using the Amazon Co
|
||||
+---------------------------+----------------------------+-------------------------------------+
|
||||
| | Fulfilled By Amazon (FBA) | Fulfilled By Merchant (FBM) |
|
||||
+===========================+============================+=====================================+
|
||||
| **Orders** | Synchronize shipped and | Synchronize unshipped and canceled |
|
||||
| | canceled orders. | orders. |
|
||||
| **Orders** | Synchronize shipped and | Synchronize unshipped and cancelled |
|
||||
| | cancelled orders. | orders. |
|
||||
+---------------------------+----------------------------+-------------------------------------+
|
||||
| **Shipping** | Shipping cost is computed | Shipping cost is computed by Amazon |
|
||||
| | by Amazon, and included in | and included in the synchronized |
|
||||
|
||||
@ -10,15 +10,15 @@ Orders are automatically fetched from Amazon, and synchronized in Odoo, at regul
|
||||
The synchronization is based on the Amazon status: only orders whose status has changed since the
|
||||
last synchronization are fetched from Amazon. This includes changes on either end (Amazon or Odoo).
|
||||
|
||||
For *FBA* (Fulfilled by Amazon), only *Shipped* and *Canceled* orders are fetched.
|
||||
For *FBA* (Fulfilled by Amazon), only *Shipped* and *Cancelled* orders are fetched.
|
||||
|
||||
For *FBM* (Fulfilled by Merchant), the same is done for *Unshipped* and *Canceled* orders. For each
|
||||
For *FBM* (Fulfilled by Merchant), the same is done for *Unshipped* and *Cancelled* orders. For each
|
||||
synchronized order, a sales order and customer are created in Odoo (if the customer is not already
|
||||
registered in the database).
|
||||
|
||||
.. note::
|
||||
When an order is canceled in Amazon, and was already synchronized in Odoo, the corresponding
|
||||
sales order is automatically canceled in Odoo.
|
||||
When an order is cancelled in Amazon, and was already synchronized in Odoo, the corresponding
|
||||
sales order is automatically cancelled in Odoo.
|
||||
|
||||
Force synchronization
|
||||
=====================
|
||||
|
||||
@ -173,7 +173,7 @@ When the data to create is more complex it can be useful, or even necessary, to
|
||||
Field Values Values
|
||||
================== ==================== ======================
|
||||
name Big Villa Trailer home
|
||||
state New Canceled
|
||||
state New Cancelled
|
||||
description A nice and big villa Home in a trailer park
|
||||
postcode 12345 54321
|
||||
date_availability 2020-02-02 1970-01-01
|
||||
|
||||
@ -277,7 +277,7 @@ Note that the default ``active=False`` value was assigned to all existing record
|
||||
.. exercise:: Add state field.
|
||||
|
||||
Add a ``state`` field to the ``estate.property`` model. Five values are possible: New,
|
||||
Offer Received, Offer Accepted, Sold and Canceled. It must be required, should not be copied
|
||||
Offer Received, Offer Accepted, Sold and Cancelled. It must be required, should not be copied
|
||||
and should have its default value set to 'New'.
|
||||
|
||||
Make sure to use the correct type!
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
==================================
|
||||
=================================
|
||||
Chapter 9: Ready For Some Action?
|
||||
==================================
|
||||
=================================
|
||||
|
||||
So far we have mostly built our module by declaring fields and views. We just introduced business
|
||||
logic in the :doc:`previous chapter <08_compute_onchange>` thanks to
|
||||
@ -30,7 +30,7 @@ Object Type
|
||||
:align: center
|
||||
:alt: Cancel and set to sold
|
||||
|
||||
A canceled property cannot be sold and a sold property cannot be canceled. For the sake of
|
||||
A cancelled property cannot be sold and a sold property cannot be cancelled. For the sake of
|
||||
clarity, the ``state`` field has been added on the view.
|
||||
|
||||
- You should be able to accept or refuse an offer:
|
||||
@ -99,8 +99,8 @@ and its
|
||||
|
||||
.. exercise:: Cancel and set a property as sold.
|
||||
|
||||
- Add the buttons 'Cancel' and 'Sold' to the ``estate.property`` model. A canceled property
|
||||
cannot be set as sold, and a sold property cannot be canceled.
|
||||
- Add the buttons 'Cancel' and 'Sold' to the ``estate.property`` model. A cancelled property
|
||||
cannot be set as sold, and a sold property cannot be cancelled.
|
||||
|
||||
Refer to the first image of the **Goal** for the expected result.
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ Our real estate module now makes sense from a business perspective. We created
|
||||
:doc:`constraints <10_constraints>`. However our user interface is still a bit
|
||||
rough. We would like to add some colors to the list views and make some fields and buttons conditionally
|
||||
disappear. For example, the 'Sold' and 'Cancel' buttons should disappear when the property
|
||||
is sold or canceled since it is no longer allowed to change the state at this point.
|
||||
is sold or cancelled since it is no longer allowed to change the state at this point.
|
||||
|
||||
This chapter covers a very small subset of what can be done in the views. Do not hesitate to
|
||||
read the reference documentation for a more complete overview.
|
||||
@ -303,7 +303,7 @@ should not be displayed to the user, we can use the ``invisible`` attribute to h
|
||||
there is no garden.
|
||||
- Make the 'Accept' and 'Refuse' buttons invisible once the offer state is set.
|
||||
- Do not allow adding an offer when the property state is 'Offer Accepted', 'Sold' or
|
||||
'Canceled'. To do this use the ``readonly`` attribute.
|
||||
'Cancelled'. To do this use the ``readonly`` attribute.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ Python Inheritance
|
||||
|
||||
**Goal**: at the end of this section:
|
||||
|
||||
- It should not be possible to delete a property which is not new or canceled.
|
||||
- It should not be possible to delete a property which is not new or cancelled.
|
||||
|
||||
.. image:: 12_inheritance/unlink.gif
|
||||
:align: center
|
||||
@ -87,7 +87,7 @@ when you need to call the parent method with a modified recordset.
|
||||
|
||||
.. exercise:: Add business logic to the CRUD methods.
|
||||
|
||||
- Prevent deletion of a property if its state is not 'New' or 'Canceled'
|
||||
- Prevent deletion of a property if its state is not 'New' or 'Cancelled'
|
||||
|
||||
Tip: create a new method with the :func:`~odoo.api.ondelete` decorator and remember that
|
||||
``self`` can be a recordset with more than one record.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user