[freeside-devel]

[Dave Burgess]

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".   This allows us
to possibly extend the paradigm to include "EDI" transactions, assuming the X12
people get off their duff and get microcharges working.   I don't think I need to
change the definition of paybatchnum, but it will be important to not duplicate the
paybatchnum between three types of batches.  If you want, I can add a field called
'achbatchnum' to the definition, although I don't think it's needed.  Here are the
semantics for the batch  table using ACH that I'm thinking about:

batchtype        Batch Type Identifier
paybatchnum  Batch Number
cardnum           ABA and Routing number.  These items are simply concatenated
together, since the ABA Number is always nine digits (zero filled if necessary).
This leaves a 10 digit space for the routing number, which I think is always OK.
exp                    Not needed
amount            Amount
invnum            Invoice Number
custnum          Customer ID number
payname         Check Number range (if batch is for tele-check), blank for ACH.
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.

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

>
> > What else has he done? you might ask....
> >
> > - I added some /&nbsp; entries to some of the cust_main.cgi entries
> > so that the table would look like a table on the printer.  On the
> > screen, it doesn't matter much, but it looks odd to have the
> > separators disappear when you are looking at a table.
> >
> > - I also added some of these to the table builder in search/cust_main.cgi.
>
> Unsure if I want these but I'd like to see the changes.
>

Sure.  I'll pack them up and send them to the list.  Basically, I just added a few
"&nbsp;" entries before the "</TD>" tags.   In my origianl attempt at this, I used
"&nbsp;" for the Company Name on any entry where the field was NULL.  I didn't like
that, since it left little clickable screen turds that didn't do anything for me.
This new way allows the boxes to be completely empty.  Other browsers handle this
for you, but Netscape (which is what I prefer) doesn't.

>
> > - I changed the default dates on the 'new customer' screen.  The system now
> > uses the current date from the server and sets the various entries to
> > 'reasonable' values.  The Credit Card entry starts out 12 months from now
> > (it's halfway through a 2 year period and will be right about 4% of the time).
>
> No.   Credit card expiration date should start out with no date selected.

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

>
>
> > The Complimentary entry expires in 1 year; the Bill and ACH entries expire
> > in 2037.
>
> That's fine.

We had already agreed on this.

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

>
> sorry, but until your changes are high-quality enough i don't have to
> audit them and you can check them into CVS directly, if you want your
> changes integrated, please send them as separate patches that do one
> thing.

"Until your changes are high-quality enough...."?  Thanks.  I noticed that I'm about
the only person here that's giving you patches through the mailing list.  In fact,
with the exception of a couple of people, you and I seem to be the only people
participating in the list....

I will split the changes up as best I can.  I've been trying to split them into
groups of specific funtionality but some of this stuff kind of defies that.  The
view/svc_www.cgi patch, for example, is just one of the 4(?) pieces that need to be
defined, and it's only about half of what needs to be there.  Basically, I'm trying
to satisfy three masters here.  You are certainly one, our accountant is another,
and our book-keeper is a third.  Each change I make gets approved by both of them
and has to meet at least three criteria before I can send it to you:

1)  It can't break the system in an unexpected way.
2)  I has to implement something that the people that deal with money want.  This is
why I'm trying to get ACH working.
3)  It has to be reasonable.  I'm not going to do something pathological just
because someone asks.

Dave