I received a couple of bug reports and have fixed the issues that were troubling people.  Some quirkiness with the metric calculations were resolved.  Also, I abstracted the order-by-case feature a bit more from the custom sized products feature so you can run them more separately than before.  There is also better XML comments in layout/madetorder.xml for turning on and off the order-by-case count feature.

Release 0.7.0
============================

* Fixed broken metric calculations
* Removed debug code which caused a crash on “configurable” products.
* Force cart page to behave like product page for “order-by-the-case” feature.

http://biz.metrofindings.com/main.page/magento_modules.html

Does anyone use the purchase order payment method in Magento?  It seems open for abuse.  It would be nice if the customer had to be part of a pre-approved group, or if they had to enter a password or account number code which is generated at the retailer when the customer verifies their line of credit.

Anyone have thoughts on this?  Anyone have a way to limit payment options to customer groups?

Wow, the response to MTO has been pretty overwhelming.  My PM inbox is getting pretty full.  If you have questions, don’t hesitate to ask them in the comments of any blog post, or create your own blog post.  If I haven’t responded to your PM, I’m sorry.

This 0.6 release brings metric support with meters and centimeters.  Also, one user asked for plain text input from users, that feature should be finished now.

Configuration and installation is really going to be rough for a lot of people since there are quite a few template and layout changes.  Ask questions here, start a new wiki page perhaps, don’t hesitate to create content in this group.

http://biz.metrofindings.com/main.page/magento_modules.html

http://biz.metrofindings.com/main.content.image/magento_mto_3.png

Well, I’m releasing my speed patches to the public.  If you are in need of more scalability, customizations, etc you can contact me with a PM.

http://biz.metrofindings.com/main.page/magento_modules.html

Hello everybody.  I’ve been waiting around to see if I could edit the wiki page about my modules, but no such luck.  I can’t seem to edit any wiki pages.

So, here’s the low-down on the MTO module.

I started to support meters/centimeters instead of just inches.  I would like some feedback on how centimeters / meters should be represented.  It’s pretty easy for inches: 2 select boxes, one for whole inches, one for fractional inches.

Latest version is 0.3.0.  Some daring developers can try to install it and give me some feedback.  This module is significantly different from the wiki page about making custom modules, so don’t treat that page as a manual.  It is a theoretical overview of this module.

Download it from here:

http://biz.metrofindings.com/main.page/magento_modules.html

I’ve finally posted all the code on its own project page.  The documentation is kind of slim, but the installation procedure shouldn’t be that difficult.  I changed the style a lot since the old screenshots were posted.  Here is the homepage of the project.

http://cognifty.com/main.page/customer_service_portal.html

This was the original blog entry that talked about some of the goals and features:
http://www.magentocommerce.com/group/blog/action/viewpost/263/group/174/

I’ve been posting in the forums about my customer service portal that is designed for integrating shopping carts with backend inventory/accounting/tracking systems.  I’m trying to make this a very generic messaging system, and as such, it is not highly specified to any one particular backend system.  The only shopping cart that it is planned to work with currently is Magento.

The main goals of this application are:
1. Take orders from a cart and store them as messages.
2. Automatically route messages to other queues based on rules.
3. Automatically convert messages into tickets.
4. Allow human acceptance/rejection of tickets.
5. Allow exporting of approved/rejected orders into any format.

Currently, there is a need to have all orders vetted by humans, so there are no automatic rules to directly convert an inbound message into an outbound message, but this should be relatively simple.

The human interaction portion sorts tickets by date, allows status changes, keeps track of internal notes (only seen by customer service people), and allows for locking of tickets to avoid workers clobbering each other’s changes.  Here are screenshots of the customer service portion:

http://niftyphp.sourceforge.net/cust_serv/customer_service_portal_01.png
http://niftyphp.sourceforge.net/cust_serv/customer_service_portal_02.png

(I’m not sure if you can click these or not.  If not, copy and paste them into a browser).

There will be an official page for this customer service portal soon (sometime this week)

I’m trying to refactor some of the code that I’ve done for one client into a more generalized module that anyone can install.  Right now it is limited to 3 dimensional products, but I get the feeling that should be enough for most people.  I’m hoping to release the code with the next Mage release, either 0.8 or 1.0 preview 1.

Everyone has told me that I *have* to have a SKU for everything I sell.  That’s fine, and it’s also true.  Everything that you sell should have some code or identifier on it so that every part of the organization has a common reference point for dealing with the order or dealing with the customer.  The problem comes when you have custom products.  At what point do you decide which options affect the sku and which don’t?

Take, for example, a roll of fabric.  It is sold by the square yard and it is always 12’ widths.  So 3 feet of length is 1 yard x 4 yards or 4 square yards. 6 feet of length is 2 yards by 4 yards or 8 square yards.  So, you can see where this is going, can’t you?  Do you create SKUs for each 3 foot length?  Yes, you say?  Okay, now we have about 1000 SKUs for that one product.  Yeah, and we have 12 kinds of fabric, each a different mix of cotton and polyester.  Okay, that’s only 12,000 SKUs, that’s nothing.  We should write a simple script to populate some CSV files and import them into Magento, that’s doable.

Wait, why was I complaining again?  Oh, because that’s a contrived and simple example.  Take that fabric, with it’s thousands of sizes, dozens of fabric combinations, and add in colors.  Sure, why can’t the customer order any color they want.  They’re pretty savvy designers, so just give them the ability to punch in whatever CMYK values they want.  Now do you see the problem?  We’ve just taken our 12,000 SKUs and multiplied them by 100,000,000 (one hundred million (assuming each color level has a percentage 0-100%)).  So now we have, easily billions of SKUs, just for 1 fabric product. 

1 product?!  Yeah, depending on the organization, some people in it may consider the fabric roll just 1 product.  Spun cotton yarn might be another, fluffy polyester stuffing might be another.  Perhaps this company only sells “6 products” in the mind of someone working there.

So, Billions of SKUs, that’s okay.  Importing billions of SKUs?  not okay.  Duplicating a description, image, weight, tax class, etc etc for every single *possible* combination doesn’t seem worth while.  I don’t have a problem with unique SKUs, as long as they can be dynamically generated.

At what point do you say?  This doesn’t constitute a product that I want in Magento?  I’m surprised that Magento doesn’t have an easy way to override the SKU or to even add line item details to each invoice/sales order.

On Friday I came to a road-block with Magento.  I’m trying to add extra parameters to an order line item (Sales Quote Item in Magento) for each product ordered.  These will hold customer entered input for the product; for example, dimensions.  I’m not sure exactly how the data will be formatted, yet.  I need to pass this information along with the order invoice so that customer service and manufacturing know exactly what the customer wants.

The problem is that text area data are not being saved to the order, but “varchar” types and “int"s are being saved properly.  I’ve posted about it in the forums, but have yet to get a response.  I think I will switch to all varchar types for the time being and hope that Magento 1.0 will have this problem solved.

See this URL
http://www.magentocommerce.com/boards/viewthread/1748/