You could certainly build a query to handle this, but I strongly suggest against it. A few years ago, I had a couple projects very similar to this where I asked myself the same question. Originally, I developed it to calculate on-the-fly, by taking all the sum of all the related lines (quantity * price) - very similar to your situation. As the projects grew, more business logic was required, which added many layers of complexity. For an example, let's take a quotation. The original quote's body might sum up to an amount, but maybe doesn't take into account extra charges, overhead, extension of work, etc. Scenarios like this arose to the need to add a user-specified "total bid value", which if present, would override the lines calculation. You can see how conditionals such as this can easily break-down and cause headaches in trying to go down this road.
Instead, I suggest that at the time of persistence (including update) is when you perform your net total calculation, and then save it as a field on your parent record. This still gives you the ability to perform on-the-fly calculations, but without the overhead of performing costly joins and other additional calculations. I also have some experience with ERP integrations, and many enterprise solutions take this same approach of storing the calculated total.