[freeside-devel]

Dave Burgess burgess at www.cynjut.net
Sun Dec 23 15:04:15 PST 2001


> On Mon, Dec 17, 2001 at 04:25:25PM -0600, Dave Burgess wrote:
> > ivan wrote:
> > 
> > > On Sat, Dec 15, 2001 at 05:17:57PM -0600, Dave Burgess wrote:
> > > > I need to decide if I want to start up my own database table (with
> > > > a structure almost identical to the cust_pay_batch table) or if I
> > > > should add a destination/flavor flag to the existing cust_pay_batch
> > > > table.
> > >
> > > 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.  Based
on that, do you prefer "CHEK" or "CHCK"?

> 
> > This allows us to possibly extend the paradigm to include "EDI"
> > transactions, assuming the X12 people get off their duff and get

[elided]

> paybatchnum is the primary key for the cust_pay_batch table.  it's unique
> for every record.
> 

D'oh.

Never mind.

> >  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'.  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?  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.

> 
> 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.  I'm not sure (since I don't
actually have a need for tele-check) where to put the check number
in the batch table.  For that matter, I'm not convinced that we
would actually produce a batch for 'tele-check', since those could
be real-time transactions.

I'm going to mull on that some more.  ACH is important to me,
tele-check isn't.  Of course, that's no reason to gratuitously
break tele-check.  I just want to do this so that it doesn't hurt
too bad when it comes time to implement tele-check, or whatever
comes after.

> 
> > 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?  I
assume so, since it's really a necessary change to make the ACH
stuff work.  Be warned - we don't use 'CARD' here, so someone is
going to have to check it out before it goes into the codebase.

> > >
> > > > Also, on the SSAN front: I added a little bit of code to the cust_main.pm
> > > > file to allow SSAN to be entered in the system unless there is a
> > > > 'user_nossan' flag in the conf directory.  The display suppresses it either
> > > > way right now.  The reason I went to the trouble is that the Bank suggests
> > > > using the SSAN as the customer identifier.  While that's dicey for the ISP,
> > > > it's OK for the bank (financial transactions are tracked by SSAN) when ACH
> > > > is involved.  Besides, I wanted to keep a way for people to use SSAN if they
> > > > needed to.
> > >
> > > Okay.  I'm fine with making the default be no SS# tracking, and having a
> > > configuration value to turn it on.
> > >
> > 
> > The logic for this is fairly simple, so I can change the name on the
> > conf. file entry to something else.  I wasn't really sure about the
> > 'user_nossan' flag file; can anyone suggest a different name to show
> > that we 'do' want to track SSAN?  I was thinking "track_cust_ssan",
> > "use_ssan", or something....
> 
> track_ss
> 

