Items flagged as incomplete or needing process setup:

1. Replenishment notification routine — resolved, see E-030

2. SNPS Clk adapter boards (HC3...) owner — technical owner not known; needs to be looked up.

3. What Jira Assets is used for — resolved, see E-031

4. Ticket workflow for CM spare consumption — resolved, see E-032

5. System transfer workflow — resolved, see E-033

6. CM stock count recipient list — resolved, see E-024

7. Inventory transaction recipient — resolved; covered by weekly inventory & transaction report (E-022)

Source file: ESIN-How We Operate the Support Agreement.pdf (Actions needed section)

Goal: make the support agreement fully operatable by anyone stepping in for Elsa.

All existing entries provide a solid foundation. The following specific procedures are missing and need to be written up (talk through with Claude to document them):

1. How to create the monthly report — template location, tool, step-by-step process — resolved, see E-037 2. How to create the weekly inventory & transaction report — same — resolved, see E-038 3. How to invoice Synopsys — where, format, what to include in the timesheet, where to send 4. How to track the hour bank — where it is recorded, what counts as dev hours vs support hours 5. How to measure SLA — where does time-to-response data come from, how is it calculated 6. Contract renewal reminder — scope review due ~2026-11-01 (90 days before SOW expiry 2027-08-01) 7. Maintenance process — set up and document the process for maintenance activities 8. Replenishment process update — review and update the existing replenishment process 9. Notification process for updated documentation — how and when to notify Synopsys when documentation is updated, who to notify, and through what channel

Once all of the above are documented, create a "Start here" entry that links everything in the right order for a new person picking up this role.

Approach: Go through each item one by one with Claude — describe how it works and Claude will write the entry.

Duplicate of E-040.

Duplicate of E-041.

Ownership: Synopsys owns all spare parts stock. Synopsys makes budget decisions.

Stocking model: E-Sharp holds consigned spare parts at E-Sharp HQ for fast repair turnaround and replenishment to CMs. E-Sharp also sets and manages safety stock levels at CMs.

Purchasing flows:

• E-Sharp-supplied parts: E-Sharp quotation → Synopsys PO → E-Sharp manufacturing → E-Sharp receives into consigned stock → E-Sharp invoices Synopsys
• 3rd party parts (e.g. Samtec, Kitron): E-Sharp requests quote on behalf of Synopsys → Synopsys PO, delivery to E-Sharp → Vendor manufacturing → E-Sharp receives into consigned stock → 3rd party invoices Synopsys directly

Source file: Support Agreement - Handling of spare parts.pdf; SOW Section 3.4

Trigger: Replenishment is recommended when projected stock falls below the defined warn level quantity in SharpMES.

Warn level calibration: Warn levels are set to cover approximately 3 months of consumption, which aligns with typical lead times (Kitron/Sanmina 10–12 weeks, Samtec 12 weeks). Raise a replenishment recommendation as soon as the warn level is hit — not after.

How it is communicated: Flagged items appear in the consolidated inventory report. Replenishment recommendations are sent alongside the month-end consumption report from logistics@esharp.se.

Notification must include:

• Item description and Synopsys part number
• Current stock level
• Recommended reorder quantity

Warn level adjustment: Levels are not fixed. As consumption data matures, individual part warn levels will be revised:

• High movers or critical parts → warn level raised
• Low consumption parts → warn level lowered

What Synopsys does with it: Bobby Bagnas confirms transactions on the Synopsys/SAP side. The recommendation should trigger Synopsys to raise a new PO (Ship in Place for E-Sharp-produced parts, direct PO for 3rd party).

Source files: ESIN-How We Operate the Support Agreement.pdf; SOP Consigned materials_final.docx

Weekly Excel report of all open SUP tickets plus tickets closed in the past 7 days, sent to Sharafali and his distribution list.

How it works

A Python script queries Jira via the REST API and generates an Excel file saved to Documents\Reports\SUP_Ticket_Aging_YYYY-MM-DD.xlsx. It runs automatically every Monday at 09:00 via Windows Task Scheduler (task name: "SUP Ticket Aging Report"). The PC must be logged in.

Script location

C:\Users\ElsaRhodin\Documents\Claude\ticket_aging_report.py

