https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43757 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Related question on the missing-UNA case, to check it belongs here rather than in a new bug. I'd read (IBM's EDIFACT documentation) that an interchange can start directly with UNB because it "includes the delimiter values". Looking at ISO 9735 more closely, that isn't right. UNB carries the syntax identifier and version (e.g. UNOC:3), sender, recipient, date/time and control reference. It carries no separator characters. Only UNA declares separators. When UNA is absent the receiver is meant to assume the defaults for that syntax level. So an interchange that starts with UNB is the "no UNA" scenario already described in point 2 of the description, and I don't think it needs a separate bug. On the optional follow-up ("assume the standard separators when UNA is absent"), the comment in the description holds. For character sets other than UNOA/UNOB the default separators are non-printable, so a sender using printable separators must send UNA. Falling back to `:+.? '` would therefore be a tolerance for non-conforming suppliers, not spec behaviour. That makes it worth doing only if we see real supplier files that do this, and I'd limit it to files that are otherwise parseable with those separators. Is anyone aware of a supplier sending UNB-first files? A sample (anonymised) would help decide whether the follow-up is warranted. -- You are receiving this mail because: You are watching all bug changes.