Here's what I see for problems with order entry being offline (see
below). Obviously I haven't done order entry they way you are thinking
about it, so maybe I have a completely different scenario.
1) One of the first steps would be to get a unique order number that
wont clash with the other 100 order takers. Sure I can delay the
creation of that until I am connected, but if I am on the phone with a
customer then they are going to want some sort of reference number
*before* we hang up. I have played the game of "you have this number
range that nobody else will pull from" but that is kludgy IMO.
2) Customer on phone wants to order a pink hat. If they don't have the
sku number I need to prompt. There's no way I am going to download the
entire ITEMPF table *and* associated tables to the users PC - that's a
lot of data. What about calculating the price for that item? What if the
business is more than pick'n'pack and there's configuration?
3) I need to check and see if the item is in stock which requires up to
the minute real-time data. I also need to commit my order so inventory
can be deducted *before* somebody else orders and all the sudden we have
orders but not enough product.
I could go on, but you get my idea. In your scenarios what data would
you actually be attempting to store locally?
Your thinking that the application has to be centrally controlled or maintained, that it has to live where the database lives. It doesn’t have to, but it can, or you can have both.
I think the programming effort to NOT have them (app and DB) live in a
connected state (doesn't have to be on the same server) would prove to
be lengthly to build to the point of not enough ROI.
>I understand that's an issue, but people working in technology are
asked to solve problems, not dictate how things should be done because
of any particular technical view they might have about how things
"should be".
We are also asked to develop applications for the long term that scale
well, maintain well, debugged easily, etc. Users would love to be able
to work from home and do orders even when the construction crew down the
street cut through their DSL line, but in reality it is more of an
infrastructure issue where the problem could be solved just by rerouting
calls.
With the proliferation of wireless networks at most coffee shops (and
even McDonalds in MN) I just can't see why an offline ERP type app is a
necessary thing. Again, the offline approach is great for things that
have more to do with that personal user, but outside of that I think we
are just wasting time trying to find a problem for a "solution".
I am all for thinking out of the box, but I am just not following your
line of reasoning for apps like order entry.
Aaron Bartell
http://mowyourlawn.com
Evan Harris wrote:
Hi Aaron
Any application could potentially operate this way - for instance you might
want to create orders (or any kind of transaction) off line and then upload
them when you are connected again. You might want to get some base data
files and then do some reporting or presentation of data. With the amount of
local storage available now you can have any number of local lookup tables
to support a disconnected app.
Your thinking that the application has to be centrally controlled or
maintained, that it has to live where the database lives. It doesn’t have
to, but it can, or you can have both.
I am guessing your next comment will be along the lines of database
synchronization and maintaining data integrity in the face of a distributed
environment. I understand that's an issue, but people working in technology
are asked to solve problems, not dictate how things should be done because
of any particular technical view they might have about how things "should
be".
If you can't see it, then cool. But consider this: way back in the day
people considered PC's a waste of time; moving the apps out this way seems
like a natural extension of this at one level, at another level it's déjà
vu.
FWIW I am not commenting on what is necessarily best or right, just what I
think I see starting to emerge.
Regards
Evan Harris
midrange.com
