The don’t give a different meaning. They give refined meaning. Consider the Winning-Appliance_MIG_Invoice implementation guide you shared.
Page 7 it indicates which segments are expected/supported in the heading section. The INVOIC message defines many, many segments. The MIG from Winning Appliances identifies which segments they use.
Page 8 identifies the segments for the detail section. Same note as above.
Page 10 identifies the details for how to use the UNB segment. The Partner identification code qualifier element defines the 2 codes that are specifically supported out of many, many codes that are possible as defined by the standards. The MIG is saying “use this subset.”
They are not defining anything new nor are they changing the definition of anything. Everything in the MIG is within the constraints of the defined standard. The defined standard is what the imported document types in wM IS/TN support.
They cannot do so. The VANs and partners will not accept that. If an element is defined in the standard as a number, then it must always be a number. To do otherwise makes it “non-EDI” not “custom EDI.”
No. Not only are they not encouraged they are not really allowed. If you start placing data into an element that does not conform to the definition within the standard, no one will accept it. The EDI software that everyone uses enforces conformance to the standards. There is no notion of “customizing the standard.”
I’ve never encountered a scenario the EDI docs could not address. If there is a data value that cannot be placed in a particular element due to type, there is most likely another place for that data. Either within the same segment or in another segment. And it is likely that other place is more appropriate. These standards have been vetted and updated extensively by many, many participants. It is highly unlikely that a given company has a scenario so unique that they would need to modify the definition a standard doc.