At the minimum, they could put character usage limitations in the documentation, so we would know about that before filling a database. It’s no dealbreaker to me, but you’re right – this is not 1996 and you’d think commonly-used extended characters would not be an issue.
I’m actually a little embarrassed that my 50+ posts are almost entirely questions. Glad to hear you liked the the write-up. Someday I’d like to be helpful here!
I have one question: how was the customer able to add items to their cart when you had insufficient inventories? I thought the cart prevented ordering more than were available. Were you adjusting inventory quantities after orders had already been placed?
Bob
[quote name=‘jobosales’]Were you adjusting inventory quantities after orders had already been placed?[/QUOTE]
Yes. In some cases the items ordered were one-of-a-kind and I removed them from inventory by hand, since I knew those orders were paid/approved and did not want to be double-selling things while troubleshooting the cart.
One of my orders still claims to be backordered, but in this case the one-of-a-kind products she ordered have been deleted from the database altogether. The cart goes to change status and finds it can’t adjust inventory for a sku that no longer exists, so it just gets stuck. That order will remain “backordered” forever but I can handle that, since it is an isolated case and I know why it happened.
In everyday use, the cart hides my inventory and will remove the “add to cart” button for any item with a zero quantity in stock. If someone tries to buy more than I have, it will inform them that they attempted to add more than is available. Just the way I like it!
It’s been mentioned elsewhere, but an inventory-neutral status option would be a very good thing.
[quote name=‘Dardanus’]It’s been mentioned elsewhere, but an inventory-neutral status option would be a very good thing.[/QUOTE]
Yes it would. Strangely, this item that used to be on the roadmap is no longer there:
[QUOTE]The ability to set “Decrease/Increase” property for default order statuses[/QUOTE]
I assumed that they were going to add a “No change” option since no change and decrease are the only logical inventory adjustments for a new order. Hopefully, they will bring this back.
Bob
Of course. :mrgreen:
Nothing drastic fortunately, but tonight I helped my mom place her first-ever online order (go mom!). We processed this as a phone order, and: backordered! Not open!
I investigated this order thoroughly and discovered that the attempted status change was reducing inventory on some products in her order, but not others. The not-updating products did not have any apparent bad characters in their names or skus, but the resolution to the issue was simply retyping the exact same product name in the admin and saving the product. Once I figured out which were the offending products and retyped their names, I got a Paid status that sticks. And inventory was finally adjusted on all items in her order, not some of them.
Now I am really wondering what is going on. Clearly this is not about inventory itself, it’s about characters in the product names causing the cart to choke. The name in question was Miniature Sandal Necklace; not exactly complicated.
I can understand an illegal character causing an issue, I could have typed that. There were none. The obvious next question is whether NeoOffice (like Word) “helpfully” added some hidden formatting to my text. Can’t see how that matters though, because CS-Cart requires a CSV file to upload product. Isn’t CSV by definition a plain-text format? Normally I run copy through a plain-text editor such as TextEdit if I want to be certain there is no hidden formatting tagging along, but I thought saving as .CSV would serve that purpose for me. Maybe not?
The question I have yet to answer is this: What, exactly, is CS-Cart not liking about some of my imported product names? Computers don’t do things at random, so there is something causing this behavior. Why is that something causing the cart to think it can’t change an inventory value in the database as long as that condition is present?
Curiouser and curiouser. It’s becoming a challenge 
Not sure what is happening. You might want to recheck the TextEdit preferences are set to plain text and UTF-8.
For a good (and free) plain text editor, have a look at Fraise (formerly Smultron - [url]http://github.com/jfmoy/Smultron/downloads[/url]) or TextWrangler (the baby brother of BBEdit - http://www.barebones.com/products/textwrangler/). Also excellent is TextMate (€39) from [url]http://macromates.com/[/url].
Bob
Oh, I like TextWrangler. I was using NeoOffice because it allowed me to work in a true spreadsheet, but it obviously caused a mess with the formatting. I wish there was a CSV reader that would open a file in spreadsheet format but allow no formatting.
As it is, I did do some prep and F/R in Neo again for ease of use, then opened/saved the file in TextEdit, carefully checking for encoding and saving as plain text CSV. Then, uploaded once again. Good thing CS-Cart’s upload features work reliably.
Now, I just need to watch as orders come in, to see if any more get stuck in backorder hell. Someone did place one before I uploaded, but I was able to trace the offending products and fix them.
It’s still very curious to me that the cart will change inventory on anything it can, but leaves the messed-up product(s) inventory unchanged, and then silently bounces the status back to backordered. This would be much easier to manage if the cart could run a check beforehand, and if it finds an “untouchable” product, don’t change ANY inventory and give an error message instead. (If I really wanted to dream, the error message would tell me what product it tripped over!) That, or like you said Bob, it should just work without such a strict limitation on character useage.
As it stands, I’ve had to check inventory levels of all products in the order, note which ones did NOT change, fix them, and then reset the inventory on all the other products because each attempt to change status reduces those other inventories with every attempt! Once all that is done, then and only then can I mark it “paid” one more time, knowing that inventory has been reduced appropriately AND the status will remain.
Hopefully this thread will become a matter of history soon. Only time will tell now if I see another “stuck” order, and what the reason is if I do.
[quote name=‘Dardanus’]
As it stands, I’ve had to check inventory levels of all products in the order, note which ones did NOT change, fix them, and then reset the inventory on all the other products because each attempt to change status reduces those other inventories with every attempt! Once all that is done, then and only then can I mark it “paid” one more time, knowing that inventory has been reduced appropriately AND the status will remain. [/QUOTE]
That is clearly a bug - since CS-Cart handles order status at the order level, once the order status is set to ‘Backordered’ any order line item whose inventory has been adjusted should be reversed.
It wil be nice when they finally implement a real backorder system that identifies backorders at the line item level. This will make things more obvious plus also giving the opportunity to ship what is available while allowing later backorder fulfillment.
Bob
For anyone referencing this in the future, it’s been about 10 days since I forced all the products through a plain-text editor and re-uploaded. No problems so far, with inventory tracking or order statuses. Everything is working as advertised.
Nice to have this little issue resolved. Thanks again, Bob, for your assistance!