Thanks Kevin and everyone else for all the good information!
-----Original Message-----
From: mapics-l-bounces@xxxxxxxxxxxx [mailto:mapics-l-bounces@xxxxxxxxxxxx] On Behalf Of Kevin Fox
Sent: Thursday, February 07, 2013 12:05 AM
To: MAPICS ERP System Discussion
Subject: Re: [MAPICS-L] XA Pack List
Kevin
Since your name is Kevin, I thought you might deserve a little more information.
From the responses you have received you can see that they fall into
two categories
1. Create your own
1.1 Create your own forms using custom code with or without writing your own overlays
1.2 Use the existing forms supplied and create your own overlays.
2. Purchase and implement a forms package.
There are of course, many factors that should go into your decision. I'm not going to address all possible factors, but I'll give you some additional information that might assist your decision.
Which ever solution you eventually decide to implement you want to take into consideration a very key consideration. I believe that whatever you decide you will want to ensure that you do no harm. It's like a doctor's Hippocratic oath, only for programmers. Whenever we, as developers, use code to solve a particular business issue, it should take into consideration the future costs as well. This is not only true of purchasing a packaged solution, but also true when you create custom code solutions.
Doing harm takes many forms and has many negative results.
First, anytime you create code that prevents the application of Infor supplied service packs (PTFS), enhancements (PCMS) and upgrades (Versions) your actual costs are significant. As a consulting manager that works for an Infor Gold Channel Partner of more than a dozen Infor products, I receive several calls each day from customers that are struggling under the burden of poorly executed code that requires continuing on going maintenance and is preventing their company from upgrading.
And the costs are huge. A short time ago I received a call from a customer that was running R4.0 (nearly 20 years!) and was unable to upgrade because of the custom code they had written during that time. Unfortunately, the coding methods this customer used included significant modifications to source code, code that contained hard coded variables and 3rd party packages that directly accessed the data files. It also included not 1 but
2 different forms packages both of the suppliers had long ago went out of business. In fact, the second forms package was purchase because the supplier of the first forms package had gone out of business. The first package could not be replaced because it was used so pervasively (bar code labels, etc.) that the cost to replace it was deemed to time consuming and expensive. In addition, much of their code written over the years was undocumented, poorly written, and the employees or consultants used to create the code were long since forgotten and lost to time.
But what makes this worse. What was really painful for the President of the company, the son of the companies founder, was to find out was that nearly all of the code that they had been created over the years was all included in the current release of the code. Nearly 50% of the code was written because the users were not trained and did not know that MAPICS (as it was known then) already had the feature in their R4.0 release.
(Example, they wrote code to enable the entry of customer part numbers during customer order entry.) Imagine his shock when he realized that not only did the company pay for all the code to be created but they also paid an entire department to constantly try and make it work better in their ever changing and more competitive world. And just to compound the problem they were faithfully paying their annual license agreement and could not take advantage of any of the development work done during most of the 20 years.
And, here is the real pain: during the 20 years they were losing market share to their competitors. Not because their competitors were cheaper, but because they could never keep up with demand. Always had a huge backlog, making profits. But never able to catch up. A direct result of poor customer delivers, their market share shrank for 17 percentage points.
Their issues were directly tied to their lack of planning systems. No forecasting, even though they had the forecasting application no production planning, even though they had MPSP, same with no master scheduling. They did run MRP every week, but 5 programs were written to eliminate the MRP messages because "the planners couldn't keep up with them". They had more spreadsheets than Microsoft, and more planning meetings than the Pentagon and still could never get caught up.
At great cost ( but significantly less than they had been paying) and some help, they have been able to finally break the shackles of all their custom code. They have implemented the latest version of their ERP system and have already seen their inventory turns double. They are very optimistic about the future.
I'm not sharing this with you because of all the great features of XA, but because of the lessons we all need to learn about writing code as a solution.
When it is done poorly, the company is going to be effected. Do it right, and not only does it enhance the users ability to perform their jobs better (after all that is why we write code) but it does not prevent applying services packs from the ERP vendor (in this case Infor). Using the tools provided native in the ERP solution, code today no longer blocks the path to updates and enhancements.
That all being said as background to my recommendations:
What ever you decide to do,
1. ensure that the code or package uses SystemLink to connect to the business objects.
2. ensure that the code or package is integrated within PowerLink.
Remember that the future of printing is now. XA report writers are built right into the interface. And are not output spool dependent. (PO's being generated, PDF'd and emailed or faxed without having to access the outq!) So any code or package dependent on the spooled output alone, should be suspect.
3 ensure that the code or package does not prevent the application of
service packs and upgrades It should be release independent.
4. ensure that the code or package can be used to generate the output forms without code development for future forms and changes
If you do this, you will dramatically lower the costs for your company and contribute to its profitability and survival.
Good Luck!
On Tue, Feb 5, 2013 at 7:56 AM, Kevin Fish <Kevin.Fish@xxxxxxxxxxx> wrote:
Hi Everyone,
Is anyone using a different solution for the XA packing list? We're
getting complaints from dealers about the number of pages and spacing
within the pages. Plus the headings take up nearly half of every page.
We're currently on release 7.8.
Thanks!
Kevin
--
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list To
post a message email: MAPICS-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/mapics-l.
--
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list To post a message email: MAPICS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/mapics-l.
midrange.com
