> ## Documentation Index
> Fetch the complete documentation index at: https://help.polygon-one.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Requests

> Request packaging data from suppliers, chase replies, and review submissions

## Overview

With a **data request** you ask a supplier for the packaging data of their units and components in a structured way. The supplier receives a secure portal link, delivers components and documents directly into the platform, and you track progress in the [supplier cockpit](/en/ppwr/datenerfassung/uebersicht).

There is exactly **one request type** — the data request. It can cover whole packaging units, individual components, or both; the supplier delivers components, values, and documents.

<Note>
  Readiness checks sent earlier remain usable: their links still open and can still be answered. New ones are no longer created.
</Note>

## Creating and sending a request

You start a request on the packaging unit, on the component, or from the supplier's row in the cockpit — everywhere via the **Request data** button, and everywhere the same **Request packaging data** dialog opens.

<Steps>
  <Step title="Open the dialog">
    Click **Request data**. The **Request packaging data** dialog opens.

    <Frame caption="The Request packaging data dialog with scope, supplier, and message">
      <img src="https://mintcdn.com/polygonone/U5pMt0dQhFreJM5t/images/ppwr/datenerfassung/datenanfrage-dialog.png?fit=max&auto=format&n=U5pMt0dQhFreJM5t&q=85&s=fb29f88a3dff8a3f4ed8f0b3be07dc20" width="663" height="926" data-path="images/ppwr/datenerfassung/datenanfrage-dialog.png" />
    </Frame>
  </Step>

  <Step title="Select or create the supplier">
    If you start from a unit or component, the already-assigned supplier is pre-selected. If the supplier does not exist yet, create them via **+ Add a new supplier** right in the dialog (name, email, country); on send, they are assigned automatically. If you start from the cockpit row, the supplier is already fixed.
  </Step>

  <Step title="Review the scope">
    The dialog shows both grains: **Packaging units in this request** and **Components in this request**. Both lists are pre-selected with **this supplier's full scope** — including the unit or component you started from. That way the supplier holds one link covering everything instead of several partial requests. You can narrow the selection.

    The platform prevents double-asking on its own: components already collected through a selected packaging unit are excluded automatically, and anything already part of an open request is not asked for again.
  </Step>

  <Step title="Due date and message (optional)">
    Set a due date under **Requested by (optional)** and add context for the supplier under **Message to the supplier (optional)** (max. 2000 characters).
  </Step>

  <Step title="Choose the delivery method and send">
    Decide how the supplier gets access:

    * **Copy link** (badge **Recommended**, the default): the **Create link** button creates the access, and under **Invitation link ready** you copy it — you pass it on yourself, e.g. from your own mailbox, which the supplier recognizes. No email is sent.
    * **Send email**: the **Send request** button has Polygon One send the email automatically. This requires an email address on the supplier record — without one the option is blocked and the dialog points you to the copy-link option.
  </Step>
</Steps>

<Info>
  If your selection spans both grains, the send creates **one request per grain** — one for the packaging units, one for the components. The supplier sees both in their request dashboard; with the **Copy link** delivery method they still receive **one combined link**.
</Info>

## Requesting from the cockpit

The **Request data** row action in the [supplier cockpit](/en/ppwr/datenerfassung/uebersicht) opens the very same dialog: the supplier is fixed, and both lists are pre-selected with their full scope. So nothing goes out automatically — you can adjust the scope before sending and choose between link and email just as anywhere else.

The **bulk action** works differently: **Request data (\{count})** sends asynchronously in the background and **by email only** — there is no copy-link option here. Selected suppliers without an email address are reported in the result as **skipped**; no request is created for them. Add an email address for those suppliers first — or request from them individually via the row action with a copied link.

## What the supplier receives

With automatic delivery, the supplier gets an email with the subject **"\{your company name}: packaging data request (PPWR)"**. It contains:

* who is asking and why (EU Packaging and Packaging Waste Regulation, PPWR),
* how many units or components are affected,
* the due date ("Requested by \{date}"), if set,
* the **Open the request** button with the secure portal link.

The email language follows the supplier's country (e.g. German for DE/AT). If the supplier replies directly to the email, their reply automatically lands in the request's message thread. The portal link works **without an account** — what the supplier sees there is described on the [supplier portal](/en/ppwr/datenerfassung/lieferantenportal) page.

## One link per supplier

Every supplier has **one durable portal link**: a new request to the same supplier reuses that link instead of issuing a second one. If several requests are open, the link lands on a request list split into **To do** and **Completed**.

