Client had the last version before Denali and it was not on MS SQL.

I will look into your suggestions and see what we can do.

You may want to use the SlimAPI as a REST client to push batch info into FA.

The version of the REST API tested for FA 2.4.x is here.

I researched open source EPR systems because the client does not wish to continue with CMS software.  They spent a lot of money to try to get Denali to work and Cougar was not having a lot of success converting their data to it.  On top of that Cougar no longer supports anything other than Denali and their support leaves more than a lot to be desired.  They would not even refund the client for what they spent trying to get Denali to work.

The client is running the legacy CMS 18.1 software on Windows 7 Pro 32 bit, but they are looking to the future because of limitations in the software and the ability to move to newer hardware when it becomes necessary.

As I mentioned before, I have been able to load the necessary FA database tables with data from their CMS system.  That includes their COA, etc.  They can test the on-line FA system for functionality at present, but would need to be able to do batch processing for all transactions, in particular Order Entry and POS (up to 4 registers) before they could fully transition to FA.

Importation of data into FA is not a problem for me.  Between SQL scripts, phpMyAdmin and MySQL Workbench I have that covered.

As an example of what they do now, let us take Order Entry:
  In CMS when the user goes to enter a new Order, the software allows them to create a new Batch, or use one that was created previously.  This may happen many times a day in different batches.  They do not want these batches posting through to the G/L until they are ready to do that.  Inventory items selected in a batch must appear as committed in the stock and removed once the batch is posted.  If any batch containing items is deleted then those items must be released back to stock.

With POS, each register would start a batch each day, be able to check it at the end of the day before posting it.

I worked my way through the first PDF describing how to do Modules/Extensions, but the second PDF with Security and the rest I could not find.  I believe that you were working on a translation from Spanish.

I will have to check what updates were applied to 2.4.4.  I believe I installed one, but not sure if it has the Git Master updates.

You can run VMWare Player in your Win7+ workstations and run WinXP in a Virtual Machine in it where your legacy CMS client can run. That way, you will not need to change the software and the way you run your business.

Have you setup your Chart of Accounts in FA and tailored it to suit your existing one in the legacy CMS?
You will need to use the latest FA v2.4.4+ Git Master as it sorts out quite a bit of issues.

Perform one batch of one type of transaction with just one transaction in it and compare the before and after backups of the sql - you can then figure out how to frame the SQL statements to import a full batch.

1. Cougar Mountain Software CMS - Last version before Denali.
    Will not run on any Windows beyond 7 Pro 32 bit.

2. CMS is currently on a MS Server 2012 in-house server supporting 10 workstations.

3. FA 2.4.4 is on client's web-server with SSL Cert.

4. I have extracted & imported the folllowing from CMS to FA:

  Vendor Master - (suppliers)
  Customer Master - (debtors_master)  Also SQL to Branches
  Inventory Master - (stock_master)  Also SQL to item_codes and prices
  item_categories, COA, taxes, etc.
 
Please elaborate on your thoughts.

Thank you.

A Legacy Accounting client is desiring to use FA if Batch Processing can be implemented.

Project Requirements Outline:

1. A "Batch" tab on the main navigation with options below to:
   (a) Create a New Batch
   (b) Select an Existing Batch
   (c) Post a Batch
   (d) Delete a Batch

An auto-generated batch_id could be retrieved from Transaction References.
While a second user supplied description field would make the batch unique.
Date & Time data could be automatic or user entered.

2. These batch_ids would need to be selected when entering Sales or other types of transactions. This would require the addition of a drop-down selection for choosing the appropriate batch.

3. In Sales-> Order Entry e.g. there could be a number of batches depending upon purpose.

Inventory would need to be committed upon Order creation and removed once the batch is posted.

Similarly released if the batch is deleted.

4. POS would have unique batch_ids based upon register location/id.

5. Batch Listings would need to be run and corrected before any batch could be posted to the G/L.

6. Other considerations such as reporting, etc, to be determined.

Please submit your proposal detailing time-frame and cost in USD

This is a paying job and the client is willing to allow the successful project to be added to FA under Open Source License.

Thank you,

neholtz