On Sat, 27 Feb 2010, Chris Travers wrote:
On Sat, Feb 27, 2010 at 3:22 PM, Luke <..hidden..> wrote:On Sat, 27 Feb 2010, Chris Travers wrote:On Sat, Feb 27, 2010 at 2:53 PM, Luke <..hidden..> wrote:Departments newbie here... What is the intended behavior when orders with different departments set, are consolidated?We need to rethink this more carefully for 1.4. Feedback would be welcome.The only thing I can think of, is causing departments to be associated with line items alo projects.Yep. that's probably what we will have to do.Force grouping by department, and reset running numbers within a departmental section of an order or invoice.Unfortunately that is a very deep change and quite frankly isn't going to happen before 1.4. In the mean time, best answer is to send out
Figured as much, but I want it on the table at least. This isn't something that effects me more than a few times per year in the way I'm doing things now, and I'll just have to deal...
I assume you're keeping a requested changes list for 1.4. As for runningnumbers having to reset: I was talking about templates only.I have thoughts on how to do that, but I'd have to know more about how templates are processed in order to see if they make sense.
[ramble]The first is that if sorting by department, the code would have to take the current runningnumber at the start of a department block, and, visible to the template only, do a reset of it to 1.
for (runningnumber = 1; runningnumber <= count(lineitems); runningnumber++)
{
if lineitem->department != remembered_department then newdept = true else
newdept = false;
if newdept then displaynumber = 0 and indept = true; if indept then displaynumber++; output displaynumber as runningnumber; }yada, yada. Assumes pre-sorting into departments, no non-departmented items, and about 10 other things, so probably crap, but it's where my mind went first.
[/ramble] Luke