Why would anyone upgrade to Macola ES?

[crystalreporting]

Macola have confirmed that the 'new' upgrade about to be released for Progression SQL to Macola ES will ONLY convert master files. No transaction or history files will be converted. Given that, who in their right mind would upgrade to Macola ES? Essentially, only the master files will be converted (ARCUSFIL, APVENFIL etc.) and no open transactions will. That would mean re-keying all open sales orders, purchase orders, AR invoices and so-on, PLUS all of your history will be lost! Does anyone else have a concern/problem with this?

Peter Shirley

http://www.linkcorp.com

 

[dgillz]

I just had a lengthy discussion on this topic with some people at Exact and I was assured that this is a temporary thing in response to the demand of some people to go to ES now. The long term outlook - they said 1st quarter '04 at the latest - is to have a full conversion utility like we have from 6x to 7x. They come out and say substantially all of this in the new RPD for the conversion utility.

If you were around when the first 6x to 7x conversions took place, I am sure you have some ugly memories about that as well. I know I do. The key on converting from 7.6.200 to ES is managing the project and the client's expectations, at least until the conversion utility is mature.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[ultrav]

That is ridiculous! By doing that, they are insuring that all current users of Progression will think about using other programs before updating - if the data and history don't follow there is not an advantage to staying with Macola. It does not take much to keep users of these programs because no one wants to migrate to another system - but if we lose all of our history - we might as well weigh all the options out there. Macola/Exact has really left a bad taste in my mouth over the past couple of years(the version 7.6.2 fiasco, rising maintenance fess with nothing to show for it, waiting on version 8 -now waiting on ES, and dropping my reseller).

 

[crystalreporting]

I guess I'm questioning why they would even bother with a conversion that converted master files only. I can't think of one of my clients that would want to upgrade to Macola ES knowing none of their (valuable) history and none of their current open transactions would be converted. Why even call it a conversion utility if that's all that it does? I was around in the 6.0 to 7.0 days, and I remember the problems, and fully understand the complexity involved in writing conversions. I just don't understand what Macola hope to achieve in releasing a conversion that few (if any) Progression SQL customers will use...

Peter Shirley

http://www.linkcorp.com

 

[kscheeler]

I agree with dgillz.

This will do a few things. It buys time for Exact to get a full conversion utility out there. It will get a few more companies running ES which will help with getting the product more mature and in those client's cases, it will give them functionality that they don't have now.

I also agree that with most of our clients that have been running Macola for years, they want the open information and history and we would probably get kicked out the door if we recommended something like this.

Kevin Scheeler

 

[MacolaHelp]

