BMW Back-Office Monitoring and Administration Suite (release BPRelease_03092017)

This release bundles a set of routine back-office checks and administrative tasks for BMW IT and After-Sales. Its most complete routine is PIX Technical Unit error-log monitoring: it reads the PIX portal's error log for a date range, removes duplicate error codes, works out which dealer and country support group owns each error, pulls a pre-written explanation of that error code out of a Word template, and emails it to the dealer with the support group copied. The same release also carries SAP basis health checks (SM12/SM13/SM21/SM37/SM66/SP01/ST22), SAP stock-monitoring consolidation across two SAP systems, an ATLAS material-discrepancy upload into MQS through Citrix, ITSM-driven SPOA service-package cancellation, S-Gate role changes and password-reset guidance, ISAR/Citrix availability checks, and a training order-entry exercise.

At a glance

Trigger	Not recorded in the source. Every routine begins from a plain start point — no scheduler entry, no mailbox watch, no deferred work. Consistent with either a scheduled unattended session or a manual start by an operator.
Frequency	Not recorded in the source. Date defaults hint at a working-day cadence: the PIX search date defaults to 02.02.2017, and the SAP log extract contains an explicit rule — if today is Monday, use Friday's date as the From Date, otherwise use today's.
Systems used	PIX TU portal (web); Microsoft Excel; Microsoft Word; Microsoft Outlook; SAP GUI (systems NRP/NRI, AWQ/QA1, AEQ/AEP, TEP); SQL Server localhost\SQLExpress, database BMW_RPA; Citrix Receiver (ISAR and TF farms, domain MUC); ITSM incident tool (web); SPOA vehicle/package portal (web); S-Gate https://sgate.bmwgroup.com; BAT user-administration tool (web); Landshut authorisation-request portal (web); Training Order System (Windows app TrainingOrderSystem); mainframe web front-end (prototype)
Inputs	PIX credentials (user navisione); PIX search From Date; dealer directory C:\BluePrism\data\PixTUMonitoringLogs\PIX_Dealer_Info.xlsx; error-text template C:\Users\s.jyothi.avadhanam\Desktop\PIX TU Error Log Monitoring Template.doc; mail list C:\BluePrism\data\PixTUMonitoringLogs\MailList.xlsx; SAP credentials from BMW_RPA.system_credentials where application_name='NMS'; training order file C:\BluePrism\Training\Applications\Windows\Orders.csv; ITSM search filters (group spoa:global:3rd, tag #SD#Cancel Package#, status Resolved); ATLAS batch file Descrepancy_Check.bat
Outputs	Outlook emails to dealers (subject PIX TU Error Description) with country support group copied; fallback email to PIX Support when no template text exists; email NMS-SP01 Error Counts to s.jyothi.avadhanam@accenture.com; S-Gate password-reset instructions (see the recipient caveat in Stage E1); entries on work lists PIXTUMonitMailSend, SPOAPackageCancellation, QueueTrainingOrder, Queue 1; Excel/CSV artefacts (Error_Code.xlsx, AW.xls, AE.xls, NMS_ST22.xls, NMS_SM66.xls, NMS_SM12.xls, NMS_SM13.xls, SP01_ErrorCounts.xls, ATLAS_Material_Data.xls, Descripencies.csv, Parts.txt); parts uploaded to MQS Part Transfer; cancelled SPOA packages; changed S-Gate roles and dealer BP-IDs; created training orders
Typical run	Not recorded in the source (no volume figures, no run-duration data)
Owner	Not recorded in the source. The only human name visible anywhere is the mailbox s.jyothi.avadhanam@accenture.com, which is both the sender path (file paths under that Windows profile) and the sole recipient of the SP01 report.

Before you start

Accounts and credentials. Passwords are blank in the stored design for PIX, ITSM, S-Gate, BAT, SPOA and most SAP logons — they must be supplied at run time from wherever your credential arrangement holds them (the source does not show where). Two exceptions matter:

• SAP NMS credentials are fetched automatically from the database: select user_id,password from system_credentials where application_name='NMS'; on localhost\SQLExpress, database BMW_RPA.
• The Landshut portal object and the SAPConnection object contain plaintext passwords embedded in the flow (muc\qxq0595 / 1qaz1qaz, and SAP user qxq0595 / 3edc3edc). Treat these as a control finding and have them removed before any reuse.

Account identifiers hard-coded in the release — confirm each is still valid and entitled before running:

System	Account
PIX TU portal	navisione
SAP NMS (NRP/NRI)	qx68203
SAP ATLAS (AEP)	QXI4826
SAP TEP (Landshut SAP leg)	qxq0595
Citrix TF farm	qxp5286 (domain MUC)
Citrix ISAR farm	qxm8387
ITSM / SPOA / S-Gate	QXO8154
S-Gate user being edited (default)	QXK4832
Landshut portal	muc\qxq0595
Training Order System	staff number bp

Files that must be in place (create or restore before the run — the automation does not create them):

• C:\BluePrism\data\PixTUMonitoringLogs\PIX_Dealer_Info.xlsx — dealer directory keyed on country code
• C:\BluePrism\data\PixTUMonitoringLogs\MailList.xlsx — mail distribution list read inside the send-mail routine
• C:\Users\s.jyothi.avadhanam\Desktop\PIX TU Error Log Monitoring Template.doc — Word document containing one block per error code, delimited by the literal lines Error Code <n> Starts and Error Code <n> Ends
• C:\BluePrism\Training\Applications\Windows\Orders.csv (training routine only)
• C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Descrepancy_Check.bat (ATLAS routine only)
• Writable folders: C:\BluePrism\data\PixTUMonitoringLogs\, C:\BluePrism\data\SAP_NMS\, C:\Users\s.jyothi.avadhanam\Desktop\SAP\, C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\

System state. Outlook should already be open (if not, the automation launches it, but this costs time and can fail on the first mail). Excel and Word must be installed and must not be left with a modal dialog open from a previous run. SAP GUI's logon pad must list the target systems under the exact names the automation clicks: NRP, NRI, AEP, TEP, AWQ [160.46.162.36]--QA1. For Citrix work, the desktop window titled MyNetwork * must be reachable, and the operator should expect a Citrix Receiver - Security Warning dialog which the automation dismisses with Allow reading only.

One housekeeping point before you start. Two routines in this release, named Blueprsim and PIX_TU_Monitoring, are byte-for-byte identical. Establish which one is the live one and disable the other; running both would send duplicate dealer notifications.

Procedure

Stage 1 — Sign in to the PIX TU portal

1. Launch the PIX application and wait up to 5 seconds for the login region to appear.
2. Click the user name field and type the PIX user name (default navisione); click the password field and type the password.
3. Click OK.
4. If the login screen does not behave as expected, the automation closes the PIX application entirely and continues from the recovery point, allowing a fresh attempt.

Stage 2 — Pull the error log for the period

1. Click Error Log in the portal and wait 5 seconds.
2. Enter the From Date (design default 02.02.2017 — supply the correct date for the run).
3. The automation calculates the To Date itself (step named "Get Todate"). The exact rule is not visible in the source; assume "today" unless told otherwise.
4. Click Search.

Stage 3 — Capture and de-duplicate the error table

1. Read the whole error table from the results page into a working data set (a "collection" — a tabular block of rows and columns held in memory).
2. Create a new Excel workbook, write the table into it starting at cell A1 of Sheet1, and save it as C:\BluePrism\data\PixTUMonitoringLogs\Error_Code.xlsx.
3. Wait 10 seconds, then run the Excel routine PIXMacroCode, whose internal step is named RemoveDuplicates. This reduces the sheet so each error code / Technical Unit combination appears once. The workbook is saved and Excel is closed.

Stage 4 — Load the cleaned rows onto the mail-send work list

1. Add the de-duplicated rows to the shared work list named PIXTUMonitMailSend. A work list here is simply a persistent to-do table that the automation draws from, so that each error row can be tracked as pending, done, or failed. One entry is created per error row.
2. No priority, tags, deferral date or initial status is set — every entry goes on as an ordinary pending item.

Stage 5 — Take the next outstanding item

1. Claim the next unworked entry from PIXTUMonitMailSend, retrieving its identifier and its row of data.

2. If no entry is returned (the identifier comes back blank) then the run ends here — nothing left to notify.

3. If an entry is returned then continue to Stage 6.

   Ambiguity worth flagging: as written, the main flow claims one entry, processes it, marks it complete, and ends. It does not loop back to claim the next one. The loop over error rows actually lives inside the routine called in Stage 6, which iterates the whole cleaned spreadsheet rather than the work list. The developer's intent here is genuinely unclear; verify against a live run before assuming full coverage.

Stage 6 — Identify the dealer and support mailbox

For each error row (the routine re-reads Error_Code.xlsx and loops its rows):

1. If the Partner TU field is populated and the error number is exactly four digits long then proceed with lookup; otherwise the row is not notified.
2. In the PIX portal, click Search Technical Unit, enter the TU number, click Search, and read the country code shown for that unit.
3. Open the dealer directory C:\BluePrism\data\PixTUMonitoringLogs\PIX_Dealer_Info.xlsx and look up that country code to obtain two addresses: the dealer email (used as To) and the support-group email (used as CC).
4. If a dealer email was found then continue to Stage 7. If not then the recipient is switched to PIX Support (step "Send To - PIX Support") and the fallback body described in the exceptions table is used.

Stage 7 — Build the explanation text from the Word template

1. Build the two search markers from the error number: Error Code <n> Starts and Error Code <n> Ends.
2. Open a Word instance, make it visible, and open C:\Users\s.jyothi.avadhanam\Desktop\PIX TU Error Log Monitoring Template.doc.
3. Extract the text lying between the two markers — this becomes the mail body.
4. Close the Word instance.
5. Insert the dealer name and dealer number into the extracted text (steps "Enter Dealer Name in Error Description" and "Enter Dealer Number in Error Description"). The template body visible in the source contains blank placeholder lines Dealer Name:________ Dealer Number:______________ which these steps fill.

Stage 8 — Send the notification from Outlook

1. Attach to the Outlook window (window title matching *- Outlook) and bring it to the front. If Outlook is not running then the automation launches it and resumes.
2. Click Home, then New Email.
3. Fill To (dealer), CC (country support group) and Subject — PIX TU Error Description.
4. Copy the composed body to the clipboard, click into the message body, and paste with Ctrl+V.
5. Click Send.

Stage 9 — Close the work-list entry

1. Mark the PIXTUMonitMailSend entry as complete so it will not be picked up again on a later run.

---

Stage A — Side routine: SAP NMS basis health check and spool report

Only one chain in this stage is actually driven by a routine: the SP01 spool error-count report (process SAP_NMS_SP01_VBO). Everything listed under "Built but not orchestrated" below exists as finished screen-level routines that no routine calls; the source therefore defines no sequence between them and nothing in this release runs them. Treat that part as an inventory of available building blocks, not as a procedure to follow.

Orchestrated: SP01 spool error counts

1. Open SAP Logon, select system NRP, key user qx68203 and the password, and confirm. If the login window does not appear then an exception is raised ("Window doesn't exist").
2. Type transaction SP01 into the transaction-code field and confirm.
3. On the selection screen enter Created By *, the created-from and created-to dates (both calculated in the flow), and client 010; click Execute. If the spool-request selection screen needs re-activating then recovery activates it and clicks Display.
4. Wait up to 70 seconds for the list, then export it via System → List → Save → Local file → Spreadsheet, write the file name (SP01_ErrorCounts1.xls, resolving to C:\Users\s.jyothi.avadhanam\Documents\SAP\SAP GUI\SP01_ErrorCounts.xls) and confirm Replace.
5. Read the exported spreadsheet, compute the error counts, and email them with subject NMS-SP01 Error Counts to s.jyothi.avadhanam@accenture.com, copying the same address.
6. Terminate SAP.

Built but not orchestrated (no routine invokes these; no order is defined)

These routines read the NMS SAP credentials from the database (select user_id,password from system_credentials where application_name='NMS';) and log on to NRP/NRI. If a system-message popup appears after logon then the flow activates it, clicks OK and resumes. The developer's own notes state the intent of each transaction:

Transaction	What the routine does	Developer's note
SM12	Enter table *, lock argument *, client 010, user *; list lock entries; export to C:\BluePrism\data\SAP_NMS\NMS_SM12.xls	"Delete previous day locks"
SM13	Enter date range, execute, read the update-error table, discard rows where the error field INFO5 is blank	"check if any failed updates are there"
SM21	System Log → Choose → All remote system logs; enter From/To date; re-read logs; then use Find to search for database errors and read the hit count and error text	"search for database erros"
SM37	Enter job name and user; tick Released, Ready, Active, Finished, Cancelled; enter date range; execute; export via Extras → Export → Local file → Spreadsheet; reduce the export to unique errors	"Check for canceled jobs"
SM66	Open the transaction and export the work-process list to NMS_SM66.xls	"Check the Work proccess which is taking more time to run which is in PRIV mode"
SMQ1	Enter client, queue name and queue destination; execute	"Reprocessing stuck RFCs"
SM58	Enter From/To date and user name; execute	"Reprocessing stuck RFCs"
SP01 (duplicate of the orchestrated chain, in a different object)	Enter Created By *; execute; use Find repeatedly to count spool requests in process and with errors	"Finding numbder of Spool requests being proccessed and spool request with errors"
ST22	Enter From/To date, user *; tick exception, program affected, program components; start; export to NMS_ST22.xls; keep only rows for client 010	—
BD87	Enter From/To date and IDoc status; execute; expand client 010 in the tree; display IDocs	—

Important caveat. The notes for SM12, SMQ1 and SM58 describe remediation ("delete locks", "reprocess stuck RFCs"), but no step in the source actually deletes a lock or reprocesses a queue. As built, these routines report only. Do not assume remediation has happened.

Date selection. One of these unorchestrated SAP routines carries an explicit rule for its extract window: if today is Monday, use Friday's date as the From Date; otherwise use today's date.

Stage B — Side routine: SAP stock monitoring consolidation

1. Log on to SAP system AWQ [160.46.162.36]--QA1.
2. Run transaction SM37. Enter job name *STOCK*, user name *, and the job start/end date range (design defaults 06.02.2017–07.02.2017). Execute.
3. Open the spool, set the output type, and export via Local file → Spreadsheet to file name AW.xls. Terminate this SAP session.
4. Log on to SAP system AEP (the AEQ object). Run transaction se16n.
5. Enter table name mbew, confirm, and click More.
6. Copy the AW data out of AW.xls (Excel routine CopySAPData formats it first), paste it into the SE16N selection, enter area number a190, and execute.
7. Export the result via Export → Local file → Spreadsheet to AE.xls in directory C:\Users\s.jyothi.avadhanam\Desktop\SAP. Terminate SAP.
8. Run the Excel consolidation routine SAP_AWPMacrocode: it reads the AE data, opens the AW workbook, writes the AE data starting at cell M1, re-formats the standard-price column as a number, saves, and closes Excel.

Stage C — Side routine: ATLAS material discrepancies uploaded to MQS

1. Log on to SAP system AEP as QXI4826. If a "continue with logon" prompt appears then the automation selects it and clicks OK.
2. Run transaction SE16N, enter table name MARA, and execute.
3. Export the result list via Export → Spreadsheet → Save as ATLAS_Material_Data.xls.
4. Run the Excel formatting routine ATLAS_Material_Data against that workbook.
5. Start the batch file C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Descrepancy_Check.bat and wait 10 seconds.
6. Read the resulting CSV C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Descripencies.csv (first line treated as the header row), extract the part numbers, and write them to C:\Users\s.jyothi.avadhanam\Desktop\TF_Atlas_Discrepancies\Parts.txt. Close SAP.
7. In Citrix: attach to the MyNetwork * window, click the browser address bar, type http://vtpep.muc/ and press Enter. Log in with the Q-number and password on the page.
8. Navigate Internal → MQS-Production → Part Transfer.
9. Set the string type to MAT, click Browse, and enter the file path \\Client\C$\Users\s.jyothi.avadhanam\Desktop\Descrepancies\Parts.txt in the file dialog. (Note the path used on the Citrix side differs from the local write path in step 6 — folder Descrepancies versus TF_Atlas_Discrepancies. Verify which is correct for your environment.)
10. Open the file and click Select Parts from file to complete the upload.

Stage D — Side routine: SPOA service-package cancellation driven by ITSM

1. Log into ITSM with Q number QXO8154. If the home page does not appear within 5 seconds then an exception is raised ("Home page doesn't exist").
2. Click Search Incident and enter three filters: Assigned Group spoa:global:3rd, Notes contains #SD#Cancel Package#, Status Resolved. Click Search.
3. Open each result in turn and read its Notes text and Incident ID into a working list.
4. Add that list to the work list SPOAPackageCancellation — one entry per incident.
5. Claim the next entry. If no entry is returned then end.
6. Parse the free-text incident notes to extract the package name (the same code also extracts vehicle numbers and an environment indicator). A typical note reads: "#SD#Cancel Package# Please cancel BSI plus package 5 years/100000 km. bearing code 07NA only from the VIN as requested by dealer… Note: Please don't cancel RI package 07CK."
7. If a package name was found then mark the entry complete. If not then mark the entry as an exception with reason Couldn't find Package Name.
8. Important caveat. The production routine stops at step 7. The actual cancellation in SPOA exists only in a separate, manually-run test routine ("SPOA PAckage Cancel Test") with hard-coded values (vehicle A050323, package 07T4). If cancellation is required end-to-end, that gap must be closed or the cancellation done manually.
9. The cancellation steps themselves, where they run, are: log into SPOA → click Service Package Deletion → select variable input and enter the chassis/vehicle number → Search → read the package table → loop the rows skipping the header → trim and compare each package name against the requested one → if the package's registration date is on or after today minus two months then tick its checkbox, write the reference text and click Cancel Package; if it is older than two months then skip that row and continue.

Stage E — Side routine: S-Gate account administration

E1 — Password-reset guidance

1. Log into the BAT user-administration tool with Q number QXO8154.
2. Select the interface language, then click Check User Integration.
3. If the supplied user identifier contains a full stop (e.g. kintali.ashik) then enter it in the login name field; otherwise enter it in the Q-Number field. Click Search User, then open the normal user-data view.
4. Read the account status and the user's email address.
5. If the status contains User is locked after 3 login failures or Enforce password change then the automation composes a mail carrying the six-step self-service instructions with subject SGate Password Reset. No recipient is supplied by the flow — only the body text and subject are passed to the send-mail routine, and the email address read in step 4 is never used as the To address. Recipient handling must be confirmed and added before this branch can be relied on. The instruction text reads:

   Open https://sgate.bmwgroup.com and select your market → click "Problem with Password" → click "Reset Password" → enter your e-mail address or Account-ID → click "Next" → choose your reset option (code via e-mail or reset code). Signed "SGate Support".

6. If the status shows neither condition then no email is sent and the routine ends.

E2 — SPOA role change

1. Log into S-Gate with language Englisch. If the login window or Login button is missing then the automation closes the browser and resumes; persistent failure raises "Login window doesn't exist" / "Login button doesn't exist".
2. Navigate Menu → User Administration → Admin AG/NSC → Edit User.
3. Enter the target Q number (design default QXK4832) and click Search.
4. Click Edit Role, then tick the SPOA roles required. Optionally the role set is first read from a reference user (QXO8154) via the View User screen and copied.
5. Click Continue to RAUS, then Save and View.
6. A separate branch, Create Dealer, adds a business-partner ID: open Edit User → search the Q number → Edit Dealer → Add BP-ID → enter the dealer AG number → Search → select the BP ID → Close → Save and Back.

Stage F — Side routine: ISAR / Citrix availability checks

Three independent checks, each starting with a login to the ISAR Citrix portal as qxm8387:

1. CLAT check — click 30_Antares, then CLAT, then Open. Dismiss the Citrix Receiver - Security Warning dialog with Allow reading only. Attach to the CLAT window (waiting up to 60 seconds), activate it, and click Datei → Öffnen to verify the XML open dialog appears.
2. User administration performance check — click 30_Antares, then ISAR Client, then confirm the open prompt with Alt+O. Attach to the window titled ISAR-Client * (up to 90 seconds), click Start, then Benutzerverwaltung. If the Benutzerverwaltung window does not exist then raise "Window doesn't exist".
3. Logged-in users verification — click 00_Administration → Konsolen → Citrix_AppCenter-PROD and open it. Wait up to 200 seconds for the AppCenter window. Right-click Citrix AppCenter, choose Configure and run discovery, then: Next → untick single sign-on → Next → Remove the existing computer → Add Local Computer → Next → wait up to 50 seconds → Next → Finish. If the discovery window does not appear then raise "Window doesn't exist".

Stage G — Side routine: Training order entry ("Consolidation Exercise")

This is a training/demo routine, not production work. The developer labelled its purpose "Consolidation Exercise".

1. Launch the Training Order System and wait up to 5 seconds for the login window. If it does not appear then raise "Login Screen has not appeared".
2. Log in with staff number bp and the password, then wait for the Options window.
3. Open Excel, open C:\BluePrism\Training\Applications\Windows\Orders.csv, read the sheet into a working list, and close Excel.
4. Add the list to the work list QueueTrainingOrder.
5. Claim the next entry. If none is returned then close the application and end.
6. Validate the four order fields in turn. Each failure raises its own exception naming the bad value:
   • blank or invalid Product Code → "Invalid or Blank product code [x] in Order data for Item id-y"
   • invalid Quantity → "Invalid Quantity x in order data for Product Id :- y"
   • invalid Unit Price → "Invalid Unit price x in order data for Product Id :- y"
   • invalid Cost Centre → "Invalid cost centre x in order data for Product Id :- y"
7. If all four fields are valid then choose menu option 1 (New Order), key Product Code, Quantity, Unit Price and Cost Centre, and click Submit Order.
8. Read the order reference number out of the confirmation message, click Continue, and mark the work-list entry complete.
9. When the list is exhausted, close the Training Order System.

Stage H — Side routine: Landshut authorisation-request review, with SAP user-maintenance leg

No routine in this release calls this one. It is documented because it is complete and because it drives a step in SAP.

1. Launch the Landshut portal and log in — the flow types muc\qxq0595 and its password straight into the login dialog (see the credential warning in "Before you start"). If the Administration page does not appear within 20 seconds then a system exception is raised.
2. Click SAPZulassungsteam on the administration page. If the login dialog reappears, recovery re-enters the same credentials and continues.
3. Work through the requests in the application-administration list, up to a maximum of eight records (the record counter must stay below 9). For each request:
   • a. Click Detail to open it.
   • b. Read the six release/approval fields: Completion Date, Local Admin Release, Release, Business Release, BV Release, Key User Release.
   • c. If any one of those six fields is populated then capture the record straight away — add a row and read UserID, Name, Email, Department, Subarea, Requested Permissions, Valid from/to and Comments.
   • d. If all six are blank then read the Applicant name and check it against the Excel lookup workbook (Excel routine Landshut_excel). If the applicant is found in the workbook then capture the record as in (c). If the applicant is not found then click Back and move on to the next request without capturing anything.
   • e. Read the Subarea value. If it does not start with the letter "A" then carry out step 4 for that request.
4. SAP leg (only for requests whose Subarea does not start with "A"): open SAP Logon, select system TEP, and click Logon. Sign in as qxq0595 with the password embedded in the flow. On the SAP home screen, type the user-maintenance transaction into the command field (the screen element is named SU; the exact code written is not visible in the source) and press Enter. On the user-maintenance screen, key the user whose role is required (design default qxq0595) and click EDIT, then wait up to 15 seconds for the user record to open. The flow stops there — no role change is made or saved.

Exceptions and recovery

Condition	What the automation does	What a human should do
PIX login screen unresponsive or login fails	Closes the PIX application entirely and resumes from the recovery point so a fresh attempt can be made	If it recurs, verify the navisione account is not locked and the portal is reachable
No template text found for an error code in the Word document	Substitutes the fallback body, inserts the TU Number and Error Code, and sends to PIX Support rather than the dealer. Body reads: "Dear PIX Team, We couldn't find proper error description for the below Error Code of TU number… Please process this request. Regards, RPA Team"	Add the missing Error Code <n> Starts / Ends block to the Word template so future runs are covered
No dealer email resolved for the TU's country code	Recipient switched to PIX Support	Add or correct the country-code row in PIX_Dealer_Info.xlsx
Work list PIXTUMonitMailSend empty	Ends cleanly	Nothing — normal end state
Training order data fails validation	Raises a specific exception naming the bad value; the enclosing recovery marks the work-list entry as an exception with reason "Exception bubbled up from Object " + exception detail, then resumes	Correct the source row in Orders.csv and re-present it
Training Order System window (Login, Options, New Order, Order Confirmation) absent after 5 s, or the confirmation window stays open after Continue	Raises a window-specific exception; the routine-level recovery calls the application's Exit — developer note: "Termionate Process and Exit"	Check the application is installed and responsive; restart it
Package name cannot be parsed from an ITSM incident note	Marks the SPOAPackageCancellation entry as an exception, reason Couldn't find Package Name	Read the incident manually and cancel the package by hand, or clarify the note format with the requesting group
SPOA package found but registered more than two months ago	Skips it silently — the loop moves on without ticking the cancellation box	Decide manually whether an older package should still be cancelled
SAP window, login window, transaction screen, results list, file-type popup or save popup missing	Raises exceptions with texts such as "Window doesn't Exist", "Login window doesn't exist", "REsults window doesn't exist", "FileType window doesn't exist", "Save popup doesn't exist"	Check SAP availability and that the logon pad entries still carry the expected names
SAP system-message popup after logon	Activates the popup, clicks OK, resumes	Read the message yourself if the run later fails — it may be a maintenance notice
S-Gate login window or Login button missing	Closes the browser in recovery and resumes; persistent failure raises "Login window doesn't exist" / "Login button doesn't exist". Later screens raise "User admin. doesn't exist", "Edit user window doesn't exist", "Search button doesn't exist"	Confirm the S-Gate account has the User Administration entitlement
Landshut detail field unreadable (Key User Release, Release, Local Admin Release, Completion Date, Business Release, BV Release)	Each read is guarded by a 2-second existence check with its own message, e.g. "Error Occured while reading Key User Release information"; recovery resumes	Open the request in the portal and read the field manually
Citrix AppCenter discovery window absent	Raises "Window doesn't exist"	Confirm the AppCenter console published app is still available on the ISAR farm
Citrix Receiver - Security Warning dialog appears	Attaches to the window by title and clicks Allow reading only	Nothing — expected behaviour
Outlook not running when a mail must be sent	Launches Outlook in recovery, then resumes composing	Leave Outlook open before scheduled runs to avoid the delay
Database action fails (SQL Server / OLEDB helper)	Configurable: raises an "Action Failed" carrying the driver message only when the helper is set to raise on failure. Open transactions are rolled back on close. Developer note explains why close failures are deliberately swallowed: "this is probably being called as part of a wider action, and the caller has the context with which to decide where the exception should be raised."	If credentials cannot be read, the unorchestrated SAP NMS routines will fail at logon — check BMW_RPA.system_credentials and SQL Express availability

Data handled

Name	What it holds	Where it comes from
UserName / Password (PIX)	PIX portal credentials; user defaults to navisione, password blank at design time	Design default plus run-time supply (source unknown)
From Date	Start of the PIX error-log search window; default 02.02.2017	Operator or scheduler input; To Date derived in-flow
ErrorCollection / Error Collection	The scraped PIX error table, one row per logged error, with at least the fields PartnerTU and ErrorNo	Read directly from the portal's HTML table; later re-read from Error_Code.xlsx after de-duplication
Error_Code.xlsx	The persisted, de-duplicated error list at C:\BluePrism\data\PixTUMonitoringLogs\Error_Code.xlsx	Written by the automation, then filtered by the RemoveDuplicates macro routine
Country Code	Two-letter (or similar) market code for a Technical Unit	Read from the TU search result page in PIX
To / CC	Dealer email address and country support-group mailbox	Looked up by country code in PIX_Dealer_Info.xlsx; falls back to PIX Support
Start Text / End Text	The literal markers Error Code <n> Starts / Error Code <n> Ends, built from the error number	Calculated per row
output	The extracted error explanation, with dealer name and number filled in — becomes the mail body	Word template extract plus in-flow substitutions
Subject	PIX TU Error Description	Fixed default
Body - Error Description Not Found	Fallback mail text to PIX Support with placeholders for [TU] and [ErrorCode]	Fixed default in the PIX object
PIXTUMonitMailSend	Work list of error rows awaiting notification	Populated in Stage 4
SPOAPackageCancellation	Work list of ITSM incidents requesting package cancellation; each entry carries Notes and the incident ID	Populated from the ITSM search results
QueueTrainingOrder	Work list of order rows from Orders.csv, with fields Product Code, Quantity, Unit Price, Cost Centre	Populated from the CSV
Queue 1	Test work list used only by a test object	Development leftover
Query / Query Results	select user_id,password from system_credentials where application_name='NMS'; and its result set	BMW_RPA database on localhost\SQLExpress; used only by the unorchestrated SAP NMS routines
Assigned Group / TagName / Status	ITSM search filters: spoa:global:3rd, #SD#Cancel Package#, Resolved	Fixed defaults
PackageName / VehicleNumbers / Environment	Values parsed out of the free-text ITSM incident note	Text-parsing code inside the SPOA object; Environment is extracted but never used anywhere
User Status / Email Id (BAT)	Account status text and the user's email address. The status decides whether the reset mail is sent; the email address is read but never used — it is not passed to the send-mail routine as a recipient	Read from the BAT user-data screen
Content_FLName	The six-step S-Gate self-service password-reset instructions	Fixed default in the BAT object
Test SPOA Roles / Roles	The set of SPOA roles to assign in S-Gate; may be copied from reference user QXO8154	Design input, or read from the reference user's role list
ErrorCounts	Summarised SAP SP01 spool error counts, used as the body of the NMS-SP01 Error Counts email	Computed from SP01_ErrorCounts.xls
Errors / Runtime Errors / UniqueData	Filtered SAP result sets — SM13 rows with a non-blank INFO5, ST22 rows for client 010, de-duplicated SM37/SM12 error lists	Read from SAP tables or exported spreadsheets by the unorchestrated routines
Job Name / Table Name / Area no / Client	SAP selection criteria: *STOCK*, mbew and MARA, a190, 010	Fixed defaults
AW.xls / AE.xls	The two SAP stock extracts merged in Stage B, with AE data written from cell M1	SAP GUI local-file exports
Descripencies.csv / Parts.txt	Discrepancy output of Descrepancy_Check.bat and the extracted part-number list uploaded to MQS	Batch file output, then automation-written text file
User Details (Landshut)	Up to 8 authorisation-request records (the record counter must stay below 9): UserID, Name, Email, Department, Subarea, Requested Permissions, Valid from/to, Comments, Applicant, plus the six release/approval fields	Read from the Landshut portal detail pages. Records with any of the six release/approval fields populated are captured directly. Records where all six are blank are captured only if the Applicant is found in the Excel lookup workbook (MS Excel VBO :: Landshut_excel); if not found, the bot clicks Back and moves to the next record. Nothing in this release consumes the resulting list, although the Subarea value drives the SAP leg in Stage H.
Order Reference No	Reference number returned by the Training Order System after submission	Parsed out of the confirmation message text

Not determinable from the source

• No schedule or trigger is recorded for any routine — daily, weekly or manual is not stated.
• Volumes: PIX error rows per run, ITSM incidents per run, and order rows in Orders.csv are all unknown.
• Who owns and monitors the work lists PIXTUMonitMailSend, SPOAPackageCancellation and QueueTrainingOrder, and who clears entries marked as exceptions.
• Whether the PIX main flow was meant to loop over every work-list entry. As built it claims one entry, sends, marks it complete and ends; the loop over error rows sits inside the template-extraction routine instead.
• Which of the two identical routines, Blueprsim or PIX_TU_Monitoring, is the live one.
• Where run-time passwords come from for PIX, ITSM, S-Gate, BAT, SPOA and most SAP logons (only the unorchestrated SAP NMS routines read the BMW_RPA credentials table). The Landshut and SAPConnection objects hold plaintext passwords in the flow — a control concern.
• Recipients for most outputs. Only s.jyothi.avadhanam@accenture.com (SP01 counts) and the dealer/support addresses from PIX_Dealer_Info.xlsx are visible; the S-Gate password-reset mail is composed with no recipient at all. The role of MailList.xlsx inside the send-mail routine is unclear.
• How From/To dates are chosen at run time for the PIX search and most SAP transactions — the stored values are 2016/2017 literals, and only one SAP object carries the explicit Monday/Friday rule.
• The intended order in which the unorchestrated SAP basis transactions (SM12, SM13, SM21, SM37, SM66, SMQ1, SM58, ST22, BD87) should run, and who is meant to start them — no process wires them together.
• Who consumes the AW/AE stock workbooks, the NMS_*.xls exports, the SM21/SM66/SMQ1 findings, and the uploaded Parts.txt. The developer notes imply remediation intent ("delete previous day locks", "reprocessing stuck RFCs") but no step performs it.
• The structure of the dealer directory workbook, and which error codes the Word template actually covers.
• Whether the SPOA cancellation is meant to run end-to-end. The production routine stops after parsing the package name; the actual Delete Package call exists only in a manual test routine with hard-coded values.
• The business purpose and destination of the Landshut authorisation-request extract — no routine in this release calls it, and the captured record list is never written anywhere; nor is it clear what is meant to happen in SAP after the user record is opened for editing.
• Environment/system targeting for SPOA and S-Gate: an "Environment" value is parsed from incident notes but nothing consumes it.
• The correct Citrix-side path for the parts upload — the file is written to …\TF_Atlas_Discrepancies\Parts.txt but the Citrix upload dialog is fed \\Client\C$\Users\s.jyothi.avadhanam\Desktop\Descrepancies\Parts.txt.
• Several assets appear to be stubs, prototypes or duplicates with no clear owner: BAT User Status, Mainframe and SendMail are empty; MaxDate, sample, SQL Developer VBO, Hilliards Readiness VBO, FP_SE16, Mainframe_WEB, WriteCSV, PIX_ERROR_LOG, Citrix Login and MSExcel VBO Landshut look like development leftovers.

---

How this SOP was checked

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

The core PIX TU error-log routine (login → error-log search → table scrape → Excel de-dup → PIXTUMonitMailSend queue → TU/country lookup → Word template extract → Outlook send → mark complete) is traced accurately step-for-step, including the single-item/no-loop ambiguity, the 4-digit ErrorNo + PartnerTU condition, and the recovery-on-login behaviour. SPOA/ITSM, S-Gate role change, BAT status check, ISAR/Citrix checks, ATLAS→MQS, stock-monitoring consolidation and the training order exercise are all correctly identified with the right transaction codes, queues, file paths and thresholds (AddMonths(Today(),-2), Monday→Friday date rule, INFO5 / MANDT='010' filters). Correctly flags stubs and duplicates (Blueprsim vs PIX_TU_Monitoring), and correctly says the source records no trigger, frequency, volumes or owner. Weakest areas: the Landshut object's row-selection logic, the fact that most SAP-basis monitoring objects have no calling process, and a few recipient/filename details.

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

Remaining minor notes, not corrected:

• Stage 6 step 4 / Exceptions table (fallback body) — SOP ties the 'Body - Error Description Not Found' fallback and 'Send To - PIX Support' to the dealer-email-not-found branch. In the source the fallback body steps (Set Content to Body, Enter TU Number in Content, Enter Error Number in Content) sit in the CATCH Recover2 recovery block of 'Extract Data from Template'; 'Send To - PIX Support' is a separate SET whose branch source is not shown. (Present the fallback as the recovery path when the template extraction/lookup fails, and note that whether the missing-dealer-email branch also uses it is not determinable from the source.)
• Stage E2 step 4 (reference user) — Describes reading the role set from reference user QXO8154 as an optional in-flow step. The 'Reference User' page of SGate_Role_Change is not called by any process or page in the outline. (Note that a Reference User routine exists (reads the role list of QXO8154 into a collection) but is not invoked by the role-change process as built.)
• Stage 3 step 3 — Invented de-duplication key: 'each error code / Technical Unit combination appears once'. Source only shows an inline code stage named RemoveDuplicates inside MS Excel VBO :: PIXMacroCode with no visible key. (Say the macro removes duplicate rows; the exact de-duplication key is not visible in the source.)
• Stage 3 step 2 / Data handled — Error_Code.xlsx — Save target stated as 'Error_Code.xlsx' at A1 of 'Sheet1'. WriteToExcel :: ExcelWrite creates a worksheet named Sheet1 but writes to the worksheet at position 1 and saves via 'Save Current Workbook As' with File name 'C:\BluePrism\data\PixTUMonitoringLogs\Error_Code' (no extension); the .xlsx name appears only as the later read path. (Note the save-as path carries no file extension and the write target is the first worksheet; the .xlsx name is the path the bot later reads.)
• Stage A step 3 (SP01 row) / Outputs list — Export file given as SP01_ErrorCounts.xls only. The SP01 object holds two values: the name typed into the save dialog defaults to 'SP01_ErrorCounts1.xls' while the file later read is 'C:\Users\s.jyothi.avadhanam\Documents\SAP\SAP GUI\SP01_ErrorCounts.xls'. (Record both values and flag the mismatch as something to verify.)
• Stage G step 9 — 'When the list is exhausted, close the Training Order System' implies iteration over QueueTrainingOrder. The Create Orders main page shows one Get Next Item, one validation/creation pass, Mark Completed, then End — no loop back, exactly like the PIX flow the SOP flags elsewhere. (State that as built the routine processes a single queue entry per run and does not loop back; the Exit path is taken only when the first Get Next Item returns nothing.)
• Stage 7 step 5 — Attributes the 'Dealer Name:________ Dealer Number:______________' placeholder lines to the Word template. That text is the default Content data item of the Send Mail object, not the .doc template. (Say the placeholder wording appears in the Send Mail object's stored default body; where the dealer name/number substitution actually lands is not visible.)
• Stage C / Systems and accounts table — Two attribution slips: (a) the standalone process 'TF_Citrix' (Citrix login → Connect to MQS → Upload Parts, i.e. the upload leg run on its own) is not mentioned anywhere; (b) domain 'MUC' and account qxp5286 are presented as TF-farm login facts, but the Domain='MUC' default lives in the leftover 'Citrix Login' object, and QXO8154 is attributed to S-Gate login although SGate_Role_Change holds no username default. (Mention TF_Citrix as a separate re-run entry point for the MQS upload, and attribute Domain 'MUC' / QXO8154 to the specific objects that hold them (Citrix Login object; BAT and SGate Reference User respectively).)