Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

zzfritz

Archived
  • Posts

    496
  • Joined

  • Last visited

Everything posted by zzfritz

  1. Your first suspicion is correct: this contribution is obsoleted due to a change in whats_new.php. The contribution is a modification to whats_new.php v1.30, and the current version is v1.31. The difference causing your problem is that the infobox_box_contents array no longer has the text alignment in it, so this $info_box_contents[] = array('align' => 'left', 'text' => 'BOX_HEADING_SHOW_RANDOM' should be $info_box_contents[] = array('text' => 'BOX_HEADING_SHOW_RANDOM'
  2. There is no "best" payment solution for all stores. What is best for you depends on where you are, what your sales volume is, and how your customer base accepts the alternative choices. Some of the payment gateways are targeted to the Europeans and others to the US, their fees vary widely depending on volume, service level and startup cost. One of the problems with asking this question here is that forum rules prohibit touting or promoting commercial services.
  3. It is useful to know that many appreciated the prior attempt to summarize taxed vs. nontaxed sales, for the same reason I did. Indeed, it was meant to please an accountant. One uncertainty I had about taxed/nontaxed is this: should the distinction be based simply on whether the products were shipped inside or outside the store zone (the presumptive basis for sales tax in the US states). Earlier versions of the report divided the product subtotals this way. The alternative, employed in version 2.0, is to summarize the subtotals of orders which had some tax charged, and those which had no tax. This has the virtue of being apparently independent of the reason for charging tax (i.e., not based on the shipping destination). But it could be deceptive if an order included some taxed and some nontaxed items, in which case to get an accurate summary the report would have to walk through each product of each order as the checkout process did. I am not even certain that all the details available at checkout are retained in the database to permit such an approach. Maybe I should post three variations of this report: one without the taxed/nontaxed columns, one with the columns based on store zone, and one based on whether tax was charged. Opinions, please?
  4. Version 2.1 is released today, as announced here: http://www.oscommerce.com/forums/index.php?act...ndpost&p=345315 Reluctantly I removed the "taxed" and "nontaxed" columns, which were among the original reasons I wrote the report in the first place. These were meaningful only for stores which assessed tax on some order but not on others, and there are too many variations and uncertainties to be accommodated without the ability to configure the report. Someday (please, Harald) reports will be modules with configurablity. Now there is no assumption about the relationship of the orders_total components, so the report should make sense for all stores. Translations of the language files for german and espanol would be appreciated, and included in the next release.
  5. Talon's well known error message is the one indicating some script has a space or extra new line character at the end. Probably happened when editing. For those having a failure on the Save CSV, I am reviewing the coding standards for SSL since this is most likely where I failed to anticipate the compatibility problems.
  6. To Chris, this is and will remain only a financial reporting tool and not a marketing tracker. I agree that the marketing report would be valuable, but it should not be piggybacked onto this one which is already crowded enough. To Wicked and the Germans, the language is not the problem but perhaps the difference I had not anticipated is in the way your order totals are composed. My assumption in the financial calculations was that ot_total is the sum of all the other entries for the order (ot_subtotal, ot_tax, ot_shipping, ot_loworderfee, etc). If that is not correct, I need to be educated. Maybe we could private message and share some data for testing. kooyan, version 2.0.1 should work on both MS1 and MS2 since the structure of the orders and orders_total tables is the same. I will keep plugging away with this. The next enhancement that I am testing is a popup window that shows the breakdown of taxes for each month or day. If you have more than one tax class (for instance, two different VATs or maybe a sales tax and a luxury tax), the subtotal for each will be given. The main purpose of this report is to assist stores in maintaining and reporting the sales and tax data required by their jurisdiction's taxing authority.
  7. You're not giving us much to go on, but if you lost all database info (in particular, the configuration table) then you must re-enable all the payment and shipping modules in Admin. In the case of USPS, you must re-enter the USPS User ID and Password that you must have obtained if your store was previously operable. This forum contains thousands of warnings about backing up your database.
  8. The shipping module takes as the shipper's postal code the value set at Admin -> Configuration -> Shipping/Packaging -> Postal Code. Make sure this is correctly set in your store.
  9. Okay, but WHAT contribution is it? It is probable that the script should contain a reference to TEXT_PRODUCT_META_INFO and that is misspelled. But we are working in the dark here ...
  10. The miscalculations have been corrected in v 2.0.1, just uploaded: http://www.oscommerce.com/community/contributions,539 This upload includes the missing language files, for whose omission I apologize. Please share your corrections and improvements to the translations. To rename the "extra" column, edit the define statement in the language file for TABLE_HEADING_OTHER at about line 41.
  11. This is the support thread for version 2 of the Monthly Sales & Tax report contribution, announced here: http://www.oscommerce.com/forums/index.php?showtopic=86986
  12. One puzzling obstacle in an otherwise excellent test of uploading, maybe someone recognizes what I have not -- Although the first column of the uploaded spreadsheet has unique values of mixed text and numerics as products_model, EP is loading them with a leading comma-space (", "). Example: "WN00001" becomes ", WN00001" I studied the code but cannot find how, why or where this is being done. The text file is correctly tab-delimited, and all other fields are being properly handled. Only the model number (really should be called SKU) is being altered. Anybody have a clue?
  13. Pay attention to the ouput messages from the script. Your product numbers are not unique, so the subsequent occurrences are acting to update rather than add. It told you so, and even put a warning at the end. This contribution assumes, and its documentation emphasizes, that the first column (product_model field) must be unique.
  14. http://www.oscommerce.com/forums/index.php?sho...=0entry323450
  15. It is true that the ZIP-plus4 is not accepted by the USPS API, and probably should be truncated in the module code to make sure it isn't being passed along. As it happens, I am also installing a new store with MS2 this week and will necessarily upgrade this contribution. Thanks for the first tip.
  16. To distinguish taxable from exempt orders, the report logic compares the value of the delivery_state field in the (orders table entries) against the store zone, as returned by the tep_get_zone_name function. There was a revision to that function call several months ago, adding two parameters. I suspect this is the culprit. What did work in version 1.5 of the report was the call tep_get_zone_name(STORE_ZONE) My best guess at the correct new call (I could find no public documentation of the change or specification for the new parameters) is this tep_get_zone_name(tep_get_country_name($country_id), STORE_ZONE, STORE_ZONE) but maybe that is wrong. Perhaps someone more familiar than I am with the core functions could see the problem.
  17. I am the author of this contribution. In the current version of this report (1.55), the "taxable sales" column is calculated as the sum of order subtotals for orders shipped within the store's own zone. This should produce correct results for stores having a single tax zone for the store's home location. The assumption is stated in the "install.txt" accompanying the contribution: "Taxable vs exempt sales totals are based on the store zone." But for stores having more than one tax zone, or imposing tax for zones other than the store's own location, the "taxable sales" column will not be correct. Even for these stores, however, the "tax paid" column will accurately reflect the sum of taxes on the orders. The logic currently employed is very simple: as the entries in the orders_total table are scanned, the subtotal entries are added either to the exempt or taxed column based on whether the order delivery state is identical to the store zone. Perhaps the column headings should read "shipped within zone" and "shipped out of zone". The original goal of this report was merely to summarize by month the gross sales and the elements of the order totals (subtotal, shipping, tax, low order fee, and other), by reading only the orders_total table. I added the taxable and exempt columns simply because these could be summarized for the simplest case. The logic to determine taxable vs. exempt sales for other cases is much more complex and requires probing around in other database tables.
  18. Meanwhile, I just posted UPS Choice 1.8: http://www.oscommerce.com/community/contributions,528 Not a big deal, just upgraded to the most recent scripts on MS2.
  19. The correct version for MS1 would be UPS Choice 1.7. Does the standard UPS module work okay for you? If not, as I suspect, the problem is not with this contribution anyway. The email hook sends an email only if the http connection to the UPS web site was successful, so that lack of an email suggests a socket failure on your server.
  20. Fortunately, the authorizenet module in MS1 and MS2 uses the currently supported protocol, not the old method variously known as "relay response" and "WebLink". The protocol named ADC is employed by Bao's contribution: http://www.oscommerce.com/community/contributions,725 but that requires curl which not all servers provide. Authorizenet created enormous confusion by the way it named the protocols, as you can see in the announcement last October: But the bottom line, and the answer to your post, is that the standard authorizenet module in MS1 and MS2 uses SIM.
  21. Moderator comment: Posting that much code is never necessary and always annoying. Just refer to cvs scripts by their fully qualified names and version numbers. A revision of this contribution for MS2 is now available: http://www.oscommerce.com/community/contributions,487 Unfortunately I have not had an opportunity to test it, so confirmation of its effectiveness will be appreciated.
  22. The company UPS has a new API that supports all countries, but osC uses their old API that does not. That osC uses the old "deprecated" cgi/API is a subject of many posts. Unfortunately none of us has implemented the new module yet, and the core developers are properly immersed in just that -- the core.
  23. If the insurance charge is a fixed amount per order, you could just use the handling charge capability added to the shipping modules in MS1. You could change the phrase "Handling Fee" to "Insurance Charge" where it occurs in the shipping modules themselves, so it is labeled correctly.
  24. You can re-order the array built by the UPS shipping module, either the cvs or the UPS Choice variation, before it is returned to checkout_shipping.php which presents the choices to the user. At line 104 of ups.php v1.53 or v1.54, or at line 122 of the variation of v1.53 included in the contribution UPS Choice 1.7, add this statement: array_multisort($methods, SORT_NUMERIC, SORT_ASC);
  25. Okay, here's a win: I posted version 1.55x for those without file save capability (a temp file used to export the csv feature). http://www.oscommerce.com/community/contributions,539
×
×
  • Create New...