PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 05/31/2019 10:21 AM by  Red
ED40 and Wild Cards
 2 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Red
Content Manager, Supply Chain
Sutter Health
Veteran Member
(243 points)
Veteran Member
Posts:83


Send Message:

--
05/30/2019 2:23 PM

    A number of years back, we brought in a consultant to assist bringing up some vendors on EDI.  It was really more a matter "horsepower", compared to a "technical" assignment, but I was certainly willing to pick his brain while he was available.  The biggest learning I got out of it was the use of the asterisk (*) as a wildcard.  So, as an example, if we had a line set up as

      tpid_I_VENDOR     |     123456789     |     *

          all incoming accounts for a specific GSID/tpid would translate to the same vendor (123456789, in the example).  (Remedial, I am sure, but we used to 'translate' every account number explicitly.  Yes, we don't always work smarter.)

    Well, now we are trying to solver for the same GSID/tpid being able to translate into two possible vendors (think McKesson Pharm and McKesson Blood Plasma, or some of the Bard entities).  If the account numbers are unique between the entities, no worries; but if the two sides use the same account number, the ED40 will only translate against the first line that it sees as a match.  Somehow this got me back to the use of wildcards.  The question:  Can the ED40 use "qualified" wildcards? Now my examples are:

    tpid_I_VENDOR     |     123456789     |     *MCK

    tpid_I_VENDOR     |     234567890     |     *MBP

        or

    tpid_I_VENDOR     |     123456789     |     MCK*

    tpid_I_VENDOR     |     234567890     |     MPB*

     

    Honestly, I have not solved for how I am going to get these qualified values inbound from the supplier (either some GHX Connect+ trickery or assistance from the vendor), but I figured if the ED40 was not going to be able to help, I wasn't going to spend a good deal of time on that piece.

     

    I appreciate any help you have to offer.

    Thanks,

    Red

    Learn from the Past. Prepare for the Future. Act in the Present.
    JimY
    Private
    Private
    Veteran Member
    (1315 points)
    Veteran Member
    Posts:469


    Send Message:

    --
    05/31/2019 5:54 AM
    When we have a vendor with different divisions we use the shipto to determine which division and then translate it to a Purchase From Location. For each division the External Value starts with 440, but the rest of the value is different. I believe the vendor had to put that value in the Ship To location on the 810.
    List Name: GHXOM_I_SHIPTO
    Lawson Value: ST1 4483PUR11000
    External Value: 4408860870

    List Name:GHXOM_I_SHIPTO
    Lawson Value: ST1 4483PUR21000
    External Value: 4409876420
    Red
    Content Manager, Supply Chain
    Sutter Health
    Veteran Member
    (243 points)
    Veteran Member
    Posts:83


    Send Message:

    --
    05/31/2019 10:21 AM
    Jim,
    Thanks for response. When the vendor is supplying discrete account values (SoldTo, ShipTo, whichever), then you are correct that explicitly defining the inbound accounts will address the issue. And it does occur to me, pretty much as I am writing this, that acctX-MCK and acctX-MPB are inherently discrete as well, so if the vendor can accommodate the process, then explicit definitions will, again, suffice. I think I was hoping to be able to use the "qualified" wildcard because it would be greatly reduce the number of lines, and simplify the overall maintenance.

    What I will also say is that we do not use the inbound version of the ShipTo value. The only inbound values we use are Vendor, Company and ProcessLevel, and I think the REMIT value has been recently added for those instances where we receive non-PO invoices via EDI. I will need to work with my analyst to see about the use of the _I_SHIPTO to see if that will help.

    Thanks again,
    Red
    Learn from the Past. Prepare for the Future. Act in the Present.
    You are not authorized to post a reply.