Create Orders — bulk order entry into the Training Order System

This procedure takes a file of order lines, loads each line onto a shared to-do list, checks the data is complete and sensible, and then keys each valid order into the Training Order System desktop application, capturing the order reference the system returns. Lines that fail validation, or that break during keying, are flagged on the to-do list with a reason so they can be corrected and re-run. The developer's own label for the automation is "Consolidation Exercise", which suggests it was built as a training/consolidation build rather than a mission-critical production flow — treat the production status as unconfirmed.

Scope of this SOP. The steps in the Before you start, Procedure, Exceptions and recovery and Data handled sections cover the Create Orders automation only. The same release also contains five other, unrelated automations — PIX_TU_Monitoring, SAP_StockMonitoring_Process, Set SPOA Role -SGate, SGate Password Reset and MaxDate — plus supporting components for SAP basis monitoring (SAP_NMS_VBO, NMS_SM12_VBO), the BAT user-status tool and Outlook mail sending. None of these is called by Create Orders and none is covered in operational detail here. Each requires its own SOP before it can be run or rebuilt. Outline-level summaries of all of them, sufficient to scope that work, are in the Appendix at the end of this document.

At a glance

Trigger	Manual or scheduled start of the Create Orders process. There is no inbound e-mail, file-watcher or event trigger in the source; the run simply opens the order application and reads the CSV.
Frequency	Not recorded in the source
Systems used	Training Order System (Windows desktop app, process name TrainingOrderSystem); Microsoft Excel; the shared to-do list (work queue) named QueueTrainingOrder held inside the automation platform
Inputs	Order file C:\BluePrism\Training\Applications\Windows\Orders.csv — one row per order, with columns Product Code, Quantity, Unit Price, Cost Centre. Order System login: Staff Number (default bp) and Password.
Outputs	Orders created in the Training Order System; an Order Reference No read from each confirmation screen; each to-do list entry set to Completed or flagged as an exception with the text Exception bubbled up from Object <detail>
Typical run	Not recorded in the source — no volume, duration or run-window is stated
Owner	Not recorded in the source

Before you start

• Access to the Training Order System. You need a working staff number and password. The process ships with Staff Number bp as a default; the password has no stored default in the process, so it is presumably supplied at run time or pulled from a credential store not visible in the source.
• The order file must be in place. C:\BluePrism\Training\Applications\Windows\Orders.csv must exist and be readable on the machine running the automation. If the file is missing, Excel will fail to open it and the run will stop.
• Excel must be installed on the same machine. The automation opens Excel with macro/worksheet events switched off (Enable Events = False) so that nothing in the file fires automatically, makes the window visible, then closes Excel again once the data is read.
• Check the state of the to-do list QueueTrainingOrder before starting. The automation adds every row of the CSV to this list at the start of each run and does not clear it first. If items from a previous run are still sitting there, or if the same CSV is loaded twice, duplicate orders can be raised. Confirm with the queue owner what the clear-down policy is before re-running.
• Nothing else should be driving the Training Order System window while the run is in progress — the automation reads and types into the live windows.

Procedure

Stage 1 — Open the order application

1. Launch the Training Order System (Windows process TrainingOrderSystem).
2. Wait up to 5 seconds for the Log In window to appear.
3. If the Log In window does not appear within 5 seconds, then the automation stops with the error "Login Screen has not appeared".

Stage 2 — Sign in

1. On the Log In window, type the Staff Number (default bp) and the Password into their fields.
2. Press Sign In.
3. Wait up to 5 seconds for the Options window (the main menu) to appear.

Stage 3 — Read the order file

1. Start Excel with worksheet/macro events disabled, and make the Excel window visible.
2. Open C:\BluePrism\Training\Applications\Windows\Orders.csv.
3. Read the whole worksheet into memory as a table of order rows. The outline does not name a specific sheet — the "read worksheet" action is called without a sheet name, so it takes the active/first sheet.
4. Close Excel.

Stage 4 — Load the work list

