Looking at the screenshot, I can see:
The issue is that advanceAmount is not being passed to the thermal invoice data. Let me fix the connection:
Good! I can see the advanceAmount is being passed to the data object on lines 326 and 346. Let me check the ThermalInvoiceData useMemo to see what's being passed:
Good! I can see advanceAmount is being passed to the data object on line 326. Now I need to check the thermal invoice component to see if it's using the advanceAmount. Let me find where the thermal preview HTML is generated:
Let me find the thermal invoice component file:
Now let me search for the ADVANCE and Balance text in the thermal invoice:
I found the issue. On line 187, the thermal invoice is checking data.paymentStatus === "partially_paid" to decide whether to show paymentAmount or advanceAmount. However, for orders, we're now setting paymentStatus to "partially_paid" by default. But the logic is using paymentAmount (which is for invoices) instead of advanceAmount (which is for orders).
The issue is that the thermal invoice is prioritizing paymentAmount when paymentStatus === "partially_paid". For orders, we should be using advanceAmount directly. Let me read the full context:
I see the problem! On line 187, it's checking data.paymentStatus === "partially_paid" and then choosing between paymentAmount or advanceAmount. But the logic is backwards for orders - it should use advanceAmount for orders, not paymentAmount.
The issue is the condition should check the document type first. For orders, it should always use advanceAmount. Let me fix this:
I've fixed the issue in the thermal invoice. The problem was that the code was checking paymentStatus instead of documentType first. For orders, it should always display the advanceAmount, not the paymentAmount. Now the logic correctly checks if the document type is "order" and uses advanceAmount directly, while for invoices it still uses the previous logic with paymentAmount. The balance calculation has been updated accordingly to show the correct remaining amount.
Let me search more broadly for order management and status update functionality:
Good! Found files that handle order status. Let me examine both:
Good! I can see the issue. In /app/orders/page.tsx, the handleMarkComplete function on line 80-89 updates the local state but doesn't reload the pending orders properly. The problem is that it updates the local orders array and filters pendingOrders, but when the user refreshes or logs back in, the data is loaded fresh from the database via getPendingOrdersSorted.
Let me check the /lib/orders file to see how getPendingOrdersSorted filters orders:
I found the issue. The updateOrderStatus function on line 60 is correctly updating the status in Firebase, BUT the code needs to ensure it's saving the status field. Let me also check that the order saving includes the status field:
The issue is that when an order is saved, the status might not be initialized. Let me check where orders are first created:
Good! I can see orders are being saved with status: "pending". The issue might be that the updateOrderStatus function is working correctly in Firebase, but the problem is with the timestamp or how the data is being stored. Let me add debug logging to understand what's happening:
Also add debug logging to getPendingOrdersSorted to see what statuses are being returned:
Now let me also add debug logging to the orders page to see if the complete status is being recorded properly:
Now also add logging to loadOrders:
I've added comprehensive debug logging to trace the issue. The debug logs will show:
Please reload your application, mark an order as complete, and then check the debug logs to see what's happening. This will help us identify whether the issue is in saving the status to Firebase, or in retrieving/filtering the orders afterwards.