Jennifer,

Exactly!  I've submitted this to ASI awaiting to see if they are going to fix this.

We also wanted to use the public interface to allow our staff to pull free copies out of inventory for any trade shows they may attend.  Thus allowing us to keep inventory properly accounted for.  It seemed that if the special pricing did work correctly through the public interface with a $0 amount, it would take away the need for all the additional steps needed on the desktop client side (batch creation, etc...).

Just my 2 cents.

Ryan

I received this back from ASI Tech Support today:

>>

Hi Jennifer,

This is a known issue that is fixed in 15.1.3.7542.

An attempted workaround from the original issue, but still does not provide correct results:
You want the first product to be free and each one after that to be .37. Add this item to a category in your store and login as an M customer type (the customer type with special pricing) and view category. You get the array error.

Now go back and change your special pricing to
1 / 0 / .01
2 / .37 / /37

You should no longer get an error, but if you choose quantity of 2, it charges you .38 - therefore not a good workaround.

>>

Not sure I understood how that workaround was a workaround, but there you have it!

Jennifer Strawn
Accounting & Association Software Group

Really,

That looks just like the work around they tried to give me when I was running version 15.1.3.6699. As a matter of fact, that is the same pricing (.37) I used when I reported the issue! I've recently upgraded to 7542 (well I think it was 7542) but it didn't mention anything about fixing special pricing. We ended up having to offer an electronic version free via a link using some custom work on the store where we had the other description put below the web description. It costs money but we had to do something.

I'll let you know if they reply to my original submission on this issue. It's been over 45 days since I submitted it without a true fix though.

Ryan

In the next few weeks, I am going to install the latest version on our dev site, so I will test it here to see if it fixed the issue. I'll let you know.

Jennifer Strawn
Accounting & Association Software Group

I just confirmed that I'm running 15.1.3.7542.

I had a product kit setup with a regular and non-member price (same amount for each).  I already had a special pricing rule set with a flat amount = $0.  Didn't work!  Still charges the regular or non-member price.   Let me know if you find anything different.

Ryan

ASI notification received today:

Your Issue "An error occurred while loading the product list" has been updated with the following response:
 
ASI Response:
This issue has been tested and closed and will be available in the iMIS 15.1.3.7848 software update.

This was how I originally found that the $0 issue was an issue. Hopefully they fixed the underlying special pricing problem to fix this one.

Edit:
It does look like the next build should address special pricing.

Another ASI notification received.
Subject: Re: Your Issue "Special pricing of $0; M/NM pricing set" 
Your support Issue has been updated with the following response:
 
ASI Response:
This issue has been tested and closed and will be available in the iMIS 15.1.3.7848 software update.
 
Ryan

Hopefully they got it right this time! 

Jennifer Strawn
Accounting & Association Software Group

Jennifer,

I installed the 7848 patch hoping to be able to offer the 1st item free.  This patch does allow you to give the first one away free, BUT it doesn't (or maybe I don't) know how to calculate any additional quantities properly. 

Using my original number $0.37 for the base of each item.  I setup a Source Code of Order_Lines.QUANTITY_ORDERED and then set Units/Code = 1 Base Amount = 0 Amt/Add'l Unit = 0 

Then I added Units/Code = 2 Base Amount = .37 Amt/Add'l Unit = .37 

The first is $0, but then here are some examples of the charges calculated for additional quantities:

Examples:
If I enter a quantity of 5 it charges 1.50 instead of 1.48.
If I enter a quantity of 10 it charges 3.30 instead of 3.33.
If I enter a quantity of 100 it charges $37 instead of $36.63.

These are just some random quantities I entered.
 

Ryan

Ryan,

It may seem a little strange but here is the explanation.

The Unit price of each item needs to be an even penny. That is probably a good idea for refunds and such. That means that if the first item is $0.00 and the next 4 are .37/each then you might expect the total cost to be $1.48. However when you divide $1.48 by 5 to get the unit price you end up with .296 cents each. That then gets rounded to .30 cents (an even penny) and then that unit cost is multiplied by the quantity to get your $1.50.

We built a custom cart for some of our clients and coupon codes and discounts end up creating the same rounding issues.

