WEBVTT 00:00:01.300 --> 00:00:05.340 An alert describes a condition. A sell request asks for an action. 00:00:05.340 --> 00:00:09.379 A fill records an executed amount. These are three different kinds of 00:00:09.379 --> 00:00:13.419 evidence. A changing price can bring a position near an exit condition 00:00:13.419 --> 00:00:17.459 without creating a completed sale. Likewise, clicking a submission button does not 00:00:17.459 --> 00:00:20.825 by itself prove that the requested quantity has been sold. 00:00:21.325 --> 00:00:25.178 In a position sell flow, Accepted means the request is awaiting confirmed 00:00:25.178 --> 00:00:29.031 fills. Pending confirmation means no fill has yet been confirmed to that 00:00:29.031 --> 00:00:32.884 flow. Read the words that follow the status rather than stopping at 00:00:32.884 --> 00:00:36.738 a reassuring first word. While the result is uncertain, keep the request 00:00:36.738 --> 00:00:40.591 reference and inspect its status instead of starting another sale to see 00:00:40.591 --> 00:00:41.875 whether that one works. 00:00:42.375 --> 00:00:46.367 Filled, when confirmed by the server, is stronger evidence of execution. Even 00:00:46.367 --> 00:00:50.359 then, check the quantity and the matching records. Your original holding may 00:00:50.359 --> 00:00:54.351 have contained more than the amount requested. A confirmed sale of four 00:00:54.351 --> 00:00:58.343 units from a ten-unit holding leaves six units, assuming no other activity. 00:00:58.343 --> 00:01:02.335 Confirmation of a request does not automatically mean the entire original holding 00:01:02.335 --> 00:01:03.000 has disappeared. 00:01:03.500 --> 00:01:07.153 Another message can say that the provider outcome was received while internal 00:01:07.153 --> 00:01:10.806 accounting is still pending. That means one part of the process has 00:01:10.806 --> 00:01:14.459 responded, but the app has not finished recording the result internally. The 00:01:14.459 --> 00:01:18.112 screen specifically tells you not to start another sale. Allow that request 00:01:18.112 --> 00:01:21.765 to be reconciled and check the relevant records; do not try to 00:01:21.765 --> 00:01:24.200 repair a display delay by creating another order. 00:01:24.700 --> 00:01:29.096 A resolved request can also be described as ended with accounting confirmed. 00:01:29.096 --> 00:01:33.493 The accompanying wording matters: this does not necessarily mean the entire requested 00:01:33.493 --> 00:01:37.889 amount was sold. An ended order and a fully filled order are 00:01:37.889 --> 00:01:42.285 different outcomes. Use the executed quantity, any remaining holding, and the recorded 00:01:42.285 --> 00:01:44.850 status together to understand what actually finished. 00:01:45.350 --> 00:01:49.107 If the request was not confirmed, or the browser closed before you 00:01:49.107 --> 00:01:52.863 saw the outcome, use the available Saved sell requests recovery flow. Its 00:01:52.863 --> 00:01:56.620 Check status or retry same request action is designed around the original 00:01:56.620 --> 00:02:00.376 request and amount. Do not clear saved requests to manufacture a fresh 00:02:00.376 --> 00:02:04.133 attempt. Recovery can be blocked when identity or account evidence is missing; 00:02:04.133 --> 00:02:06.950 read that message and return to the original context. 00:02:07.450 --> 00:02:11.466 Closing a dialog after submission is not the same as cancelling an 00:02:11.466 --> 00:02:15.482 exchange order. A connection error is not proof that nothing happened, either. 00:02:15.482 --> 00:02:19.498 In Live, compare with the connected exchange's order and fill records when 00:02:19.498 --> 00:02:23.515 necessary. If the app received a status but failed to refresh the 00:02:23.515 --> 00:02:27.531 portfolio, treat that as a reconciliation problem rather than assuming the sale 00:02:27.531 --> 00:02:28.200 itself failed. 00:02:28.700 --> 00:02:32.635 For any outcome, ask three questions. What was requested? What amount is 00:02:32.635 --> 00:02:36.570 confirmed as executed? What still needs an update or a status check? 00:02:36.570 --> 00:02:40.505 Those questions work for successful, partial, and uncertain results. They help you 00:02:40.505 --> 00:02:44.440 stay precise without needing to understand the software behind the scenes, and 00:02:44.440 --> 00:02:48.375 they prevent a confusing message from turning into an accidental duplicate action.