1. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 1 Process Flow for TSS - Supplier This document describes the process and interdialogue rules in the NeBI interface between TSS and subcontractors. Security: Public

2. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 2 Document History 2003-12-11Ove FritzC 2004-02-23Lars AbrellD 2005-10-11Per RudalPE1RenegOrder init av FNS uppdaterad, ny slide ExecuteOrder med OEA justerade format (master slide), puts 2005-10-11Per RudalPE2FNS ändrat till Supplier, puts av slide Villkor 2005-11-04Per RudalPE3Nya slides Dialogöversikt o Affärsregler. ExecuteOrder med OEA borttagen tills vidare. 2005-11-04Hans GustePE3_1Rubrik Affärsregler ändrad till Interdialogregler, Approved tillagt sid 1 2005-11-18Anders HultinPE3_2Interdialogregler kommenterade efter internt Relacommöte 2005-12-07Per RudalPE4Interdialogreglerna uppdaterade efter e-gs-forum 29/11. CancelOrder: ruta 6b, “ESN2”, är ny. RenegOrderBySup: ruta 12, “manuell hantering” är borttagen. 2005-12-23Per RudalPE5Interdialogreglerna uppdaterade efter e-gs-forum 14/12 (h-regel 4, tillägg 4-6) Nya slides: 2 Transaktionsmönster, 3 Omsändning o larm 2006-01-16Per RudalPE6Uppdatering efter e-gs-forum 11/1: slide 2, Transaktionsmönster; slide 3, Omsändning, heart-beat o larm; slide 11, Inderdialogregler 2, punkt 2, 3, 6. 2006-06-20Per RudalEVersion för gränssnittsdokument J. PE7 utgår. Röd reservationstext i Interdialogreglerna borttagen. 2006-06-20Per RudalFVersion för gränssnittsdokument K. Ny slide 9, RenegotiateOrder initierad av Supplier alt B. 2006-06-20Per RudalPG1Dialog för leveransgodkännande, “ExecuteOrder med OEA” återinförd (jmfr PE1 o PE2 ovan) 2006-10-20Per RudalPG2slide 3: Omsändning http-nivå Telia: 3*120s -> 7*4min slide 4 Dialogöversikt + slide 9, Reneg Supplier alt B + slide 11, EO m levgodk: version 3.1 -> 4.0 2006-11-08Per RudalGVersion för gränssnittsdokument L 2006-12-01Per RudalPH1Version för gränssnittsdokument M Ny layout. Ny slide 6, NegotiateOrder med förhandling + slide 4, Dialogöversikt uppdaterad 2007-01-19Hans Guste, PeRuPH2Translation to English. New doc name “NeBi_proc_TSS-Supplier PH2”. New slide Dialogue rules. Inter-dialogue rules updated. 2007-01-31Per RudalHProcess version for NeBI_doc_TSS-Supplier_M.doc (no changes except for version and date) 2007-02-15Per RudalPI1Process version for NeBI_doc_TSS-Supplier_PN1.doc: added dialogue InvoiceDetail 2007-05-10Per RudalPI2slide 14, InvoiceDetail: InvoiceDetailPart rules 2007-09-19Per RudalPI3New slide 15, RequestRequisite (+ slide 5, Dialogue overview updated), slide 3, Transaction Pattern adjusted for RR 2007-09-28Per RudalIProcess version for doc spec N. Slide RequestRequisite corrected 2007-11-26Per RudalPJ1Process version for doc spec PO1. Added slide 13+15, dialogues ExecuteOrder_3.1 + 4.1 2007-12-20Per RudalJProcess version for doc spec O. Slightly adjusted are slides 13, 15 and 20 rule 2.. 2008-05-30Per RudalPK1New slide 4 Transaction Validation and Feedback. Slide 3 Transaction Pattern: Improved text 2008-09-02Per RudalPK2New slides: slide 4: Transaction Validation and Feedback 1; slide 18: EO w partial execution + delivery acc Improved slides: slide 5, Trans Validation and Feedback 2; slides 14-17, EO variants: statuses; slide 23: Inter-dialogue Rules 2

3. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 3 Transaction Pattern Responder 2. Request (dialog + trans) 4. ebMS header validation 13. ebMS header validation NeBI Application Trans B Trans A Initiator 8. Request (dialog + trans) 11. Request (dialog + trans) 16. Request (dialog + trans) 6. Ack / Error 15. Ack / Error 1. 7. 9. 10. 17. Dialog X The dialogue above is an example. The internal flow of a party (B2B to/from App) including function names etc are determined entirely by the party itself. Dialogue X consists of two transactions: trans A, inititiated by the Initiator; and trans B, initiated by the Responder. The common public NeBI-interface (B2B to B2B, pink above) shows the NeBI transaction pattern which is valid for all NeBI transactions (but RequisiteRequest). A NeBI transaction (each pink box above) consists of: a) A transaction request, which is an http-request holding one ebMS-message including a business document, e g an Order b) A transaction reply, which is a new separate http-request holding one ebMS-message containing an MSH-ack or Error 3. ebMS service + action (=dialog + trans) 5. MSHack / Error 14. MSHack / Error 12. ebMS service + action (=dialog + trans) B2B

4. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 4 B2BBusiness App Receiving Party B2BBusiness App Sending Party Transaction Validation and Feedback 1 NeBI Transaction 1a. Business Message 1 A) Send msg type 1 B) Is Msg 1 valid? 1c. MSH ack D) Correct msg 1f. Transaction Accept (TA) 1e. Transaction Complaint (TC) 1d. Transaction Reject (TR) C) Is Msg 1 valid? The figure shows the generic NeBI transaction pattern. For a specific transaction all, some or none of the signals (Error/MSH ack, TR/TC/TA) may be enabled/allowed. A NeBI transaction consists of: a)A Business Message, which contains a business document, e g Order, OrderResponse, ExecutionStatus, etc. b)An optional ebMS Error signal, which contains errors detected by the receiving party B2B server, e g formal errors concerning mime/soap/xml validity, party id’s, dialog and transaction names, etc. c)An optional ebMS Message Server Handler acknowledgment (MSH ack), which is a reception acknowledgment from the receiving party B2B server (not from the business application, compare Transaction Accept). d)An optional Transaction Reject (TR), which means that the receiving party business application has rejected the Business Message, i e the transaction is not valid and message content is not used by the receiving party. Reasons for rejection are formal errors not detected by the B2B server or violated business rules, e g the business process does not permit the transaction. The sending party is supposed to correct the errors and resend the transaction or act according to the business process. e)An optional Transaction Complaint (TC), which means that the receiving party business application regards the message as incomplete, not fully understandable or disagrees with some parts. The transaction is still valid and the correct parts of the message are used by the receiving party. The sending party is supposed to use the information in TC to improve future transactions. Reasons for complaint are minor errors such as ESN2 without preceding OC in respons to an OCR; ESN2 with reason NewOrder when not permitted in OR; missing less important field values, etc. f)An optional Transaction Accept (TA), which means that the receiving party business applicaton has received and fully understood the message. The signals Error and MSH ack are mutually exclusive, ie only one of them may be sent in a transaction instance. The same goes for TR, TC and TA. The Business Message as well as the signals (Error/MSH ack, TR/TC/TA) are (currently) sent in separate http requests. 1b. ebMS Error

5. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 5 Transaction Validation and Feedback 2 Party X B2BBusiness App Party Y B2BBusiness App Trans 3 Trans 2 J) Send msg type 3 F) Send msg type 2 NeBI 2a. Business Message 2 3a. Business Message 3 E) Business logic: trans 2 or 3 Trans 1 1a. Business Message 1 A) Send msg type 1 B) Is Msg 1 valid? 1c. MSH ack 1b. Error 2c. MSH ack 2b. Error G) Is Msg 2 valid? H) Is Msg 2 valid? D) Correct msg I) Correct msg L) Is Msg 3 valid? 1f. Transaction Accept 1e. Transaction Complaint 1d. Transaction Reject C) Is Msg 1 valid? 2f. Transaction Accept 2e. Transaction Complaint 2d. Transaction Reject K) Is Msg 3 valid?

6. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 6 Resending, Heart-beat and Alarms Sönnico, Ericsson? 1.Resending on http-level If http-return is not received for an http-request, then: TSSwill resend the http-request every 4min 7times Eltelwill resend the http-request every 120s during 24h 2.Resending on transaction level If MSH-ack (Message Service Handler Acknowledgment) is not received for a transaction, then: TSSwill resend the trans every 10 minutes during 24h (given http-return is received, see 1 above) Relacomwill resend the trans with increasing interval during 24h Eltelwill resend the trans every 10 minutes during 24h (given http-return is received, see 1 above) 3.Heart-beat TSS sends fictitious orders (also called Topaz-order) every 15 minutes to be able to supervise the functionality of the flow also when normal traffic is low. 4.Transaction alarm TSSIf OA is not received by TSS within X minutes after OR is sent, TSS supervision staff will be notified (historically called 15-minutes alarm). The time is configurable per business agreement. Relacomwill supervise TSS heart-beat Eltelwill supervise TSS heart-beat This slide describes the resending pattern, heart-beats and alarms for (missing) events in the NeBI interface. All values are configurable. Current values are indicated.

7. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 7 Dialogue Overview 1.NegotiateOrder [nebi.biz:BC:NegotiateOrder_3.0] 2.NegotiateOrder with order content negotiation[nebi.biz:BC:NegotiateOrder_4.0] 3.RenegotiateOrder initiated by TSS[nebi.biz:BC:RenegotiateOrder_3.0] 4.RenegotiateOrder intiated by Supplier alt A[nebi.biz:BC:RenegotiateOrder_3.0] 5.RenegotiateOrder initiated by Supplier alt B[nebi.biz:BC:RenegotiateOrder_4.0] 6.CancelOrder [nebi.biz:BC:CancelOrder_3.0] 7.ExecuteOrder [nebi.biz:BC:ExecuteOrder_3.0] 8.ExecuteOrder with transaction complaint [nebi.biz:BC:ExecuteOrder_3.1] 9.ExecuteOrder with delivery acceptance[nebi.biz:BC:ExecuteOrder_4.0] 10.ExecuteOrder w delivery acc + trans complaint[nebi.biz:BC:ExecuteOrder_4.1] 11.ExecuteOrder w partial execution + delivery acc[nebi.biz:BC:ExecuteOrder_4.2] 12.InvoiceDetail [nebi.biz:BC:InvoiceDetail_4.0] 13.RequestRequisite [nebi.biz:BC:RequestRequisite_3.0]

8. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 8 NegotiateOrder [nebi.biz:BC:NegotiateOrder_3.0] TSS B2BApplication Supplier B2BApplication 1. OrderRequest ByBuyer d) Reject order c) Accept order a) Send order NeBI 2. OrderAcknowledgment BySupplier 3. DialogueCancellation BySupplier b) Is the order acceptable?

9. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 9 NegotiateOrder with order content negotiation [nebi.biz:BC:NegotiateOrder_4.0] TSS B2BApplication Supplier B2BApplication 1. OrderRequest ByBuyer d) Reject order c) Accept order a) Send order NeBI 2. OrderAcknowledgment BySupplier 3. DialogueCancellation BySupplier b) Is the order acceptable? e) Change order 4. OrderRequest BySupplier 5. OrderAcknowledgment ByBuyer g) Accept changed order 6. DialogueCancellation ByBuyer h) Reject order f) Is the change acceptable? i) Change Supplier order

10. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 10 RenegotiateOrder initiated by TSS [nebi.biz:BC:RenegotiateOrder_3.0] TSS B2BApplication Supplier B2BApplication 1. OrderUpdateRequest ByInitiator d) Reject change c) Accept change a) Change order NeBI 2. OrderUpdateAcknowledgment ByResponder 3. DialogueCancellation ByResponder b) Is the change acceptable?

11. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 11 RenegotiateOrder initiated by Supplier alt A [nebi.biz:BC:RenegotiateOrder_3.0] TSS B2BApplication Supplier B2BApplication NeBI a) Request Order change 1. OrderUpdateProposalRequest ByInitiator 2. DialogueCancellation ByResponder c) Reject the change request 3. OrderUpdateRequest ByResponder d) Change the order e) If the OUPR concerns a cancellation the dialogue is ended and TSS initiates a new CancelOrder dialogue. b) Is the change acceptable? h) Reject the change g) Accept the change 4. OrderUpdateAcknowledgment ByInitiator 5. DialogueCancellation ByInitiator f) Is the change acceptable?

12. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 12 RenegotiateOrder initiated by Supplier alt B [nebi.biz:BC:RenegotiateOrder_4.0] TSS B2BApplication Supplier B2BApplication NeBI a) Change order 1. OrderUpdateRequest BySupplier 2. OrderUpdateAcknowledgment ByBuyer c) Accept order change 3. DialogueCancellation ByBuyer d) Reject order change b) Is the change acceptable?

13. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 13 CancelOrder [nebi.biz:BC:CancelOrder_3.0] TSS B2BApplication Supplier B2BApplication 1. OrderCancellationRequest d) Reject cancellation c) Accept cancellation a) Cancel order NeBI 2. OrderCancellation 3. DialogueCancellation ByResponder Comments to c) If Supplier wants payment for the cancelled order, Reason.Name is set to 'faktureras’ in OC and ESN2+OE are sent in an ExecuteOrder dialogue. In rare occasions, Supplier will not be able to send ”OC faktureras”. This will not give TSS problems. b) Is the cancellation acceptable?

14. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 14 ExecuteOrder [nebi.biz:BC:ExecuteOrder_3.0] TSS B2BApplication Supplier B2BApplication NeBI b) Report event 1. ExecutionStatusNotification 1 f) Send WorkReportReady 2. ExecutionStatusNotification 2 i) Send CommitmentReady 3. OrderExecuted ESN2 events ProvisionalWorkReportPreliminärArbetsrapport WorkReportReadyArbetsrapportKlar ESN1 events DistributedUtlämnad WorkBegunArbetePåbörjat SubReportDelrapport MessageMeddelande DormantVilande ResumedÅterupptaget ObjectReadyAnläggningKlar OE events CommitmentPartlyReadyÅtagandeDelvisKlart(OPER) CommitmentReadyÅtagandeKlart(OER) a) For every ESN1 event

15. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 15 ExecuteOrder with transaction complaint [nebi.biz:BC:ExecuteOrder_3.1] TSS B2BApplication Supplier B2BApplication NeBI b) Report event 1. ExecutionStatusNotification 1 f) Send WorkReportReady 3. ExecutionStatusNotification 2 i) Send CommitmentReady 5. OrderExecuted 2. TransactionComplaint d) Reject ESN c) Bad ESN 4. TransactionComplaint g) Bad ESN h) Reject ESN 6. TransactionComplaint j) Bad OE k) Reject OE e) A TC with status ’reject’ means the faulty trans has not updated the order, while status ’complaint’ means the order has been updated with the correct parts of the defect trans. ESN2 events ProvisionalWorkReportPreliminärArbetsrapport WorkReportReadyArbetsrapportKlar ESN1 events DistributedUtlämnad WorkBegunArbetePåbörjat SubReportDelrapport MessageMeddelande DormantVilande ResumedÅterupptaget ObjectReadyAnläggningKlar OE events CommitmentPartlyReadyÅtagandeDelvisKlart(OPER) CommitmentReadyÅtagandeKlart(OER) a) For every ESN1 event

16. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 16 ExecuteOrder with delivery acceptance [nebi.biz:BC:ExecuteOrder_4.0] TSS B2BApplication Supplier B2BApplication NeBI c) Send WorkReportReady 2. ExecutionStatusNotification 2 d) Send CommitmentReady 3. OrderExecutedRequest 5. OrderExecutedAcknowledgment g) Accept CommitmentReady 4. OrderExecutedDenial f) Reject CommitmentReady e) Is executedreport acceptable? b) Report event 1. ExecutionStatusNotification 1 ESN2 events ProvisionalWorkReportPreliminärArbetsrapport WorkReportReadyArbetsrapportKlar ESN1 events DistributedUtlämnad WorkBegunArbetePåbörjat SubReportDelrapport MessageMeddelande DormantVilande ResumedÅterupptaget ObjectReadyAnläggningKlar OE events CommitmentPartlyReadyÅtagandeDelvisKlart(OPER) CommitmentReadyÅtagandeKlart(OER) a) For every ESN1 event

17. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 17 ExecuteOrder w delivery acc + trans complaint [nebi.biz:BC:ExecuteOrder_4.1] TSS B2BApplication Supplier B2BApplication NeBI 8. OrderExecutedAcknowledgment m) Accept CommitmentReady 7. OrderExecutedDenial l) Reject CommitmentReady k) Is executed report acceptable ? b) Report event 1. ExecutionStatusNotification 1 e) Send WorkReportReady 3. ExecutionStatusNotification 2 2. TransactionComplaint d) Reject ESN c) Bad ESN 4. TransactionComplaint f) Bad ESN g) Reject ESN h) Send CommitmentReady 5. OrderExecutedRequest 6. TransactionComplaint i) Bad OER j) Reject OER n) A TC with status ’reject’ means the faulty trans has not updated the order, while status ’complaint’ means the order has been updated with the correct parts of the defect trans. ESN2 events ProvisionalWorkReportPreliminärArbetsrapport WorkReportReadyArbetsrapportKlar ESN1 events DistributedUtlämnad WorkBegunArbetePåbörjat SubReportDelrapport MessageMeddelande DormantVilande ResumedÅterupptaget ObjectReadyAnläggningKlar OE events CommitmentReadyÅtagandeKlart(OER) a) For every ESN1 event

18. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 18 TSS B2BBusiness App Supplier B2BBusiness App NeBI ExecuteOrder w partial execution + delivery acc [nebi.biz:BC:ExecuteOrder_4.2] 11. OrderExecutedAcknowledgment l) Accept commitmentReady 10. OrderExecutedDenial k) Reject commitmentReady i) Send CommitmentReady 9. OrderExecutedRequest ESN2 events ProvisionalWorkReportPreliminärArbetsrapport WorkReportReadyArbetsrapportKlar ESN1 events DistributedUtlämnad WorkBegunArbetePåbörjat SubReportDelrapport MessageMeddelande DormantVilande ResumedÅterupptaget ObjectReadyAnläggningKlar d) Report event 4.ExecutionStatusNotification 1 Distributed / WorkBegun a) For each event h) Send WorkReportReady 8.ExecutionStatusNotification 2 WorkReportReady OE events CommitmentPartlyReadyÅtagandeDelvisKlart(OPER) CommitmentReadyÅtagandeKlart(OER) j) Is commitment really ready? e) Report event 5.ExecutionStatusNotification 1 SubReport / Message / Dormant / Resumed a) For each event (optional and repeatable) 3. OrderExecutedAcknowledgment c) Accept commitmentPartlyReady 2. OrderExecutedDenial b) Reject commitmentPartlyReady a) Report Commitment- PartlyReady 1. OrderPartlyExecutedRequest e) Is commitment really partly ready? The grey area is optional and may be repeated before WorkReportReady g) Send Provisional- WorkReport 7.ExecutionStatusNotification 2 ProvisionalWorkReport f) Report event 6.ExecutionStatusNotification 1 ObjectReady a) For every PWR (optional and repeatable)

19. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 19 InvoiceDetail [nebi.biz:BC:InvoiceDetail_4.0] TSS B2BApplication Supplier B2BApplication NeBI a) Send InvoiceDetailPart 1. InvoiceDetail 2. InvoiceDetailAcknowledgment c) Ok 3. InvoiceDetailComplaint d) Not Ok b) Is the InvoiceDetail Correct? -All parts are sent in the same conversation -IDA/IDC must arrive before sending next part a) ID is sent for every InvoiceDetailPart

20. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 20 1. transaction BTA:RequisiteRequest RequestRequisite [nebi.biz:BC:RequestRequisite_3.0] TSS B2BApplication Supplier B2BApplication a. BD:RequisiteRequest a) Send request NeBI b. BD:Requisite Find Requisite Observe that BTA:RequisiteRequest, unlike all other transactions in this document, is a transaction that has a reply that contains a business document. The dialogue RequestRequisite consists of only one transaction, BTA:RequisiteRequest.

21. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 21 Dialogue Rules 1.A dialogue defines a transaction pattern between two parties 2.A conversation is an instance of a dialogue. It is identified by its conversationId which must be unique. 3.Every transaction contains a conversationId so that the receiving party can associate the transaction with a conversation

22. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 22 Inter-dialogue Rules 1 Within each dialogue the process rules are illustrated by the sequence diagrams in the previous slides. The following slides describe inter-dialogue rules that are rules that apply to concurrent dialogues that concern the same order. Principal rules 1.The first dialogue for every order is NegotiateOrder 2.Concurrent dialogues concerning the same order are permitted 3.Transactions are not permitted towards an order with a completed ExecuteOrder dialogue 4.An order is identified by its OrderId which must be unique The rule means that every NegotiateOrder dialogue concerns a new order with a unique orderid (see below for order resend though). When a new unique order is rejected in the NegotiateOrder dialogue using DialogueCancellation, then the order, including its orderid, is regarded as non-existant. The orderid of the rejected order may be reused in a new NegotiateOrder dialogue. In a conversation of dialogue type ”NegotiateOrder with order content negotiation” all transactions, possibly including multiple OrderRequest transactions operate on the same order, thus using the same orderId. This does not violate the rule since the the same conversation is used. 5.Resending an order is allowed if the “resend flag” is set When resending, the order content is identical, apart from the resend flag. Resending is done when an order needs to be sent through the regular channel at a time when it has already reached Supplier through a reserve channel.

23. dokID: Telia AB CIO Office nr 2002/007/1, rev PK2, 2008-09-02 [Approved: J Alatalo, SIG] sid 23 Inter-dialogue Rules 2 Exceptions, additions and explanations 1.The dialogue NegotiateOrder must be finished before starting ExecuteOrder [OA before ESN/OE] Info: Some violations of the rule occurs for technical reasons, since the IT components between the business application endpoints not always manage to maintain the original business application transaction sequence. The reason is that the IT components have parallel execution threads. This problem is most common during recovery after a stop. 2.ESN2/OE is not allowed to be sent during an ongoing RenegotiateOrder initiated by supplier TSS will reply with TransactionComplaint. Info: If TSS does not respond to OrderUpdate(Proposal)Request in a timely manner, the Supplier should contact TSS through other channels. 3.WorkReportReady (ESN2) confirms cancellation request (OCR) [ESN2 = OC + ESN2] Explanation: Supplier does not need to confirm OCR with OC if Supplier sends ESN2 in the dialogue ExecuteOrder, see slide CancelOrder. 4.In the dialogue RenegotiateOrder initiated by supplier, an ”impossible” orderchange (OUR) as an answer to OUPR may be rejected by the Supplier Info: Subsequent status reporting (ESN/OE) is allowed, but cannot be handled by TSS. Manual routines must be used. 5.Supplier may initiate multiple simultanous RenegotiateOrder dialogues Info: TSS will however reject new instances of RenegotiateOrder initiated by supplier. Supplier must wait for the ongoing dialogue to complete or contact TSS through other channels in order to solve the problem.