Commission Database Examples/Experience or Suggestion on creating database

[di]

Does anyone have any recommendations on Examples or experience on
creating a multilevel commission in Access Database. I realize
this can be a very complicated set up so would like some advise.
Thanks

[Alan Webb]

Di,
If they are still around, there was AgainTech's CompSense package which was
started as an Access 2.0 database. I'd analyse the problem as a data
warehouse, looking for my measured fact(s)--commision dollars on sales
dollars to start with, and dimensions, one of which would be my heirarchy,
another is likely to be time, a third probably personnel, and any others
that are needed. The biggest issue would be identifying the grain of fact
needed. From there the rest is fairly straightforward DBA & Systems
Analysis stuff.

"di" <di******@chart er.net> wrote in message
news:9b******** *************** ***@posting.goo gle.com...

Does anyone have any recommendations on Examples or experience on
creating a multilevel commission in Access Database. I realize
this can be a very complicated set up so would like some advise.
Thanks

[Pieter Linden]

"Alan Webb" <kn*****@hotmai l.com> wrote in message news:<cY******* *************@c omcast.com>...

Di,
If they are still around, there was AgainTech's CompSense package which was
started as an Access 2.0 database. I'd analyse the problem as a data
warehouse, looking for my measured fact(s)--commision dollars on sales
dollars to start with, and dimensions, one of which would be my heirarchy,
another is likely to be time, a third probably personnel, and any others
that are needed. The biggest issue would be identifying the grain of fact
needed. From there the rest is fairly straightforward DBA & Systems
Analysis stuff.

"di" <di******@chart er.net> wrote in message
news:9b******** *************** ***@posting.goo gle.com...

Does anyone have any recommendations on Examples or experience on
creating a multilevel commission in Access Database. I realize
this can be a very complicated set up so would like some advise.
Thanks

Alan,
since you're on the subject, know any good books on Data Warehousing
besides Kimball & Ross, "DW Toolkit" ? I was supposed to do that
class last term, but the instructor was so awful that I dropped.

[T Martin]

I've been designing/maintaining a commissions database in Access which our
company uses to track payments on orders, revenue reps earn etc and run
various reports. What exactly are you looking for in this database
(reports, tracking, etc.) and I'll let you know if it is what I've been
working with.

thanks

T Martin

"di" <di******@chart er.net> wrote in message
news:9b******** *************** ***@posting.goo gle.com...

Does anyone have any recommendations on Examples or experience on
creating a multilevel commission in Access Database. I realize
this can be a very complicated set up so would like some advise.
Thanks

[Alan Webb]

Pieter,
No, but the basics of Kimball & Ross' books are summarized in some articles
Kimball wrote for Intelligent Enterprise. My summary follows. First, a
data warehouse is a relational database. You can't ignore Boyce-Codd Normal
Form just because you've decided to jump camp and call yourself a data
warehouse architect. The primary mission of a data warehouse is to support
management's understanding of the performance of the organization through
numeric measurement (metrics). Traditional relational designs tend to be
better at capturing data. There are design choices which improve the speed
and reliability of data capture that can in turn inhibit management's
ability to interpret the data being captured.
So, a Systems Analyst tasked with building a relational database tries to
understand the flow of information through a business process and in turn
design a database that efficiently supports that information flow. Some key
goals are to provide the most current picture of the business, to minimize
redundant work by attempting to only capture a piece of data once and
provide it wherever needed, and to put the right data in the right hands at
the right time.
The same Systems Analyst tasked with building a data warehouse is not
releived of his need to understand how information flows through a business.
But instead of ensuring the efficient flow of current data the task is to
ensure management has information it can use to measure the performance of
the organization and make good decisions. As a first goal a data warehouse
must be an accurate historical record of the organization's performance.
One of the early questions that has to be asked is, "What are we measuring
and from what perspective(s) (dimension(s)) to we want to view these
measures?" Based on the answers to these questions the analyst can then
begin to map out attributes of the dimensions that management is interested
in and to identify the numeric facts that will be used to measure the
organization's performance.
So, the relational schema that often evolves has at its center a fact table
containing columns of numeric measures as well as foreign keys that relate
to one or more dimensions by which the numeric measures will be viewed.
"Pieter Linden" <pi********@hot mail.com> wrote in message
news:bf******** *************** ***@posting.goo gle.com...

Alan,
since you're on the subject, know any good books on Data Warehousing
besides Kimball & Ross, "DW Toolkit" ?

[Pieter Linden]

"Alan Webb" <kn*****@hotmai l.com> wrote in message news:<os******* *************@c omcast.com>...

Pieter,
No, but the basics of Kimball & Ross' books are summarized in some articles
Kimball wrote for Intelligent Enterprise. My summary follows. First, a
data warehouse is a relational database. You can't ignore Boyce-Codd Normal
Form just because you've decided to jump camp and call yourself a data
warehouse architect. The primary mission of a data warehouse is to support
management's understanding of the performance of the organization through
numeric measurement (metrics). Traditional relational designs tend to be
better at capturing data. There are design choices which improve the speed
and reliability of data capture that can in turn inhibit management's
ability to interpret the data being captured.
So, a Systems Analyst tasked with building a relational database tries to
understand the flow of information through a business process and in turn
design a database that efficiently supports that information flow. Some key
goals are to provide the most current picture of the business, to minimize
redundant work by attempting to only capture a piece of data once and
provide it wherever needed, and to put the right data in the right hands at
the right time.
The same Systems Analyst tasked with building a data warehouse is not
releived of his need to understand how information flows through a business.
But instead of ensuring the efficient flow of current data the task is to
ensure management has information it can use to measure the performance of
the organization and make good decisions. As a first goal a data warehouse
must be an accurate historical record of the organization's performance.
One of the early questions that has to be asked is, "What are we measuring
and from what perspective(s) (dimension(s)) to we want to view these
measures?" Based on the answers to these questions the analyst can then
begin to map out attributes of the dimensions that management is interested
in and to identify the numeric facts that will be used to measure the
organization's performance.
So, the relational schema that often evolves has at its center a fact table
containing columns of numeric measures as well as foreign keys that relate
to one or more dimensions by which the numeric measures will be viewed.
"Pieter Linden" <pi********@hot mail.com> wrote in message
news:bf******** *************** ***@posting.goo gle.com...

Alan,
since you're on the subject, know any good books on Data Warehousing
besides Kimball & Ross, "DW Toolkit" ?

Cool, I'll get around to reading them after I finish this ridiculous
homework... that's the problem with school - gets in the way of
learning all the time! Thanks for the commonsense explanation. I
almost never get them in school. (Makes you wonder what you're paying
for!)

Pieter

[Alan Webb]

Di,
Again Tech's big marketing pitch was that their package would let you design
and modify a commision plan per employee if needed as well as the ability to
create arbitrary pay calendars per employee. I helped code some of the
interface--which was a nightmare of complexity because they used contract
coders and allowed each contractor to design his or her own interface for
that portion of the application--and saw the potential of the product if
they ever got it to work right. In any case, in addition to the other
dimensions I wrote about one more is probably commision plan, since this
will change over time as managers seek to drive sales through changes to the
compensation plan and it will be necessary to know the compensation plan for
historical records so the data can be understood. The numbers will not tie
if you use a current compensation plan for an employee on sales they
completed and were paid on a few years ago.

"di" <di******@chart er.net> wrote in message
news:9b******** *************** ***@posting.goo gle.com...

Does anyone have any recommendations on Examples or experience on
creating a multilevel commission in Access Database. I realize
this can be a very complicated set up so would like some advise.
Thanks