Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

EDI Mapping

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    EDI Mapping

    Is anyone familiar with EDI Mapping. I would like to map certain fields to a particular EDI software which would be sent through a third party van to a customer. Looking for the best way to go about this?

    #2
    RE: EDI Mapping

    Hi Robert....

    I have done some EDI with Alpha software, I wrote data to a file that
    would import into an EDI software for transmiting. The EDI software
    gave a brief explataion of the necessary field delimiters & formatting
    for the file to import correctly. I would check the EDI software that you
    will be using to transmit the transactions for inforamtion regarding import
    file requirements. I believe that the "clearing house" was Harbenger ... Who
    will your transactions be going through? Maybe I can be of some more help?

    Good Luck!

    Comment


      #3
      RE: EDI Mapping

      Hello Doug,

      Thanks for replying. Our van or third party is Kleinschmidt. The software we are using is from Qualedi or Eventra. I have checked with Alpha and Eventra and didn't have much luck. We are key entering our data now and it is becoming too much. Is there any software out there specifically designed to interface? Any more ideas let me know.

      Comment


        #4
        RE: EDI Mapping

        Hi Robert,

        When I worked with Harbenger, they offered a "port" utility, $2900.00
        The client wasn't ready to spend that kind of money, I managed to write
        a script that would generate a file that would import directly into the
        EDI software. When you key the data into Eventra it may have a "print to file"
        option, if so, that should generate a simple text file, from that you can get
        an idea of delimiters & formatting. If that option is not avaliable....

        EDI is a standard, & its just not polite these days to create a software that
        has will not let you import your data into it. If you have contacted Eventra,
        contact them again, & ask about being able to import a formatted text file into
        their software. When they create the file to transmit, they are reading data from
        a database & write a text file & send it to a modem... most seem to use a third
        party communication software like Pro Com or something similar. So if they are
        writing a text file how much more trouble is it to include an import function
        that will read that same format into their database?

        Alpha is very capable of writing a text file with the proper formatting, you may
        need to brush up on you xbasic, these are some of the help topics you will be
        using to write the file....

        .create(Filename, Open Mode)

        Bytes Written = .write_line(Text Line)

        Bytes Written = .write(Text [, Number of Bytes])

        .create(Filename, Open Mode)

        = File.open(Filename, Open Mode)

        Position = .pos_get()

        .seek(Byte Offset)

        .flush()

        Character = CHR(ASCIIValue)

        Number of Bytes = .bytes_get()

        These are a few of the topics that will help,I don't know how comfortable you
        are with xbasic, but either way I would suggest that you think through
        the logic of what you want to do & put it on paper. Then search the help files
        for the function or method to complete each part of the task.


        Comment


          #5
          RE: EDI Mapping

          It's pretty easy - eventually. (You might want to create special browses and indexes to confirm data integrity at each conversion stage, especially for the first few test runs.)

          First, there is usually a pre-standard involved, or the firm your exchanging data with has its own. If the latter, get the infor from the firm. For a pre-defined industry standard/subset, find out from the firm your exchanging the data with what the standard is, and where you can get a copy describing the file layouts (header/trailer info, field type, name, other desc, size, expected/allowed values, what those values indicate, and, in the case of dates, sometimes they format them YYYMMDD and MMDDYYYY in the same files). Chances are the firm will be able to provide you with the layouts.

          The files are usually standard ASCII. Write an operation which imports the file (this is usually the biggest pain - getting the field sizes, start, and end to match). Writing an operation to move it to a safety copy (append to an existing file) is usually a good idea. First, if something screws up you don't have to re-import. Second, you might have more than one file to translate. (We get between 0 and 14 a night. Since they're work orders of up to 10K records, and are appened to 2 files of over 350K and another of 275K records, I only want to process and append all that once.) This is where I convert their field names to ours, and change the obligatory 1 or 2 char fields into something more readable, and text representations of dates to regular date fields. Since our system uses auto-increment to indicate each transaction, I also make sure that the first record's ID doesn't overlap existing orders' IDs.

          Now write an xbasic routine to convert their codes to your,
          split fields in to one or more (ie: full name to first name and last name - make sure you test for JRs, etc, and put them in the last name). Some of the fields we use are based on one or more of the other guy's fields (ex: if work ordered = type A then we set 4 other fields used to do other stuff to what we want them to be, sometimes these other values are based on multiple fields : Field1 = A, Field2 = X might make our OurField = "123" while Field1 = B, Field2 = X might make our Field3 = "456", unless their Filed3 = "Z", in which case our Field3 = "abc", unless a search in previous work history or an AlwaysCancelThisWorkCode in a master table for the record of this client's record indicates that the order is to be cancelled automaticaly (mis-order by a user), in which case it is added, marked AutoCancel, and flagged to go to the rsults file at the end of the run and gets automatically converted back to their codes and transmitted). What a pain.

          After you've converted everything over adn confirmed the data, then you just append it to whatever file your manually entered work is done in now and continue the process.

          For sending EDI, just revrese the process. If you are sendning the data to an EDI clearing house / router, then arrange with them for you to send a couple test files in so they can check it and do a test run to make sure it doesn't get rejected by their system. In our case it comes from whatever the client is using, goes to an system (no idea what kind), to an IBM mainframe, over to another IBM mainframe, then to a Tandem, then to ours. If your data doesn't convert cleanly you know something in that chain is going to break. If for no other reason than so that you night guy is going to call you at 3 AM and tell you you have to come in to fix it.

          Comment


            #6
            RE: EDI Mapping

            Hello Jim,

            Thanks for replying. It sounds like there is a little more involved here than I have the time or expertise at this point to accomplish. Have you set up an edi programs like this?

            Comment


              #7
              RE: EDI Mapping

              Doug,

              Thanks for replying. It sounds like there is a little more involved here than I have the time or expertise at this point to accomplish. Have you set up an edi programs like this? I developed the billing database from Alpha 5v4 that we are using but have no familiarity with mapping for edi.

              Comment


                #8
                RE: EDI Mapping

                Hi Robert....

                I have written xbasic scripts that generate a text file from table data for
                import into EDI software. The client that I wrote the application for had
                specific transaction criteria. The clearing house for the trading partners also
                had specific formating criteria for importing into their EDI software. If the
                EDI software that your trading partners are using has the functionality for
                importing a formated ASCII or Text file into it, then it is within the scope of
                Alpha5 V4 to write such a file.

                If you are interested in working through the xbasic & just need a nudge to get
                you started... I believe that I have a copy of the script I wrote for the EDI
                application. I was using Alpha 5 V 1.1 at the time. If you would like I could
                send it to you to examine. The xbasic syntax has changed a little with the
                newer release of Alpha 5 V4, & I will have to change out any critical billing
                information before I can send it to you.

                If you are asking me if I would be interested in looking at this, please
                email me so we can discuss this off of the forum.





                Comment


                  #9
                  RE: EDI Mapping

                  (I was tempted to answer by just saying "Yes" - one for an industry standard format, and one for a client-specific standard. Both designed so that the EDI file returned could be run from the same program by selective branching.)

                  Set up the import/export in v1, slightly modified it for v4.03. Haven't had time to translate the inbound or outbound programs that convert between the EDI format and ours. It's in Quick Basic X (extended, replacement to 4.5). If you have QB I might be able to zip them up and send it all to you. (Code is rather lengthy for a word processor, and has MANY subprograms.) First I'd have to know what industry you are in (I have a non-compete contract and this is proprietary).

                  (The problem with converting it is that in QB I use called subroutines/subprograms and a lot of GOSUB/RETURN structures because of the complexity of the conversion. Too complex for top-down programming, and I haven't gotten A5 to not continue processing a script where it calls another. You could probably do it using functions, but fortunately I've been to busy to look at that approach. In fact, this is really the only area I don't like about XBASIC in A5 - the lack of a GOSUB / RETURN structure.)

                  A simple way to start would be to first read in the EDI file as text strings. In our case, there are 5 BIG strings (EDI records) per transaction. Then you can either get the specific porion of each string that applies to a specific field and convert it using SELECT (usually more convenient than IF) and other stuff. After modifying the data to match your system, write the record and if you're not at the end of the file, get and process until you are.

                  You could alternatively create an intermediary file. After importing the text strings, strip the file down to matching fields and then process your data conversion. (It would be better to use A5's import operation, especially if you have an idea of what the data is supposed to look like, so that you can confirm that you are breaking the data up correctly.) The only problem is that if you don't use a big string to read it in as, you could end up not correctly reading/processing header and trailer records (holds info such as who is sending the file, the date, and the trailer with counts).

                  Operationally:
                  Inbound
                  1. Import EDI file as big strings
                  2. Extract and process header info
                  3. Concatenate strings for same transaction (if applies), append to new work file
                  4. In a script, convert/format values in work file to your data requirements
                  5. In the same script write each record to your tables (in our case it's faster that way than appending 10K records to 2 files because of the index build time for 350K + records)

                  Outbound - revrese the process
                  1. Have mechanism to get the records you want to send (we use a field to flag for this in a master control file with key fields common to the transaction header and support tables), and write the records to a temporary workfile)
                  2. Translate the data back to EDI standard
                  3. Write holding file with each record in a nice big string of all values (PAD EXTRA SPACES TO MATCH SIZE)
                  4. Export it as a text file for upload, preceded with your header and followed by your trailer.

                  Comment

                  Working...
                  X