Sage 100

We discussed this with a client but they didn't decide to move ahead with it.  Our quick analysis was similar to yours - it appears that the building block elements of OM could be exported and then imported to PM because the data is similar.  We have an import for templates but haven't done one for work tickets.  Activity and transaction history would be a bigger challenge with the number of tables involved.  We thought the current cost state of the work ticket would come along with the step detail and the totals data on the header.  We also agree that the sales orders would have to be re-imported and thought the link to the work ticket could be included in that process.

The removal of OM and what that might do to the Sage 100 install was a big question mark we had too.  It's hard to imagine it being a simple, clean process.  However, the long-term benefits of being on the new version of PM vs having to deal with OM could easily make the process worthwhile.  Add in that unless the manufacturing company is making highly customized products to order simply doesn't need OM and the cost is probably worth it over time.

If your client is willing to give it a go and we can assist with the process let me know.

So we have actually done this though we did NOT try to bring in history, to Bernie's point that would have been pretty hard.  We took the job ops info and wrote all the data into a SQL database so we have it if they want it and can make reports, but they were okay with the item transaction history being there.  We did run into a couple of things, they were going to 2022.  One the import of a work ticket if you provide the work ticket template IT DOES NOT automatically go and pull the steps and material, this was road block one.  I ended up exporting from the Job Ops system all open work tickets, uploading that file into a SQL table and used BOI to create the work tickets from the data, this way I could use the work ticket template to pull in the steps and materials.  That said we sort of had a great scenario since they did not use actual labor or material it was all backflush.  I was able to establish all the open work tickets.  They also did all job ops work tickets under the same customer number because really they functioned more like make to stock.  So identifying those sales orders and removing them was not an issue.  We were able to export and import the template information but I know we did run into an issue with the extended description, our master developer had to write some around that I would have to check.  I would say it wasn't easy but it's doable, it's really setting expectation with the customer on what will be available history wise if they leave it behind, in our case they were okay not having that history in lookup screens, as long as they could run a report.

My client also has Scanco multi-bin, did your client have this?  If this happened, I would switch them to the DSD multi-bin.  They also use scanners, but switching to ScanForce does not concern me.

So we have actually done this though we did NOT try to bring in history, to Bernie's point that would have been pretty hard.  We took the job ops info and wrote all the data into a SQL database so we have it if they want it and can make reports, but they were okay with the item transaction history being there.  We did run into a couple of things, they were going to 2022.  One the import of a work ticket if you provide the work ticket template IT DOES NOT automatically go and pull the steps and material, this was road block one.  I ended up exporting from the Job Ops system all open work tickets, uploading that file into a SQL table and used BOI to create the work tickets from the data, this way I could use the work ticket template to pull in the steps and materials.  That said we sort of had a great scenario since they did not use actual labor or material it was all backflush.  I was able to establish all the open work tickets.  They also did all job ops work tickets under the same customer number because really they functioned more like make to stock.  So identifying those sales orders and removing them was not an issue.  We were able to export and import the template information but I know we did run into an issue with the extended description, our master developer had to write some around that I would have to check.  I would say it wasn't easy but it's doable, it's really setting expectation with the customer on what will be available history wise if they leave it behind, in our case they were okay not having that history in lookup screens, as long as they could run a report.

Hi Michele, I am sorry for the late response. 

There is an Operations Management utility to migrate Production Management to OM.

Thanks,

Gil