At work, I have been tasked to work on parsing and creating 835 files. I already have a previous system that parses 835 files for use in a sales/payment reconciliation program, but that uses an external commercial program to convert to XML and I process the XML results.
First, there are a number of solutions already out there. As for open-source, python-based pyx12 was one of the first I started playing with because there was a lack of non-GPL java based ones. The java-based ones include EDIReader and OBOE.
Now, one of the challenges I was running into was this whole conversion to XML. I will need to store the 835 EDI files, and if you use a different tool later for XML conversion it may convert it differently, which may lead to different results on the same 835 EDI file (or using the same original datasources when creating an 835 file).
So, I have written my own, specific parser/renderer based on a simplified, java-based domain model (domain objects that could be extended to be EJB3 Entities to be precise). No XML. And, to be more specific, it only works with Pharmacy-based 835 making it smaller and more efficient for my particular purpose. How efficient? I can parse a 2000 transaction 835 EDI file from local disk into java classes in about 200ms -- and that is prototype, non-optimized code with no external library dependencies ;-)
What have we learned? I left some out, but you have to already know and understand 835 EDI files to accomplish this. If you do not have domain knowledge related to 835's, there are plenty of software packages to help you and then you will have to integrate it into your solution. I took the latter approach first and it did work, but proved inefficient and dependent on a commercial solution. With more knowledge, you are able to take control of your destiny (with software at any rate)!