Approving user account.

[SkipDever]

In my wonderings through the ofbiz code, I have noted that
availableToPromiseTotal for items on an order is not reduced until
createOrder is called.  I expected availableToPromiseTotal to be reduced
(assuming there was any) when the "Add To Order" button was pressed.

This means that if there are 10 people using your system and 5 want the same
product which has 3 in stock, all 5 will show AOH=3 when they press Add to
Order, but two will get their order rejected when the order is processed.

This is easy enough to change, but I wondered why it was done this way in
case I am missing something.

Skip

[David E Jones]

Most retailers don't consider an add to cart to be sufficient  
commitment on the customer's part to even try to guarantee that they  
will get it. I have actually done stuff like that before, but I  
really wouldn't recommend it because you end up with lots of funny  
exceptions and it is too easy for data to get in bad states, or for  
reservations to never get cleaned up and such. This also puts a lot  
of traffic on certain entities too and can increase chances of  
locking and other concurrency problems.

If you DO want to do this, I would recommend NOT using the current  
availableToPromise counts and the OrderItemShipGrpInvRes records as  
those are meant for something a little different, and a little more  
important to get write (ie reduce chances of interfering with it and  
what what).

-David


On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:

> In my wonderings through the ofbiz code, I have noted that
> availableToPromiseTotal for items on an order is not reduced until
> createOrder is called.  I expected availableToPromiseTotal to be  
> reduced
> (assuming there was any) when the "Add To Order" button was pressed.
>
> This means that if there are 10 people using your system and 5 want  
> the same
> product which has 3 in stock, all 5 will show AOH=3 when they press  
> Add to
> Order, but two will get their order rejected when the order is  
> processed.
>
> This is easy enough to change, but I wondered why it was done this  
> way in
> case I am missing something.
>
> Skip
>

[SkipDever]

Thanks David, I'll use the code as is and see if anyone bitches.  I agree
that the logic is complicated, especially considering that a person can just
exit their browser and leave things hanging.

Skip

-----Original Message-----
From: David E Jones [mailto:[hidden email]]
Sent: Thursday, October 04, 2007 6:21 PM
To: [hidden email]
Subject: Re: availableToPromiseTotal



Most retailers don't consider an add to cart to be sufficient
commitment on the customer's part to even try to guarantee that they
will get it. I have actually done stuff like that before, but I
really wouldn't recommend it because you end up with lots of funny
exceptions and it is too easy for data to get in bad states, or for
reservations to never get cleaned up and such. This also puts a lot
of traffic on certain entities too and can increase chances of
locking and other concurrency problems.

If you DO want to do this, I would recommend NOT using the current
availableToPromise counts and the OrderItemShipGrpInvRes records as
those are meant for something a little different, and a little more
important to get write (ie reduce chances of interfering with it and
what what).

-David


On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:

> In my wonderings through the ofbiz code, I have noted that
> availableToPromiseTotal for items on an order is not reduced until
> createOrder is called.  I expected availableToPromiseTotal to be
> reduced
> (assuming there was any) when the "Add To Order" button was pressed.
>
> This means that if there are 10 people using your system and 5 want
> the same
> product which has 3 in stock, all 5 will show AOH=3 when they press
> Add to
> Order, but two will get their order rejected when the order is
> processed.
>
> This is easy enough to change, but I wondered why it was done this
> way in
> case I am missing something.
>
> Skip
>

[David E Jones]

Abandoned carts are something we already detect, and save the  
contents of to the database for analysis. It is possible to do  
something similar to cancel reservations, but this is one of many  
things that you'll run into that just isn't totally reliable and over  
thousands of operations eventually adds up to lots of work to monitor  
and clean up.

-David


On Oct 4, 2007, at 7:35 PM, skip@theDevers wrote:

