Extend auto-billing to other types of Storm node

This would be a wonderful addition and I do feel it would be necessary to include #560832: timetrack record invoice status not only so that the auto billing features would work correctly but also for an admin who is looking through the timetrackings.

@Magnity:

I think there are two approaches to the multiple time price issue.
1) Use which ever comes further down the list. i.e. If Ticket Price exists use that if not use Task Price, if Task price exists use that if not use Project price.
2) Don't allow multiple prices, but this may have problems with previous installations.
I suppose at least you can override it on the invoice.

I would also agree that the TimeTracking needs to record if it's been billed.

Can I make one further (maybe seperate) suggestion, we use different rates, contracted, pre-paid, non-contracted etc. Can we change the price field to an auto-complete coming from a rate list defined in attributes? Should we also have a default price set somewhere so we don't have to fill it in?

Almost exactly what I think I need. We use tickets for customer issues (bugs, problems, etc.), separate from projects. We then add time-trackings associated with those tickets. It seems to me that Tickets should be able to output to invoice and include all its time, and after reading the responses here, that functionality could be added to all portions of storm.

Also, the suggestion for different pricing rates would be almost necessary in our situation, as we bill different rates for "after-hours", "emergency", and "weekend"

The way I see it is:

I would think it is assumed that for all tasks/projects/tickets we are doing for clients (that are billable), we would want to invoice the client. Why not make it easier (in my head atleast...) to add a PAID (Wait, this is what "billed" does? are billed and paid the same thing?) flag to each Storm node

So far, each storm node would have as follows: Price rate for that project/task/ticket, and how its billed (hourly, flat, etc), and also PAID flags.

Invoicing should then do the following:
When clicking 'create new invoice' - One should be able to select the Organization, and all items that are part of it that have not yet been PAID should be automatically added to the invoice (with the option to manually remove them), this would filter through, so if in invoice I would select Organization, and then Project, all items part of that project (tasks, tickets, timetrackings) would be added to invoice.

It seems to me that items that are BILLABLE should also be automatically INVOICE-ABLE - as I don't see a situation where we bill something to a client without invoicing them.

What do you guys think? (Hope I made sense, typed it quick without thinking)

I agree. I think auto invoicing by way of organization/ticket/project is a definite must. I just also think multiple rate structures are severely limiting in that multiple price rates must be done on separate time trackings.

"Product" as separate item seems to be needed as new tracked entity.

Product needs following minimum properties:
- Name ; Comment
- Type (taxonomy)
- Active (available in pick-lists; can use Published status)
CCK fields:
- Unit_Value (required) ; UnitType (none/hour/day/month/quantity)
- Min_Value (minimum to always apply/null) ; Max_Value (maximum to always apply/null)
(Might be meaningful to simply extend Product from Ubercart/eCommerce)

Usage in Project/Task/Ticket:
For a Project - define allowed Products as part of its config
For a Task - Pick a Product applicable to it from the Project list
For a Ticket - Pick a Product applicable to it from the Project list

Then we can simply define a "Support" project for on-going Customer support

Invoicing
Create Invoice-Items from the Products associated to Task/Ticket, taking Duration/Quantity from Task & Ticket

I'm working on #735694: timetracking records not taking fixed price from organisation, project or task. which I need to do to extend the functions for a customer.
Extending it further for billing of other node types within Storm would also be an advantage to my customer too.

Although it might take me a little while to do this one, I'd like to offer to try and develop this, after I finish the other one.
I can't promise that I can do it as this will be my first BIG storm development task but I already have a plan in mind for it.

If agreed, I can post details of what I propose to add/change, for discussion.

Go ahead.

A lot of the code can probably be copied from the timetrackings bit - will probably need a 'billed' flag on each.

OK. I've made a list of some things I would change under this issue.
The aim is to allow invoices to be created from other node types but I'm not thinking of adding any additional validity checks (i.e. allow task creation on open projects only etc...)

Let me know what you think:

