Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

braathwaate

Pioneers
  • Posts

    12
  • Joined

  • Last visited

Profile Information

  • Real Name
    BraathWaate

Recent Profile Visitors

2,233 profile views

braathwaate's Achievements

  1. The code is used during checkout confirmation when calculating the order total and order tax. If you redeem a fixed amount coupon, then checkout, you run this code.
  2. I think the tax calculation for coupons subtracted before tax is wrong. For my installation, the commented out code on line 322 to calculate ratio1 is correct and intuitive, whereas the code on line 325 to calculate ratio1 (curiously marked "//// debug") does not make any sense. For example, the current release calculates a 4.9% tax on a $129.60 order with a $10 coupon (discounted total of $119.60) at $5.84 whereas the older code calculates correctly at $5.86. The larger the coupon, the worse is the error. For those who sell instate merchandise in the US with fixed off coupons, check your orders. Those pennies could add up! Here is the release code for ot_coupon at line 321: } else { // $ratio1 = $od_amount/$amount; // this produces the wrong ratipo on fixed amounts reset($order->info['tax_groups']); while (list($key, $value) = each($order->info['tax_groups'])) { $ratio1 = $od_amount/($amount-$order->info['tax_groups'][$key]); ////debug $tax_rate = tep_get_tax_rate_from_desc($key); $net = $tax_rate * $order->info['tax_groups'][$key]; if ($net>0) { $god_amount = $order->info['tax_groups'][$key] * $ratio1; $tod_amount += $god_amount; $order->info['tax_groups'][$key] = $order->info['tax_groups'][$key] - $god_amount; } } }
  3. 3. in function _sendCurl. Is in 1.07 and later (maybe earlier). 4. line 420 of ship_fedex.php in saturday shipping release. 5. the code really doesn't delete the order, but it appears to be deleted because after a cancel, the final orders screen doesn't show the order, because the sql query fails because there is no status 6 in the orders status file. There are two ways of addressing the problem. Add an orders_status 6 to to the orders_status file (ostensibly named Cancelled Shipping???), or simply return the code to an earlier version and use status code 2. My preference is the later, but I do not claim to understand why the coding change was made. 6. the readme.txt states: "Read install.txt for detailed installation information. The file includes all ne cessary code updates; you can also just drop the included files into a new oscommerce in stallation." However this is not true, because the file package does not (nor should it) contain configure.php. For a custom installation, the install.txt states. ## ## add to admin/includes/configure.php: ## // fedex define('DIR_WS_FEDEX_LABELS', DIR_WS_IMAGES . 'fedex/'); // fedex eof ## Hence, the correct instruction in readme.txt is that you can drop the included files into a new oscommerce installation AND make the change to configure.php. If you drop in the included files without making the change to configure.php, you will never see a printed label (because the directory logic will fail). -- These were all minor nits and my many thanks to those who worked on this contribution.
  4. FYI Installation Nits. I've just installed this contribution for the first time and ran into the following problems. The problems were minor, but it would be nice if they could be incorporated into a subsequent release. 1. Ran into cURL errors that some others have run into, and I had to add: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); in function _sendCurl(). My suggestion is to add this code preceded by a comment delimiter (//) and make a note in the install.txt 2. The fedexdc.php class is duplicated, but not quite, between catalog & catalog/admin. My suggestion is to make a note in install.txt to copy the catalog/admin/fedexdc.php to catalog/fedexdc.php and perhaps not include a copy in catalog/. 3. There is debug code in fedexdc.php that writes to a post.txt file but doesn't close the handle. My suggestion is to remove this code. 4. EMAIL_TEXT_CONTENT is not defined (bug introduced by recent saturday shipping release) 5. Cancel results in order status of 6. This was again a recent change. Older code returned the order into processing (2). My suggestion is that authors or modifiers of the cancel function decide on what is appropriate. If 6 is the answer, then the install.txt must be updated. 6. The fedex readme.txt should be modified to state that the change to configure.php is necessary on a virgin ms2 install; i.e., just copying the included files on a full distribution will not install the feature without making the configure.php change.
  5. For my installation I had the following issues. 1. I had to change the sql query to use final_price rather than products_price to allow for orders that have been modified for discounting. 2. I had to add a 0 manufacturers_id to the manufacturers table so that the sql query would pick up products that had no manufacturer. 3. In order to match the actual sales for the period, total order discounts also have to be figured in on a separate line. This is an issue for those who us the Gift Voucher contribution. It entails summing the order_totals "other" class for the period.
  6. I agree this is a flaw, but should be easily fixed. Luckily in my installation I only have one extra class for now so it works for me. There is yet another flaw in the report. The "Taxed Sales" is a total of subtotals that have tax. When a single order contains both non-taxed and taxed items, "Taxed Sales" will include the non-taxed items, because the subtotal includes the non-taxed items. Unfortunately, there are not separate totals for taxed and non-taxed items in the orders_totals table. For my installation, I changed the code to resum the orders rather than use the subtotals in orders_totals. This works for my installation but may not work in other installations where other manipulations of subtotals occur during order processing (i.e. discounting, surcharges, etc). Here is the code: // changed code to sum order for tax rather than use orders_totals // necessary when order contains both taxed and non-taxed items // // sum of order products taxed $taxed_query_raw = "select sum(round(op.final_price*op.products_quantity,2)) taxed_sales, monthname(o.date_purchased) row_month, month(o.date_purchased) i_month from " . TABLE_ORDERS . " o left join " . TABLE_ORDERS_PRODUCTS . " op on (o.orders_id = op.orders_id)"; $taxed_query_raw .= " where op.products_tax!=0 and month(o.date_purchased)= '" . $sales['i_month'] . "' and year(o.date_purchased)= '" . $sales['row_year'] . "'"; if ($status<>'') $taxed_query_raw .= " and o.orders_status ='" . $status . "'"; if ($sel_month<>0) { $taxed_query_raw .= " and dayofmonth(o.date_purchased) = '" . $sales['row_day'] . "' group by dayofmonth(o.date_purchased)"; } else { $taxed_query_raw .= " group by month(o.date_purchased)"; }; $taxed_query = tep_db_query($taxed_query_raw); $taxed_this_row = tep_db_fetch_array($taxed_query); // // subtract "other" row from taxed sales // "other" is a global order discount, but to minimize taxes // we assume that the discount comes from taxable sales first. $taxed_this_row['taxed_sales'] += $other_this_row['other'];
  7. For my heavily modified MS2 code, the Monthly Sales & Tax Report 2.1.1 did not correctly calculate the taxed/non-taxed detail by day (i.e. report after clicking the month). The reason is that: if ($sel_month<>0) { $taxed_query_raw .= " and dayofmonth(o.date_purchased) = '" . $sales['row_day'] . "' group by o.date_purchased"; } else { $taxed_query_raw .= " group by month(o.date_purchased)"; }; needs to be: if ($sel_month<>0) { $taxed_query_raw .= " and dayofmonth(o.date_purchased) = '" . $sales['row_day'] . "' group by dayofmonth(o.date_purchased)"; } else { $taxed_query_raw .= " group by month(o.date_purchased)"; }; The reason is the sql query would not sum if the date_purchased was in datetime format, because the times of the purchases would differ would differ. I am not sure how this ever worked for anyone else but as I said, my code is heavily modified and perhaps entries in my database differ. Sorry if this has been mentioned before. I did read through the thread and did not find any mention.
  8. Problem report: Editing a coupon with coupon admin resets the start/end date of the coupon. There is some code that tries to retain the old start/end date, but it didn't seem to work on my system, so I had to change it to make it work. I was just wondering if someone else could confirm they had the same problem or if I have a install problem.
  9. What are your settings in Admin->Modules->Order Total->Discount Coupon? Try setting recalculate-tax to true. Hope that helps.
×
×
  • Create New...