[Typo3-shop] price calculations.

[Franz Holzinger]

Hello Marc
>> But it would be more complicated, if one contract reduces the phone 
>> price by different amounts depending on the phone.
>>
>> Answer this question before I continue.
> 
> 
> Its the first one, one contract, eg. Vodafone 100 min a month, would 
> always reduce a phone price with a fixed price.
> 
> But there is an other problem: a contract can also be sold without a 
> phone, and then the amount with what a phone would be reduced would have 
> to be processed and displayed as a negative price indicating a so called 
> 'cash back' offer. This form of contract deal is called 'sim-only' So 
> that is why it would seem logical to set a contract as a separate 
> product just as a phone would be. So when you combine phone A with 
> contract B that would result in a reduced price and if you take just the 
> contract you would receive an amount (as a customer that is). Is this an 
> option?
Yes, this would be best solution. If you need an additional price 
addition or reduction you can also use the accessory price of an article.

> In addition to that: how tt_products works is that the dealer calculates 
> the desired sell price and inputs that in the price field.
> But with this shop the price entered has to be the purchase price for 
> the dealer and than the shop has to calculate, via a calculation 
> function or script, the amount that will be displayed in the frontend.
You can of course write your own calculation script. But if you do not 
TScript configuration options for it, you have to change you code each 
time the calculation changes. Decide whether you want to use your own 
tables for the contracts or the tt_products table.
You should use price2 for the dealer price.

>> That is no problem because you can use different templates. At the 
>> moment only one template will be used for the shop. This can be split 
>> for the bill and delivery in the program code. But how does this work?
>> What happens if someone buys a handy from Vodofone and one with a 
>> T-Mobile contract?
> 
> 
> well in Holland people usually have one contract on there name. So if 
> for example a father would like to buy a second phone + contract for his 
> son or daughter to use he would just have to pay two separate visits to 
> the shop. This is actually a situation that rarely happens. The same 
> goes for business customers who would like to buy 10 contracts with 10 
> phones. They would just have to give the shop a ring or an email because 
> this would mean a big deal for the shop owner and he handles that 
> personally. But it would be possible for example for a person to buy a 
> phone with contract and an extra phone or whatever so the reduction 
> should belong to the total amount. This again points somehow to a 
> contract being a separate product with a negative selling price.

A negative price for buying a contract is the most easy solution.

>> I would say, that you create 1 shop for each provider. For each 
>> provider you have an own articles folder. You have to enter the same 
>> data if each provider sells the same mobile.
> 
> well that would be an option but I thought of it this way:
> 
> one subtree for special offers: just phones, phones with contracts, home 
> phones (DECT, like Gigasets from Siemens).
> one subtree for phones (without contracts).
> one subtree for contracts without phones.
> one subtree for a contract and a phone.
> and maybe a subtree for special contracts (contract for people who 
> already have a contract and want to renew their contract and receive a 
> discount so basicly just another contract only with different discount 
> from new customers.

You could do so. But when you have the same phone in more than one 
subtree, you have to enter all the data for the phone again and again.
Try to use the accessory: one subtree for phones and contract as 
accessory. Then in the accessory field use the number not as the price 
but as the number of the contract sold together with the phone.

>> But maybe the tt_products price calculation should get extended a bit.
>>
>> pricecalc {
>>   variant = table  /* The prices are calculated using a database table */
>>   table = {
>>      name = contracts_table /* This is the name of the table with the 
>> prices for contracts */
>>      id = id_field /* The identifier id field from the contracts table */
>>      }
>>   10.prod.1 = 4.99  // Where there is a product with a price 4.99 this 
>> will cost 4.99 for contract No. 1
>>   10.prod.2 = 8.99  // costs 8.99 for vendor No. 2 (id_field)
>>   10.prod.5 = 19.99
>>   20.prod.1 = 6.99  // Where one products from the article folder 
>> costs 6.99 ...
>>   20.prod.2 = 13.98
>>   20.prod.5 = 29.99
>> }
> 
> 
> I will have to studie this in practice so give me a little time to 
> figure your script out. 
This is another option, but more complicated, because it needs 
programming. However the advantage with this is that you could use your 
own contracts table and write your own contracts extension that you use 
together with tt_products. More work but more extensibility for the future.

 > I just implemented a 1.2.7 version without the
> tables for categories option :) so I'm progressing but...
> I am working on the Core API document because my understanding of the 
> extension extension :) is not up to level with you guys.
Most fundamental work can be done with the Extension Kickstarter.


> on other thing: 5 networks something like 8 contract-types per network 
> so one simple selector box is not going to 'cut it'. But this should be 
> do-able I think.
On the details page of a phone there should no contract be selectable. 
This would make it too complicated. The user himself should put a 
contract into his baket separately. So he could easily get an overview 
about the prices and just change the mobiles or contracts as he likes.
It is a bad way to connect a phone to a contract. When the seller wanted 
to change his selection afterwards he would have to reselect both 
another phone as well as another contract.

> http://www.gsmeasy.nl/
> a little to big so less functionality would be ok.
Make it as easy as possible and without any selectors.

> http://www.startelecom.nl/
> ugly site but the meganisme is about what I want to build, but then not 
> with proprietary cms ,like this one, but with Typo3.
Here only one phone can be selected. Then a lot of data for the contract 
have to be entered. So this means that you either adapt the tt_products 
only for your needs. The fields you need are not in tt_products now. But 
when you change it only for your mobile shop you would loose everything 
again when the next version of tt_products will be published.
I think you should extend the fe_user extension. There will be more 
people who need special data fields.
So I propose to make the name 'fe_user' as a parameter to tt_products. 
It should be changed to use the TCA of the 'fe_user_your_name' to do its 
job.

> Yes the Dutch way of doing contract selling with is a little strange 
> compared to what the rest of the world does...
Others countries other customs.

Greetings,

Franz