Friday, October 17, 2014

It's been a while

I haven't post in such a long time.  It doesn't mean that I am not involved with Everest any longer, just busy with other projects.  

After the selling off of Everest to another company, the product has been lack luster.  There hasn't been much improvement.  As a matter of fact all the strong point of Everest are slowly disappearing.  The promise of .Net never materialized.  As they could not get it to work correctly.  And soon will be abandoning the ecommerce module all together.  As the current V6.26, there are no more ASP install program.  Which means, they will not support it any longer.  

It's understandable that the old classic ASP has to go eventually, but wouldn't it be nice to have .Net working before terminating the classic ASP.  .Net by the way has been an on going project about 5-6 years ago.  Going at this rate, I think they should just drop the .net and adopt a new technology, as .net itself may change.  They just can never get it working right.  But the .Net version is so unreliable and also not open source code.  You can customize it, but very little.

What Everest needs to focus on is the SDK.  Making it stronger for the e-commerce.  Especially Credit Card processing.  They already have an awesome SDK, just need to build more objects instead of trying to build an ecommerce template, which most people end up customizing themselves anyway.  Their template is so dated.

Tuesday, December 20, 2011

Everest ERP UPS Freight Rate Import Bug

For those of you importing UPS rates into Everest via the Rate import utility provided by Everest.  You will encounter a flaw in the import.  It is not apparent until you start shipping international and more than 50lbs.  What makes matter worst is that it works and does not work depending where the weights falls.  First we must understand how Everest import the rates.  Everest makes the assumption that every rate will be in increment of 1 lb.  When in fact it does not.  This is the case when it's an international rate.  In the example below, you can see that UPS has increment of 2lbs for 50 and over. Note: They also change to 5 lbs increment for 100 lbs and above.
UPS Rate Table

But then you see that when Everest imports the rate from UPS, it makes an assumption that everything is in 1 lb increment. So you can clearly see that if a weight falls between, 74.01 to 75 lbs, it will not calculate the shipping rate, because it simply does not exist.
Everest Freight Rate Table

I did contact Everest before, I don't remember when, but it was a long time ago, but they have not recognize it as a bug at that time.  Well it is a bug.  But very simple to fix.  All they have to evaluate the two rates and this way they won't make the wrong assumption.  But that is Everest.  So..... I am going to post the sql script to fix the problem.

Update fritrate
set docwtfrom=docwtto-1.99
where zonecode=634 and docwtfrom>50 and docwtfrom<100

Update Fritrate
set docwtfrom=docwtto-4.99
where zonecode=634 and docwtto>100

Replace the 634 with the appropriate zone. Remember this will only work for UPS format, others I do not know.