On Thu, Aug 16, 2012 at 1:51 PM, Kurt Wendt wrote:
> Matt - its SO TRUE - because, even though EDI is "Supposed" to be a
> Standard - all the Trading partners use or do it slightly differently -
> so we have to end up hard-coding all this Crap in our programs to make
> the EDI stuff work. Its NUTS
gment) that begins with ST tells you the name of the transaction
set: ST|837 is a provider healthcare
claim sent to a payer.
- Original Message -
From: "Kurt Wendt"
To:
Sent: Thursday, August 16, 2012 11:34 AM
Subject: RE: EDI, Hex & VFP - Oh My...
Honestly - I'm not s
?INT(VAL(TRANSFORM(0x65)))
:-)
--
rk
-Original Message-
From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On
Behalf Of Kurt Wendt
Sent: Thursday, August 16, 2012 2:59 PM
To: profoxt...@leafe.com
Subject: RE: EDI, Hex & VFP - Oh My...
Then it dawned on me -
I hear ya. And, I know that Stephen has gotten on here and also ranted a
bit about EDI. Yeah - not really fun stuff...
-K-
-Original Message-
From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com]
On Behalf Of M Jarvis
Sent: Thursday, August 16, 2012 2:56 PM
On Thu, Aug
Of Ted Roche
Sent: Thursday, August 16, 2012 2:49 PM
To: profoxt...@leafe.com
Subject: Re: EDI, Hex & VFP - Oh My...
Most of the internet is speaking Unicode UTF-8 or -16 these days.
ASCII is really only defined for the first 128 characters (7-bit) and
the 'extended ASCII character set&#x
On Thu, Aug 16, 2012 at 11:51 AM, Kurt Wendt wrote:
> Matt - its SO TRUE - because, even though EDI is "Supposed" to be a
> Standard - all the Trading partners use or do it slightly differently -
> so we have to end up hard-coding all this Crap in our programs to make
> the EDI stuff work. Its NUT
xtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com]
On Behalf Of M Jarvis
Sent: Thursday, August 16, 2012 2:53 PM
To: profoxt...@leafe.com
Subject: Re: EDI, Hex & VFP - Oh My...
On Thu, Aug 16, 2012 at 11:48 AM, Ted Roche wrote:
> So, your vendor, in choosing an upper 8-bit character
On Thu, Aug 16, 2012 at 11:48 AM, Ted Roche wrote:
> So, your vendor, in choosing an upper 8-bit character, is implementing
> a "non-standard EDI format" which I can't even type without lol.
>
The nice thing about having very explicit STANDARDS is that there are
so many to choose from
--
gt; -Original Message-
> From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On
> Behalf Of kamcgin...@gmail.com
> Sent: Thursday, August 16, 2012 1:44 PM
> To: profoxt...@leafe.com
> Subject: Re: EDI, Hex & VFP - Oh My...
>
> If this is for a ANSI 837 t
On Thu, Aug 16, 2012 at 11:34 AM, Kurt Wendt wrote:
> Actually - I find it VERY ODD that they are using this particular character -
> because, in other EDI files, its usually characters like you described
> below...
>
if it's a mainframe you are talking to it doesn't really surprise
me... ours
tech-boun...@leafe.com] On
Behalf Of kamcgin...@gmail.com
Sent: Thursday, August 16, 2012 1:44 PM
To: profoxt...@leafe.com
Subject: Re: EDI, Hex & VFP - Oh My...
If this is for a ANSI 837 transaction set, for example: sending claims to
Medicare:
Element separator: 124 '|'
Sub-element sep
If this is for a ANSI 837 transaction set, for example: sending claims to
Medicare:
Element separator: 124 '|'
Sub-element separator: 094 '^'
Segment terminator 126 '~'
Those are all ASCII, visible, printable codes so you should not have to use the
hex value.
- Original Message -
F
foxt...@leafe.com
Subject: Re: EDI, Hex & VFP - Oh My...
On Thu, Aug 16, 2012 at 9:54 AM, Kurt Wendt
wrote:
> As such, I figured I would try to implement via the Hexcode. But, how
exactly do I use HexCodes in VFP. I know the ASC() and CHR() commands,
but, AFAIK - that's for purely Ascii c
Hex in VFP:
constant number, just prefix with 0x :
0x5F (same as just 95)
format number to string:
TRANSFORM(95,"@0") -> 0x005F = 8digits after the 0x
string to number:
VAL("0x5F") or EVALUATE("0x5F") -> 95
Fred
On Thu, Aug 16, 2012 at 9:54 AM, Kurt Wendt wrote:
> Hey folks,
>
14 matches
Mail list logo
