As you will realise, as it is Microsoft SQL Server that is used for the AstrA Millennium for PC and AstrA Millennium for Mac database, any SQL savvy application such as MS Query, Excel, Brio and your own choice of application should be able to generate custom reports and extract data. Actually preparing the application for such file operations is of course the essentials of this process and needs careful and accurate planning.

We have therefore put together a plan of action and implementation (which is not exhaustive) for our users' consideration. Carefully examine this and consider the implications involved. Do remember that any work undertaken by S&S Systems is on a 'time and cost' basis and so this plan must be as accurate and practical as possible to avoid any unnecessary expenditure and wastage of time and effort.

You will need to do at least the following to achieve a practical and effective integration of your application into AstrA:

• Produce a summary which clearly and accurately documents all the business requirements and all proposed business processes, eg inserting, updating, deleting and selecting information in any database. This will clarify what you are trying to do and help judge the scale of your requirements. This will enable us to see what you want to do is in fact both reasonable and achievable.
• Document your technical environment and how you propose to integrate it with AstrA, for example, are you planning to call SQL Server directly from your application? What connectivity are you planning to use? Please note that the Stored Procedures created by S&S are only part of the process and there are a considerable number of other Transact SQL commands required to ensure correct operation, eg, error checking routines and data validation.
• Document what level of work is to be completed for each desired task, eg the creation and filing of a Manual Sales Invoice, for both AstrA and your application. You will need to assess the capability of the application being used to handle error situations such as multi-user issues, incorrect account or stock code entries and how they will be handled. This needs to be done on a task-by-task basis as all operations are uniquely different and require specific care and handling.
• Define at what point your application will transfer the required parameters to an AstrA Stored Procedure ready to process the transaction and how your application will handle the responses from SQL Server. Careful consideration should be given to error messages that would stop the transaction being completed and how your application would reverse (roll back) any partial update of the database due to the error.
• A fully documented manual and procedure to perform and implement product Acceptance Testing. This should be compiled by yourselves and a completed copy of a fully accepted report should be submitted to S&S. The Acceptance Testing should consider all areas that your application will integrate with AstrA, what you propose to do, the test and validation data and the confirmation of the test. You should also document what action should be taken where the requirements cannot be achieved and what action to take.
• Detail the relevant sections to be used within AstrA, eg Sales, Purchases, Stock, Nominal, Multi-Currency, etc and what parts of each of these sections will be handled by your application. You should also carefully detail what functions your application cannot achieve and what your proposal is for any shortcomings in your application.

Detail the absolute task for AstrA, ie what are you going to use AstrA for? For example;

• How will settlement terms be calculated?
• How will Invoice Numbers be generated? Are such as Sales Ledgers going to be maintained in AstrA and if so, how will other balancing transactions such as Credit Notes, Adjustments, Payments, Cancelled Payments be handled? Will AstrA be used to produce a Nominal Ledger, Trial Balance, Profit & Loss, Balance Sheet, Vat Return? Where any area of AstrA is to be maintained and updated by your application, again, careful consideration should be given to how such as the associated Sales Nominal Accounts will be updated and how your application will know about the appropriate nominal accounts to use and update together with the basic Control Accounts such as Debtors & Creditors, Vat etc. This is only an example and so you should consider the action of any and all transactions handled by your application and what impact they will have on your Astra database and then take appropriate action.

Detail the construction of your local application database. You will need to construct some form of database in your application to maintain the various details that are updated and held in AstrA for localised use in your application, eg User Names and Passwords to enable the correct level that users may use the AstrA database for such security and auditing purposes. You will also need to define the various fields that will be used to process transactions and how these fields to be edited and how calculation fields are used, eg Prompt Payment Discounts and how they would effect the VAT amount.

Detail the process used to maintain an up-to-date set of file information. Will your application maintain such as its own client data and how will this data be synchronised with the AstrA database in real-time?

Report Generation. Detail the report data and the method used to extract it from the Astra database. The stored procedures require specific data to be sent to them to generate reports. The date that is then generated would be sorted in the 'front-end', ie AstrA. How do you propose to handle the data that is returned by SQL Server? Note that simple file buffering is not adequate as large amounts of data can be returned and routines to handle such as Cursor Rows should be implemented and documented.

You should also have the in-house expertise, specifically for your chosen application, as S&S cannot not offer any support on 3rd party applications. You should have experience and your application should be capable of at least the following:

• Gracefully connecting and disconnecting from SQL Server.
• Sending Transact SQL statements to the server and reading returned result sets.
• Start transactions, interrogate results from subsequent commands, rollback if there is an error and finally commit the transaction if all is OK.
• Understanding all of the return codes sent from ODBC commands.
• Executing and sending data to Transact SQL Stored Procedures
• Manipulating SQL Server-side Cursors, returning data row by row and finally dropping the relevant Cursors.
• Your application should have corresponding variables to SQL Server, eg Variable length strings, a Money compatible variable, 8 byte reals, 2 and 4 byte integers, Dates (inclusive of time), Timestamps, etc.

Once we have a specific breakdown from you as above, we can consider the time and costs involved and move forward to the next stage.

If you require any further information/assistance regarding this matter, please do not hesitate to contact us at info@AstraAccounts.co.uk.

Yours sincerely


S&S Customer Support

Please add to Favourites and visit again - (c)   S Alsop

Please note that although the products offered have been developed with great care, no liability is assumed for any error, loss or damage (direct or consequential) caused by their use. It is up to the purchaser or their agent to satisfy themselves as to the suitability of all of the products. Please click here to see our full Terms & Conditions. No-one is allowed to alter these terms on behalf of us. Typing errors and price changes reserved.