Report columns

Colour coding

• Red — Waiting for Synopsys action (Waiting for Customer / Waiting for Ops)
• Yellow — E-Sharp owned, open > 7 days
• White — E-Sharp owned, open ≤ 7 days
• Grey — Closed or resolved this week

Time calculation

All time is measured in calendar days (date boundaries in Stockholm time). Weekends and holidays are not excluded — a ticket open over a weekend counts those days.

To run manually

Open Command Prompt and run: python "C:\Users\ElsaRhodin\Documents\Claude\ticket_aging_report.py"

To adjust thresholds or columns

Edit the script directly. Key config variables are at the top of the file under # Configuration. The yellow highlight threshold is controlled by the > 7 check in write_excel().

Automated internal comment posted on E-Sharp-owned SUP tickets that have had no E-Sharp agent activity for 2+ calendar days (weekends included), reminding the assignee to take action.

How it works

A Python script runs every day at 09:00 via Windows Task Scheduler (task name: "SUP Stale Ticket Reminder"). It checks all open, E-Sharp-owned tickets and posts an internal Jira comment if the ticket has been inactive long enough. The PC must be logged in.

Script location

C:\Users\ElsaRhodin\Documents\Claude\stale_ticket_reminder.py

Reminder logic

• First reminder: posted after 2 calendar days of no E-Sharp activity (weekends count)
• Follow-up reminders: posted every day after, as long as the ticket remains inactive and E-Sharp-owned
• Activity that resets the timer: external (customer-visible) comment by an @esharp.se agent, or a status change by an @esharp.se agent
• Internal comments do not count as activity (including the automated reminders themselves)
• Skipped if: ticket status is "Waiting for Customer" or "Waiting for Ops" (Synopsys-owned)

State and log files

• State (tracks last reminder per ticket): Documents\Claude\stale_reminder_state.json
• Log (what ran and when): Documents\Claude\stale_reminder.log

To run manually

Open Command Prompt and run: python "C:\Users\ElsaRhodin\Documents\Claude\stale_ticket_reminder.py"

To adjust thresholds or message text

Edit the script. Key settings at the top under # Configuration:

• FIRST_REMINDER_DAYS — calendar days before first reminder (currently 2)
• FOLLOWUP_REMINDER_DAYS — calendar days between follow-ups (currently 1)

Message text is in the first_reminder_text() and followup_reminder_text() functions.

Decision

Tickets in status Pending or Replenishment process are not actively owned by any party — neither E-Sharp nor Synopsys is expected to take a next step while the ticket is in these statuses.

Impact on tooling

Ticket Aging Report (ticket_aging_report.py) — runs every Monday at 09:00

• Next Step Owner column shows — (dash) for these tickets instead of "E-Sharp"
• Row is highlighted in light blue to visually distinguish from E-Sharp-owned (white/yellow) and Synopsys-owned (red) tickets
• Legend updated to include: Blue = No active owner (Pending / Replenishment process)

Stale Ticket Reminder (stale_ticket_reminder.py) — runs Monday & Friday at 09:00

• Tickets in Pending or Replenishment process are skipped unless they have been in that status for 7+ calendar days
• After 7 days, the normal reminder logic applies — to catch tickets that are silently stuck

Rationale

These statuses represent a waiting state with no clear action owner:

• Pending — waiting on an external factor or decision not yet assigned
• Replenishment process — a replenishment order has been initiated; the process is running and no internal follow-up is expected until it completes

Reminding or flagging these as E-Sharp-owned would create noise and mislead the aging report.

Legend: Owns = accountable for the outcome | Does = executes the task | Notified = kept informed

1. Issue Intake & Ticket Management

2. Technical Debugging & Resolution

3. Spare Parts — Consumption at CM

4. Spare Parts — Shipping & Logistics

5. Inventory Management

6. Replenishment

7. Reporting

8. Meetings

9. Change Management

Known gaps / open items

• SNPS Clk adapter board technical owner — E-009 lists this as unsure for HC3 clock adapter boards. Needs to be confirmed before sharing externally.
• Agistix booking for CM spare swap returns — process not yet fully defined (who books transport when a CM returns a broken part).
• Jira Assets station status — not consistently maintained (E-031). Agreement needed on whether CMs are responsible for keeping this up to date.

