I’m doing some work on credit card processing right now. This is all related to my company’s upgrade from Dynamics AX 2012 RTM to 2012 R3. There were major changes to the credit card processing code in R2, and we’ve customized the code from RTM quite a bit, so there’s a lot to do. I’d like to write more about it, but it probably wouldn’t be of any general interest, plus I don’t want to get into any company-specific stuff.
But one very minor thing came up yesterday that was a little bit interesting. I noticed a support ticket from a user who was entering a new card, and wanted to enter an expiration date that wasn’t shown in the drop-down. (It was too far in the future.) This didn’t have anything to do with the upgrade, per se, but it made me curious enough to look at the code in RTM and in R3, to see what was being done. I was curious if maybe we had something in there like this example from The Daily WTF, or something where the upper-limit on the year was hard-coded to a specific year.
Well, it’s not quite that bad, but it is a bit questionable. In RTM, there’s a drop-down that is populated with years from (current year) to (current year + 7). In R3, it’s pretty similar, except that, when editing the expiration date after initial entry, you can go to current year + 8. (That’s probably an off-by-one error, rather than an intentional extension of the range.)
This all made me wonder what a reasonable upper-bound for expiration year would be, which lead me to this Stack Overflow question, which seems to indicate that there’s no agreed-upon maximum, but that it’s probably safe to go with 15-20 years. So Dynamics AX could stand to be be a bit more flexible on that range.
The other thing that bothers me about the way AX handles expiration dates is that (in 2012 RTM) they’re stored in the database as “MMYY”, which makes it difficult to sort and filter out expired cards. I was hoping that would be corrected in R3, but they’ve only changed it to “MM/YYYY” (without any leading zeroes on the month), which has the advantage of being more easily-readable by a human, and also of storing the full 4-digit year, but the disadvantage of being even more difficult to sort on, since the year sometimes starts in the 3rd position and sometimes in the 4th.
And let me end this blog post with a link to my very favorite publicly-documented method in AX, related to credit card processing: CreditCardWizard.codeCoverageFudge. I’m not entirely sure why this method exists in the released product, but I’m guessing it was added to fudge the code coverage numbers in some unit testing metrics. Maybe a certain percentage of code coverage had to be achieved, but there was no easy way to write meaningful tests for the remaining uncovered code, so they just wrote a method that does nothing, and a unit test for it?