I don't have any slick workaround but you could add some more unit entries in the grid to better control the total price up to a certain level.

Thanks,

Randy Richter

rrichter@atsol.org

Hey Randy,

Thanks, for the quick response! 

I'll start by stating this is WAY outside of my understanding!

But that make sense to me for a flat pricing model, but wouldn't the calculation/logic have to change to accommodate ANY special pricing rule discounts?  For example use a specific calculation/logic for each discount level in the special pricing rule and then combine the totals for any of the discount levels hit for each product (similar to a cart). 

Here are my thoughts on this, using the shopping cart and manually adding items when the discounts should apply as a model/example:
Have a general/base product setup with maybe a base price of $0, add a kit with the same product with a quantity of 1 with your base/core price, then add other kits for your discount levels with the appropriate discount price.  Add items to the cart whenever you hit the discount levels using the appropriate kits.  It would add a little more processing time to get the correct price, but I don't see how you can offer special pricing if you don't use a specific calculation for each discount level in the special pricing rule.   

Right now the only problem is that we say it costs one price, but what the system calculates doesn't match what we say.  I know that ultimately we would be refunding the same amounts since it would do the same calculations, at least I think. 

I tried using an even number ($0.50) for our pricing, but it still has problems with certain quantities when it does the calculations.

Examples:
If I enter a quantity of 1 it charges $0.00 this is correct.
If I enter a quantity of 2 it charges $0.50 this is correct.
If I enter a quantity of 3 it charges $0.99 instead of $1.
If I enter a quantity of 4 it charges $1.52 instead of $1.50.
If I enter a quantity of 5 it charges $2 this is correct.
If I enter a quantity of 6 it charges $2.52 instead of $2.50.
If I enter a quantity of 7 it charges $3.01 instead of $3 
If I enter a quantity of 8 it charges $3.52 instead of $3.50.
If I enter a quantity of 9 it charges $3.96 instead of $4.
If I enter a quantity of 10 it charges $4.50 this is correct.
If I enter a quantity of 100 it charges $50 instead of $49.50.
If I enter a quantity of 150 it charges $75 instead of $74.50.

Thanks,

Ryan

Ryan,

I can't defend how iMIS does this. If you wanted to handle this manually in iMIS you could do the following.

Assume product PUB1 is setup as the first is free and the next ones are $.50/each.

In iMIS the order could end up in one of the following ways.

Order line 1 - PUB1 1 @ $.00 = $.00

Order line 2 - PUB1 2 @ $.50 = $1.00

Total price $1.00

OR

Order line 1 - PUB1 1 @ $.34 = $.34

Order line 2 - PUB1 2 @ $.33 = $.66

Total price $1.00

The first woudl probably accurately reflect what you woudl want to show on the receipt. Again though on refunds and such staff would need to refund the right quantity on the right line item. That would mean though that ASI would have to modify their cart so that it looks correct to the person throughout the purchase process and then at the very end store two orderlines in iMIS instead of just 1 order line with the rounded average price per unit.

I have tried to buid systems that don't round and just take into account the actually extended price. But with the IBO's the total amount of the order has to exactly match the credit card charge you put in iMIS. And you can't/don't want to charge a person $.33333333333 cents on the credit card. In paypal you have to charge them $.33 or .34 (always round to the nearest penny.

It has come down that you have to balance what the system forces you to do and what you can live with from a rounding point of view. The exrtra workaround for two order lines instead of one would work in the desktop but not in the out of the box automated cart.

Sorry that there isn't an more straightforward solution to this.

Thanks,

Randy

I guess I'm just a little suprised I don't see this more frequently with other websites that sale products.  Maybe I just haven't purchased anything from any iMIS sites that use special pricing.

Ryan

Now, I'm not getting my hopes up just yet, but I just tested this again on our demo site running 15.1.3.8125. Again, I was trying to achieve "first one free, then $5.00 each after that". I found that if I put in special pricing like this:

Units/code - Base Amount - Amt/Addl Unit

1 - 0.00
2 - 5.00 - 5.00

then in the iMIS Desktop and in the public views, it was returning pricing like this:

Jennifer Strawn
Accounting & Association Software Group

I didn't see anything in the "Resolved Issues" area for this release. Please post back to let me know if everything went as planned!