[freeside-devel]

[ivan]

On Sun, Dec 23, 2001 at 05:04:04PM -0600, Dave Burgess wrote:
> > On Mon, Dec 17, 2001 at 04:25:25PM -0600, Dave Burgess wrote:
> > > ivan wrote:
> > > 
> > > > Add a destination field to the existing cust_pay_batch table, as well as a
> > > > batch number.
> > > >
> > > 
> > > Good.  I'll get started down that path.   My first thought, then, is to
> > > add a field called "batchtype" and have it hold on of "ACH", "CARD", or
> > > "CHEK".
> > 
> > Just use "ACH" "CARD" and "CHECK".
> 
> I just double checked, and the 'payby' field in cust_main is only 4 
> characters.  I thought it would be a good thing to keep the payby indicator
> and the batchtype indicator the same, or at least in the same set.

Just because I was silly about cust_main.payby years and years in
ago is no reason to propogate that sort of fixed-width silliness.

> Based on that, do you prefer "CHEK" or "CHCK"?

I prefer "CHECK", but I don't care very much.  Whatever you like is
fine.
 
> > >  If you want, I can add a field called 'achbatchnum' to the definition,
> > 
> > Yes.  Just "batchnum".  Toghter the "batchtype" and the "batchnum" define
> > a batch. 
> > 
> > > although I don't think it's needed.
> > 
> > It is.
> 
> OK.  I can do that.  Right now, I'm leaning toward making batchnum
> 'date related'.

No, just make it an int.  If you like, you can add another table with
batchnum as the primary key, a date field, and whatever other data you
like (information about the batch transmission or whatnot). 

>  It's going to end up as part of the output filename
> so that the Book-keeper can download it and import it directly into
> the ACH program we use.
> 
> > Change the [cardnum] field name [in cust_pay_batch] to payinfo.
> 
> Isn't that going to hose up everything you've written so far that
> will talk to this table?

There isn't much.

>  It's a rhetorical question, Of course.
> While it might mess up a bunch of code, the argument could be made
> that this was a violation of identifier integrity and should have
> been called "payinfo" all along.
> 
> I'll alter the table, but are you going to modify the stuff that
> uses cardnum now?   Or do you want me to do that?  Just let me
> know.

I certainly wouldn't refuse, if you're offering to make the necessary
changes.  I think only FS/FS/cust_main.pm (the collect method),
httemplate/browse/cust_pay_batch.cgi and httemplate/docs/billing.html need
to be modified.

> > No.  Don't use the payname field [in cust_pay_batch] for this,
> > and store it in the cust_main table, not the cust_pay_batch table.
> 
> Of course.  I was a little unclear on the purpose of some of the
> fields in the cust_pay_batch table - the check number range part
> would be stored in the cust_main table.  The payname field will be
> needed to hold the name from the bill_last/bill_first fields in
> the batch going to the bank for ACH.

No, use the cust_main.payname to hold the "exact name on the
check" for payby ACH - just like you use the cust_main.payname field for
the "exact name on the card" for payby CARD.

> > > Currently, I plan to use <start>:<stop> for the range.  If there is no ":", the
> > > number is assumed to be a one-time number and is cleared after use.  Note that I'm
> > > not actually going to use this piece for a long time, so it may end up just stubbed
> > > out for now.
> > > 
> > > The rest of the fields are used as before.  Most of them aren't actually used in the
> > > ACH batch, but could be important in other locations and situations.  There
> > > shouldn't be an impact on the current system, except for the change to check for
> > > 'CARD' on the card batch SELECT.
> > > 
> 
> Who do you want to handle the 'CARD' identifier change? me?

Sure :)

> > I wouldn't even try to "keep up" with your tree.  If you want to continue
> > to leverage the future work of myself and other Freeside contributors, it
> > is in your best interest to contribute your changes back to the project
> > and thus minimize the differences (and thus maintenance overhead) between
> > the official tree and your tree.
> 
> I totally agree.  At this point, I get about 10 hours a week to work on
> code changes for the system.  This week-end, for example, I've had a bunch
> of other stuff to do (hosing up customers' routers has been the bulk of
> it) so I haven't had much time to do anything else.
> 
> The biggest problem I'm having is trying to keep the 'diffs' aligned
> with your code, while still moving forward on mine.

I did something very similar at MAPS - we forked and froze a copy of RT2
<http://www.fsck.com/projects/rt/> while it was still in development.  The
two things I suggest to you are: use CVS yourself, periodically importing
a "vendor branch", and find a graphical diff/merge tool you like.  I like
xxdiff.  But most importantly: use CVS yourself.

> I've got about
> 5 different sets of diffs (logically) in view/cust_main.cgi alone
> (for example) and it's hard to separate them from one another when
> the 'orig' file for the diffs is the one from pre6.  The set, right
> now, applies directly to pre6, but as soon as I start segregating
> them, the line numbers start to skew, and it gets worse as the
> patchsets move forward.  I can't think of a way that keeps the
> changes flowing to you in some kind of reasonable way that isn't
> going to force you patch the files by hand imperpetuity.

Did I mention you should be using CVS?  If you use CVS and keep your
changes logically separate, you'll have a much easier time sending them
upstream than if you just have a source tree.

> > Everyone who has CVS commit access started out by sending patches. 
> > Nothing personal.
> 
> OK.  Sorry.  I took it personally.  I interpretted that as 'your
> code is pretty crappy, but someday it might be OK.'

I'm not talking about code quality (nothing could be as bad as the mess
I've made of httemplate/) - I'm talking about spending the extra time to
make the code suitable for everyone, not just yourself.

Things like:  adding a configuration option for that new feature you're
using but not everyone will want.  Asking the list before you make major
changes.  Making sure your changes don't break other things, even if
you're not using them (see your CARD note above, for example).  Providing
a documented upgrade path from the last stable version for incompatible
changes (in contrast to your wholesale removal of svc_acct_sm).  You get
the idea. 

> You talk about other contributors, but I don't see them.

Just because there isn't a lot of list traffic doesn't mean there aren't
contributors.

For example, two of the most significant changes in 1.4.0 - the improved
svc_forward mail alias handling (replacing svc_acct_sm) and the more
robust - were mostly the work Jeff Finucane.

> - How would I set up a service that varies?  Example:  Suppose we
> charge for Majordomo mailing lists at the rate of 1 for $10, 2 for
> $15, 3 for $17.50, 4 for $18.75, 5 for $20.00, 6 for $21.00, 7 for
> $22.00, etc.?  Right now, I need to set up 6 packages, each one
> with a different price.  What about bandwidth charges for a Web
> Site?  I have the services setup now for this, but I can't figure
> out a way to make them work.

All prices are Perl expressions.  Use a single service, and write a Perl
expression that returns the appropriate price for the number of Majordomo
lists.  This works the same for hourly billing, or billing by mb, or
whatever you like.

-- 
_ivan