* **Validity**: 30 days — refreshed every time the link is reused. After a maximum lifetime of 90 days, the platform issues a fresh link automatically and sends it with the next request.
* **Replaced partial requests**: if a new, wider request also covers earlier partial requests, those are cancelled. The dialog tells you on send: "… earlier partial request(s) replaced — their old links no longer work."

## Request statuses

The supplier's **request history** shows the status of every individual request:

| Status                   | Meaning                                                                                              |
| ------------------------ | ---------------------------------------------------------------------------------------------------- |
| **Draft**                | The request exists but has not been delivered yet.                                                   |
| **Sent**                 | The request is with the supplier; a reply is pending.                                                |
| **In progress**          | The supplier has opened the request and is working on it.                                            |
| **Submitted**            | The supplier has submitted their reply. The data is on your units/components.                        |
| **Correction requested** | You sent the reply back for correction; the supplier can resubmit.                                   |
| **Cancelled**            | The request was withdrawn — or replaced by a new, wider request. It no longer counts in the rollups. |

In the cockpit you additionally see the derived **collection status** per supplier: **Not requested** / **Awaiting reply** / **Partially provided** / **Complete** / **Overdue** — including the progress "\{provided} of \{total}". **Complete** means the data has been fully provided, not merely that the supplier replied.

## Reminders and chasing

Polygon One follows up automatically so requests don't go stale:

* **Supplier reminders**: by default, after **7 and 14 days** without a reply, the supplier receives a reminder email ("Reminder: \{company} — packaging data request (PPWR)") with the same portal link.
* **Escalation to you**: if a request stays unanswered for **21 days**, your admins are notified.
* The **Reminders** column in the cockpit shows "\{count} reminder(s) · last \{date}" for the most recent open request — or "—" if none have been sent.

<Info>
  The rungs (7/14 days, escalation after 21 days) are defaults. Under **Settings → PPWR** you can add or remove rungs and switch chasing off entirely. When a request is reopened for correction, the reminder ladder starts over — and the supplier's link is refreshed.
</Info>

<Note>
  Requests you delivered via **Create link** trigger **no automatic reminder emails** to the supplier — the platform never emailed them, so chasing is on you. The 21-day escalation to your admins still fires.
</Note>

## Message thread

Every request has a **message thread** between you and the supplier. You open it via the messages button in the cockpit row ("Message \{name}"); the supplier reaches the same thread from the portal — even after submitting their reply.

<Frame caption="Message thread between you and the supplier">
  <img src="https://mintcdn.com/polygonone/U5pMt0dQhFreJM5t/images/ppwr/datenerfassung/anfrage-nachrichtenverlauf.png?fit=max&auto=format&n=U5pMt0dQhFreJM5t&q=85&s=1cf9ead095b4d0963ebf5fddf05055c5" width="554" height="469" data-path="images/ppwr/datenerfassung/anfrage-nachrichtenverlauf.png" />
</Frame>

Direct email replies from the supplier to the request email are automatically filed into the thread — nothing gets lost in mailboxes.

## Reviewing replies

Once the supplier has submitted, three review mechanisms apply:

1. **Delivered component data** is written by the platform directly to the packaging unit — including the supplier's self-declaration that their information is accurate. The [obligation checklist](/en/ppwr/rollen-pflichten/pflichtenkatalog) and the collection progress update immediately; the cockpit shows what is complete and what is missing.
2. **Uploaded documents** are analyzed by the AI: from a **technical documentation**, recognized values are prepared as proposals for acceptance into the components, or applied automatically when the AI is confident; all other evidence documents are checked for whether they fit their evidence slot. You can approve or **reject** individual documents — on rejection, the request automatically goes back to the supplier with a note on which documents to replace. Details: [Evidence documents](/en/ppwr/datenerfassung/nachweise).
3. **Request correction**: if something is substantively wrong, send the whole reply back via the row action **Request correction** with an optional reason. The request switches to **Correction requested**, the supplier sees their previous answers prefilled and resubmits corrected data. The supplier can also ask for a reopen themselves ("Request a correction" in the portal) — but only you actually reopen it.

## Next steps

<CardGroup cols={2}>
  <Card title="Supplier portal" icon="store" href="/en/ppwr/datenerfassung/lieferantenportal">
    What your supplier sees after clicking the link.
  </Card>

  <Card title="Evidence documents" icon="file-shield" href="/en/ppwr/datenerfassung/nachweise">
    AI analysis, proposal review, and the document library.
  </Card>
</CardGroup>