I can think of scenarios where just master file conversion is acceptable. Since the accounting is so different, populating the tables might be easier than draggin history along with it. Of course, eaxact/macola should be including the AR & AP open tables (don't know if the rocket scientists in Marion got this one or not). Since ES does all GL activities hot, it would be a mess to re-enter AR or AP open items if they didn't include in the conversion.

As far as distribution history, I could be content with having access to my old version 7 history & new ES stuff on the same workstation, since they appear to be making no major changes to distribution files or functions. I, in fact, did this from macola 6 to macaola 7 since the IMINVTRX conversion was such a mess. In addition, if a client needs to implement something new like pp/pull or bins/lots/serial #s, etc., or implement something new due a business change like feature items, what better time to do it than when you have clean master files?

If there were no implementation issues in the client's current version, it sounds like waiting until the full conversion utiity is available makes sense. Let all those other guys road test it for you. I didn't appreciate having to create all my own "clean up" utilities in the 6 to 7 conversion for distribution, that's for sure.

For clients that have been reasonably to highly satisfied w/macola so far, they'll wait for a good conversion utility. For those that want the new features or functionality, it gives them an opportunity to "re-invent" their software in today's market & technology. This lets them take a good look at their business plan & practices & set the software up to deal w/it w/o spending on new software, just "re-implementing" what they already own for 10% annual maintenance. If you are a good salesperson, you should be able to convince them to invest in YOUR services, understanding THEIR business, to get macola to work, rather than spending $$ for new software & no one to manage the implementation.

 

[dgillz]

For those interested, the following is the list of tables converted in the new conversion utility. Conspicuous by their absence are the APOPNFIL and the AROPNFIL.

apctlfil_sql A/P Setup File
apvendst_sql A/P Vendor Distribution File
apventyp_sql A/P Vendor Type File
arcarcde_sql A/R Carrier Code File
arctlfil_sql A/R Setup File
arslmfil_sql Salesperson File
arsrvfil_sql Service Codes File
artypfil_sql Customer Type File
bmctlfil_sql BOM Control File
bmftrfil_sql Product Feature File
bmoptexc_sql Option Dependencies/Exclusions File
bmoptfil_sql Product Option File
bmprdstr_sql Product Structure File
cmcurcod_sql C/M Currency Code table
cmcurrat_sql C/M Rate Table
cmprccst_sql C/M Price/Cost Table
compfile_sql Company File
hzcdefil_sql Manufacturing Codes file
hzcrwfil_sql Manufacturing Crew File
hzctlfil_sql Manufacturing Control File
hzctract_sql Manufacturing Work Center Account File
hzctrcap_sql Manufacturing Work Center Capacity file
hzctrfil_sql Manufacturing Work Center file
hzctrmch_sql Manufacfuring Work Center Machine File
hzempper_sql Manufacturing Employee File
hzeqpfil_sql Manufacturing Equipment File
hzernfil_sql Manufacturing Earnings Codes File
hznotfil_sql Note File (Only Routing Notes Upgraded)
hzocfil_sql Manufacturing Operation Code File
hzplpfil_sql Manufacturing Product Load Profile file
hzrptcal_sql Report Calendar Header file
hzshpcal_sql Shop Calendar Header file
hzshpdtl_sql Shop Calendar Detail file
imcatfil_sql I/M Item Product Category File
imctlfil_sql I/M Inventory Setup File
iminvbin_sql I/M Inventory Bin File
iminvloc_sql I/M Inventory Location File
imitmidx_sql I/M Item Index (Master) File
imitmnot_sql I/M Note File
imitmtxt_sql I/M Item Text File
imkitfil_sql I/M Item Kit File
imlfmst_sql I/M LIFO/FIFO Master File
imlocfil_sql I/M Location File
imlsmst_sql I/M Serial/Lot Master File
immatcst_sql I/M Material Cost Type File
imsubitm_sql I/M Substitute Item File
imtyploc_sql I/M Material Cost Type Location Account File
jobfile_sql Job File
lpctlfil_sql LP Control File
lpernfil_sql LP Earnings File
lpsftfil_sql LP Shift File
mcctlfil_sql MCA Setup FIle
mrctlfil_sql MRP Setup file
mrlocfil_sql MRP Location file
msctlfil_sql Master Schedule Control file
msfrcfil_sql Forecast Orders File
mspcwfil_sql Master Scheduling Product Category Work File
msschfil_sql Master Scheduling file
oecarcde_sql O/E Carrier Code File
oecmtcde_sql Comment Code File
oectlfil_sql O/E Setup File
oecusitm_sql Customer Item File
oeprcfil_sql Price Codes File
oeprdact_sql Product Category Account File
oermactl_sql RMA Setup File
oeshpldt_sql O/E Shipping Lead Time File
pocomcde_sql P/O Commodity Code Work File
poctlfil_sql P/O Setup File
poitmvnd_sql P/O Item Vendor File
polndcst_sql P/O Landed Cost File
poprpven_sql RFQ Prospective Vendor File
poqtelvl_sql RFQ Quote Level Approval File
porfqctl_sql RFQ Setup File
poshpfil_sql P/O Ship-To Code File
ppcstcap_sql Production Captured Cost File
ppcstfil_sql Production Order Value Added Cost File
ppcststr_sql Product Structure Cost File
ppctlfil_sql POP Setup File
prdirfil_sql Payroll Directory Table
prempfil_sql Payroll Employee File
qectlfil_sql Q/E Setup File
qecusfil_sql Q/E Prospective Customer Table
sccstfil_sql Cost Master File
scctlfil_sql Standard Cost Setup File
sfctlfil_sql Shop Floor Setup File
srctlfil_sql Standard Product Routing Setup File.
srdtlfil_sql Routing Detail File
srrtgfil_sql Routing Header File
sycdefil_sql System Code File
syprdfil_sql System Period File
syseqctl_sql Sequential Forms Control File
sysnotes_sql System Notes File
taxdetl_sql Tax Code File
taxsched_sql Tax Schedule File



Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[MacolaHelp]

Without AR/AP open or any GL files converted, I am unclear as to how this could be implemented. Don, are you in touch w/someone in Marion that can "educate" us about how this is supposed to work?

 

[dgillz]

Exact's position is that you key in a journal entry. That is a TWO LINE journal entry, one debit and one credit, for every single open item in your AP and in your AR.

This is potentially thousands of lines. This is not difficult, just time consuming. Evidently some are willing to do this to go to ES. This is exactly what we did at Triangle Partners when we went to Macola ES internally several months ago, but the average distribution or manufacturing business has a lot more AP and AR transactions than we do.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[crystalreporting]

Great feeback - thanks for the list Don. I guess my concern is more with the history. Even our largest customers could key in their open items, open orders etc. and as MacolaHelp pointed out, we may be able to 'sell' this on the basis of cleaning up their existing system. However, very few of our existing customers will be willing to give up their history. I understand MacolaHelps suggestion of being able to report off these files - but by the same token, how difficult would it have been to convert OEHDRHST, OELINHST, PPORDFIL (closed orders), IMORDHST etc. particularly given that the file structures have changed little in distribution?

Peter Shirley

http://www.linkcorp.com

 

[dgillz]

I think we all need -- both resellers and endusers -- to put pressure on Exact to get the conversion done ASAP.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[MacolaHelp]

I'm going to guess here, but I would imagine that the conversion is hitting snags on putting the non-master files from accounting into that giant db that exact globe/esynergy use. If that is the case, then if we agreed to give up AR/AP open HISTORY, audit trails, etc., maybe Exact could re-focus on the distribution & mfg history files. Do we no longer have an AR/AP open item load? Pity if that's the case. And for us poor souls that still have Macola PR clients . . .

Or should we collaborate to address key files that Peter has indicated are priority for his clients if that would get them moved over to ES? Then at least our clients might be able to offer some beneficial suggestions to the code as early users that exact might implement ??? Over time, I found that I often need to modify data files (wish I didn't), & do so with relatively little fear these days.

There will be nothing worse than taking an existing good faith client through the pain & expense of a conversion only to find that something doesn't work that they've always used. Especially risky here, since there are no programmers left @ exact from v6 & not many (if any) from v7. Perhaps that is the reason we have conversion utility problems? Maybe no one in Marion understands the underlying file structure anymore?

 

[crystalreporting]

Maybe Exact could offer three conversion levels?

Level 1. The one that does the master files only (the current upgrade utility).

Level 2. Level 1 as well as any distribution history files e.g. OEHDRHST, OELINHST, IMORDHST, PPORDFIL etc.

Level 3. Everything - master files, open trx and history.

Peter Shirley

http://www.linkcorp.com

 

[canimp]

There are some very adept programmers who understand the underlying tables from 7.5 up to and inc. ES - however, they are employed by regional offices - often for customizations, as well, they've also had success in writing their own tools to bring over historical data and open transactions.

Perhaps that is an interim solution for clients who desire to go to ES immediately? bring over the master files, then use other programmers to migrate the historical data.