Design Notes

A few thoughts on the design of this application.

The following objects/components will be needed.

• User: This will represent each unique user of the application. Each user will be able to configure a Tally Connection and associated transactions.
• Company/Organization: This is a group of users. It is provided as an object in case there is a need for multi-tenancy later.
• Tally Connection: This contains the information about the tally connection itself. Each tally connection needs an IP address or URL, port number and company name.
• Transactions List: This contains a list of transactions that will be supported by the application. Each user can then turn on/off the transaction that they want to transmit to their Tally connection.
• Transaction: Each transaction that will be sent to Tally.
• Response: Tally's response for each transaction will be stored online. It will contain the latest response for the transaction in this object. This is to prevent the responses or lack thereof when the transaction has not been successfully posted and is queued in the system.
• Transaction Queue: The transactions as received by the system will be stored in a FIFO list or a queue. Some transactions might be dependent on earlier transactions, hence the need for the queue.
• Object Maps: This is to be revisited later. Initial thoughts are that some account heads in Tally need to be specified before a transaction can be sent. For instance, some users prefer to store all their customers/vendors under sundry debtors/creditors. This is the default behaviour of the system. If users store additional groups under sundry debtors/creditors, the wrapper needs to know. This could be one of the means of defining it in the system.