I have changed the code to use 'track_ss', including the 'Conf.pm'
entry and the /*/cust_main.cgi tables.  If the 'track_ss' conf file
does not exist, no SSANs will be captured on the data screens.
The field is still in the DB, however, so that people that waffle
back and forth will have the field to work with.  It might also end
up being important for some ACH implementations.

> > 
> > I would agree except for one thing.  The way you have implemented in
> > "edit/cust_main.cgi sub expselect()", there is no way to do this without a 
> > rewrite of that function.
> 
> It may need to be modified, but it certainly doesn't need to be rewritten.

It isn't very big, but the way it works right now, a blank date would cause
an exception, so the selector code and the error code will both need to be
modified.  I think that leaves one or two lines in the middle that don't get
touched. ;-)

> 
> >  It starts out now with Jan 2001 selected, which is just as
> > arbitrary as 1 year from today.  Until I get to the point where rewriting the
> > expselect function is important to me, I am comfortable with the change.
> 
> I'm not.  Credit card expiration date should start out with no date
> selected.
> 

I see that you are set on that :-)

> >  If you
> > want it left defaulting to Jan 2001, that's fine.  Either way, we end
> > up with a nearly bogus date in the field unless something else changes.
> 
> Jan 2001 is preferable to "1 year from today".  As I said, no date
> selected is ideal. 

Sure, and I think we are in violent agreement on the ideal behavior.

The current behaviors (the subotimal you prefer versus the suboptimal
I prefer) are the only debate point.  Since you seem to have a
stronger opinion than I do, leaving it at Jan 2001 is fine for now.
I'll back the code out of the patch I'm sending you.

An important note on this kind of stuff:  I just work here.  Donna
reminds me of a Tazmanian Devil with a bat when it comes to stuff
like this.  I do what she says, and she didn't like Jan 2001.  I
don't use the system, I'm just the CTO.  I'll let her know, and
remind her that I need my fingers :-)

> 
> > > > Well, that's enough for the 6 hours I spent tonight.  I'm having trouble
> > > > keeping the patches segreagated, especially when I work on three or four
> > > > trouble tickets from the book keeper and receptionist.  I hope you can
> > > > forgive me for lumping a lot of these patch sets together.
> > >
> > > no problem.  i hope you can forgive me for sending them to /dev/null.
> > >
> > 
> > Sure.  It's your system.  I can make these changes totally private if
> > you prefer.
> 
> That's certainly your option if you like, within the constraints of the
> software license.  I'd prefer you contributed back to the project, of
> course, 

I'd prefer to contribute back to the project as well.  See below.

> 
> > It's no skin off my nose one way or the other.  What I was
> > actually referring to is that I can get a lot of code written and
> > tested in a relatively short piece of time.  Since I have no way of
> > knowing which patches you are going to pick up and which you are going
> > to toss, I have to work from some kind of starting point.
> > Whether you pick up the changes or not doesn't really matter to me at
> > this point, but as our source trees get further and further out of
> > sync, it is going to get harder and harder on you to keep up.
> 
> 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'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.

> 
> 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've been
writing code for about 30 years, and it's one of the few places
where I'm a little thin skinned.  You can insult just about anything
else in my life and I won't mind much.  I take my code personally -
I'm an Uber-geek.

You talk about other contributors, but I don't see them.  From
here, it looks like you and me, and that worries me.  I don't know
about your schedule, but I can't help you keep the project moving
like I could 30 years ago when I was in college.  I've heard from
one guy that said he had some changes, but I haven't seen anything.
Of course, I've only been hanging on every word of every message
here for the past three months.  Unless there's some super-secret
'real developers' list out there somewhere, I would just expect a
little more interchange on the list.

For example, when I ask a question, I have come to expect an answer
from someone other than the person we rely on to manage the project.
Even groups as 'interesting' as the original 386BSD group was likely
to answer. You can't be the only person that reads this list that
speaks English....

For example:

I asked the developer's list if anyone has written a widget that
can help me import about 1800 user records, services, packages,
and billing records from an OptiGold database that we will be
getting when we consumate the purchase of the ISP we are buying.
We've got our old users pretty well squared away and would like to
do the same thing with the new customers.  

The reason I asked the other developers is because they (rather
than the users-list) are a lot more likely to know what I'm talking
about.  Of course, I could just send the list to Ivan and pay him
to do it, but why wouldn't we want to share the art amongst the
developers?  On the other hand, a message to the effect "We let Ivan
do that so he can collect his beer money!" would have been just as
OK.  Instead, I got a stunned silence.

> 
> Your view/svc_www.cgi has already been checked in.

I know.  I appreciate that.  I have made precisely no new progress
on extending that set of changes.  I have a work-around that keeps
the book-keeper happy, so there's no pressure.  She needed to be
able to click on the view screen from the big customer list and
get the info back.  I also modified view/cust_main.cgi to do
basically the same thing as view/svc_www.cgi so that the information
showed up on the big customer summary.

Let me reiterate something that I said earlier.  I think this system
has a *LOT* of potential.  There are lots of things that still need
to be done to get it up to where my accountant would be happy, but
it's a lot closer than the POS that we hacked together 4 years ago
when this company was still small.  The one reason we chose it over 
OptiGold was that there seemed to be an active development community.

If the problem is that no one has any projects to work on, drop me a
line - I've got plenty.  Here's a sample of the things I'm going to
be working on over the next year:

- What happens if a person wants to pay for some of their packages
with a Credit Card every month, but wants to write a check for
things that vary?  Two credit cards, one for the dial-ups and one
for DSL? Use your imagination....

- 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.

- We've discussed svc_wo and svc_charge in the list before.  
  --  Ivan indicated that there is a way to do the svc_charge part
without a table dedicated to that.  Write an interface that does
that.  
  --  The svc_wo stuff seems pretty straightforward - I just don't
have time to write it.  As soon as it's there, my web development
people can start tracking their time directly to the system, instead
of having to merge this information with the old, crappy system.

- Generally Accepted Accounting Practice (GAAP) says that when a
customer has more than one outstanding invoice, any payments received
will be applied to the oldest invoice first, and the remainder of
the payment will then be applied to each subsequent invoice.  We
can get into the reasons in private E-Mail if anyone would like.
The current payment processing system doesn't do this.  It actually
forces the accountant to hand process each invoice.  Extend the
current /edit/cust_pay.cgi?custnum={n} routine so that it automatically
applies the payment entered against any open invoices and then
leaves the unapplied credit in the field (as it does now).  The
routine /edit/cust_bill_pay.cgi?{n} needs to be written yet, but
that should have an 'Apply Automatically' button.

- Extend the 'invoicing' code so that it looks for unapplied credits
and applies them to the new invoice (this might already work, I
haven't even checked).  This way, pre-paid accounts (which we
regularly get) will work correctly.  Every once in a while, we'll
get a customer that drops $50 on us for $15 a month dial-up.  From
what I've seen, we would go in and change his 'next bill' date to
100 days from now - that's suboptimal.  It changes our billing
period from monthly to daily: something I am reticent to do.

- Write a report for your accountant that shows your income for
the year.  This one gets interesting depending on whether you using
cash-basis or accrual-basis accounting.

- Heck, write a report for anything and start a new section on the
default index.html.  

If there really are developers out there, someone else will stand
up and say 'Yeah, me too - I can test that for you when you get
done' as a minimum.

Expect several big blocks of code changes in the near future.  I'm
still trying to split them up so that they are logically grouped.
You'll probably see the first of them tomorrow while the rest of
my family is racing around with last-minute shopping.

Dave




More information about the freeside-devel mailing list