Further, extract "usps_v3.php" into the 'shipping' folder of your shop replacing an existing one. Don't forget to make a backup copy of the current file in case something goes wrong.
*Note: as we can see USPS added some new shipping methods so we would appreciate if someone contacted USPS to provide the full list of supported shipping methods along with the countries and states they are used for.
Last modified: 13 Jan 2011 2:10 PM
rocketman
11 Jan 2011 4:27 PM
I uploaded the patch.. works very limited domestically.. No to international. needs a lot of work to make usable
Vera
11 Jan 2011 5:00 PM
I uploaded the patch.. works very limited domestically.. No to international. needs a lot of work to make usable
As we said, we appreciate all feedback. In order for more methods to show up you need to add more methods in admin and know their Shipping Code. We don't have such list on our hands and can't propose anymore methods.
Regards,
ViArt Team
rocketman
11 Jan 2011 5:39 PM
I will work to get you that information needed
8thSinCoffee (Guest)
12 Jan 2011 2:05 PM
This did not work on our prod 3.4.7 system, but did on a test version of 4.0.5. Some ugly XML errors.
What type of documentation do you want? If you have a 3.4.7 system it should be recreatable on your own.
8thSinCoffee (Guest)
12 Jan 2011 2:16 PM
Vera - I have my own home-grown rating tool that prints out all the rates in the XML response, and here is a list of the ones that come back for domestic shipping in the US:
For the time being, I'm using my own shipping methods I created, and have disabled USPS. It is unfortunate that Viart places a low priority on this, since those of us who actually use the software for business need a system that is updated timely, and does not rely on customers to provide information. I have always supported Viart as best I could, but I don't think it reasonable for customers to be asked to provide development information. No offense to Viart intended, but if I have to disable significant features that impact my customer's experience every time a small change is made, then I'll try to find another cart that is updated in a timely manner.
At the very least, when we report problems, Viart staff might at least investigate on their own and download the new documents from USPS or whoever it is and make needed changes. I was asked if I would allow my site to be used for testing. Does Viart not have a system they can use to test our software???
Am I being unreasonable? I hope not, I just expected more of a proactive approach by Viart instead of them asking us to identify the problem, offer the changes and then test them for Viart.
logan
12 Jan 2011 7:30 PM
Vera,
what exacerbates this problem is that when we call USPS, and when they ascertain that we are users and not developers, they curtly inform us to contact the 3rd party cart supplier (YOU). I have pressed the issue with them to the point of them simply hanging up on me. They aren't there to fix this for us, they are under the impression that YOU are.
I did manage to get development guides for DOM v4 and INTER v2, if you would like them, contact me offline with your email address and I will forward you the pdfs I have
thanx
8thSinCoffee
12 Jan 2011 7:46 PM
I opened a support request in December for the RateV4 interface, and sent ViArt a copy of the USPS guide at that time. They should already have it. I didn't get a copy of the international one.
Vera
13 Jan 2011 1:04 PM
You are not being very fair in your statements and this is why.
We are a company that sells shopping cart software, we support our product i.e. the code we have created on 100% and always provide patches and solutions for different problems. In addition to our code and on request of many customers we integrated 91 payment systems and 5 shipping modules. We never refuse to help with any of those third party systems and always do what we can but do you really think it is possible to track the changes in almost 100 systems at the same time? We don't consider it a crime asking users to provide necessary information, it's the least you could do while we spend our time and resources fixing a problem created by a third party.
Regarding asking to test on a live site. Yes we do have a playground but would you rather install a patch that was never tested on the live environment before? And actually, Ed, you have offered help yourself.
Regards,
ViArt Team
logan
24 Jan 2011 2:53 PM
No one has (and I certainly haven't) blamed ViArt for not keeping abreast of changes at USPS and their impact on our operations.
But I think the point is this:
USPS doesn't want to give us the info because we are end users of a 3rd party software that you (ViArt) sells. They only want to disseminate the info to developers of this software (ViArt) and not the end users (us). But you are asking US to get ViArt the info? Is there some problem that prevents ViArt from contacting USPS and getting the info in the manner and method that USPS would prefer?
Though it isn't a crime to ask us for help and input, the origin of the info (USPS) has made it abundantly clear that they want to hear from ViArt, not us. To justify an alternate course of action, while at the same time refusing to engage the primary course does beg the question; WHY?
Why, as the developer and vendor of a 3rd party cart software, would ViArt not want to get the information and support offered directly from the original source of the API?
TOCDCO
25 Jan 2011 3:45 PM
I understand both sides of this, however I would say that if the shipping and payment systems weren't in ViArt, then it would render almost useless to me, pushing me to another provider.
As I really do not use the shipping side, of ViArt but occasionaly, it's not as big of an impact on me. But yes, either way, we need to get this figured out.
logan
18 Feb 2011 1:37 PM
Vera,
It works well, even considering the high amount of customization I have... I believe you can restore 1st class also...
What's needed is an aguement that if the shipping method (<Service>) is first class, then the tag <FirstClassMailType> is passed with the container "Parcel" inside (in my instance) along with the <Service> containing "First Class", else the <Service> is passed with "All" and <FirstClassMailType> is ignored by USPS...
let me know if you're interested in trying that out...
thanx
