PendingUsecases

# PIX Technical Unit Error Monitoring — and bundled SAP health-check routines

Each working day this automation checks the BMW **PIX** file-transfer application for transfers that failed between BMW central and its dealers. For every error found it looks up which dealer and which country support group own that Technical Unit (TU), pulls the standard explanation for that error code out of a Word template, and emails the explanation to the dealer with the support group copied — so dealers can fix their own transfer failures without an analyst triaging each one. The same release file also contains three unrelated routines that were built by the same team and shipped together: daily SAP basis health checks for the **NMS** system, the same checks for the **ATLAS** systems, and a material-master discrepancy extract that is uploaded into MQS-Production through Citrix.

Treat the PIX routine (stages 1–9) as the main process. Stages A, B and C are separate jobs with their own start points; they share no data with the PIX routine.

## At a glance

| | |
|---|---|
| **Trigger** | Not recorded in the source. The PIX process begins by logging into PIX and searching errors from a supplied **From Date** (stored default `02.02.2017`), so it is either scheduled or started by hand with that date set. Stages A, B and C are independent start points with no trigger recorded. |
| **Frequency** | Not recorded directly. The SAP routines contain a date helper — "if today is Monday use Friday's date, otherwise use today's date" — which implies those run every business day and report on the previous working day. |
| **Systems used** | PIX (Technical Unit / file-transfer web application); Microsoft Excel; Microsoft Word; Microsoft Outlook desktop; SMTP relay `ind.smtp.accenture.com` port 25; SAP GUI (NMS system `NRP`; ATLAS systems `AEP`, `AAP`, `AWP`); Citrix / MyNetwork portal `http://vtpep.muc/` |
| **Inputs** | PIX credentials (user `navisione`); From Date; PIX on-screen error table (columns include **PartnerTU** and **ErrorNo**); `C:\BluePrism\data\PixTUMonitoringLogs\PIX_Dealer_Info.xlsx`; `C:\BluePrism\data\PixTUMonitoringLogs\PIX TU Error Log Monitoring Template.doc`; `C:\BluePrism\data\PixTUMonitoringLogs\MailList.xlsx`; SAP and Citrix credentials (see *Before you start*) |
| **Outputs** | One email per actionable dealer error, subject **"PIX TU Error Description"**, to the dealer with the country support group in CC; a fallback email to PIX Support where no description text was found; the de-duplicated working file `Error_Code.xlsx`; a completed/exception audit trail on the **PIXTUMonitMailSend** to-do list; SAP export spreadsheets in `C:\BluePrism\data\SAP_NMS\` and the ATLAS equivalents; `Parts.txt` uploaded to MQS-Production |
| **Typical run** | Not recorded in the source — no volume figures for PIX error rows or emails sent. |
| **Owner** | Not recorded in the source. Hard-coded paths and the sender address point at one developer's machine (`s.jyothi.avadhanam@accenture.com`, desktop folders under `C:\Users\s.jyothi.avadhanam\`). |

## Before you start

**Access and credentials.** Every password below is blank in the source — obtain them from your credential store before running anything.

| System | Account | Notes |
|---|---|---|
| PIX application | `navisione` | Password supplied at run time |
| SAP NMS, system `NRP` | `qx68203` | Used by stage A |
| SAP ATLAS `AEP` / `AAP` | Not recorded | Used by stage B |
| SAP ATLAS `AWP` | `qxl3498` | Used by stage B |
| SAP ATLAS `AEP` for SE16N extract | `QXI4826` | Used by stage C |
| MyNetwork / Citrix portal `http://vtpep.muc/` | `qxp5286` | Used by stage C |
| SMTP relay | `s.jyothi.avadhanam@accenture.com` on `ind.smtp.accenture.com:25` | Sender address for the PIX mails |

**Files that must exist and be current.**

