diff --git a/functional_tests/README.md b/functional_tests/README.md new file mode 100644 index 00000000..ebec36dc --- /dev/null +++ b/functional_tests/README.md @@ -0,0 +1,20 @@ +# Roost Generated Functional Test + +**Execution Date:** 1/7/2026, 6:47:29 AM + +**Test Unique Identifier:** "TCSBaNCS_functional-after-fix_clone" + +**Input(s):** + 1. tcsdoc1.docx + Path: /var/tmp/Roost/RoostGPT/TCSBaNCS_functional-after-fix_clone/c0b76230-ee8c-42c7-8d70-5705123405d1/tcsdoc1.docx + 2. tcsdoc2.docx + Path: /var/tmp/Roost/RoostGPT/TCSBaNCS_functional-after-fix_clone/c0b76230-ee8c-42c7-8d70-5705123405d1/tcsdoc2.docx + +**Test Output Folder:** + 1. [TCSBaNCS_functional-after-fix_clone.json](TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.json) + 2. [TCSBaNCS_functional-after-fix_clone.feature](TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.feature) + 3. [TCSBaNCS_functional-after-fix_clone.csv](TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.csv) + 4. [TCSBaNCS_functional-after-fix_clone.xlsx](TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.xlsx) + +--- + diff --git a/functional_tests/TCSBaNCS_functional-after-fix_clone/.roost/roost_metadata.json b/functional_tests/TCSBaNCS_functional-after-fix_clone/.roost/roost_metadata.json new file mode 100644 index 00000000..24a1938b --- /dev/null +++ b/functional_tests/TCSBaNCS_functional-after-fix_clone/.roost/roost_metadata.json @@ -0,0 +1,29 @@ +{ + "project": { + "name": "TCSBaNCS_functional-after-fix_clone", + "created_at": "2026-01-07T06:47:29.403Z", + "updated_at": "2026-01-07T06:47:29.403Z" + }, + "files": { + "input_files": [ + { + "fileName": "TCSBaNCS_functional-after-fix_clone.txt", + "fileURI": "/var/tmp/Roost/RoostGPT/TCSBaNCS_functional-after-fix_clone/c0b76230-ee8c-42c7-8d70-5705123405d1/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.txt", + "fileSha": "cf83e1357e" + }, + { + "fileName": "tcsdoc1.docx", + "fileURI": "/var/tmp/Roost/RoostGPT/TCSBaNCS_functional-after-fix_clone/c0b76230-ee8c-42c7-8d70-5705123405d1/functional_tests/TCSBaNCS_functional-after-fix_clone/tcsdoc1.docx", + "fileSha": "2cd5271236" + }, + { + "fileName": "tcsdoc2.docx", + "fileURI": "/var/tmp/Roost/RoostGPT/TCSBaNCS_functional-after-fix_clone/c0b76230-ee8c-42c7-8d70-5705123405d1/functional_tests/TCSBaNCS_functional-after-fix_clone/tcsdoc2.docx", + "fileSha": "55a242034e" + } + ] + }, + "api_files": { + "input_files": [] + } +} \ No newline at end of file diff --git a/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.csv b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.csv new file mode 100644 index 00000000..58bd0dd2 --- /dev/null +++ b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.csv @@ -0,0 +1,29 @@ +Place a local TASE equity Buy via Call Centre and authorize +TASE Buy lifecycle - executions, 1051/1052 recon, OD-SA matching under tolerance and idempotence +Foreign Equity Sell - broker cancel-and-average rebook, fees segregation, T+1 settlement and FX +UI - Security Transfer Outside Bank with relatives split and maker-checker +Transfer Outside Bank - File 15 to 1051 recon to 1052 settlement and lots movement +Mutual Fund purchase with auto price correction via 1051 Reverse and Reallocate +UI - Order Amendment on executed local equity with reversal and rebook +API - Verify amendment reversal and rebook postings and idempotence +Market Data entitlement matrix enforcement for Live vs Delayed +Self-transaction prevention across portfolios at BP-level with price logic +1054 Failed/Pending settlement handling with manual blocks and cancellation +Fractional orders batch settlement with transit deals and average price computation +Custody fee daily accrual recompute and quarterly application with messaging +Instrument setup and type mapping - Makam and Foreign ETF CRUD validations +Market Information rates - automated feed, errors, manual entries, CPI and lock override +UI - Extranet off-floor pre-blocks and manual capture authorization +API - Extranet recon and settlement with duplicate capture prevention +Incoming Security Transfer via File 132 - To Be Repaired to settlement +Delivery In/Out - ADR to Local security conversion with linked legs +POA restriction - Call Centre blocked, Front Office allowed +Pending order modification/cancellation matrix with disclosed qty and nostro cutoff +Positions reconciliation EOD - TASE 1053, APEX 871 and Tax Engine with ageing +Regulatory commission and fee reporting with SELL-only third-party handling and publication +Within-bank Securities Transfer - Virtual Sell with MU restriction and CA ex-date block +UI - MF manual price correction (Reverse and Reallocate) and recompute +TASE Net Settlement 32 and 1091 - store-only ingestion, recon toggle and late arrival +Distribution fee daily accrual and month-end packets with Kafka events +Third Party Transfers (Foreign custodian) - Delivery Out/In with reporting and manual settlement +FO daily re-placement for GFM At the Opening Stoplimit across days to expiry \ No newline at end of file diff --git a/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.feature b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.feature new file mode 100644 index 00000000..798fdf9b --- /dev/null +++ b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.feature @@ -0,0 +1,689 @@ +Feature: Multi-market trading, settlement, transfers, fees, reconciliation and entitlements + + # UI Tests + @ui @callcentre @tase @equity @buy + Scenario Outline: Place a local TASE equity Buy via Call Centre and authorize + Given I am logged in via SSO as 'Call Centre Agent' with entitlements for live local data + And I have selected customer with masked ID '****' and an active portfolio with sufficient buying power + And I am on the Order Entry (Equity) screen + When I select exchange 'TASE' and enter symbol '' + And I set side 'Buy', price condition 'Limit' with price '' ILS, quantity '', validity 'Good For Day' + And I click 'Place Order' + Then I should see pre-trade validation result '' + And on Preview I see estimated and detailed commission + When I tick 'I Agree' for commission and order and I click 'Confirm' + Then the order status should be 'Authorized' + And the Order Book should show the new order with status 'Placed with Market' or 'Authorized' as per routing + And the audit trail should capture 'OrderId' and 'SessionId' + + Examples: + | symbol | price | qty | validationOutcome | + | ABCD | 105.10 | 1000 | Passed with Info/Warn | + | ABCD | 105.10 | 1000 | Passed | + + # API Tests + @api @tase @equity @buy @execution @recon @settlement @gl @tax + Scenario Outline: TASE Buy lifecycle - executions, 1051/1052 recon, OD-SA matching under tolerance and idempotence + Given the API base URL is '${BASE_URL}' and authorization token is set + And a previously 'Authorized' order exists with orderId '${orderId}' for symbol 'ABCD' quantity '1000' limit '105.10' ILS + When I send a POST request to '/api/market/executions' with payload: + """ + { + "orderId": "${orderId}", + "fills": [ + { "qty": 400, "price": 104.90, "execId": "E1" }, + { "qty": 600, "price": 105.20, "execId": "E2" } + ], + "exchange": "TASE", + "tradeDate": "" + } + """ + Then the response status should be 200 + And the order status should be 'Executed' with averagePrice '105.08' + And custody and cash blocks should be adjusted and released for executed portions + When I send a POST request to '/api/files/ingest/1051' with payload: + """ + { + "businessDate": "", + "records": [ + { "symbol": "ABCD", "qty": 400, "price": 104.90, "execId": "E1" }, + { "symbol": "ABCD", "qty": 600, "price": 105.20, "execId": "E2" } + ], + "mode": "primary" + } + """ + Then the response status should be 202 + And the trade reconciliation status for order '${orderId}' should be 'Reconciled' using criteria 'Instrument,Quantity,ExecutionId,Price,TradeDate' + When I re-send a POST request to '/api/files/ingest/1051' with the same payload + Then the ingestion should be idempotent and no duplicate deals are created + When I send a POST request to '/api/files/ingest/1052' with payload: + """ + { + "businessDate": "", + "movements": [ + { "movementId": "M1", "eventId": "EV1", "symbol": "ABCD", "qty": 1000, "price": 105.08, "custodian": "LOCAL", "settlementType": "DVP", "currency": "ILS" } + ] + } + """ + Then the system should create Settlement Advice and auto-match with Open Delivery within tolerance '0.50' ILS + And OD and SA matching status should be 'Settled' + When I run the 'Street Settlement Batch' and 'Customer Settlement Batch (Actual)' + Then GL batch should post 'Debit Customer Cash','Credit Nostro Cash','Credit Fee Income' in ILS with correct TD/VD and no suspense + When I send a POST request to '/api/tax/eod/send-movements' with payload: + """ + { "businessDate": "", "orders": ["${orderId}"] } + """ + Then the tax engine response status should be 200 and a 'TaxFileId' should be recorded + When I re-send the same 1052 payload + Then Settlement Advice creation should be idempotent and no duplicate postings occur + And reports '1051 recon', '32/1091 store', 'RSP34290' should show no mismatches + And the audit trail should include 'OrderId','DealId','OpenDeliveryId','SettlementAdviceId','GLBatchId','TaxFileId' + + Examples: + | tradeDate | settleDate | + | 2026-01-02 | 2026-01-05 | + + @api @nyse @equity @sell @averageRebook @fees @multiccy @settlement @tax + Scenario Outline: Foreign Equity Sell - broker cancel-and-average rebook, fees segregation, T+1 settlement and FX + Given the API base URL is '${BASE_URL}' and authorization token is set + And a SELL order exists on NYSE for 'KMT.N' qty 500 with partial executions on '' + When I send a POST request to '/api/files/ingest/broker-order-summary' with payload: + """ + { + "businessDate": "", + "orders": [ + { + "brokerOrderRef": "B123", + "symbol": "KMT.N", + "side": "SELL", + "avgPrice": 56.05, + "currency": "USD", + "fees": { "brokerCommission": 12.34, "SEC": 1.23, "TAF": 0.75 } + } + ] + } + """ + Then original executions should be cancelled and one average deal rebooked + And OD status should be 'Matched' + And fee handling should post SEC to Third Party Payable, customer ST Commission to Fee Income, brokerCommission and TAF to Fee Expense + When I run the 'Foreign Street Settlement Batch' for '' + Then street-side cash movements should post in USD and FX translation to ILS should be recorded per rules + When I run the 'Customer Settlement Batch' for '' + Then postings should occur on value date with TD/VD stamps and correct FX conversions + And recon vs broker file should be 'Reconciled after rebook' + And reports include broker commission with SEC and TAF + And TAF cap differences are flagged for refund workflow (no auto cap) + When I send a POST request to '/api/tax/eod/send-movements' with payload: + """ + { "businessDate": "", "orders": ["${orderIdSell}"] } + """ + Then SELL tax should be calculated on settlement date and positions align in tax-engine reconciliation + + Examples: + | tradeDate | settleDate | + | 2026-01-07 | 2026-01-08 | + + @ui @backoffice @transfer @outsideBank @makerChecker + Scenario Outline: UI - Security Transfer Outside Bank with relatives split and maker-checker + Given I am logged in as 'Branch Maker' at the home MU and on Transfers > Security Transfer + And I select TASE positions for symbol '' and default full available quantity + When I click 'Add Beneficiary' and choose 'Outside Bank' + And I add two beneficiaries with splits '60' and '40' and bank/branch codes and accounts provided + And I uncheck 'Same Entity' and select Transfer Case 'Transfer between relatives' subcase 'Spouse of a sister/brother' + And I click 'Verify' + Then validations should pass: only TASE allowed, branch filtered, fractional permitted, order date read-only today + When I Preview, print commission quote, tick 'I Agree' and click 'Release' + Then the transaction is routed to Checker1 with remarks and appears in Authorization Queue + When 'Checker1' approves and escalates to 'Checker2' and 'Checker2' approves + Then the status becomes 'U-Authorized' and audit trail shows 'TransferOrderId' and 'AuthorizationIds' + + Examples: + | symbol | + | ABCD | + + @api @tase @transfer @files @recon @settlement @lots @tax + Scenario Outline: Transfer Outside Bank - File 15 to 1051 recon to 1052 settlement and lots movement + Given the API base URL is '${BASE_URL}' and authorization token is set + And a U-Authorized transfer order exists with two split legs for symbol 'ABCD' + When I run the 'BOD File 15' generator for '' + Then a File15Id should be produced and sent to TASE + When I ingest 1051 on '' + Then reconciliationStatus should be 'Reconciled' at order level + When I ingest 1052 on '' + Then Settlement Advice should be created and auto-matched with Open Delivery within tolerance '1.00' ILS and statuses set to 'Settled' + And custody blocks are removed and DR movements written + And lots/layers moved to beneficiaries and taxIdentifierFlag set to 1 + When I send a POST request to '/api/tax/eod/send-movements' with payload: + """ + { "businessDate": "", "transfers": ["${TransferOrderId}"] } + """ + Then GL postings should reflect 'Debit Transfer Fee','Credit Fee Income','Security DR/CR between internal transfer accounts' with proper TD/VD + + Examples: + | bodDate | bodDatePlus1 | settleDate | + | 2026-01-02 | 2026-01-03 | 2026-01-03 | + + @api @mutualfund @tase @autoPriceCorrection @allocation @recon @settlement @tax + Scenario Outline: Mutual Fund purchase with auto price correction via 1051 Reverse and Reallocate + Given the API base URL is '${BASE_URL}' and authorization token is set + And an MF order exists for fund 'XYZ' with units 1000 + When I ingest 1051 allocation for '' at NAV_T 10.000 + Then allocation should be created and contractual customer cash settlement scheduled for T+1 at 17:30 + When I run 'Customer Settlement Batch' on '' + Then cash debit principal + commission should be posted with TD/VD + When I ingest 1051 price correction on '' with new NAV 10.050 and reverse+reallocate + Then the prior allocation is reversed (movements only) and a new allocation booked at corrected NAV without duplication + When I ingest 1052 on '' + Then street side settlement completes and OD/SA are 'Settled' + And GL and tax reflect corrected price and idempotence prevents duplicate SA + And MF Order Book shows 'Allocation','Reversed','Reallocated','Settled' + + Examples: + | tradeDate | contractualDate | + | 2026-01-05 | 2026-01-06 | + + @ui @backoffice @amendment @makerChecker + Scenario Outline: UI - Order Amendment on executed local equity with reversal and rebook + Given I am logged in as 'Back Office Operator' and on BO > Order Amendment + When I set Amendment Type 'Non-Derivative' and Amendment For 'ExistingOrder' + And I enter executed Order Id '' and source portfolio '' + And I select checkboxes 'Price' and 'Portfolio' and set corrected limit price '104.80' and Correction Portfolio '' + And I provide remarks and click 'Save' to trigger workflow + Then exceptions route to Checker1 and I assign to Checker1 + When Checker1 approves and limits escalate to Checker2 and Checker2 approves if required + Then amendment status should be 'Completed' with audit links to original and amended entities + + Examples: + | origOrderId | sourcePortfolio | targetPortfolio | + | ORD-12345 | P-1111 | P-9999 | + + @api @backoffice @amendment @reversal @rebook @tax + Scenario Outline: API - Verify amendment reversal and rebook postings and idempotence + Given the API base URL is '${BASE_URL}' and authorization token is set + When I GET '/api/orders//amendment/status' + Then the response status should be 200 and 'state' should equal 'Completed' + When I GET '/api/orders//postings' + Then I should see reversal entries exactly negating principal, fees and tax with correct TD/VD + When I GET '/api/orders//postings' + Then I should see new postings for corrected deal hitting GLs 'Customer Cash','Nostro Cash','Fee Income/Expense' + When I re-apply amendment via POST '/api/orders//amend' with identical payload + Then the response status should be 409 and error 'idempotent' and no duplicate reversals or rebookings are created + When I POST '/api/tax/eod/send-movements' with payload: + """ + { "businessDate": "", "orders": ["",""] } + """ + Then tax postings should show prior items reversed and recomputed for corrected deal + + Examples: + | origOrderId | newOrderId | eodDate | + | ORD-12345 | ORD-12345A | 2026-01-07 | + + @ui @entitlements @marketdata @profiles + Scenario Outline: Market Data entitlement matrix enforcement for Live vs Delayed + Given I am logged in via SSO as 'Call Centre Agent' using entitlement profile '' + And I open Market Watch and add TASE 'ABCD' and NYSE 'KMT.N' + When I 'Get Quote' for 'ABCD' + Then I should see '' and depth actions '' + When I 'Get Quote' for 'KMT.N' + Then I should see '' and depth actions '' + When I open Order Entry for 'KMT.N' + Then the top-of-panel quote shows '' + When I open Order Entry for 'ABCD' + Then Order Quote and Depth are '' + And Index Watch shows indices 'Live' irrespective of profile + And Top Gainers/Losers shows delayed list with footer 'Prices are delayed by 20 minutes' + When I switch to entitlement profile '' + Then foreign quotes and depth now show 'Live' and delayed banners disappear + And E-Journal and audit entries exist for entitlement changes and widget access + + Examples: + | profile | localTag | localDepth | foreignTag | foreignDepth | foreignPanelWatermark | localPanelState | profileSwitch | + | PROFILE-A | Live | Enabled | Delayed | Disabled | Delayed | Live | PROFILE-B | + + @ui @negative @tase @selfTransaction + Scenario Outline: Self-transaction prevention across portfolios at BP-level with price logic + Given I am logged in as 'Call Centre Agent' and authenticated BP '****' with portfolios P1 and P2 + And in P1 I place a Buy Limit for 'ABCD' qty 1000 at 100.00 ILS and it is 'Authorized' then 'Placed with Market' + When I switch to P2 and place a Sell '' for 'ABCD' qty 200 with price '' and click 'Confirm' + Then I should see '' and '' if blocked + When P1 order is partially executed 400 @ 100.00 + And in P2 I try Sell Limit at 99.90 + Then I should see 'Blocked' and 'Self-Transactions are not allowed in TASE' + When P1 order is fully executed + And in P2 I place a Sell Market for 200 + Then the order is accepted and sent to market + And audit logs show single blockage attempts and BP-level application with no override workflow permitted + + Examples: + | sellType | sellPrice | expectedResult | errorMsg | + | Market | 0 | Blocked | Self-Transactions are not allowed in TASE | + | Limit | 99.90 | Blocked | Self-Transactions are not allowed in TASE | + | Limit | 101.00 | Accepted | | + + @api @tase @1054 @failPending @reversal @idempotence + Scenario Outline: 1054 Failed/Pending settlement handling with manual blocks and cancellation + Given the API base URL is '${BASE_URL}' and authorization token is set + And an executed Buy deal exists for 'ABCD' with 'DealId' and 'OpenDeliveryId' + When I ingest 1054 on '' marking the trade as '' + Then reconciliationStatus on deal and OD updates to '' and alerts raised + When I create a manual custody block equal to executed quantity + Then customer Actual settlement batch should not post client-side settlement for this OD + When I initiate Cancel for the failed order via '/api/st-orders//cancel' and obtain Checker1 approval + Then reversal movements for principal, fees, and tax are posted with TD/VD + And OD/SA linkage is removed and OD excluded from future matching + When I re-upload the same 1052 for this OD + Then idempotence prevents SA creation + When I re-ingest the same 1054 file + Then no duplicate state changes occur and audit logs single processing instance + And GL balances reflect net zero and tax engine reverses prior provisional items + + Examples: + | tPlus1 | status1054 | + | 2026-01-06 | Failed | + | 2026-01-06 | Pending | + + @api @tase @fractions @transitDeal @batch + Scenario Outline: Fractional orders batch settlement with transit deals and average price computation + Given the API base URL is '${BASE_URL}' and authorization token is set + And two SELL orders executed on '' produced fractional leftovers totaling non-integer units + When I ingest 1052 on '' + Then integer portions settle and fractions remain outstanding + When I run 'Fractional Settlement Batch' post-1052 + Then a Transit Deal is created between customer and bank fraction portfolio for exact fractional quantities + And average price equals weighted average execution price of sells on '' in ILS with rounding per rules + And GL posts 'Credit Customer Securities','Debit Internal Fraction Portfolio' with no suspense + And duplicate prevention keys avoid multiple transit deals on reruns + And RSP34400 reflects instrument, fractional quantity, average price, parent orders, and GL batch reference + + Examples: + | tradeDate | tPlus1 | + | 2026-01-05 | 2026-01-06 | + + @api @fees @custody @accrual @quarterly @idempotence + Scenario Outline: Custody fee daily accrual recompute and quarterly application with messaging + Given the API base URL is '${BASE_URL}' and authorization token is set + When I run 'Custody Daily Accrual' for '' + Then accruals are computed per security with tiering and caps and FX applied where required + When a back-dated trade correction on '' affects Day '' + And I run 'Custody Daily Accrual Recompute' + Then Day '' accrual is adjusted by delta without double-counting + When I run 'Quarterly Aggregation' at quarter end '' + And I execute 'Apply Custody Fees' + Then customer cash is debited and Fee Income credited with TD/VD + And messages '77' and '425' are generated and delivered + And RSP34390 reconciles with GL + When I rerun 'Apply Custody Fees' for the same quarter + Then idempotence prevents duplicate debits + + Examples: + | dayD | dayDPlus2 | quarterEnd | + | 2026-01-03 | 2026-01-05 | 2026-03-31 | + + @ui @backoffice @instrumentSetup @makerChecker + Scenario Outline: Instrument setup and type mapping - Makam and Foreign ETF CRUD validations + Given I am logged in as 'Back Office Admin' and on Financial Instruments + When I trigger auto-ingestion for TASE and select a new Makam + Then the system maps to type '54' TBills with faceValue, poolFactor, couponType 'None', currency 'ILS' + When I set rate type parameters (Price in Percentage, Clean vs Dirty) and CPI linkage and Save + Then Checker1 approves and instrument status becomes 'Authorized' with InstrumentId and AuthorizationId captured + When I create a new Foreign ETF manually (exchange NYSE, currency USD) with instrumentType '229', lotSize 1, priceDecimals 4, quantityDecimals 3 and route for approval + Then Checker1 approves and ETF is Authorized + When I attempt to create a duplicate instrument with same ISIN/Ticker + Then I should see error 'INSTR_DUP_KEY' + When I edit the ETF to change quantityDecimals to '6' and priceDecimals to '6' + Then change is accepted + When I set quantityDecimals to '7' or priceDecimals to '7' + Then I should see error 'DEC_PRECISION_EXCEEDED' + When I deactivate the ETF with no holdings and then reactivate + Then both state changes are captured in E-Journal + When I attempt to delete the Makam with a dummy reference present + Then delete is blocked with 'INSTR_IN_USE' and only Deactivate permitted + And in Call Centre Order Entry and Advanced Search authorized active instruments appear and Draft/Deactivated remain hidden + + Examples: + | | + | placeholder| + + @api @marketInfo @rates @idempotence @manualOverride @valuation + Scenario Outline: Market Information rates - automated feed, errors, manual entries, CPI and lock override + Given the API base URL is '${BASE_URL}' and authorization token is set + When I POST '/api/mi/feeds/ingest' with payload: + """ + { "source": "TASE", "businessDate": "", "rows": [ { "symbol":"ABCD", "price": 101.23, "currency":"ILS" } ] } + """ + Then feed loads with provenance 'Feed' + When I re-upload the same feed file + Then idempotence prevents duplicate rows and CTRLM logs 'Duplicate Ignored' + When I POST '/api/mi/feeds/ingest' with payload missing price for a symbol + """ + { "source": "TASE", "businessDate": "", "rows": [ { "symbol":"EFGH", "currency":"ILS" } ] } + """ + Then bad record is rejected with error 'RATE_MISSING_FIELD' and others processed + When I POST '/api/mi/feeds/ingest' with invalid currency for ETF + """ + { "source": "Bloomberg", "businessDate": "", "rows": [ { "symbol":"KMT.N", "price": 56.2000, "currency":"EUR" } ] } + """ + Then record fails with 'RATE_CCY_MISMATCH' and prior good rate is not overwritten + When I POST '/api/mi/manual/single' with payload: + """ + { "symbol": "MAKAM-XYZ", "cleanPrice": 99.876, "cpiIndex": 1.012, "provenance": "Manual Single" } + """ + Then Portfolio Valuation should use CPI-adjusted value + When I POST '/api/mi/manual/mass' with payload: + """ + { "rows": [ + { "symbol": "ABCD", "price": 0.01 }, + { "symbol": "EFGH", "price": 0.00 }, + { "symbol": "KMT.N", "price": 9999999.01 } + ] } + """ + Then 0.00 and >9,999,999.00 should be rejected with 'PRICE_THRESHOLD_BREACH' and decimals validated per instrument rules + When I POST '/api/mi/override/lock' with payload: + """ + { "symbol": "ABCD", "price": 102.00, "lock": true } + """ + And I ingest a new feed containing 'ABCD' + Then locked manual price is not overwritten and provenance remains 'Manual Override' + When I run 'valuation refresh' for '' + Then affected portfolios reflect new rates in account currency using FX and TD/VD preserved + When I POST '/api/mi/feeds/ingest' with prior-date file after EOD + """ + { "source":"TASE", "businessDate":"", "rows":[ { "symbol":"ABCD","price": 100.00, "currency":"ILS" } ] } + """ + Then rows go to historical table per policy without changing today's rates + + Examples: + | bizDate | priorDate | + | 2026-01-06 | 2025-12-30 | + + @ui @callcentre @extranet @blocks + Scenario Outline: UI - Extranet off-floor pre-blocks and manual capture authorization + Given I am logged in as 'Call Centre Agent' and on Fund Balance + When I place a '' block for expected extranet trade and record Block Reference + Then block should be visible in balances + Given I am logged in as 'Back Office Operator' on Manual Trade Capture + When I select order category 'Extranet transaction out of exchange' and enter instrument, side, quantity, price and portfolio + And I preview fees and confirm + Then the trade is routed to Checker1 if limits exceeded + When Checker1 approves + Then deal and Open Delivery are created and trade trail indicates 'Extranet category' + And I expire previously placed blocks and verify balances update + + Examples: + | blockType | + | Cash | + | Custody | + + @api @tase @extranet @recon @settlement @idempotence + Scenario Outline: API - Extranet recon and settlement with duplicate capture prevention + Given the API base URL is '${BASE_URL}' and authorization token is set + When I ingest 1051 for '' showing extranet trade without corresponding order + Then reconciliationStatus is 'Not Matched' and flagged on exception report + When on '' I confirm manual BO trade capture exists with 'ManualDealId' + And I ingest 1052 for '' + Then system creates SA and auto-matches OD and SA under tolerance and sets status 'Matched' + When I run 'Street Settlement' and 'Customer Settlement' + Then postings occur on settlement date with correct TD/VD, GL double-sided Nostro/Customer per business event + When I attempt to capture the same extranet trade again with identical instrument/qty/price + Then the API responds 409 with error 'EXTN_DUP_TRD' and no duplicate is created + + Examples: + | tradeDate | tPlus1 | settleDate | + | 2026-01-05 | 2026-01-06 | 2026-01-06 | + + @api @tase @transferIn @file132 @repair @settlement @idempotence + Scenario Outline: Incoming Security Transfer via File 132 - To Be Repaired to settlement + Given the API base URL is '${BASE_URL}' and authorization token is set + When I ingest File 132 at BOD for '' containing one good and two error records + Then Delivery In orders are created: one 'Authorized', two 'To Be Repaired' + Given I open the Incoming Transfer Repair screen as 'Back Office Operator' + When I repair record A by mapping missing security + And I repair record B by aligning layers to order quantity + And I repair record C by correcting beneficiary identifiers + And I route for authorization and Checker1 approves + Then state moves from 'To Be Repaired' to 'Authorized' and custody blocks applied + When I ingest 1051 and then 1052 + Then SA is created and matched with OD and statuses are 'Settled' + And lots are transferred and taxIdentifierFlag derived appropriately, and EOD tax feed sent + When I retry ingesting the same File 132 + Then duplicates are ignored and no new postings occur + + Examples: + | bodDate | + | 2026-01-05 | + + @ui @backoffice @delivery @conversion @linkedLegs + Scenario Outline: Delivery In/Out - ADR to Local security conversion with linked legs + Given I am logged in as 'Back Office Operator' + When I create a Delivery Out with Delivery Type 'ADR to Local Sec Conversion' and External Reference 2 'CONV-REF-123' + And I create a Delivery In with Delivery Type 'ADR to Local Sec Conversion' and External Reference 2 'CONV-REF-123' + And I submit both legs for approval + Then Checker1 approves and both orders become 'Authorized' and ODs created and linkage stored + When I authorize/ingest Settlement Advice(s) or 1052 + And I auto-match or manually match OD/SA for both legs using 'Instrument,Custodian,Settlement Type,Quantity' and Amount zero/tolerance + Then both legs 'Settled', ADR position reduced and local position increased by converted quantity + And no duplicate SA/matching allowed when retrying with same External Reference 2 + And audit and reports show linkage by CONV-REF-123 + + Examples: + | | + | placeholder| + + @ui @negative @poa @channelRestrictions + Scenario Outline: POA restriction - Call Centre blocked, Front Office allowed + Given I am logged in as 'Call Centre Agent' acting as POA for a customer + When I open Order Entry for 'ABCD' and set Buy Limit 100.00 ILS qty 200 and click 'Place Order' + And I proceed to Confirm + Then order placement is blocked with error 'POA_CC_BLOCK' and no order id or blocks are created + And no authorization workflow can override this restriction + When I log in as 'Front Office User' acting as the same POA and place the same order + Then the order is 'Authorized' then 'Placed with Market' and appears in Order Book + And audit shows channel='FO' role='POA' and user ids + And PII is masked on screens and exports + When I attempt an MF Purchase via Call Centre as POA + Then the same restriction applies with 'POA_CC_BLOCK' + + Examples: + | | + | placeholder| + + @ui @orderManagement @modifyCancel @disclosed @stoplimit @cutoff + Scenario Outline: Pending order modification/cancellation matrix with disclosed qty and nostro cutoff + Given I am logged in as 'Call Centre Agent' + And I place a Buy Stoplimit order for 'ABCD' qty 1000, disclosed Initial 200 Additional 100, triggerPrice 99.80, limitPrice 100.00, validity 'Good For Month' + Then status is 'Authorized' then 'Placed with Market' + When I modify price condition to 'Market' keeping validity GFM and accept warning + Then modification is saved and trail updated + When I modify disclosed quantities to Initial 300 and Additional 200 + Then validations pass (Initial <= total, Initial+Additional <= total) and modification saved + When a partial execution of 250 units occurs + Then open quantity is 750 and blocks update proportionally + When I attempt to increase total quantity to 1200 after partial fill + Then I see error 'QTY_INC_AFTER_PARTIAL_NOT_ALLOWED' and no change applies + When I modify validity to 'Good For Day' near end of trading + Then expiry date updates and alerts shown + When I cancel the order + Then remaining open qty is cancelled and state changes to 'Cancelled' + Given I create a Sell Limit and leave it pending beyond 'nostro open order cutoff' + When the cutoff job runs + Then the order is auto-cancelled or blocked per setup and an operational alert is logged + And E-Journal and auditTrail show modifications, cancellations, cutoff action + + Examples: + | | + | placeholder| + + @api @positions @recon @1053 @871 @tax @ageing @idempotence + Scenario Outline: Positions reconciliation EOD - TASE 1053, APEX 871 and Tax Engine with ageing + Given the API base URL is '${BASE_URL}' and authorization token is set + When I ingest TASE 1053 for '' and APEX 871 and Tax Engine Open Positions + And I execute Reconciliation job + Then matched items move to 'Reconciled' and unmatched to 'Not Matched' and counts by source are captured + When I introduce mismatches and rerun recon + Then exceptions appear with state 'Failed' and ageing 'Day-0' + When I advance business date and re-ingest the same files + Then duplicates are ignored and ageing increments to 'Day-1' + When I perform a manual position correction and mark exception 'Repaired' and rerun recon + Then item moves to 'Reconciled' and audit logs include 'RepairActionId' + When I mark an extra foreign position as 'External Only' or align via manual movement + Then state transitions to 'Closed Manually' and excluded from further ageing + When I re-ingest corrected tax positions file + Then exceptions auto-resolve to 'Reconciled' + And recon reports show states and ageing buckets with PII masking + When I inject a late prior-date 1053 after EOD + Then it posts to historical store without changing today's statuses + + Examples: + | eodDate | + | 2026-01-06 | + + @api @fees @regulatory @814 @815 @414 @idempotence + Scenario Outline: Regulatory commission and fee reporting with SELL-only third-party handling and publication + Given the API base URL is '${BASE_URL}' and authorization token is set + And settled trades exist across Equity, ETF, MF with various fee items for period '' + When I run 'Fee Aggregation' for '' + Then computed fees respect basis, min/max caps and tiers + When I generate TASE 814 (and 815 if applicable) + Then 'averages' match computed averages and 'price list' reflects configured tariffs and files stored with run ids + When I generate BOI 414 A/B/C customer packets + Then packets contain the correct data per type and 414-A is published to website with PII masking + And SELL-only SEC/TAF appear only on SELL foreign equity marked Third Party and excluded from bank income totals with GL mapping to Third Party Payable + When I include boundary trades below min and above max + Then applied amounts equal min or max and reported consistently + When I rerun reporting batches for the same period + Then idempotence prevents duplicate files or versions without duplicate accounting (error 'DUP_PERIOD_IGNORED' or versioned) + And totals reconcile with GL Fee Income and Third Party Payable + + Examples: + | period | + | 2025-Q4 | + + @ui @backoffice @transfer @virtualSell @muRestriction @caExDate + Scenario Outline: Within-bank Securities Transfer - Virtual Sell with MU restriction and CA ex-date block + Given I am logged in as 'Branch Maker' at a non-home MU + When I open Transfers > Security Transfer and attempt initiation + Then I see 'MU_HOME_BRANCH_REQUIRED' and no draft is created + When I log in at home MU and select a security on CA ex-date + And I choose Within Bank and tick 'Virtual Sell' + And I click 'Verify' + Then I see 'CA_EXDATE_BLOCK' and no custody blocks applied + When I select a different TASE security without CA ex-date and keep full quantity + And I Preview, tick 'I Agree' and 'Release' assigning to Checker1 + Then Checker1 approves and status is 'U-Authorized' + When EOD process runs + Then transfer auto-settles within bank, custody blocks removed, only security movements via internal control posted + And EOD tax sets taxIdentifierFlag=1 and audit shows MU ids and Virtual Sell flag + + Examples: + | | + | placeholder| + + @ui @mutualfund @manualPriceCorrection @makerChecker + Scenario Outline: UI - MF manual price correction (Reverse and Reallocate) and recompute + Given I am logged in as 'Back Office Operator' on MF Allocation Reversal/Execution Handling + When I search fund 'XYZ' and date '' and view AllocationId and GLBatch reference + And in Market Information I update rate to corrected NAV '' for '' and note RateBatchId + And I select action 'Reverse' (movements only) and submit for authorization + Then Checker1 approves and allocation status sets to 'Reversed' + When I initiate 'Reallocate' at corrected NAV, route for approval, and Checker1 approves + Then AllocationId2 is created and idempotence prevents repeating without new rate change (error 'ALLOC_CORR_ALREADY_APPLIED') + When 1052 is ingested on T+1 + Then street-side settlement posts once against the corrected allocation and duplicate SA is prevented + And GL and tax recompute correctly and reports and Kafka events reflect correction + + Examples: + | tradeDate | navCorr | + | 2026-01-05 | 10.050 | + + @api @tase @netSettlement @32 @1091 @storeOnly @toggle @idempotence + Scenario Outline: TASE Net Settlement 32 and 1091 - store-only ingestion, recon toggle and late arrival + Given the API base URL is '${BASE_URL}' and authorization token is set + When I set 'ReconEnabledForTASEFees' to 'No' + Then audit records the toggle and processing mode is 'Store Only' + When I ingest File 32 interim (Type C) for '' + Then rows are stored with FileBatchId32A and no recon executed + When I ingest File 1091 for '' + Then rows stored with FileBatchId1091A augmented with portfolio, type and subtype and no GL/fee recompute triggered + When I generate 32 store report + Then report is based on last file with INTERIM watermark and no reconciliation status + When I re-ingest the same interim files + Then idempotence logs 'DUP_FILE_IGNORED' + When I ingest File 32 final (Type D) for '' + Then prior interim is superseded for reporting and finalized with FileBatchId32B tagged FINAL + When I set 'ReconEnabledForTASEFees' to 'Yes' and load fee schedule and run Recon job + Then differences at trade level are computed using 1091 vs system and min/max cap cases highlighted + When I upload a malformed 1091 with missing field + Then bad rows rejected with 'FILE_FIELD_MISSING' and skip items created + When I inject prior-date final 32 after EOD + Then it is stored historically without changing today's reporting or recon outcomes + And exported reports show PII masking and FINAL tags with run timestamp + + Examples: + | bizDate | + | 2026-01-06 | + + @api @distributionFee @accrual @monthEnd @kafka @idempotence + Scenario Outline: Distribution fee daily accrual and month-end packets with Kafka events + Given the API base URL is '${BASE_URL}' and authorization token is set + When I run 'Distribution Fee Daily Accrual' for day '' + Then accrual per fund uses NAV_D and FX to ILS and AccrualRunId stored and exemptions applied (money market zero, no-agreement not billed) + And boundary cases (zero holdings = zero, large position capped) are applied and stored + When I advance through the month including leap-day if applicable and run daily accruals + Then weekend/holiday behavior follows config and totals maintain continuity + When I run 'Month-End Packet Generator' for '' + Then per fund per manager CSV/PDF packets generated and delivered via secure email and Kafka events emitted with metadata and no PII + And BO summary report reconciles with GL policy (Fee Income posted monthly or memo-only) + When I rerun Month-End generator for the same period + Then idempotence or versioning applies without duplicate accounting (error 'DUP_PERIOD_IGNORED' or new version) + When I alter one day’s accrual by back-dated position correction and rerun recompute + Then month total adjusts and a new packet version is generated with audit retained + + Examples: + | dayD | period | + | 2026-02-01 | 2026-02 | + + @ui @backoffice @thirdPartyTransfer @manualSettlement @makerChecker + Scenario Outline: Third Party Transfers (Foreign custodian) - Delivery Out/In with reporting and manual settlement + Given I am logged in as 'Back Office Operator' on Create Securities Transfer Order + When I choose '' for foreign instrument 'ABC.N' in USD with quantity including fractional if supported + And I set Transfer Case 'Third party Transfer' and enter beneficiary custodian details in external reference + And I tick 'I Agree' and 'Release' and assign to Checker1 + Then Checker1 approves and status is 'U-Authorized' and 'Not Sent to TASE' marker present and custody block applied + When I generate Third Party Transfer report extract + Then record shows masked PII with portfolio id, instrument, quantity, expected deliver date and beneficiary fields + When custodian confirms off-system and I post Manual Settlement movements + Then for Delivery Out: reduce customer securities and post to Internal Transfer Control with proper TD/VD and valuation FX if needed + And for Delivery In: increase customer securities and reverse internal control and lots captured with Same Entity not applied + When I attempt to repost manual settlement for the same external reference + Then system blocks with 'DUP_EXT_REF' and no duplicate postings occur + And Security Transfer History shows 'Settled' and audit entries for both legs + + Examples: + | transferType | + | Delivery Out | + | Delivery In | + + @ui @frontoffice @rePlacement @stoplimit @validity @expiry + Scenario Outline: FO daily re-placement for GFM At the Opening Stoplimit across days to expiry + Given I am logged in as 'Call Centre Agent' with FO–BO integration active + When I place a Buy Stoplimit for 'ABCD' trigger 99.80, limit 100.00, qty 1200, validity 'Good For Month', release 'At the Opening' + Then status is 'Authorized' then 'Placed with Market' (At the Opening Day 1) and cash block equals consideration + fees + When Day 1 opens below trigger then rises above trigger but below limit with no fill + Then order remains Pending and cash block remains + When EOD occurs with no fills + Then FO re-queues order for Day 2 At the Opening and trail shows 'Re-Placement by FO' with reference to child submission if applicable + When on Day 2 partial execution 300 @ 99.95 occurs + Then status 'Partially Executed' open qty 900 and block decreases proportionally and recon vs 1051 pending until file arrival + When I modify trigger to 100.00 equal to limit + Then decision-table allows equality or warning is accepted and FO uses updated trigger from next day + When on Day 10 open price above limit 100.20 and 600 executes + Then open qty 300 remains and state/history reflects multi-day partials + When liquidity prevents remaining fills until expiry + Then FO continues daily submission; on expiry the order auto-expires and blocks are released and E-Journal shows Auto-Expiry + When I attempt to manually re-place the expired order + Then the system requires a new order and blocks reuse with 'ORDER_EXPIRED_REUSE_NOT_ALLOWED' + And auditTrail includes FO re-placement entries, modifications, executions and expiry + + Examples: + | | + | placeholder| diff --git a/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.json b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.json new file mode 100644 index 00000000..1a92c501 --- /dev/null +++ b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.json @@ -0,0 +1 @@ +[{"type":"end-to-end","title":"Local TASE Equity Buy - Full E2E from Order to Settlement, Accounting and Tax","description":"Place a TASE equity Buy order via Call Centre and verify lifecycle: validations, partial and full executions, 1051 trade recon, OD-SA matching with 1052 under tolerance, customer settlement (Actual), accounting, tax engine postings, and reconciliations.","testId":"TC-TASE-LOCAL-E2E-001","testDescription":"High-risk local market flow validating state transitions, file interface idempotence, tolerance, movements, GL, and tax.","prerequisites":"Customer portfolio active with sufficient buying power, entitlements live for order quote and depth, instrument listed on TASE, fee schedule configured, accounting rules mapped for Buy Client and Buy Broker, custodian tolerance configured, tax engine connectivity up, maker-checker limits defined.","stepsToPerform":"1. Login via SSO and authenticate customer using masked ID **** and select portfolio; confirm market data entitlements show live quotes for local instruments.\n2. Open Order Entry (Equity), select exchange TASE, symbol ABCD, set orderType Buy, price condition Limit with price 105.10 ILS, quantity 1000, validity Good For Day, quantityType Regular, orderCategory Normal.\n3. Click Place Order and verify pre-trade validations: buying power >= consideration + fees, product subscription, limits/market parameters, trading calendar; proceed past information/warnings if any.\n4. On Preview, review Estimated and Detailed Commission, tick I Agree for Commission & Order, and Confirm; verify status changes to Authorized with internal order number captured in audit.\n5. Verify FO–BO integration sends to market (ST-SP) and status updates to Placed with Market; simulate partial execution (e.g., 400 @ 104.90) and confirm custody/cash blocks adjust and order status becomes Partially Executed.\n6. Simulate final execution (600 @ 105.20) and verify order status Executed; confirm ST allocations and deals recorded with correct average price and fees; verify cash block release date updated for executed portion.\n7. Ingest TASE file 1051 (trade recon) including duplicate-record attempt; verify idempotence and that matched deals show reconciliationStatus Reconciled using matchingCriteria Instrument,Quantity,ExecutionId,Price,TradeDate; unmatched remain Not Matched.\n8. Verify Open Delivery automatically created; ingest TASE file 1052 and confirm system creates Settlement Advice, prevents duplicate SA by key TASE movement id,Event id,Security id,Quantity,Price; auto-match OD and SA where quantity, instrument, custodian, settlement type align and amount within tolerance 0.50 ILS.\n9. Run settlement batch at configured time; confirm street side settlement posted and matching status on OD and SA set to Settled; verify customer settlement batch (Actual model) runs near 1052 window and posts client-side cash/security movements on settlement date.\n10. Validate accounting entries: businessEvent Buy Client posts Debit Customer Cash, Credit Nostro Cash, Credit Fee Income; verify TD/VD stamps, correct currency ILS, and suspense unused; ensure reversal not triggered; confirm GL balances update.\n11. Send EOD movements to Tax Engine; receive tax/refund details for today’s settlements, lots update, counters file for last 10 days, and confirm postings to customer cash account; verify positions/lot closure reflected in valuation.\n12. Check reconciliation and reports: 1051 recon report shows no mismatches, 32/1091 stored for reference, RSP34290 exceptions empty, trade/position recon ageing zero, customer notifications generated as per directive.\n13. Verify UI artifacts: Order Book shows Executed, Trade Book lists both fills, E-Journal contains Initiated By Me record, auditTrailIds include OrderId,DealId,OpenDeliveryId,SettlementAdviceId,GLBatchId.\n14. Perform negative retry: re-upload the same 1052 file and confirm idempotence prevents duplicate SA creation and no duplicate postings occur.","expectedResult":"Order lifecycle completes with correct state transitions, OD-SA matched and settled under tolerance, customer settlement posted under Actual model, accurate fee computation, GL postings as per rules, tax engine postings received and applied, recon statuses Reconciled, and idempotence prevents duplicates.","userRole":"Call Centre Agent,Back Office Operator,Checker1","channel":"Call Centre","exchange":"TASE","instrumentType":"Equity","orderType":"Buy","validityType":"Good For Day","quantityType":"Regular","orderCategory":"Normal","currency":"ILS","price":105.1,"triggerPrice":0,"quantity":1000,"tolerance":0.5,"settlementCycle":"T+1","fileInputs":"ST-SP,1051,1052","interfaceName":"Trade Recon,Settlement Advice,Open Delivery Matching","batchName":"Street Settlement Batch,Customer Settlement Batch,EOD Tax Feed","stateFrom":"Authorized,Placed with Market,Partially Executed","stateTo":"Executed,Matched,Settled","businessEvent":"Buy Client,Buy Broker","accountingEntriesExpected":"Debit Customer Cash,Credit Nostro Cash,Credit Fee Income","glAccounts":"Customer Cash,Nostro Cash,Fee Income,Internal Control","feeItems":"ST Commission,TASE Fee if configured","feeMethod":"flat percentage,flat","minMaxApplied":"Yes if configured","taxRate":0,"authorizationLevel":"None for order,Checker1 for exceptions","alertType":"Information,Warning","reconciliationStatus":"Reconciled","matchingCriteria":"Instrument,Quantity,ExecutionId,Price,TradeDate","auditTrailIds":"OrderId,DealId,OpenDeliveryId,SettlementAdviceId,GLBatchId,TaxFileId","assumptions":"ASSUMPTION Actual customer settlement model is enabled at system level,ASSUMPTION Instrument not under CA ex-date,ASSUMPTION Fee schedule active with no overrides"},{"type":"end-to-end","title":"Foreign Equity Sell with Broker Average Rebook, SEC/TAF Fees and T+1 Street Settlement","description":"Validate foreign SELL trade lifecycle with EOD cancel-and-average rebook from broker, third-party fees treatment, multi-currency accounting, and settlement batch.","testId":"TC-FORGN-AVG-SELL-002","testDescription":"Covers FO–BO interplay, fee segregation, OD matched propagation, and recon vs broker files.","prerequisites":"Customer holds sufficient foreign security quantity, FX rates available, broker fee package configured (broker commission, TAF), customer fee schedule configured (ST Commission, SEC fee as 3rd party), broker settlement account defined, tax engine integration active.","stepsToPerform":"1. Authenticate customer and open Order Entry for foreign symbol KMT.N on NYSE; set orderType Sell, limit price 56.20 USD, quantity 500, validity Good For Day; verify custody balance suffices.\n2. Place order, pass warnings/information, confirm Authorized then Placed with Market; simulate executions (e.g., 3 fills); verify custody blocks released proportionally and sale proceeds table updated for executed portion (buying power reflects proceeds).\n3. At EOD, ingest FO Broker Order Summary file; system cancels original trades and rebooks one average price deal (e.g., 56.05 USD) with tags: brokerCommission, SEC, TAF; confirm cancel-and-rebook reflected in BO and OD marked Matched.\n4. Validate fee handling: SEC posted to 3rd party payable and marked as 3rd party in customer account, customer-side ST Commission posted to Fee Income, brokerCommission and TAF posted as Fee Expense vs Broker settlement account; confirm fees form part of cost price as specified.\n5. Verify OD matched status propagates and reconciliation status updated; manually reconcile any deals captured off the report by marking recon status to enable batch settlement.\n6. Run T+1 Street Settlement batch (no custodian confirmation available); confirm street-side cash movements post in broker settlement currency USD and OD status set to Settled; ensure FX translation to account currency ILS is posted correctly with rounding per rules.\n7. Run customer cash settlement batch on T+1 (per exchange cycle) and verify postings to customer cash account on value date with TD/VD stamps and correct FX conversions.\n8. Generate BO recon report vs Broker Order Summary highlighting any differences; verify daily and monthly broker commission reports include Order Ref, Exec Qty/Price, Net Amount, Commission, SEC, TAF.\n9. Note TAF cap difference: simulate custodian cap applied in 872 vs no cap in BaNCS; flag difference for refund workflow; ensure no automatic cap applied in system.\n10. Send EOD movements to tax engine; verify settlement-date-based tax on SELL calculated and posted, lots closed and counters file updated; confirm positions align in tax-engine recon.","expectedResult":"Original executions are cancelled and rebooked at broker average with correct fee segregation, OD set to Matched then Settled by T+1 batch, accounting correct across currencies, tax posted on settlement date, and recon reports highlight TAF cap differences.","userRole":"Back Office Operator,Call Centre Agent,Checker1","channel":"Call Centre","exchange":"NYSE","instrumentType":"Equity","orderType":"Sell","validityType":"Good For Day","quantityType":"Regular","orderCategory":"Normal","currency":"USD,ILS","price":56.2,"triggerPrice":0,"quantity":500,"tolerance":0,"settlementCycle":"T+1","fileInputs":"Broker Order Summary EOD,872 reference (manual recon)","interfaceName":"FO–BO Broker Recon","batchName":"Foreign Street Settlement Batch,Customer Settlement Batch,EOD Tax Feed","stateFrom":"Authorized,Placed with Market,Executed","stateTo":"Cancelled and Rebooked Average,Matched,Settled","businessEvent":"Sell Client,Sell Broker","accountingEntriesExpected":"Credit Customer Securities,Debit Broker Settlement,SEC to Third Party Payable,Customer ST Commission to Fee Income,Broker Commission and TAF to Fee Expense","glAccounts":"Customer Cash,Customer Securities,Broker Settlement,Fee Income,Fee Expense,Third Party Payable FX","feeItems":"ST Commission,SEC,TAF,Broker Commission","feeMethod":"flat percentage,flat per unit","minMaxApplied":"No cap in system for TAF","taxRate":0,"authorizationLevel":"Checker1 for exceptions if any","errorCodeExpected":"","alertType":"Information","reconciliationStatus":"Reconciled after rebook","matchingCriteria":"Broker Order Ref,Symbol,Side,Exec Qty,Avg Price","auditTrailIds":"OrderId,RebookedDealId,ODId,GLBatchId,BrokerReconReportId,TaxFileId","assumptions":"ASSUMPTION No custodian confirmation files used for auto settlement,ASSUMPTION FX rates available at trade and settlement dates"},{"type":"functional","title":"Securities Transfer Outside Bank with Relatives Split, Maker-Checker, BOD File 15 to 1052 Settlement","description":"Initiate an Outside Bank transfer to relatives with percentage split, ensure decision-table logic for same entity vs transfer case, multi-level authorization, BOD file 15 submission, 1051 recon, 1052 settlement, lots transfer and accounting.","testId":"TC-TRANSFER-OUT-REL-003","testDescription":"Covers UI-heavy transfer screens, validations, file interface sequencing, and tax identifier derivation.","prerequisites":"Portfolio holds settled TASE equities with available quantities, no CA ex-date on business date, list of external banks/branches loaded, transfer fee schedule configured, tax engine integration active, authorization limits set (maker, checker1, checker2).","stepsToPerform":"1. From Transfers > Security Transfer, verify MU home-branch restriction allows initiation; select TASE positions and default full Available Quantity; confirm Value shows in ILS and CA indicator absent.\n2. Click Add Beneficiary, choose Outside Bank; add two beneficiaries using Bank Code 1245 and Branch Code 5124 with account numbers ****1111 and ****2222; set percentage splits 60 and 40.\n3. Uncheck Same Entity; select Transfer Case 'Transfer between relatives' and subcase 'Spouse of a sister/brother'; verify Mutual Funds (if any selected) are rejected for non-same-entity with proper error.\n4. Click Verify; confirm validations: only TASE allowed for Outside Bank, branch list filtered by bank, fractional quantities permitted, order date defaulted to today and read-only.\n5. Preview: review commission details, print commission quote, tick I Agree; Release to trigger maker-checker; assign to a specific Checker1 with remarks and confirm assignment appears in Authorization Queue.\n6. As Checker1, open My Queue, review transaction details and customer exceptions (if any); approve and escalate to Checker2 pool per workflow; as Checker2, approve and set status to U-Authorized.\n7. Run BOD batch next day; confirm File 15 is generated and sent to TASE for both legs (split quantities); verify auditTrailIds include TransferOrderId and File15Id.\n8. On T, receive 1051 showing transfer orders; update reconciliationStatus at order level to Reconciled; monitor any To Be Repaired items (none in positive flow).\n9. Receive 1052 settlement; system creates Settlement Advice and matches with Open Delivery; verify matching criteria (instrument,custodian,settlement type,amount within tolerance) and mark OD/SA Settled; custody blocks removed and DR movements written.\n10. Validate lots/layers moved to beneficiaries and Same Entity Tax Identifier derived as 1 due to selected transfer case; confirm tax engine gets EOD message and updates positions/lots accordingly.\n11. Verify accounting for transfer: customer DR securities vs internal transfer control accounts; fees debited from selected fee account; GLs posted as per rule with correct TD/VD.\n12. Review Security Transfer History and reports RSP34100,RSP35490-equivalent (if applicable); confirm audit and E-Journal show Initiated By Me and Authorized By Me entries.","expectedResult":"Transfer order passes validations, authorized by two levels, File 15 sent at BOD, 1051 reconciles, 1052 settles both split legs, custody blocks removed, lots transferred, taxIdentifierFlag set to 1, fees applied, GL postings correct, and history/reporting complete.","userRole":"Branch Maker,Checker1,Checker2,Back Office Operator","channel":"Back Office","exchange":"TASE","instrumentType":"Equity","orderType":"Security Transfer","validityType":"NA","quantityType":"Regular,fractional supported","orderCategory":"Transfer between relatives","currency":"ILS","price":0,"triggerPrice":0,"quantity":0,"tolerance":1,"settlementCycle":"Per clearing (T+1 expected)","fileInputs":"15 (outgoing),1051 (recon),1052 (settlement)","interfaceName":"TASE Transfer Outgoing and Clearing","batchName":"BOD File 15,EOD Recon 1051,Settlement 1052","stateFrom":"Released,Authorized","stateTo":"Pend Settle,Settled","businessEvent":"Transfer Out","accountingEntriesExpected":"Debit Transfer Fee,Credit Fee Income,Security DR/CR between internal transfer accounts","glAccounts":"Customer Securities,Internal Transfer Control,Fee Income,Customer Cash","feeItems":"Transfer Commission","feeMethod":"flat","minMaxApplied":"Yes","taxRate":0,"taxIdentifierFlag":1,"transferCase":"Transfer between relatives","beneficiaryType":"External bank accounts","sameEntity":"No","authorizationLevel":"Checker1,Checker2","reconciliationStatus":"Reconciled","matchingCriteria":"Instrument,Custodian,Settlement Type,Quantity,Amount tolerance","auditTrailIds":"TransferOrderId,AuthorizationIds,File15Id,OpenDeliveryId,SettlementAdviceId,GLBatchId,TaxFileId","assumptions":"ASSUMPTION No CA ex-date on business date,ASSUMPTION External bank master valid and reachable"},{"type":"end-to-end","title":"Mutual Fund Purchase with Auto Price Correction (Reverse and Reallocate) and Clearing","description":"End-to-end MF order from purchase before cut-off through allocation, contractual settlement, auto price correction via 1051 reversal/reallocation, and 1052 street settlement.","testId":"TC-MF-AUTO-PRICECORR-004","testDescription":"Validates MF trading parameters (file 126), allocation 1051, auto reverse and reallocate, and accounting/tax effects.","prerequisites":"NAV list available, MF trading parameters from file 126 loaded, customer has sufficient funds, MF product configured for auto price correction, accounting rules for MF purchase/redemption configured, Kafka events enabled for MF documents.","stepsToPerform":"1. From NAV List, select local fund XYZ, confirm cut-off time and latest NAV; open Purchase; enter units 1000 and principal account; verify trade balance allows purchase.\n2. Place order and accept applicable warnings/information; on Preview tick I Agree and Confirm; capture internal order number.\n3. End of T (evening), ingest 1051 allocation file; system creates allocation at NAV_T, updates customer security position (units) and marks allocation status; verify contractual customer cash settlement scheduled T+1 17:30 per table.\n4. Run customer settlement batch on T+1 (contractual); confirm cash debit principal + commission, fee postings, and TD/VD stamping.\n5. Same T+1 evening, ingest 1051 with price correction (reverse and reallocate) for the fund; system auto-reverses prior allocation (movements only) and books new allocation at NAV_T+1; verify order trail shows Reverse and Reallocate actions.\n6. Ingest 1052 (street) on T+1 for local MF; confirm street side cash and security settlement, and OD/SA statuses set to Settled; for foreign MF, ensure timing aligns per schedule (if configured) but keep this case local.\n7. Validate accounting: reversal entries negate previous allocation, new allocation postings applied, fees recomputed as per rules; ensure no duplicate settlement advice is created (idempotence on key fields).\n8. Send EOD movements to Tax Engine on both days; verify positions/lots updated to reflect revised price and that any tax impacts are calculated on settlement date; counters file updated.\n9. Verify BO reports: MF allocation status, settlement report, and customer notifications; confirm Kafka events emitted for MF documents (CSV/PDF) for BO and fund manager packets where applicable.\n10. Review Order Book and MF Order Book history; ensure status reflects Allocation, Reversed, Reallocated, Settled and auditTrailIds captured.","expectedResult":"MF purchase allocated at T, contractually settled at T+1, auto price correction reverses and reallocates at new price without duplication, street settlement completes, accounting and tax reflect corrected price, and reports/messages generated.","userRole":"Call Centre Agent,Back Office Operator","channel":"Call Centre","exchange":"TASE","instrumentType":"Mutual Fund","orderType":"Purchase","validityType":"NA","quantityType":"Units","orderCategory":"Normal","currency":"ILS","price":0,"triggerPrice":0,"quantity":1000,"tolerance":0,"settlementCycle":"Contractual T+1 street T+1","fileInputs":"126 (params),1051 (allocation,reversal,reallocation),1052 (clearing)","interfaceName":"MF Allocation and Clearing","batchName":"Customer Settlement Batch,Street Settlement Batch,EOD Tax Feed","stateFrom":"Order Placed,Allocated","stateTo":"Reversed,Reallocated,Settled","businessEvent":"MF Purchase Allocation,MF Settlement","accountingEntriesExpected":"Debit Customer Cash,Credit Fund Units,Credit Fee Income,Reversal entries for correction","glAccounts":"Customer Cash,MF Units,Nostro Cash,Fee Income","feeItems":"MF Purchase Commission,Distribution Fee accrual external to scope","feeMethod":"flat percentage","minMaxApplied":"Yes","taxRate":0,"authorizationLevel":"None unless limit breach","reconciliationStatus":"Reconciled","matchingCriteria":"Fund Id,Units,NAV,Trade Date","auditTrailIds":"MFOrderId,AllocationId,ReversalId,ReallocationId,SettlementAdviceId,GLBatchId,TaxFileId","assumptions":"ASSUMPTION Local fund used for timing simplicity,ASSUMPTION Distribution fee accrual reporting handled separately"},{"type":"functional","title":"Order Amendment on Executed Local Equity - Existing Order Correction with Reversal and Rebook","description":"Correct an executed order via Order Amendment (ExistingOrder), changing price and portfolio, and validate reversal and rebooking of deals, movements, GL, and tax re-computation.","testId":"TC-ORD-AMEND-EXEC-005","testDescription":"Validates post-execution correction controls, maker-checker, idempotence and downstream adjustments.","prerequisites":"An executed TASE equity order exists with completed settlement, correction portfolio active, amendment rights enabled for BO user, accounting rules support reversals, tax engine online.","stepsToPerform":"1. Navigate to BO > Order Amendment; set Amendment Type Non-Derivative and Amendment For ExistingOrder; enter executed Order Id and source Portfolio Ref; load order details.\n2. Select checkboxes Price and Portfolio; enter corrected limit price (e.g., 104.80 ILS) and Correction Portfolio ****9999; provide remarks detailing teller mistake.\n3. Save to trigger amendment workflow; verify exceptions route to specific authorizer due to policy; assign to Checker1; Checker1 reviews and approves; if limits require, escalate to Checker2 and approve.\n4. System posts reversal: cancel original customer deal and associated movements (principal, fees, tax) with correct TD/VD and back-dated balance recomputation; reverse OD/SA links if pending and mark exclusion for future matching to prevent duplicates.\n5. System rebooks corrected order/trade to target portfolio at corrected price; generate new deal and movements; ensure security and cash positions reflect new values; create new OD/SA if settlement is re-performed.\n6. Validate idempotence: attempting to re-apply amendment does not create duplicate reversals or rebookings; amendment status updated to Completed.\n7. Verify accounting: reversal entries are exact negation; new postings hit correct GLs (Customer Cash,Nostro,Fee Income/Expense); ensure suspense not used; confirm E-Journal updated under Initiated By Me and Authorized By Me.\n8. Send updated movements to tax engine at EOD; verify prior tax/refund postings are reversed and recomputed for settlement date of corrected deal; lots updated and valuation reflects new cost.\n9. Review Order History and Trade History to ensure traceability of original vs amended order; confirm auditTrailIds link original and amended entities; verify reports (Transaction Control, Tax Control) show both reversal and new entries.","expectedResult":"Executed order is corrected via authorized amendment; original postings fully reversed, new postings created correctly, no duplicate OD/SA, GL and tax recomputed accurately, and complete audit trail maintained.","userRole":"Back Office Operator,Checker1,Checker2","channel":"Back Office","exchange":"TASE","instrumentType":"Equity","orderType":"Amendment ExistingOrder","validityType":"NA","quantityType":"Regular","orderCategory":"Normal","currency":"ILS","price":104.8,"triggerPrice":0,"quantity":0,"tolerance":0,"settlementCycle":"As per corrected deal","fileInputs":"1051,1052 (if regenerated or linked)","interfaceName":"Order Amendment Processor","batchName":"EOD Reversal and Rebook,TAX EOD","stateFrom":"Executed,Settled","stateTo":"Reversed,Rebooked,Settled","businessEvent":"Order Amendment Correction","accountingEntriesExpected":"Reverse Principal/Fees/Tax,Post corrected Principal/Fees/Tax","glAccounts":"Customer Cash,Nostro Cash,Fee Income,Third Party Payable","feeItems":"ST Commission reversal and re-application","feeMethod":"same as original","minMaxApplied":"Yes per schedule","taxRate":0,"authorizationLevel":"Checker1,Checker2 as per limits","errorCodeExpected":"","alertType":"Information","reconciliationStatus":"Reconciled after correction","matchingCriteria":"Instrument,Qty,Price,Trade Date with corrected values","auditTrailIds":"AmendmentId,OriginalOrderId,ReversalMovementId,NewDealId,GLBatchId,TaxFileId","assumptions":"ASSUMPTION Exchange permits correction via BO process,ASSUMPTION CA not impacting the corrected trade window"},{"type":"functional","title":"Market Data Subscription Matrix Enforcement - Live vs Delayed by Function and Origin","description":"Validate entitlement-driven live vs delayed market data behavior across Call Centre widgets and order functions for local (TASE) and foreign (Orbis) instruments.","testId":"TC-MD-ENT-006","testDescription":"Covers decision-table for entitlement matrix, UI banners, disabled actions, and provenance of quotes and depth across functions.","prerequisites":"Test user with role Call Centre Agent; two entitlement profiles configured: PROFILE-A (local live, foreign delayed) and PROFILE-B (local live, foreign live); ORS and Bizportal connectors up; sample TASE symbol ABCD and foreign symbol KMT.N available; audit enabled; PII masked.","stepsToPerform":"1. Login via SSO to Call Centre and select PROFILE-A for the session (local live, foreign delayed); authenticate a customer with masked ID ****.\n2. Open Market Watch and add ABCD (TASE) and KMT.N (NYSE); verify latency banners are visible on grid.\n3. Click Get Quote for ABCD and confirm Live tag, five best bids/offers visible, depth actions enabled; capture timestamp provenance ORS.\n4. Click Get Quote for KMT.N and confirm Delayed banner, last update time shows delay, depth toggle disabled or prompts subscription; provenance shows Orbis.\n5. Open Order Entry for KMT.N; verify top-of-panel quote shows delayed watermark, Order Depth button disabled; ensure Order Quote still shows best available with delay.\n6. Open Order Entry for ABCD; verify Order Quote and Depth are live; place no order, just verify UI enables depth, charts and L2.\n7. Open Index Watch and confirm indices are Live irrespective of profile; sample TA-35 shows current tick without delayed banner.\n8. Open Top Gainers and Losers and confirm list is delayed per policy; verify footer message 'Prices are delayed by 20 minutes'.\n9. Open Portfolio Valuation; verify valuation refresh respects entitlement (for PROFILE-A, foreign holdings use previous close/EOD while local updates live where applicable); export grid and check timestamps.\n10. Open Tax Simulation; verify delayed usage is enforced and simulation runs without live tick dependency; proceed to results and ensure no live quote overlay is shown.\n11. Switch user to PROFILE-B (local live, foreign live) without changing customer; repeat steps 3–6 to confirm foreign quotes and depth now Live; delayed banners disappear.\n12. Review E-Journal entries and auditTrailIds for entitlement changes and page accesses; ensure CTRLM shows no interface failures, and all events record source adapters.","expectedResult":"Entitlement matrix is enforced precisely: local functions always live, foreign functions delayed unless enabled; delayed banners and disabled depth appear where required; switching to PROFILE-B turns foreign data live across Get Quote and Order Entry; Index Watch remains live; valuation and tax simulation adhere to policy; audit trails capture adapter provenance and entitlement changes.","userRole":"Call Centre Agent","channel":"Call Centre","exchange":"TASE,NYSE","instrumentType":"Equity,Index","currency":"ILS,USD","interfaceName":"ORS,Bizportal,Orbis","alertType":"Information","authorizationLevel":"None","auditTrailIds":"SessionId,EntitlementChangeId,WidgetAccessId,QuoteRequestId","assumptions":"ASSUMPTION Network latency is stable for observing live vs delayed markers,ASSUMPTION No trading action is executed in this test"},{"type":"negative","title":"TASE Self-Transaction Prevention Across Portfolios at BP-Level with Price Logic","description":"Ensure system blocks self-transactions per TASE rule at BP-level across multiple portfolios with market and limit price conditions and allows when criteria are not met.","testId":"TC-TASE-SELF-007","testDescription":"Validates decision-table for opposite orders, price thresholds, cross-portfolio (same BP), multi-channel interaction, and error messaging.","prerequisites":"Business Partner BP-**** has two portfolios P1 and P2; instrument ABCD tradable on TASE; data live; no POA override; self-transaction rule enabled; existing balances sufficient.","stepsToPerform":"1. As Call Centre Agent, authenticate BP-**** and select portfolio P1; place a Buy Limit order for ABCD: quantity 1000, price 100.00 ILS, validity Good For Day; confirm order status Authorized then Placed with Market with open quantity 1000.\n2. Without executing P1 order, switch to portfolio P2 (same BP) and attempt to place a Sell Market order for ABCD quantity 200; on Preview click Confirm.\n3. Verify system blocks with error 'Self-Transactions are not allowed in TASE' and no order id is generated; capture errorCodeExpected and alertType Error.\n4. In P2, attempt Sell Limit for ABCD quantity 200 at price 99.90 (<= open Buy price); Confirm and verify same block occurs.\n5. In P2, attempt Sell Limit for ABCD quantity 200 at price 101.00 (> open Buy price); Confirm and verify order is accepted and sent to market (allowed case per rule).\n6. In FO or simulator, partially execute P1 Buy for 400 shares at 100.00; verify P1 order remains Partially Executed with open quantity 600; repeat step 4 in P2 and confirm block persists while any open buy exists.\n7. Fully execute the remaining 600 on P1; verify order status Executed with no open quantity.\n8. Retry in P2 a Sell Market order for ABCD quantity 200; verify it is now accepted since no open opposite order exists.\n9. Review E-Journal and audit trails for both portfolios; ensure blockage attempts are logged once and no duplicate orders created; confirm rule applies at BP-level not portfolio-level.\n10. Attempt to assign an authorizer to override the block; verify workflow does not allow override for self-transaction and remains blocked.","expectedResult":"Self-transaction prevention blocks opposite orders across portfolios of the same BP when price conditions meet rule criteria; allowed path works when price is outside the prohibited threshold and after the original order is fully executed; no maker-checker override possible; accurate error messaging and audit logging.","userRole":"Call Centre Agent,Front Office Simulator","channel":"Call Centre","exchange":"TASE","instrumentType":"Equity","orderType":"Buy,Sell","validityType":"Good For Day","quantityType":"Regular","orderCategory":"Normal","currency":"ILS","price":100,"triggerPrice":0,"quantity":1000,"errorCodeExpected":"Self-Transactions are not allowed in TASE","alertType":"Error","stateFrom":"Authorized,Placed with Market","stateTo":"Partially Executed,Executed,Blocked","authorizationLevel":"Not Applicable for override","auditTrailIds":"OrderIdP1,BlockedAttemptIdP2,OrderIdP2Allowed","assumptions":"ASSUMPTION No other open orders for ABCD under BP-****,ASSUMPTION Exchange phase allows continuous trading"},{"type":"functional","title":"Local TASE 1054 Failed/Pending Settlement Handling with Manual Blocks and Reversals","description":"Validate processing of TASE 1054 failed or pending trades, manual block actions, cancellation via ST Order List, and complete reversal of movements and OD/SA links.","testId":"TC-1054-FAIL-008","testDescription":"Covers state transitions, file robustness, manual operational controls, idempotence, and accounting reversals for a failed Buy trade.","prerequisites":"Executed Buy trade for ABCD on T (deal captured and reconciled with 1051); Open Delivery created; customer is on Actual model; cancellation rights in BO; accounting rules and reversal mappings configured; tolerance 0.50 ILS.","stepsToPerform":"1. Ingest TASE file 1051 for T; verify the deal matches and reconciliationStatus is Reconciled; capture DealId and OpenDeliveryId.\n2. On T+1 prior to 1052, ingest 1054 marking the trade as Failed or Pending; confirm reconciliationStatus on deal and OD updates to Failed/Pending and alerts raised to BO operations.\n3. Per rule for Buy trades, create a manual custody block in the customer account equal to executed quantity; record Block Reference; verify system allows creation even if insufficient free balance.\n4. Verify customer settlement batch (Actual model) does not post client-side settlement for this failed OD; ensure no postings on customer cash and securities for value date.\n5. From ST Order List screen, initiate Cancel for the failed order; obtain Checker1 approval if required; confirm system posts reversal movements for principal, fees, and tax with proper TD/VD stamps.\n6. Verify OD/SA linkage is removed and Open Delivery is excluded from future matching; attempt re-upload of the same 1052 (if any) and confirm idempotence prevents SA creation.\n7. Re-ingest the same 1054 file to test idempotence; verify no duplicate state changes occur and audit logs one processing instance only.\n8. Validate accounting: original postings are fully reversed, suspense accounts are not used, and GL balances reflect net zero for the transaction; export GL batch for review.\n9. Run reports RSP34280 Failed and Cancelled Trades and RSP34290 Reconciliation Exception; confirm entries appear with correct statuses and are cleared post cancellation.\n10. Send EOD movements to Tax Engine and verify that any prior provisional tax items related to this deal are reversed and lots are restored to pre-trade state.","expectedResult":"1054 failure updates statuses to Failed/Pending, manual block is created, customer settlement is suppressed, order cancellation reverses all movements and excludes OD from matching, file processing is idempotent, GL and tax are correctly reversed, and reports reflect accurate failure and closure.","userRole":"Back Office Operator,Checker1","channel":"Back Office","exchange":"TASE","instrumentType":"Equity","orderType":"Buy","validityType":"Good For Day","quantityType":"Regular","orderCategory":"Normal","currency":"ILS","tolerance":0.5,"settlementCycle":"T+1","fileInputs":"1051,1054","interfaceName":"Trade Recon,Failed Settlement","batchName":"Customer Settlement Batch Actual,EOD Tax Feed","stateFrom":"Executed,Reconciled","stateTo":"Failed,Cancelled,Reversed","businessEvent":"Buy Client reversal,Buy Broker reversal","accountingEntriesExpected":"Reverse Principal,Reverse Fee Income,Reverse Third Party if any","glAccounts":"Customer Cash,Nostro Cash,Fee Income,Third Party Payable","reconciliationStatus":"Failed then Cleared","matchingCriteria":"Instrument,Quantity,ExecutionId,Price,TradeDate","authorizationLevel":"Checker1 for cancellation","auditTrailIds":"DealId,OpenDeliveryId,BlockRef,CancelActionId,GLBatchId,TaxFileId","assumptions":"ASSUMPTION 1052 not yet processed for the failed OD,ASSUMPTION No partial street settlement occurred"},{"type":"functional","title":"Fractional Orders Batch Settlement with Transit Deals and Average Price Computation","description":"Validate nightly batch that settles leftover fractional quantities from full-sell orders between customer and bank fraction portfolio, creating transit deals linked to 1052.","testId":"TC-FRACT-009","testDescription":"Covers fraction identification, average price computation on trading date, deal creation, accounting, linkage to 1052, and reporting.","prerequisites":"At least two full-sell orders executed on T for instrument ABCD resulting in fractional leftovers (e.g., 0.3 and 0.7 units due to lot-size or clearing constraints); bank fraction portfolio configured; 1052 processing enabled; report RSP34400 available.","stepsToPerform":"1. Execute two customer full-sell orders for ABCD on T that produce fractional residuals totaling non-integer units; verify execution records and remaining fractional balances in portfolio activity.\n2. Ingest 1051 on T to reconcile trades; ensure deals are Reconciled and OD created; no fraction settlement yet.\n3. Ingest 1052 on T+1; confirm street side settlement for integer portions completes and ODs for those quantities are Settled; fractions remain outstanding.\n4. Run Fractional Settlement Batch post-1052; verify the batch scans for fractional leftovers on T and prepares consolidation by instrument and trading date.\n5. Validate batch creates a Transit Deal between customer and bank fraction portfolio for the exact fractional quantities; check Deal Category shows Transit Deal and references the parent order ids.\n6. Verify average price used for transit deal equals the weighted average execution price of customer sells on T; confirm rounding follows system rules and currency ILS.\n7. Validate accounting: customer securities credit for fractions, internal fraction portfolio debit, no external broker legs; ensure GL postings are double-sided and no suspense used.\n8. Confirm OD/SA linkage for the transit deals is recorded as 1052-linked event where applicable, and that duplicate prevention keys avoid creating multiple transit deals on reruns.\n9. Generate and review RSP34400 Fractional Trading Report; confirm entries show instrument, fractional quantity, average price, parent orders, and GL batch reference.\n10. Check portfolio valuation after batch; verify no residual fractional quantity remains in customer account and that internal fraction portfolio reflects the mirror position.","expectedResult":"Fractional leftovers are settled via automatically created transit deals at correct average price, accounting entries post to customer and fraction portfolios, 1052 linkages are respected, reruns are idempotent, and reporting and positions reflect zero residual fractions for the customer.","userRole":"Back Office Operator","channel":"Back Office","exchange":"TASE","instrumentType":"Equity","orderType":"Sell","validityType":"Good For Day","quantityType":"Regular with fractional outcome","orderCategory":"Normal","currency":"ILS","settlementCycle":"T+1","fileInputs":"1051,1052","batchName":"Fractional Settlement Batch","businessEvent":"Transit Deal Creation","accountingEntriesExpected":"Credit Customer Securities,Debit Internal Fraction Portfolio","glAccounts":"Customer Securities,Internal Fraction Portfolio Control","reconciliationStatus":"Reconciled for trades,Transit processed","matchingCriteria":"Instrument,Trade Date,Average Price,ParentOrderIds","authorizationLevel":"None","auditTrailIds":"TransitDealId,ParentOrderIds,GLBatchId,ReportIdRSP34400","assumptions":"ASSUMPTION Fractional support configured with precision to 3 decimals,ASSUMPTION No corporate action ex-date blocks on T"},{"type":"end-to-end","title":"Custody Fee Daily Accrual Recompute and Quarterly Application with Messaging","description":"Validate daily custody fee accrual across holdings, back-dated correction recomputation, quarterly aggregation, debit to customer, GL postings, and BO reports/messages.","testId":"TC-CUSTFEE-010","testDescription":"Covers periodic fee engines, tier/slab rules, multi-currency valuation, back-dated adjustments, quarterly charge application, and notifications.","prerequisites":"Fee schedule configured for custody fee using tiered percentage on position value with min/max caps; customer holds local and foreign securities; message templates 77 and 425 configured; report RSP34390 enabled; GL accounts Fee Income and Customer Cash mapped.","stepsToPerform":"1. On Day D, run Custody Daily Accrual batch; verify accrual amounts computed per security based on position value in portfolio currency, FX rates applied where required.\n2. Review accrual store for D and confirm min/max caps are applied per instrument as configured; export accrual snapshot for audit.\n3. Post a back-dated trade correction on D+2 affecting Day D positions (e.g., reduce ABCD quantity effective D); ensure reversal and rebook complete for the trade.\n4. Re-run Custody Daily Accrual recompute job; verify the system recalculates Day D accrual and posts an adjustment entry for the delta, not double-counting.\n5. Repeat daily accrual until the end of quarter Q; verify accrual continuity for weekends and holidays (no accrual or carry as per config) and leap-year logic if applicable.\n6. Run Quarterly Aggregation process at Q close; confirm aggregation sums daily accruals per customer and compares against caps; prepare application batch.\n7. Execute Apply Custody Fees batch; verify customer cash account is debited and Fee Income credited for the quarter total, with TD/VD stamps per policy.\n8. Validate Message 77 and 425 are generated and delivered to the customer with correct period, total fee, and holdings summary; verify Kafka or messaging events if applicable.\n9. Generate RSP34390 Custody Fee Report and BO summary; confirm figures reconcile to GL and applied amounts; check export for fund manager if any dependency.\n10. Attempt to re-run Apply Custody Fees batch for the same quarter; verify idempotence prevents duplicate debits and flags prior application.","expectedResult":"Daily custody fee accruals are computed correctly with tiering and caps, back-dated corrections trigger precise recomputation adjustments, quarterly aggregation and application debit the customer once with proper GL postings, regulatory messages are sent, and reports reconcile with GL; reruns are idempotent.","userRole":"Back Office Operator","channel":"Back Office","currency":"ILS,USD","feeItems":"Custody Fee","feeMethod":"final tier,flat percentage,min max caps","minMaxApplied":"Yes","batchName":"Custody Daily Accrual,Quarterly Aggregation,Apply Custody Fees","businessEvent":"Custody Fee Accrual,Custody Fee Application","accountingEntriesExpected":"Debit Customer Cash,Credit Fee Income","glAccounts":"Customer Cash,Fee Income","authorizationLevel":"As per fee application limits if configured","auditTrailIds":"AccrualRunId,RecomputeId,QuarterlyAggregationId,ApplyBatchId,MessageId77,MessageId425,ReportIdRSP34390","assumptions":"ASSUMPTION FX rates available for valuation each accrual day,ASSUMPTION No customer-specific fee override unless configured"},{"type":"functional","title":"Financial Instrument Setup and Type Mapping - Local T-Bill (Makam) and Foreign ETF","description":"Validate instrument master ingestion and manual CRUD with correct security type mapping, parameters, validations, and maker-checker approval.","testId":"TC-INST-SETUP-011","testDescription":"Covers local TASE Makam (type 54) and foreign ETF (type 229) creation/update, uniqueness, rate parameter linkage, deactivation constraints, and UI availability.","prerequisites":"Security type mappings per TASE table 143 loaded, Orbis/Bloomberg connectors available, maker-checker workflow active, admin role has create/update rights, no holdings for newly created test instruments.","stepsToPerform":"1. Login to Back Office as Admin and navigate to Financial Instruments; verify SSO and role-based access is granted.\n2. Trigger auto-ingestion for TASE security master and select a new Makam; confirm system maps to securityType 54 TBills and loads faceValue, poolFactor, couponType None, currency ILS.\n3. Open the ingested Makam and set Rate Type Parameters (Price in Percentage, Clean vs Dirty) and CPI linkage; Save to route for approval.\n4. As Checker1, open Authorization Queue, review instrument parameter changes, approve; verify amendment status changes to Authorized and auditTrailIds capture InstrumentId and AuthorizationId.\n5. Create a new Foreign ETF manually (exchange NYSE, currency USD); set instrumentType 229, lotSize 1, priceDecimals 4, quantityDecimals 3; Save and route for approval; approve as Checker1.\n6. Attempt to create a duplicate instrument with same ISIN/Ticker as the ETF; verify system blocks with errorCodeExpected INSTR_DUP_KEY and alertType Error.\n7. Edit the ETF to change quantityDecimals to 6 and priceDecimals to 6; validate Boundary Value Analysis accepts 0–6 and rejects >6 with errorCodeExpected DEC_PRECISION_EXCEEDED.\n8. Attempt to Deactivate the ETF effective today; since there are no holdings, confirm deactivation allowed; reactivate and save; verify state transitions captured in E-Journal.\n9. Attempt to Delete the Makam after creating a dummy reference (link to fee schedule or order type mapping); verify delete is blocked with message INSTR_IN_USE and that only Deactivate is permitted.\n10. Open Call Centre Order Entry and Advanced Search; verify both instruments appear post-approval and not visible while in Draft/Deactivated states; validate TASE/Orbis provenance shown.\n11. Cross-check security type mapping values against TASE table codes (e.g., 54->TBills, 229->ETF) and confirm rateType parameters persisted to Market Information module.","expectedResult":"Instrument records are created/updated with correct type mapping and parameters, uniqueness enforced, decimal boundaries validated, delete blocked when referenced, maker-checker approvals recorded, and instruments are visible for trading only when active and authorized.","userRole":"Back Office Admin,Checker1","channel":"Back Office","exchange":"TASE,NYSE","instrumentType":"TBills,ETF","currency":"ILS,USD","interfaceName":"Security Master Ingestion","fileInputs":"TASE Master,Orbis,Bloomberg","authorizationLevel":"Checker1","errorCodeExpected":"INSTR_DUP_KEY,DEC_PRECISION_EXCEEDED,INSTR_IN_USE","alertType":"Error,Information","auditTrailIds":"InstrumentId,AuthorizationId,ChangeSetId","assumptions":"ASSUMPTION No live customer positions exist for the test instruments,ASSUMPTION Security type mapping table is current and trusted"},{"type":"functional","title":"Market Information - Automated Security Rate Feed, Manual Overrides, CPI usage and Idempotence","description":"Validate automated rate ingestion robustness, provenance, manual single/mass entry with thresholds, CPI application to bonds, and override locking.","testId":"TC-MI-RATES-012","testDescription":"Covers file interface technical validations, duplicate prevention, delayed vs live timestamps not in scope, and downstream valuation impacts.","prerequisites":"Security universe loaded, MI adapters up (TASE/Bloomberg), CTRLM monitoring enabled, CPI index configured, valuation screens accessible, user has MI edit rights.","stepsToPerform":"1. Initiate end-of-day automated rate feed ingestion for TASE and Bloomberg; verify file sequence and business date are accepted and rates load with provenance Feed.\n2. Re-upload the exact same feed file; verify idempotence prevents duplicate rate rows and CTRLM logs 'Duplicate Ignored'.\n3. Upload a partial file missing mandatory Price field for one symbol; verify file rejects the bad record, processes others, raises alertType Error with errorCodeExpected RATE_MISSING_FIELD and creates a skip-item in CTRLM.\n4. Upload a file with invalid currency for a foreign ETF (expected USD but file has EUR); verify record fails with errorCodeExpected RATE_CCY_MISMATCH and no stale data overwrites prior good rate.\n5. Manually create a single bond rate for a Makam using Clean price 99.876 with CPI index 1.012 applied; save and verify Portfolio Valuation uses CPI-adjusted value and provenance Manual Single.\n6. Perform Mass Manual Entry for 5 symbols including an equity, ETF, and bond; enforce Boundary Value Analysis: accept min price 0.01, reject 0.00 and > 9,999,999.00 with respective threshold errors; confirm decimals respect instrument rules.\n7. Set Override Lock on one equity symbol and change price manually; ingest a new feed where the same symbol appears; verify locked manual price is not overwritten and provenance remains Manual Override.\n8. Run valuation refresh; confirm affected portfolios reflect new rates in account currency using FX as of valuation date and TD/VD stamps preserved.\n9. Generate MI Audit Extract; confirm each rate row shows source adapter, timestamp, userId for manual rows, and that rejected records are present in error log.\n10. Attempt late arrival reprocess: upload prior-date feed after EOD; verify reprocess policy either rejects or posts to historical table per config without changing today’s rates.","expectedResult":"Rate ingestion processes valid rows, ignores duplicates, rejects malformed or mismatched records with precise errors, manual and mass entries observe thresholds and decimals, CPI is applied to bonds, locked overrides are honored, valuation updates correctly, and audit/CTRLM logs are complete.","userRole":"Market Information Operator","channel":"Back Office","exchange":"TASE,NYSE","instrumentType":"Equity,ETF,TBills","currency":"ILS,USD","interfaceName":"Security Rates Feed","fileInputs":"TASE Rates,Bloomberg Rates,Manual Mass Upload","authorizationLevel":"None for feeds,Checker1 for manual override if configured","errorCodeExpected":"RATE_MISSING_FIELD,RATE_CCY_MISMATCH,PRICE_THRESHOLD_BREACH","alertType":"Error,Warning,Information","auditTrailIds":"RateBatchId,ManualRateId,CTRLMEventId","assumptions":"ASSUMPTION FX rates are present for valuation currency conversions,ASSUMPTION Lock-override policy configured to prevent feed overwrite"},{"type":"end-to-end","title":"Extranet Off-Floor Trade Capture and Settlement with Block Expiry","description":"E2E for Extranet trade: call centre blocks, off-exchange execution, T+1 BO manual capture with specific order category, block expiry, and settlement via 1052.","testId":"TC-EXTRANET-E2E-013","testDescription":"Validates UI-heavy call-centre blocks, EOD mismatch identification, BO trade capture at average/actual price, OD/SA matching, accounting and audit.","prerequisites":"Customer authenticated, sufficient buying power or holdings, extranet order already placed externally, 1051/1052 interfaces active, order category 'Extranet transaction out of exchange' available, fee schedules mapped.","stepsToPerform":"1. As Call Centre Agent, open Fund Balance and place appropriate block: for Buy place cash block equal to estimated principal+fees, for Sell place custody block equal to intended quantity; record Block Reference IDs.\n2. End of T, ingest 1051; verify the extranet trade appears as mismatch (no corresponding order) on exception report and reconciliationStatus Not Matched.\n3. On T+1 morning, BO Operator opens Manual Trade Capture; select orderCategory Extranet transaction out of exchange, enter instrument, side, quantity, price, and customer portfolio; preview fees and confirm; route to Checker1 if limits exceeded.\n4. Checker1 reviews the captured trade in Authorization Queue; approve; verify deal and Open Delivery are created and order/trade trail indicates Extranet category.\n5. Expire previously placed cash/custody blocks from the call centre as per process; verify Block Balance reduces to zero and Available/Trade Balances update.\n6. Ingest 1052 settlement file; system creates Settlement Advice and auto-matches to OD under tolerance; verify matchingCriteria Instrument,Quantity,Settlement Type,Amount tolerance and status Matched.\n7. Run Street Settlement Batch and Customer Settlement Batch per model; ensure postings occur on settlement date with correct TD/VD and that double-sided GL entries hit Nostro/Customer as per businessEvent.\n8. Validate accountingEntriesExpected: Principal, Commission, and any configured third-party fees; ensure no suspense used; export GL batch for verification.\n9. Verify E-Journal shows Initiated By Me (BO capture) and Authorized By Me (Checker), and that order books/trade books reflect Extranet categorization.\n10. Negative duplicate check: attempt to capture the same extranet trade again using identical instrument, qty, price; system should detect duplicate by composite key and block with errorCodeExpected EXTN_DUP_TRD.","expectedResult":"Extranet trade is correctly captured and authorized in BO on T+1, initial blocks are expired, OD/SA are matched and settled via 1052, accurate GL postings occur, reports and journals reflect off-exchange nature, and duplicate capture is prevented.","userRole":"Call Centre Agent,Back Office Operator,Checker1","channel":"Call Centre,Back Office","exchange":"TASE","instrumentType":"Equity","orderType":"Buy or Sell","orderCategory":"Extranet transaction out of exchange","currency":"ILS","tolerance":1,"settlementCycle":"T+1","fileInputs":"1051,1052","interfaceName":"Extranet Recon and Settlement","batchName":"Street Settlement Batch,Customer Settlement Batch","businessEvent":"Buy Client,Buy Broker or Sell Client,Sell Broker","accountingEntriesExpected":"Principal,Commission,Third Party if configured","glAccounts":"Customer Cash,Nostro Cash,Customer Securities,Fee Income,Third Party Payable","authorizationLevel":"Checker1 if limit breach","errorCodeExpected":"EXTN_DUP_TRD","alertType":"Information,Warning,Error","reconciliationStatus":"Not Matched then Reconciled","matchingCriteria":"Instrument,Quantity,Settlement Type,Amount tolerance","auditTrailIds":"ManualDealId,OpenDeliveryId,SettlementAdviceId,GLBatchId,BlockRefIds","assumptions":"ASSUMPTION Extranet platform submits trades to clearing and appears in 1051/1052,ASSUMPTION No corporate action ex-date on trade date"},{"type":"functional","title":"Incoming Security Transfer via File 132 - To Be Repaired Handling to Settlement","description":"Validate ingestion of TASE file 132 for incoming transfers, creation of Delivery In with To Be Repaired status, manual repairs for security/layers/beneficiary issues, and settlement completion.","testId":"TC-TRANSFER-IN-132-014","testDescription":"Covers file interface robustness, validations, repair UI, maker-checker, OD/SA matching, lots transfer and tax engine notifications.","prerequisites":"Beneficiary customer portfolio exists, TASE 132 sample file with one good record and two error records ready, 1051/1052 available, tax engine integration up.","stepsToPerform":"1. Run BOD batch to ingest File 132; verify technical validations and that Delivery In orders are created: one in Authorized, two in To Be Repaired due to issues.\n2. Open Incoming Transfer Repair screen; for record A, note error 'Security not present in system' and add mapping by selecting correct local instrument; save.\n3. For record B, observe 'Difference between layers quantity and order quantity'; load layers from sender, adjust or split as per UI, and align totals; save.\n4. For record C (if present), verify 'Beneficiary Account/Identification mismatch'; correct beneficiary identifiers to match target portfolio; save.\n5. Route repaired items for authorization; Checker1 approves; verify stateFrom To Be Repaired moves to Authorized and custody blocks applied.\n6. Ingest 1051; confirm reconciliationStatus Reconciled at order level and that any duplicates are ignored (idempotence on File 132 replay).\n7. Ingest 1052; system creates Settlement Advice and matches with Open Delivery using matchingCriteria Instrument,Custodian,Settlement Type,Quantity,Amount tolerance; set statuses to Settled.\n8. Verify lots/layers are transferred to beneficiary, Same Entity detection applied when BP matches, and taxIdentifierFlag derived accordingly; ensure EOD feed sent to tax engine.\n9. Validate accounting: DR/CR to internal transfer control and customer securities, no cash principal since free receipt/delivery, fees if configured debited from fee account.\n10. Retry ingest of the same File 132; confirm idempotence prevents duplicate orders and logs show 'Duplicate Instruction Ignored' with no new postings.","expectedResult":"File 132 creates incoming transfers; items with issues are flagged To Be Repaired, can be corrected and authorized; OD/SA matching and settlement complete; layers move accurately; tax/GL updated; duplicate file ingestion is idempotent.","userRole":"Back Office Operator,Checker1","channel":"Back Office","exchange":"TASE","instrumentType":"Equity,Fund if eligible","orderType":"Delivery In","currency":"ILS","tolerance":1,"settlementCycle":"Per clearing","fileInputs":"132,1051,1052","interfaceName":"TASE Incoming Transfer","batchName":"BOD File 132,EOD Recon 1051,Settlement 1052","stateFrom":"To Be Repaired,Authorized","stateTo":"Authorized,Settled","businessEvent":"Transfer In","accountingEntriesExpected":"Security DR/CR between internal transfer control and customer securities,Transfer Fee if configured","glAccounts":"Customer Securities,Internal Transfer Control,Fee Income,Customer Cash","feeItems":"Transfer Commission if configured","authorizationLevel":"Checker1","errorCodeExpected":"SEC_NOT_FOUND,LAYER_QTY_MISMATCH,BENEFICIARY_ID_MISMATCH","alertType":"Error,Information","reconciliationStatus":"Reconciled","matchingCriteria":"Instrument,Custodian,Settlement Type,Quantity,Amount tolerance","auditTrailIds":"TransferInId,RepairActionId,AuthorizationId,OpenDeliveryId,SettlementAdviceId,TaxFileId,GLBatchId","taxIdentifierFlag":1,"assumptions":"ASSUMPTION Order level values always reported in ILS,ASSUMPTION CA ex-date restriction enforced by sender; if breached, BO will hold"},{"type":"functional","title":"Delivery In/Out - ADR to Local Security Conversion with Linked Legs","description":"Validate BO capture of ADR->Local conversion using Delivery Out and Delivery In linked via External Reference 2, approvals, matching, and zero-cash accounting.","testId":"TC-DELIVERY-ADR-015","testDescription":"Covers dual-leg capture, linkage integrity, settlement advice authorization, duplicate prevention, and movement/GL correctness for no financial consideration conversions.","prerequisites":"Customer holds ADR units sufficient for conversion, local security master present, delivery types configured (ADR to Local Sec Conversion), matching and settlement batches active.","stepsToPerform":"1. As BO Operator, create Delivery Out for ADR leg: select Transfer Type Delivery Out and Delivery Type ADR to Local Sec Conversion; enter portfolio, ADR instrument, quantity, and set External Reference 2 to CONV-REF-123.\n2. Create Delivery In for Local security leg: select Delivery In and Delivery Type ADR to Local Sec Conversion; enter same portfolio, target local instrument, corresponding converted quantity per ratio, and set External Reference 2 to CONV-REF-123.\n3. Submit both legs; system applies custody blocks and routes to maker-checker; assign to Checker1.\n4. Checker1 opens Authorization Queue, reviews both legs ensuring identical External Reference 2, approves; confirm both orders are Authorized and Open Deliveries created with linkage stored.\n5. Receive or create Settlement Advice(s) per custodian flow; if 1052 is used, ingest and confirm SA created; else authorize SA manually; verify OD and SA are eligible for matching.\n6. Use auto-match or manual matching to pair OD/SA for both legs; verify matchingCriteria Instrument,Custodian,Settlement Type,Quantity and that Amount is zero or within tolerance for no consideration.\n7. Run Settlement process; confirm statuses set to Settled for both legs and that customer ADR position is reduced while local security position is increased by converted quantity.\n8. Validate accounting: zero principal cash; security movements between customer ADR and local security with internal conversion accounts if configured; ensure correct TD/VD, no suspense postings.\n9. Attempt to re-upload the same 1052 or re-authorize SA with same External Reference 2; verify idempotence prevents duplicate SA or duplicate matching and logs 'Duplicate Conversion Ignored'.\n10. Review Security Transfer History/Delivery reports; ensure both legs show linked by CONV-REF-123 and auditTrailIds capture both transaction ids and GL batch.","expectedResult":"ADR to Local conversion is captured as two linked deliveries, approved, matched, and settled without cash consideration; positions and GL reflect correct conversion; duplicates are prevented and full auditability is preserved.","userRole":"Back Office Operator,Checker1","channel":"Back Office","exchange":"Foreign and Local","instrumentType":"ADR,Equity","orderType":"Delivery Out,Delivery In","currency":"USD,ILS","tolerance":0,"settlementCycle":"Per custodian","fileInputs":"1052 if available","interfaceName":"Delivery In/Out Conversion","batchName":"Settlement Batch","businessEvent":"Security Conversion No Consideration","accountingEntriesExpected":"No cash principal,Security DR/CR between ADR and Local instrument control accounts","glAccounts":"Customer Securities,Internal Conversion Control","authorizationLevel":"Checker1","errorCodeExpected":"DUP_SA_BY_EXT_REF if duplicated","alertType":"Information,Error","reconciliationStatus":"Reconciled","matchingCriteria":"Instrument,Custodian,Settlement Type,Quantity","auditTrailIds":"DeliveryOutId,DeliveryInId,ExternalRef2,OpenDeliveryIds,SettlementAdviceIds,GLBatchId","assumptions":"ASSUMPTION Conversion ratio is known and applied,ASSUMPTION Conversion treated as no financial consideration per policy"},{"type":"negative","title":"POA Restriction Enforcement - Call Centre Blocked, FO Allowed","description":"Validate that a bank-employee POA to a customer account cannot place securities orders via Call Centre, but can place via Front Office, with full audit and privacy controls.","testId":"TC-POA-FO-016","testDescription":"Covers POA restriction per policy (only FO placement), role-based access, error messaging, and E-Journal/audit lineage.","prerequisites":"Customer portfolio active; POA user mapped to the customer account; Call Centre Agent and FO user credentials; instrument ABCD listed on TASE with live entitlements; fee schedules and accounting rules configured.","stepsToPerform":"1. Login via SSO as Call Centre Agent; authenticate customer using masked ID **** and select target portfolio.\n2. Open Order Entry (Equity) for TASE symbol ABCD; set orderType Buy, price condition Limit 100.00 ILS, quantity 200, validity Good For Day; click Place Order.\n3. Observe validation modal; verify system identifies that the acting user is a POA and channel is Call Centre; proceed to Confirm.\n4. Verify order placement is blocked with explicit error and no order id generated; capture error code and alert type; confirm no cash/custody blocks are created.\n5. Check E-Journal Initiated By Me and Authorization Queue; ensure no authorization workflow can override the POA restriction at Call Centre channel.\n6. Log out; login as Front Office user acting under the same POA; load the same customer; open Order Entry for ABCD with identical parameters.\n7. Place order; pass standard Buying Power and market parameter validations; on Preview tick I Agree and Confirm; capture internal OrderId and status Authorized.\n8. Verify order routes to market (Placed with Market) and appears in Order Book; ensure audit trail records channel=FO, role=POA, and user ids.\n9. Validate privacy: any customer identifiers shown in FO and Call Centre screens are masked per policy; export or print actions are disabled or masked where required.\n10. Attempt MF Purchase via Call Centre as POA; confirm the same restriction applies and is blocked with consistent error code and audit log.","expectedResult":"Call Centre attempts by a POA to place orders are blocked with a clear non-overridable error; no artifacts (orders, blocks, postings) are created. Placement via FO succeeds with proper validations and audit lineage; PII is masked throughout.","userRole":"POA User,Call Centre Agent,Front Office User","channel":"Call Centre,Front Office","exchange":"TASE","instrumentType":"Equity,Mutual Fund","orderType":"Buy","validityType":"Good For Day","quantityType":"Regular","orderCategory":"Normal","currency":"ILS","price":100,"triggerPrice":0,"quantity":200,"tolerance":0,"settlementCycle":"T+1","fileInputs":"","interfaceName":"ST-SP Order Router","batchName":"","stateFrom":"Create","stateTo":"Blocked at Call Centre,Authorized at FO,Placed with Market","businessEvent":"Buy Client,Buy Broker (FO only)","accountingEntriesExpected":"None on blocked attempt,Standard entries on FO success","glAccounts":"Customer Cash,Nostro Cash,Fee Income","feeItems":"ST Commission","feeMethod":"flat percentage","minMaxApplied":"Yes if configured","taxRate":0,"authorizationLevel":"Not applicable for CC block,FO per limits","errorCodeExpected":"POA_CC_BLOCK","alertType":"Error at Call Centre,Information at FO","reconciliationStatus":"","matchingCriteria":"","auditTrailIds":"SessionId,POAFlag,BlockedAttemptId,OrderIdFO,ChannelTag","assumptions":"ASSUMPTION POA mapping is active and recognized by both channels,ASSUMPTION Same customer and portfolio are accessible to FO user"},{"type":"functional","title":"Pending Order Modification and Cancellation Matrix with Disclosed Qty, Stop Conditions and Nostro Cutoff","description":"Verify modification/cancellation constraints across price/validity/quantity types for a pending order, including partial fills, disclosed quantities, stoploss/stoplimit behavior, and the 'nostro open order cutoff' control.","testId":"TC-ORD-MOD-CANCEL-017","testDescription":"Decision-table and state-transition coverage for modify/cancel on pending vs partially executed orders with operational cutoff enforcement.","prerequisites":"Customer authenticated with sufficient buying power and entitlements; instrument ABCD on TASE; cutoff time configured; fee and accounting rules active.","stepsToPerform":"1. Place a Buy Stoplimit order for ABCD: quantity 1000, disclosed type with Initial 200 and Additional 100, triggerPrice 99.80, limitPrice 100.00, validity Good For Month; confirm Authorized then Placed with Market.\n2. Attempt to modify to Market price while keeping validity GFM; verify warning about change of price condition and impact on stop trigger; accept and confirm modification.\n3. Modify disclosed quantities: increase Initial to 300 and Additional to 200; verify decision-table validations (Initial <= total, Initial+Additional <= total) and save; confirm modification accepted and reflected in Order Trail.\n4. Simulate a partial execution of 250 units; verify open quantity 750 and disclosed quantities adjust per exchange rules; ensure custody/cash blocks update proportionally.\n5. Attempt to increase total order quantity to 1200 after partial fill; verify system restricts increase beyond allowed rules or requires new order; ensure error is displayed and no change is applied.\n6. Modify validity from Good For Month to Good For Day near end of trading; confirm the expiry date update and alerts regarding time-in-force change.\n7. Attempt to cancel the order; confirm cancellation accepted when open quantity exists and capture state transition to Cancelled for the remaining open qty only.\n8. Recreate a new Sell Limit order for the same symbol and leave it pending beyond configured 'nostro open order cutoff' time; at cutoff, verify the system auto-cancels or blocks leaving open orders per setup and logs an operational alert.\n9. Verify E-Journal entries for each modification/cancellation and that auditTrail captures every state change with timestamps and user ids.\n10. Export Order Book and Order Trail; validate fields for disclosed quantities, stop parameters, and cutoff actions are correctly populated.","expectedResult":"Modifications obey decision-table constraints for price/validity/quantity types; partial fills restrict quantity increases; cancellations apply only to open quantity; disclosed quantity adjustments and stop conditions are handled correctly; cutoff control enforces auto-cancel/block with full audit.","userRole":"Call Centre Agent","channel":"Call Centre","exchange":"TASE","instrumentType":"Equity","orderType":"Buy,Sell","validityType":"Good For Month,Good For Day","quantityType":"Disclosed,Regular","orderCategory":"Normal","currency":"ILS","price":100,"triggerPrice":99.8,"quantity":1000,"tolerance":0,"settlementCycle":"T+1","fileInputs":"ST-SP executions simulator","interfaceName":"Order Management and Routing","batchName":"Operational Cutoff Job","stateFrom":"Authorized,Placed with Market,Partially Executed","stateTo":"Modified,Cancelled,Auto-Cancelled at Cutoff","businessEvent":"No settlement impact until execution","accountingEntriesExpected":"Blocks only until execution; no postings on cancel","glAccounts":"Customer Cash,Customer Securities","feeItems":"Order Modification Fee if configured,Order Cancellation Fee if configured","feeMethod":"flat,flat percentage","minMaxApplied":"Yes per fee schedule","taxRate":0,"authorizationLevel":"Checker if maker limit exceeded","errorCodeExpected":"QTY_INC_AFTER_PARTIAL_NOT_ALLOWED if applicable","alertType":"Warning,Information,Error","reconciliationStatus":"","matchingCriteria":"","auditTrailIds":"OrderId,ModificationId,CancellationId,CutoffActionId","assumptions":"ASSUMPTION Exchange accepts disclosed quantity modifications on pending orders,ASSUMPTION Cutoff policy is enabled for the market"},{"type":"functional","title":"Positions Reconciliation EOD - TASE 1053, APEX 871 and Tax Engine Positions with Ageing and Idempotence","description":"Validate end-of-day position reconciliation for local (1053), foreign (871) and tax engine positions, including exception ageing, manual adjustments, and duplicate ingestion handling.","testId":"TC-POS-RECON-018","testDescription":"Covers file interface robustness, reconciliation state transitions, tolerance handling, manual close, and re-run behaviors.","prerequisites":"Settled positions exist for local and foreign securities; tax engine daily open positions file available; recon tolerances configured; CTRLM monitoring enabled.","stepsToPerform":"1. Run EOD ingestion for TASE 1053 (local); verify technical validations (date, format) pass and positions load to staging with provenance.\n2. Run EOD ingestion for APEX 871 (foreign) and Tax Engine Open Positions extract; ensure files are accepted and stored for reconciliation.\n3. Execute Reconciliation job; verify matched items move to state Reconciled and unmatched to Not Matched; capture counts by source (1053,871,Tax).\n4. Introduce mismatches: a) wrong quantity for a TASE symbol, b) an extra foreign position present in 871 but not in BaNCS, c) a symbol missing in tax-engine file; rerun recon and confirm these appear as exceptions with state Failed and Day-0 ageing.\n5. Advance business date and rerun ingestion with the same three files to test idempotence; verify duplicates are ignored and ageing increments to Day-1.\n6. Perform a manual position correction in BO to fix the TASE quantity; mark exception as Repaired and rerun recon; verify item moves to Reconciled and audit logs the repair action id.\n7. For the extra foreign position, create a manual security movement to align or mark as External Only per policy; confirm state transitions to Closed Manually and excluded from further ageing.\n8. For the symbol missing in tax engine, resend the tax positions file with corrected record; re-ingest and ensure the exception auto-resolves to Reconciled.\n9. Generate recon reports and exports; validate counts, states (Reconciled,Failed,Closed Manually), and ageing buckets; verify PII masking on exported outputs.\n10. Inject a late-arrival prior-date 1053 file; confirm reprocess policy posts to historical store without changing today’s reconciled statuses.","expectedResult":"All three sources reconcile correctly with clear classification of matched/unmatched; exceptions age across days, support manual repair/closure, and resolve on corrected ingestion; duplicate re-ingestion is idempotent; reports reflect accurate states and privacy.","userRole":"Back Office Operator","channel":"Back Office","exchange":"TASE,Foreign","instrumentType":"Equity,ETF,Fund","orderType":"NA","validityType":"NA","quantityType":"NA","orderCategory":"NA","currency":"ILS,USD","price":0,"triggerPrice":0,"quantity":0,"tolerance":0,"settlementCycle":"EOD","fileInputs":"1053,871,Tax Engine Positions","interfaceName":"Position Reconciliation","batchName":"EOD Recon Job","stateFrom":"Not Matched,Failed","stateTo":"Reconciled,Closed Manually,Aged","businessEvent":"Position Recon Adjustment","accountingEntriesExpected":"Only for manual corrections if movements posted","glAccounts":"Customer Securities,Internal Control","feeItems":"","feeMethod":"","minMaxApplied":"Not Applicable","taxRate":0,"authorizationLevel":"Checker approval for manual movement if required","errorCodeExpected":"DUP_FILE_IGNORED on re-ingest,FORMAT_ERR if malformed","alertType":"Information,Error","reconciliationStatus":"Reconciled,Failed,Closed Manually","matchingCriteria":"Customer,Security,Quantity,Settlement Date","auditTrailIds":"ReconRunId,FileBatchId1053,FileBatchId871,TaxPosFileId,RepairActionId","assumptions":"ASSUMPTION No CA ex-date adjustments during the test window,ASSUMPTION Timezone alignment is configured for foreign files"},{"type":"functional","title":"Regulatory Commission and Fee Reporting - TASE 814/815 and BOI 414 A/B/C with Publication and Idempotence","description":"Validate computation and reporting of commissions/fees and regulatory outputs, including averages and price list to TASE (814/815) and BOI 414 A/B/C to customers, with website publication for 414-A and SELL-only 3rd-party fee handling.","testId":"TC-FEE-REPORT-019","testDescription":"Covers fee decision-table, min/max caps, SELL-only SEC/TAF inclusion, CSV/PDF generation, privacy, and duplicate-run protection.","prerequisites":"Executed trades exist across Equity, ETF, MF with various fee items; fee schedule configured with flat, percentage, tiers, min/max; 3rd party flags enabled for SEC/TAF on SELL; report templates available; website publishing connector enabled.","stepsToPerform":"1. Execute a set of sample trades: a) Local Buy equity with tiered brokerage, b) Foreign Sell equity with SEC and TAF, c) MF purchase with commission; ensure trades are settled and fees computed.\n2. Run Fee Aggregation batch for the reporting period; verify computed fees per charge item, basis (transaction value,count,position value), and caps/min applied.\n3. Generate TASE 814 file: validate 'averages' section equals computed averages and 'price list' section reflects configured tariffs; ensure format and mandatory fields conform; store the file with run id.\n4. Generate TASE 815 if applicable per scope; verify presence/absence as per bank setup.\n5. Generate BOI 414-A/B/C customer packets: A (averages), B (transaction-level fees), C (safekeeping fees and holdings); ensure correct customer segmentation and period coverage.\n6. Publish 414-A to website channel; verify PII masking rules are applied and only required aggregates are exposed; confirm publication status in logs.\n7. Verify SELL-only rule: SEC and TAF appear only on the SELL foreign equity, marked as Third Party, and excluded from bank income totals; confirm mapping to Third Party Payable GL in supporting extract.\n8. Perform Boundary Value Analysis: include a trade where raw fee < min cap and one > max cap; confirm applied amount equals min or max respectively and reported correctly in all outputs.\n9. Re-run the reporting batches for the same period; verify idempotence prevents duplicate file creation or increments the version with no duplicate posting; logs show 'Duplicate Period Ignored' or similar.\n10. Validate distribution: files delivered to TASE and customer channels; BO summary report totals reconcile with GL Fee Income and Third Party Payable for the period.","expectedResult":"Regulatory files 814/815 and BOI 414 A/B/C are generated accurately from computed fees, published per policy with PII protections, SELL-only third-party fees are correctly tagged, caps/min/max are enforced, and duplicate runs are idempotent; totals reconcile to GL.","userRole":"Back Office Operator","channel":"Back Office,Website Publication","exchange":"TASE,Foreign","instrumentType":"Equity,ETF,Mutual Fund","orderType":"Buy,Sell","validityType":"NA","quantityType":"Regular","orderCategory":"Normal","currency":"ILS,USD","price":0,"triggerPrice":0,"quantity":0,"tolerance":0,"settlementCycle":"Period End","fileInputs":"Trade and Fee Stores","interfaceName":"Regulatory Reporting,Website Publisher","batchName":"Fee Aggregation,TASE 814/815,BOI 414 Generator","stateFrom":"Computed","stateTo":"Reported,Published","businessEvent":"Fee Reporting","accountingEntriesExpected":"No new postings; reconciliation vs Fee Income and Third Party Payable GLs","glAccounts":"Fee Income,Third Party Payable","feeItems":"ST Commission,SEC,TAF,Custody Fee if in scope","feeMethod":"flat,flat percentage,final tier,final slab","minMaxApplied":"Yes","taxRate":0,"authorizationLevel":"As per report release workflow","errorCodeExpected":"DUP_PERIOD_IGNORED on rerun","alertType":"Information,Warning","reconciliationStatus":"Reconciled vs GL totals","matchingCriteria":"Charge Item,Basis,Customer Segment,Period","auditTrailIds":"ReportRunId814,ReportRunId415or815,BOI414PacketId,WebsitePublishId","assumptions":"ASSUMPTION Latest 814/815 formats are loaded,ASSUMPTION Website publication channel is reachable"},{"type":"functional","title":"Within-Bank Securities Transfer - Virtual Sell with MU Restriction and CA Ex-Date Block","description":"Validate within-bank transfer using Virtual Sell (self) path, enforcing MU home-branch restriction, CA ex-date block, same-entity auto-detection, immediate settlement, and tax lot propagation.","testId":"TC-TRANSFER-VIRTUAL-020","testDescription":"Covers UI-heavy within-bank transfer Virtual Sell, ex-date prevention, maker-checker routing, and EOD tax updates.","prerequisites":"Customer holds settled TASE equities with available quantities; at least one security under CA ex-date today for negative path and another without CA; MU of operator differs from portfolio MU for the first attempt; maker-checker limits set.","stepsToPerform":"1. From Transfers > Security Transfer, attempt initiation while logged in at a non-home MU; verify error enforcing home-branch restriction and no draft created.\n2. Login at home MU and reopen Security Transfer; select a security that is on CA ex-date; keep default Available Quantity; proceed to Add Beneficiary.\n3. Select Within Bank and tick Virtual Sell; verify Same Entity and Transfer Case fields auto-disable and target portfolio auto-fills with source portfolio.\n4. Click Verify; confirm system blocks due to CA ex-date with explicit error and no custody blocks applied.\n5. Return to Select Security; choose a different TASE security without CA ex-date; keep full quantity; proceed to Add Beneficiary with Virtual Sell still enabled.\n6. Preview and review commission; tick I Agree; Release to trigger maker-checker; assign to Checker1; verify Authorization Queue shows transaction.\n7. As Checker1, approve; confirm status U-Authorized; by EOD process, verify within-bank transfer auto-settles (no external files) and custody blocks removed.\n8. Validate movements: security DR/CR within customer account per virtual sell design and internal control postings; ensure no cash principal is booked.\n9. Send EOD movements to tax engine; verify lots/layers transfer within the same entity and Same Entity Tax Identifier derived as 1; counters file alignment is maintained.\n10. Review Security Transfer History, E-Journal, and GL batch; ensure audit shows MU ids, Virtual Sell flag, and correct state transitions; attempt to select 'Transfer without Identification (Tax Event)' and confirm option is unavailable in Within Bank Virtual Sell.","expectedResult":"Virtual Sell within-bank transfer can only be initiated from the home MU, is blocked on CA ex-date, proceeds for non-CA securities with maker-checker, settles automatically by EOD, posts only security movements via internal control, sets taxIdentifierFlag=1, and maintains full audit trail.","userRole":"Branch Maker,Checker1","channel":"Back Office","exchange":"TASE","instrumentType":"Equity","orderType":"Security Transfer","validityType":"NA","quantityType":"Regular,fractional supported","orderCategory":"Virtual Sell","currency":"ILS","price":0,"triggerPrice":0,"quantity":0,"tolerance":0,"settlementCycle":"Same-day internal,EOD finalize","fileInputs":"None (within bank)","interfaceName":"Internal Transfer Processor,Tax Engine EOD","batchName":"Within Bank Transfer Settle,EOD Tax Feed","stateFrom":"Released,Authorized","stateTo":"Settled","businessEvent":"Transfer Within Bank Virtual Sell","accountingEntriesExpected":"Security DR/CR within internal control,No cash principal","glAccounts":"Customer Securities,Internal Transfer Control","feeItems":"Transfer Commission if configured","feeMethod":"flat","minMaxApplied":"Yes if configured","taxRate":0,"taxIdentifierFlag":1,"transferCase":"Self (Virtual Sell)","beneficiaryType":"Same account","sameEntity":"Yes","authorizationLevel":"Checker1","errorCodeExpected":"MU_HOME_BRANCH_REQUIRED,CA_EXDATE_BLOCK","alertType":"Error,Information","reconciliationStatus":"Not Applicable","matchingCriteria":"Instrument,Quantity,Same Portfolio","auditTrailIds":"TransferOrderId,AuthorizationId,GLBatchId,TaxFileId,MUIds","assumptions":"ASSUMPTION Virtual Sell is configured to settle by EOD without external files,ASSUMPTION CA indicators are up to date for ex-date validation"},{"type":"functional","title":"Mutual Fund Manual Price Correction via BO Screen - Reverse, Reallocate and Recompute","description":"Manually correct a Mutual Fund allocation price using the Allocation Reversal and Execution Handling screen, ensure reversals and reallocations at corrected NAV, idempotence and downstream accounting and tax re-computations.","testId":"TC-MF-MAN-PCRC-021","testDescription":"Covers manual price correction path distinct from auto 1051-based correction, enforcing maker-checker, movements reversal, fee re-compute, and tax engine re-postings.","prerequisites":"Customer holds MF units from T allocation at NAV_T, manual correction rights enabled for BO, Kafka events enabled for MF docs, accounting rules for MF allocation and settlement configured, EOD tax integration active.","stepsToPerform":"1. Authenticate to Back Office as Operator and open MF Allocation Reversal/Execution Handling screen; search fund XYZ and business date T with allocation at incorrect NAV_T.\n2. Validate current allocation details: units, NAV_T, allocation status, and that customer cash settlement was scheduled Contractual T+1; capture AllocationId and GLBatch reference for the initial entry.\n3. In Market Information, update Security Rate for the fund to corrected NAV_CORR for T (manual rate entry with provenance Manual Single); save and note RateBatchId.\n4. Return to MF manual correction screen; select action Reverse (movements only) and execute; verify reversal preview shows principal and commission negation; submit for authorization.\n5. As Checker1, approve the reversal; confirm movements are posted with exact negation and TD/VD stamps preserved; verify allocation status set to Reversed and auditTrail updated.\n6. Initiate Reallocate action for same order at NAV_CORR; preview recomputed commission per fee rules and confirm; route to Checker1; approve and ensure new AllocationId2 is created with corrected NAV.\n7. Ensure idempotence: attempt Reverse and Reallocate again for the same order without new rate change; system should block with errorCodeExpected ALLOC_CORR_ALREADY_APPLIED and no duplicate movements are posted.\n8. Ingest 1052 (street) for the fund on T+1; confirm street-side settlement posts once against the corrected allocation; verify duplicate SA creation is prevented by key TASE movement id,Event id,Security id,Quantity,Price.\n9. Run customer contractual settlement batch for T+1; ensure cash postings align to corrected NAV, and previous contractual entries are not duplicated; verify GL net equals corrected allocation only.\n10. Send EOD movements to Tax Engine; confirm prior tax placeholders are reversed and recomputed for settlement date with corrected NAV, lots updated and counters file received for last 10 days.\n11. Validate BO reports and Kafka events: MF allocation status shows Reversed and Reallocated, settlement report reflects corrected NAV, and MF documents events emitted with fund id and run timestamp.\n12. Review E-Journal and MF Order Book; ensure trail shows actions Reverse, Reallocate, Settled with user and time, and privacy masking applied to customer identifiers.","expectedResult":"Manual price correction reverses the original allocation and books a new allocation at corrected NAV, idempotently; settlement occurs once against the corrected allocation, GL and tax are recomputed correctly, reports and Kafka events reflect the correction, and full audit is maintained.","userRole":"Back Office Operator,Checker1","channel":"Back Office","exchange":"TASE","instrumentType":"Mutual Fund","orderType":"Price Correction Manual","validityType":"NA","quantityType":"Units","orderCategory":"Normal","currency":"ILS","price":0,"triggerPrice":0,"quantity":1000,"tolerance":0,"settlementCycle":"Contractual T+1,Street T+1","fileInputs":"1052","interfaceName":"MF Manual Price Correction,Market Information Rates,Tax Engine EOD","batchName":"Customer Settlement Batch,Street Settlement Batch,EOD Tax Feed","stateFrom":"Allocated","stateTo":"Reversed,Reallocated,Settled","businessEvent":"MF Purchase Allocation,MF Settlement","accountingEntriesExpected":"Reverse Principal,Reverse Fee,Post corrected Principal,Post corrected Fee","glAccounts":"Customer Cash,MF Units,Nostro Cash,Fee Income","feeItems":"MF Purchase Commission","feeMethod":"flat percentage,min max caps if configured","minMaxApplied":"Yes if configured","taxRate":0,"authorizationLevel":"Checker1","errorCodeExpected":"ALLOC_CORR_ALREADY_APPLIED","alertType":"Information,Warning,Error","reconciliationStatus":"Reconciled","matchingCriteria":"Fund Id,Units,NAV,Trade Date","auditTrailIds":"AllocationId,ReversalId,ReallocationId,RateBatchId,SettlementAdviceId,GLBatchId,TaxFileId","assumptions":"ASSUMPTION Fund supports manual correction flow,ASSUMPTION Original allocation not part of any corporate action"},{"type":"functional","title":"TASE Net Settlement Store-Only Ingestion and Recon Toggle - Files 32 and 1091","description":"Validate ingestion of TASE 32 and 1091 as store-only, configurable recon toggle when trading fee setup not feasible, idempotence on final D file, late arrival handling, and BO difference reporting.","testId":"TC-NETSET-1091-022","testDescription":"Covers interface robustness, duplicate prevention, sequence control, data augmentation, and reporting of differences without postings.","prerequisites":"Interfaces enabled to ingest 32 and 1091, system parameter ReconEnabledForTASEFees set to No, GoAnywhere routing active, executed and settled local trades exist for the day, CTRLM monitoring on.","stepsToPerform":"1. In Back Office, set ReconEnabledForTASEFees=No; verify toggle recorded in audit and that processing mode is Store Only with no postings.\n2. Ingest TASE File 32 for Business Date T flagged with record 01 Type=C (interim); confirm file is accepted, rows stored as-is with FileBatchId32A, and no recon is executed.\n3. Ingest TASE File 1091 for the same date; verify rows stored with FileBatchId1091A, augmented with portfolio id, security type, sub type; confirm no GL or fee recompute triggered.\n4. Generate 32 store report; verify the report is based on last file received and currently tagged interim; totals displayed with a watermark INTERIM and no reconciliation status.\n5. Re-ingest the same interim files; confirm idempotence logs Duplicate Ignored and no duplicate rows; CTRLM alerts only informational.\n6. Ingest TASE File 32 final (record 01 Type=D) for date T; confirm system supersedes prior interim for reporting and marks FileBatchId32B as FINAL; no processing beyond storage.\n7. Switch ReconEnabledForTASEFees=Yes; load a fee schedule for trading commissions; re-run Recon job; verify differences computed at trade level using 1091 vs BaNCS, flags mismatch amounts and produces difference column.\n8. Validate boundary cases: include one trade with fee below min cap (system applied min) and one above max cap (system capped); ensure reported applied fee equals min or max and difference vs 1091 highlighted.\n9. Upload a malformed 1091 with missing field; verify bad rows are rejected with errorCodeExpected FILE_FIELD_MISSING, good rows stored; CTRLM creates skip items and alertType Error.\n10. Inject a prior-date final 32 file after EOD; verify policy posts to historical store without changing today’s reporting or recon outcomes.\n11. Export BO recon and difference reports for 32 and 1091; verify PII masking on customer references, versioning includes FINAL tag and run timestamp.","expectedResult":"Files 32 and 1091 are stored idempotently, interim superseded by final for reporting; recon can be toggled on to compute differences when fee setup exists; malformed records are rejected with precise errors; reporting shows correct totals and differences without unintended postings.","userRole":"Back Office Operator","channel":"Back Office","exchange":"TASE","instrumentType":"Equity,ETF,Bond","orderType":"NA","validityType":"NA","quantityType":"NA","orderCategory":"NA","currency":"ILS","tolerance":0,"settlementCycle":"EOD","fileInputs":"32,1091","interfaceName":"Net Settlement Store,Fee Recon Toggle","batchName":"EOD Net Settlement Store,Recon Job","stateFrom":"Stored Interim","stateTo":"Stored Final,Reconciled,Failed for bad rows","businessEvent":"None,reporting only","accountingEntriesExpected":"None","glAccounts":"None","feeItems":"Trading Commission if setup","feeMethod":"flat percentage,min max caps,tiers","minMaxApplied":"Yes for configured items","taxRate":0,"authorizationLevel":"None","errorCodeExpected":"DUP_FILE_IGNORED,FILE_FIELD_MISSING","alertType":"Information,Error","reconciliationStatus":"Reported Differences Only","matchingCriteria":"PortfolioId,Security,TradeId,Fee Item","auditTrailIds":"FileBatchId32A,FileBatchId32B,FileBatchId1091A,ReconRunId,ToggleChangeId","assumptions":"ASSUMPTION TASE fee setup may be infeasible leading to store-only mode,ASSUMPTION No customer postings occur from 32 or 1091 ingestion"},{"type":"end-to-end","title":"Distribution Fee Daily Accrual and Month-End Fund-Manager Packet with Kafka Events","description":"Compute daily distribution fees on MF holdings, enforce exemptions, generate month-end per fund per manager packets (CSV/PDF), emit Kafka events, and idempotently handle reruns.","testId":"TC-DISTFEE-E2E-023","testDescription":"Validates fee engine for distribution fees, exemptions for money market funds and non-agreement cases, FX handling, leap-year logic, reporting, and privacy.","prerequisites":"Distribution fee configuration active at product level, fund manager agreements loaded for selected funds, holdings exist across multiple funds including one money-market fund, Kafka topic configured, BO summary report enabled.","stepsToPerform":"1. On Day D, run Distribution Fee Daily Accrual; verify accrual per fund uses NAV_D and position value in fund currency with FX to ILS where needed; store AccrualRunId.\n2. Confirm exemptions: money market fund accrues zero to customer and manager, and any fund without agreement accrues internally but is not billed to manager; ensure flags recorded.\n3. Include boundary cases: a) zero holdings day accrual equals zero, b) very large position triggers tier cap if configured; verify caps applied and stored.\n4. Advance days to cover month including a leap-day scenario if applicable; run accrual each day; confirm weekend/holiday behavior per config (skip or zero accrual) and continuity of totals.\n5. On Month-End, run Distribution Fee Packet Generator; verify per fund per manager CSV and PDF generated with columns specified (Fund Id, Fund Manager Name, Total Sec Qty, Exempted Holding, Total Sec Value, Total Charge Amount, Date, Rate, Currency, Fund Category, Distribution Fee).\n6. Verify website or secure email channel not used for customers, and that fund-manager packets are delivered to secure email as configured; capture ReportId and delivery status.\n7. Ensure Kafka events emitted for each generated packet with metadata (fund id, period, run id) and no PII; verify consumer receives events.\n8. Generate BO summary report aggregating all managers; confirm totals reconcile with GL (Fee Income) if accounting is posted monthly or remain off-ledger if memo-only per bank policy.\n9. Rerun the Month-End generator for the same period; verify idempotence: either versioned output with no duplicate accounting or rerun blocked with errorCodeExpected DUP_PERIOD_IGNORED.\n10. Alter one day’s accrual by back-dated position correction; rerun recompute job; ensure delta adjusts month total and updated packet is regenerated with new version and audit retained.\n11. Validate privacy: outputs mask customer PII and include only aggregates; confirm access controls enforced for report retrieval.","expectedResult":"Daily accruals compute correctly with FX and caps, exemptions honored, month-end fund-manager packets produced and delivered with Kafka events, BO summary reconciles with GL policy, reruns are idempotent or versioned without duplicate postings, and privacy is enforced.","userRole":"Back Office Operator","channel":"Back Office,Secure Email,Kafka","exchange":"TASE","instrumentType":"Mutual Fund","orderType":"NA","validityType":"NA","quantityType":"Units","orderCategory":"Distribution Fee","currency":"ILS,USD","tolerance":0,"settlementCycle":"Daily accrual,Monthly packet","fileInputs":"NAV feeds for funds","interfaceName":"Distribution Fee Engine,Packet Generator,Kafka Publisher","batchName":"Distribution Fee Daily Accrual,Month-End Packet Generator,Recompute Job","stateFrom":"Accrued Daily","stateTo":"Reported Monthly,Delivered","businessEvent":"Distribution Fee Accrual,Distribution Fee Reporting","accountingEntriesExpected":"As per bank policy monthly posting to Fee Income or memo-only","glAccounts":"Fee Income","feeItems":"Distribution Fee","feeMethod":"flat percentage,tiers with caps","minMaxApplied":"Yes","taxRate":0,"authorizationLevel":"As per report release policy","errorCodeExpected":"DUP_PERIOD_IGNORED","alertType":"Information,Warning","reconciliationStatus":"Reconciled vs GL totals if posted","matchingCriteria":"Fund Id,Manager,Period","auditTrailIds":"AccrualRunId,MonthEndRunId,PacketIdCSV,PacketIdPDF,KafkaEventId,RecomputeId","assumptions":"ASSUMPTION Money market funds are exempt for customer charges,ASSUMPTION PII is not included in manager packets"},{"type":"functional","title":"Third Party Transfers (Foreign Custodian) - Delivery Out/In with Reporting and Manual Settlement","description":"Process a third-party transfer to or from a foreign custodian without TASE files, including maker-checker, reporting extract, and manual movement generation to settle.","testId":"TC-TP-FOREIGN-024","testDescription":"Validates third-party transfer case not sent to TASE, linkage to reports, manual settlement posting, and GL correctness.","prerequisites":"Customer holds foreign securities, transfer case Third party Transfer available in BO, report template for third party transfer available, internal transfer control GLs mapped, authorization limits set.","stepsToPerform":"1. As BO Operator, open Create Securities Transfer Order; choose Delivery Out; select foreign instrument ABC.N in USD; enter quantity including fractional if supported; set Transfer Case to Third party Transfer.\n2. Enter beneficiary custodian details in remarks or external reference as per bank convention; ensure Outside Bank path is disabled for non-TASE and that this transfer is flagged as Not Sent to TASE.\n3. Preview commission and charges if configured; tick I Agree; Release to trigger maker-checker; assign to Checker1; note TransferOrderId and Virtual Sell unchecked.\n4. As Checker1, approve; verify status U-Authorized, custody block applied, and no BOD File 15 scheduling is created.\n5. Generate Third Party Transfer report extract; verify record shows portfolio id, instrument, quantity, expected deliver date, beneficiary custodian fields, and that PII is masked as required.\n6. After custodian confirms off-system, post Manual Settlement movements: reduce customer securities and post to Internal Transfer Control; ensure TD/VD correct and currency USD with FX translation to account currency ILS if required for valuation.\n7. For an incoming leg (Delivery In), repeat steps 1–4 with Transfer Type Delivery In; after custodian confirmation, post manual receipt movements to increase customer securities and reverse internal control; ensure lots/layers captured and Same Entity logic not applied.\n8. Validate duplicate prevention: attempt to repost manual settlement for the same external reference; system blocks with errorCodeExpected DUP_EXT_REF and no duplicate postings occur.\n9. Review Security Transfer History; confirm both legs show Transfer Case Third party Transfer, Not Sent to TASE marker, statuses Settled, and audit entries Initiated By Me and Authorized By Me.\n10. Verify accounting: no cash principal posted, only security DR/CR against internal control; export GL batch for audit.","expectedResult":"Third-party transfers proceed with maker-checker, no TASE files are generated, reporting extract is produced, manual settlement postings correctly adjust positions and GL control accounts, duplicate postings are prevented, and audit history is complete.","userRole":"Back Office Operator,Checker1","channel":"Back Office","exchange":"Foreign","instrumentType":"Equity,ETF","orderType":"Delivery Out,Delivery In","validityType":"NA","quantityType":"Regular,fractional supported","orderCategory":"Third party Transfer","currency":"USD,ILS","tolerance":0,"settlementCycle":"Per custodian confirmation","fileInputs":"None (not sent to TASE)","interfaceName":"Third Party Transfer Report,Manual Settlement","batchName":"Authorization Workflow only","stateFrom":"Released,Authorized","stateTo":"Settled","businessEvent":"Transfer Third Party","accountingEntriesExpected":"Security DR/CR with Internal Transfer Control,No cash principal","glAccounts":"Customer Securities,Internal Transfer Control","feeItems":"Transfer Commission if configured","feeMethod":"flat","minMaxApplied":"Yes if configured","taxRate":0,"authorizationLevel":"Checker1","errorCodeExpected":"DUP_EXT_REF","alertType":"Information,Warning,Error","reconciliationStatus":"Not Applicable to TASE recon","matchingCriteria":"External Reference,Instrument,Quantity","auditTrailIds":"TransferOrderId,AuthorizationId,ManualSettlementId,ReportId","assumptions":"ASSUMPTION Custodian confirmations are handled outside system,ASSUMPTION External reference used as idempotence key"},{"type":"functional","title":"FO Daily Re-Placement for Future-Dated Validity with Stoplimit Triggers Across Days","description":"Place a Good For Month At the Opening Stoplimit order and verify FO re-places it daily until executed or expired, with correct trigger behavior, blocks management, and state transitions.","testId":"TC-FO-REPLAY-025","testDescription":"Covers FO handling of future-dated validity, stoplimit decision-table boundaries, cross-day partials, and expiry.","prerequisites":"FO–BO integration active, instrument ABCD on TASE with live entitlements, buying power sufficient, operational cutoff and trading calendar configured.","stepsToPerform":"1. As Call Centre Agent, authenticate customer (masked ID ****) and open Order Entry; set Buy, Stoplimit, triggerPrice 99.80 ILS, limit price 100.00 ILS, quantity 1200, validity Good For Month, release condition At the Opening; place order and confirm.\n2. Verify status Authorized then Placed with Market (At the Opening for Day 1); ensure cash block equals consideration plus estimated fees and expiry date reflects month end or configured limit.\n3. Simulate Day 1 open with LTP opening below trigger (e.g., 99.50) then rising above trigger to 99.90 but below limit; verify trigger condition met and order enters market at limit 100.00; if no fill, remains Pending; cash block remains.\n4. End Day 1 with no fills; verify FO automatically re-queues the order for Day 2 At the Opening; Order Trail shows Re-Placement by FO with timestamp and no new OrderId (or shows child submission id if design uses child tickets).\n5. On Day 2, simulate partial execution 300 @ 99.95; verify order status Partially Executed, open quantity 900, cash block decreases proportionally, and sale proceeds table not used for buy; reconciled vs 1051 as Not Matched until file arrival.\n6. Modify trigger boundary: change triggerPrice to 100.00 equal to limit; confirm decision-table allows equality or raises warning per rules; approve modification; FO uses updated trigger from next day.\n7. On Day 10, simulate open price above limit (e.g., 100.20); verify order rests at limit price per exchange rules; execute further 600; open quantity 300 remains; validate state/history reflects multi-day partials.\n8. On penultimate business day, reduce market liquidity such that remaining 300 never fills; ensure FO continues daily submission; cash block reflects only open portion; watch operational alerts for upcoming expiry.\n9. On expiry date (Good For Month end), verify FO does not re-place; system auto-expires remaining open quantity; status changes to Expired; cash blocks released and E-Journal records Auto-Expiry.\n10. Validate no unauthorized override occurred; ensure auditTrail includes FO re-placement entries, modifications, executions, and expiry; export Order Book and Trail to confirm At the Opening and stoplimit parameters across days.\n11. Negative check: attempt to manually re-place expired order; system requires new order and blocks reuse with errorCodeExpected ORDER_EXPIRED_REUSE_NOT_ALLOWED.","expectedResult":"FO re-places the At the Opening Good For Month stoplimit order daily, triggers and executes per conditions, manages cash blocks on partials, and auto-expires residual quantity at validity end; audit trail captures each re-placement and expiry, and expired orders cannot be reused.","userRole":"Call Centre Agent,Front Office System","channel":"Call Centre,Front Office","exchange":"TASE","instrumentType":"Equity","orderType":"Buy","validityType":"Good For Month,At the Opening","quantityType":"Regular","orderCategory":"Normal","currency":"ILS","price":100,"triggerPrice":99.8,"quantity":1200,"tolerance":0,"settlementCycle":"T+1 for executed portions","fileInputs":"ST-SP executions,1051 for trade recon","interfaceName":"Order Management,FO Daily Re-Placement","batchName":"Auto-Expiry Job if applicable","stateFrom":"Authorized,Placed with Market","stateTo":"Partially Executed,Modified,Expired","businessEvent":"No settlement impact until execution","accountingEntriesExpected":"Blocks only,postings on executed portions in separate flows","glAccounts":"Customer Cash","feeItems":"Order Modification Fee if configured","feeMethod":"flat","minMaxApplied":"Yes per schedule","taxRate":0,"authorizationLevel":"Checker if maker limit exceeded","errorCodeExpected":"ORDER_EXPIRED_REUSE_NOT_ALLOWED","alertType":"Information,Warning","reconciliationStatus":"1051 Reconciled for executed parts","matchingCriteria":"Instrument,Exec Qty,Exec Price,Trade Date","auditTrailIds":"OrderId,FOReSubmitIdOrMarker,ModificationId,ExecutionIds,ExpiryActionId","assumptions":"ASSUMPTION FO creates re-placement records without changing OrderId or links child submissions,ASSUMPTION Trading calendar excludes holidays correctly"}] \ No newline at end of file diff --git a/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.xlsx b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.xlsx new file mode 100644 index 00000000..cd4f293a Binary files /dev/null and b/functional_tests/TCSBaNCS_functional-after-fix_clone/TCSBaNCS_functional-after-fix_clone.xlsx differ