"Dino Hsu" <dino1_at_ms1.hinet.net> ¼¶¼g©ó¶l¥ó
news:8vnbmf$5chhh$1_at_ID-41926.news.dfncis.de...
> Gregory,
>
> Thanks for your good points. I would like to sketch more characteristics
of
> it:
> 1.The users have the choice of going on-line, using the web-based order
> placement system or going off-line, accumulating the orders locally and
> sumbmitting them later when going on-line again.
> 2.We wish the on-line and off-line user interface should be as similar as
> possible.
> 3.The replication of the local databases and the headquarter database can,
> hopefully, be taken care of automatically. Because otherwise the programs
on
> both sides have to do import/export kind of stuffs, which are what we did
> before and it came out to be much more difficult to maintain.
> 4.Order status are feedbacked to the users later after the orders are
> processed or, say, the goods are delivered.
> 5.The users need to see the total prices, the discounts they have, and the
> gifts they got immediately. Unfortunately we have very complicated offer
and
> incentive programs, as well as frequently updated promotion campaigns (18
> times per year). The information of customers (basic contact, incentive
and
> offer-related information, accumulated sales amount, etc.), products,
> offers, and even programs have to be updated on every campaign change.
These
> complicated billing functions should be shared among the on-line and
> off-line programs.
> 6.One important thing is that we have other order channels as well: fax,
> mail, telephone call, voice response, etc., all channels should be
> consolidated at the headquarter and updated back to channels with as
little
> time lag as possible.
> 7.This system will also be connected to real-time inventory and different
> levels of sales reports.
> From all of the above, I hope you can understand why we are searching for
> technical solutions about on-line/off-line and auto-replication
> functionalities.
> Any comments are highly appreciated.
>
> Regards,
> Dino
> "Gregory M. Sliker" <gsliker_at_lightstream.net> ¼¶¼g©ó¶l¥ó
> news:E4vT5.1581$d3.68112910_at_news.axxsys.net...
> > It seems like this has more to do with "where" order data is stored than
> > what the capabilities of a particular language has to offer, (Java or
CGI
or
> > ASP). When a user clicks a Submit Order button the data needs to go
> > somewhere, a database back at the office or a local database or even
just
a
> > text file on the user's machine. When connected to the internet you
check
> > for the existence of the file or new rows in the local database and if
> > present, export the data in it to the office database. Once the rows
are
> > commited I would then delete the file or delete the rows in the local
> > database, (it's always nice to clean up after ourselves). Regardless of
how
> > you want to store the data for an order it should be totally transparent
to
> > the user, with the possible exception of an indicator that states if
they're
> > connected or not.
> >
> > HTH,
> >
> > Greg Sliker
> >
> > "Dino Hsu" <dino1_at_ms1.hinet.net> wrote in message
> > news:8vjblf$47ifl$1_at_ID-41926.news.dfncis.de...
> > > Dear all,
> > >
> > > I am not sure whether this is the right group to post, I hope it's
right.
> > > There are hundreds of zone managers who will place orders in their
home,
and
> > > we want to develop an order-placement application for them, leveraging
the
> > > new web technology. Hoever, this program should be able to provide
off-line
> > > order placement and on-line data exchange (replication), because they
cannot
> > > afford the cost of being always on-line.
> > > As far as I know about Java or CGI or ASP database applications, they
are
> > > basically on-line programs, but we do need an on-line/off-line 2-way
> > > solution. Can anyone give one's precious comments? Thanks in advance.
> > >
> > > Regards,
> > > Dino
> > >
> > >
> > >
> >
> >
>
>
Received on Fri Nov 24 2000 - 21:48:12 CST
