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.
midrange.com
