Can't use the standard



  • The company I work for has regular clients who we invoice from our custom software fairly regularly. Two of these clients are quite large (I won't name them, mainly because you lot would definitely know one of them), and require us to send their invoices to them electronically. Instead of haggling over the format and such, we agreed to use standard EDI messages. This makes it really easy for us, because it means that we can make the code pretty standard and pass in just a few parameters to get the invoices built correctly and then sent to the correct companies. About 2 years ago, I was involved in a project that moved this functionality from a legacy VB6 desktop app to our current browser based, which is written in C#. At the time, we were told to just port the code over and make sure it works.

    During the testing phase of the port, company A (a huge tech company) told us to change the file name on our test files to include TEST at the end. Ok, no big deal. company B told us that we had to change our ID in the file from CMPNY to CMPNY_TEST for test files. Ok, fine.

    Fast forward to today, and I'm tasked with setting up a new company to receive electronic invoices from us using EDI. I figure that now is a good time to go over the code for building an EDI message and make sure that everything is sleek and smooth. So I grab the EDI spec for the invoice message we are using and start working my way through the code. I finally get to this bit:

    ISA15     I14     Usage Indicator              Must Use
    Description: Code used to indicate whether data enclosed by this interchange envelope is test, production or information.
        Code     Name
         T           Test
         P           Production
         I            Information

    On second thought, I think I'll call company A Innotel. I'll let you run with that one.



  • There are differences between dev, test, and prod?



  • Some of the systems I've worked with would say there are vast and sweeping differences. Especially where environment is concerned, because running test and prod on different operating systems couldn't possibly cause issues, right?



  • With the site I'm working on right now (personally), production is a Linux server, and I develop/test on a Windows server. 😃



  • @chubertdev said:

    With the site I'm working on right now (personally), production is a Linux server, and I develop/test on a Windows server. 😃

    But ... what ... I mean ...

    Who's the "genius" that came up with that idea?



  • @abarker said:

    But ... what ... I mean ...

    Who's the "genius" that came up with that idea?

    It's a super-small site that's on a shared hosting $5/mo plan, and I CBA to set up a proper environment for it.



  • Still, I'm sure that leads to all sorts of interesting bugs.



  • @abarker said:

    But ... what ... I mean ...

    Who's the "genius" that came up with that idea?

    That's my standard process of operations for PHP, btw. The difference is I'm aware of the gotchas having done this in various forms for my entire 11 years of PHP.



  • None that I've run into yet, other than configuring the Windows dev environment to handle the production code.


  • Discourse touched me in a no-no place

    @Arantor said:

    That's my standard process of operations for PHP, btw. The difference is I'm aware of the gotchas having done this in various forms for my entire 11 years of PHP.

    For the vast majority of what you use a server computer for, you can be quite adequately served by both Windows and Unix. The underlying API is a bit different, but the concepts are really not too far apart; you can have a compatibility layer that hides almost all the details. There are a few exceptions. For example, I still suspect that Windows has better thread support, and Unix has better subprocess support.

    Also, anything with GUIs tends to be much more awkward to make cross-platform. And that's where Macs are definitely better, even if you happen to not like the style. Alas, they're also very different to everything else too. (Cross-platform GUIs? Don't make me laugh. Nothing that is great on one platform will look good on another without substantial modifications. The best you can hope for is to have properly transferrable skills.)



  • BTW, "Cant' use the standard" and "EDI" are nearly synonymous. No two companies create similar EDI documents for the same transaction. There's always crap like "don't use segment XX12 for that, our software requires you use XX34 instead, even though the spec says XX34 is for something totally unrelated".



  • Yes, as I work with more companies doing EDI, I am discovering this. Which is utterly baffling, because - like any messaging standard - you have to write your own software to take the data and put it where you want it, or to output the data into the message. So why not stick to the B*****ming standard?



  • The specific problem I was thinking about came as a result of the fact that test was 32bit and prod was 64bit. I don't remember the specifics, but the gist is there was a bug in the 64bit version of a library we were using that would periodically bring prod to it's knees. Still, after hours callouts pay well!


Log in to reply