Multiple updates on how to find orders in hubspot and exclude for example Aircall Tickets

delay-list-skill/SKILL.md

@@ -203,6 +203,34 @@ Check HubSpot for existing communication on the order item using the **mandatory
 - **If email shows internal issue** (e.g., artwork, stock) → tell which orders are internal reason.
 - **If no email found** → add order information to markdown file
 
+**CRITICAL — Skip Aircall tickets:** Tickets with a subject matching `"Aircall new ticket"` or containing `"Aircall"` are auto-generated phone call logs and should be ignored entirely. Do not count them as HubSpot hits and do not include them in any category. If an order's only HubSpot result is an Aircall ticket, treat it as having no HubSpot hit (i.e. it should go to supplier outreach).
+
+**CRITICAL — Informational-only tickets do NOT count as actionable hits.** Many orders have HubSpot tickets that are purely informational and do NOT indicate that the delay has been communicated to or acknowledged by the supplier. When an order's only tickets are informational, treat it as having no actionable HubSpot hit — it must go to supplier outreach.
+
+**Informational-only ticket types (ignore for categorization):**
+- **Supplier order confirmations** — e.g. "Order confirmation Showdown Displays", "Solo midocean Order confirmation", "Bestelling Ontvangen", "Auftrag … zu Bestellung", "Your Bullet Sales Order#", "O- 003-FSSE-…" (PF Concept), "Order … ontvangen voor klant" (Primex). These confirm the order was placed, not that the delay is being handled.
+- **Auto-generated "in production" / "being printed" emails** — e.g. "Your project is being printed", "Bestelling in Drukproces". These are automated supplier pipeline notifications, not responses to a delay inquiry.
+- **Shipping date expectation emails sent BEFORE the dispatch date passed** — e.g. "Verwachte verzenddatum", "Shipping date expectations", "BIC Graphic Confirmation: Your Shipment Date". These were sent at order acceptance, not in response to a delay.
+- **Auto-replies / out-of-office** — e.g. "Automatic reply:", "Out of Office".
+- **Proof/design sent emails** — e.g. "Bestel ontwerp", "Print proof update". These are part of the normal order flow, not delay communication. (Exception: if the proof is still awaiting approval and is blocking production, that IS actionable — categorize as "other_status".)
+
+**Actionable ticket types (DO count as real HubSpot hits):**
+- Delay explanations with reason (e.g. "delayed dispatch", "Vertraging:", "We're sorry, job X is delayed")
+- Artwork issues blocking production (e.g. "ARTWORK REFUSAL", "artwork query", new file needed)
+- Stock/production issues (e.g. "STOCK DIFFERENCE", "creation failed", "update failed", "retry attempt")
+- Internal Helloprint issues (e.g. "AutoCheck Declined", "Speed Up Request")
+- Complaint tickets (e.g. "Your complaint")
+- Any ticket where a human wrote about the specific delay or a problem with the order
+
+**Multi-ticket handling:** When an order has multiple tickets, apply this logic:
+1. Filter out Aircall tickets entirely.
+2. Classify each remaining ticket as either "informational" or "actionable" using the lists above.
+3. If ALL remaining tickets are informational → treat as no HubSpot hit → order goes to supplier outreach.
+4. If at least one ticket is actionable → use the **most recent actionable ticket** (by `createdate`) to determine the order's category.
+5. In the PDF report, show the primary (most recent actionable) ticket ID and note the total ticket count (e.g. "413360096501 (+2 more)").
+
+**CRITICAL — Supplier name sourcing:** When categorizing HubSpot results, ALWAYS use the `supplier_name` from the delay list order data — never derive the supplier name from the HubSpot ticket subject. Ticket subjects often reference sub-brands, parent companies, or intermediary names (e.g. "Oakdene" instead of "Solopress v2") which do not match the actual supplier on the order.
+
 ### HubSpot Search Strategy (MANDATORY — execute ALL 3 steps)
 
 The `hp_order_line_id` and `hp_order_id` fields in HubSpot frequently contain **multiple comma-separated values** in a single field (e.g., `"9155560, 9162986"`). IN/EQ filters only match when the field contains exactly one value, so they **will miss** multi-value fields. All 3 steps below are required — skipping step 3 consistently causes 10-20% of tickets to be missed.
