• Printing Collates in Ecometry

    0 Comments

    December 22, 2007 in Development, Ecometry

     

    A recent discussion on the Ecometry Google Group got me to thinking that we could use a central place for information on supported printers in Ecometry. If you call Ecometry about printer support, you’ll be told that they only support the HP 8150 series printer with an add-on font dimm. In general they work pretty good with the thick collate stock that we generally use. (more…)

  • Is Ecometry Stuck In The Past?

    2 Comments

    October 25, 2007 in Ecometry

     

    Several months back, Kyle IM’d me a link to the Top 10 Dead (Or Dying) Computer Skills. We both noticed that Ecometry used the first two technologies, Cobol and Non-Relational Databases. Having had our troubles with Ecometry and how backwards it sometimes seemed to how applications are developed today, especially web apps, this gave us a little chuckle.

    I recently got a little fired up (here and here) with Ecometry regarding their support billing cycles, so I came back to this article and figured I’d publish it.

    There are many reasons companies stay with old technologies. Sometimes it just works, so its hard to justify change. Sometimes the cost outweighs the benefits of developing a new application. But sometimes, just sometimes, to increase market share and keep existing customers, you have to change. I’m not saying companies like Ecometry will ever disappear, I just think that eventually, something better will come along.

    What I will say to that effect is that as time goes on, better solutions come out (read web applications) that can do the same things antiquated systems like Ecometry do but better (Ecometry isn’t the most user friendly application in the world). Older companies are either forced to change or die out because people go elsewhere. Think about it, why is Digital Equipment (DEC) gone? Something better came along. Why don’t we use DOS anymore? Something better came along. I think we’ll start to see more and more of this happen with Web 2.0 applications replacing desktop applications (look at some of the Google applications that have come out that are useful, but not yet as powerful as say Microsoft Office) when its possible for them to have the same usefulness and features their desktop ancestors had.

    Image courtesy of Wikipedia

    Eventually, as web applications become more and more powerful, legacy applications such as Office and Ecometry will go the way of the Dodo. This isn’t a knock on Ecometry so much as its an observation on my part as the direction of software these days. More and more powerful applications are being developed for the Web as we bandwidth increases and we start to go more mobile.


  • Update: Converting Ecometry EDI Files

    0 Comments

    August 7, 2007 in Development, Ecometry

     

    A while back I posted a little C# console application I wrote to convert EDI files to CSV and Ecometry Ship Confirm Batch files. I’ve since updated it, with some usability fixes and also writing out the Item Number and Product Name to the file. You can get it here. Feel free to download it and contact me with any issues or feature requests.

  • Building an Ecometry Shipping Station

    23 Comments

    June 18, 2007 in Development, Ecometry

     

    For this upcoming Halloween, we’re moving the Morbid Industries warehouse out to California. It was a business decision a long time coming. Shipping product from China to the East Coast and then back across the country was getting expensive. A lot of our customers are on the West Coast too, so we were basically shipping product in containers across the country for nothing. So, because we were doing this, and we use Escalate Retail’s Ecometry for order management, I needed to build a shipping station to send out there. Ecometry sends you to Agilysys, for pre-built shipping stations, however, they’re really expensive and we were looking to save some money. I had read on the Ecometry Google newsgroup that people had built their own, so I decided to brave it and do the same.

    I’d like to thank a couple of people for there help right off the bat. Paul, a support engineer from Datalogic/PSC was a big help getting the right interface cable I needed and helping with programming the scanner to read our barcodes properly. Also, Daniel Lively for his suggestions on the Ecometry Google newsgroup. Thanks guys!

    Here’s the list of parts I used:

    • Dell Optiplex computer
    • Zebra Z4MPlus Thermal Printer
    • Mettler Toledo PS60 scale
    • SIIG Cyber 2S1P (model #JJ-P21012-S6) Dual serial port and Parallel port card
    • PSC Powerscan PSSR-1110
    • PSC AT keyboard wedge Y cable Model #8-0738-03
    • AT to PS/2 adapter
    • PS/2 to AT adapter

    Pretty much you can hook up the entire thing and it will work. For the scale, you need to set your COM port to the following settings:

    • Baud Rate: 9600
    • Databits: 7
    • Parity: Event
    • Stop Bits: 2
    • Flow control: X on X off

    For programming the scanner, you can find documentation on Datalogic’s website here. The programming guide that I needed for the model scanner I purchased is here. Depending on the scanner model you use, you’ll need a different programming guide so that you can scan the right bar codes for your application. We enabled Code 39 and Code 128 since we scan FedEx bar codes.

    A couple of additional notes. I’m not sure I actually needed the SIIG Cyber 2S1P card as I would have had enough ports to hook up all the equipment. It was recommended on the newsgroup to get one for the scale. I was also told an easier setup with the PSC Powerscans is to use PSSR-7000 and a USB interface. They’re really easy to set up I guess. Also, in place of the Zebra Z4MPlus thermal printer, you can supposedly use a Zebra S600 or a S400, which are cheaper.

    Most of the parts I sourced on eBay. I think all said and done, we paid less than $1,000 for the entire shipping station. The computer was free as we had one kicking around, but you can use pretty much any computer running Windows 2000 or Windows XP. I just recommend having a bit of memory in it so it isn’t a complete slug. I believe this is significantly less expensive than buying a pre-built shipping station through Agilysys. It’s faster than the one we originally bought from them too!

  • Converting Ecometry EDI Files

    0 Comments

    March 7, 2007 in Development, Ecometry

     

    A while back, we started having to deal with EDI files in Ecometry for Fright Catalog. We started charging for our catalog and wanted a third party to ship them for us. Unfortunately, the third party couldn’t handle EDI files, they needed a CSV file and annoyingly, Ecometry’s software couldn’t do it for us. Not wanting to create a CSV file for this by hand, I created a C# console application (requires the Microsoft .NET 2.0 Framework) to parse these EDI files for me into a CSV file. It will output the following:

    • Customer Number
    • Company Name
    • Title
    • First Name
    • Middle Initial
    • Last Name
    • Address 1, Address 2, Address 3
    • City
    • State
    • Postal Code
    • Country

    This was great, until it came time to processes these orders. Now I needed to generate a ship confirm batch file as specified in the Ecometry 7.x documentation. Not wanting to do this by hand either (especially since I’d need to do this on a regular basis) and being a fan of the DRY (Dont’ Repeat Yourself) principal, I extended my little utility to create Ship Confirm Batch files for Format 256. Other formats might be supported later, contact me if you need them, maybe I can help.

    So now I have a cool application that will parse these EDI files for me in the formats I need. If you’re interested in getting your hands on it for your own use, I have a download available with the executable. Let me know if you have any issues with it or want to see some new features.


  •