Decision

SSJ is expected to deliver one or a few general maintenance documents covering all Harmonix testers — not test fixture-specific documentation. If SSJ wants fixture-specific documents, they must write those themselves.

Exception: If Sharafali instructs otherwise, defer to his direction.

Requirements for the documents SSJ provides

• Must cover all Harmonix testers (general scope, not per-fixture)
• Must list all test boards/modules currently in use

Source

Email from Jerry Miller (SSJ) — clarification communicated to SSJ by Elsa Rhodin.

Rejected alternative

SSJ writing test fixture-specific documents as part of their deliverable — rejected unless Sharafali overrides.

Used when a critical support call requires immediate management notification.

Source file: Stand-by-support.pdf

Who to assign tickets to per product/test type:

Source files: Stand-by-support.pdf; ESIN-How We Operate the Support Agreement.pdf

During call — identify:

1. Where are they calling from?
2. Who is calling?
3. Which test station(s) is affected?
4. Does any station of that type work? Ask them to test with a working DUT before escalating.

Non-critical (line not down):

• Direct them to use working stations
• Ask them to create a ticket in the help center
• Ask them to prepare station for debugging (working DUT + serial number, IP address, note on station)
• Inform that action will be taken first thing in the morning

Critical (line is down):

• Attempt resolution if within your knowledge
• Create / ask them to create a ticket
• Prepare station for debugging (same as above)
• Escalate to management immediately by phone/message
• Note caller's phone number

After call:

• Open ticket and assign to correct owner (see Technical Owners entry)
• Ensure assignee is informed and acts ASAP
• Update customer on progress

Source file: Stand-by-support.pdf

If someone emails you directly about a problem: Refer them to the service portal, or create a ticket on their behalf.

Ticket workflow:

1. Customer registers an issue via email or support portal
2. Elsa monitors incoming tickets and changes status from "To Do" → "Open"
3. Elsa finds the right person and assigns the ticket (assignee receives email notification)
4. Once you start working: set status → In Progress (sends notification to the requester)
5. Reply via comments in the ticket. Internal notes are also available (only visible internally)
6. Option to add yourself as a watcher

Source file: Support Channels/Ticket Support/Lathund ticketsystem.docx

All reports sent from logistics@esharp.se.

Monthly report — sent at start of each month (set Outlook reminder)

• Content: KPI (station uptime), SLA (time to first response), support hours & development hour bank, action tracker
• Recipients: Huy Tran, Jerry Miller, Zachariah Ponnal, Tom Chappron, Sharafali Shaherwalla, Brian Brennan
• ⚠️ How-to instructions not yet imported — add the step-by-step guide from Confluence

Weekly inventory & transaction report — sent every first working day of the week

• Content: transaction log + consolidated inventory report
• Note: Per Bobby Bagnas' request, filter out Sanmina/Kitron in consolidated inventory report
• Include manufacturer name in the "parts" report (in MES)
• Recipients: haps_buyers@synopsys.com, inventoryteam@synopsys.com, Curtis Lindholm, Sharafali Shaherwalla, Jerry Miller
• Bobby Bagnas responsible for confirming each transaction on the Synopsys/SAP side
• ⚠️ How-to instructions not yet imported — add the step-by-step guide from Confluence

Consolidated month-end report — sent at end of each month

• Also include: E-Sharp replenishment recommendations (process needs to be formalised)

Source file: ESIN-How We Operate the Support Agreement.pdf

When E-Sharp receives an order confirmation from Synopsys:

1. Create a part order in the inventory system
2. List all parts that will arrive (based on the packing list)
3. In the comment section, enter the ETA and any shipping info
4. Set the order line status to In Progress
5. Mark the part order as Consigned and/or add the Agistix number / other shipping numbers

When consigned parts arrive:

1. Verify items against the delivery documentation (packing list)
2. Register items in the inventory system by completing the corresponding part order
3. Place items in the designated customer-specific storage area
4. Scan the packing list and notify the customer of received items including quantities and any discrepancies
   • Send email from logistics@esharp.se to: inventory-team@synopsys.com, haps_buyers@synopsys.com

Source file: ESIN-How We Operate the Support Agreement.pdf

