Posts Tagged ‘MOM XL’

Seasonal Implementation Made Easy Using IEM and Multi-Company

Tuesday, June 1st, 2010

Posted by Dennis Ombati, Mail Order Manager XL Support Specialist

Dennis Ombati, M.O.M. XL Support SpecialistRecently, I had a chance to work with a major retailer of aquatic sports gear that needed their second SiteLINK store set up and fully integrated with Mail Order Manager in a relatively short period of time.  With the summer season fast approaching, their goal was to capitalize on the demand for their products and to double up their e-commerce revenue.

To accomplish this, they used the Multi-Company Controller Module which allowed them to establish a second company in the M.O.M. system.  By creating this second company, they gain the ability to integrate with multiple SiteLINK websites.  I walked the client through the process of building this second company and advised them on creating data files based on our stock file structure located in the M.O.M. Help file Data Dictionary.

The client provided the stock and inventory data for close to 2000 products in an Excel spreadsheet and we imported the data through the Import Export Module’s Stock Import Wizard.

Data Import Wizard

After a quick re-index and complete publish to their website, their second SiteLINK store was up and running.

Time was of the essence and this whole project would have taken them a whole month to complete due to the amount of products that needed to be created one by one.  With the use of all the additional modules involved (Multi-Company, IEM, and SiteLINK), the roll out time was shortened substatially.  The client was very happy that we were able to complete the project in less than a week thus saving them time and money.

Tags: , , , , , ,

Posted in Support | No Comments »

Avoiding Unnecessary Backend Manipulation

Friday, May 14th, 2010

Posted by Ryan Galicia, Mail Order Manager XL Support Supervisor

Ryan Galicia, M.O.M. XL Team Leader

A long time M.O.M. user specializing in selling automotive parts recently wrote into our support mailbox with the following question: “We have thousands of quotes in our database and we would like to be able to bulk cancel most of them (i.e.: quotes entered before 2009).  Does M.O.M. support this or will I have to do it through SQL using a stored procedure?”

While the request was simple enough, a common practice often found by the M.O.M. user community is to look for operations that can be accomplished through backend manipulation.  For the above email, I wrote back to the user explaining that a backend stored procedure is not necessary for what he was looking to accomplish and he simply needed to use the Database Purge Module’s option to Purge Quotations prior to a certain date.

M.O.M. quote purge 

The cited email was just a small example of how some of our more long time and advanced users look immediately for a backend procedure to accomplish a goal.  As seen, a lot of these cases do not require the backend manipulation that they originally think is needed. 

The Mail Order Manager system is designed as a relational database system (meaning the data within the tables are linked together) and any type of manipulation on one table can have adverse effects on other tables in the database design if not they are not updated properly.  Additionally, unsupervised backend data manipulation not conducted by Mail Order Manager Technical Support is not covered under a user’s Support contract and the technical support team will not be able to assist with any unforeseen errors that a user encounters. 

On a case by case basis, some issues do require manipulation of the backend data to reach a resolution; however, it should not be attempted or conducted without consulting M.O.M. Technical Support.  Examples of these issues can vary and range from an incorrect inventory value on a report or screen to a field containing a value so high it reaches the maximum size of that field and produces what’s called an ‘overflow’ error. 

As many of our M.O.M. users can attest to, the recent including of web based support services (available only to our Resolution Support or Business Operations Support tiers) allows a M.O.M. tech to conduct a remote session on a user’s machine and run any necessary backend modifications to a client’s system.  This is the proper procedure to follow when backend data modifications need to be made as a technician will cover all necessary areas and tables to make sure the data that has been modified reports corrected in the front-end of M.O.M.

Tags: , , , , , , ,

Posted in Support | No Comments »

M.O.M. Enterprise to M.O.M. 7i XL Conversion

Monday, May 3rd, 2010

Posted by Katherine Ulloa, Dydacomp Senior Technical Support