| Path | Purpose |
|---|---|
| `C:\BluePrism\data\PixTUMonitoringLogs\PIX TU Error Log Monitoring Template.doc` | Word document holding the standard text for each error code, marked up with `Error Code <n> Starts` … `Error Code <n> Ends` blocks |
| `C:\BluePrism\data\PixTUMonitoringLogs\PIX_Dealer_Info.xlsx` | Dealer and support-group email addresses, looked up by country code |
| `C:\BluePrism\data\PixTUMonitoringLogs\MailList.xlsx` | Read by the Outlook send routine; how the result is used is not visible in the source |
| `C:\BluePrism\data\PixTUMonitoringLogs\Error_Code.xlsx` | Working file the bot overwrites each run — no need to pre-create, but do not have it open in Excel |
| `C:\BluePrism\data\SAP_NMS\` | Target folder for NMS export spreadsheets (stage A) |
| `C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Descrepancy_Check.bat` | Batch job that produces `Descripencies.csv` (stage C) |

**System state.** Excel and Word must be installed and closable by automation — the bot opens and quits its own instances. For the Outlook send path, Outlook must already be running with a window titled `*- Outlook`. For SAP, the SAP Logon front end must be installed with the relevant system entries visible in the selection list. For stage C the Citrix session window titled `MyNetwork *` must already be open before the Citrix login step runs.

**Note on the two email paths.** The release contains two send mechanisms wired to two versions of the same page: an SMTP send and an Outlook desktop send that types into the mail window and pastes the body from the clipboard. Which one is live in production is not stated in the source. Confirm before you run, because the Outlook path will visibly take over the desktop.

## Procedure

### Stage 1 — Log into PIX

1. Launch the PIX application and wait up to 5 seconds for the login dialog.
2. Once that wait has elapsed (in the source the credential entry follows the wait's timeout branch), click the **UserName** field and type the user name (default `navisione`).
3. Click the **Password** field and type the password.
4. Click **Ok**.
5. **If anything in the login step throws an error — launch failure, missing dialog, a field that cannot be typed into — then** the bot closes the PIX application and the run resumes past the login step (see *Exceptions*). Note the bot does not treat the 5-second wait expiring as a failure in its own right; termination is driven only by an exception raised somewhere in the login block.

### Stage 2 — Search the error log from the given date

1. Wait for PIX to settle (up to 10 seconds), then click the **Error Log** tab/link on the page.
2. Work out the date to search from. The source performs a calculation named *Get Todate* immediately before typing the date; **the rule inside that calculation is not visible in the outline**, so treat the effective From Date as unverified. The stored default is `02.02.2017`, which is plainly stale.
3. Type the From Date into the search field.
4. Click **Search** to list matching errors.

### Stage 3 — Capture and de-duplicate the error list

1. Read the whole error table off the PIX results page into a list. Relevant columns are **PartnerTU** (the Technical Unit) and **ErrorNo** (the error code); the full column layout is not recorded.
2. Create a new Excel workbook, write the error list starting at cell **A1** of the first worksheet, and save it as `C:\BluePrism\data\PixTUMonitoringLogs\Error_Code.xlsx`. Excel is then closed.
3. Re-open `Error_Code.xlsx` and run the built-in **RemoveDuplicates** routine over it, then save. This is what turns a raw error dump into one row per distinct dealer error.
4. Read the cleaned sheet back in as the working error list for the rest of the run.

### Stage 4 — Load the errors into the mailing queue

1. Add every cleaned error row to the to-do list named **PIXTUMonitMailSend** (a Blue Prism work queue — a simple shared list of rows the bot works through one at a time, each row carrying a status and an attempt count).
2. Take the next pending row off **PIXTUMonitMailSend**.
3. **If no row comes back (the queue is empty), then** skip forward to stage 9 and close PIX. **If a row comes back, then** continue to stage 5.

### Stage 5 — Filter to actionable errors

For each error row the bot checks:

> `[PartnerTU] <> " "` **AND** `Len([ErrorNo]) = 4`

1. **If the Partner TU is populated and the error number is exactly four digits, then** continue to stage 6 for this row.
2. **If not, then** the row is not processed further inside the loop — no dealer email is produced for it.

### Stage 6 — Identify the dealer and support group for the TU

1. In PIX, click **Search Technical Unit**.
2. Type the TU number from the current error row.
3. Click **Search**.
4. Read the **country code** currently selected on the resulting screen.
5. Open `C:\BluePrism\data\PixTUMonitoringLogs\PIX_Dealer_Info.xlsx` and read it in full.
6. Match the country code against that file to obtain two addresses: the **dealer email** (used as *To*) and the **support group email** (used as *CC*). The exact matching rule inside the lookup code is not visible in the source.

### Stage 7 — Build the error description from the Word template

1. **If a dealer email was found (To is not empty), then** continue. **If not, then** the dealer mail is not sent and the fallback path applies (stage 8, step 5).
2. Set the two marker strings for this error code, following the pattern seen in the source: `Error Code <n> Starts` and `Error Code <n> Ends` — for example `Error Code 100 Starts` / `Error Code 100 Ends`.
3. Open Word, show it, and open `C:\BluePrism\data\PixTUMonitoringLogs\PIX TU Error Log Monitoring Template.doc`. (An older copy of this file at `C:\Users\s.jyothi.avadhanam\Desktop\PIX TU Error Log Monitoring Template.doc` also appears in the source — confirm which is authoritative.)
4. Extract the block of text sitting between the two markers. That block is the mail body.
5. Close Word.
6. Insert the dealer number into the extracted description text.

### Stage 8 — Send the mail

1. Set the subject to **"PIX TU Error Description"**.
2. Send the extracted description as the body, **To** the dealer address, **CC** the country support group.
3. *SMTP path (used by the process-level version):* send from `s.jyothi.avadhanam@accenture.com` via `ind.smtp.accenture.com` port 25. The relay must be configured first or the send raises a configuration error.
4. *Outlook path (used by the older object version):* attach to the running Outlook window, click **Home → New Email**, type the To, Subject and CC, click into the body, copy the description to the clipboard and paste it with `Ctrl+V`, then press **Send**. Each field is checked for existence first and a named exception is raised if it is missing.
5. *Fallback where no description was found:* the source contains a prepared body addressed to PIX Support:

   > Dear PIX Team,
   > We couldn't find proper error description for the below Error Code of TU number.
   > TU Number: [TU]
   > ErrorCode: [ErrorCode]
   > Please process this request.
   > Regards,
   > RPA Team

   The TU number and error number are substituted in and the recipient is set by a calculation named *Send To - PIX Support*. **The content of that calculation — i.e. the actual PIX Support address — is not visible in the source, and these fallback steps sit off the main flow, so it is ambiguous whether they fire automatically for every unmatched row.** Verify this manually.

### Stage 9 — Close out the row and the application

1. Mark the current **PIXTUMonitMailSend** row **Completed**.
2. Terminate the PIX application and end the run. The outline shows a single pass — take next row, extract and send, mark Completed, close PIX, end — with no return to "take the next pending row". **Whether the flow loops back to work further queue items is therefore not visible in the source.** The per-row iteration that *is* visible is the collection loop inside "Extract Data from Template" (stages 5–8), which walks every row of the error list that was handed to it.
3. If you need to confirm the queue was fully drained, check **PIXTUMonitMailSend** after the run for rows still pending.

---

### Stage A — (Separate routine) NMS SAP daily health check

1. Log into SAP system **`NRP`** as **`qx68203`**: launch SAP Logon, select the system from the list, type user and password, click **Ok**. Acknowledge any system-message popup with **Ok**.
2. **If SAP reports "Already Logged In", then** the bot closes SAP and stops the run — no checks are performed. **If not, then** continue.
3. Load the transaction-code list into the to-do list **NMSWorkQueue**. *The actual list of codes is held in a data item with no visible value in the source.*
4. Take the next code off **NMSWorkQueue** and run the matching routine. Recognised codes: **ST22, SM66, SM12, SM13, SMQ1, SM21, SM37, SM58, BD87, AL11, SP01**. Anything else falls through the "otherwise" branch with no action.
5. Each routine follows the same shape: enter the transaction code (written as `/nst22`, `/nsm12` etc.), fill the selection screen, execute, then export the result list via **System → List → Save → Local file**, choose **Spreadsheet**, click **OK**, type the target directory `C:\BluePrism\data\SAP_NMS\`, type the file name, and click **Replace** to overwrite the previous day's file.
6. Date range for the date-driven transactions comes from a helper: **if today is Monday, use Friday's date; otherwise use today's date.**
7. Standing selection values seen in the source:

   | Transaction | Field values used |
   |---|---|
   | SM12 | Table name `*`, Lock argument `*`, Client `010`, User name `*` |
   | ST22 | User `*`, with **Exception**, **Program Affected** and **Program Components** ticked; From/To date from the date helper |
   | SP01 | Created by `*`, created From/To from the date helper, Client `010` |

8. Export file names observed: `NMS_ST22.xls`, `NMS_SM66.xls`, `NMS_SM12.xls`, `NMS_SM13.xls`, `NMS_SP01.xls` and equivalents, all in `C:\BluePrism\data\SAP_NMS\`.
9. For SP01 only, the saved workbook is read back and an error count is extracted into a text summary. What is done with that summary downstream is not shown.
10. Mark the code **Completed** and take the next one. When the queue is empty, close SAP.
11. The release also contains Excel formatting/consolidation routines named **SAP_NWS_SM12**, **SAP_SM37_Code**, **Consolidated NWS Template** and **Consolidated NMS Template** that parse and reformat these exports. **No recipient, report or ticket-raising step is visible in the source** — where the consolidated output goes is unknown.

### Stage B — (Separate routine) ATLAS SAP health check across systems

1. Load the ATLAS system list into the to-do list **SAP_ATLAS_Systems**. *The list of systems is held in a data item with no visible value; from the routing logic it contains at least `AEP`, `AAP` and `AWP`.*
2. Take the next system off the queue.
3. **If the system name is `AEP` or `AAP`, then** run the standard ATLAS transaction routine. **Otherwise (i.e. `AWP`), then** run the AWP-specific routine, which logs in as `qxl3498`.
4. Either routine then logs into SAP for that system and loads its transaction-code list into the to-do list **SAPAtlasWorkQueue**.
5. Take each code in turn and run the matching routine. Recognised codes: **SM12, SM13, ST22, SMQ1, SMQ2, SMQ3, SM66, SM58, SCOT, SM21, DB01**.
6. Export each result list as a spreadsheet the same way as stage A. File names are prefixed per system — `ATLAS_ST22.xls`, `ATLAS_SM12.xls`, `ATLAS_SM66.xls`, `ATLAS_SM13.xls`, `ATLAS_SMQ1.xls`, `ATLAS_SM21.xls` for AEP/AAP and `AWP_ST22.xls`, `AWP_SM12.xls`, `AWP_SM66.xls`, `AWP_SM13.xls`, `AWP_SMQ1.xls`, `AWP_SM21.xls` for AWP. The target directory is not visible in the extract shown.
7. Mark each code **Completed**, then each system **Completed**. Close SAP when the transaction queue empties.

### Stage C — (Separate routine) TF/ATLAS material discrepancy upload

1. Log into SAP system **`AEP`** as **`QXI4826`**. If a multiple-logon prompt appears, select **Continue with logon** and click **Ok**.
2. Enter transaction **`SE16N`**, click **Ok**.
3. On the table-display screen, enter table name **`MARA`** (material master) and click **Execute**.
4. On the results screen click **Export**, choose **Spreadsheet**, click **Ok**, then **Save** as `ATLAS_Material_Data.xls`. Allow up to 40 seconds for the export to complete.
5. Reformat that workbook using the built-in **ATLAS_Material_Data** Excel routine and save it under a new name.
6. Run the batch file `C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Descrepancy_Check.bat` and wait 10 seconds.
7. Read its output `C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Descripencies.csv`, treating the first line as a header.
8. Extract the part numbers from that file and write them to `C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Parts.txt`. Close SAP.
9. Log into the MyNetwork portal: attach to the window titled `MyNetwork *`, type the URL `http://vtpep.muc/`, press Enter, then enter user **`qxp5286`** and password and click **Login**.
10. Navigate **Internal → MQS-Production → Part Transfer**.
11. Set the string type to **`MAT`**.
12. Click **Browse**, type the file path `\\Client\C$\Users\s.jyothi.avadhanam\Desktop\Descrepancies\Parts.txt` into the file-path and file-name fields, press Enter / **Open**, select the file, then click **Select Parts from file** to complete the upload.

   *Note the mismatch worth checking: the parts file is written to `…\Desktop\TF_Atlas_Discrepancies\Parts.txt` but uploaded from `…\Desktop\Descrepancies\Parts.txt`. Confirm which path is correct in your environment.*

