we went kinetic web last weekend and we are having EDI format issue since then..
seems that the END of line went from CRLF to just LF.. those are now beging reject by our customer.. I have open a ticket with Epicor but nothing so far.. any suggesting
ex of last weekend move to Kinetic WEB
before upgrade
If the customer’s getting their documents then it might not be the CR/LF. Maybe a schema change? Any specific errors on your EDI translator side?
Possibly related to the linux migration since linux uses LF instead of CRLF.
Not sure how youd fix that other than the customer updating things on their end.
Could be…but if the CR/LF in the schema lines was the cause, the doc probably wouldn’t import into whatever translator’s being used.
If the customer’s rejecting what they received, that means it got past the translator…maybe a missing segment/element.
We moved to Linux this weekend too - once we got the filepaths sorted we were off and running. No reject emails/alerts from our customers/vendors, no 864/824 back…
I only say that because I dont know what is set up, but normally when you parse a file like that, you have handling to deal with LF vs CRLF as its a pretty common thing to have to deal with.
If the customer has some custom thing setup that was designed in house or by a contractor to parse that information, then they could have done it in a way that doesnt handle it nicely.
Possible…anytime you get into delimiters it’s trouble. CR and LF and * and ~ and ^ and all that jazz…
One bad part description with a weird character in it…
Hi John,
File can read no worries. But as the delimiter changed, the mapping can’t read the others lines.
We tested with CRLF and not LF. We need to receive it with CRLF as EOL delimiters.
We should received as it is before.
Possibly something in report style? I’m just throwing a guess out there. We migrated this weekend and didn’t see any delim issues. What EDI translator are you using?
