Revision [216]
This is an old revision of VerticalMarketFunctionality made by PhilDaintree on 2007-08-13 21:24:14.
Vertical Market Functionality
Slightly cryptic naming of this page .....
Many businesses require specific data entry fields against a service that they offer
eg. 1 A Hotel offering the service of accomodation, requires the night of the accomodation, the room number and number of guests, name of guest etc
eg. 2 A courier business offering the service of delivery of packages, requires the pickup address, destination address, weight of the packate, volume of the package etc
Similarly a business that sells items of a particular category may require specific fields for just that category. Our demo of airconditioners may require fields for kw output heating, kw output cooling, inverter, outside unit noise dBa, indoor unit noise dBa etc.
The specific fields may be required to define the item properly as static data against the item or they may be required to be entered on every sale of the item/service.
It occurs that a generic way to add fields for input at the time of order entry would be valuable to many such vertical market accounting applications and afford a very flexible set up that could cover many obscure situations. Where the field is required at the time of the order/invoice entry, then these fields should print out on invoices and order inquiries.
It also occurs that services of different kinds will have different fields that are appopriate we could define these service properties either at the item level or against the "stock category" - the word stock is used here to mean "item". I am not sure which level would be best. under the example above of a courier business the item might be
A4 courier bag accross town
but there could also be A4 courier bag accross 1 sector, 2 sectors, 3 sectors, A5, Foolscap etc - so it might make more sense to define a stock category that requires the extra fields and have all these items as part of a "courier bag" stock category and not have to define the properties of each item separately.
Similarly accomodation could be:
a deluxe room
a single room
self catering apartment etc
if these were all defined as members of the stock category - accomodation then the same properties would apply accross each service albeit that the pricing and description of each item would be different.
To code this I am thinking that we will need a couple of new tables:
CREATE TABLE stockcategoryproperties
propertyid int auto_increment,
categoryid int,
PropertyName varchar(50),
NumericValueExpected tinyint default 0,
MaximumLength tinyint default 50,
categoryid being a foreign key to stockcategories catid
we could extend this to have a field showing the possible values for the property if it was completed perhaps a comma separated list of the possible values stored as one field and exploded out into separate values as a combo box
Perhaps also a field to allow some kind of validation of the value entered ie >0 etc.
and we also need a
salesorderdetailsproperties
propertyid
salesorderdetailsid
propertyvalue varchar(50)
propertyid being a foreign key to stockcategoryproperties this would allow for an unlimited number of properties.
That's the easy bit since we now need an additional form to enter a stock categories properties - a relatively easy one and some additional forms in order entry - the most complex area of the system!
<Phil - 14/8/07>I have coded this up to the extent that we now have unlimited properties against stock categories and we can choose whether the stock category property creates fields for the input of new items of the category in the new item screen or whether it creates additional required order entry fields. This was released with version 3.07 and a couple of bug fixes into 3.071. I have not done the order entry modifications required to effect the vertical market service options ... always looking for sponsors though </Phil>