@@ -213,10 +241,12 @@ Search tickets using `IN` operator on `hp_order_line_id` with batches of max 50
 **Step 2 — Batch IN-filter on `hp_order_id`**
 For all orders where NO hit was found in step 1: search tickets using `IN` operator on `hp_order_id` with batches of max 50 order IDs. Record which orders got a hit.
 
-**Step 3 — Individual full-text `query` search (DO NOT SKIP)**
-For every detail ID that STILL has no hit after steps 1 and 2: search tickets using the `query` parameter (not a filter) with the individual detail ID as search string. This finds tickets where the ID is embedded in a multi-value field. Do this for every remaining `id_order_detail`. If that returns 0, also try the `id_order`.
+**Step 3 — Individual full-text `query` search (DO NOT SKIP — execute for ALL orders)**
+Execute this step for **every** `id_order_detail` — including those that already had a hit in step 1 or 2. A step 1/2 hit may find a different ticket (e.g. an Aircall ticket or generic auto-created ticket) than the one containing the actual supplier communication. Multi-value `hp_order_line_id` fields (with 50-100+ comma-separated IDs) are common for bundled supplier emails and are only matchable via `query`.
 
-> **Why this matters:** In practice, ~15% of HubSpot tickets use multi-value fields. Without step 3, you will miss existing supplier communication and send unnecessary outreach emails for orders that already have a known status.
+For each `id_order_detail`: search tickets using the `query` parameter (not a filter) with the individual detail ID as search string. If that returns 0, also try the `id_order`. Merge all results from steps 1, 2, and 3 — do not discard earlier hits, but ensure the full picture of tickets per order is captured.
+
+> **Why this matters:** In practice, many supplier outreach emails reference dozens of orders in a single ticket with a multi-value `hp_order_line_id`. The IN filter cannot match these. Step 2 may find only tangentially related tickets (Aircall, auto-generated). Without step 3 on ALL orders, you will miss the actual supplier email thread and either miscategorize orders or send duplicate outreach.
 
 ### Supplier-Specific Handling
 
@@ -242,6 +272,8 @@ Before creating generic outreach emails, check if the supplier has a specific wo
 
 For all **remaining suppliers** (not covered by supplier-specific handling above), create drafts with emails per supplier so we can review them.
 
+> **CRITICAL RULE — No duplicates in outreach:** Before generating supplier outreach emails, EXCLUDE every order that already appears in a HubSpot category (Section 1) with an actionable ticket. Only orders with zero actionable HubSpot hits (including those with only informational tickets) should appear in the outreach email drafts. An order must never appear in both the HubSpot Analysis section and the Supplier Outreach section.
+
 > **CRITICAL RULE:** Bundle emails per supplier. Never create multiple emails to the same supplier. Group all delayed order lines for a supplier into ONE email.
 
 ### Email Template
@@ -347,7 +379,7 @@ Colour-coded tables categorising orders with existing communication:
 - **1.3 Other Statuses** (blue header) — shipped, awaiting approval, customer issues, unclear status.
 - **1.4 HubSpot Tickets Found — Review Needed** (orange header) — tickets exist but need manual review to determine action.
 
-Each table shows: Detail ID, Order, Supplier, Issue/Status.
+Each table has 4 columns: **Ticket ID** (the real HubSpot `hs_ticket_id`), **Order Detail ID** (`id_order_detail`), **Order ID** (`id_order`), **Details** (summary of the issue/status). The Ticket ID must be the actual HubSpot ticket identifier — do NOT use the `id_order_detail` as Ticket ID. When performing the HubSpot search, always store the returned `hs_ticket_id` alongside the matched `hp_order_line_id` / `hp_order_id` so they can be rendered correctly in the report. Use Paragraph flowables for the Details column to allow text wrapping.
 
 **Section 2 — Manual Action Required**
 - **Flyeralarm** — order table with note that portal case creation is required