odoo-forge-bundle 0.1.0

package/payload/skills/odoo18-docs/references/docs/applications/inventory_and_mrp/plm/manage_changes/version_control.md

@@ -0,0 +1,168 @@
+---
+title: "Version control"
+source_url: "https://docs.odoo.sbggai.top/applications/inventory_and_mrp/plm/manage_changes/version_control.html"
+---
+
+===============
+# Version control
+
+.. |BOM| replace:: :abbr:`BoM (Bill of Materials)`
+.. |BOMs| replace:: :abbr:`BoMs (Bills of Materials)`
+.. |ECO| replace:: :abbr:`ECO (Engineering Change Order)`
+.. |ECOs| replace:: :abbr:`ECOs (Engineering Change Orders)`
+
+Use Odoo's *Product Lifecycle Management (PLM)* to manage previous versions of bills of materials
+(BoMs). Store former assembly instructions, component details, and past product design files while
+keeping the past details out of the production |BOM|.
+
+Easily revert to previous |BOM| versions, when needed. Additionally, use *PLM* to trace which |BOM|
+version was active on specific dates for recalls or customer complaints.
+
+Every |BOM| version is stored in an *engineering change order* (ECO) for organized testing and
+improvements without disrupting normal manufacturing operations.
+
+.. seealso::
+   :ref:`Engineering change order <plm/eco>`
+
+# Current BoM version
+
+To see the current version of the |BOM| used in production, go to :menuselection:`PLM app --> Master
+Data --> Bill of Materials`, and select the desired |BOM| from the list. Then, switch to the
+:guilabel:`Miscellaneous` tab, where the currently live :guilabel:`Version` of the |BOM| is
+displayed.
+
+> **note**:
+>    |BOMs| can also be accessed from :menuselection:`Manufacturing app --> Products --> Bill of
+   Materials`.
+
+.. image:: version_control/current-version.png
+   :align: center
+   :alt: Show the current version BOM in the Misc tab.
+
+# Version history
+
+To manage all former, current, and future versions of a |BOM|, begin by navigating to
+:menuselection:`Manufacturing app --> Products --> Bills of Materials` and click the desired |BOM|.
+
+From the |BOM| page, click the :guilabel:`ECO` smart button, and switch to list view by selecting
+the :guilabel:`≣ (four horizontal lines)` icon on the top right corner.
+
+> **note**:
+>    The :guilabel:`ECO` smart button is visible on the |BOM| **only** if the *PLM* app is installed.
+
+.. image:: version_control/eco-smart-button.png
+   :align: center
+   :alt: Show ECO smart button on a BoM.
+
+In the list of |ECOs| for the product, navigate to the search bar at the top, and click the
+:guilabel:`▼ (down arrow)` icon on the right to access a drop-down menu of :guilabel:`Filters`.
+
+Next, filter by :guilabel:`Done` |ECOs| to view: the revision history of the |BOM|, the
+:guilabel:`Responsible` user who applied the change, and the :guilabel:`Effective Date` of the
+|BOM|.
+
+Click each |ECO| to view the past components, operations, and design files associated with the
+|BOM|.
+
+.. image:: version_control/eco-list.png
+   :align: center
+   :alt: Display ECO revision history for a BoM for a product.
+
+> **note**:
+>    If the :guilabel:`Effective Date` field is empty, the :guilabel:`Effective` date of the |ECO| is
+   automatically set to :guilabel:`As soon as possible` and no dates are recorded in the revision
+   history of the |BOM|.
+
+   .. image:: version_control/no-effective-date.png
+      :align: center
+      :alt: List of BOM effective dates.
+
+> **tip**:
+>    A workaround for checking when the |BOM| went live is by navigating to the chatter, and hovering
+   over the time the |ECO| was moved to the :ref:`closing stage <plm/eco/stage-config>`.
+
+# Design files
+
+Attach computer-aided design (CAD) files, PDFs, images, or other design material to the |BOM|
+itself.
+
+To do so, navigate to :menuselection:`PLM app --> Master Data --> Bill of Materials`, and select the
+desired |BOM|. On the |BOM|, navigate to the *chatter*, and click the :guilabel:`📎 (paperclip)`
+icon.
+
+The files associated with the |BOM| are displayed in the :guilabel:`Files` section. To add more
+design files, select the :guilabel:`Attach files` button.
+
+.. image:: version_control/attach-files.png
+    :align: center
+    :alt: Show paperclip icon in the chatter to attach files to a BoM.
+
+## Manage design files in an ECO
+
+Add, modify, and remove files in an |ECO|. Once the |ECO| is approved and applied, the new files are
+automatically linked to the production |BOM|. Archived files are removed from the |BOM|, but are
+still accessible in the |ECO|.
+
+To manage the design files in the |ECO|, begin by navigating to :menuselection:`PLM app --> Changes`
+and choose the desired |ECO|. Next, open the :guilabel:`Attachments` page by clicking the
+:guilabel:`Documents` smart button.
+
+Hover over each attachment to reveal the :guilabel:`︙ (three vertical dots)` icon. From there,
+choose whether to :guilabel:`Edit`, :guilabel:`Remove`, or :guilabel:`Download` the file. Any
+changes made to these files are contained within the |ECO|, and will only apply to the production
+|BOM| once the :ref:`changes are applied <plm/eco/apply-changes>`.
+
+.. example::
+   In the `Create 60% keyboard` |ECO|, the design files are from the original `100% keyboard` |BOM|.
+   To replace the keyboard PDF, begin by selecting the :guilabel:`Documents` smart button.
+
+   .. image:: version_control/documents-smart-button.png
+      :align: center
+      :alt: Show *Documents* smart button from an active ECO.
+
+   On the :guilabel:`Attachments` page, hover over the `100% keyboard manual.pdf` design file, and
+   click the :guilabel:`︙ (three vertical dots)` icon. Then, click the :guilabel:`Remove` option to
+   archive the file.
+
+   Next, on the same :guilabel:`Attachments` page, click the :guilabel:`Upload` button to upload the
+   new design file, named `60% keyboard manual`.
+
+   .. image:: version_control/attachments.png
+      :align: center
+      :alt: View of *Attachments* page from the *Documents* smart button. Displays one archived and
+            one newly added attachment.
+
+> **note**:
+>    Archived files are **not** permanently deleted — they can still be accessed in the previous
+   |ECO|, or as an archived file in the latest |ECO|, where the archival occurred.
+
+# Apply rebase
+
+Odoo simplifies merge conflict resolution for concurrent |ECOs| on the same product.
+
+Conflicts can occur when the production |BOM| is updated while other |ECOs| are modifying the
+previous version. Differences between the new and previous production |BOMs| are displayed in the
+:guilabel:`Previous Eco Bom Changes` tab, visible only in this scenario.
+
+To resolve conflicts and retain |ECO| changes, click the :guilabel:`Apply Rebase` button.
+
+.. example::
+   Two |ECOs|, `ECO0011` and `ECO0012`, are created when the current |BOM| version is `5`. In
+   `ECO0011`, a new component, `Space stabilizer`, is added, and the changes are applied. This means
+   the current |BOM| version has become `6`.
+
+   .. image:: version_control/branch-change.png
+      :align: center
+      :alt: Apply changes to an ECO to update the production BOM.
+
+   This means `ECO0012` is modifying an outdated |BOM|. As shown in the :guilabel:`Previous Eco Bom
+   Changes` tab, the |BOM| is missing the `Space stabilizer`.
+
+   To ensure the changes applied by `ECO0011` are kept when the changes occur in `ECO0012`, click
+   the :guilabel:`Apply Rebase` button to apply the previous |ECO| changes, without affecting the
+   changes already made to `ECO0012`.
+
+   .. image:: version_control/merge-change.png
+      :align: center
+      :alt: Click the *Apply Rebase* button to update the BOM to match the production BOM.
+

