How to add a sales type / what is the difference between type and list

I think this is only matter of naming. Price list is normally related to sales type. Nevermind.
You can entry actual prices for Items& Invenotry/Sales Pricing. There is also multilevel guess system for not defined prices, but you are right - finally the price is not directly related to cost of purchase, but eventually to price in default (base) pricelist.

Janusz

Well, I'm not sure what is your conclusion, so I don't know whether I agree or not .
I would like to avoid words meaning discussions, but for us price list and sales type is merely the same: this is set of prices used in company for some sales segment, together with algorithms used for price calculation when exact price is not set for given item.
As a reply to your question 2: you can add sales type in Sales/Sales Types, and entry prices for just created sales type in Items&Inventory/Sales Pricing. Is this what you are asking for?
Janusz

Thanks ed10, now someone is seeing my point.
@itronics I checked Sales/Maintenance/Sales Types. You can add a sales type, but the mark up for the entire item list has to be the same. ed10 and I are pointing out that any company selling multiple lines can reasonably expect that they are going to want to have some items marked up higher than others. For example if I sold car stereos it might look like this.
JVC stereos +25% markup
JVC accessories +40% markup
Kenwood Stereos +18% markup
Kenwood accessories +30% markup
Cable, wire and other install materials +50% markup
This can be accomplished by entering the prices for each item, but now we need to consider wholesale and commercial customers.
With sales types you can simply make a wholesale sales type that gives a discount off retail, but it has to be the same for every item in inventory. Since you don't have the same markup for every item in inventory you don't want the same discount for  every item in invetory. In this example
a Kenwood stereo that cost 100 would retail for 118 a 15% wholesale discount would make the sale price 100.30. That is not reasonable!
If a JVC accessory cost 100 it would retail for 140 a 15% wholesale discount would make the sale price 119. That is reasonable. Hopefully this example makes it clear that having a sales type that uses one percentage added or subtracted from retail is a recipe for disaster in most business types.
Having a sales type arrangement that uses a single percentage to add to the cost, will keep you from loosing money on a sale, but still prevent you from making as much money as you can.
Since we are all in business to make as much money as we can, I think I should say the only way to do that is to have price list NOT sales types. A true price list is an actual list of every single item, with an actual price or percentage of the cost associated with that item alone not the entire list. If a company intelligently groups its customers there will only be a handful of groups and a list for each group. It really  isn't that hard to manage in the accounting package we currently use. FA does many things better than this other package, but this particular stumbling block is a deal breaker. I am adding this to the list of items I have to change, before FA can be feasible for our company. Hopefully this would become part of the core FA application at some point, but if I can make it happen in a module rather than changing the core files I will give it back to the community.
-Jason

Jason, I understand constraints you explained and this is somewhat obvious: nobody want to sell items below the costs. But in both your posts you have not mentioned about ItemandInventory/Sales Prices menu option, so I guess you simple overlooked it.
In short words logics behind prices system in FA:
. You can set exact price for every item/pricelist pair;
. Customer has one pricelist selected as default;
. When exact price is not set for given item/pricelist the price is calculated from base company pricelist.

I hope Tom has explained all this better than me, so maybe now it is more clear for you.

Janusz

@Tom
That  makes since now.
'Under Sales->Manage Customer there is a pull down menu "Sales Type/Price List"'
This is what I was missing.
Now I have another question. If I edit the prices for every item using this system, will the custom pricing be effective for the sales type or only for that customer using that sales type?
@itronics I think we just had a disconnect
@ed10 I too do not see how you can use two price list (aka sales types) on a single sales order. I can see giving a clearance price to a customer for one item, but only by changing the price here
Under Sales->Manage Customer there is a pull down menu "Sales Type/Price List"
This would be absolutely chaotic to manage on a large scale. I definitely see your concern and hope that this has already been addressed and we simply need the right person to read your question.

@ed10 In FA price list is related to transaction as a whole, and not the single item in transaction, so you are right - there is no way to use multiply price lists on the same transaction. You can consider this as an issue, but it depends on type of business. I guess you would like to have sales type selectable per line item?
Janusz

@Jason - I will call it a Price List - If you edit a Price List it changes the price for all customers assigned to that Price List. You could have 1 price list for each customer, or have 3 different price lists and pick the price list based upon the customer's volume, negotiating skills, etc

@itronics: Sounds like Ed wants dynamic special pricing based on date, stock levels etc. FA can't do that, but on a Line by Line item you can change the price or set the discount.

@ed One way I could see to support this kind of pricing was if we were to expand the Sales type to include a Group of Price lists. For example the Sales type could retain the Price Factor to handle the default price (based on the Base Price List) and then an ordered list of price lists, if the item is not found in the First list, the second one is checked, etc If it is found you are done, if it was not found in any then use the Base Price * factor as it does now.

It might take a new table or a new field in an existing table but with a little bit of work it could be done and would be a great contribution to the project!

tom

I would like to thank you guys, for all the important suggestions. We are busy now with final 2.3 release preparation, which is planned at the beginning of December. We will consider changes in this area just after the release, when we have more time and less constraints on database scheme changes.

Janusz