TECHNICAL OVERVIEW
 
The reasons for introduction of TallyServer have been to address the following issues:

• People with branches / factories etc. have had a perpetual difficulty in ensuring that all transactions of the remote location are available at the head-office. They have, typically, used the export/import method of getting their information across... sometimes with unpredictable results.
  

• People have several programs running with some functional overlap with Tally, and sometimes-just information sources available, which are relevant along with Tally. Typically, the only way they can share/exchange information is to write import/export routines to get the information together.  

THE SOLUTION

Let us take the first problem - replicating data from remote locations: 

We shall assume that the Head Office is connected to the Internet through a leased-line, and therefore, has a ‘fixed IP address'. 

A user can deploy a ‘TallyServer' (which is nothing but normal Tally with the ‘Server' capabilities activated) at the Head Office, and TallyClients at the remote locations (a TallyClient is also normal Tally with ‘Client' capabilities activated). 

Each remote location then creates a ‘Rule'... which is essentially a ‘request to allow data synchronization' with the Head Office. At the Head Office, the administrator ‘allows' this Remote location to exchange data with it. 

Now, whenever the remote location connects to the internet, they can select to ‘Synchronize' their data, and all updated transactions and masters will automatically get exchanged with the head-office, so that both places have identical sets of data available. 

This is the simplest use of TallyServer and TallyClient... 

At a more complex level, and with the help of some programmers who are adept in TDL and/or Web programming, a user could ensure that data is exchanged only after some ‘modification' has been made to it (for example, data coming from location A would automatically be assigned to cost-center A, or that a Delivery Note for material sent to Head Office becomes a Receipt Note at the Head Office). Highly complex environments can be created using this mix of programming. 

Taking the second problem - which is working with multiple programs: 

A TallyClient has capabilities to ‘push' information to a listening ‘server' (which is what is described above), and also, capabilities to ‘pull' information from another ‘server'... 

Thus, a TDL programmer can use Tally and pick up information from other ODBC compliant databases (which basically means almost all commercial databases like Oracle, MS-SQL, DB2, Access, Foxpro etc). and represent it in Tally. For example, a user could get a report of the current list of Outstandings, customer-wise, with an additional column showing which Salesman is attending the customer, when the last visit to the customer was made, and when the next visit is expected (this information probably coming from his Customer Relationship Management software). 

On the reverse side, if a TallyServer is installed, a user could write programmes in Visual Basic, Java, Perl, Visual C++, or other scripting languages, to extract information from Tally to use in other applications. One example of this is already available through ODBC. However, the ODBC approach is a little limited in the range of information which can be supplied from Tally... and a person adept in TDL and another scripting language can create esoteric applications. For example, if a person wants remote users to enter vouchers using a browser over the Internet, then a combination of TDL and ASP/Java programming can achieve it. This, of course, requires that TallyServer be installed.