eBay import orders

[David Shere]

Somewhere in a party's record would need to be:

* eBay buyer id (like "SteeleRubber")
* eBay buyer EIASToken, which looks like this: "nY+sHZ2PrBmdj6wVnY
+sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ==".  From eBay documentation: "The
EIAS value for a given user does not change, even if the user's eBay
user name changes. An application stores this value the same way it
stores the eBay user name. When making calls that return a User object
(which contains both the UserID and EIASToken), the application checks
the user ID returned against the one it has stored and changes the
stored user ID as necessary.

What table would be the best to put this in?  

Jacopo Cappellato wrote:

> Oh great,
>
> one detail that we have not implemented (and it isn't in our short
> term plan) but that it could be rather important is that, when
> importing orders, the interface doesn't attempt to find an existing
> party id associated to the eBay buyer: right now a new party is always
> created everytime a new order/auction is imported.
>
> It would be great if you could work in this area:
>
> * implement a mechanism to lookup parties from an eBay buyer
> * if the party is found, determine if we need to update its contact
> information
>
> Of course I will take care of reviewing/committing your work and of
> course, if you'll need them, to provide suggestions/details.
>
> Jacopo

--
David Shere
Information Technology Services
Steele Rubber Products
704-483-9343 x277

[Jacopo Cappellato]

Hi David (Shere),

I'd say we can store it in the PartyAttribute entity.

For example:

partyId="10000"
attrName="EBAY_BUYER_ID"
attrValue="nY+sHZ2PrBmdj6wVnY+sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ=="

Does it make sense?

Jacopo

David Shere wrote:

> Somewhere in a party's record would need to be:
>
> * eBay buyer id (like "SteeleRubber")
> * eBay buyer EIASToken, which looks like this: "nY+sHZ2PrBmdj6wVnY
> +sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ==".  From eBay documentation: "The
> EIAS value for a given user does not change, even if the user's eBay
> user name changes. An application stores this value the same way it
> stores the eBay user name. When making calls that return a User object
> (which contains both the UserID and EIASToken), the application checks
> the user ID returned against the one it has stored and changes the
> stored user ID as necessary.
>
> What table would be the best to put this in?  
>
> Jacopo Cappellato wrote:
>> Oh great,
>>
>> one detail that we have not implemented (and it isn't in our short
>> term plan) but that it could be rather important is that, when
>> importing orders, the interface doesn't attempt to find an existing
>> party id associated to the eBay buyer: right now a new party is always
>> created everytime a new order/auction is imported.
>>
>> It would be great if you could work in this area:
>>
>> * implement a mechanism to lookup parties from an eBay buyer
>> * if the party is found, determine if we need to update its contact
>> information
>>
>> Of course I will take care of reviewing/committing your work and of
>> course, if you'll need them, to provide suggestions/details.
>>
>> Jacopo

[David Shere-2]

Yes.  See, I would have created a new table.  That's why I ask first! :)

On Fri, 2007-07-20 at 23:12 +0200, Jacopo Cappellato wrote:

> Hi David (Shere),
>
> I'd say we can store it in the PartyAttribute entity.
>
> For example:
>
> partyId="10000"
> attrName="EBAY_BUYER_ID"
> attrValue="nY+sHZ2PrBmdj6wVnY+sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ=="
>
> Does it make sense?
>
> Jacopo
>
> David Shere wrote:
> > Somewhere in a party's record would need to be:
> >
> > * eBay buyer id (like "SteeleRubber")
> > * eBay buyer EIASToken, which looks like this: "nY+sHZ2PrBmdj6wVnY
> > +sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ==".  From eBay documentation: "The
> > EIAS value for a given user does not change, even if the user's eBay
> > user name changes. An application stores this value the same way it
> > stores the eBay user name. When making calls that return a User object
> > (which contains both the UserID and EIASToken), the application checks
> > the user ID returned against the one it has stored and changes the
> > stored user ID as necessary.
> >
> > What table would be the best to put this in?  
> >
> > Jacopo Cappellato wrote:
> >> Oh great,
> >>
> >> one detail that we have not implemented (and it isn't in our short
> >> term plan) but that it could be rather important is that, when
> >> importing orders, the interface doesn't attempt to find an existing
> >> party id associated to the eBay buyer: right now a new party is always
> >> created everytime a new order/auction is imported.
> >>
> >> It would be great if you could work in this area:
> >>
> >> * implement a mechanism to lookup parties from an eBay buyer
> >> * if the party is found, determine if we need to update its contact
> >> information
> >>
> >> Of course I will take care of reviewing/committing your work and of
> >> course, if you'll need them, to provide suggestions/details.
> >>
> >> Jacopo
>
>
>

[Ean Schuessler]

On Friday 20 July 2007 04:12:43 pm Jacopo Cappellato wrote:
> Hi David (Shere),
>
> I'd say we can store it in the PartyAttribute entity.
>
> For example:
>
> partyId="10000"
> attrName="EBAY_BUYER_ID"
> attrValue="nY+sHZ2PrBmdj6wVnY+sEZ2PrA2dj6wGkYCnDZeHqQ+dj6x9nY+seQ=="

I've used PartyContactMech for this sort of thing in the past. It allows
duplicates (multiple ebay ids) as well as from/thru dates. I've also
considered employee IDs to be a contact mech in the past. I was dealing with
the merger of an acquired company and managing multiple employee IDs with
PartyContactMechPurpose was useful.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com