Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

zzfritz

Archived
  • Posts

    496
  • Joined

  • Last visited

Everything posted by zzfritz

  1. Ah, the pesky "standards update" removed the private function tep_array_merge in favor of array_merge available in PHP4. The script has been revised to reflect this change, and version 1.55 of the contribution is posted here: http://www.oscommerce.com/community/contributions,539 Regarding insertion of file name defines in application.top, that will work but there should be new instructions in keeping with the design change this month: all the filenames have been moved out of application.top into a new file named filenames.php. Most of us choose to keep the alphabetic order of these defines.
  2. On this page there is a great big link to "Contribute a new package" on the right side under the list of newest contributions: http://www.oscommerce.com/community/contributions The correct Package Category for a button image contribution would be "Images".
  3. Holy cow, has anyone else noticed that the contributor Warren has achieved "Banned" status? I have not determined how or why. The inability of the contributor to engage in the discussion of this rather important contribution creates a hopeless situation. What can we do about this? Can he be rehabilitated?
  4. For Anthony and others whose servers deny permission for file saving, version 1.54x has been posted with the csv capability disabled: http://www.oscommerce.com/community/contributions,539
  5. The missing parameter problem is fixed in rev 1.54 just posted: http://www.oscommerce.com/community/contributions,539
  6. The contribution has been revised to include the additional parameter in the call to tep_get_zone_name, and to omit the csv capability if the user does not have file save permission. http://www.oscommerce.com/contributions/Mo...les&Tax1.53.zip
  7. We may not all have the same expectations for how this contribution should behave, since the author's initial description was unclear. One strategy would be to enable customer order modification ONLY due to admin intervention (for instance, because a given product is not available with the attributes selected), in which case the admin/orders.php "restore" button may as well put the products back in the customer's shopping cart immediately. An email notification should be generated, directing the customer to revise the order was cancelled and the products restored to the shopping cart for possible resubmission. In this model, the order itself may as well be deleted and not just given another status. The other, more complicated, strategy that I suspect the author had intended would be to permit revision of orders by customers at any time prior to the order status reaching a specified point in its progression, WITHOUT admin first intervening. On top of this, admin can ALSO kick an order back to the customer for revision or cancellation. This model uses order status as the key to whether the order can be revised. I would have been satisfied with the first strategy. To accomplish all the goals of the second strategy, I think the contribution needs a bit more development (clarifying the distinction between "cancelling" and "restoring").
  8. Well, I finally got an order into a state that showed the "change/cancel" button on the customer side, but not by using the "restore" button in admin. The "restore" button for admin/orders.php sets the order status to the value selected in config for "cancelled by admin". And that is one of the status values for which catalog/account_history_info.php will NOT display the "change/cancel" button. I edited the order in admin, changing the status to Processing, and BEHOLD the customer side showed the "change/cancel" button. When that button was clicked, the order contents were put back into the shopping cart and the order status was set to the value selected in config for "cancelled by customer." So, it appears to me that the "restore" button in admin is misleading. It really is "cancel by admin". There should be two buttons in admin, one for "cancel by admin" and another to "restore", and config needs another selection to choose what status code should be applied with the "restore" button.
  9. Marcel correctly identifies that the contribution's assumptions regarding the ranking of order status codes is a flaw. I am going to try adjusting the orders_status_id field in the orders_status table, directly, to see if the behavior can be corrected. But, the other question remains unaddressed: when the order is "restored" from admin, why does it have a "cancelled" status? These words have seriously different meanings. If you intend a distinction, please explain, otherwise adopt consistent terminology.
  10. Congrats on a very significant contribution, the best solution to most order edit needs: putting it back on the customer for resubmission. The install was easy and the configuration panel mostly clear. BUT there appears some confusion between the words/concepts "restore" and "cancel". When you click the "restore" button in admin/orders.php, the new status for the order is set to the one selected in configuration as "Set Order Status Of Orders Cancelled By Store Administrator To". Shouldn't the restored order be set to some other status that is recognized as being editable on the catalog side? (How does the system determine ranking among the status codes, anyway?) I took the suggestion of creating two new status codes, Cancelled by Admin and Cancelled by Customer, and selected them for the choices by the same name in configuration. And I chose "Processing" as the highest status permitted for restoral. My installation is a pretty fresh MS1, with no attribute mods. However, I have yet to find a combination of config settings that gives the customer the choice of revision or cancelling the order. The new button never appears, so I didn't get the chance to "watch the magic happen." Help would be appreciated by anyone who has this working.
  11. Daniel: similar error message have been reported by two other users of USPS Methods 2.4, but only when the transit time option has been selected. Until the problem has been isolated and resolved, we suggest that you disable the transit time option.
  12. sirkyle, UPS Choice is not compatible with pre-11/2002 snapshots. It appears that you have a version of admin/includes/functions/general.php earlier than 1.143, which indicates that your site requires updating if you wish to use this and other contributions for shipping and payment modules.
  13. Terral, this error results from the way you made the edit to the admin function script general.php, in step 3 of the installation instructions. Somehow you introduced an extra space or new line character that should not be there. See this FAQ: http://www.oscommerce.com/community/faq,1-7/q,17
  14. That's not a sufficiently precise description to work from. The report just summarizes what is in the database orders_total table, so maybe that's where the problem is.
  15. Is there a progress report on this, Steve? Many are eager and hopeful for the contribution.
  16. Besides coding conventions, there is also an issue regarding how contributions should be packaged. Brad Waite and I have just had a private colloquy about this, on a contribution in which we collaborated. He preferred to post diff files, while I had posted replacement files in nested directories. Each package appeals to a different audience, so I proposed to release the contribution both ways simultaneously. Of course all contributions should be accompanied by a readme.txt or install.txt, which clearly describes the function, content and structure of the contribution, then lists steps for its installation. The contributor should also note the compatibility constraints (e.g., works only with checkout system post 20021101) or certification (e.g., tested with MS1). Let me take this opportunity to stimulate some discussion on conventions (or at least suggestions) for packaging contributions.
  17. To summarize the taxable and nontaxable goods, the report would have to review the order details that were processed when the order was made (the individual products, their tax classes and the associated calculations). I had intended to rely only on what is available in the orders_total table for the data summarized by this report (with the limited exception that the date the order was made is taken from the orders table). This illustrates the principle that no report satisfies everyone's expectations for it. Sorry about that.
  18. What livefooduk asks for is exactly what the report was designed to provide, an accounting summary from which to prepare tax filings. It works that way for me, only because I am in a US state where sales tax is charged for sales shipped within the state and my store has no other tax obligation. The leftmost column (1) is gross income, and indeed is the sum of columns 2, 5, 6, and optional 7 & 8. The troublesome columns, as I pointed out above in this thread, are 3 and 4 because making the distinction for taxed/exempt sales is not a simple matter. Up through version 1.5, the "exempt sales" column is the sum of the subtotals of orders shipped outside my store's zone, and the "taxable" column is the sum of order subtotals within the store's zone. That works for my simple situation, but not for others. The next revision, which is nearly ready, may be (almost) what you are asking for because it will distinguish taxable/exempt based on whether tax for the orders was zero. These columns will be the sum of order subtotals, which includes shipping only if you have set up the Order Total module that way.
  19. I have revised USPS Methods as version 2.3, with the most current cvs functionality for separate handling fee, sort order and tax class: http://www.oscommerce.com/community/contributions,487 This time the contribution is in scripts, not diffs, and the instructions are improved.
  20. I have revised USPS Methods as version 2.3, with the most current cvs functionality for separate handling fee, sort order and tax class: http://www.oscommerce.com/community/contributions,487 This time the contribution is in scripts, not diffs, and the instructions are improved.
  21. No, it wouldn't. As I mentioned above, the possible variations for summarizing taxable vs. nontaxable orders/items are endless. So we need to focus on what summaries have practical value. The elements of the report that are universally worthwhile are the columns that summarize the gross totals, product subtotals, tax, shipping, and the optional loworder fee and credit class amounts. The two extra columns were my attempt to enhance the report for the simple tax reporting obligation in most US states, where interstate sales are exempt. If there are a few other simple analogues useful in other jurisdictions, I will try to implement them for the good of the community. Suggestions are welcome if they are accompanied by an explanation of their pragmatic goal.
  22. Not quite sure I understand precisely what you are asking, and tax-related distinctions are quite tricky to implement since the world of tax has no limit to its complexity. It's a wonder the osC developers have been able to provide what is necessary for us to tailor the variety of taxing strategies which are out there, but apparently they have. Having the capability to calculate the imposed tax on an order is one thing, but to summarize the resulting taxes (or the sales from which they were derived) in a report is something else. The logic of doing it is backwards, so to speak, making inferences instead of imposing methods. I began with a very parochial (US) view of sales tax, a simple percentage state tax on selected merchandise with an occasional hike for local authorities. But now I realize that many of the other taxing systems are quite different, and perhaps beyond my ability to synthesize. The incremental improvement I will next provide for this report is to change the logic for distinguishing between what I characterize as 'taxed sales' and 'exempt sales'. Through version 1.5, those columns show the subtotals from sales shipped within vs. outside the store zone. That is not sophisticated enough in stores that charge sales tax for multiple jurisdictions due to having a business presence in them (which requires the imposition of the tax in the destination state), other than the store zone itself. So, in version 1.6, the taxed column will be the subtotal of all orders for which any tax was added, and the exempt column will be the subtotal of all orders for which no tax was added. A further planned enhancement will be to make the figures in the tax amount column be live links, which if pressed, reveal the breakdown of the figure by tax zone or tax type -- not interesting if you only have one tax zone or tax type, but essential information if you have more than one. The main purpose of this report is to extract the data necessary for preparing sales tax filings to the taxing authorities. So, to get back to the question, it might be yet another thing to look for sales based on whether the products themselves were exempt. That could be the same as what I will do in version 1.6, but maybe it is not.
  23. Michelle -- we determined that this behavior results from your having no sales in January, which is the month that triggers output of the yearly footer. The logic will be improved in the next interim release, a few days hence. Farrukh -- I believe you have misplaced the two scripts which comprise this report contribution. The larger one goes in the admin/ folder, and the smaller one with the define statements goes in the admin/includes/languages/english/ folder. Chris -- The next major revision of this contribution (maybe next month) will provide the capability to expand each month's summary line to show the daily totals for that month. But I resist adding things, such as number of orders, which are measures of marketing performance rather than accounting data. There is not room on the screen to include enough to satisfy both objectives, so these should be in separate reports. Other contributors are making efforts in that direction as well.
  24. Holy cow, Hobbs, you are quite correct. I thought that the introduction of the billing address was for just this reason, and assumed it was being used by the payment module. Blissful ignorance. This is a bug, duly reported and easily fixed, but oddly deflected by the team member. I see your insistent addition to the bug report today. While our attention is focused on AuthorizeNet, be reminded that the Relay Response method will be obsolete on April 30. We must all be using Direct Response (such as Bao's contribution) by then. http://www.oscommerce.com/forums/viewtopic.php?p=100743
  25. Order editing is a huge challenge, not yet adequately addressed by any contribution. But you could just save the display of invoice.php from your browser as a txt file, then edit it to your heart's content. I just tried this, and was disappointed to find that the results from IE6 were hard to work with because it does not retain the column formatting. But Opera 5.12 did a very nice job of padding the columns with spaces so it looks pretty good in a fixed width font such as Courier.
×
×
  • Create New...