1. Add every order row read from the file to the shared to-do list named QueueTrainingOrder. Each row becomes one entry to be worked.
2. Priority, tags, defer-until date and initial status are not set in the source — the platform defaults apply.

Watch point: the automation does not check for or remove pre-existing entries in QueueTrainingOrder. Re-running against the same CSV will add the rows again.

Stage 5 — Take the next order

1. Claim the next unworked entry from QueueTrainingOrder, retrieving its internal reference (Item ID) and its order data (Product Code, Quantity, Unit Price, Cost Centre).
2. If no entry is returned (Item ID comes back blank) then the list is empty — go to Stage 10 and shut down.
3. If an entry is returned then continue to Stage 6.

Stage 6 — Validate the order line

The automation runs four checks in sequence on the claimed order line. The outline exposes the four checks and their failure messages, but not the actual pass/fail rules (e.g. whether Quantity must be a whole number, what constitutes a valid Cost Centre). Confirm the rules with the process owner before working an item manually.

Check	If it fails, the automation raises
Product Code	Invalid or Blank product code [<code>] in Order data for Item id-<Item ID>
Quantity	Invalid Quantity <qty> in order data for Product Id :-<Product Code>
Unit Price	Invalid Unit price <price> in order data for Product Id :-<Product Code>
Cost Centre	Invalid cost centre <cc> in order data for Product Id :-<Product Code>

1. Check Product Code, then Quantity, then Unit Price, then Cost Centre.
2. If any check fails then the run raises the corresponding error; the recovery handling in Stage "Exceptions and recovery" flags the entry on the to-do list and moves on. The order is not keyed.
3. If all four checks pass then the line is treated as good (the developer labelled this path "Valid Odrer Data") and the automation proceeds to Stage 7.

Stage 7 — Key the order

1. From the Options window, enter menu option 1 (New Order) and press Go.
2. Wait up to 5 seconds for the New Order window.
3. Fill the New Order window from the order line:
   • Product Code ← Product Code
   • Number Required ← Quantity
   • Unit Price ← Unit Price
   • Cost Centre ← Cost Centre
4. Press Submit Order.
5. Wait up to 5 seconds for the Order Confirmation window.

Stage 8 — Capture the order reference

1. On the Order Confirmation window, read the full text of the confirmation message.
2. Extract the Order Reference No from that message text.
3. Press Continue.
4. Confirm the Order Confirmation window has closed. If it is still open, then the automation raises "Order Confirmation Window still exist even after clicking continue button".

Note: the captured Order Reference No is held only in memory for the duration of the item. The outline shows it being written to no file, e-mail, database or back to the to-do list. If you need an audit trail of order references, this is a gap to raise with the process owner.

Stage 9 — Close off the work item

1. Mark the entry in QueueTrainingOrder as Completed, using its Item ID.
2. Return to Stage 5 and take the next entry.

Traceability caveat: the loop back from "Mark Completed" to "Get Next Item" is not drawn in the source outline. The structure (claim next item → work it → mark complete, with an explicit "no item left → close application" branch) only makes sense as a repeating cycle, so treat the loop-back as inferred rather than proven, and verify it against the live process before rebuilding.

Stage 10 — Shut down

1. When the to-do list returns no further entries, close (terminate) the Training Order System application.
2. End the run.

Exceptions and recovery