Parties: Synopsys, Inc. (Sunnyvale CA) and E-Sharp Software Solutions AB (Kävlinge, Sweden). Effective 2025-08-01, signed 2025-07-23 (SNPS) / 2025-07-19 (E-Sharp).

Term: 2 years (~expires 2027-08-01). Review scope 90 days before expiry. Extension requires written amendment.

Compensation: $19,000 USD/month (excl. taxes). Total cap: USD $421,800. 30% discount first 6 months (setup phase). 50 hrs/month dev bank; carry forward up to 3 months. Travel reimbursed if pre-approved in writing.

Covered test stations: BOA6 Power Input Board, BOA6 Panel ×3, BOA12 IO, BOA12 AUX & Back panel, BOA12 QSFP, AB/Stack (BOA Assistant + BOA6/12 FPGA Stack), BOA6 Control board 0&1, B6 HT3, B6 HT3-Co, B6 Back panel, B12 Control board 0&1, HC3-2xHC2 HT3-HC3x4

SLA:

• Email/Ticket response: 4 hrs | Telephone: 10 min | Debugging session: 2 working days
• HMA response: 4 hrs | Repair resolution: 1 week (receipt → ready-to-ship)
• Scheduled on-site visits: 1/year per CM (travel not included)
• Ad-hoc on-site: Europe 48 hrs, America 1 week
• Critical bug fix: 1 working day | Non-critical bug fix: 4 weeks

KPI: Station uptime ≥90% avg during first 6 months. Target after 6 months to be agreed.

Bug severity:

• Critical: system crash, data corruption, security vulnerability, incorrect measurements, comms failure
• Non-critical: UI issues, performance lags, logging errors, cosmetic issues

Support hours: Mon–Fri 09:00–21:00 CET | Sat–Sun 13:00–21:00 CET | Closed Swedish public holidays

Source file: SOW Support Agreement.pdf

What it's for: Jira Assets is used to track test station metadata — location, IP address, serial number, station type, status (Up / Down / Limited). Asset records can be linked to support tickets for context, and station status can be updated manually.

Current status: Not fully implemented in day-to-day operations. Station status must be reported manually — there is no automated status feed. As a result, Assets is not yet consistently used in the ticket workflow.

Potential value: If station status were kept up to date in Assets, it would improve ticket context and make it easier to calculate uptime KPI without relying solely on manual reporting.

Scope: CM personnel performing repairs, maintenance, or troubleshooting on Synopsys PCBA test stations. Use this procedure every time a spare part is taken from the E-Sharp spares cabinet.

Procedure:

1. Identify the required part

   • Confirm the part is needed for a Synopsys PCBA test station
   • Verify correct part name and part numbers (E-Sharp and Synopsys)
   • For complex errors or uncertainty: create a support ticket and involve E-Sharp in debugging before consuming a spare

