Parent/Child is useful for just determining what kind of service it is. You can determine if it's a parent/child pretty easily by checking if services.parent_service_id is set. If it is, it's a child, if not, parent.
So if a service has a parent, it is denoted Child. If a service does not have a parent, it is denoted Parent regardless of whether it may have any children?
I think that answers your second question, only count invoices that are paid in full. You can pull the total because the service is linked to the line item for the invoice. You might have more than 1 service on an invoice, but if it's paid in full then you'd count the line item price.
Partial payments would of course have to be ignored since it is arbitrary what service line items the partial amount could be applied to from the invoice. But not all package line items from an invoice are linked to a service, like service changes. Older invoices could not be checked for revenue since they do not reference a service at all.
This wouldn't consider taxes, and I don't think we want to include taxes anyway. Not sure about coupons though, we wouldn't want to count the pre-coupon price since we're going for the total actual revenue from the package.
Are taxes not apart of revenue now? Even the Billing Overview plugin includes taxes in the revenue calculation since that comes from transactions. It sounds like this calculation is inching toward being profit instead of revenue.
If a coupon is used on the service then that discount could not be considered in the revenue calculation, furthering the total revenue inaccuracy. Also, if multiple transactions are used to pay an invoice, and one of them is a credit transaction, then that transaction wouldn't count as revenue, but it's not possible to determine which part of the invoice is paid with non-credit transactions in order to identify the appropriate service(s) paid, so the calculated total revenue would not be representative of the service revenue.
It appears to me that there are too many variables that cannot be accounted for, which will cause any attempts to calculate package revenue to be wildly inaccurate. The number of "Units" would also not be feasible since we wouldn't know whether the invoice contains line items for a new service, an updated service, or added/updated/changed service options.
How is a parent/child reference useful? We know whether the service has a parent, but we don't necessarily know whether the service has any children unless we search for some.
What if a package is sold in multiple currencies? Do we go by the configured pricing amount even if a transaction may be applied in a different currency (e.g. converted)?