this may not be the best way to do this, but we have an issue with 810 transactions that webMethods generates, and this is how we tried to get around it.
on the tds segment, all of our customers (except 1) want the TDS fields with NO decimal places. so I opened up EDIFFSchema.X12.V4010:Dictionary and created a new field definition called 610rm, which is identical to 610 except the FormatService is wm.b2b.edi.util.formatServices:formatN0 instead of formatN2. then, I went up to the record definitions and changed the TDS record to contain 4 of the new 610rm fields called TDS01-04.
when we ran the wm.b2b.edi.convertToString, the TDS segment isn’t created at all. when I reversed the modifications to the dictionary, the TDS segment still isn’t created.
is it okay to modify the edi dictionary in this way?
if not, how can I have the convertToString process draw the TDS segment without decimal places?
You can add/change a new formatService for the particular field but its not good suggestion to add new field in the TDS structure.So build a logic in the format service or before mapping to TDS structure to remove decimal places this makes convertToString works as expected.
I think RMG’s suggestion is the safest. But I believe the output format for the convertToString service is controlled by the format.xml file in the config folder of the WMEDI package. I had a similar problem with convertToString producing decimal output in scientific notation. I never wanted this behavior to occur so I changed the formatDecimal service in this file so that the externalFormatString matched the internalFormatString and it took care of the problem. It might be possible to do something similar to remove the decimal. But, as RMG says, you’re probably best served by removing the decimal yourself before invoking convertToString.
the problem is that even when we removed the decimal in the document, the EDI output from the convertToString would have the decimal place. so we would put in 19030 in the document, and it would come out in the EDI as 19030.00
I think we thought about making a new format service, but we’d have to apply it to the 610 field definition, and the 610 is used in lots of other segments and transactions that we would want to still include 2 decimal places. so we thought we could make a new field definition just like the 610, but using the formatN0 service on that field, then change the TDS to have the new field, because the only transaction we do that uses TDS is the 810.
But adding a new field in TDS Schema is not a good idea,but is your format service removing decimals working as expected when you set in the original field and convertToString works?
we never changed the format service of the 610 element that was originally used in the TDS record definition, because that 610 is also used in other transactions where we want it to be formatted with 2 decimal points.
that’s why we made a new field definition, and changed the TDS record definition to have 4 of those new fields…
we’ve since changed the TDS record definition again to have 4 of the original 610 fields, but now it doesn’t draw the TDS segment at all.
should we just re-install the EDI transaction type into the EDI module to re-create the EDI FF schema and dictionary…?
For rollback,yes re-install either the Document type or migrate a patch of only 810 dictionary/schema taking from another environment from QA or Prod and test for TDS populating or not.
For example if you pass 123.00 input it will give 12300 which is correct.
There is no need to change the default behaviour.
Here i am doing lot of 810 mapings and i am sucessfully doing the same.
the formatting is back to default now, but it seems to add just one decimal place now. it DOES, by default, multiply the TDS01 segment by 100, but it also adds .0 on the end.
ex. 193.00 becomes 19300.0
now that we’re back to default, what should we try? ramesh, what version of EDI has the default behavior working like that? I’d like to think that the webMethods EDI module would do this automatically since it is the standard for the TDS segment, but we’re just not seeing the same thing you are when our service runs…
In almost our 4010 810 integrations before mapping to TDS01 element we are replacing decimal to nothing and convertToString output work fine the edioutput doesnt show in decimal format (.00) looks this is default behaviour.
We are using here 810 4010 version.
You dont need to change any format service in the dictionary/schema for your need.
It simply works for you too.The TDS01-TDS04 is referring to 610 field which is having format service wm.b2b.edi.util.formatServices:formatN2
is the correct one and suits your requiement too.
But i really did not understand why it is not working for you.
In my case if i map 1934.00 from my idoc to TDS01 and convert to string output will give TDS01 as 193400.
As i understood you are expecting same thing i believe.
Just check whether the 610 field definition is having same format service as i mentioned above.
I don’t know why it’s not working here either. especially after I run that particular service (wm.b2b.edi.util.formatServices:formatN2) with these inputs…
it looks to me like that ‘valueToValidate’ is the one I want, but it appears that the ‘formattedValue’ is being returned, and it’s not correctly formatted. what’s the output of your formatN2 service if you give it the same inputs?
Might be you are using any transformers while mapping.
If you are using any remove those transformers.(you can very well use trim )
Let me know your feedback.
on our production server, the formatN2 service works as yours does. all of these changes have only been done to our development server. does anyone know of a server setting that might be causing this. isn’t there a FORMAT_IMPLIED_DEC setting of some kind?
I would like to know what people think about Tim Conner’s comment on this thread posted on May 27.
I have a similar problem where convertToString gives decimal output in scientific notation. Is changing the format.xml under the config directory as suggested by Tim advisable ?
It is ok if you change in the format.xml,but make sure this change effects in all your environments.Some times customization is required matching with data if that causes documents fail when partner receives or internal processing.
Thanks RMG. But I guess changing the format.xml would affect all the fields that refer to the “formatDecimal” service. This can cause undesirable results somewhere else, right ?
On the other hand changing the EDI dictionary doesnt seem to be a very good option either because wM creates only one dictionary for a given X12 version and changing one field might affect some other transaction types which use the same field.
Which option is the lesser of the two evils.
Are there better alternatives ?