[ic] Inconsistent order numbers - SOLVED - Yep, it is

Kevin Old interchange-users@icdevgroup.org
Wed Apr 9 17:31:00 2003


On Tue, 2003-04-08 at 17:26, Kevin Old wrote:
> On Tue, 2003-04-08 at 13:08, Dan Browning wrote:
> > At 09:14 AM 4/8/2003 -0400, you wrote:
> > >On Mon, 2003-04-07 at 22:04, Kevin Old wrote:
> > > > On Mon, 2003-04-07 at 17:45, Dan Browning wrote:
> > > > > At 05:06 PM 4/7/2003 -0400, you wrote:
> > > > > >Hello everyone,
> > > > > >
> > > > > >I am using the iTransact module in 4.9.7 and setting the following in
> > > > > >iTransact.pm
> > > > > >
> > > > > >my $company = $opt->{company} || "$::Variable->{COMPANY} Order
> > > > > >$opt->{order_id}";
> > > > > >         $Session->{mv_order_number} = $opt->{order_id};
> > > > > >
> > > > > >so that my order numbers in IC will match the ID that iTransact uses.
> > > > > >This was all working in 4.9.6 without any problems.  I have not changed
> > > > > >any routes or code.
> > > > > >
> > > > > >The 2 emails that are sent from IC have the iTransact order_id in the
> > > > > >mv_order_number field.  However the receipt.html page (calling for
> > > > > >[value mv_order_number] ) and everything printed in the
> > > > > >catalogdirectory/logs/log file and everything in the database is the
> > > > > >TEST000* number.
> > > > > >
> > > > > >I have already checked and turned off test mode.
> > > > > >
> > > > > >Can someone please shed some light on any changes made from 4.9.6 to
> > > > > >4.9.7 that would cause this?
> > > > > >
> > > > > >Thanks,
> > > > > >Kevin
> > > > >
> > > > > What version of 4.9.7?  If you are using CVS, a date would be handy 
> > > (like
> > > > > "03-04", etc.).  A change that Mike recently made in CVS was the 
> > > following
> > > > > (on Mar 29)...
> > > > >
> > > > > User:      heins
> > > > > Date:      2003-03-29 22:11:08 GMT
> > > > > Modified:  lib/Vend Order.pm
> > > > > Log:
> > > > > * Allow $Session->{mv_order_number} to be set anywhere.
> > > > >
> > > > > Revision  Changes    Path
> > > > > 2.47      +8 -2      interchange/lib/Vend/Order.pm
> > > > >
> > > > >
> > > > > rev 2.47, prev_rev 2.46
> > > > > Index: Order.pm
> > > > > ===================================================================
> > > > > RCS file: /var/cvs/interchange/lib/Vend/Order.pm,v
> > > > > retrieving revision 2.46
> > > > > retrieving revision 2.47
> > > > > diff -u -r2.46 -r2.47
> > > > > --- Order.pm    29 Mar 2003 20:19:20 -0000      2.46
> > > > > +++ Order.pm    29 Mar 2003 22:11:08 -0000      2.47
> > > > > @@ -1,6 +1,6 @@
> > > > >   # Vend::Order - Interchange order routing routines
> > > > >   #
> > > > > -# $Id: Order.pm,v 2.46 2003/03/29 20:19:20 mheins Exp $
> > > > > +# $Id: Order.pm,v 2.47 2003/03/29 22:11:08 mheins Exp $
> > > > >   #
> > > > >   # Copyright (C) 1996-2001 Red Hat, Inc. <interchange@redhat.com>
> > > > >   #
> > > > > @@ -28,7 +28,7 @@
> > > > >   package Vend::Order;
> > > > >   require Exporter;
> > > > >
> > > > > -$VERSION = substr(q$Revision: 2.46 $, 10);
> > > > > +$VERSION = substr(q$Revision: 2.47 $, 10);
> > > > >
> > > > >   @ISA = qw(Exporter);
> > > > >
> > > > > @@ -1581,6 +1581,12 @@
> > > > >                                  $shelf->{$_} = [ @$cart ];
> > > > >                                  push @main, $_;
> > > > >                          }
> > > > > +               }
> > > > > +
> > > > > +               if($Vend::Session->{mv_order_number}) {
> > > > > +                       $value_save->{mv_order_number} =
> > > > > +                               $::Values->{mv_order_number} =
> > > > > 
> > > +                                       $Vend::Session->{mv_order_number};
> > > > >                  }
> > > > >
> > > > >                  $Vend::Interpolate::Values = $::Values = { 
> > > %$value_save };
> > > > >
> > > >
> > > > Dan,
> > > >
> > > > Yes, I'm aware of those changes.  This is very weird though.  All of the
> > > > emails that have the mv_order_number in them are correct.  But the order
> > > > creation and receipt page show whatever the next number is in
> > > > order.number.
> > > >
> > > > I'll try to get the previous version of Order.pm and see if the problem
> > > > still happens.
> > > >
> > > > Is there a better place for me to set the order number so that I get the
> > > > order-id returned from iTransact?
> > > >
> > > > Any help is appreciated.
> > > >
> > > > Thanks,
> > > > Kevin
> > >
> > >Dan,
> > >
> > >Well, I was aware of those change and went and checked the version of
> > >the file in the CVS source directory I downloaded and it was 2.47 - the
> > >version Mike added the code so that mv_order_number could be set
> > >anywhere.  I got to thinking about it and just wanted to make sure I had
> > >the right version and I went to /usr/lib/interchange/lib/Vend and looked
> > >at the version of Order.pm in there and it was 2.45.  I copied the newer
> > >version over the old one and it works like a charm.  But, that doesn't
> > >explain why 2.45 was installed.  This was a fresh installation from the
> > >CVS source.
> > >
> > >Any ideas?
> > >
> > >
> > >Thanks,
> > >Kevin
> > 
> > Well, this is obviously the result of a stray gamma particle during your 
> > installation.  Remember to shield your computer with aluminum next time.
> > 
> 
> Dan,
> 
> I got Order.pm version 2.47.
> 
> I'm still having trouble with everything that happens inside
> log_transaction.  References to mv_order_number print the TEST000*
> number.  I tried substituting [data session payment_id] for it, but the
> order never completed....Here's what was in the icdebug file
> 
> -> execute for DBD::mysql::st (DBI::st=HASH(0x99627f0)~0x99661f4)
>     -> dbd_st_execute for 08bc8bf0
>       Binding parameters: INSERT INTO transactions VALUES
> ('03040820153622173', '', NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'order_number:
> 03040820153622173\nsession: H76rzwYn\nusername: kold\nshipmode: GNDRES
> (UPS Ground Residential)\nshipping: 4.63\nnitems: 1\nsubtotal:
> 6.99\nhandling: 0.00\nsalestax: 0.00\ntotal_cost: 11.62\nfname:
> QwErTy\nlname: Old\ncompany: \naddress1: 13303 Krislyn Woods
> Place\naddress2: \ncity: Charlotte\nstate: NC\nzip: 28278\ncountry:
> US\nemail: kevin.old@uavco.com\nphone_day: 7046506978\nphone_night:
> \nb_company: \nb_fname: \nb_lname: \nb_address1: \nb_address2: \nb_city:
> \nb_state: \nb_zip: \nb_country: \nb_phone: \npayment_method: Real-time
> Credit Card (mc -- itransact)\npayment_mode: itransact\norder_id:
> 03040820153622173\nauth_code: \ntracking_number:\norder_date: 20030408
> 16:15:40\norder_ymd: 20030408\norder_wday: 2\nstatus: pending\ndeleted:
> 0\narchived: 0\ncomplete: 0\ncomments: \naffiliate: \ncampaign:
> \nparent: \npo_number:')
> Column 'order_number' cannot be null error 1048 recorded: Column
> 'order_number' cannot be null
> <- dbd_st_execute -2 rows
>     !! ERROR: 1048 'Column 'order_number' cannot be null'
>     <- execute= undef at DBI.pm line 1364 via (eval 591) line 13
> 
> 03040820153622173 above is the transaction id returned from iTransact.
> 
> This looks like some kind of trouble with binding the data to the
> transaction.  
> 
> I've already adjusted the appropriate columns to handle the long
> order_number in the transactions and orderline tables.
> 
> Also, I noticed that Mike made changes to Data.pm, Glimpse.pm, Page.pm,
> Scan.pm, TextSearch.pm and Util.pm around the time he updated
> Order.pm.....should any of this effect this problem?
> 
> Where should I be setting mv_order_number if I want the payment_id
> returned from iTransact to be printed in every call to [value
> mv_order_number]?
> 
> Any [more] ideas?
> 
> Thanks,
> Kevin

Ok, well, I think it was something with different versions of modules. 
I got a fresh version of everything on CVS, refreshed my install and
everything worked just fine.  Except in the log_transaction file I had
to change [value mv_order_number] to [data session payment_id].

Any idea what's causing this?  In 4.9.6 I didn't have to change anything
in log_transaction.

Thanks,
Kevin


-- 
Kevin Old <kold@carolina.rr.com>