## Exceptions and recovery

| Condition | What the automation does | What a human should do |
|---|---|---|
| Any unhandled failure while processing one PIX error row | Marks that **PIXTUMonitMailSend** row as **Exception**, recording the system's own failure text, then resumes with the next row. Retry and keep-locked settings are not visible in the source. | Review exception rows on the queue, fix the cause, re-queue if the dealer still needs the mail. |
| Error row has a blank Partner TU, or an error number that is not exactly 4 digits | Row is skipped by the filter; no mail is produced | Decide whether those errors need manual triage — the bot silently drops them. |
| No dealer email resolved for the TU's country code | The dealer mail is not sent. A fallback body ("We couldn't find proper error description…") addressed to PIX Support exists for this case, but it sits off the main flow, so automatic firing is unconfirmed. | Check whether the error was actioned at all; if not, email PIX Support manually and add the missing dealer to `PIX_Dealer_Info.xlsx`. |
| Word template text for the error code cannot be extracted | Recovery block sets the body to the fallback "Error Description Not Found" text and resumes | Add or fix the `Error Code <n> Starts/Ends` block in the template. |
| Any exception raised during the PIX login step (launch, missing dialog, fields that cannot be filled) | Terminates the PIX application and resumes past the login step. The 5-second login wait expiring is not itself treated as a failure — the bot proceeds to type the credentials. | Confirm PIX is reachable and the account is not locked, then re-run. |
| Outlook send path: **To**, **Subject**, **CC** or body field not present within its wait window | Raises a named exception — `To Doesn't exist`, `Subject doesn't exist`, `CC doesn't exist`, `Body doen't exist` — and a recovery block relaunches/reattaches Outlook | Ensure Outlook is open and not showing a modal dialog before the run. |
| SMTP send attempted before the relay is configured | Raises `ConfigurationException: "Cannot connect to Server you must use Configure first"` | Check the SMTP host/port/credential configuration. |
| Excel problems: no valid Excel session, workbook not open, file missing | Raises `Bad Handle`, `Workbook Not Found` or `File Not Found`, naming the offending session, workbook or path | Close stray Excel instances; confirm the named file exists at the path in the message. |
| SAP: expected screen not present (transaction-code field, results list, file-type dialog, save popup, directory field) | Raises a descriptive exception per screen — e.g. `Transaction code doesn't exist`, `REsults window doesn't exist`, `FileType window doesn't exist`, `Save popup doesn't exist` | Usually a timing or SAP-performance issue; re-run the affected transaction. |
| SAP logon shows a system message or multiple-logon prompt | Recovery blocks click **Ok** on the system message, or select **Continue with logon** and click **Ok** | None, unless it recurs — then check for a stuck session. |
| SAP NMS logon reports "Already Logged In" | Sets a status of `Already Logged In`, closes SAP and **stops the whole NMS run** | Clear the existing session for `qx68203`, then re-run — otherwise the day's checks are simply missing. |
| Any unhandled failure in the SAP NMS or ATLAS routines | Marks the current transaction-code or system row **Exception** with the failure detail, then resumes | Review the queue, re-run the missed transactions. |

