Search

[tbergman73013]

We have finally engaged in the process of moving our charging over to SM, well, evaluating it with that goal in mind. Two things we saw immediately have caused us to reconsider. First, we have found that the update status procedure is deadly slow, taking way too much time so we will have to find a workaround for sorting our orders by status so that we can charge just those that we are ready to ship.

The second problem seems to be a bug. We have an order in yahoo store (legacy store) that was charged, however, in SM it shows open status. We have changed the status in SM to charged, but when we update from the store, it returns it to open status. We submitted the batch and tried it again, but still updating from the store causes the order status to be returned to open. If we cannot rely on the status of orders in SM, even when recently updated from the store to be correct, we have a very serious problem. Help please?

Thank you.

Tom

[David Johns]

Tom,

Glad you are trying to use SuperManager to help you with charging your orders.  I hope we can get it working for you.

For the first issue - I may not understand what you are trying to do.  When you charge orders through SuperManager there is generally no need to update the status.  I'm guessing that someone else is processing your shipments for you and you need to check which ones have tracking numbers.  Is this the case or is there some other reason you need to update the status of the orders before charging?

For the second issue - How was this order charged?  Was it charged for the full amount?  SuperManager will only mark an order as charged if the amount charged equals the amount due.  If it doesn't, you'll need to modify an item price, remove an item, add or change a total to justify why the amount received isn't the amount due for the order.  This is further discussed in the manual under the heading "Moving Orders from Open to Closed".

Thanks,
David

[tbergman73013]

The order in question is an ordinary order with the same amount authorized and charged, and with no modifications made, other than to try and change the status. We cannot get SM to recognize that this order should be closed.

Also, can you tell me if SM should be slow in opening an order across a peer to peer network? All the actions seem to take forever when we access the smg file across our network.

[Mike Griggs]

Hello,
Please do the following for me to help us debug this problem..

1. double click on the order to open the Order Details Window
2. locate the "Order Totals" section towards the bottom of the window
3.  There is an "Amount Paid" total and an "Amount Due" total.
4. What numbers do you see next to the Amt Paid and Amt Due?

Slow network problem..
Have you installed the supermanager on each networked computer?
and you are simply opening the supermanager database file across the network?
Depending on the file size it could take some time to open the file but once the file is open you should be able to work with it as normal.

Do you have autosave turned on for every 5 min or so?  If you do then try increasing this to every hour and maybe this will help.

If you can give us more information about your network setup then we might be able to help.

Thanks!
Mike

[tbergman73013]

Okay. I think I have it. We use multi-pricing in our yahoo store, and when we updated from SM to the store, it rounded the unit price up and changed the order amount!

Does that mean that when we update from SM to post our shipping info, SM Will change all the orders that have odd pricing due to our use of the multi-pricing method? Yikes!

I will try your suggestions on the slow load times. The file I am working with is fairly large at 29MB, about 6 months of data in it. We have since decided to keep a much smaller number of orders in our active file. I was hoping we could use SM for order research, but the slow load and access times makes this impractical, so we are back to using SM as an order processing system which is what we go it for. Now if we can just get past this hurdle.

Thank you.

Tom

[tbergman73013]

I did a little more searching and SM is apparently supposed to handle quantity pricing correctly, however, in our case it is choking on the rounding. The case in point is a product with the following quantity pricing setup: $.50 200/$9.00, 2000/$79.00. This customer bought 401, so the price was $.045. The shopping cart truncated the price at $.04 and SM rounded it up to $.05 resulting in a new, higher cost in the order, and so it would not close the order. So, now that I understand (or at least think I do...) how do we fix it?

Thank you.

Tom

[David Johns]

Tom,

So in this cirumstance there are several ways to calculate the prices:

1. $9.00/200*401=$18.045, then either round to $18.05 or truncate to $18.04
2. $9.00/200=$0.045 each, rounded to $0.05 each * 401 = $20.05
3. $9.00/200=$0.045 each, truncated to $0.04 each * 401 = $16.04

It seems SuperManager currently does #2.  Is #1 or #3 what you think it should be doing?

Thanks,
David

[tbergman73013]

The store uses number 1, so SM should too.

Thank you.

Tom

[David Johns]

Tom,

I found an approach to fix this and am almost finished.  Just to be clear, in the case you stated, did Yahoo calculate 18.05 as the total or 18.04?

Thanks,
David

[David Johns]

Tom,

I just released beta version 1.4.0.1 which should resolve this issue.  Please use "Help" | "Check for Updates" to install the new version.  Give it a try and let us know how it works.  For this particular order, you may need to go to the item details screen for the item that has the wrong price and manually enter "0.045" in the price box.  Future orders should not be changed from the proper price.  Try it out and let us know how it works.

Thanks,
David

[tbergman73013]

David,

We have had two orders with a penny difference, and I have given up on worrying about the differences between the way SM Charges the total and the way the store computes the total. In addition to the rounding difference, our orders look stupid because the subtotal is incorrect, given the quantity and price as shown on the invoice. I am changing all my quantity price settings so that the cart will never get a third decimal outcome from the necessary division when customers buy unusual quantities.

I will update our versions (currently 1.4.0.0) as soon as I can. I have looked and the later version does not appear to be available?

Thank you again for your help.

Tom

[tbergman73013]

I was able to update to 1.4.0.2, so we will see if we keep getting differences. Hopefully between my corrections of the quantity pricing and the update, this problem will go away.

Thank you.

Tom