package/payload/skills/odoo18-docs/references/docs/applications/inventory_and_mrp/plm/manage_changes.md

@@ -0,0 +1,14 @@
+---
+title: "Change management"
+source_url: "https://docs.odoo.sbggai.top/applications/inventory_and_mrp/plm/manage_changes.html"
+---
+
+=================
+# Change management
+
+.. toctree::
+   :titlesonly:
+
+   manage_changes/engineering_change_orders
+   manage_changes/eco_type
+   manage_changes/version_control

package/payload/skills/odoo18-docs/references/docs/applications/inventory_and_mrp/plm/management/approvals.md

@@ -0,0 +1,103 @@
+---
+title: "Approvals"
+source_url: "https://docs.odoo.sbggai.top/applications/inventory_and_mrp/plm/management/approvals.html"
+---
+
+=========
+# Approvals
+
+.. |ECO| replace:: :abbr:`ECO (Engineering Change Order)`
+.. |ECOs| replace:: :abbr:`ECOs (Engineering Change Orders)`
+
+.. _plm/approvals:
+
+Notify stakeholders and managers automatically by assigning approvers to stages of :ref:`engineering
+change orders <plm/eco>` (ECOs) under review. Changes can only be applied after the assigned
+approver accepts them. Approvals ensure reviews by team members, which prevents mistakes and
+premature actions.
+
+.. seealso::
+   :ref:`Stage configuration <plm/eco/stage-config>`
+
+# Add approvers
+
+To add an approver, first go to the :menuselection:`PLM app`, and click on the project card of an
+|ECO| type to open the Gantt view of the |ECOs|.
+
+On the :guilabel:`Engineering Change Orders` page, hover over the intended stage, and select the
+:icon:`fa-gear` :guilabel:`(Actions)` icon. Then, click :guilabel:`Edit` to open a pop-up window.
+
+> **note**:
+>    Approvers can be added to any stage, but they are most essential in the *verification* stage,
+   before the final *closing* stage which applies the |ECO| and updates the :abbr:`BoM (Bill of
+   Materials)`. This allows stakeholders to control how and when changes are made.
+
+   See the documentation about :ref:`stage types <plm/eco/stage-config>` for more information.
+
+In the :guilabel:`Edit` stage pop-up window, click the :guilabel:`Add a line` button, located under
+:guilabel:`Approvals`. Then, type in the position or title of the approver under :guilabel:`Role`
+(e.g. `Engineering Manager`, `Quality Team`, etc.), and select the relevant :guilabel:`User` from
+the drop-down menu.
+
+.. _plm/approvals/approval-type:
+
+## Approval types
+
+Next, set the :guilabel:`Approval Type` to :guilabel:`Is required to approve`, :guilabel:`Approves,
+but the approval is optional`, or :guilabel:`Comments only`.
+
+.. example::
+   Assign the `CTO`, "Mitchell Admin," as a required approver for |ECOs| in the `Validated` stage in
+   the `New Product Introduction` |ECO| type.
+
+   Approvals from the quality and marketing teams are **not** required to apply changes to the |ECO|
+   because their :guilabel:`Approval Type` is set to :guilabel:`Approves, but the approval is
+   optional` and :guilabel:`Comments only`, respectively.
+
+   .. image:: approvals/approvers.png
+      :alt: Set an approver that "Is required to approve" ECOs in the "Validated" stage.
+
+# Manage approvals
+
+Approvers can track their to-do approvals by navigating to the :menuselection:`PLM app`, and
+selecting the card for an |ECO| type, which shows the count of open tasks assigned to them.
+
+.. image:: approvals/validation-overview.png
+   :alt: Display count of validations to-do and buttons to open filtered list of ECOs.
+
+Here's what each button on an |ECO| project card does:
+
+#. The :guilabel:`# Engineering Changes` button displays a count of in-progress |ECOs| of this ECO
+   type. Clicking the button opens the Gantt view of the :guilabel:`Engineering Change Orders` page.
+#. :guilabel:`My Validations` displays a count of |ECOs| the approver must accept or reject.
+   Clicking on this button displays |ECOs| pending approval or rejected (marked with the red
+   :guilabel:`Blocked` state).
+#. The :guilabel:`All Validations` button shows the count of |ECOs| awaiting approval or rejected by
+   any approver. Clicking it reveals these pending |ECOs|.
+#. :guilabel:`To Apply` displays a count of |ECOs| to which the user needs to apply changes.
+   Clicking on the button displays all the |ECOs| to approve, and apply changes to, in the
+   verification stage.
+
+|ECOs| marked with the green :guilabel:`Done` stage have already been approved, and the user needs
+to click on the |ECO| to enter the form view, and click the :guilabel:`Apply Changes` button.
+
+> **tip**:
+>    |ECO| approvals can be accessed, managed, and follow-up actions scheduled through *Activities*.
+   See the :doc:`Activities documentation <../../../essentials/activities>` to learn more about
+   integrating management workflows.
+
+## Approve ECOs
+
+Navigate to an |ECO| in a verification stage, while logged in as the assigned approver, to see the
+:guilabel:`Approve`, :guilabel:`Reject`, and :guilabel:`Apply Changes` buttons.
+
+To approve the |ECO|, and apply the changes onto the production :abbr:`BoM (Bill of Materials)`,
+click :guilabel:`Approve`, and then :guilabel:`Apply Changes`.
+
+Note that the :guilabel:`Apply Changes` button will **not** work unless the :guilabel:`Approve`
+button was clicked first. Additionally, the chatter logs the history of the clicked buttons.
+
+> **warning**:
+>    If no approver has the :guilabel:`Is required to approve` approval type, the :guilabel:`Apply
+   Changes` button **will work** without requiring the :guilabel:`Approve` button to be clicked
+   first.

