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)?

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.

This should be actual revenue, so we don't want to do any currency conversion. Maybe we should have a currency selector on the report page? Otherwise, we'd want to list each service that has processed in different currencies as many times as there are transactions of different currencies. Most people will process in a single currency, so the currency selector is probably fine, and just default it to the default currency if possible.

The currency conversion would have already taken place when the payment was made. So an invoice may be in EUR to pay for a package in USD. Your "Amount" column is only representative of a single currency sum. So your solution is to filter by currency and find all transactions in that currency that apply to that package?

What about invoices that have multiple packages on them, or other line items that are not for the package?

Yes, I think that makes sense. I suppose you only consider closed invoices, so partial payments would not be counted, but it wouldn't really be possible to determine how much of a partial payment is for what package.

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.

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.

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.

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?

Yes, it's considered a parent even if there are no children under it

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.

It's a bummer that service changes can't be counted, we should probably include a note about that someplace. It's ok that older invoices that do not have a service association are not counted.

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.

That's a good observation, perhaps we should include it. It should at least be consistent.

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.

I don't think we need to consider the payment source, whether the transaction was considered a credit or not. It's probably best if people giving discounts actually discount the invoice rather than apply a credit transaction. Though, if it's possible to show how much of applied payments were from credit transaction types that would be useful.

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.

As long as we explain in the docs or in a tooltip what the limitations are, I think the report would still be useful. Can the number of units be counted from total unique service IDs associated with the invoices? This should weed out any duplicates.

I updated the task to ignore whether a Package is a parent or child, I don't think that matters much. Each Package should contain a single line in the report. This should remove some complexity because a Package might be both a parent and a child. We'll just count each package once.

The goal of the report is to determine how much revenue each Package has generated over a given period. We'll ignore partially paid invoices.

I think we would fetch all invoices that were closed within the selected date range, compile a list of service ID's and amounts for all resulting invoices. From there we can determine quantity of services per Package and total received. If tax is recorded separately, let's not count that. Hopefully that simplifies the report enough that we can move forward with it.