[freeside-devel]

[ivan]

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

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

Yes.  Don't.

> but it will be important to not duplicate the paybatchnum between three
> types of batches.

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

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

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

Change the field name to payinfo.

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

No.  Don't use the payname field for this, and store it in the cust_main
table, not the cust_pay_batch table.

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

track_ss

> > > - 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 may need to be modified, but it certainly doesn't need to be rewritten.

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

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

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

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

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

Everyone who has CVS commit access started out by sending patches. 
Nothing personal.

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

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

-- 
_ivan