package/payload/skills/odoo18-docs/references/docs/applications/inventory_and_mrp/plm/management.md

@@ -0,0 +1,12 @@
+---
+title: "Project management"
+source_url: "https://docs.odoo.sbggai.top/applications/inventory_and_mrp/plm/management.html"
+---
+
+==================
+# Project management
+
+.. toctree::
+   :titlesonly:
+
+   management/approvals

package/payload/skills/odoo18-docs/references/docs/applications/inventory_and_mrp/plm.md

@@ -0,0 +1,23 @@
+---
+title: ""
+source_url: "https://docs.odoo.sbggai.top/applications/inventory_and_mrp/plm.html"
+---
+
+:nosearch:
+:show-content:
+:hide-page-toc:
+:show-toc:
+# 
+# Product lifecycle management
+
+Odoo *Product Lifecycle Management* (*PLM*) offers a systematic approach for testing, collaboration,
+and iteration of products across concept development, design, manufacturing, marketing, and
+post-launch support stages.
+
+With approvals, key stakeholders can review changes before implementation.
+
+.. toctree::
+   :titlesonly:
+
+   plm/manage_changes
+   plm/management

package/payload/skills/odoo18-docs/references/docs/applications/inventory_and_mrp/purchase/advanced/analyze.md

@@ -0,0 +1,147 @@
+---
+title: "Purchase Analysis report"
+source_url: "https://docs.odoo.sbggai.top/applications/inventory_and_mrp/purchase/advanced/analyze.html"
+---
+
+========================
+# Purchase Analysis report
+
+.. |PO| replace:: :abbr:`PO (purchase order)`
+.. |POs| replace:: :abbr:`POs (purchase orders)`
+
+The *Purchase Analysis* report provides statistics about products purchased using Odoo's
+**Purchase** app. This data is useful for gaining a deeper understanding of key metrics related to
+purchase orders (POs), including the quantity of products ordered and received, the amount of time
+it takes to receive purchased products, and more.
+
+To open the Purchase Analysis report, navigate to :menuselection:`Purchase app --> Reporting -->
+Purchase`.
+
+> **important**:
+>    The :guilabel:`Purchase Analysis` report is one of many reports available across the Odoo app
+   suite. This documentation only covers the measures specific to the :guilabel:`Purchase Analysis`
+   report, along with a few use case examples.
+
+   For a full overview of the basic features available in most Odoo reports, see the documentation
+   on :doc:`reporting essentials <../../../essentials/reporting>`.
+
+# Measures
+
+*Measures* refer to the various datasets that can be displayed on the :guilabel:`Purchase Analysis`
+report, with each dataset representing a key statistic about |POs| or products. To choose a measure,
+click the :guilabel:`Measures` :icon:`fa-caret-down` button, and select one of the options from the
+drop-down menu:
+
+- :guilabel:`# of Lines`: The number of |PO| order lines, across all |POs|.
+- :guilabel:`Average Cost`: The average cost of |POs|.
+- :guilabel:`Days to Confirm`: The number of days it takes to confirm a |PO|.
+- :guilabel:`Days to Receive`: The number of days it takes to receive the products in a |PO|.
+- :guilabel:`Gross Weight`: The total weight of purchased products.
+- :guilabel:`Qty Billed`: The quantity of a product (or products) for which the vendor has already
+  been billed.
+- :guilabel:`Qty Ordered`: The quantity of a product (or products) ordered.
+- :guilabel:`Qty Received`: The quantity of an ordered product (or products) received.
+- :guilabel:`Qty to be Billed`: The quantity of an ordered product (or products) for which the
+  vendor has yet to be billed.
+- :guilabel:`Total`: The total amount spent, including tax.
+- :guilabel:`Untaxed Total`: The total amount spent, excluding tax. This measure is selected by
+  default.
+- :guilabel:`Volume`: The total volume of ordered products, for products which are measured by
+  volume.
+- :guilabel:`Count`: The total count of |POs|.
+
+> **tip**:
+>    Only one measure can be selected at a time when one of the :icon:`fa-area-chart`
+   :guilabel:`(graph view)` options is enabled. However, multiple measures, and varying group-by
+   criteria (on the x and y axes), can be selected when using the :icon:`oi-view-pivot`
+   :guilabel:`(pivot table)`.
+
+.. _purchase/purchase-analysis-example:
+
+# Use case: determine days to receive products from each vendor
+
+One possible use case for the :guilabel:`Purchase Analysis` report is determining how long each
+vendor takes to deliver purchased items. This allows companies to make better informed decisions
+about which vendors they want to purchase from.
+
+.. example::
+   A local bike shop, *Bike Haus*, sells high-quality unicycles, bicycles, tricycles, and all the
+   accessories needed to ride and maintain them. They purchase their inventory from a few different
+   vendors, and then sell those products on to customers through their storefront.
+
+   Recently, Bike Haus has decided to have their purchasing manager, David, look into how long it
+   has taken each of their vendors to deliver the items they've purchased during the current year,
+   2024.
+
+   David starts by navigating to :menuselection:`Purchase app --> Reporting --> Purchase`, and
+   selecting the :icon:`fa-bar-chart` (bar chart) graph type at the top of the report.
+
+   Next, he clicks the :icon:`fa-caret-down` :guilabel:`(toggle)` button on the right of the search
+   bar to open its drop-down menu. In the :guilabel:`Confirmation Date` filter section, he makes
+   sure that **only** the :guilabel:`2024` filter is enabled. Then, he selects the
+   :guilabel:`Vendor` option in the :guilabel:`Group By` section, before clicking away from the
+   drop-down menu to close it.
+
+   Finally, David clicks on the :guilabel:`Measures` :icon:`fa-caret-down` drop-down menu, and
+   selects the :guilabel:`Days to Receive` option.
+
+   With all of these options enabled, the :guilabel:`Purchase Analysis` report shows a bar chart,
+   with one bar for each vendor, representing the average number of days it takes to receive
+   products purchased from the vendor.
+
+   Using this data, David can see that it takes Bike Friends over 4.5 days, on average, to deliver
+   purchased products. This is more than four times the amount of time it takes any other vendor.
+
+   Based on these findings, David makes the decision to reduce the quantity of products purchased
+   from Bike Friends.
+
+   .. image:: analyze/dtr.png
+      :align: center
+      :alt: The Purchase report, showing the average days to receive products from vendors.
+
+# Use case: compare vendor POs for two time periods
+
+Another use for the :guilabel:`Purchase Analysis` report is to compare key statistics about |POs|
+for two different time periods, for a specific vendor. By doing so, it is easy to understand how
+purchases from the vendor have increased or decreased.
+
+.. example::
+   Following the :ref:`previous example <purchase/purchase-analysis-example>`, it has been one month
+   since Bike Haus decided to reduce the quantity of products purchased from Bike Friends, one of
+   their retailers. Bike Haus' purchasing manager, David, wants to understand the impact this
+   decision has had on the amount of money they have spent on Bike Friends products.
+
+   David starts by navigating to :menuselection:`Purchase app --> Reporting --> Purchase`. Then, he
+   selects the :icon:`oi-view-pivot` :guilabel:`(pivot table)` option at the top of the screen.
+
+   In the search bar, he types `Bike Friends`, and clicks :guilabel:`Enter`, so the report only
+   shows data for purchases from Bike Friends.
+
+   Then, David clicks the :icon:`fa-caret-down` :guilabel:`(toggle)` button on the right of the
+   search bar to open its drop-down menu. In the :guilabel:`Confirmation Date` field, he leaves the
+   :guilabel:`June` and :guilabel:`2024` filters enabled. He also selects :guilabel:`Confirmation
+   Date: Previous Period` in the :guilabel:`Comparison` section, before clicking away from the
+   drop-down menu to close it.
+
+   Next, David clicks on the :guilabel:`Measures` :icon:`fa-caret-down` drop-down menu. He leaves
+   the :guilabel:`Total` and :guilabel:`Untaxed Total` datasets enabled, and disables the
+   :guilabel:`Order` and :guilabel:`Count` datasets.
+
+   Finally, David clicks the :icon:`fa-minus-square-o` :guilabel:`Total` button above the rows on
+   the pivot table, and selects the :guilabel:`Product` option.
+
+   With all of these options configured, the :guilabel:`Purchase Analysis` report shows a pivot
+   table comparing purchase data for the current month, June, with the previous month, May.
+
+   The pivot table is broken down into two main columns: one for the untaxed total spent, and one
+   for the taxed total spent. These columns are further broken down into three smaller columns: the
+   amount spent in May, the amount spent in June, and the variation between the two months,
+   represented as a percentage.
+
+   On the left side of the pivot table, one row is shown for each product purchased from Bike
+   Friends during June. Using this report, David is able to see that Bike Haus has spent much less
+   money on products purchased from Bike Friends, compared to the previous month.
+
+   .. image:: analyze/comparison.png
+      :align: center
+      :alt: The Purchase report, comparing the amount spent at a vendor.