> Thanks David, I'll use the code as is and see if anyone bitches.  I  
> agree
> that the logic is complicated, especially considering that a person  
> can just
> exit their browser and leave things hanging.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:[hidden email]]
> Sent: Thursday, October 04, 2007 6:21 PM
> To: [hidden email]
> Subject: Re: availableToPromiseTotal
>
>
>
> Most retailers don't consider an add to cart to be sufficient
> commitment on the customer's part to even try to guarantee that they
> will get it. I have actually done stuff like that before, but I
> really wouldn't recommend it because you end up with lots of funny
> exceptions and it is too easy for data to get in bad states, or for
> reservations to never get cleaned up and such. This also puts a lot
> of traffic on certain entities too and can increase chances of
> locking and other concurrency problems.
>
> If you DO want to do this, I would recommend NOT using the current
> availableToPromise counts and the OrderItemShipGrpInvRes records as
> those are meant for something a little different, and a little more
> important to get write (ie reduce chances of interfering with it and
> what what).
>
> -David
>
>
> On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:
>
>> In my wonderings through the ofbiz code, I have noted that
>> availableToPromiseTotal for items on an order is not reduced until
>> createOrder is called.  I expected availableToPromiseTotal to be
>> reduced
>> (assuming there was any) when the "Add To Order" button was pressed.
>>
>> This means that if there are 10 people using your system and 5 want
>> the same
>> product which has 3 in stock, all 5 will show AOH=3 when they press
>> Add to
>> Order, but two will get their order rejected when the order is
>> processed.
>>
>> This is easy enough to change, but I wondered why it was done this
>> way in
>> case I am missing something.
>>
>> Skip
>>
>
>

[jonwimp]

Skip,

I agree that it really depends on the customer's needs.

Perhaps in your case, the customer absolutely wants a blazing fast GUI, and doesn't want a browser
UI at all. In that case, you'll really only be maintaining one set of GUI codes, the Java GUI app.

All my customers so far want to access OFBiz from "anywhere around the world". So that's a
different case.

 > What is an issue to me is that not only the GUI code, but the Ofbiz Entity
 > Engine code as well is run on the client desktop

I think that's neat. It's still the same Entity Engine, one set of codes to maintain.

Is it that slow? Well, I believe it certainly is slower than raw SQL. Plus, it's written in Java.

Another interesting setup could be this. Have a few load-balanced and clustered servers running
the Entity Engine, and a single OFBiz server running everything else. Might improve performance.
But I'm not sure, like I said, I'm always surprised when it comes to optimization work. Will need
to do some actual measurements first. Is the Entity Engine the bottleneck in OFBiz?

The above setup will allow the rest of us browser UI users to still use browser UIs, and fire off
requests to the "Entity Engine servers". What do you think?

 > I concede that centrally managed code is way better.  So much so that it
 > generally trumps other considerations.  However, from a certain point of
 > view, the client code is still centrally managed provided that any changes a
 > promptly propagated to the desktops.

Yeah, you're right. The key is to "match client code to server code", ie "these versions of client
codes works with those versions of server codes". It's not tough to manage that in SVN. OFBiz's
POS codes is one example.

 > Also, once a GUI is written, it does not (or should not) get changed much.
 > Otherwise, the users face significant retraining costs.

I'm seeing small additive changes very often. Customers want a couple of new fields every week!
Also, they want to compact the UIs every now and then (driven by end-user feedback), and that will
not incur retraining costs. Making the UI simpler and more intuitive to use won't incur retraining
costs.

Those small changes are cheap to do if I just have to manage a single set of UI codes --- the
browser UI codes. Customers almost always want to tweak the paint job on quite a regular basis if
it doesn't cost too much to do so. The only thing stopping them is if I say "that field will cost
you another $5000".

 > I don't view this a swing back.  It is no different in concept than a java
 > applet.  In fact, it could be implemented as an applet.  It's just that it
 > would be a BIG applet, so may as well be an application deployed on the
 > desktop.

No, it's not a swing back if you're still maintaining only a single set of UI codes --- the Java
GUI app. If you've chosen to use Java (SWT or applet) for your UI, it's as good a choice as
HTML/AJAX. Java/SWT and HTML/AJAX are merely UI toolkits, both equally viable (the latter less
responsive).

Hey, back to the CRM thing. Isn't there a standard set of CRM features that the market wants to
see? Should we do something like that?

Jonathon

skip@theDevers wrote:

> Jonathon
>
> I agree, nice discussion.
>
> On point one, I agree, IT folks cost way more.  But, you make a value
> judgement at the outset.  If you are writing an application that will be
> used by one to save $3000; not a good idea.  But, if it will be used by 5
> and takes you two months, great ROI.
>
> As you know, know, java byte code is JIT compiled to the local machine and
> in my testing is about 20% slower than raw C++.  Way better than interpreted
> Javascript.  But, I concede, on modern machines, it is not an issue.  What
> is an issue to me is that not only the GUI code, but the Ofbiz Entity Engine
> code as well is run on the client desktop.  Only the database server runs
> elsewhere.
>
> I concede that centrally managed code is way better.  So much so that it
> generally trumps other considerations.  However, from a certain point of
> view, the client code is still centrally managed provided that any changes a
> promptly propagated to the desktops.
>
> Also, once a GUI is written, it does not (or should not) get changed much.
> Otherwise, the users face significant retraining costs.
>
> "While a full Java app is fast enough for trigger-happy trigger-efficient
> backoffice personnel, it
> might be too expensive a swing in the pendulum. Yes, end-users did suffer
> when we swung from
> user-friendliness to IT savings. But should we now swing so vehemently back
> to user-friendliness
> (with Java client app), and move so far away from IT savings?"
>
> I don't view this a swing back.  It is no different in concept than a java
> applet.  In fact, it could be implemented as an applet.  It's just that it
> would be a BIG applet, so may as well be an application deployed on the
> desktop.
>
> Also, I don't work for a particular company.  I would expect my work to be
> used by many, so the ROI increases with each installation.
>
> I see room for both methods depending on the customers' needs.
>
> Skip
>
> -----Original Message-----
> From: Jonathon -- Improov [mailto:[hidden email]]
> Sent: Wednesday, October 03, 2007 11:25 PM
> To: [hidden email]
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>
>
> Hey Skip,
>
> Nice discussion. :)
>
>  > 1.  Backoffice personell are expensive.
>
> I was thinking more in terms of IT department savings. The
> "create/maintain/deploy" human
> activities can be quite a bit more expensive (IT consultants) than
> backoffice personnel, I would
> think. Is that the case where you are?
>
> Still, saving manpower is always good. AJAX (and Web 2.0) technology came in
> to correct the
> pendulum swing, the swing from saving backoffice manpower (or end-users) to
> saving IT manpower.
> Yes, usability and end-user experience did suffer when the IT folks tried to
> save on the
> "create/maintain/deploy" side of things.
>
>  > It takes 20 seconds less on simple orders (Finalize with defaults) and 45
>  > seconds less with complicated ones using the Java app.
>
> I had similar savings with AJAX. It's not so bad, really. After all, AJAX is
> done with javascript,
> and javascript is done with...? C/C++ or something similarly tight. The
> parser and runtime is in
> the browser itself! Now, where does Java stand in comparison? :)
>
> I would imagine that your Java GUI app does trim and quick server calls (for
> quick
> synchronization) to the server. That's what AJAX does too.
>
>  > I know I can achieve the same effect with ajax, but if I have to write
> these
>  > apps from scratch anyway, why not take advantage of the extra horsepower
> and
>  > compiled Java?
>
> Because AJAX is still part of "server codes" (served up by server), so you
> can manage them
> centrally. Java client codes (GUI mostly?) is separated from server codes
> (separately installed on
> client). AJAX is coded as part of HTML pages served up by "server codes".
>
> While a full Java app is fast enough for trigger-happy trigger-efficient
> backoffice personnel, it
> might be too expensive a swing in the pendulum. Yes, end-users did suffer
> when we swung from
> user-friendliness to IT savings. But should we now swing so vehemently back
> to user-friendliness
> (with Java client app), and move so far away from IT savings?
>
>  > With Ofbiz code doing the grunt work, I can spend my time making the GUI
>  > fast, easy, and smart.
>
> Actually, that business model does work. GUI is everything to customers or
> end-users. Some
> customers will pay a lot just to have GUIs they like. However, most
> customers I know are
> cost-conscious, and won't want to pay for a Porsche paint job if they can
> get a cheaper and still
> effective GUI that works.
>
> If your customer is willing to pay lots for future maintenance of Java GUI
> app, browser GUI
> modules (OFBiz widgets and such), and OFBiz backend modules, then sure, have
> fun doing all that
> maintenance.
>
> Eg scenario: "Did you change the UI like I wanted?"... "Yes, I did"... "I
> see it only in the
> browser GUI modules"... "I'll do it in the Java GUI module too, sorry I
> forgot"... "Make sure you
> do the change exactly, I want the change to be precisely uniform and
> consistent".
>
>  > 2.  "Also, the move forward is to "dumb down" the client terminals (cheap
> to
>  > deploy, scalable)."... Witness the move to Ajax backed Javascript as an
>  > example.
>
> "Dumbing down" client terminals means we don't have to "teach" (install)
> those terminals too much.
> The point is to be able to acquire any computer (new or old), and still be
> able to run the app and
> hit the server, without having to "teach" or install much to those
> terminals.
>
> AJAX is part of the browser. Browser adoption rates are driven by browser
> competition, not by our
> own Java GUI development team. With browser adoption moving along healthily,
> we can do away with
> our Java GUI development team (reassign).
>
>  > It takes almost no time to code a GUI with Netbeans.
>
> In software development, the biggest headaches isn't about getting something
> coded. It's about
> collaboration between IT teams, collaboration between software components
> (in your case, server
> and client components). And the need for such collaboration is so strong,
> version control
> mechanisms were born, and honed by now.
>
> Take this DocBook example (since there was a recent mention of DocBooks
> somewhere). DocBook is
> plain text format, and can be automatically converted into OpenDocument
> format (MS Word equivalent
> in OpenOffice). OpenDocument format is binary. Suppose I write a huge book
> using OpenDocument
> format, and I make some changes. I would have to send a new complete binary
> of the whole book to
> my publisher. But with DocBook's plain text format, plus version control, I
> only need to send a
> small diff to update (collaborate with) my publisher.
>
> More than 10 years back, I remember a time when we used MS Word documents
> for functional specs.
> Lots of protocols then for change management, under project management. For
> every change in the
> specs documents, a "changelog" section needs to be carefully and
> painstakingly updated. In
> reality, there were many "carefully and painstakingly" crafted errors in
> those "changelog"
> sections. We're just humans. There was simply no way to do a "diff" for MS
> Word docs.
>
>  > No such tools currently exist (that I know of) for Ajax backed apps.
>
> It may take some time for AJAX frameworks to compete and crystallize some
> standards. Or has that
> already happened? Still, it isn't difficult to do AJAX. It's almost standard
> by now.
>
>  > 4.  "In production, servers aren't hit all the time. There are peak
> periods,
>  > and there are lull periods."  If the brains are on the user's desktop,
> there
>  > are no lull or peaks at any time (and no associated aggravation).  Their
>  > work is never interrupted or slowed (assuming the database server is not
>  > overloaded.)
>
> Even if you put the Java GUI app on the client terminals, you'll still need
> to handle peak periods
> on the server codes. If you're already doing clustering and load-balancing
> on the server side, you
> might as well do it there only, and gain the benefit of "easier control"
> (only a few servers,
> platforms and setups you can control).
>
> If you're thinking of executing business logic codes on the client
> terminals, you face the
> additional risk of such codes running differently on different terminals. We
> never know. Sun SDK
> could run a tad different on some setups. There'd be so many different
> setups or platforms to
> cater for, the cost of maintenance could increase exponentially.
>
> To fix that problem, you could mandate a uniform setup for all client
> terminals. So, if the top
> boss wants a newfangled 128-bit computer, and still wants to run your Java
> GUI app, would you be
> able to tell him "Sir, you gotta get with the program because Sun SDK won't
> run with 128-bit"? :)
>
> Using only browsers as the client app, the responsibility to "cater for
> various platforms" falls
> on the browser developers instead.
>
>  > 5.  "Those folks writing the "offloading algorithms" won't know how
> fast/slow
>  > my computer is."  Gads Jonathon, I couldnt agree more.  I get aggravated
>  > daily waiting for Javascript intensive web pages to download.  However, I
> am
>  > not running javascript, but blazingly fast compiled Java.  If the user's
>  > machine doesnt have the guts, I wouldn't install Ofbiz on it.  They can
> use a
>  > browser to access the same funcionality.
>
> Then you'd have double the maintenance responsibility.
>
> You not only have to maintain the server codes that servers up GUI via
> browser, you also have to
> maintain the Java GUI app.
>
> Finally, you may argue that javascript is just too difficult to handle (I
> hate it too). Browsers
> might deal with javascript so differently (or even wrongly at times). You
> could consider mandating
> that every dumb terminal installs a new browser (the winner then). The best
> browser out there will
> be a cinch to install. There's ready support for the browser. Many great
> browsers are now free,
> even opensource. Will your Java GUI app be able to compete with the polish
> that goes into browser
> development and support?
>
> Jonathon
>
> skip@theDevers wrote:
>> Johathon
>>
>> Hmmm, you've almost got me convinced to give this up.  So convinced in
> fact
>> that I am gonna forward this email on to my current customer and get his
>> reaction.  It's well thought out and you obviously spent a great deal of
>> time thinking about it and I thank you for it lavishly.
>>
>> Still, I have these arguments in favor to offer:
>>
>> 1.  Backoffice personell are expensive.  Even saving them 10 minutes
> (that's
>> 10 seconds a transaction or less) a day translates to $3000 a year even
> for
>> the lower paid ones, and this is per-person.  I have timed myself using
> the
>> Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java
>> based order entry application I am currently finishing.  The results?  It
>> takes 20 seconds less on simple orders (Finalize with defaults) and 45
>> seconds less with complicated ones using the Java app. And, all my code is
>> using the stock Ofbiz services to do the real work so it's fairly simple
> to
>> write.  The difference in time is because I can change the control having
>> the input focus intelligently and I don't have to wait for brower repaints
>> between atomic operations.  A fast operator can go as fast as they can
> type.
>> I know I can achieve the same effect with ajax, but if I have to write
> these
>> apps from scratch anyway, why not take advantage of the extra horsepower
> and
>> compiled Java?  By the way, the nearly finished Java app is surprisingly
>> small.  With Ofbiz code doing the grunt work, I can spend my time making
> the
>> GUI fast, easy, and smart.
>>
>> 2.  "Also, the move forward is to "dumb down" the client terminals (cheap
> to
>> deploy, scalable)."  I would partially disagree with this although it is
>> repeated a lot.  This was certainly true a couple of years ago, but
> lately,
>> we are heading back in the other direction.  Witness the move to Ajax
> backed
>> Javascript as an example. It takes almost no time to code a GUI with
>> Netbeans.  No such tools currently exist (that I know of) for Ajax backed
>> apps.  Also. go look at the sales stats for Dell and HP and you will see
>> that the  majority of their sales are to business and it shows no signs of
>> slowing (although it is not increasing as fast as it was a few years ago).
>>
>> 3.  "Even if the client terminals just happen to be blazing fast enough
> for
>> graphics-intensive work...".  Graphics-intensive capability is more a
> factor
>> of the video card than the CPU.  EVERY desktop I see with an A/R or A/P
>> person in the chair is capable of running Ofbiz, Word and Excel at the
> same
>> time.  On my test box, I have Ofbiz running with Netbeans, Visual Studio,
>> Gaim, and Outlook and it's no smoker and joker.
>>
>> 4.  "In production, servers aren't hit all the time. There are peak
> periods,
>> and there are lull periods."  If the brains are on the user's desktop,
> there
>> are no lull or peaks at any time (and no associated aggravation).  Their
>> work is never interrupted or slowed (assuming the database server is not
>> overloaded.)
>>
>>
>> 5.  "Those folks writing the "offloading algorithms" won't know how
>> fast/slow my computer is."  Gads Jonathon, I couldnt agree more.  I get
>> aggravated daily waiting for Javascript intensive web pages to download.
>> However, I am not running javascript, but blazingly fast compiled Java.
> If
>> the user's machine doesnt have the guts, I wouldn't install Ofbiz on it.
>> They can use a browser to access the same funcionality.
>>
>>
>> Hmmm, now I've almost convinced myself to carry on. :)
>>
>> Cheers
>>
>> Skip
>>
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:[hidden email]]
>> Sent: Wednesday, October 03, 2007 7:43 PM
>> To: [hidden email]
>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>
>>
>>  > You might be surprised by how expensive such a solution would be to
>>  > create/maintain/deploy and how little it will help on server resources.
>>
>> I have many clients wanting to move away from that distributed (client
>> codes) model to the
>> centralized (server codes) model. Yes, it is proving to be expensive.
> Kinda
>> "tried and tested" to
>> be expensive, actually.
>>
>> "Create/maintain/deploy" are all human activities. Will be inordinately
>> expensive to create
>> artificial intelligence to do all that. In general (with our current
>> state-of-the-art of AI), it
>> is cheaper to simply upgrade the server hardware. Yes, computer hardware
>> speed improvement may be
>> slowing down now (used to be doubling every 1.5 years?). But there will
>> surely be something new
>> coming up (quantum computers, multi-state logic units, etc), unless we're
>> suddenly hit by an
>> epidemic that halves human intelligence every 1.5 years. (Or I infect all
>> you guys with my stupidity).
>>
>> Also, the move forward is to "dumb down" the client terminals (cheap to
>> deploy, scalable). Even if
>> the client terminals just happen to be blazing fast enough for
>> graphics-intensive work, perhaps
>> those terminals' users' job scope is to do graphics-intensive work on a
>> regular basis? Putting a
>> part of OFBiz into those machines will compromise the efficiency of their
>> graphics-intensive work.
>>
>> As for "You might be surprised", I'm ALWAYS surprised when it comes to
> doing
>> optimization work!
>> Optimization needs are very hard to calculate and predict by hand. Rather
>> than spend weeks using
>> complex maths and theories to predict (presume, rather) bottle-necks, it's
>> easier to spend a
>> couple of hours to do an actual measurement of computation speeds.
>>
>>  > You might also be surprised by how capable servers are of handling
>>  > concurrent load, how different performance tends to be in a development
>>  > versus production environment, and for certain things how easy it is to
>>  > tune them once the slowest stuff has been identified.
>>
>> In production, servers aren't hit all the time. There are peak periods,
> and
>> there are lull
>> periods. To handle such cases, clustering and load-balancing is the usual
>> practice. The diff
>> between clustering servers and using smart client terminals, both being
>> distributed models, is
>> this... it's easier to monitor and tune a few servers than to do so for
>> hundreds of client terminals.
>>
>> Also, consider how irritating javascript is getting to be, those that try
> to
>> offload huge amounts
>> of servers' workloads into our personal computers. Those folks writing the
>> "offloading algorithms"
>> won't know how fast/slow my computer is, and could render my computer
>> completely useless by
>> overloading it.
>>
>> But before going into clustering, it is often adequate to spot the
>> bottle-necks in a single
>> server, and optimize just those areas. That'll help the OFBiz framework
> and
>> help the OFBiz
>> community too.
>>
>> For all the optimization smarts we have, I must say that I had
>> over-optimized before in my career.
>> In business, over-optimizing a system isn't "passing with flying colors",
>> but actually translates
>> into a loss. While it is great to "push the envelope", it'll help in
> thesis
>> writing more than in
>> business. Study the bottle-necks in production settings, and fix just
> those.
>> Still, please feel free to over-optimize the OFBiz framework! That's a
>> different scenario. Huge ROI.
>>
>> Jonathon
>>
>> David E Jones wrote:
>>> You might be surprised by how expensive such a solution would be to
>>> create/maintain/deploy and how little it will help on server resources.
>>> You might also be surprised by how capable servers are of handling
>>> concurrent load, how different performance tends to be in a development
>>> versus production environment, and for certain things how easy it is to
>>> tune them once the slowest stuff has been identified.
>>>
>>> -David
>>>
>>>
>>> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>>>
>>>> David
>>>>
>>>> This issue here to me asset utilization.  In a typical mid-sized
> company,
>>>> there are dozens or hundreds of desktop computers that their user use
>>>> to do
>>>> their daily work.  If the user is using a browser to access logic on
>>>> one of
>>>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>>>> application to Ofbiz (i.e. running an entity engine on the desktop
>>>> tied to
>>>> the same database as the main ofbiz servers and running xml setups
>>>> identical
>>>> to the servers), that workload is performed on the users desktop and
>>>> not on
>>>> the main ofbiz servers thereby freeing the server for functionality that
>>>> REQUIRES browser based access.
>>>>
>>>> This does not in any way supplant Ofbiz, it enhances it by
>>>> distributing the
>>>> workload and giving the clerical user a better amd more responsive
>>>> experience.
>>>>
>>>> As some examples, my recent testing of the sales order functionality
>>>> shows
>>>> that it takes ~ 200 msecs to complete the "userLogin" service or 120
>>>> msecs
>>>> to complete "calculateProductPrice" (these numbers are from the ofbiz
> log
>>>> file on a fairly fast machine with lots of debug output).  If this is
> all
>>>> done on the main ofbiz servers about 5 of the former and 10 of the
>>>> later can
>>>> be done simultaneously to maintain a reasonable lag time.  If the load
> is
>>>> spread out among say 8 desktops and 2 browser accesses, everyone has a
>>>> really good experience.
>>>>
>>>> The only drawback to this all is that if the server configuration
>>>> changes,
>>>> the desktops must be patched as well.  In practice, that is not a big
>>>> issue.
>>>>
>>>> So, it makes great sense to me to write desktop applications for common
>>>> backoffice functions.
>>>>
>>>> I am currently working on a suite of such applications, hence my
>>>> interest in
>>>> BJs SWT based CRM.
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: David E Jones [mailto:[hidden email]]
>>>> Sent: Wednesday, October 03, 2007 11:12 AM
>>>> To: [hidden email]
>>>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>>>
>>>>
>>>>
>>>> I'm not sure where this thread is leading or how it's related to
>>>> OFBiz...
>>>>
>>>> In any case, there is CRM functionality in OFBiz. The first step
>>>> would be defining in a little more detail what you mean by "CRM"
>>>> since that means very different things in different companies. OFBiz
>>>> does offer a single view into customer interactions including web
>>>> site visits, phone/email/in-person/etc communications, requests,
>>>> quotes, orders, shipments, invoices, payments, balance accounts,
>>>> projects, calendar events, and many other things. You can also
>>>> classify parties for marketing and sales, and do things like
>>>> marketing campaigns including reference codes via email, snail mail,
>>>> whatever.
>>>>
>>>> If you're looking for simple desktop contact management something
>>>> like ACT or even salesforce.com would be better. If you're looking
>>>> for enterprise CRM (especially a business or industry specific
>>>> incarnation of such) then OFBiz a great basis for the effort.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>>>
>>>>> I'd like to see the SWT code as it is.  To heck with translating it
>>>>> to use
>>>>> web based widgets.
>>>>>
>>>>> I gotta set up a web site soon to hold code like this.
>>>>>
>>>>> Skip
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:[hidden email]]
>>>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>>>> To: [hidden email]
>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>> OFBiz
>>>>>
>>>>>
>>>>> basically yes.
>>>>> the tool i used added some classes to better manage things.
>>>>> http://www.elance.com/p/?
>>>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>>>> 182#tab=1
>>>>> click on Java CRM
>>>>>
>>>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>>>> BJ
>>>>>>
>>>>>> SWT as in Eclipse SWT?
>>>>>>
>>>>>> Skip
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: BJ Freeman [mailto:[hidden email]]
>>>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>>>> To: [hidden email]
>>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>>> OFBiz
>>>>>>
>>>>>>
>>>>>> there at least two efforts going that i know of.
>>>>>> the data model pretty much has all that you need.
>>>>>> Si's implementation does not totally integrate with the current data
>>>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>>>> Once I figure out how to show the UI I want in widgets I will release
>>>>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>>>>> It is built entirely within the current ofbiz datamodel.
>>>>>> as soon as I get some irons of the fire will focus on it more
>>>>>>
>>>>>>
>>>>>>
>>>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>>>> Thanks for your input relating my previous questions, I am
>>>>>>> interested in
>>>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>>>> in what
>>>>>>> facilities OFBiz already has
>>>>>>>
>>>>>>> Thanks
>>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>
>>
>
>
>

