I’ve got a nasty problem here.
I’ve got an inbound EDI INVOIC which I want to validate and transform.
So I use wm.b2b.edi:convertToValues and the schema EDIFFSchema.EANCOM.V96A:TINVOIC.
Now where it get’s nasty is that the EDI message has two optional TAX segments on the same level. If they are both in the EDI message there is no problem, the EDIValues output contains both segments correctly. But when the first TAX segment is not there AND the second one IS, the EDIValues output document contains only the first segment in stead of only the correct second one.
Everyone who has tried to validate and transform an inbound EDI INVOIC and wishes to optionally use both segments, as the standard dictates, should have encountered this problem. Yet I can’t find it on any forums. Who can help me here.
You better open an SR with wM tech support and they might help you either with a schema fix or validation optionally for this segment.
Probably you can alos do some R&D on the INVOIC schema and change it if necessary the TAX segments.Also there are few other schemas i have noticed the same behaviour while mapping the inbound like X12 124 with 2 NM1 segments in the same level (1 NM1 is document and other is doclist…its nasty too )etc…
A more complete solution on how to handle this is by having different names for TAX1 & TAX2. You can accomplish this by specifying an alternate name for the two TAX segments in the flat file schema. If you do this, you’ll have to alter both the inbound (convertToValues) and outbound (convertToString) maps that use this flat file schema. The converToString service would no longer recognize TAX as a valid segment - the segments would need to match the alternate names the users define. The final name in the output record would still be TAX, but the mapping would need to change to reflect the alternate name.
To do this:
Create a new TAX segment in the flat file schema. This cannot be a reference, it must be a definition. (<-- how the @$#!+%! could anyone have known this) Re-create this TAX segment to look just like the definition that is currently in place. Delete the existing reference to TAX record. Do this process again for the second TAX reference. Make sure the schema looks the same as the original schema structure. The only difference should be that you now have two TAX record definitions instead of references. Now specify an alternate name for the first TAX segment (TAX1) and a different alternate name for the second segment (TAX2). Now those TAX segments should always be referred to in mapping as TAX1/TAX2.