It was needed to show clear profit in Ubercart reports in my case so I made this patch and I also suggest to port it into the project. If it seems really useful for community of course.

CommentFileSizeAuthor
ubercart-reportsfixed-01.patch14.32 KBcoveryoureyes

Comments

Status: Needs review » Needs work

The last submitted patch, ubercart-reportsfixed-01.patch, failed testing.

coveryoureyes’s picture

I dunno what's exactly wrong with my patch!

longwave’s picture

Version: 7.x-3.4 » 7.x-3.x-dev
Status: Needs work » Needs review

Patches should be tested against -dev.

longwave’s picture

ubercart-reportsfixed-01.patch queued for re-testing.

longwave’s picture

I would prefer to see all reports customisable through Views in #568854: Replace uc_reports with Views, though this is perhaps worth adding in the interim.

DanZ’s picture

Do all the reports need to be moved to Views at once, or would it be reasonable to have the legacy reports around at the same time as the newfangled Views reports?

longwave’s picture

I don't see why we can't keep the existing ones around as well, for now. I certainly don't expect to switch every report to use Views in a single patch; trying to do them one at a time is much more sensible.

tr’s picture

Status: Needs review » Needs work

I think the most common use case is that sites don't even use the cost field, which means that a profit column wouldn't hold any meaningful data for those sites. I don't think we should be adding additional columns to the existing reports based on one user's needs. A far more "profitable" approach is to expose fields like profit to Views, so that users can build their own ad hoc reports. Note also that profit is a tricky term - hardwiring in a definition of sale price minus cost is probably not a good thing to do. Because it's a derived value, do we even need to explicitly expose it to Views? Can't the calculation be done in the View itself, or through something like a computed field?

Ubercart is not intended to be nor will it ever be a software package for accounting. Consequently, I personally just export all my orders to an external accounting program for reporting and tracking numbers like profit. The built-in reports should just be used for general information, trends and guidance, as they don't/can't/won't conform fully to accepted accounting practices.*

*As a specific example, Ubercart does not distinguish between cash and accrual accounting methods, so it's unlikely that the reports will provide the sort of accurate financial data that can be used for tax reporting or auditing purposes. Perhaps someone is interested in integrating an open source accounting package with Drupal/Ubercart? That would be great, but that will have to be a contributed module - it's not something that's going to be put into core Ubercart.

DanZ’s picture

Status: Needs work » Closed (won't fix)

Note also that profit is a tricky term - hardwiring in a definition of sale price minus cost is probably not a good thing to do. Because it's a derived value, do we even need to explicitly expose it to Views? Can't the calculation be done in the View itself, or through something like a computed field?

A Views computed field could do it on a per-item basis, either for listed products (nodes) or for ordered products.

However, you really want a computed entity field (stored in the DB). Doing it via a Views computed field would not work, because Views cannot use aggregation (SQL SUM()) on computed values.

Since ordered products are now fieldable entities, this absolutely could be done via a computed field. A field added this way is automatically exposed to Views. In fact, this sort of thing is the exact reason for all that work in making that entity fieldable. There's no need to add anything further to Ubercart.

So, a profit field can be added to the ordered product entity type at admin/store/settings/orders/products/fields. A custom report can be made with Views. This will give you everything you need, and with no patches.