## Data handled

| Name | What it holds | Where it comes from |
|---|---|---|
| **UserName / Password** (PIX) | PIX login. Default user `navisione`; password blank in source | Configuration / credential store |
| **From Date** | Start date for the PIX error search. Stored default `02.02.2017`; a *Get Todate* calculation is applied before typing it | Supplied at run time, or calculated (rule not visible) |
| **ErrorCollection** | The list of PIX errors. Named columns in use: **PartnerTU**, **ErrorNo** | Read from the PIX error-log table, then written to and re-read from `Error_Code.xlsx` after de-duplication |
| **Error_Code.xlsx** | Working copy of the error list, de-duplicated | `C:\BluePrism\data\PixTUMonitoringLogs\Error_Code.xlsx`, overwritten each run |
| **Country Code** | Country of the TU being processed | Read off the PIX Technical Unit search screen |
| **Data** (dealer info) | Full contents of the dealer reference file | `PIX_Dealer_Info.xlsx` |
| **To** / **CC** | Dealer email and country support-group email for the current error | Looked up from dealer info by country code |
| **Start Text / End Text** | The `Error Code <n> Starts` / `Error Code <n> Ends` markers for the current error code | Built from the error number |
| **output** | The error-description text extracted from the Word template, with the dealer number inserted; becomes the mail body | `PIX TU Error Log Monitoring Template.doc` |
| **Subject** | `PIX TU Error Description` | Fixed default |
| **Body - Error Description Not Found** | Fallback body for PIX Support, with `[TU]` and `[ErrorCode]` placeholders | Fixed default |
| **PIXTUMonitMailSend** | To-do list of error rows awaiting an email; each row ends Completed or Exception | Populated at stage 4 |
| **MailList.xlsx** | A distribution list read by the Outlook send routine | `C:\BluePrism\data\PixTUMonitoringLogs\MailList.xlsx` — **the source does not show it being used in any mail field** |
| **NMSWorkQueue** | To-do list of NMS transaction codes for one day's health check | Populated at stage A; source values not visible |
| **SAP_ATLAS_Systems** | To-do list of ATLAS system names (`AEP`, `AAP`, `AWP` at least) | Populated at stage B; source values not visible |
| **SAPAtlasWorkQueue** | To-do list of ATLAS transaction codes per system | Populated at stage B |
| **TransactionCode / FileName / Directory** (SAP objects) | Per-transaction settings, e.g. `/nst22` → `NMS_ST22.xls` in `C:\BluePrism\data\SAP_NMS\`; `/nsm12` → `ATLAS_SM12.xls`; `/nsm66` → `AWP_SM66.xls` | Fixed defaults inside each SAP object |
| **From Date / ToDate** (SAP) | Reporting window: Friday's date if today is Monday, otherwise today | Calculated by the *Get Dates* helper |
| **ErrorCounts** (SP01) | Count of spool errors extracted from `NMS_SP01.xls` | Read back from the saved SP01 export |
| **Parts.txt / Descripencies.csv** | Discrepant part numbers from the MARA extract, and the raw batch output they came from | `Descrepancy_Check.bat` output, then written by the bot |

## Not determinable from the source

- Schedule, robot and run window for any of the five entry points — nothing about triggering is recorded.
- How **From Date** is actually populated in production; the stored default `02.02.2017` is stale and the *Get Todate* calculation's contents are not visible.
- Whether the PIX process loops back to take further rows off **PIXTUMonitMailSend** within one run, or handles a single queue item per run and then closes PIX.
- Volumes: typical number of PIX error rows per run, and therefore emails sent.
- Which send path is authoritative — SMTP via `ind.smtp.accenture.com` or the Outlook desktop automation. Both exist and both are wired to a version of the same page.
- Why the Outlook routine reads `MailList.xlsx`; the distribution list it produces is never seen being used.
- Whether the "Error Description Not Found" mail to PIX Support fires automatically, and the actual PIX Support address (the *Send To - PIX Support* calculation is not shown).
- Exact column layout of the PIX error table and of `PIX_Dealer_Info.xlsx`, and the matching rule inside the dealer lookup code.
- The full list of transaction codes loaded into **NMSWorkQueue** and **SAPAtlasWorkQueue**, and the ATLAS system list — all held in data items with no visible values.
- Ownership and monitoring of the four to-do lists: who reviews items marked Exception, and whether retries are configured.
- What happens downstream to the SAP export files (`NMS_*.xls`, `ATLAS_*.xls`, `AWP_*.xls`) — consolidation routines exist, but no recipient, report or ticket step is shown. The output directory for the ATLAS exports is also not visible.
- Passwords and credential sources for PIX, SAP and Citrix are all blank.
- Hard-coded personal paths and identities (`C:\Users\s.jyothi.avadhanam\Desktop\…`, sender `s.jyothi.avadhanam@accenture.com`, Q-numbers `qxp5286`, `qxl3498`, `qx68203`, `QXI4826`) indicate a developer machine; the production equivalents are not stated.
- Business meaning of the pre-canned "error 102 (Error of SSL hand shake)" dealer letter sitting as the default body in the Outlook send object — whether it is ever actually sent or is leftover scaffolding.
- The path mismatch in stage C between where `Parts.txt` is written and where it is uploaded from.

---

How this SOP was checked

Generated from the project's source files and audited against them. Audit verdict: minor issues, confidence medium.

Strong, largely traceable coverage of the PIX flow (login → error-log search → table read → Excel write/de-dup → PIXTUMonitMailSend queue → 4-digit/PartnerTU filter → TU-to-dealer lookup via PIX_Dealer_Info.xlsx → Word template extract → mail → Mark Completed/Exception → terminate) with correct paths, subject, SMTP host/port, thresholds and queue names. Stages A/B/C correctly map SAP_NMS_All_Transactions, SAP_ATLAS_All_Systems→All_Transactions/AWP, and TF_Atlas_Descrepancies incl. SE16N/MARA, batch file, Parts.txt and the Citrix MQS upload. Genuinely unsupported items (trigger, volumes, which mail path is live, MailList.xlsx use, PIX Support address, ATLAS export directory, transaction-code list contents) are correctly flagged as not determinable. Gaps: several dormant Excel routines in the release are not inventoried, and one asset (standalone SP01 object) is folded into stage A without noting it has no visible caller.

2 corrections from the audit were applied to the procedure above.

Remaining minor notes, not corrected:

• Stage A step 7 table, SM12 row — The concrete SM12 selection values (Table name '', Lock argument '', Client '010', User '*') appear in the SAP_ATLAS_AWP_All object's SM12 page. The SAP_NMS_All_TC_VBO SM12 page is truncated in the outline and shows no field values, so these values are attributed to the wrong system/stage. (Attribute those wildcard/client-010 values to the ATLAS AWP routine (stage B) and note that the NMS SM12 field values are not visible in the extract.)
• Stage A step 9 ('For SP01 only, the saved workbook is read back…') — The read-back and error-count extraction belong to a standalone SP01 object with its own SAP logon, selection screen and Terminate pages. Nothing in the outline shows SAP_NMS_All_Transactions calling that object; the process calls SAP_NMS_All_TC_VBO::SP01, whose content for read-back is not shown. (Describe SP01 error-count extraction as a separate SP01 asset (system NRP, user qx68203) with no visible caller, rather than as a step inside the NMS queue loop.)
• Stage A step 5 (generic export path) — Presents 'System → List → Save → Local file' as the export route for every transaction. That menu path is what SM66 (and SP01) use; the NMS ST22 page clicks an Export button then 'Local file' directly. (Note the two variants: menu path System→List→Save→Local file for SM66/SP01, direct Export/Local file for ST22; downstream steps (Spreadsheet → OK → directory → filename → Replace) are common.)
• Opening paragraph ('Each working day…') and 'Frequency' row; Stage A step 6 — Daily frequency and the exact date rule ('Monday → Friday's date, otherwise today') are asserted as fact. The source shows only an IF on [GetDay]='Monday' routing to 'Get Friday Date' vs 'Get From Date'; the contents of those calculations are not visible, and no schedule exists anywhere in the outline. (Present the Monday/Friday branch as the visible decision and mark the actual dates produced (and the daily cadence) as inferred/unverified, consistent with the 'Not determinable' section.)
• Stage 3 step 2 ('save it as … Error_Code.xlsx') — The write routine saves with file name 'C:\BluePrism\data\PixTUMonitoringLogs\Error_Code' (no extension); the .xlsx path appears only where the file is re-opened/read. (State the save target as 'Error_Code' (extension supplied by Excel) and note the read-back path is Error_Code.xlsx.)
• Stage A step 11 (inventory of Excel helper routines) — Lists only SAP_NWS_SM12, SAP_SM37_Code, Consolidated NWS Template and Consolidated NMS Template. The Excel object also contains SAP_STARD_FP_Code, STARD_SM37, SAP_Finance_SM13, Landshut_excel, CopySAPData, GetPartsFromTF, SAP_AEcode/ReadAEData and SAP_AWPMacrocode (writes an AE collection at cell M1 and number-formats standard price) — none of which appear in the SOP. (Add these to the inventory of dormant/uncalled helper routines shipped in the release, flagging that no process in the outline calls them.)