in reply to Getting an ANSI X.12 file's delimiters

First of all, ++ to you, simply for being (probably) the only other monk here that uses perl for X12. I'm just curious, which X12 transactions do you work with? I, coming from healthcare, do a lot with 270/271, 835 and 837. Personally, I use a somewhat more complicated library (written mostly by me) for handling X12's. So much fun.

Anyway, as to your particular implementation: I've found that some EDI sources use (almost certainly non-compliantly... but the spec has some minor vagueries) an "\r\n" pair as their segment separator, or, even wackier include a following linefeed (and/or carriage return) after their segment separator (since this is how the spec examples tend to make the files appear). So I end up with using:

($isa =~ /.{105}(.?\r?\n?)/)[0]
as my segment separator.

P.S. In other geeky stories... have you ever had to have an argument with your boss about why "grep" is inappropriate for X12 files?


------------
:Wq
Not an editor command: Wq

Replies are listed 'Best First'.
Re: Re: Getting an ANSI X.12 file's delimiters
by delirium (Chaplain) on Dec 08, 2003 at 23:55 UTC
    Thanks. I hadn't given \r too much thought, as it hasn't ever bit me. We're on Unix, and most of our trading partners are Unix and Linux. (.?\r?\n?) is pretty cool, though. I'll have to remember that.

    I do mainly banking files right now (820, 828, etc.). It's my wife who is in health care, though. She works at Foresight helping develop the HIPAA validator, among other things.

    I haven't ever had to argue against the grep utility. My group knew not to use it long before I got there. A few of our TPs send data with no line breaks, and our version of Unix has a grep that can't handle > 2048 characters. Saying "grep says it can't handle the file" carries some weight, apparently.