1- billable flag on project/task/ticket (plus admin pages to control defaults)
2- billed flag on project/task/ticket
3- add node id of invoice to project/task/ticket/timetracking (to trace back to invoice)
4- add route from invoice item back to original project/task/ticket/timetracking record
5- if price mode is project, all created tasks/tickets/timetracking under it are "not billable" by default.
6- if price mode is task, all created tickets/timetracking under it are "not billable" by default.
7- if price mode is ticket, all created timetracking under it are "not billable" by default.
8- add new filters for views module for new columns
9- add new filters for storm pages
10- "add to invoice" function for project/task/ticket (plus "already billed" message)

11- close project/task/ticket with invoice creation? Maybe not.

12- Use exisiting permissions to allow invoice creation.

5/6/7: Not sure about these because in some circumstances, I think someone might want to bill for a timetracking (for example), but listed on the invoice as unbilled.

9: What do you mean?

Hopefully we can do this step by step (where appropriate) to make reviewing easier. Of course, the more people that chip in to review things, the less you have to wait for me (a hint that someone will hopefully pick up on).

9. For example, allowing people to filter by billed/billable for the storm/tickets, /tasks, /projects pages, as they can do for storm/timetrackings page at the moment.

5/6/7: I can see both sides of this.
i) A supplier wants to put all information on an invoice about the timetracking and list as unbilled, then create bill at project level.
ii) A supplier wants to put NO information on the invoices except for the billed project.

I suppose we could have another admin flag to switch on/off this function.
If the flag is on, it will calculate billable, otherwise it uses the normal default set by the site.

Great. Go ahead.

Thank you for tackling this.

(The following is based on my use of phpCOIN, a "basic" but functionally very rich free billing solution)

It seems that the following concept are still outstanding:
- Order : It is similar to a Project, but could cater for Products & Services.
- Payment : Settles All/Part of an Invoice

Invoices thus can cover all/part of a either the following: Order/ Effort on a Project / Effort on a Task.

Order - has Order Items (status:draft,quote, pending, accepted, completed, cancelled; rest similar to Invoice)
Invoice - has Invoice Items
Payment - has single item (date-time, value, method, comment)

Flow is then:
a) Order -> Invoice -> Payment
b) Order -> Project -> Invoice -> Payment
c) Project -> Invoice -> Payment
d) Task -> Invoice -> Payment

Order Items:
- Are in fact Products (can also have manual-entry ad-hoc product).
- Must be able to set Recurrence: project/task / once-off / day/week/month/quarter/year

Invoice Items:
- Copy the Recurrence property from the Order Item / Is Once-off for Project, Task

Use Cases:
a) Invoice Use-Case: Auto/Manual create Invoice from Order:
Create Invoice ,related to Order ID, with Items copied from Order

b) Project Use-Case: Auto/Manual create Project from Order Item:
Create Blank Project,related to Order ID + Order Item in the Order

c) Task Use-Case: Auto/Manual create Task from Order Item:
Create Task, related to Order ID + Order Item in the Order

d) Invoice Use-Case: Auto/Manual create Invoice from Project:
Create Invoice ,related to Project ID (same working as current)

e) Invoice Use-Case: Auto/Manual create Invoice from Prev Invoice:
Create Invoice for new period with same properties as prev, copy Invoice Items

Thanks You for all your effort on enhancing STORM for all of us!

Hi,
I attach a first patch file. This allows the billing of a project onto an invoice.
I've moved some of the functions from the timetracking module into the invoice module if they will be used in more than one place.

I've also separated the code for creating the invoice number into a new storminvoice function, as it's also used in more than one place.

Let me know what you think and I can continue to work on the rest.

I'm not sure about comment #14. I've read it a few times and can't get my head around it. It sounds like a different requirement to that originally mentioned.

Any comments from anyone?

Thanks for this tchurch, should be a good step forward.

I've only really done a quick read through - a couple of comments below, probably more to come when I get a minute.

Also, I appreciate this needs a fair few changes, and so might need a few reviews - if there are any of the more basic changes, such as separating the invoice number generation into it's own function etc., that could be submitted as their own patch, I'd be happy to commit these sorts of distinct parts so to try to reduce the amount that we have to review all in one patch!

