Jumbled up subfields in a field retrieved from a message about prowide-core HOT 1 CLOSED

The field gets broken because its content is invalid. And since field 61 in particular does not have any subfield (component) separators (slashes, semicolon, line break) then it is impossible for the parser to recreate the same object you have originally build.

When you build the field instance with new Field61() and you set the internal components individually, each value you provide is store in inner attributes of the class. So far, so good.

However, when you append the field to the message, in the actual message structure the field value is a plain String. For your particular test this becomes:

:61:230510C1,S//dummy

Then, when you retrieve the field from the message, the parser will do a best effort to split the string into field 61 internal components. But if the value has missing or not well-formed content, there is no way to do a proper match.

When you set the values, you should make sure they are compliant with the field specification:

DATE2 [DATE1] 2a [1a] NUMBER <SUB-6> <VAR-SEQU-1>

I suggest you do the test taking into consideration field 61 samples from compliant messages. For example:

081027C858,28NOPT12716219\n1524/6006/TESORO NACIONAL
1001060106D341,34N422NONREF\r\nFURTHER REFERENCE
090227C291553,62NAYG13391140\n1524/6009/TRASPASO AUTOMATICO AL
020626D120000,NCOLABCD//12345
1512290201EDZ0000000002,2222FBNKNONREF
170717D203336,94NTRFR016341554//2395200\n01P

from prowide-core.