Re: Best Practices for Application Schema for Outbound 834

Following a little on what Eric is recommending...

There are things that are easier to do in code, and there are things that 
are easier to do in a map.

If your source schema is close to the nesting levels of the 834, then you 
will save yourself a ton of map-pain.

I would suggest you start something like

Header
Member
    Coverage
        Provider

Luckily for you, the 834 is rather flat - and is probably the best 
transaction to get your feet wet on.

---Chris


"Eric Stott" <ericstott@[EMAIL PROTECTED]
> wrote in message 
news:eN7OSdVmHHA.3760@[EMAIL PROTECTED]
> Like you said, without knowing more, it is challenging to offer a 
> suggestion.I would have an extract where it pulls 'header' information
and 
> then details where it has the informaiton that will populate the 2300 
> level loop.
> Sorry I could not be of more assistance,
> Eric
> http://blog.biztalk-info.com
>
> "Mark Vance" <Mark Vance@[EMAIL PROTECTED]
> wrote in message 
> news:ED1456C9-732C-4B73-9E3C-7EEBC342642E@[EMAIL PROTECTED]
>>I need to generate an outbound 834 from our internal application and I 
>>need
>> some assistance as to what is the best way to structure my source
schema 
>> (our
>> application data) to ease and simplify the mapping of our data to the
834
>> schema.  The data exists in an SQL 2005 database.  I realize the reader

>> of
>> this post does not know about how our internal application and how it
is
>> structured but I would think there is probably a preferred application 
>> schema
>> approach to use to ease the data mapping to the 834 schema.
>
>