 |
|
| Computers Forum Index » Computer - Databases - Pick » So how dead is CDP?... |
|
Page 4 of 5 Goto page Previous 1, 2, 3, 4, 5 Next |
|
| Author |
Message |
| Homer L. Hazel... |
Posted: Thu Oct 15, 2009 9:42 am |
|
|
|
Guest
|
"frosty" <frostyj at (no spam) bogus.tld> wrote in message
news:OPGdnQPTMOSZlkvXnZ2dnUVZ_t2dnZ2d at (no spam) centurytel.net...
Quote: Homer L. Hazel wrote:
Just to understand, the St. John site is not a disaster? It is a
e-tail success?
If by "success" you mean "makes more money for the company than
it costs to maintain" then I'd say, "Could be."
If by "success" you mean "a model for how to build a site" then
I'd say "you left out the word 'not'."
--
frosty
I will defer to your wisdom about the site, for I am not
an Internet expert, but I do not think I share your thoughts
about the site.
It seemed straight forward and easy to navigate.
There was no annoying flash or music.
I found out they have special band aids for mammograms
which I had never known before. 8>)
Larry |
|
|
| Back to top |
|
|
|
| dawn... |
Posted: Thu Oct 15, 2009 12:38 pm |
|
|
|
Guest
|
On Oct 14, 9:40 am, JJCSR <JCro... at (no spam) ktp.com> wrote:
Quote: On Oct 14, 12:20 am, Art Martz <artma... at (no spam) triad.rr.com> wrote:
You might also take a look atwww.marketamerica.comfora web site
driven with a UniVerse/Redback back-end.
Art
Thanks for the information, Art. Does "MarketAmerica" use any MV for
the website, itself, or are they doing what I have to do - extract SQL
tables (or any other type of data) and build a PICK (MV) file?
FWIW, I'm working on an e-commerce site directly against MV with the
Cache' AJAX platform (called Zen). We can use javascript and css,
along with MVBASIC. We use OO enhancements for MV to address
concurrency using their automated versioning of records and other nice
features. There is a learning curve, but there is with any browser-
based rich user interface (AJAX) platforms. We use SQL projrections of
our metadata, but we do not export to anything SQL at all. Cache's
implementation of SQL for MV is as fast as any out there. In fact,
they implemented the MV query language on top of SQL and still get the
speed out of it.
One of the reasons I chose this platform is that we can write the
software with no middle-tier language in our source code other than
mvbasic. [They have recently implemented server-side javascript too,
which we might try out at some point, plus they have other language
options too, but mvbasic is what we are using.]
cheers! --dawn
Quote: Just
curious.
Jim Cronin
Kittery Trading Post |
|
|
| Back to top |
|
|
|
| Rob Allen... |
Posted: Fri Oct 16, 2009 3:30 pm |
|
|
|
Guest
|
On Oct 13, 5:22 am, "Ricky Ginsburg" <ric... at (no spam) fawnridge.com> wrote:
Quote: Hey Jim. Do you remember George Capell?
I'm not Jim, but I worked for George Capell for about a year in the
early 80s.
Rob Allen |
|
|
| Back to top |
|
|
|
| mvdbman... |
Posted: Sat Oct 24, 2009 7:20 pm |
|
|
|
Guest
|
On Oct 14, 9:42 am, JJCSR <JCro... at (no spam) ktp.com> wrote:
Quote: On Oct 12, 5:29 pm, mvdbman <mvdb... at (no spam) gmail.com> wrote:
On a more serious note, there is another retailer with a
"Pick" (UniVerse) backend. I work for Neiman Marcus.
http://www.linkedin.com/in/mvdbman
-Bruce H
Bruce:
What about the "front-end", the web page, itself? Are you using any
MV-based software for the website, or do you extract tables and build
MV files?
Jim Cronin
Kittery Trading Post
The NM e-com web sites are backended (yes, that's a new word!) by
Oracle. Since the product data is in UniVerse, there are several
"feeds" sent to the Oracle systems in near-real-time by UniVerse
software running as phantoms via sockets with the data going as xml.
These feeds keep product info up to date in Oracle. There are feeds
containing customer updates and orders from Oracle back into UniVerse.
I have not been involved much in that process, so I am not very
knowledgeable as to the nuts and bolts of the whole process but I
believe I have given the gist of it - briefly!
But speaking of web pages, the project I am currently working on
involves Web Services. We have a J2EE application being created by IBM
for WebSphere Portal Server (several "portlets") using a large data
store in WebSphere Product Center as a common data source and with
WebSphere Process Server managing all the messaging between the
WebSphere products just mentioned and FileMaker and UniVerse. We are
using the U2 Web Services Developer Tool to create the wsdl's for all
the incoming (to UniVerse) SOAP requests. We also have an MV program
that generates outbound SOAP requests to WPS (WebSphere Process
Server) and WPC (WebSphere Product Center). The app, once finished,
tested and installed, will allow the merchants to create sku's, offer
items (an offer is a catalog, an item is a specific size and color of
a product on a page of the catalog), PO's and to manage Vendors. The
project is due to be installed in a few "pilot" buying offices first
quarter next calendar year.
Bruce H |
|
|
| Back to top |
|
|
|
| GlenB... |
Posted: Fri Nov 06, 2009 5:12 pm |
|
|
|
Guest
|
On Oct 5, 10:19 pm, Tony Gravagno
<address.is.in.po... at (no spam) removethis.com.invalid> wrote:
Quote: This forum has been dying for a long time now. I know too many people
who say they never even read it anymore. The noise-to-signal ratio
has chased everyone away. Does anyone have a suggestion for bringing
back the quality? Feel free to suggest that people would come back if
some of us just go away - I'd agree and comply.
It can't be my fault. I hardly post here anymore. No time.
Quote: As to where people have gone, I think some are just lurking rather
than posting. Some people have been hit by the economy and spending
time in places other than forums. Many end-users have migrated to
other platforms, leaving no one here to discuss Pick but old pickies.
And many have moved to product-specific forums. That said, the
traffic in those is down to almost nothing sometimes too.
Is the MV market just depressed?
T
Help! Drowning in orders here! I've been promoted to sales rep. New
projects and problems that I have no time for! I find time to tweet
occasionally. at (no spam) pickcoder
Someone please clone me so I can get a break. And please, Pick sales
peeps, STOP calling my office #. I don't have time to talk! If I need
your products or services I will call you. *running around in circles
going nowhere*
GlenB |
|
|
| Back to top |
|
|
|
| wjhonson... |
Posted: Sat Nov 07, 2009 9:35 am |
|
|
|
Guest
|
On Nov 6, 9:12 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Quote:
Someone please clone me so I can get a break.
GlenB
I'm right here. And I'm cheap (and easy).
Will Johnson |
|
|
| Back to top |
|
|
|
| GlenB... |
Posted: Mon Nov 09, 2009 5:25 pm |
|
|
|
Guest
|
On Nov 7, 4:35 am, wjhonson <wjhon... at (no spam) aol.com> wrote:
Quote: On Nov 6, 9:12 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Someone please clone me so I can get a break.
GlenB
I'm right here. And I'm cheap (and easy).
Will Johnson
You sound like an insurance commercial. Do you deny most of your
claims for the first 2 requests? :)
The biggest time waste I've experienced is having to get address
matches on credit cards for US and Canada. I've been on hold now for
15 mins waiting for someone at Titanium Platinum Card in Canada to
pick-up. Then, I'll get no address match and have to e-mail the
customer for a different card and put the order on hold. Argh!!
Businesses need an international credit card billing and shipping
address validation protocol for all card issuers. By the time I'm done
wasting my time, I will have lost all profits on the order.
GlenB |
|
|
| Back to top |
|
|
|
| wjhonson... |
Posted: Mon Nov 09, 2009 7:37 pm |
|
|
|
Guest
|
On Nov 9, 9:25 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Quote: On Nov 7, 4:35 am, wjhonson <wjhon... at (no spam) aol.com> wrote:
On Nov 6, 9:12 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Someone please clone me so I can get a break.
GlenB
I'm right here. And I'm cheap (and easy).
Will Johnson
You sound like an insurance commercial. Do you deny most of your
claims for the first 2 requests? :)
The biggest time waste I've experienced is having to get address
matches on credit cards for US and Canada. I've been on hold now for
15 mins waiting for someone at Titanium Platinum Card in Canada to
pick-up. Then, I'll get no address match and have to e-mail the
customer for a different card and put the order on hold. Argh!!
Businesses need an international credit card billing and shipping
address validation protocol for all card issuers. By the time I'm done
wasting my time, I will have lost all profits on the order.
GlenB
You're doing this manually? Why couldn't you code software to wait
for a response, and if it gets a no match to automagically email back
the customer, etc. Why do you have to be involved in a purely
automatic task like that?
Will |
|
|
| Back to top |
|
|
|
| GlenB... |
Posted: Mon Nov 09, 2009 8:28 pm |
|
|
|
Guest
|
On Nov 9, 1:01 pm, Tony Gravagno
<address.is.in.po... at (no spam) removethis.com.invalid> wrote:
Quote: GlenB wrote:
The biggest time waste I've experienced is having to get address
matches on credit cards for US and Canada. I've been on hold now for
15 mins waiting for someone at Titanium Platinum Card in Canada to
pick-up. Then, I'll get no address match and have to e-mail the
customer for a different card and put the order on hold. Argh!!
Businesses need an international credit card billing and shipping
address validation protocol for all card issuers. By the time I'm done
wasting my time, I will have lost all profits on the order.
"International" might mean USA and Canada for USA-based merchants with
USA/Canada-based consumers. Outside of that it can get more
difficult. I was doing this in NebulaPay. Essentially the single
BASIC API allowed for address validation and other operations for an
assortment of providers. Unfortunately I doubt I'll be taking that
software out of mothballs anytime soon.
T
Vital can not validate many card billing addresses, simply because:
1) the issuing bank is still in the stone ages and does not provide
address validation over the intarweb. 2010 card security? Heh! That's
a laugh from a merchant stand-point.
2) the issuing bank is not a US-drafted bank and therefore will not
mesh with Vital since the zip may be alpha-numeric
3) the issuing "bank" is a congolmerate of holding firms that don't
even know each other's phone numbers, much less which department has
computer access to the card info for that specific card.
GlenB |
|
|
| Back to top |
|
|
|
| GlenB... |
Posted: Mon Nov 09, 2009 8:30 pm |
|
|
|
Guest
|
On Nov 9, 2:37 pm, wjhonson <wjhon... at (no spam) aol.com> wrote:
Quote: On Nov 9, 9:25 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
On Nov 7, 4:35 am, wjhonson <wjhon... at (no spam) aol.com> wrote:
On Nov 6, 9:12 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Someone please clone me so I can get a break.
GlenB
I'm right here. And I'm cheap (and easy).
Will Johnson
You sound like an insurance commercial. Do you deny most of your
claims for the first 2 requests? :)
The biggest time waste I've experienced is having to get address
matches on credit cards for US and Canada. I've been on hold now for
15 mins waiting for someone at Titanium Platinum Card in Canada to
pick-up. Then, I'll get no address match and have to e-mail the
customer for a different card and put the order on hold. Argh!!
Businesses need an international credit card billing and shipping
address validation protocol for all card issuers. By the time I'm done
wasting my time, I will have lost all profits on the order.
GlenB
You're doing this manually? Why couldn't you code software to wait
for a response, and if it gets a no match to automagically email back
the customer, etc. Why do you have to be involved in a purely
automatic task like that?
Will- Hide quoted text -
- Show quoted text -
Because sometimes it's how the numbers are to appear in the address
and also the fact that periods "." are considerd a number in the Vital
address validation service. What a PITA. Sometimes you have to spend
$10 in $1 charges to get an address match because the customer doesn't
type the address in exactly as it is on the bill!. As we say here, "no
coffee for you tomorrow morning!!"
GlenB |
|
|
| Back to top |
|
|
|
| Ross Ferris... |
Posted: Mon Nov 09, 2009 10:20 pm |
|
|
|
Guest
|
On Nov 10, 7:30 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Quote: On Nov 9, 2:37 pm, wjhonson <wjhon... at (no spam) aol.com> wrote:
On Nov 9, 9:25 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
On Nov 7, 4:35 am, wjhonson <wjhon... at (no spam) aol.com> wrote:
On Nov 6, 9:12 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Someone please clone me so I can get a break.
GlenB
I'm right here. And I'm cheap (and easy).
Will Johnson
You sound like an insurance commercial. Do you deny most of your
claims for the first 2 requests? :)
The biggest time waste I've experienced is having to get address
matches on credit cards for US and Canada. I've been on hold now for
15 mins waiting for someone at Titanium Platinum Card in Canada to
pick-up. Then, I'll get no address match and have to e-mail the
customer for a different card and put the order on hold. Argh!!
Businesses need an international credit card billing and shipping
address validation protocol for all card issuers. By the time I'm done
wasting my time, I will have lost all profits on the order.
GlenB
You're doing this manually? Why couldn't you code software to wait
for a response, and if it gets a no match to automagically email back
the customer, etc. Why do you have to be involved in a purely
automatic task like that?
Will- Hide quoted text -
- Show quoted text -
Because sometimes it's how the numbers are to appear in the address
and also the fact that periods "." are considerd a number in the Vital
address validation service. What a PITA. Sometimes you have to spend
$10 in $1 charges to get an address match because the customer doesn't
type the address in exactly as it is on the bill!. As we say here, "no
coffee for you tomorrow morning!!"
GlenB- Hide quoted text -
- Show quoted text -
Considered the PayPal gateway .... sure, percentage may be higher, BUT
the stress levels are a whole lot lower :-)
Also, the "rape & pillage" approach for extractibng data from a web
site could be worthwhile. We have just had to do this for one of our
clients whose major trading partner believed that an email sent with
details of an order corresponded to a web service .... luckily they
did have the required information available on their web site, so
every X minutes we go out, traverse the site, and see if there is any
new information to pick up .... of course the first time they make a
decent change to the site we are shot (minor changes should be AOK as
we use DOM references), but meanwhile the "roll your own" web service
approach is working fine |
|
|
| Back to top |
|
|
|
| Tony Gravagno... |
Posted: Mon Nov 09, 2009 11:01 pm |
|
|
|
Guest
|
GlenB wrote:
Quote: The biggest time waste I've experienced is having to get address
matches on credit cards for US and Canada. I've been on hold now for
15 mins waiting for someone at Titanium Platinum Card in Canada to
pick-up. Then, I'll get no address match and have to e-mail the
customer for a different card and put the order on hold. Argh!!
Businesses need an international credit card billing and shipping
address validation protocol for all card issuers. By the time I'm done
wasting my time, I will have lost all profits on the order.
"International" might mean USA and Canada for USA-based merchants with
USA/Canada-based consumers. Outside of that it can get more
difficult. I was doing this in NebulaPay. Essentially the single
BASIC API allowed for address validation and other operations for an
assortment of providers. Unfortunately I doubt I'll be taking that
software out of mothballs anytime soon.
T |
|
|
| Back to top |
|
|
|
| GlenB... |
Posted: Tue Nov 10, 2009 12:07 am |
|
|
|
Guest
|
On Nov 9, 5:20 pm, Ross Ferris <ro... at (no spam) stamina.com.au> wrote:
Quote: On Nov 10, 7:30 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
On Nov 9, 2:37 pm, wjhonson <wjhon... at (no spam) aol.com> wrote:
On Nov 9, 9:25 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
On Nov 7, 4:35 am, wjhonson <wjhon... at (no spam) aol.com> wrote:
On Nov 6, 9:12 am, GlenB <batch... at (no spam) bellsouth.net> wrote:
Someone please clone me so I can get a break.
GlenB
I'm right here. And I'm cheap (and easy).
Will Johnson
You sound like an insurance commercial. Do you deny most of your
claims for the first 2 requests? :)
The biggest time waste I've experienced is having to get address
matches on credit cards for US and Canada. I've been on hold now for
15 mins waiting for someone at Titanium Platinum Card in Canada to
pick-up. Then, I'll get no address match and have to e-mail the
customer for a different card and put the order on hold. Argh!!
Businesses need an international credit card billing and shipping
address validation protocol for all card issuers. By the time I'm done
wasting my time, I will have lost all profits on the order.
GlenB
You're doing this manually? Why couldn't you code software to wait
for a response, and if it gets a no match to automagically email back
the customer, etc. Why do you have to be involved in a purely
automatic task like that?
Will- Hide quoted text -
- Show quoted text -
Because sometimes it's how the numbers are to appear in the address
and also the fact that periods "." are considerd a number in the Vital
address validation service. What a PITA. Sometimes you have to spend
$10 in $1 charges to get an address match because the customer doesn't
type the address in exactly as it is on the bill!. As we say here, "no
coffee for you tomorrow morning!!"
GlenB- Hide quoted text -
- Show quoted text -
Considered the PayPal gateway .... sure, percentage may be higher, BUT
the stress levels are a whole lot lower :-)
Also, the "rape & pillage" approach for extractibng data from a web
site could be worthwhile. We have just had to do this for one of our
clients whose major trading partner believed that an email sent with
details of an order corresponded to a web service .... luckily they
did have the required information available on their web site, so
every X minutes we go out, traverse the site, and see if there is any
new information to pick up .... of course the first time they make a
decent change to the site we are shot (minor changes should be AOK as
we use DOM references), but meanwhile the "roll your own" web service
approach is working fine- Hide quoted text -
- Show quoted text -
Believe me, we've considered all the angles. There are many people
out there that still don't trust PayPal, much less using a CC on the
intarweb. The costs involved with the PayPal stuff kills our margins
even more than with the existing Visa rates. We do a decent amount of
individual business and the average ticket is so low that if we lose
any more than Visa rates then we might as well just give the stuff
away. The added issue with PayPal is that we could only accept orders
from customers with confirmed addresses. Otherwise, we're throwing
away more money on more risk. Like I said in a tweet a little while
back, it's becoming more expensive and risky to accept credit cards
over paper checks. The card industry needs some major rennovation and
forced standardization of electronic address validation methods. Look
how long it took Internet e-tailers and such to finally catch on that
the CVV2/CID is not just a random number the bank likes to print on
the card. We got belted often when we forced customers to provide that
years ago, but now it's a requirement by any reputable e-seller. The
zip code is also becoming more prevalant, but it's a waste of
validation time if only 1/4 of the issuing banks even have electronic
validation services in place for the card networks. Bank of America
has to be the worst IMO.
Consider this, in this day and age of credit card fraud: We
received an order for a foreign country, known for card fraud. The
order was for 100 pieces of a consumer-ish hand tool product. No one
_ever_ orders that many pieces of such an item from us, even in the
USA. The card was an American Express and the billing address was NY.
Would you believe that:
1) When we contacted American Express, they could not find the card
number at first. Eventually they found it.
2) They stated that the billing address we had was wrong, but they
could not state if it was a US or non-US card.
3) They refused to contact the card holder to validate the order
request or to make them aware of the potential purchase.
4) They would not place a tracer or flag on the account until the card
was literally defrauded by us charging funds on it.
5) So, we ran a $1 address validation and badgered a manager to put a
"watch flag" on the account. Did they actually notify the cardholder?
Probably not.
So, in an attempt to stop card fraud before it happened we were
blocked by the actual card issuer because the card had not yet been
defrauded. *boggles*
It took several escalation levels to reach someone that would even
listen to what we were saying and help out. We would have had to ship
the product, lose our money(a sizeable amount in this case), and get a
chargeback from the card holder(Amex basically), in order for the
number to be marked as a breached card number. What's wrong with this
picture???
GlenB |
|
|
| Back to top |
|
|
|
| Peter McMurray... |
Posted: Tue Nov 10, 2009 4:56 am |
|
|
|
Guest
|
<snip>
Quote: wasting my time, I will have lost all profits on the order.
GlenB
You're doing this manually? Why couldn't you code software to wait
for a response, and if it gets a no match to automagically email back
the customer, etc. Why do you have to be involved in a purely
automatic task like that?
Will- Hide quoted text -
- Show quoted text -
Because sometimes it's how the numbers are to appear in the address
and also the fact that periods "." are considerd a number in the Vital
address validation service. What a PITA. Sometimes you have to spend
$10 in $1 charges to get an address match because the customer doesn't
type the address in exactly as it is on the bill!. As we say here, "no
coffee for you tomorrow morning!!"
GlenB
Then of course you have the dumbos that refuse to accept a PO Box as an
address even if you go to the trouble of putting it on the second line.say
Ed Kookie Byrnes
77 Sunset Strip
PO Box 94
Yes my address on cards is a PO Box and yes the post office want the box on
the envelope not the street address for a delivery and yes the carriers do
not come up the road but leave parcels at - you guessed it - the post
office.
Funnily enough Amazon manage to get it all correct with one key billing as
well so it is possible.
Peter McMurray |
|
|
| Back to top |
|
|
|
| GlenB... |
Posted: Tue Nov 10, 2009 7:03 am |
|
|
|
Guest
|
On Nov 9, 6:56 pm, "Peter McMurray" <excalibu... at (no spam) bigpond.com> wrote:
Quote: snip
wasting my time, I will have lost all profits on the order.
GlenB
You're doing this manually? Why couldn't you code software to wait
for a response, and if it gets a no match to automagically email back
the customer, etc. Why do you have to be involved in a purely
automatic task like that?
Will- Hide quoted text -
- Show quoted text -
Because sometimes it's how the numbers are to appear in the address
and also the fact that periods "." are considerd a number in the Vital
address validation service. What a PITA. Sometimes you have to spend
$10 in $1 charges to get an address match because the customer doesn't
type the address in exactly as it is on the bill!. As we say here, "no
coffee for you tomorrow morning!!"
GlenB
Then of course you have the dumbos that refuse to accept a PO Box as an
address even if you go to the trouble of putting it on the second line.say
Ed Kookie Byrnes
77 Sunset Strip
PO Box 94
Yes my address on cards is a PO Box and yes the post office want the box on
the envelope not the street address for a delivery and yes the carriers do
not come up the road but leave parcels at - you guessed it - the post
office.
Funnily enough Amazon manage to get it all correct with one key billing as
well so it is possible.
Peter McMurray
I'm not sure what you are trying to accomplish with the street/
box combo. That regularly causes us grief because PO box zips are
never street zips. That breaks the typical validation mech. Instead,
use the PO box as your main card billing address. Call the issuing
bank and ask to add an authorized shipping address. That will be your
street address or any other address you regularly ship packages to.
When validation is done on both addresses, there will be no
conflicting data.
Glen.mobile |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Wed Nov 25, 2009 4:28 am
|
|