Condition	What the automation does	What a human should do
Blank or invalid Product Code on a queued order line	Raises Invalid or Blank product code [<code>] in Order data for Item id-<Item ID>; the item is flagged as an exception and the run continues	Correct the product code in the source data and re-present the line
Invalid Quantity	Raises Invalid Quantity <qty> in order data for Product Id :-<Product Code>	Correct the quantity; confirm the acceptable range with the process owner (rule not visible in source)
Invalid Unit Price	Raises Invalid Unit price <price> in order data for Product Id :-<Product Code>	Correct the price and re-present
Invalid Cost Centre	Raises Invalid cost centre <cc> in order data for Product Id :-<Product Code>	Check the cost centre against the approved list and re-present
Any error while working an item — failed validation or an application/screen error	The recovery handler marks the to-do list entry as an exception with the reason Exception bubbled up from Object plus the technical detail, then resumes normal running and takes the next item. Retry count and "keep locked" behaviour are not set in the source.	Review flagged entries in QueueTrainingOrder, read the reason text, fix the underlying data or application issue, and decide whether to re-queue
Unrecoverable failure in the outer recovery block	Calls the Order System Exit action — the developer's note reads "Termionate Process and Exit" — and ends the run	Check whether the order application was left in a clean state; establish how many items were completed before the abort, then restart
Log In window absent within 5 s of launching the app	System exception: "Login Screen has not appeared"	Check the application is installed and starting normally on the runtime machine
Options (menu) window absent when selecting New Order	System exception: "Option Window does not exist"	Check the session is still logged in and no modal dialog is blocking the menu
New Order window absent after the menu selection, or before keying	System exception: "New Order Window does not exist"	Confirm menu option 1 still maps to New Order in the current application version
Order Confirmation window missing after Submit	System exception: "Order Confirmation Window does not exist"	Check in the application whether the order was actually created before re-submitting — there is a duplicate-order risk
Order Confirmation window still open after Continue is pressed	System exception: "Order Confirmation Window still exist even after clicking continue button"	Clear the dialog manually and check the order state

Data handled

Name	What it holds	Where it comes from
FilePath	C:\BluePrism\Training\Applications\Windows\Orders.csv — the order file to load	Fixed default in the process
Data	The table of order rows. First holds the whole worksheet read from the CSV; later holds the single order line claimed from the to-do list, with fields Product Code, Quantity, Unit Price, Cost Centre	Excel, then the to-do list
Item ID	The internal reference of the to-do list entry currently being worked. Blank means the list is empty. Used to mark the entry Completed or as an exception, and quoted in the Product Code error message	Returned when claiming the next entry from QueueTrainingOrder
Order Reference No	The order reference extracted from the Order Confirmation message after a successful submission	Read from the Training Order System confirmation window
Staff Number	Login identity for the Training Order System; defaults to bp	Process default
Password	Login password for the Training Order System; no default stored	Supplied at run time — source of supply not visible in the outline
Enable Events	Set to False so Excel opens the CSV without firing worksheet events	Process default
Handle / WorkBook Name	Internal references to the running Excel session and the opened workbook	Created when Excel is started and the file opened
QueueTrainingOrder	The shared to-do list of order lines awaiting entry, in progress, completed, or flagged as exceptions	Populated from the CSV at the start of each run

Not determinable from the source

• Schedule, run window and expected daily volume of order lines.
• Who supplies or refreshes Orders.csv, and whether the file is archived or deleted after loading.
• Who owns QueueTrainingOrder and whether it is cleared between runs — repeated loading of the same file could duplicate orders.
• What the captured Order Reference No is used for; it is never written to a file, e-mail or system in this process.
• The actual validation rules behind the four data checks (numeric ranges, permitted cost centres, etc.) — only the failure messages are exposed.
• The source of the Order System password (no default stored; likely a credential store not shown).
• Whether failed items are retried and how many attempts are allowed — the retry and "keep locked" settings are left unset.
• Whether the process genuinely loops back to claim the next item after marking one Completed; the loop-back is not drawn in the outline.
• The relationship (if any) between this process and the other, unrelated automations shipped in the same release: PIX_TU_Monitoring (PIX error-log extraction, Word-template mail merge, Outlook send), SAP_StockMonitoring_Process (SM37 and SE16N/MBEW extracts consolidated in Excel), SGate Password Reset and Set SPOA Role (SGate/BAT user administration), plus the SAP NMS/SM12 monitoring components. None of these is called by Create Orders, and their triggers and owners are not stated. See the Appendix for outline-level summaries.
• Which parts of the release were production-ready: several assets are empty placeholders (BAT User Status, Mainframe, SendMail) and several file paths point at one person's desktop (C:\Users\s.jyothi.avadhanam\...).