2. Create a help center ticket

   • Open a new ticket at the E-Sharp help center (ticket type: Report spare part swap), or send an email to logistics@esharp.se
   • Include: station name, reason for using the spare (or reference an existing ticket), part consumed (Synopsys/E# P/N) and quantity
   • ⚠️ Without a ticket, E-Sharp will not send a replacement for the consumed part

3. Retrieve the spare part from the E-Sharp spares cabinet

4. Install the part

5. Scrap or return the broken part — follow E-Sharp instructions in the ticket

Rules:

• Spare parts are strictly for Synopsys PCBA test station repairs only
• Do not use, borrow, or remove parts for any other purpose
• Every usage must be logged — no exceptions
• Parts must remain in their labeled bags until installation

When it happens: The inventory move is recorded in SharpMES at the time of shipment — not when the CM confirms receipt.

What to do:

1. When items are shipped to a CM, move the stock in SharpMES from the E-Sharp location to the relevant CM location (Kitron or Sanmina)
2. When the CM confirms receipt, compare their received quantities against what was recorded in MES
3. If there is a discrepancy (e.g. CM received one fewer than recorded), adjust the MES record manually to match the confirmed received quantity

Why: Keeps MES aligned with physical stock at CMs and ensures the inventory reports sent to Synopsys are accurate.

All Synopsys-owned consigned inventory must be:

• Stored in a clearly marked, customer-specific area separate from E-Sharp's own stock
• Kept clean, organised, and accessible at all times

Source file: SOP Consigned materials_final.docx

Purpose: Monthly report sent to Synopsys covering the past month's support agreement performance. Sent at the start of each month from logistics@esharp.se (see E-022 for recipients).

Report contains: KPI (station uptime), SLA (time to first response), development hour bank, action tracker.

1. Start from last month's report

1. Make a copy of last month's report — found at: Delad/projekt/synopsys/support agreement/monthly report/[year]
2. Name it: Monthly report - [Month] [Year]

2. KPI — Station uptime

Definition: Average number of stations in status "Working" or "Minor faults" divided by total number of test stations. The average over a period = sum of daily uptimes ÷ number of days.

Steps:

1. Keep track of stations that were/are down during the month
2. Calculate uptime for Sanmina and Kitron separately, then combined for total
3. Calculate using Copilot or manually
4. Use the Excel file KPI file.xlsx
5. Paste result as image into the PowerPoint

3. SLA — Time to first response

Steps:

1. Go to Jira Service Management
2. Choose the Synopsys support space
3. Click Reports
4. Choose Synopsys Support SLA report
5. Filter for the past month — set Show: Custom range, period: daily
6. Click Export CSV (via the ··· menu → Export CSV)
7. Open the CSV — check the support queue manually to match SUP cases to the correct SLA row
8. Delete rows that don't have a ticket tied to them
9. Apply conditional formatting: < 4 hours → green fill, > 4 hours → red fill
10. Update the column header to read: Time to first response - Met (Measured in Hours:Minutes)
11. Copy as picture and paste into the PowerPoint

4. Development hour bank

Before starting: Double-check that everyone has entered their hours. Notify the team that the time extract is about to be done so all figures are correct.

Steps:

1. Go to Clockify
2. In the menu, click Reports
3. Select Detailed report
4. Under Project filter, select Synopsys Support Agreement → click Apply
5. Set the time interval to the month being reported
6. Click Export → Customize (verify settings look correct)
7. Click Export → Save as Excel
8. Open the exported Excel file and copy the content (not the headers)
9. Open the existing file: Synopsys Support Monthly Report (found under shared/project/synopsys/support agreement)
10. Select the cell at the bottom left under the table
11. Paste the data (Ctrl+V) — the "period" column should auto-update to the correct year/month
12. Go to the Summary sheet
13. Click one of the PivotTables → PivotTable Analyze → Refresh → Refresh All
14. Verify the information looks correct and hours are logged for the right month
15. In the PowerPoint, show only the relevant month's breakdown, and for the development hour bank section show the last three months
16. Paste as image into the PowerPoint

5. Action tracker

Write down current actions and their status for the project (e.g. ongoing repairs, service trips, documentation work).

Source file: ESIN-How to create monthly report-030626-071909.pdf

Purpose: Sent every Monday from logistics@esharp.se to Synopsys (see E-022 for recipients). Contains three attached reports.

Save location: delad/projekt/synopsys/support agreement/weekly inventory and transaction report/ — create a new subfolder named with the date range for each report.

1. Consolidated inventory report

1. Go to SharpMES → Parts Viewer → Inventory
2. Filter on consignee: Synopsys
3. Enable Show zero quantity rows
4. Filter on location: select all except Sanmina and Kitron
5. Press "Save consolidated report"
6. Save to the folder above

2. Transaction log

1. Apply the same filters as the consolidated inventory report
2. Press "Save transaction report" — save to the same folder
3. In the report, filter:
   • Transaction date: previous week only
   • Status: Completed
4. Keep only these columns:

3. Parts report

1. Go to SharpMES → Parts Viewer → Parts
2. Filter on consignee: Synopsys
3. Add the Manufacturer column
4. Filter on warn level quantity: Greater than 0
5. Press "Save list to file"
6. Remove columns that are completely empty or not relevant to the customer

4. All reports — formatting

• Save all three as XLSX
• Make them easy to read: headers in bold, column widths adjusted

5. Send the report

Send from logistics@esharp.se with the three files attached. Use this email body:

Hi all,

Please find attached the weekly inventory and transaction report for last week (Month date–date).

The three reports included are: Transaction log: All transactions made during the past week. Consolidated inventory: Current stock levels for Synopsys consigned material. Please note that stock levels at Sanmina and Kitron are not included in this report. Parts: All parts included in the spare parts program.

If you have any questions, please feel free to reach out.

Source file: ESIN-How to create inventory and transaction report-030626-071945.pdf

Share the background data and math for station uptime calculations with Sharafali and his engineering team for review and reconciliation.

Owner: Elsa Rhodin Action by: Daniel Hansson

Create and share a list of spare parts indicating which are tested, not tested, and pass-through, for use by test engineering teams.

Owner: Elsa Rhodin Action by: Daniel Hansson

Send a weekly report listing open tickets, days aging, E-Sharp owner, Synopsys owner, CM owner, issue description, and next steps to Sharafali and his distribution list.

Owner: Elsa Rhodin Action by: Daniel Hansson, Daniel Rhodin

From bi-weekly meeting 2026-06-04.

Huy Tran raised a concern about a shipment with a tracking number still showing as being in Fremont. Elsa to check whether it was delivered and report back.

Context: Delays are occurring due to tariff issues and metal content reporting requirements.

From bi-weekly meeting 2026-06-04.

One set of loopback boards has completed testing and is ready. Additional sets are pending. Decision needed on whether to send the available set or wait for additional sets to complete testing before shipment.

Estimated earliest delivery ~1.5 weeks from shipment date.

Update 2026-06-09: Decision still pending — answer expected by end of day 2026-06-10.

Update 2026-06-16: 2 sets shipped to Sanmina. Remaining sets to be shipped as soon as they are built — no hold, ship immediately when ready.

From bi-weekly meeting 2026-06-04.

Halo test has disabled tests and IT problems with Ethernet ports. Mikael to sync with Andreas to clarify the current status and outstanding issues before the R1.0 release note is finalised.

From bi-weekly meeting 2026-06-04.

Ticket 124 involves ongoing Accordion board failures, specifically an MPIO module not being recognised. Jerry is extracting GPIO/MPIO modules from failed boards for reuse. Mikael to respond in the Jira ticket with advice on how to debug and next steps, using serial numbers and golden units to track and isolate suspect boards.

From bi-weekly meeting 2026-06-04.

Ticket 125 (CD zero issue) — cable replacements have been tried. Jerry to monitor the 3.3V rail during the CD zero test to check for voltage fluctuations or dropouts. Findings to be documented in the support case notes. Martin (Mikael's contact) may provide further input.

From bi-weekly meeting 2026-06-04.

Elsa provided guidance on marking return shipments for repair using specific HTS and ECCN codes to streamline customs handling. The updated return for repair shipment guide needs to be linked in the portal so all participants can access the new customs handling instructions.

Full contact list for the Synopsys support agreement.

E-Sharp logistics mailbox: logistics@esharp.se — use for all outbound customer communication

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

The following system accesses are required to operate the Synopsys support agreement. Ensure anyone stepping into this role has all of these before starting.

• Jira Service Management (JSM) — admin access required
• Jira Assets — for test station asset tracking
• Jira — general project access
• Confluence — documentation access
• Help center — https://esharp.atlassian.net/helpcenter/synopsys
• logistics@esharp.se — shared mailbox used for all customer-facing logistics communication

Adding Your Email to Receive Ticket Notifications

1. Go to Jira Service Management
2. In the sidebar, choose the Synopsys space
3. Click the three dots → Space Settings
4. In the left sidebar: Automation
5. Find the automation "Elsa + Daniel R automatic email on created ticket"
6. Add your email address → Save

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

Safety Stock

Safety stock thresholds are set in cooperation with E-Sharp's engineers, divided into E-Sharp and CM-specific levels. Thresholds are recorded in:

• Spare parts stocking proposals (OneDrive: Support agreement folder)
• Part descriptions in SharpMES — Warn level quantity field

Once stock drops below the Warn level quantity, the item is flagged in the consolidated report → E-Sharp recommends replenishment to Synopsys.

Warn Level Setting Rule

Set warn level to cover 3 months of usage so replenishment can be requested before stock runs out. Adjust warn levels over time if high-movers or stagnant parts are identified.

Lead Times

Replenishment Process

Recommendations are sent alongside the month-end consumption report. When recommending:

• Trigger: item appears in consolidated report (projected qty < warn level)
• If E-Sharp has an active order, ensure items needed are at E-Sharp — not CM location
• Recommend order quantities considering MOQ

Customer Notification

When an item reaches the reorder threshold, notify customer including:

• Item part number and description
• Current stock level
• Recommended reorder quantity
• "Deliver by" date

Send from logistics@esharp.se. Recipients: haps_buyers@synopsys.com, inventory-team@synopsys.com, Curtis Lindholm, Sharafali Shaherwalla, Jerry Miller.

CM Spare Part Swap Workflow

When a CM needs to replace a broken spare part:

1. A spare part is needed at the CM site
2. CM registers a ticket for spare swap
3. CM consumes spare from local CM stock
4. E-Sharp ships a replacement for the broken spare
5. CM receives replacement spare
6. CM returns or scraps the broken spare

Note: Booking of transportation in Agistix — process not yet fully defined.

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

At the end of each month, E-Sharp sends a consolidated inventory report to Synopsys to track monthly consumption.

Steps

1. In SharpMES, navigate to Parts Viewer
2. Select Inventory
3. Filter by Consignee: Synopsys
4. Generate the report — include stock at Sanmina and Kitron for accurate consumption tracking
5. Include E-Sharp replenishment recommendations if any parts have fallen below warn level (see E-058)
6. Send from logistics@esharp.se to the same recipients as the weekly inventory/transaction report (see E-022)

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

E-Sharp Warehouse — Full Stock Count

A full physical stock taking shall be performed every 3 months.

Monthly cycle counts during the first 3 months after the start of inventory handling, or after major changes (no fixed date required).

• Notify inventory-team@synopsys.com from logistics@esharp.se at least 1 week before it takes place
• Preferably mention it in the weekly report beforehand

Steps:

1. Gather list of all Synopsys consigned parts stored at E-Sharp warehouse
2. Perform physical count
3. Compare results to system records
4. Investigate any discrepancies
5. Report results to customer; re-count if requested
6. Adjust system records after customer approval

CM Sites — Stock Count (No Fixed Dates)

Send from logistics@esharp.se with an inventory report for the CM location:

1. Export the inventory report for the CM location from SharpMES
2. Remove any unnecessary information from the file
3. Add an extra column: Actual Qty
4. Send to the relevant recipients below and ask them to fill in actual quantities

Kitron:

• ManujaNB.Harasgama@synopsys.com
• Erik.Boris@kitron.com
• marcus.warhag@kitron.com

Sanmina:

• Alex.Tran@synopsys.com
• Jerry.Miller@synopsys.com
• huy.tran@synopsys.com
• Zachariah.GeorgekuttyPonnal@synopsys.com (CC)

After receiving results:

1. Compare results and correct stock levels in SharpMES
2. Replenish if needed

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

First Batch Shipments — Attention To

• Kitron: Attn: Erik Boris / Marcus Wårhag
• Sanmina: Attn: Abner Chavez

Process

When a partner requests spare parts:

1. Confirm the request via the ticketing system
2. Pick and pack per internal logistics guidelines:
   • Pack items individually in plastic ESD bags where possible
   • Print a label and attach to each bag containing:
     • "E-SHARP SPARE PART — For use in Synopsys PCBA Test Stations only"
     • Part Name
     • Manufacturer P/N
     • E-Sharp P/N
     • Synopsys P/N
3. Ship using Agistix
4. Record the shipment in SharpMES — move inventory from the E-Sharp location to the CM location
5. Notify customer of shipped items and quantities — send from logistics@esharp.se to haps_buyers@synopsys.com and inventory-team@synopsys.com
6. Add shipment details in Agistix once booked
7. Update the Jira ticket with shipment details once processed

Ship in Place PO

If the product being replenished is produced by E-Sharp, Synopsys will create a Ship in Place PO (items go directly into Synopsys consigned stock at E-Sharp).

After production is complete:

• Send packing list to haps_shipinplace@synopsys.com
• Send from logistics@esharp.se and include all weekly inventory report recipients (so they can register the transaction in SAP)

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

Bi-weekly Meeting — Synopsys Operations

30-minute check-in with Synopsys engineers (those who submit most tickets).

Agenda:

1. Go through open tickets and test station status
2. Follow up on action points (APs) from last meeting
3. Other open topics

After the meeting: send AI-generated notes and APs to all attendees on the meeting invitation.

Bi-weekly Meeting — Synopsys Inventory/Procurement

30-minute check-in on APs. Led by Jeanette Balentine.

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

Every Week

• Weekly inventory & transaction report (see E-038)
• Record every internal transaction, delivery, or shipment in real time and send to Synopsys
• Check warn levels / safety stock (see E-058)

Every Other Week

• Bi-weekly meeting: SNPS Operations
• Bi-weekly meeting: Synopsys Inventory/Procurement team (led by Jeanette Balentine)

Every Month

• Monthly report (see E-037)
• Consolidated inventory report sent at month end (see E-059)
• Replenishment recommendations sent with month-end report (see E-058)

Source: ESIN-How We Operate the Support Agreement at E-Sharp-090626-110109.pdf

Summary

Jeanette (Balentine), Bobby (Bagnas), and Elsa Rhodin met to discuss the process for identifying and recommending disposition actions for old inventory acquired from R&D that is not on consignment.

Key points

• Scope: Old inventory acquired from R&D, not on consignment — needs review for potential disposition (scrapping or relocation).
• Data source: Inventory data is already available through the consolidated weekly reports, which include stock levels and consumption data over 7, 30, 90, and 365-day time frames — sufficient to identify unused or obsolete items.
• Manual verification required: Before making disposition recommendations, Elsa will perform a manual check to confirm that flagged items are not required for ongoing projects (e.g. building test stations).
• Disposition definition: Scrapping or sending items elsewhere. Elsa's team provides recommendations based on knowledge of inventory usage; Sharafali's team makes the final call.
• Scrap process: Jeanette requires proof of destruction per company policy. Elsa to investigate whether a scrap company relationship exists at E-Sharp.
• Timeline: Elsa delivers proposal by Monday → Jeanette/Bobby internal review with Sharafali → follow-up meeting with Elsa in two weeks to finalise.

Action items

Bi-weekly meeting — 2026-06-18

Attendees: Elsa, Mikael, Huy, Jerry

Loopback Board Stock and Maintenance Workflow

• Two sets of loopback boards have been sent to Sanmina; a third set ships next week alongside the AB stack and B6 control. More sets are on order for preventative stock.
• Mikael proposed revising safety stock from 4 to 6–8 boards to buffer against lead times and frequent failures. Huy agreed: at least 4 sets should always be available on-site.
• Decision: Increase safety stock target to 6 sets at Sanmina.

Board Repair and Component Replacement

• Huy replaced a burned component on a loopback board using parts sourced from a board provided by Jerry. Two boards fixed; remaining boards await replacement parts.
• Root cause: a system board caused the component to burn on the loopback board.

Formal Rework and Scrapping Agreement

• Jerry proposed a formal agreement: bad boards are sent for testing and repair; scrapping decisions are communicated back.
• Decision: Mikael agreed to implement this workflow.
• Jerry recommends asset-tagging loopback boards to support financial tracking and write-offs at scrap. To be discussed with Shriv Ali and integrated into the workflow.

Technical Issues

MPIO Recognition Issue

• A machine failed to recognise an MPIO on the loopback board; ATB board suspected as root cause.
• Huy requested a new ATB board for verification. Mikael and Elsa discussed building and sending a new complete ATB board assembly.

I2C Communication Failure

• Huy reported an I2C error. Mikael noted the issue could be widespread due to the protocol's pervasiveness; advised checking error codes and logs before raising a ticket.

CD0 Test Voltage Monitoring

• Martin wrote a voltage-monitoring script for channel voltage during memory transceiver tests; deployment blocked by InfoSec restrictions.
• Jerry proposed integrating the script into a debug sequence to enable deployment without internet access.

Follow-Up Actions from Previous Meeting

Holidays

• Sweden: Midsummer — support closed, resumes Monday 2026-06-23.
• US: Juneteenth — most staff back Monday 2026-06-23.

Follow-Up Action Items