If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
To close out the fatal error issue mentioned above on Sept 9...it was caused by a bug in the Merchant Optimizer module. The developer is working on a fix.
1) I think the first occurred prior to PR8 and may have been fixed. When we uploaded a large quantity of new items (1000+), some but not all (random) ended up in all our store categories instead of the specific category in the flat file. This took weeks to correct manually.
2) Occured after PR8: When we uploaded a large number of new items (about 700), some of the items never were enterred into our Miva store database. We only discovered the problem after reviewing crawl errors noted by Google. We feed Google a sitemap which includes all active items in our store. Weeks after our Oct 1, 2011 upload, we discovered that Google was reporting some 60 items that were in our sitemap but were not able to be crawled. A small portion of these 60 items were caused by server availability at the time of the crawl. However, we were able to verify that about 50 items were missing from our Miva Store. We when back to the flat file used to upload and the items were in the flat file. NOTE: BOTH THE MIVA FLAT FILE AND THE GOOGLE SITEMAP UPLOADS COME FROM THE SAME MASTER EXCEL SPREADSHEET.
Needless to say, we have loss confidence in the Miva Flat file import feature and therefore spend extra time verifying that our monthly uploads are error free. Since issue two above, we have doubled our verification efforts because we don't want Google to find our error for us.
1) I think the first occurred prior to PR8 and may have been fixed. When we uploaded a large quantity of new items (1000+), some but not all (random) ended up in all our store categories instead of the specific category in the flat file. This took weeks to correct manually.
2) Occured after PR8: When we uploaded a large number of new items (about 700), some of the items never were enterred into our Miva store database. We only discovered the problem after reviewing crawl errors noted by Google. We feed Google a sitemap which includes all active items in our store. Weeks after our Oct 1, 2011 upload, we discovered that Google was reporting some 60 items that were in our sitemap but were not able to be crawled. A small portion of these 60 items were caused by server availability at the time of the crawl. However, we were able to verify that about 50 items were missing from our Miva Store. We when back to the flat file used to upload and the items were in the flat file. NOTE: BOTH THE MIVA FLAT FILE AND THE GOOGLE SITEMAP UPLOADS COME FROM THE SAME MASTER EXCEL SPREADSHEET.
Needless to say, we have loss confidence in the Miva Flat file import feature and therefore spend extra time verifying that our monthly uploads are error free. Since issue two above, we have doubled our verification efforts because we don't want Google to find our error for us.
Hi Donson
Which import module are you using for the upload? And can you e-mail me a copy of the flat file you’re using so I can try to reproduce this issue and see what’s going on?
When the first import error occurred using PR7 (April 2011) where some items randomly were placed in all of our categories, I did contact Miva Support, Jonathan Standifird. I have sent you the email response I received from Jonathan.
It took us two weeks to discover the second import error that occurred on Oct 1. We found it when Google reported many items in our sitemap could not be crawled. Unfortunately, we overwrite these import files each time we make an upload. I checked and all imported flat files on Oct 1 have been overwritten.
I will keep your email on file and try to remember to email you any future flat files for which we discover import errors.
We've had two customers call us in the last couple of days saying they couldn't continue through the checkout process, saying the "Continue" button wasn't showing up. Not sure if this is coincidence with PR8 Update 4, but these two reports have only come in since updating.
We don't seem to have the problem. We are still getting orders. I also processed a test order and had no problem with the continue buttom.
I think Miva uses Java script for the functioning of back and continue buttoms. If a customer has Java "turned off" on their computer it will cause the problem you described.
I ran the PR8 update 4 last night and now receive this error message in Shipping Settings > Shipping Rules > Shipping Method Rules:
Miva Merchant returned an invalid response.
Function: ShippingMethodRulesList_Load_Query
Response: Runtime error in mm5/5.00/modules/shipping/BROK_UPS_CUSTOM.mvc @ [00000015:00005bda]: C:dev_mivacompile2BROK_UPS_CUSTOM.mv: Line 2906: (in expression): Array index must be positive integer
Another error is my UPS shipping will not sort properly. It is showing "Next Day Air" as the default option (he first error may have something to do with this error)....
I am not sure if the errors occurred before or after I activated the "UPS Ready Tools" module. I quickly deactivated the Miva UPS module but the error still exists. My guess is the module is somehow colliding with my Viking Coders "UPS Custom Integration" module. I was tempted to de-activate the Viking Coders module to see what happens but there are a couple of features I did not see in the new Miva UPS module, 1. Control shipping by category and 2. Drop ship product from a different zip code. These two features are very important to us.
Any ideas on the errors and are the 2 features available?
I think I may have found the problem - When I export my orders to a flat file, Viking Coders names the different shipping options like so: "BROK_UPS_CUSTOM:01, BROK_UPS_CUSTOM:02, etc." - It looks to me like the new UPS module is looking for a number only with no text (ex: 01, 02, etc.) from the Viking Coders module. I'm not sure if the Viking Coders is storing the information in the database the same way, but if so, I suspect that is the problem. Most importantly, my Viking Coders module is waaaay out of date (I should have checked that first). I am pretty sure an update will most likely fix the issue. I will post my results once I finalize the update of the Viking Coders module just in case anyone else has the same issue. Thanks Rick!
Comment