Katherine Ulloa, Dydacomp Senior Technical SupportI am very passionate when I work with users who are ready to convert to the SQL version of M.O.M. 7i.  I know that it is a big step for them, so I am committed to be there throughout the entire process.

It wasn’t too long ago that I worked with a very delightful world-class musical instrument web retailer.  They have been a Dydacomp customer for over 10 years using our Enterprise version running on a Visual FoxPro backend.  This web retailer badly needed an updated version of M.O.M. due to reaching the 2GB limit imposed on Microsoft Visual FoxPro files.  Their problems, due to this capacity limitation with the database file size, escalated to making regular and long M.O.M. Technical Support calls which constantly disrupted their business.  Thus they decided to make the move to M.O.M. XL.

Regarding the conversion process, my suggestion is to always do a test conversion first, so they will have the time to examine the new M.O.M. 7i system running on a SQL Server. During that time of testing, I make myself available to answer any questions or provide support to any issues that they may encounter while in this testing phase.

I know that a good reference document is always important, therefore, at the end of the test conversion I sent them an outline containing detailed steps that we had taken to make that conversion a success.  The client implemented this step-by-step process a couple of times by themselves until they were comfortable enough to accept the final conversion process.

MOM XL Conversion document

At times, there are customers that prefer a dedicated SQL specialist to be with them during the entire live conversion.  In this particular situation, the customer felt more comfortable running their live conversion on a Friday, during non-operational hours.  Here at Dydacomp we value our customers and we know that they expect the Mail Order Manager Technical Support team to be there when they need us the most, so I made sure this live conversion was a total success by assisting this customer even after hours and customer stating they felt self-assured at running the conversion themselves.  This is a testimonial from this success story:

“I have never received a follow up phone call from a support team like I did this time.  Katherine was concerned about the success of the conversion even after the whole process was already a proven success.”

Tags: , , , , , , , , ,

Posted in Support | No Comments »

Identifying a Customer Report/Invoice Error

Tuesday, April 13th, 2010

Posted by Ryan Galicia, Mail Order Manager XL Support Supervisor

A Mail Order Manager customer recently called into Dydacomp Support very upset that after upgrading from M.O.M. Version 5.4 to M.O.M. Version 7i they were encountering the following error when attempting to print their invoices.

M.O.M. Version 7 message

The owner of the company felt very frustrated because without being able to print proper invoices, their business was at a standstill.

Upon reviewing the error they were encountering, I noticed many keywords that stuck out to me and helped identify the problem. Because a specific report file name beginning with the letter ‘D’ is being referenced in the error message, I was able to identify that the error was due to a custom report (see reference 1). Additionally, reading the error text itself, I noticed that the variable being referenced, ‘DESC’, is a field that existed in M.O.M. 5.4 but the name was changed from Version 6.x and up to accommodate program flexibility between our different Visual FoxPro and SQL back-ends (see reference 2).

I brought this to the attention of the company’s outside IT consultant and he was unaware they had implemented a custom invoice at some point in the company’s history. Reviewing our own logged sales history for this license, we found no record that this custom invoice was purchased through Dydacomp services.

Although Dydacomp does not work with custom programming not developed by us, I understood the critical situation they were in and knew that the coding needed to correct their custom invoice was fairly simple to correct for a knowledgeable Visual FoxPro programmer. I requested their custom invoice files and provided them to one of our programmers for review, explaining to the consultant that Dydacomp Support could not guarantee a definite fix could be made but we would attempt it. Our programmer was able to successfully make the changes needed to their files for their invoice to print without error and align properly.

Understanding that we went a little outside our normal Dydacomp Support guidelines to troubleshoot and correct programming not developed by Dydacomp to make their upgrade a success, both the IT consultant and owner were very happy with the extra effort we provided to get them past the initial difficulty they experienced in what is normally a virtually seamless routine.

Tags: , , ,

Posted in Support | 1 Comment »