• Dvon Edzore (unregistered)

    Or it was programmed by someone who expected the change request "It's too slow now! Make it faster!" Whereupon our Hero strives mightily through many nights (or so the invoice states) and delivers an affordable solution to their urgent problem. Unsaid, naturally, is that our Hero leaves enough of the sloppy code in place to permit repeating the trick another time or two.

  • my name (unregistered)

    Something still isn't right. Usually there is an Excel-Interop to generate an Excel-file which is then sent

  • TheCPUWizard (unregistered)

    "Yes, core financial business functions being handled over email." -- e-mail is not secure, yo have to FAX it.. [and yes, this is actually true for many medical and other official records]

  • Hanzito (unregistered)

    A memory hog? Someone writes in Python and is worried about memory? I expect more WTFs.

  • ttlanhil (unregistered) in reply to my name

    That'll be done from the access database once the CXO's secretary copies from the email

  • Sauron (unregistered)

    Is it just my imagination, or banks are among the craziest companies when it comes to software development?

  • Mr. Picky (unregistered)

    I wonder what happens inside to_dec when the transaction amount is less than $1.00.

  • Noadle (unregistered) in reply to Sauron

    It's not your imagination.

    Remember, these are not software companies, and as far as they are concerned "if it works adequately, don't touch it".

    Many financial orgs run on a collection of Excel spreadsheets, not because it's the best tool for the job, but because it's a tool they have already bought and almost anybody can make it do something approximating the required output without resorting to Agile, Java or Cloud Service Providers.

    In a very real sense these organisations are laser focused on the short-term P&L sheet, and no-one wants to be responsible for a P&L drop (even a short one) when they can hide the higher long-term costs in the business noise.

  • Vera (unregistered) in reply to Sauron

    Tons of regulations plus tons of money involved plus managers who stay as long as they aren't implicated in some major scandal adds up to a culture of anxious coding.

  • Kevin (unregistered)

    Perhaps the lstrip of 0's was there to prevent something accidentally getting interpreted as octal, even though it is explicit about Decimal. Anyway, at a glance I fear this would have some "fun" issues with any transaction less than 10 cents.

  • (nodebb) in reply to Sauron

    Insurance companies can be even worse, having worked for a healthcare company owned by two large insurers.

  • Tim (unregistered)

    no WTFs here - move along please

    I'm not saying it's perfect but it's clearly fit for purpose and is not especially obfuscated. Honestly looping through an array 3 times instead of just once isn't going to create much of a performance penalty since the data set is small enough to hold in memory

  • Duston (unregistered)

    "the data set is small enough to hold in memory" -- for now.

  • (nodebb)

    "skip the first two and last two lines in the file (headers and footers, I assume?)."

    Looks like they are reading an ACH file. If it only has one batch, they are skipping line 1, the file header, line 1, the batch header, line n-1, the batch trailer, and line n, the file trailer. If it has multiple batches, their numbers are incorrect unless that code (I refuse to look at python hard enough to tell) is skipping certain lines depending on the first character.

    Funny thing is, unless the ACH format has changed recently (really unlikely IME), they can pull the values they want straight off the batch or file trailer, which summarize the number of transactions and dollar value already.

  • ZZartin (unregistered)

    "The bank has requested that we send them an email containing the total of all the transactions…"

    Yes, core financial business functions being handled over email

    Umm... yes it's a very common thing to send an email confirmation with some basic information about the file, not sure why that would be a problem.

  • KAH (unregistered) in reply to Bim Zively

    Oh no no no. I have more than once had business requirements approved to development to do this kind of pointless 'verification. All because someone on the business side had a -feeling- the headers -might- be wrong -somehow-, and we need to add up all the lines again.

  • löchlein deluxe (unregistered) in reply to Kevin

    Yeah, this might be one of those things where five years ago, a more senior dev fixed a problem you had on the way to the vending machine by squinting at it and going "it's probably something getting interpreted as octal" and now you have a cargo cult fear of leading zeroes. Eh, quite frankly, it's not the worst thing about this by a long shot. (Though without checking, I assume the Decimal constructor takes an optional base with default 10, which I might write out explicitly by way of cargo cult.)

  • löchlein deluxe (unregistered)

    How long until we get an algorithm that does actual long addition, primary school style?

  • (nodebb)

    There's probably a better way to parse ACH, but here is my attempt. Full code at: https://perl.bot/p/w6z5ie

    sub create_message_body_from_file( $path ) {
    # Get all lines, and remove the EOL characters.
    my @lines = $path->lines( { chomp => 1 } );
    
    my $total_cents = sum map {   # Sum all the amounts in Cents.
        substr $_, 28, 39-28+1;   #   Grab characters 28..39 from each line.
      } @lines[2 .. $#lines-2];   # Skip first and last two lines.

    my $body = <<~'EOF';
        The ACH file has been successfully transmitted the file %s with a
        total ACH amount of %.2f to the bank on %s.
        EOF

    return sprintf $body,
        $path->absolute,    # Path as string.
        $total_cents / 100, # As Dollars.
        localtime->ymd;     # Today's date in YYYY-MM-DD format.
}
  • RLB (unregistered)

    I mean, at least it's only a summary being emailed. I presume (given the text of the mail) that the transaction details are delivered more securely.

  • Lothar (unregistered)

    Hell, I'm pretty sure that EDI explicitly supports email as a delivery mechanism.

    It's called AS1 and there is an RFC for it: https://datatracker.ietf.org/doc/html/rfc3335

  • Vincit qui se vincit (unregistered) in reply to Mr. Picky

    I wonder what happens inside to_dec when the transaction amount is less than $1.00.

    Less than $1.00 but greater or equal to $0.10 is ok, but less than $0.10... you're gonna get 10x the amount. eg: '5' => '0.50'. And if there's ever a $0 transaction... that's going to crash.

  • (nodebb) in reply to gordonfish

    And here is a more robust version. Full code at https://perl.bot/p/r76k4w

    sub create_message_body_from_file( $path ) {
    my $read_handle = $path->openr;
    my $total_cents = 0;

    while ( my $line = $read_handle->getline ) {
        next if length $line < 39;                       # Skip if line is too short.
        my $amount = substr $line, 28, 39-28+1;          # Grab characters 28..39 from each line.
        $total_cents += $amount if $amount =~ /^\d+$/;   # Add to total if a number is found.
    }

    my $body = <<~'EOF';
        The ACH file has been successfully transmitted the file %s with a
        total ACH amount of %.2f to the bank on %s.
        EOF

    return sprintf $body,
        $path,                # Path as string.
        $total_cents / 100,   # As Dollars.
        localtime->ymd;       # Today's date in YYYY-MM-DD format.
}
  • LZ79LRU (unregistered) in reply to Vera

    This. Once, long ago, in another time, another land, when I was but young I auditioned for a job at a financial company as a developer. The first thing they told me was "I hope you are ok with not being able to install anything on the development machine without written permission."

    Yea, don't call me I won't call you.

Leave a comment on “Mailing it In”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article