[ic] order number after payment, not before, fixed

[Dave Paton]

Quoting Dave Paton (dpwork at earthlink.net):
> Hi, I recently upgraded from IC 4.9.4 to 5.0.0 and run a catalog (made in
> 4.8.7) that uses the foundation-style order routes. I wanted to go back
> to assigning the number after charges succeed. In CVS is a version of
> Order.pm (v 2.6.2 of 12/27/03) that seems to enable this by adding the
> "counter_tid" route setting -- if told to it looks for
catroot/etc/transaction.number
> when processing an order, instead of order.number. I sent Order.pm 2.6.2
> up live, added counter_tid to my main route in catalog.cfg and put into
> etc/log_transaction the code to increment and assign the order number.
> After that the number sequence began increasing 2 for each order.

Hi group, I looked at this some more and am pretty sure I found the issue,
will detail it in case someone else should encounter it. In my 4.8.7
foundation-style catalog.cfg the payment route info was below the final
default order route (I think by default, don't recall moving it there),
and with the payment routes down there, setting counter_tid for use by
Order.pm (2.6.2) was not working. I saw that in a 5.0 catalog.cfg payment
routes were placed above the order routes, so that the default order route
comes last. When I edited my catalog.cfg to match this style, the order
number began to increment correctly, only when set to do so upon a
charge_succeed. In logs/log the begin and end counter now is called from
etc/transaction.number for good and bad order attempts alike. In the
transactions tables, e-mails and receipt pages, sucessful orders get the
incremented etc/order.number.