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.