Tuesday, April 5, 2016

Change is good.

I started my post many years ago and every now an than I would update it.  Actually, there are so many things to do and so many content on the web that I nearly forgot I had a blog page started.  Well, it's time to get busy again.

I've decided to change the title of this blog to something more universal.  Now I am focusing more on general programming topic and tips.  Everest ERP system has taught me a lot about programming, but it's a dying Application.  Ever since it was bought out by Versata it has been steadily going down.  Not much has changed over the versions.  The company has a big ego, I am not sure if it's related to the CEO or not.  Let me note a couple of them here.
  • They have a customer satisfaction rating system call "Wow Support".  It seems like such a great program.  Customers are actually Wow about their service.  And they always have a 98% rating.  They show here how Versata Wow is calculated. I am sure they don't lie here, but what they fail to tell you is what they determine "Good, I'm Satisfied" is to be.  Simply there is only yes an no answer.  The one question that gives a good response is, was your problem solved?  In the context of the survey it really shapes the result that they want.  But it's not a scale rating, just a yes or no.  It doesn't survey how long it takes Versata to respond to your issue. It doesn't give you a chance to rate the agent serving you. 
  • In the past, they had a phone system that was so bad, you couldn't hear them.  But now it's not so bad.  But when you did the survey, you couldn't rate that problem or give feedback.
  • Then they got smart and decided that you should call them back instead on a land line number that is not local.  This way they can save some money on the call. Of course, you can't call that number for raising issues.  It's part of their Gotomeeting platform.  Talkin about cheap or just pure genius for the CFO.
  • Versata don't really want to listen to what the customers want.  I always thought the system is very good and it's still is. But what they lack is the API functionality for Credit Card Processing.  They have the object, but somehow refuses to allow access to it.  It's the one thing that can make this application great.  We need it to use on our website at the payment processing part of it.  Using it will seamlessly integrate with the rest of the system. 
That is enough rambling.  I believe all my customers will be moving away from Everest very soon.  They are lagging behind so many other ERP solution providers.  Good luck Versata...Good Luck Everest. 

Thursday, July 9, 2015

Hiring on Guru by SafePay. Not as safe as you think

I've used Guru since 2005 and had great success with hiring people from here.  But I haven't used it in a while.  But Guru added a new feature called SafePay, which I think it is a great feature as it allows the employee to reassure payment and that the employer only agrees.  d

But what they fail to advise or left out an important piece of option. Called "Auto-Pay".  This allows the employees to get paid on a certain day, which most select 7 days.  So if they didn't finish the work, they still get paid.  And there is no way to stop it once you deposit the money on Safepay. There is no way to get a refund or dispute with Guru.  They will not help.  Once the money is transferred, you are pretty much left on your own.

So if you want to avoid this headache, either not deposit any money into safepay amount or don't use Guru at all, which I will no longer use.

If you see by the email with my conversion with Guru, the information that is given during my email, is not revealed readily.  It's actually quite deceiving that they say Safepay allows the employer to know that there is money in the fund to pay for the project and only when the employer agrees with the job then it will be released.  And when I read it, it is was I thought it to be.  The Autopay is not an option for the employer to choose, but for the Employee to control.  

So please becareful about how you work with Guru.  It's very deceptive in how they promote their payment method.

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.