21 replies to this topic

[wazu]

Greetings,
We sell several items that are offered with many combinations of options. We can also sell any combination of any items we offer, in 22 different colors. However, setting up and cleaning down the spray equipment (after each color), forces us to charge a one time 'SETUP FEE' for each unique color ordered.

Example1:

(1) x model AAA (red) = $1.00 + $.50 (setup)
(5) x model DDD (red)= $2.00
___________________________________________
Total=$11.50

Example2:

(1) x model AAA (red) = $1.00 + $.50 (red setup)
(5) x model DDD (red)= $2.00
(2) x model AAA (blue) = $1.00 + $.50 (blue setup)
(1) x model AAA (green)= $1.00 + $.50 (green setup)
___________________________________________
Total=$15.50

Because the setup fee need only apply once (after total number of unique colors have been calculated), it seems logical to be a ot_loworderrfee hack. The problem (as you were about to point out) is ot_loworderrfee calls from
if ( ($pass == true) && ( ($order->info['total'] - $order->info['shipping_cost']) < MODULE_ORDER_TOTAL_LOWORDERFEE_ORDER_UNDER) ) {
Assuming our colors are an option value, maybe we need
if ( ($pass == true) && ( ($order->info['options_values_id'] == 107) ) {
Unless, (as you were pointing out again) we are calling from the cart, maybe?
if ( ($pass == true) && ($this->contents['products_options_value_id'] == '107') ){
Am I re-inventing the wheel, maybe ot_loworderrfee is not the way to go. I looked at the CC (build custom computer mod) and it seems over kill. Any direction would be extremely appreciated.

[dwatson]

If there is not a contribution that can do this, I would just tend to dig into the php code myself. I would think you would have to do that, because this is a special circumstance.

[wazu]

dwatson, on Apr 4 2005, 09:43 PM, said:

If there is not a contribution that can do this, I would just tend to dig into the php code myself.  I would think you would have to do that, because this is a special circumstance.

<{POST_SNAPBACK}>

I am brand new to PHP, am i headed in the right direction?
It seems when the cart collects the content, it merges it and asigns a unique cart_id(classes>shopping_cart).
Or is it pushed back at chekout?
Thanks.

[dwatson]

Sorry, I don't have the time to go through and read that code right now. It does not sound like a simple hack to me. You need to keep track of the colors, and then group the products selected within each color choice. It sounds like a different array structure than what osC provides. But I'm not looking at that code right now, so can't say for sure.

[wazu]

I understand, thanks for your time.

wazu

[dwatson]

Oh, one trick that might help. After the containing data structure is "filled", put in a <pre>var_dump(--array--)</pre> and take a look at exactly how it is being populated. Then you can adjust it, and figure out what extra calcualtions you then have to do on it. Maybe there is a simple way to do this, but I don't know off the top of my head.

[wazu]

Not sure what "<pre>var_dump(--array--)</pre>" is, maybe when you have more time you can elaborate, thanks for your quick reply,
wazu

[dwatson]

Look up the var_dump function in www.php.net. It just dumps the array values to the screen and is great for testing and debugging. You can do fancier dumps with objects, but I don't think you need that. The pre tags around it just make sure the exact text is shown -- meaning the browser does line feeds where there are character line feeds and the array looks readable, indented where appropriate, etc. Put one in your code there and just see what comes out on the screen -- assuming you are working with dev code and not your production site. Oh, backup first.

I think your array is going to need an extra value to track the color grouping. I would not be surprised if you had to do some parallel database work too.

Also, all this grouping and sorting could be done with SQL statements, if you were tracking all the data in the db tables.

[dwatson]

Okay, back from dinner shopping. Sorry about the shorthand.

For the <pre> tags, if its inside php, you will have to say
echo "<pre>";
var_dump(array name);
echo "</pre>";

you have to echo the pre's because they are really html tags, but the var_dump goes right to the screen.

I would take a good, hard look at that array that holds the color values and products. Then I would figure out how to sort it by colors. You might want to add an extra element to the array to track the setup fee ($0 or $X for setup). Then, when you have collected all the data nicely, sorted, and lined it up in the array, you can figure out how to write it to the db table, if needed.

Then you can make sure it comes out okay with the shopping cart screen, etc. Setup just sounds like an extra price attribute that is calculated above after you do the array manipulation.

[wazu]

dwatson, on Apr 4 2005, 10:41 PM, said:

Okay, back from dinner shopping.  Sorry about the shorthand.

For the <pre> tags, if its inside php, you will have to say
echo "<pre>";
var_dump(array name);
echo "</pre>";

you have to echo the pre's because they are really html tags, but the var_dump goes right to the screen.

I would take a good, hard look at that array that holds the color values and products.  Then I would figure out how to sort it by colors.  You might want to add an extra element to the array to track the setup fee ($0 or $X for setup).  Then, when you have collected all the data nicely, sorted, and lined it up in the array, you can figure out how to write it to the db table, if needed.

Then you can make sure it comes out okay with the shopping cart screen, etc.  Setup just sounds like an extra price attribute that is calculated above after you do the array manipulation.

<{POST_SNAPBACK}>

Thank you VERY much. I'm going to do some (more) php schooling. Quick question, Am I trying to write the color data to the base?. as it is set up now, we have an attribute "color" with 22 options of colors. these colors are already being stored in the base as products_options_values_id right? That said would i simply have to identify the unique id number at the checkout ?

thanks again,
wazu

[wazu]

This is how the cart seams to be storing the product
71{1}91{6}81{7}83{8}88

71item id
{1}color
91color id
{6}size
81size id
{7}mount
83mount id
{8}diameter
88diameter id

If the color information is already being stored, can we :
from checkout?
($order->info['products_options_value_id'] == '91')
or from in the cart?
($this->contents['products_options_value_id'] == '91')

Am i gettin closer?
thanks wazu

[dwatson]

I think you are charging the setup for the first red, and not the other reds, so you will have to build some extra data and extra logic into it. There is a sort, then a sequential if-then-else.

What this sounds like is creating another, synthetic, attribute for setup. Setup will not be chosen by the user, but rather, calculated by you. So you would have to add the field to the db that osC would normally do after the user selects an attribute. I would just make another array element for setup $ along side of (to pretty much match) the color attribute code. The new value does not have to be a code, of course. It could just be a value like 0 or .50.

All this means you have to understand what osC does to create and store a regular attribute, and you have to do it in one routine, automatically, without the user doing anything (after they have chosen color).

Of course your code could always figure this out, on the fly, on checkout given the products and colors (and their sort). But doing it up front, like it is another attribute in the db, will probably make it easier. Otherwise, you might have to calculate it multiple times.

I would think that you would also want to maintain the color sort on the checkout order confirm. Then the setups will make more sense when you see all the reds grouped together and first one has the setup $.

Again, I'm really not reading the code or looking at contributions. I'm just thinking about the logic and algorithms I would see there.

[dwatson]

Come to think of it, if osC always uses codes here for attributes, I would also create extra setup fields (in the array and db) that hold codes. Then, where osC creates ancillary tables to join (that have the values), I would do the same.

The reason for following the osC exact data structure, is that osC will probably handle everything automatically (except the color sort) in all of its display routines. It is probably expecting to see every attribute with the same data structure.

I think if you do try to calculate this setup on the fly during checkout, it will be harder. It is not just an assignment or simple calculation -- it is a sorting & grouping of the records, then a sequential if-then-else traverse of the records to find the first in each group etc. This is a lot of logic.

Unless I am mising something, this does not sound trivial at all. I wish I knew of a contribution that handles this. If there isn't one, and you do it, you should release it as a contribution.

[wazu]

Dave, are you saying there is no way to call from the data stored in it's current form?

71{1}91{6}81{7}83{8}88

71item id
{1}color
91color id
{6}size
81size id
{7}mount
83mount id
{8}diameter
88diameter id

If so, I am headed in the wrong direction. That would put this beyond me newbe.
thanks,
RE- group, RE- think, RE- drink?
wazu

[dwatson]

Pretty much. I think that you are trying hard to judge the setup from the info in a single product-record (or array, which goes into a record). I don't think that can work.

If you call the data up as it is, then try to calculate your setup $, you have to go through all that sort, group, traverse stuff every time. Its just a good chunk of logic, but it certainly could be done on the fly.

Think of it this way. Every time want to decide whether to charge a setup fee or not, you have to group every product in the cart by color. then you have to figure the first product in the color group. Then you have to set its setup to $.50. Then you have to go through each of the others and set them at $0. Then you have to know when you come to the product for a new color group and set it to $.50, etc. etc.

This certainly could be done a number of ways. It just is not as simple as looking at a single product-record and seeing if you should charge a setup for that. You have to know about all the other product-records in the cart (the groups, first ones) to do that.

In general, shopping carts assign attributes and their prices one-to-one, to products in the basket. So, someone picks a suitcase -- its $200. Then they choose the attribute or add-on -- "have it monogrammed" and that is an extra $5. So the attribute there has nothing to do with the other products in the cart.

In your case, this setup attribute has everything to do with the other products in the cart.

Here is another way you could do on the fly: Put in some conditional logic in the checkout for each product to say whether you have already charged a setup for that color. If not, then charge it. If you have, then don't charge it. Again, you are into more complicated logic than just looking at an individual product purchase record. You are tracking what has been going on with the other products in the cart before you charge the setup. You have to have a variable to track whether that color has been charged a setup, etc. This seems just as complicated as the array/database stuff.

My feeling about this is that it is not a php newbie project. If you wanted to read something like the O'Reilley book on PHP and MySQL, then you could certainly tackle it.

If I looked hard at the code and data structures, I could proably find the easiest way. But no matter what, it involves setting a price based on what has been charged for other products in the cart. Its not an atomic judgement.

I know PHP pretty well, but I'm still learning osC. So don't take this as gospel. But it seems logical to me.

[wazu]

We considered alternatives to incorporate the additional costs of the color option, with no feasible solution. After reevaluating this color setup fee, we have determined it has to be implemented. For the short term, we will offer it as “custom” requiring the customer to fill out a request. This may adversely impact online sales (for those purchasing color). In the long term, my inturpation of your valuable logic leads me to believe, you might lean towards adding additional values to track the “color fee” or “no color fee” approach. You suggested this is based on the limited consideration you gave to date and there may be simpler alternatives. May I ask you to briefly consider the following?

A hack of the “agree to terms mod”
Customer will purchase the setup fee before gaining access to the color options. (As you are pointing out, it may make navigation sloppy and restricted.) This will solve the color fee, but generate how much more work for navigation clean up?

Color popup
Purchasing the color setup fee implements a popup for the available colors. Will it be simpler to get the java based “popup choice” recognized by the cart?

New setup
The store is setup with 22 main color categories, shopping a unique category assigns its color fee (back to loworder fee hack). Another navigation nightmare.

Any feedback would be immensely valuable, as we need to commit to a direction and are presently not qualified to do so.

wazu

[dwatson]

wazu,

I am now writing pseudocode documentation on the code base. See the contribution:

http://www.oscommerce.com/community/contributions,3078

I have started with application_top.php because it is, well, at the top of every page and brings in all the key functions, classes and constants.

I am doing this becuase I will be taking apart and putting back together main pieces of osC for a client, especially the checkout process, and this is best way I know to really learn to do that.

What I will do, since I plan all the main parts of the site, is focus today on the parts that you are asking about. This is fine for me -- I don't mind working on it a little out of order. I'll send you the pseudocode (code rewritten as English logic, not computer statements) for that.

I'll also take a better look at any relevant contributions. I really should do that before blabbing so much. Can you give me a list of all the contributions that you have looked at at so far re. this? And I'll do a search myself.

It sounds like the coding work you need to do is really not that much for someone with the php skills. If I were you, I would very clearly do a one or two page write-up of exactly what you want it to do -- this thread is a good starting point. Skip the technical stuff -- just make it a very clear funcitonal spec. Your first example was good, but maybe do a crude mockup of how you really want (not kludges) to tell the user about these charges (and where) and then how you want them displayed or annotated during the checkout. For example, do you want the products sorted differently on the order confirmation for the color groups? Use the osCommerce checkout screens as a starting point, of course.

Next, there are lots of php programmers who work off-site that would do this work. Get a bid up front for what it would cost, how long it would take, etc. From the work I do today on the pseudocode, you should get a good idea of that. Then contract it out.

Then, when you get the results, put it on your environment and test it well before you upload it to your production site.

This looks non-trivial to me, but certainly not a major project. Because of that, I think you can still figure out how to do it the best way for your customers -- without navigation kludges.

I think it would be better for your customers (and your store revenue) to do it the right way, and really not that hard. It just sounds like you don't have the time now to read through all the PHP how-to books yourself.

[wazu]

Thank you very much sir.
I apologize, if I’ve given you the impression “I do not have the time”. The fact is, I thought it was a much simpler task and could learn enough to implement in a timely fashion. Based on our discussions, and my current (lack of) php knowledge, I cannot do this in a timely manner. I believe, I have investigated almost all 2500 available contributions, which led me to the current path. The working store currently has a required choice of 2 options of color (stainless steel and white) for all products. Stainless steel is the “no up charge” default. White is the “up charge ” option; we do not need a setup fee for white. We propose to add 21 additional “up charge” colors to this option field and charge (only once per unique color) a setup fee for any of the 21 additional colors that are chosen. I believe this is the "functional spec" you described? I am not clear if posting the url is allowed, or if I emailed it to you if you would find it helpful.

You have been most helpful; I will continue to explore the world of PHP.

wazu

[dwatson]

I think this is the answer. Does anyone have a better method? Thanks.

I think you were on the right track after all with the low order fee module, but it is a little more complicated than you thought. I was getting hung up with figuring a setup ($0 or $X) per product, rather than a summary of the whole amount. I think my side reaction to use a SQL query to drive it was a better idea than a focus on the attributes array. So, here goes:

* Assume that you do not really have (or will have) any real low order fee, and we can use that facility to calculate the setup fees instead.
* The algorithm for figuring setup fees can be stated simpler, which lends itself to a SQL query to get it: Charge $ SETUP (the $ SETUP constant is defined as $X) for every unique group of colors in the order, except white. You can calculate a setup total easily using this view of the calculation, as long as you have the groups counted (and subtract 1 for White if its there).
* Redo the internals of the ot_loworderfee class in the php file with that name. This way, as long as you specify that the low order fee is displayed and allowed through the admin, then the routines can perform and display their own calculations (ignoring the other settings like “order fee for orders under” and “order fee”) since it won't "really" calculate a low order fee -- just use its data structures and variables for display.
* The internals of this class would now do a join query on the tables order_products and order_products_attributes tables from the database. The query and its evaluation would return a count of the groups of unique color attributes in the order and whether white was one of them. If white is one of them, subtract 1 from the count, then multiply by $ SETUP.. Put this total into the value that is passed to low order fees.
* Rename the label on the order confirmation to something like “Color setup fees” or whatever you wanted there. That would be a text change somewhere in the files.

I think that would do it. I think all you would need to do is replace that ot_loworderfee.php file and change the label text to say “Color Setup Fees.”

[wazu]

No Luck.
It appears that the ot_loworderfee.php -
looks for the required information (the color) :: products_options_value_id
from the order :: $order->info['xxx_xxx_xxx']
However, it appears, at this point, the required information (the color) has been merged with other information about the order and the format has been changed by the shopping cart for security :: $this->cartID = $this->generate_cart_id();

Does anyone know how to extract the required information (the color):: products_options_value_id
at this point? Maybe we can read it from the HTML source from boxes>shopping_cart.php at checkout confirmation (the point that loworderfee is introduced) using something like ::
$cart_contents = $HTTP_POST_VARS['products_options_values_id'];
or
$cart_contents = $HTTP_POST_VARS['products_options_values_name'];

I am obviously code’en in the dark (no clue). Any response will be appreciated.

wazu