package/payload/skills/odoo18-docs/references/docs/applications/inventory_and_mrp/purchase/advanced/edi.md

@@ -0,0 +1,109 @@
+---
+title: "EDI purchase-to-sales order import"
+source_url: "https://docs.odoo.sbggai.top/applications/inventory_and_mrp/purchase/advanced/edi.html"
+---
+
+==================================
+# EDI purchase-to-sales order import
+
+.. |EDI| replace:: :abbr:`EDI (Electronic Data Exchange)`
+.. |PO| replace:: :abbr:`PO (purchase order)`
+.. |SO| replace:: :abbr:`SO (sales order)`
+
+Electronic data interchange (EDI) enables companies using different software systems to exchange
+information in a standardized, structured format.
+
+In Odoo, a *purchase order* (PO) can be exported as an XML file and imported as a *sales order* (SO)
+into another Odoo database, removing the need for manual entry of products, quantities, prices, and
+other key information.
+
+> **note**:
+>    Exported XMLs follow the [Order-X schema ](https://fnfe-mpe.org/factur-x/order-x/), a standard
+   commonly used in European countries. When exchanging data between two Odoo databases, this schema
+   remains compatible.
+
+   However, implementing custom developments for software that does not support the Order-X schema
+   may introduce additional complexity.
+
+# Roles and configuration
+
+To facilitate the |EDI| workflow, two companies are involved: the buyer (the company placing the
+order) and the seller (the company fulfilling the order). Each company has specific roles and
+configurations.
+
+## Buyer database
+
+The buyer database is responsible for creating and confirming purchase orders. Prerequisites include
+:ref:`installing <general/install>` the **Purchase** app and adding vendors (the sellers in this
+workflow) as :doc:`portal users <../../../general/users/portal>`.
+
+## Seller database
+
+The seller database is responsible for receiving and processing sales orders. The only prerequisite
+is :ref:`installing <general/install>` the **Sales** app.
+
+# Workflow
+
+## Buyer's process
+
+To begin, the buyer (in their database) navigates to the :menuselection:`Purchase` app to create a
+request for quotation (RFQ).
+
+Set the :guilabel:`Vendor` to the portal user representing the seller, and :guilabel:`Confirm` the
+:abbr:`RFQ (request for quotation)`. Doing so converts it into a :doc:`purchase order
+<../manage_deals/rfq>`.
+
+.. example::
+   |PO| from the buyer's database. The :guilabel:`Vendor` is the seller's portal user account, Joel.
+
+   .. image:: edi/po-database-view.png
+      :alt: Example PO. The Vendor is the seller's portal user account, Joel.
+
+## Seller's process
+
+Once the |PO| is confirmed, it appears on the seller's portal dashboard. The seller downloads the
+XML file and uploads it to their database.
+
+### Download file
+
+As the seller, log in to the buyer's database as the portal user. On the dashboard, scroll down and
+click the :guilabel:`Our Orders` button. Doing so reveals a list of purchase orders the buyer's
+database has addressed to the portal user.
+
+Select the desired purchase order, and the click :guilabel:`Connect with your software!` button.
+
+In the pop-up window, copy the provided URL, and paste it into a new browser tab to download the XML
+file.
+
+.. example::
+   Joel's portal view of the PO. The first image displays the :guilabel:`Connect with your
+   software!` button, and the second image displays a pop-up window with the :guilabel:`Copy`
+   button.
+
+.. image:: edi/po-portal-view.png
+   :alt: Portal view of the PO, with "Connect your software!" button.
+
+.. image:: edi/pop-up.png
+   :alt: Pop-up to copy link.
+
+.. example::
+   :download:`XML file <edi/P00017.xml>` for PO00017
+
+### Upload file
+
+Next, the seller logs in to their own Odoo database and opens :menuselection:`Sales` app. Click
+:guilabel:`Upload` and select the downloaded XML file. Alternatively, users can drag and drop the
+file into the :guilabel:`Quotations` dashboard.
+
+Doing so automatically generates a sales order with the customer populated as the buyer and all
+product lines, quantities, and prices pre-filled. This process ensures efficient and accurate data
+exchange between the two databases.
+
+.. figure:: edi/so.png
+   :alt: Uploaded SO in the seller's database.
+
+   Uploaded SO in the seller's database.
+
+.. seealso::
+   :doc:`../../../sales/sales/sales_quotations/create_quotations`
+