+++ stormproject/stormproject.install	26 Apr 2010 10:00:51 -0000
@@ -77,4 +79,12 @@ function stormproject_update_6104() {
+function stormproject_update_6105() {

Needs doxygen comment. Would be useful on a couple of other functions too.

+++ stormproject/stormproject.theme.inc	26 Apr 2010 10:00:51 -0000
@@ -36,13 +36,41 @@ function theme_stormproject_view($node, 
+  // Code to create invoice auto_add link
+  if (module_exists('storminvoice') && user_access('Storm invoice: add')) {
+    if ($node->billable && !$node->billed) {
+      $v = '';
+      $v = '<strong>'. t('Invoice this item:') .'</strong>';
+      $v .= '<ul>';
+      $v .= '<li>'. l('Add to new invoice', 'storm/invoice/auto_add/new/'. $node->nid) .'</li>';
+      $v .= '<li>'. l('Add to existing invoice', 'storm/invoice/auto_add/existing/'. $node->nid) .'</li>';
+      $v .= '</ul>';
+    }
+    elseif ($node->billed) {
+      $v = '';
+      $v .= '<strong>'. t('Item already billed.') .'</strong>';
+    }
+    else {
+      $v = '';
+      $v .= '<strong>'. t('Item marked unbillable.') .'</strong>';
+    }
+    ¶
+    $node->content['links']['auto_invoice'] = array(
+      '#prefix' => variable_get('storm_icons_display', TRUE) ? '<dt id="storminvoices" class="stormcomponent">' : '<dt class="stormcomponent">',
+      '#suffix' => '</dt>',
+      '#value' => $v,
+      '#weight' => 6,
+    );
+  }

Perhaps this could be generated by a function now that it will be used by several of the modules. Perhaps based on an arg of nid and billed.

Powered by Dreditor.

I've created issue #781814: move invoice number code into separate function for the invoice number generation. I'll post the separate patch code soon for it.

We could also split the rest by adding the billable/billed flags, then the invoice integration. Simply makes it easier to review!

I started working on the project level first so that I could make sure I got everything working and transferred any multiple code into their own functions. Once I've done this and we're happy with the way the functionality works, I might start the patches again and split it in this way (i.e. adding fields, generic function switches and then for each invoice integration).

At the moment for the project level, it will first look for that project's price mode and if not found then it's organizations.
I plan for task etc... to work in the same way (i.e. check task, then project and organization, stopping at the first one found).

It seems to be working so far.

As per #16, I've created #784188: Place "add to invoice" link in separate function for the invoicing icon.

My Comment #14 Extends on the requirements.

Order:
It introduces Order as added source for spawning an Invoice.
An Order can spawn multiple Products & Services, which may include 1/more Projects, 1/more Invoices.
I'm not sure if Order should be a separate Requirement.

Non-Billable Sub-items:
I agree with "locking" sub-items as described in #9 - good point (these must be billed WITH the parent, not separate).

Relation between Billable Items and Invoices
I've noticed though some Billing-sources tend to spawn multiple Invoices:
- Orders : Multiple Services and/or Products on one order
- Projects : Invoiced Monthly / each Milestone / each Deliverable
This requires the Invoice to tie back to the Order/Project/etc. , with the Invoice Items copied from the source.

Home this clarifies (or at least not muddle further)

Thanks

I suggest that the points of #14 / #21 should be a separate issue once this one is complete - adding the auto-billing functionality on it's own will be a good step forward by itself. We can then look to see what might be missing from the workflow (remembering that almost all users will have a slightly different workflow).

I have to agree with juliangb.
It sounds like it could include new node types.

Opened #786148: Add billed to filter on list page to add billed filter to timetracking (to be same as billed filter).

Opened #788204: move invoice item description/amount code into storminvoice module to move invoice item description code into storminvoice module.

Regarding #14, #21
I've added Order as new Feature Request: http://drupal.org/node/795884

Please refer to it, as I've attempted to spell out how Order Items become either: Invoice Items, Projects, Tasks

Have a look at this new work-in-progress.

It includes billing for project and tasks, recording nid for the item in the invoice_items table and filters for billed/billable.

Let me know what you think.

Looks ok from a read through. A couple of minor bits below.

Need to have a couple of people test this out.

+++ storminvoice/storminvoice.module	23 May 2010 15:55:03 -0000
@@ -730,15 +730,21 @@ function _storminvoice_insert_items($nod
+      total, weight, ¶

Trailing whitespace.

+++ stormproject/stormproject.module	23 May 2010 15:55:04 -0000
@@ -675,3 +701,77 @@ function stormproject_views_api() {
+      //$s = "SELECT MAX(CAST(SUBSTRING_INDEX(sin.number, '/', 1) AS SIGNED)) FROM {node} n INNER JOIN {storminvoice} sin ON n.nid=sin.nid
+      //  WHERE n.type='storminvoice' AND YEAR(FROM_UNIXTIME(sin.requestdate))=YEAR(FROM_UNIXTIME(%d))";
+      //$date = getdate($new_invoice->requestdate);
+      //$new_invoice->number = (db_result(db_query($s, $new_invoice->requestdate)) + 1) .'/'. $date['year'];
+      $new_invoice->number = storminvoice_get_invoice_number($new_invoice->requestdate);

Commented out code could be deleted here.

Powered by Dreditor.

(Comment deleted)

#27: issue_567558_project_task.patch queued for re-testing.

#29 was a post on the wrong issue. To clarify, this hasn't been committed yet.

I think that this almost there, but I'm not sure that the it is adding subcomponents onto the invoice correctly.

Also, I spotted this existing bug: #817322: Auto created invoices are dated 01-Jan-70 which should probably be fixed before we add to the auto-create functionality.

The bug #817322: Auto created invoices are dated 01-Jan-70 only exists on 1.33 and not -dev, I believe.

I'm continuing to do tests to make sure it puts items onto the invoices correctly.

I think I've finally finished it.
I've done most of the tests I can think of.
I've also added admin settings pages to control the default value for each node type.

Can someone review (if the code passes)?

I've had a read through and it all looks logical. I think we need to document the price modes better though now that there are more of them.

I haven't got time to apply the patch and do proper testing myself at the moment. Hopefully others will do.

To keep this moving though, I suggest that unless problems are found, this is committed to -dev, where it can be tested more fully by those who follow the -dev releases.

I'll add some documentation to the help section of the attributes module and put the same comments into the invoice module code.

I'm wondering whether to merge my 4 new price modes into 1 because they all basically do the same thing for the node it's attached to.

not applicable - This is ignored by the system. This means that no price mode is defined.
fixed - Price of 0 is used (so the invoice would need to be manually updated.
hourly - Price taken from node and multiplied by billing duration.
daily - Price given is for daily rate. This price is divided by 8 hours and then multiplied by the billing duration.
*fixed_timetracking - Will use the price given as the fixed price for that invoice item.
*fixed_project - Will use the price given as the fixed price for that invoice item.
*fixed_task - Will use the price given as the fixed price for that invoice item.
*fixed_ticket - Will use the price given as the fixed price for that invoice item.

* is a new mode.

Should I merge them into one called "fixed item price" or something like that?
Wouldn't take much effort to do it.

Just to clarify - what is the difference now between n/a and fixed?

I like the fixed_xxx names because from memory they tell you which entity the price is taken from. Assuming I've remembered correctly...

n/a - as before, it's ignored by the code. So if all nodes in a chain (organisation, project, task, ticket) have n/a then a warning is displayed that no price mode was set. It then still adds it to the invoice anyway with 0 price (as it did before with timetracking).
fixed - basically the same as n/a except no warning. This is how it works currently.

The issue I have is that you can put any fixed_xxx on any node type (i.e. you can have fixed_timetracking on an organisation).
Originally I was thinking of changing the way that "fixed" worked but it was decided to leave it and create new ones.
I now think we should merge them into 1 (maybe only 1 new one instead of 4).

To Unify / Keep Separate depends on what is related to the Invoice Item of the Invoice.
If the Time / Project / Task / etc. is linked to the Item, it "knows" where to get the value -> Can Merge into single Cost Type
Else has to stay separate.

I've tested the patch and it does work as it should - haven't found any bugs thus far. However, I agree that the Fixed XXX causes confusion and should be put into one, or made to replace the regular "Fixed" entry.

Not sure if this is invoicing etiquette, but can all these:
$description = t('project billed: @desc', array('@desc' => $node->title));
etc

be capitalized, as in "Project billed:", "Task billed", etc?

relating to comment #40, you might be interested in this issue:

#735694: timetracking records not taking fixed price from organisation, project or task.

I remember having discussions here before about "change fixed or create new price modes".
Because of the hierarchy, a price mode will affect lower node types.

i.e.
Organization has price mode "fixed_timetracking" with price 10.
All nodes under it that are added to an invoice (project, task, ticket or timetracking) will ALL use the price mode of the organization UNLESS it finds another price mode lower in the list.
So it a task has it's own price mode and you add it to an invoice (or a timetracking under that task) it will use the first price mode it finds (i.e. the task, in this case).

I would prefer to remove all the price modes I added and just use the "Fixed" price mode, to show that all nodes under it have the same fixed value when added to an invoice.

I'd like to commit this to -dev over the weekend (after changing #41) so it can be played with more and I can move onto other issues which are queueing for me (they sort of depend on this or could clash).

What do people think?

in response to comment #42 - How would "remove all the price modes I added and just use the "Fixed" price mode, to show that all nodes under it have the same fixed value when added to an invoice." affect those uses who currently use the Fixed mode as a 0?

This is a good point which was thought about. That's the reason why I went for new price modes. To be honest I never did see the point of having "fixed" as it currently is. It only adds an invoice item with zero price.

So just in case there are people using "fixed" I would then merge all my new ones into a new price mode "fixed_price" which will use the price given on the node as the invoice item price (which may have been the original intent of "fixed" but that was before my time. :)

I think there is was a difference between 'fixed', and 'fixed x' - because there needs to be a setting that simply says "use the price from this node".

However, with a 'fixed x' option for all types of nodes, this would be satisfied.

OK. I'm going to merge my new price modes into one new one called fixed_price.

I've merged them. I've also added code in the attribute module update so that all existing nodes using "fixed_timetracking" can be updated to "fixed_price" as it's all the same functionality.
Also to delete the price mode of fixed_timetracking afterwards.

The separate descriptions are still there but changed to work from the node type as well.

I think this is better.

Let me know.
I really want to get this issue done so I can move onto the others and because of the number of changes for this one I don't want to create problems.

Not tested so try again?

I see nothing wrong with this file. Any ideas?

It looks like the testbot has been upgraded to be more enthusiastic about checking syntax. The notices that are mentioned in the test exceptions will probably relate to #684016: Fix E_NOTICE notifications.

Unfortunately, we really should not commit to the branch until this is sorted, as otherwise the exceptions will probably stop testing until fixed. Therefore, we should for now, focus efforts in #684016: Fix E_NOTICE notifications, and continue to commit on other issues once that issue has seen a green patch and been committed.

#50: issue_567558_p_t_t_1attr.patch queued for re-testing.

Sorry tchurch, looks like it needs updating now the PHP notices are fixed.

@tchurch - a quick review from a readthrough (a lot easier now I'm back with dreditor!). Have not tested yet, but will try to do so soon - the below are only minor and do not affect functionality. Hopefully we can get this committed soon.

--- documentation/CHANGELOG.txt	28 Jul 2010 14:52:35 -0000	1.1.2.77
+++ documentation/CHANGELOG.txt	15 Aug 2010 19:07:46 -0000
@@ -4,6 +4,7 @@ Version 6.x-1.x-dev:
 - Feature #688086 by Francewhoa: Reformat 'Description' section.
 - Feature #814820 by Carsten Müller | tchurch: Add invoice icon on project page.
 - Bug #684016 by rfay | tchurch: Fix E_NOTICE notifications.
+- Feature #567558 by Magnity | tchurch: Extend auto-billing to other types of Storm node.

Any chance that we could standardise on putting new changelog items at the top? I don't know what the Drupal core method is - but I think it is a bit clearer for people chasing the -dev release.

+++ stormattribute/stormattribute.install	15 Aug 2010 19:07:46 -0000
@@ -15,7 +15,7 @@ function stormattribute_install() {
+    'fixed_price' => 'Fixed Price',    ¶

Trailing whitespace.

+++ stormattribute/stormattribute.module	15 Aug 2010 19:07:46 -0000
@@ -11,9 +11,29 @@ function stormattribute_help($path, $arg
+      $output .= '<p>'. t("The following price modes keys are defined:") .'<br />';
+      $output .= t("not applicable - This is ignored by the system. This means that no price mode is defined.") .'<br />';
+      $output .= t("fixed - Price of 0 is used (so the invoice would need to be manually updated.") .'<br />';
+      $output .= t("hourly - Price taken from node and multiplied by billing duration.") .'<br />';
+      $output .= t("daily - Price given is for daily rate. This price is divided by 8 hours and then multiplied by the billing duration.") .'<br />';
+      $output .= t("fixed_timetracking - Will use the price given as the fixed price for that invoice item.") .'<br />';
+      $output .= t("fixed_project - Will use the price given as the fixed price for that invoice item.") .'<br />';
+      $output .= t("fixed_task - Will use the price given as the fixed price for that invoice item.") .'<br />';
+      $output .= t("fixed_ticket - Will use the price given as the fixed price for that invoice item.") .'<br /> </p>';
+      $output .= '<p>'. t("") .'</p>';

Perhaps a < ul >? Also, why the last line?

+++ stormattribute/stormattribute.module	15 Aug 2010 19:07:46 -0000
@@ -11,9 +11,29 @@ function stormattribute_help($path, $arg
+/*
+    'fixed_timetracking' => 'Fixed Timetracking',
+    'fixed_project' => 'Fixed Project',
+    'fixed_task' => 'Fixed Task',
+    'fixed_ticket' => 'Fixed Ticket',
+*/

Is this still needed?

Powered by Dreditor.

Changed all of the above. Some of them were comments left over for me while developing.

#61: issue_567558_p_t_t_1attr.patch queued for re-testing.

+++ stormproject/stormproject.module	18 Aug 2010 19:52:42 -0000
@@ -528,6 +541,26 @@ function stormproject_form(&$node) {
+    '#default_value' => $node->billed,

Perhaps this needs an isset() ? ... : 0?

Powered by Dreditor.

Also - patch will probably not apply due to changelog changes now. Probably easiest if we edit the changelog manually as we'll never know exactly which order patches will be committed in until they go in.

Can someone try and test this ASAP so I can commit it before more changes are made. :)

I'd have to check again to make sure this wasn't caused by me checking a different patch on the same installation...

stormtask module
Update #6106
    * Failed: ALTER TABLE {stormtask} ADD `billable` INT DEFAULT 0
    * Failed: ALTER TABLE {stormtask} ADD `billed` INT DEFAULT 0

How have we left price modes? In the project form I can see Fixed as well as Fixed Project, Fixed Task and Fixed Timetracking.

Still testing... and will try not to commit anything for a while to avoid a reroll!

these columns are created as part of this issue.

The fixed project and task might be there from an old test of this issue. I had the same problem (as they're in the database and I didn't clean it).
Fixed timetracking should be removed with this issue with attribute update 6112.

Ok, have confirmed both of those were due to existing stuff on my installation.

A few more problems though
- Date for new invoice items goes to 1 jan 1970. Is this due to the previous issue - would you be able to remind me what to look for?
- Always NULL hours - "01 Jan 70: hours" (no number between date and hours).
- Storm ticket billable/billed fields have not been added to the CCK hook.
- I added a ticket with fixed price mode - and got a zero priced item. Expecting to see the value of the ticket.

Btw, I will pause committing once it hits CNR again.

I think the date problem might be because of #787822: Implement support for Date popup module on Ticket and Invoice Date Fields or due to #794638: Replace 0 with NULL for all date related fields..
I don't use Date PopUp (instead I use the drop-down lists from Storm) so I don't get a problem with invoice dates.

For NULL hours, this could be because the ticket has the price mode "hour" but the only node type that should use this price mode is timetracking (as it has start/end times).

About zero priced item, not sure. I have a ticket with fixed price mode (also with a price in the box) and it works OK.

CCK hook - not sure what you mean. If you mean having the fields available for views or in the filters (on the list page) then I still need to add this. I forgot to copy that code from the other modules. I will do that today and resubmit a patch.

CCK hook is stormticket_content_extra_fields($type_name) around 273 of stormticket.module.

Will check other things. Should I be expecting it to work recursively? (I.e. to bill for any unbilled timetrackings etc when billing for a project)?

I will look into the hook thing. Not sure if I used it for the other billable/billed flags or not.

It will only add the current node to the invoice (i.e. will add project but not anything else under it)/
This would make it a bit more complex, I think.

OK - the hook simply is an extra line to define the group. It is needed because otherwise when CCK is enabled the billable / billed fields drop down out of order.

Once this is committed we should create an issue for adding the recursive functionality so that there is a stub there for people to find if they want it.

Also, it occurred to me that we haven't documented the auto add functionality at all. This doesn't need to go into the patch necessarily (unless in the hook_help) but I wonder if you could think about a rough draft or perhaps edit the d.o. handbook pages? Storm is very lacking in documentation.

However, at this stage, I'd really like to get the patch in so probably best to handle this afterwards.

I found the hook. I had done it for the other node types but missed this one. I've also added these fields to the filter options too (which I forgot).

We should open a new issue/task for the documentation in the handbook (just to remind me to do it).

I'll finish the new patch tomorrow and upload it for testing again.

Follow up issues:
#889604: Document auto-billing functionality in handbook
#889606: Recursive auto-billing functionaiity.

I've committed the changes to the changelog apart from the entry for this issue. This is just a reroll without any changes to the changelog.

What is the difference between the price modes: "Fixed" and "Fixed Price"?

I think this was what was making me think it was going wrong before - I was using "Fixed" and getting a zero amount.

EDIT: To answer my own question... see comments #36 - #46 on this issue.

I've committed the changes in the stormattribute module. Attached is a reroll without those changes.

Apologies for doing this in stages - I find it much easier to review step by step for big patches.

Once this is fully committed I can start working on some other patches/bugs although I'll be looking over them now.

Yes, sorry, I got distracted from it. Will continue testing and committing today.

tchurch - what do you think of this change...?

With this patch, if hourly, daily, or fixed are used with a node type that is not timetracking, it will give the invoice item todays date (instead of 1st Jan 1970) and use the duration from the project/task/ticket.

Created followup: #890908: Clean up "Fixed" price mode attribute.

RE: #85, this makes sense. I do also notice a very small issue in my code for this in the storminvoice.module file.

for the function _storminvoice_insert_items, this entire change (adding src_nid and src_vid) could be removed. It's actually part of issue #738020: Link node record to invoice item (which I still need to work on). I must had forgotten to remove this code. I removed some of it but not all.
It doesn't seem to harm the invoice item DB creation so it's up to you.

I've taken those two lines out - actually that db_query didn't have enough arguments because the values weren't being passed in to substitute into the placeholder.

Here is the revised patch, which is RTBC from my point of view.

And here is one that removes the comma too. Should now pass.

Since that patch was green, I've committed #90.

Thanks for all your work on this tchurch.

I've been doing testing under #885002: Release of 6.x-1.34:
I find the following problems:

not working -
- add task, hourly price to existing OR new invoice: zero amount on invoice item.
- add ticket, hourly price to existing OR new invoice: zero amount on invoice item.
- add project, hourly price to existing OR new invoice: zero amount on invoice item.

It seems that it tries to use billing_duration for all when it's only available for timetracking.

I will submit a patch later today (I hope) for this small fix only (which will update the function storminvoice_get_item_amount) so that it will duration for the amount (as it does for the description, fixed in #85)

extra patch IN ADDITION to that already committed with this issue.

Have not applied patch, but RTBC from my readthrough.

Committed.