[jonwimp]

Agreed. The field availableToPromise should only be updated when an actual commitment is made.

Same for inventory reservations.

Question is, will the availableToPromise field, if value is 1, be put into negative value when a
few customers do an "add-to-cart" at the same time, and then check out at the same time? I think
not. A simple race should settle it, and decide which customer gets the single available item.

For inventory reservations, I think an exception is thrown during order creation if the inventory
is no longer available to be reserved. That is, if it is somehow taken away between "add-to-cart"
and "order creation".

Jonathon

David E Jones wrote:

>
> Most retailers don't consider an add to cart to be sufficient commitment
> on the customer's part to even try to guarantee that they will get it. I
> have actually done stuff like that before, but I really wouldn't
> recommend it because you end up with lots of funny exceptions and it is
> too easy for data to get in bad states, or for reservations to never get
> cleaned up and such. This also puts a lot of traffic on certain entities
> too and can increase chances of locking and other concurrency problems.
>
> If you DO want to do this, I would recommend NOT using the current
> availableToPromise counts and the OrderItemShipGrpInvRes records as
> those are meant for something a little different, and a little more
> important to get write (ie reduce chances of interfering with it and
> what what).
>
> -David
>
>
> On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:
>
>> In my wonderings through the ofbiz code, I have noted that
>> availableToPromiseTotal for items on an order is not reduced until
>> createOrder is called.  I expected availableToPromiseTotal to be reduced
>> (assuming there was any) when the "Add To Order" button was pressed.
>>
>> This means that if there are 10 people using your system and 5 want
>> the same
>> product which has 3 in stock, all 5 will show AOH=3 when they press
>> Add to
>> Order, but two will get their order rejected when the order is processed.
>>
>> This is easy enough to change, but I wondered why it was done this way in
>> case I am missing something.
>>
>> Skip
>>
>