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?

thanks.

Luke,

Which version of EDI 810 it is?

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.

Sorry if i have misunderstood your question.

HTH,
RMG

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.

version is 4010

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…?

Luke,

I understand why you have added new field.

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.

HTH,
RMG

Hi luke,

The default behaviour for TDS01 segment is

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.

Sorry, if i did not understand your problem.

Ramesh,

Luke is having problem to remove decimals he is mapping 19030 it is coming out as 19030.00,so he tried to change in the format service.

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…

hmm…

Luke,

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.

Still i will investigate on this and update you.

HTH,
RMG

Hi Luke,

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.

HTH
Ramesh.

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…

value: 193.00
direction: convertToString
validate: true
minLength: 1
maxLength: 15
FormatInfo: <none>

and get back these outputs:

formattedValue: 193.00
meetsFormat: true
valueToValidate: 19300

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?

-L

If i give the same values here is my output looks like

value:193.00
direction:convertToString
validate:true
minLength:1
maxLength:15
formattedValue:19300
meetsFormat:true
valueToValidate:19300

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?

Luke,

I have just tested the formatN2 as you told,it is showing the same output as you got.

In our 810 mappings we are replacing decimals before convertToString and TDS01 element is showing up the output as expected (19300)

RMG.

Hi,

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 ?

Shubhro

Shubhro,

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.

HTH,
RMG

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 ?

shubhro

Is it possible to override the format service for a field as defined in the dictionary from the schema ?

Then I can change the format service for the problematic field only for the Transaction type concerned and leave everything else untouched .

shubhro

Shubro,

If you change the formatService for that particular field in the Schema will that effect other partners.Just make sure before you do the change.

HTH,
RMG

I have a similar problem. I am passing 1 but the convertToString service is giving me 1E0. How do I stop this from happening? Do I edit the format.xml file?

Please elobarate more your problem,so that we can decide to change it EDIFFSchema/Formatservices or format.xml…

HTH,
RMG

Hello,
This may be elaborate, but it is what I do so that I don’t have to muddle with this weak portion of webMethods.
After I create my string, I send it through a field parser. I have a template per user so that if there is a change to be made, it will switch on the given field if it the right partner and change between (integer, scientific, double-precesion). I have separate services to convert between the three from each other. I thought this necessary as this along with the date formats, are the picky things not handled in enough detail in webMethods, but am asked to have custom for a lot of partners.
This is not an easy approach nor a drastically hard one, but I am always able to guarantee custom results for our partners so I felt it well worth it. Good day.

Yemi Bedu

Did you posted the above one as erpuser? or you are answered to above post…

Anyways thanks for sharing…

Hello,
I am not sure about your question. If you asking do only use the solution that was created, then no. If you are asking if I not only use but make the solution, then yes. I was trying to say something that would be a new avenue of approach. Given that working this way would allow for a maintainable separation of the results for the document after the developers when put efforts.

Did I say something that seemed overkill for the above postings? Oh, and I was not just speaking of the direct upper question but mentioning to many other in a general manner. Good day.

Yemi Bedu

Not at all overkill…good info though…Thanks for clarification.