Proposal for changing pricing

[Nathan Gray]

pERP's current method for tracking selling prices is to define a price  
list, valid for certain variables, and then set the prices for each  
item.
An example:
Price List A, in CAD, for the Parts sales category, offered to the  
Western sales area, to customers of Type A, effective from 2008.04.01  
until further notice.
Price List B, in CAD, for the Widget sales category, offered to the  
Western sales area, to customers of Type A, effective from 2008.04.01  
until further notice.

If I want to offer another item in the Parts sales category, I would
1.  Add the new item to the Parts sales category.
2.  Discontinue the current price list, effective 2008.06.22 (next  
Sunday)
3.  Create a new price list, and change only the effective from to  
2008.06.23 (next Monday).
I would then distribute the new price list to my customers in advance,  
so they would know what the new items and pricing would be

Pros:
- Stable pricing
- Price lists can be distributed to clients
- Easy to find the current price for something

Cons:
- Difficult or impossible to change or add to current price lists
- If prices change frequently, lots of data

I'm considering changing how the pricing works, so that the date is no  
longer part of the price list.  You would define a price list, valid  
for certain variables, and then set the prices for each item.  The  
date, however, would be tracked with the price.
If I want to offer another item in the Parts sales category, I would:
1.  Add the new item to the Parts sales category.
2.  Set the price for the new item, effective 2008.06.23

Pros:
- Easier to maintain pricing, especially for businesses where items  
and prices change rapidly
- Smaller database

Cons:
- Client needs to check to know what the current price is
- User interface gets more complicated for maintaining prices, in that  
every change needs a timestamp

In addition to the Cons of the change, there are some difficulties  
dealing with:
1.  Preserving historical data
Some of you are already using pERP in a production environment.  Sales  
Orders keep track of what price list(s) were used to figure out price  
overrides.  This section will have to be re-written, but there may be  
some loss of data reliability.  There may be some spurious price  
overrides generated if you view old sales orders.

2.  User interface difficulties
Every price change needs a timestamp.  Before that timestamp, use the  
old price, on or after, use the new price.  The simple case would  
always use time(), and changes are effective immediately, but this  
will not work for those who actually plan these things in advance.  
Currently Price List Edit page and Edit Stock item's price tab have an  
effective date that could be turned into a date / time, defaulted to  
time(), and used for entry and display.  Something similar could be  
done for Edit Build Option's price list.
I'm looking for suggestions or potential pitfalls in doing this.

3.  Which time to use
When creating a new Sales Order, it makes sense to use the current  
pricing, as of the Order Date.  Order date will have to be changed  
from a date to a date/time, or new prices could be used too early.
There are also some edge cases that will cause problems.

3.1  A sales order is being entered, but there is a new item that was  
missed and is not on the price list yet.  The price is determined, and  
the item is added to the missed price list, effective immediately.  
The item still will not be available for purchase, because the sales  
order's Order Date is displayed as a date, not a time, so it defaults  
to midnight, which is before the item was on the price list.

3.2 Due to the amazing new Thinger product line, and dealers faxing  
their orders in, the sales department is falling behind.  As they're  
catching up, they are entering the orders in the order they were  
received.  As they enter the orders, they correctly set the Order date  
to the date the fax came in.
As the orders are entered, it is discovered that there is an error on  
one of the price lists.  The error is corrected, effective  
immediately. It's a bit of a problem (price overrides, other  
historical data) to back date the price change, so the price will be  
wrong for all the orders being entered unless the sales department  
uses an order date after the correction instead of when the fax was  
received.


I need you all to think about this, and see if you can spot any other  
problems, such as things I haven't thought of, various legal  
restrictions, or where your users will have issues, and offer  
suggestions or (preferably) solutions.  This will be a fairly major  
change, and will take me a while.

Nathan Gray
nathan at goarctic dot com


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Perp-developers mailing list
Perp-developers@...
https://lists.sourceforge.net/lists/listinfo/perp-developers