> ## Documentation Index > Fetch the complete documentation index at: https://docs.invopop.com/llms.txt > Use this file to discover all available pages before exploring further. # Moving parties between Plateformes Agréées > Answer another Plateforme Agréée's request to take over a party's Annuaire line, and take over lines from other platforms. A company can change Plateforme Agréée (PA) at any time. The new PA sends a `MOBILITY_REQUEST` to the old one, and the old PA answers with a `MOBILITY_RESPONSE`: accepted, accepted on another date, or refused. Invopop handles both sides of this exchange: * **Incoming:** another PA asks to take over an address registered through Invopop. * **Outgoing:** you register an address another PA holds. ## Incoming requests ### Setup Add the **PPF incoming migration** template to your workspace, then select it as the migration workflow in the France app's configuration. > **[PPF incoming migration](https://console.invopop.com/redirect/workflows/new?template=fr-pa-incoming-migration)** > > Add to my workspace → In the **Apps** view, open the **France** app, click **Configure**, and select the workflow under **Migration Workflow**. When another PA asks to take over addresses registered through Invopop, Invopop starts one migration job per requested address. Each job runs the configured workflow on the silo entry that registered the address. Invopop only accepts a request when it comes from the requesting platform's registered contact address. Anything else is refused and no job starts. ### Takeover form The **Start migration** step publishes a `link_url` under the `migration-link` key in the silo entry meta. Each silo entry has one link, which always opens the latest request for its address. The form shows the requesting platform and the address, and lets the user: * **Accept** the takeover, on the requested date or on another effective date picked from a calendar. * **Refuse** the takeover. ### Answer deadline The company has **5 business days** from the request's arrival to answer. This deadline only applies to workspaces with a migration workflow configured (see [Setup](#setup)). The form shows the deadline. If the address is still unanswered after that, **Wait for migration approval** accepts it automatically. ### Response **Complete migration** sends the `MOBILITY_RESPONSE` for the address to the new PA: | Answer | Response status | | - | - | | Accepted on the requested date | `ACCP` | | Accepted on another date | `ACWC`, with the agreed effective date | | Refused | `RJCT`, with motif `REFUS_CLIENT` | ## Outgoing takeovers To take over an address another PA holds, set the former PA's line under the `fr-former-matricule` meta key of the party. The signed agreement then includes an additional section asking the company to consent to the takeover. When you run the [PPF register supplier](/guides/fr-pa-registration.md#ppf-register-supplier-workflow) workflow for that address, **Register party in Directory** (`gov-fr.directory.register`) sends a `MOBILITY_REQUEST` to that PA and waits for its answer. Once the takeover is accepted, Invopop registers the line with the agreed effective date, and the step stays queued until that date. If the other PA refuses, or its answer can't be processed, the step fails with the reason. ## Reading migrations The France dashboard's **Migrations** tab lists every takeover request involving your workspace's addresses, newest first. In the Console, open the **Apps** view, select the **France** app, and switch to the **Migrations** tab. A workspace with no takeovers shows **No migrations yet**. Each row shows the New PA and Old PA, the Status, the SIREN, the Role, the company's Denomination, the Request number, the number of Endpoints (addresses) it covers, the New PA and Old PA matricules, and, for failed takeovers, the Failure reason. The Role tells you which side of the exchange Invopop is on: | Role | Meaning | | - | - | | Outgoing | Invopop is the new PA, taking over an address from another platform. | | Incoming | Another platform asked to take over one of your addresses. Invopop is the old PA. | | Status | Role | Meaning | | - | - | - | | Created | Outgoing | The request is built but not sent yet. | | Sent | Outgoing | The request was emailed to the old PA. | | Acknowledged | Outgoing | The old PA acknowledged the request. | | Responded | Outgoing | The old PA agreed; the Peppol migration code is still to follow. | | Received | Incoming | The request is waiting for answers. | | Completed | Outgoing, Incoming | The migration has been completed, either accepted or rejected. | | Failed | Outgoing | The takeover failed, failure reason is logged in the launcher. | An outgoing takeover moves from **Created** to **Sent**, **Acknowledged**, **Responded** and **Completed**, or ends as **Failed**. An incoming request moves from **Received** to **Completed**. The Failure reason explains why an outgoing takeover failed: for example, the old PA rejected it or put it on hold because of a dispute, accepted it without a migration code, sent a reply that couldn't be read, or the request email couldn't be sent. If the reason is unclear, contact Invopop support. > [!NOTE] > > Clicking a row opens a read-only side panel titled **SIREN** followed by the party's SIREN, with one **Details** block per address: its Endpoint, the Silo entry ID, the Decision, and the Reason and Effective Date when they are set. The Decision is your answer on an incoming request, or the old PA's answer on an outgoing one. It stays blank until the address is answered. | Decision | Meaning | | - | - | | `ACCP` | Accepted on the requested date. | | `ACWC` | Accepted on another effective date. | | `ACSP` | Accepted in principle; the final answer and Peppol migration code will follow. | | `RJCT` | Rejected. | | `PDNG` | On hold because of a dispute (outgoing only). | ## FAQ > **How does the 5-day deadline work?** > > The company has 5 business days, to answer, counted from the moment Invopop receives the request and ending at the same time of day (Paris time). For example, a request received on Friday at 15:00 expires the following Friday at 15:00. French public holidays are not taken into account. The form shows the date to answer by. > > Until then, **Wait for migration approval** stays queued, and the workflow continues as soon as the company answers. If the address is still unanswered at the deadline, Invopop accepts it automatically: on the date the new PA requested when that is still possible, otherwise on the earliest possible date. Once the response is sent, the answer can't be changed. > > The deadline only applies to workspaces with a migration workflow configured. > **Which effective dates can the company choose?** > > The form's calendar only offers dates from the earliest the switch can happen: at least 3 business days and 4 calendar days from the answer, whichever is later. Business days are Monday to Friday. > > If the company accepts without choosing a date, the date the new PA requested is used. If that date is already too soon, the earliest possible date is used instead, and the answer is sent as `ACWC`. > **When is a migration request complete?** > > An incoming request can cover several addresses, and each address gets its own job and form. Each answer is sent to the new PA as soon as it's given, with the addresses not answered yet marked pending. > > The request is complete once every address in it has been answered and the last answer has been sent. Until then, it shows as **Received** in the [Migrations tab](/guides/fr-pa-migrations.md#reading-migrations). > **What does the Reason in the Migrations tab mean?** > > When an address was refused, the side panel of the [Migrations tab](/guides/fr-pa-migrations.md#reading-migrations) shows the Reason next to the Decision. `REFUS_CLIENT` means the company refused the takeover, and `ADRESSE_INCONNUE` means the address isn't held at Invopop. Reasons from other platforms appear as they sent them. > **What happens if I don't have a migration workflow configured?** > > Invopop receives and records the request, but no workflow job starts for your workspace's addresses: there is no form link, no automatic acceptance at the deadline, and no `MOBILITY_RESPONSE` is sent to the other PA. > > To answer it, add the [PPF incoming migration](/guides/fr-pa-migrations.md#setup) workflow and select it in the France app configuration, then contact Invopop support to have the pending request processed again. The 5-day deadline still counts from when the request first arrived, so if it has already passed, the address is accepted automatically as soon as the workflow runs. > **Does the 'Start Peppol migration' action always have to run?** > > No, it's optional. Run it on the `accepted` branch when the party is registered on Peppol: its migration key is passed to the new PA, which uses it to move the party's Peppol registration. > > Without it, the response carries `NEANT`, meaning there is nothing to migrate on Peppol. The key is never sent for refused addresses. > **What outcomes does the 'Wait for migration approval' action have?** > > The step stays queued until the company answers or the deadline passes, then ends with one of these codes: > > * `accepted`: the address was accepted, on the requested date or another one, either by the company or automatically at the deadline. > * `rejected`: the company refused the takeover. The response is sent as `RJCT` with motif `REFUS_CLIENT`. > > Both outcomes continue to **Complete migration**, which sends the answer to the other PA. A typical workflow runs **Start Peppol migration** only on the `accepted` branch. More available in our [France FAQ](/faq/france.md) section *** > **🇫🇷 Invopop resources for France** > > | | | > | - | - | > | Compliance | [Invoicing compliance in France](/compliance/france.md) [Compliance timeline](/timelines/france.md) | > | Apps | [France](/apps/france.md) [Peppol](/apps/peppol.md) [Chorus Pro France](/apps/choruspro-france.md) | > | Guides | Chorus Pro — [Supplier registration](/guides/fr-chorus-pro-supplier.md) · [Issuing invoices](/guides/fr-chorus-pro.md) [PA Guide](/guides/fr-pa.md) — [Registration](/guides/fr-pa-registration.md) · [Invoicing](/guides/fr-pa-invoicing.md) · [Status](/guides/fr-pa-status.md) · [Reporting](/guides/fr-pa-reporting.md) · [Public sector](/guides/fr-pa-b2g.md) | > | FAQ | [France FAQ](/faq/france.md) | > | GOBL | [France Tax Regime](https://docs.gobl.org/regimes/fr) [Chorus Pro Addon](https://docs.gobl.org/addons/fr-choruspro-v1) [French Factur-X Addon](https://docs.gobl.org/addons/fr-facturx-v1) | > | GitHub | [gobl.xinvoice](https://github.com/invopop/gobl.xinvoice) | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.