---

Appendix — other automations in the same release (outline level only)

These summaries are not runnable procedures. They record what each automation does, the values that matter operationally, and the points that are ambiguous, so that a full SOP can be commissioned for each. Triggers, schedules, owners and volumes are not stated anywhere in the source for any of them. Several hard-coded dates and file paths are clearly left over from development and would need to be parameterised before any rebuild.

A1. SAP_StockMonitoring_Process — stock comparison between two SAP systems

What it does: pulls a stock job list out of one SAP system ("AW"), pulls valuation data out of a second SAP system ("AE") using the material numbers from the first, and merges both into a single Excel workbook.

Reference value	Where used
Transaction SM37 (job overview)	AW system
Job Name *STOCK*, User Name *	SM37 selection
From Date 06.02.2017, To Date 07.02.2017	SM37 selection — hard-coded, almost certainly must become "today"/"yesterday"
Export file AW.xls	AW extract
Transaction SE16N (table display), table MBEW (material valuation)	AE system
Area no a190	AE selection screen
Directory C:\Users\s.jyothi.avadhanam\Desktop\SAP, file AE.xls	AE extract

Sequence:

1. Login AW — launch SAP, choose the AW system entry, enter user and password, then on SAP Easy Access enter transaction sm37 and confirm.
2. Job Selection — enter Job Name *STOCK* and User Name *, enter the job start/end date range, press Execute.
3. Generate AW Excel — open the spool for the resulting job list, choose the output type, export via Local file → Spreadsheet, save as AW.xls, then close SAP.
4. Login AE — launch SAP again, choose the AE system entry, enter credentials, enter transaction se16n.
5. Table Display — enter table name mbew, confirm, then click More (the multiple-selection dialog for material numbers).
6. Generate AE Excel — first run the Excel helper CopySAPData, which opens the AW workbook, applies formatting code to sheet 1 and copies the material list to the clipboard. Paste that list into the SE16N multiple-selection dialog, Execute, enter Area no a190, Execute again, then export via Export → Local file → Spreadsheet, saving to C:\Users\s.jyothi.avadhanam\Desktop\SAP\AE.xls. Close SAP.
7. Generate Final Data — run the Excel helper SAP_AWPMacrocode. It opens the AE workbook, runs a formatting/clean-up code step, saves it, reads the sheet back as a table, then opens the AW workbook and writes that table starting at cell M1 of sheet 1, applies number formatting to the "standard price" column, and saves.

Ambiguities: the exact content of the three inline code steps (the AW formatting, the AE clean-up, the standard-price number formatting) is not visible; the names "AW"/"AE" refer to SAP system entries in the SAP Logon pad, not documented further; credentials for both systems have no stored defaults; the final consolidated workbook is not e-mailed or filed anywhere in the source.

A2. PIX_TU_Monitoring — PIX dealer file-transfer error log and notification

What it does: logs into the PIX TU application, searches the error log from a given date, saves the errors to Excel, de-duplicates them, then for each error code pulls the matching standard wording out of a Word template and sends it to a mailing list via Outlook.

Reference value	Where used
PIX user name navisione	login
From Date 08.02.2017 (other copies default to 29.01.2017 / 02.02.2017)	error-log search — hard-coded
C:\Users\s.jyothi.avadhanam\Documents\Error_Code.xlsx	working file of extracted errors
C:\Users\s.jyothi.avadhanam\Desktop\PIX TU Error Log Monitoring Template.doc	Word template of standard error wording
Start marker Error 102 or 130 or 131 or 132, End marker Kind regards	text extraction boundaries in the Word template
C:\Users\s.jyothi.avadhanam\Desktop\MailList.xlsx	recipient list read into the Outlook To/CC fields
Subject Test	outgoing mail — clearly a placeholder

Sequence:

1. Login — launch PIX TU, click the user-name field and type the user name, click the password field and type the password, click OK.
2. Search Errors — click Error Log, type the From Date, click Search.
3. Read & Sort Error Log Table — wait up to 20 s for the results table, read it from the page, write it into a new Excel workbook (sheet "Sheet1", saved as Error_Code), then run the Excel helper PIXMacroCode, which opens Error_Code.xlsx and removes duplicate rows, saves and closes.
4. Extract Data from Template & Send Mail — read Error_Code.xlsx back as a table, then for each error row: open the Word template, extract the block of text between the start and end markers for that error code, close Word, and send it as the mail body.
5. Send Mail — attach to a window whose title ends - Outlook, activate it, click New Email, read the recipient list from MailList.xlsx, fill To, CC and Subject, click into the body, place the extracted text on the clipboard and paste it with Ctrl+V, then click Send.

Ambiguities: the default mail body stored in the Send Mail component is a full PIX support letter naming "error 102 (Error of SSL hand shake)" with blank Dealer Name:________ and Dealer Number:______________ fields — it is not clear whether those blanks are ever filled in automatically; how the per-error start marker is built from the error code is done in a calculation not shown; there is a near-duplicate component (PIX_ERROR_LOG) that performs the same job with the same file paths, and it is not stated which one is live.

A3. SGate Password Reset — reset a dealer/user password in SGate after a BAT status check

Reference value	Where used
User being reset: kintali.ashik (default)	BAT status check and SGate reset
C:\Users\s.jyothi.avadhanam\Desktop\BAT_Status.txt	file the BAT status is written to and read back from
Login language Englisch	SGate login
Gate condition: status text not equal to User is enabled.	decides whether the reset proceeds

Sequence:

1. BAT Login — launch the BAT tool, enter the BAT user name and password, click Login.
2. Check User Status in BAT — select the language, click Check User Integration, type the login name into the search field, click Search User, click User data normal, read the status value from the page and write it to BAT_Status.txt (overwriting).
3. Read the status back — read line 1 of BAT_Status.txt.
4. Decision — if the status is not "User is enabled." (i.e. the account is locked/disabled) then continue to the SGate reset. The source does not draw an explicit branch for the "already enabled" case, so what happens when the user is enabled is ambiguous and must be confirmed.
5. SGate Login — launch SGate, enter user name and password, set the language to English via the language selector, click Login.
6. Change Password — from the SGate menu: Menu → User Administration → Change Password; type the target user into the "Specify User" field and double-click Next. The screen library also contains a Perform Reset button, but no step in the outline presses it — confirm whether the reset is actually completed or whether the automation stops one click short.

A4. Set SPOA Role -SGate — assign SPOA roles to an SGate user

Reference value	Where used
Target user (Q number) qxo8154 (another copy defaults to QXK4832)	Edit User search
Login language Englisch	SGate login
Role list: input collection Test SPOA Roles — no default values stored	role assignment

Sequence:

1. SGate Login — as A3, step 5.
2. Home — click Menu → User Administration → Admin AG/NSC → Edit User.
3. Edit User — click the Q-Number field, type the target Q number, click Search.
4. Edit Role — click Edit Role, then in the role screen write the value "SGate User DE", loop through the supplied list of roles selecting each one in turn, click Continue to RAUS, then Save and View.

Ambiguity: the Select SPOA Role step also contains a call to a Create Dealer routine (search a dealer by AG number, add the BP-ID to the user, save and back) inside its recovery handling. Whether dealer creation is part of the normal role-assignment path or only a fallback is not clear from the outline and must be established before rebuilding. The list of roles to assign is supplied at run time from an unknown source.

A5. MaxDate — development scratch process (no business function)

A three-stage process containing a single calculation, a loop over a table, and a developer note reading only "new note". Its one stored value is a date, 19.01.2017 12:11:27. There is no application interaction, no file, no queue and no output. The similarly-named object sample (a login screen recorder plus a collection sort) is in the same category. Treat both as leftover development artefacts: no SOP is required, but confirm before deleting.

A6. Supporting components not called by any process

These exist in the release but no process in the release invokes them. They represent either work in progress or automations whose driving process was not shipped.

