RE: framework question

[CWilt@xxxxxxxxxxxx]

> 
> > From: CWilt@xxxxxxxxxxxx
> > 
> > It seems to me that in the real world, whatever class did 
> the pricing
> > would
> > already need to know about customer.  Off the top of my 
> head, I'd have
> > pricing method in the Invoice class or an InvoiceItem 
> component class
> of
> > Invoice.
> 
> This would be pretty useless if I were trying to get a price for, say,
> standard pricing of work in process.  Have you ever actually coded a
> pricing system?  I have.  It's a lot more complex than just 
> figuring out
> the price at invoice time.  There's also quotes, 
> requisitions, purchase
> orders, RMAs, not to mention the various material pricing 
> done for WIP.
> 

Yes in fact I have coded a pricing system.  My example was looking at a
simple distributor type environment.  Seemed like what we were talking about
given the " real world where you have hundreds, thousands or even millions
of individual items"  I can think of very few manufactures who make hundreds
of individual items let alone thousands or millions.

As far as calculating the price at "invoice time".  Depends on your
definition of "invoice time" I suppose and rather you've got separate Order
and Invoice classes and the properties of those classes.  Are they two
completely separate things?  Is one a component of the other?  In any event,
lets just say pricing is done in the class that holds the detail of what is
being purchased.  Be it named Order, Invoice, whatever.

Returns and quotes would most likely be specialized types of that class.
The pricing routines wouldn't need to change.  Some of the other routines
would of course.


> 
> > Suddenly you have absolutely no way of knowing how prices should be
> and
> > are being calculated without digging into the code.
> 
> Same with OO.  In your case, someone would have to guess 
> which class the
> pricing actually was in, since you don't follow normal OO 
> strategy where
> the attribute belongs to the object, and you just kind of put things
> where you see fit.  So now I have to know that your pricing 
> is done in a
> class called InvoiceItem, which is a component class of 
> Invoice.  Yeah,
> that's intuitive.

But Joe the actual selling price of an item isn't an attribute of the item.
The item's list selling price certainly may be.  But the actual sell price
for an item only exists in the real world when somebody actually purchases
some quantity of the item.  Thus, the actual sell price is going to have to
be in a class that knows who, what, when and how many are being purchased.

So it makes perfect sense and completely follows OO strategy.

> 
> 
> ? What happens next month or
> > next year, when the guy orders the same product and pays 
> 10% more for
> it.
> > He calls in wondering why.  The customer service people check, well
> > there's
> > been no price change to the product, it wasn't on special, and your
> terms
> > haven't changed.  Guess well have to call IT and see if they can
> figure
> > out what the dammed AS-400 is doing now.
> 
> This is a procedural issue that needs to be worked out for any
> circumstance.  But in MY environment, the CS people would be calling a
> pricing server, so they'd get the same price as the invoice.  They may
> not know WHY the price is that way, but again, that's a procedural
> issue.  If it were necessary for someone to know that, one would place
> the annotation in the customer notes file.

You're missing the point.   The point being if your system had a properly
implemented method of giving customer special deals like this.  Then the CS
people would hopefully be able to see records of the fact that the customer
was being given 10% off anything he hadn't bought before.  Even if it was a
month ago and for only one day.

Instead, the CS people don't have anything to tell the customer except that
they don't see any reason for the difference and that it must be a computer
problem.

> 
> 
> > How do you answer your auditors when they ask you how a customer's
> price
> > is
> > calculated?  "Well, that depends on what day and what 
> customer it is."
> 
> Why yes, that's exactly what I'd say.  As well as "how much have they
> ordered in this shipment, how much have they ordered this 
> year, whether
> they have negotiated split pricing with another item, whether 
> they have
> preferred customer pricing, and whether this due to a special
> consignment."  Not to mention whether or not Ed in sales closed a
> special deal with this customer that they can buy at a 15% discount if
> they but 5000 units this month.

Again you're missing the point.  It's not that the price itself changes or
you offer special deals.  There's a significant difference between telling
the auditors "We use the customer's pricing plan along with the list cost or
list sell to determine base price of the item.  Then we take into account
contracts listed in these files and special deals from these files."  And
telling the auditors "Well, gee it depends on the day and the customer.  Let
me see if I can find a copy of the source code from that day to tell you
what we did."


> 
> 
> > If you really don't see any kind of a problem with that if statement
> > Joe...perhaps we do have completely different ideas of what
> programming is
> > all about.
> 
> We sure do.  It seems that for you programming is about modeling
> theoretical problems into an elegant solution space.  For me,
> programming is about making the client's business work.
> 
> Joe
> 

Not quite Joe.  You are apparently an old-time hack programmer from way back
whose only coding criteria is does it work, was it quick to do, and did I do
it in RPG.

I on the other hand prefer to engineer a  proper solution to a customers
business problem that will provide the flexibility they need now and in the
future.  Very little I do is theoretical Joe.


Now we can continue with the snide personal comments, we can drop the
thread, or we can continue the discussion.  It's up to you Joe.


Charles