Component	What it can do	Notes
SAP_NMS_VBO	Logs into SAP (selecting the "NRI" system entry), opens transaction ST22 (runtime errors/dumps), enters a date range and user, ticks the Exception / Program / Components filters, runs it, reads the results table and discards every row whose client (MANDT) is not 010	Date range defaults 01.02.2017–14.02.2017
NMS_SM12_VBO	SAP basis monitoring across many transactions, each with its own developer note: SM12 lock entries ("Delete previous day locks"), SM66 ("Check the Work proccess which is taking more time to run which is in PRIV mode"), SM13 failed updates, SM37 cancelled jobs (exports the job list to a spreadsheet and extracts unique errors via Excel), SM21 system log ("search for database erros"), SMQ1 and SM58 ("Reprocessing stuck RFCs"), SP01 ("Finding numbder of Spool requests being proccessed and spool request with errors"), BD87 IDoc reprocessing on client 010	Default date ranges 01.02.2016–14.02.2017 etc. — all hard-coded
Credential lookup (used by both of the above)	Reads the SAP NMS user and password from a SQL Server database: server localhost\SQLExpress, database BMW_RPA, query select user_id,password from system_credentials where application_name='NMS';	This is the only database credential source in the release
BAT	Launch/login, check a user's integration status, write it to BAT_Status.txt, read it back	Used by SGate Password Reset (A3)
Send Mail	Drive Outlook to compose and send a message, recipients read from MailList.xlsx	Used by PIX_TU_Monitoring (A2)
ITSM / Citrix Login / WebApplication	Log into the ITSM incident system (search incident, show "Assigned To My Selected Groups"), log into Citrix and open the admin console, log into a web app	Not called by any process; incident ID INC000010707267 is a test value
BAT User Status, Mainframe, SendMail	Defined but contain no steps at all	Empty placeholders

---

How this SOP was checked

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

Covers the Create Orders process end-to-end and faithfully: launch/login of the Training Order System, Excel read of C:\BluePrism\Training\Applications\Windows\Orders.csv with Enable Events=False, bulk load into QueueTrainingOrder, Get Next Item with the correct [Item ID]<>"" branch (item → validate, no item → close app), the four validation checks with verbatim exception texts, menu option 1 → New Order → field mapping (Product Code / Number Required / Unit Price / Cost Centre) → Submit → confirmation read and reference extraction → Mark Completed, plus the 5s waits and their exact timeout error strings. Correctly flags what the source cannot support: the un-drawn loop back to Get Next Item, no persistence of Order Reference No, no queue clear-down, no schedule/volume/owner, password source. Not supported by SOP scope: the other executable processes in the same release.

1 correction from the audit was applied to the procedure above.

Remaining minor notes, not corrected:

• Exceptions and recovery table, row 'Any error while working an item' — States the recovery handler 'resumes normal running and takes the next item'. The outline shows Mark Exception followed by RESUME Resume2 but does not show the resume target; that it returns to Get Next Item is inference, and it is asserted as fact here even though the equivalent loop-back is caveated in Stage 9. (Say the handler marks the item as an exception and resumes execution; note that the resume destination is not visible in the source, consistent with the Stage 9 traceability caveat.)
• Exceptions and recovery table, row 'Unrecoverable failure in the outer recovery block' — Describes one recovery block as 'outer' and the Mark Exception block as inner. The source shows two peer blocks (Stage2/Recover1 and Stage3/Recover2) with nesting depth 1; no containment relationship between them is stated. (Describe them as two separate recovery handlers — one that marks the queue item as an exception and resumes, one that calls Order System Exit ('Termionate Process and Exit') and ends the run — without claiming a nesting hierarchy.)
• Stage 4 step 2 and exceptions table (retry / keep locked) — Says priority, tags, defer-until, status, retry and 'keep locked' are 'not set in the source — the platform defaults apply'. In the outline these parameters are shown as unresolved ('?'), which means their values could not be recovered, not that they were left blank. (Reword to: these parameters' values are not recoverable from the source outline; confirm against the live process before rebuilding.)