Add to Favourites

Insights on Customising TallyPrime 

It is mandatory to have a deep understanding of the features of TallyPrime before trying to customise the product. Similarly, you should know the various diversity of users and the way they are operating TallyPrime.  Finally, you should know the purpose of customisation and the right way to execute that. This document is meant for giving insights to the professionals like Business Analysts, Developers, Support Executives, and all those who are involved during the customisation.

Know Your Product

The topic Get Familiar with TallyPrime on TallyHelp will give you a basic understanding of TallyPrime. Firstly, try to understand the purpose of the TallyPrime and understand the product from the users’ perspective. It will give you the right approaches for customising TallyPrime. Understand Tally’s Promise, technology, principles, and the choice of building business solutions for small and medium businesses. 

Brand Promise

“You can Focus on your business and not on the software” is the commitment from Tally. The pillars of the Tally are Simplicity, Speed, Flexibility, and Reliability. These points need to be ensured in the customisation as well. 

1. Simplicity means Tally is so simple, easy to learn and operate. Install and start running your business in minutes! The core philosophies on which Tally is built are, errors are natural, and users should always be able to discover and correct them in an easy and simple manner. 
2. Reliability means the user should be able to trust all the information that it presents!
3. Speed is experienced, the delight of an ‘instant’ software beats everything else. The speed is not just involved only in generating the reports, it should be thought through for any interaction flow like creating masters and transactions and any configurations as well.
4. Flexibility means Tally suits for a various diversity of users and the businesses

Features of Tally

You need to understand all the functional features of Accounts, Inventory and Statutory modules. One should be aware of the technical features of Tally as the required features have to be taken care of in the customisations as well.

• Print, Export, e-Mail
• Data related – Import, Export, Backup, Restore, Split, and Data synchronisation
• The options for data integrations
• Supported OS, Bitness, and the compatibility of other applications like Excel
• Accessing Tally online through – Remote Login, Browser, and other modes like RDP / RDP browser
• Security and User Management 
• Accessing data over TallyPrime Server
• The configurations/settings of the application

Design Patterns and Principles

The users should feel that the solution is built for them. In order to archive that Tally ensured the aspects of Simplicity, Flexibility, Speed, and Reliability. The importance of knowing the design principles of the product, its capabilities, and at least a basic understanding of your customer cannot be understated. Only ‘simple yet impactful’ stories get retold.  This happens when stories are built on ‘principles’ – which tend to get remembered.

Flexibility

This interaction design helps us in achieving unmatched flexibility which allows us to adopt rather than enforce. 

There are cases where the business processes cannot be managed with the predefined order. The fundamental tenet of ‘Flexibility’ addresses this need, for example, to procure material from their supplier they might issue a formal purchase order and expect the material to be received and tracked as per terms of the purchase order, for another type of purchase they want to record purchase voucher without purchase orders. Irrespective of user behaviour the application should be flexible enough to support the user to record the transactions and provide the necessary warnings and information.

At the same time if a business wants to be organised we have enough provisions in the system to help them in getting organised.

There are several examples that exhibit how we have allowed the business to handle exceptional situations delightfully, allowing to record cash payment even if it shows negative cash, allowing to sell even if the stock shows negative stock. Similarly, if a business wants to be organised we have given appropriate checks and balances to help them to work in an organised manner without compromising our promise of speed, simplicity, flexibility, and reliability.

We believe any exceptions can occur at any time so that anything should be allowed to be corrected and everything should be allowed to be discovered/detected.

One such example is ‘process flexibility’ – where everyday business processes are not ‘consistent’.  For example, in any given organisation, some things may be purchased by placing an order, ‘receiving the material’, ‘receiving the invoice’, ‘paying for the invoice’.  In the same organisation, for the same product, one may simply ‘receive the invoice with goods’ – and not have the prior two steps.  Again, in the same organisation, one may actually make each step of the process in different orders – simply because assigned people for the task were not available. 

Therefore people do not introduce to a new system and need to ‘adapt’ it for the sake of using the software. The entire cycle of adoption becomes ‘simple’ and ‘fast’ when the software accepts the current way of working.  Otherwise, the conversations relating to ‘changing processes’ will arise and its decision may not beneficial for all. This is also captured in our founder’s words: “When I buy a car, I want to be a driver and not a mechanic.  In the same way, I want to run my business, not your software.”

Tally’s interaction/interface design provides flexibility to the user rather than enforce. Tally’s core philosophies are to recognise, errors are natural, and the user should always be able to discover and correct them in an easy and simple manner. There should be a way to discover/detect all the errors in order to correct any errors. This approach derives not only flexibility, the reliability as well.

Handling Diversity

Any major features in Tally can be enabled as per the business need of users. Thereby, the user experience is made simple by showing only the mandatory fields for any feature. 

For example

1. The bill details will be shown to you only if you have enabled the option ‘Enable bill-wise entry’ in the company features.
2. The GST details will not be asked in Ledger unless the GST feature is enabled in the Company features.

The interaction design of Tally allows providing legendary simplicity. The user needs to learn a few keys to operate the entire software, enter and escape keys are examples of those. 

• ‘Users’ are handled through ‘Setup/Configuration’
• ‘Situations’ are handled through ‘Interaction Design’

For example, what is “normal” for one user, maybe an “exception” to another?  Now, for the first user to treat it as ‘normal’, there would have been a ‘setup or configuration’ step.  It is easy to confuse this with ‘having solved for the second user’. 

The more we cover the functionality the more user diversity as well increases. Since different people will have varying requirements of flexibility, and the same person will have varying requirements of flexibility in different functions of the organization – it is important to use this principle to achieve simplicity for all, rather than commonality for all.  It will make each person feel that is ‘designed for me’.  Therefore ‘do not design as common for all’ but ‘best for all’.

Another important facet of the same thing is making the customer understand ‘why a particular approach was made just for them’ – giving the customer a sense of ‘if this was done, it shows that people behind it understand my way of working’.  This gets retold several times over – as they will share those stories with their peer group with the words ‘these guys know what we need’.

On the flip side, if we ‘design for all’, the chances that ‘no one can now use it’ increases exponentially – since the system becomes too complex, too slow, less reliable – all of which are ‘basic tenets for successful adoption’.

With each passing time cycle, we will be ‘adding more users’ – and occasionally adding ‘more functional areas’.  With each more user, existing functionality may need to increase its flexibility (which is anti-simplicity), or need new functional areas (again, anti-simplicity, but also anti-speed, anti-reliability. If any aspect is not done well, it will reduce the impact of the whole feature.

Handling Unknown Situations

There are chances for unknown situations. For example, while designing for receiving the money there can be options for Cash, Credit Card, Debit Card, Paytm, UPI transactions. However, there are chances the customer may be bringing the voucher or coupons. Therefore, there should be feasibility to accommodate such scenarios. There can be an option as ‘Others’ to record such entries. These scenarios all customers may not explain.

Speed

The speed is ensured in Tally with obsession, with a complete absence of tolerance. 

Speed in Functional Aspects

After installing Tally one can directly go to the voucher entry screen and start creating a voucher. The books of accounts can be created quickly. Multiple masters can be created in few minutes by using the options like multi ledger creation, multi-stock item creation. The interface for creating master and transactions can be configured with the field as needed. Thereby it minimizes the time to create masters. Altering masters and transactions are also simple. One no need to go through all the fields to change particular information. By using the option ‘more details’ you can alter the information quickly.

The reports are generated instantly. You can change the view of the report and again the report gets generated without any additional time. Further, you can drill down reports till you reach vouchers without any additional time. There is no input required to generate reports, the period for the report is pre-defined based on the nature of the report, like the current day or a month, or a year.

The blazing speed of data entry is achieved by

• flow-based data entry which allows users to do faster data entry without any interruptions in-between.
• a quick movement of the cursor between fields during data entry, near to zero interaction with the disk drive helped us in achieving this

Speed in Non-Functional Aspects

Tally can be deployed and start using it in a minute, and so while upgrading to the new releases. The data integration between Tally and other third-party applications works faster. For example: Exporting data into Excel or importing data from Excel.

Learning or Teaching Tally, that requires very minimal time as the design patterns are simple and consistent in Tally. The context-based help instantly provides references when the user clicks the button ‘Help’. For example, if the user clicks the ‘Help’ button from the payment voucher then the help content related to the payment voucher appears. 

The application development language, TDL, enables the developers to build the solution on Tally rapidly. 

Reliability

The aspects of completeness and correctness have to be thought through either while receiving the data for processing or while generating the reports. Reliable information is key for relying on software. We chose to favour reliability over speed. If information is correctly stored on disk will only allow showing information reliably. Hence, appropriate checks and balances are in place to ensure correct data is entered and stored in a database. 

For example

1. A voucher cannot be entered manually or imported when the debit and credit values are not equal
2. A ledger cannot be deleted unless and until all transactions pertaining to that ledgers are deleted. 

The controls are built into the system to input the right data.

For example

The cost centre allocation should match the ledger amount, Similarly, the bill allocations should match with the ledger amount.

Prevention of Errors

There is a warning message given while entering the cash payment voucher while the cash balance is negative.  It is allowed in the system to move forward, as the situations are natural. For example:- This might happen where the payment vouchers are entered before the receipt vouchers are entered. It occurs when two different users owning the payment and receipt vouchers or the user kept a receipt voucher on hold for some reason. However, the negative balance is highlighted in Cashbook for the user to see and correct it.

Continuity, Cross Verification, or Triangulation of Data

Basically, it implies the ability to get to the same result in more than one way, and/or how the result is computed from its source, and/or whether the information train has continuity.  This increases the ‘trust’ in the work one is doing – and not just the ‘trust’ in the system.

The most important example of this is the concept of ‘Drill-down’.  When you see a ‘number’ (say 10,000), and drill down, the number 10,000 itself must be visible on the screen (continuity), whose ‘breakup’ is now available in some form or other (whether by period, by transaction, by the value of children, etc.) – which shows how the result is ‘computed’, and finally, if there is ‘more than one way’. 

The basic rules which govern Drill Down are:

1. You should be able to drill down from any result – which should always show how the result came into being (see Information Design).
2. This should continue indefinitely until you reach the ‘modifiable’ data – at which point, it should allow you to modify it.

It is important to consider here that there are two ‘types’ of ‘drill down’.  One which creates a new report, and one which opens the details in place (called ‘Explode’ in Tally parlance).

Sometimes, the details associated with a result are too small to merit a new report – and the ‘Drill Down’ results in an ‘Explode’.  You see that in the case of Bills, Orders, and likewise.  You could be ‘drilling down’ from ‘Group Receivables’, and reach the ‘Bills of a given Ledger’, and the next ‘drill down’ action actually ‘explodes in place’ the contributing transactions, which – in turn – can be ‘drilled down’ to alter the transaction.

Note : If there is multiple information then that breakup can be given in the explode, then from explode the drill-down can 
be provided to alter the information

For example, it is not about a ‘field which accepts a string’ – but ‘a field which accepts a ledger name’ versus ‘a field which accepts an alpha-numeric Order Number’ versus ‘a field which accepts a Description’, and so on.  Similarly, you have a field that accepts a ‘Date’ versus an ‘Amount’, and within them, one which accepts a ‘From Date’, ‘To Date’ or a ‘Due Date’.

To an end-user, it feels that the product understands the ‘intent’ of the input since it knows the ‘context’.  This may occasionally require hand-crafting, particularly for possible circular dependencies. “To Date” is equal or greater than From Date, and From Date is equal or lesser than To Date, for example … since the user may be entering/modifying any one of them.  It is quite frustrating that the ‘current period’ – for example, is ‘Apr to Jun’, and you want to change it to ‘July to Sep’, and when you are trying to enter ‘July’ the system complains because the ‘To Date’ is currently ‘Jun’ … effectively ‘forcing’ the user to first make the ‘Jun’ to ‘Sep’, and THEN come and change Apr to Jul!  

Simplicity

It is a multi-dimensional aspect as holistic simplicity comes from various facets of experience.

1. Absence of clutter provides simplicity in the user experience
2. Familiar behaviour
3. Ease of training
4. Consistency
5. Minimal user interventions
6. Language
7. Intuitiveness – It drives the ability to self-learn

Simplicity is one of the important aspects for successful adoption. It ensures that people are able to adapt the product themselves, or with very limited external help. It allows people to quickly become ‘experts’ to assist others. The quest for simplicity is beautifully captured in our founder’s words: “Are you writing programs to make the life of the user easier, or the life of the programmer easier?”.

The first principle to understand is: no customer ever ‘wants’ help. They have their business to run.  They may ‘need’ help – because they are unable to run their business the way they wanted to. There will be a ‘negative’ network effect if not resolved rapidly.

User Interface

The user interface is designed to provide a seamless experience to the users. It is the power of simplicity,  The user is allowed to achieve the result as per his/her choice with minimal interaction with the application, naturally. Our interaction design allows us to provide legendary simplicity.

For example

1. Both single entry and double entry modes are supported vouchers. Further, if it is a double-entry mode, then the ‘By’ and ‘To’ can be changed to ‘Dr’ and ‘Cr’.
2. One needs to learn a few keys to operate the entire software, For example, only the ‘enter’ key is used to navigate from a report to the voucher and coming back to the main report using the ‘escape’ key.
3. To see a daybook report for April 1, 2020 we can enter the date with minimal keystrokes in the date field like 1.4, 1 space 4, 1/4, or 1-4 without specifying the year as the year is already in the context. Moreover, just type a for April and d for December. if it is June or July then we need to type the first three characters of the months either Jun or Jul to differentiate between these two months as both the name are starting with ‘Ju’. And when we just type the name of the month, it picks the first day of the month in ‘From’ date field and similarly, it picks the last date of the month in ‘To’ date field. If the period is applied for a day, then the title for the period would be ‘For 1-Apr-2020’ and if the period is more than a day (or for a month) then the title would be like ’1-Apr-2020 to 30-Apr-2020’. 
4. The Trial Balance report can be viewed by Ledger wise or group wise. Additional columns can be created for any period, with various stock valuation methods, with or without postdated vouchers, and with budget or Scenario. We can generate multiple columns automatically for Daily, Weekly, Fortnightly, Monthly, Quarterly, Half-yearly or based on stock valuation methods. To filter the report based on master, there is a button ‘Range’, the filter can be applied on the name of groups and ledgers, Parent, opening balance, closing balance, or based on the value of Total debit/credit transactions. Similarly, the transactions used for generating the report can be filtered using the button ‘Value’. The report can be filtered using the name of the voucher type, voucher number, cost centre, buyer/party name, date, ledgers, tracking number, banking details, or inventory details. To summarize, the options given for the user is like he can get the required information from the report the way he wanted it, without a report designer or reporting tool. It looks like the report purely customizable by the user on the fly!

Navigation and Hierarchy

Any major report in Tally opens for a particular period and it shows the summary. Further, the user can alter the report based on the options provided in the configuration. This helps the user to navigate and understand the information in the ‘Report’ step by step, as needed. This interactive design helps across the diversity of users.  It is possible to show the entire information with a single click, but it is complex for any user to read and understand so much information at a glance or finding information that he/she is looking for.

• The ‘real world’ is hierarchical and it is best represented in a ‘hierarchical system’.  Belonging to a ‘hierarchy’ is a special ‘attribute’ of any information.  Basically, any object – whether a company, or master, or transaction, etc. – will have several bits of information, which can be called it’s ‘content’ and/or ‘attributes’.  Each of them can have an independent value or be a reference to another object.  

• Thus, you can have ‘Groups under Groups’, ‘Ledgers under Groups’,  … contrasted with ‘Ledgers used in a voucher’ or ‘Vouchers of a Ledger’

• When something is thought of as ‘hierarchy’, the presentation design changes – since the way to navigate is driven by this concept.  It also drives the continuity/cross-verification/triangulation outcomes – as a natural way to view the buildup of a given value.

If the design is in the natural flow then it doesn’t require training or help content/user manual.

Consistency

The concept of consistency itself needs to be understood.  Is it ‘same key for the same function’? Is it ‘same width of same fields’? Is it ‘same size of same forms’? Is it ‘same layout of same forms’? Is it ‘same tone of language’?  As can be seen, in different ‘contexts’, the concept of ‘consistency’ is different. 

When ‘consistency’ is viewed, it must be simultaneously viewed for ‘each of those facets across the application’, ‘across all the facets in the current interaction’.  For example, the way a ‘button behaves in this context’ should be consistent with how they behave across the entire application. For example: In a ledger account report the F4 is used for changing the Ledger, Similarly, the same key used in the Stock item report to change the stock item.

The consistency built across the product makes the users easily learn and adapt. The entire product is built on a few patterns which are consistent across for example the pattern to create master is consistent across all masters, similarly the transactions and to deal with reports. 

Know the Product Roadmap

The road map of TallyPrime is available on the Tally website.  It will have the details of the upcoming features along with the tentative timelines. This will also help to visualize while deciding for any customisation that might get an impact in the upcoming releases.  

At the same time, it would be good to understand the reason of functionality or feature is not provided in Tally. It will give an idea to decide whether it is good to customise or not. For example, cost centre allocation is not supported in the invoice mode of purchase voucher. The reason is that there are various additional costs involved in the purchase, that are added to the cost of purchase. As this is automatically adjusted by the system. the cost centre allocation cannot be done by the user. Therefore, the cost centre allocation for not supported in the purchase invoice.

Know Your Customer

Environment of Users

• Single user accessing the data
• Multiple users accessing a single data
• Accessing a data over TallyPrime Server 
• Accessing the data over RDP
• Accessing the data as a Remote user
• Accessing the data on Browsers

The roles and responsibilities of users vary depends upon their size of business and its operations,  For example:

1. One person does multiple tasks,
2. One person’s job is to do invoicing another person is responsible for receivables and payables.
3. One person prepares a purchase order another person verifies it and the third person approves it then only one task is completed.

All these types of businesses are using Tally. Therefore, it is important to validate and ensure that the customisation will suit all these kinds of users or not.  

Environment of Various Situations

We have been designing and building software products for small and medium businesses. The ‘Nature of Market’ which we cater to is driven by certain behaviours for which our product is built. 

The knowledge of the customer environment is an important thing to consider before making a decision for extension or integration. If a customer falls under “Environment for which we are not built for’, we must avoid extensions that requires to generate reports by reading a large number of transactions – typically when ‘values’ are included as additional fields in a transaction, and reports are generated by computing on those values.  This should not be attempted as the only way to generate the reports is by traversing the transactions, and if that number is large, it can be time-consuming and bring down the overall responsiveness of the system. This is true for every type of customer irrespective of which category they fall in. The only difference is the heat of these extensions is faced in a very early stage by customers who fall under ‘Environment for which we are not built for’ as compared to the customers who fall under other categories.

There are businesses that outsource their accounting or compliance work, Our systems should be simple enough to share the required information with such people. And the people who provide these services should be able to consume this information quickly to perform the services they offer. 

There are certain situations where users will not have the ability to self-recover like power failure, disk failure but whenever the environment is recovered user should be allowed to recover tally quickly.

We believe these businesses will grow at their own pace, our software should support the growth with the same pace whether this growth is within the same business or opening of a new business

High volume of data and multiple users

These businesses will land up in generating a huge volume of data in terms of masters and transactions. Handling more masters and transactions is not a challenge, the challenge is sharing the data with multiple users simultaneously. Multiple concurrent users on the network will bring down the responsiveness of the system in these environments. The situation becomes worse if they have to deal with more large transactions most of the time. A large transaction is defined as one with several dozen referenced to masters and/or batches and/or tracking numbers. In such environments, TallyPrime Server looks the only solution to handle a situation that gives relief in terms of concurrency as it allows read + read and read + write to happen simultaneously apart from its other benefits like better data management and administration capabilities. As this handles concurrency in a much better way than what is provided by the operating system, to complete one task, users on the network need not wait for other users on the network to complete the operation. But the time taken to perform one task will remain as it is which means that if a report was taking 2 minutes to open on the network it will continue to take more or less similar time to open in TallyPrime Server environment as well.  Without the power of TallyPrime Server, it will be a poor experience and potentially make the system unusable. There are a few examples which help in understanding the responsiveness of system in various environments.

Large number of line items in a transaction

Similarly, having more line items in a single transaction is a challenge. To be more specific, the number of line items in a single transaction consists of a number of Stock Items, Batches per Item, Ledgers, Cost Categories, Cost Centers, Bill references. Our current database is designed specifically for a large number of small transactions, rather than large transactions. An occasional large transaction will not seem to make any difference but many large transactions will impact the responsiveness and if there are concurrent users accessing the data then the experience will not be seamless. 

Performance in customisation

We must understand the desired speed of extensions that delights customers can’t be achieved in these environments unless we pre-compute certain values, keep them in memory, refer them instantly as and when required so that instant reports can be generated. This is not currently possible through TDL unless user-defined aggregation capabilities are provided. Providing user-defined aggregation has its own challenges and the topic is not being picked up as of now to solve for.

Potential Approach for Customisation

It is impossible to support thousands of businesses and millions of users with a single product. Therefore, there is enough provision given to alter or extend Tally based on the business or user’s need. We must retain Speed, Simplicity, Flexibility, and Reliability as per the product principles. One must try to customise the product the way it is designed and the way it works. One can try to extend the feature but try not to change the behaviour, example one should not try to change the experience of creating masters, transactions or generating reports differently from the way it works today. Therefore, customers will not be introduced to any strange approaches and get confidence when the solution works seamlessly and they don’t bother about it. It allows them to focus on running their business, rather than worrying about ‘if this software does not help me, what should I be doing?’. We believe these businesses will take their own time to get confidence in the software and start using them at the appropriate point in time. If a ‘functional area’ is taken, ‘completeness’ becomes a journey rather than a destination. Hence incremental implementation is key. 

Tally Definition Language (TDL)

The Tally Definition Language (TDL) is the application development language of Tally and it allows to build the solutions faster. This allows matching with the speed of changes happening around, especially the statutory requirements,  which can adversely hit business if not provided on time.  TDL is a rich language that gives immense power in hands of the developer to fulfil the personalisation needs of businesses by designing and developing simple to complex requirements. 

TDL helps to fulfil various diversity of businesses and its requirements as all those cannot be implemented in the default product. The benefits of extensions can be best enjoyed by businesses if these capabilities are communicated properly and delivered as committed. There are certain things that must be considered before attempting or committing to the customer. Understand the fact that the richness of TDL doesn’t mean it can be used to build and deliver anything. 

Understanding the requirement

Probing the customer is important to learn the actual requirement of the customer

1. When to make an extension by changing the default code and when to make an extension with the new code.
2. Aware of the implications of customisation – it’s not one-time delivery, need to consider the future releases, maintaining the source code versions

Ensuring viability over the feasibility 

One should do the viability study even if the customisation seems feasible. There are a few things which you must know in the very early stages of engagement to help make the decision on ‘attempt or not’, if attempt, to what extent, if not, what answer should give to the customer: 

• Customer environment plays a vital role
• When things should not be attempted even if extensions are technically feasible
• Things that are not fully open for an extension so that communicate

Try not to attempt a certain type of extension that potentially breaks our promise of reliability. These extensions are not suggested because of the ability of language to get reliable information in concurrent operations. There is a significant difference in the validation / business rules written in the TDL layer vs the internal (platform) layers of the architecture. The platform layer ensures data reliability even during concurrent operations, which is otherwise not possible with TDL layer rules. All the possible use-cases and test-cases need to listed and tested. For example: If a field is added in the sales voucher, the use-case should be listed for all the possible sales vouchers and their various scenarios. Ensure that the custom solution is not impacting unintended areas of the features in the product.

We can understand this with the help of a few examples: 

1. The extensions require information to be stored/changed in various masters after creating/alteration of vouchers including company and other masters. This is not recommended in such an environment because the ability to find if some other user is trying to change the information in the same master is very low.  The ability to control this through TDL reliably is literally not possible. Hence, there are chances where we can land up in storing some information that is not reliable enough.
2. The extensions require auto-creation/alteration of some/selected vouchers after creating/alteration of vouchers. Similarly, in this case, also language doesn’t give enough ability to find the best and reliable way to identify things required to alter/create vouchers. The situation becomes more un-reliable in concurrent operations.
3. Core data integrity validations are NOT designed to be at the TDL layer for example when a transaction is made for a ledger, the ledger will internally update its ‘Use counts’ to ensure they cannot be deleted. While using an existing business object (say a cost centre) as a master with UDF (string) type of storage in the voucher for capturing, will not allow this level of data integrity validation to happen. Using UDF as master will not be reliable, as UDF (used as master) can be deleted even it is used in vouchers or in any other master.
4. Building behaviour similar to voucher numbering. Voucher numbering is controlled by platform layer building extension to achieve similar behaviour is not advisable as it can’t be achieved reliably
5. Building extensions to increase the number of decimal places in the unit of measures, you will not be able to show information in reports accordingly.
6. On click of a menu/button repeating multiple columns for multiple rows. For example, to get the details of the sale of stock items, repeating thousands of ledgers in rows and repeating thousands of stock items in columns will not be the right solution even though it is technically possible. It will difficult for any user to navigate through it, and all the stock items are not applicable to all the customers.

It is not possible with customisation to create new types of masters(objects), like Ledger, Stock item, and creating link masters like Batches, Bills and Tracking number and customizing the security features.

Ensuring the Tally Way in customisations

Ensure TallyWay of interface and interaction design. The experience in the customisation report should be similar to the experience of default Tally. For example:

1. The date fields in the customisation report should work as the date fields are working in default Tally. All characteristics of date fields should be ensured. Only then the customised solution can assure provide a seamless experience. Similarly, any experience with masters, transactions, reports, and configurations needs to be aligned with the experience provided in the default Tally. 
2. The solutions must be designed in such a way so that anybody can start operating it very quickly with zero to minimal training.
3. The right code needs to be ensured by creating the use cases and test cases for all the possible scenarios. Need to have a checklist and validate your customisation with the way that the default product is working. For example:
   1. Is the custom solution working in the remote?
   2. Is the custom reports are working on the browser?
   3. Is the report added in the ‘GoTo’ Button?
   4. Is the report controllable using the security feature?
   5. Is the report getting exported in all the formats?
   6. Is the report printing properly, especially on multiple pages?
   7. Are the custom fields synchronising properly during data synchronisation?

Know the features that can be customised

There are features that are not fully open for customisation.  Avoid building workaround solutions around those areas. The ability to do changes in these areas are very limited hence (1) it might take time to discover the possibility to what extent it can be extended (2) It is a waste of time as you will try something, you will reach a certain level and then you will discover it is not possible to extend further. There could be chances you will not be able to progress at all. A few of these areas are: 

• Statutory areas like GST, VAT, Payroll, Excise, TDS, TCS, Service Tax.
• Tally licensing related areas.
• Data exchange like Synchronisation between two Tally instances.
• Interactions with third party applications like banking platform, GST Network, Data import using default Tally Import.
• Interactions with Tally.Net Servers.
• Data Migration, Data Split, Backup, Restore, etc.

Enhancing the solutions compatible with new releases

Our solution must be quickly upgradable with the assurance that nothing will break, things working fine earlier will remain to work as it is. Every existing customer has the potential to rapidly become a liability instead of an asset if the simple ability to upgrade easily does not exist.  Remember that whenever a customer ‘upgrades’,  gives the responsibility of a ‘high impact experience of upgrade’ directly to our design.

Language, Tools, and Support for customising TallyPrime

• Tally Definition Language (TDL)
• TallyPrime Developer
• Executing TallyPrime in Developer mode
• TallyHelp – Developer Reference
• Guidelines for writing Good TDL code
• Guidelines on handling projects
• TallyCare
• TDL training

Integrating TallyPrime with other applications

Apart from Accounting, Inventory, Statutory and Payroll needs, TallyPrime has other functional features required for high-performance business management. However, there are segment-specific requirements that our customers are looking forward to the integrated solutions. There are ISVs who have developed the solutions for DMS, device integrations, BI tools, CRM, Education Institution management, Hospital management, Hotel management, Jewellery & pawnbroking, Retail, and so on. The technical capabilities of TallyPrime support integrations with other applications and the illustrations are available here. Furthermore, you can write to support.tallydeveloper@tallysolutions.com for any technical clarification.

Customer Engagement

Identifying the correct category of customisation is an essential activity in the entire customisation delivery framework. The identification helps in the project’s overall planning right from engagement to delivery with evident transparency in every project stage. The identification clarifies what process to follow, which document/template to use, what types of resources are required, and what we should quote. The process results in project closure in the specified time, to the customer’s satisfaction and profitability.

Customisation can be categorized in multiple ways, depending on the working days required to close the project, its complexity, and end-to-end engagement required. This document emphasis on categorisation based on the depth of customer engagement required to deliver a project. All processes, milestones, documents/templates are designed based on customer engagement requirements.

Short-term engagement

Short-term engagement can be defined as the engagement where requirements are visible to both customer and partner. The project is expected to close within a maximum of one-week of time.

The characteristics of these type of engagement are:

• The project is closed for a maximum of one week. Project closure means all the commitments are delivered to the customer’s satisfaction, and full payment is realised.
• Engagement can happen over the phone or email to understand the requirement, and delivery can happen online.
• The customer is not very process-oriented.
• TDL Level 1 resource can assist on the requirement.
• The customer very clearly articulates the requirements.

A typical example of these type of engagements are like providing output document/format customisation, report customisation using the data available in Tally, to make minor tweaking in existing reports

Medium-term engagement

Medium-term engagement projects can be defined as projects where most of the requirements are clear to both partner and customer. It takes a minimum of two weeks to a month time to come out of the project.  The characteristics of these type of engagement are:

• Requires customer visit to understand and document the requirements.
• Resources with multiple skill sets must engage with the customer apart from the developers, like sales and implementation resources.
• Most of the requirements are clear to both customer and partner.
• A couple of customer visits are needed to freeze the requirements.
• The resources play a consultant’s role in helping the customer to finalize the requirements.
• Project delivery happens mostly in one stretch.

The typical examples of these types of engagement are complexed report generation by adding additional data entry fields in transaction and masters, changes in default report formats, addition/deletion of information in existing reports, offline or one-time integration with other data sources or third-party applications. Usually, level II developer resource is required to develop these kinds of project.

Long-term engagement

Long-term engagement projects can be defined as projects where requirements are precise on a broader level; the project’s timelines can’t have arrived immediately. They can be decided after multiple rounds of discussions with customer and project delivery happen in parts.

Following are the characteristics of this type of engagement:

• Multiple customer-visit is required to understand the requirement.
• Prototyping is required to understand the requirement internally and help the customer understand how the solution will look.
• A consultant approach is required to help the customer in freezing requirements.
• Consultancy might be required to understand the hardware and other software requirements.
• Resources with various skills must work on the project like a functional consultant, account manager, and solution lead.
• Project delivery happens in multiple phases.
• Mostly solution has to be implemented at more than one location.
• Integration with third-party software.
• A separate support desk may be required to handle post-implementation support.

Proper documentation and sign-off at every stage of the project is an essential activity in these engagements. The examples of these are the

• Automation of the manufacturing process for a textile manufacturer.
• Building solution for stocks and sales visibility for a principal company.
• Automating fee collection system for an educational institution.
• Funds visibility solution for Govt. organisations.

Buy or Sell customisation on TallyShop platform

TallyShop is a central market place that hosts basic extensions and their upgrades. Extensions are new functionality built over default Tally features. There are 800+ ready-to-plug-in extensions. The entire range of add-ons across 17 categories such as Invoicing, Workflow Management, Business Verticals, Alerts & Controls, and many more. These extensions are developed by authorised Tally Partners across India. You can reach TallyShop on our webpage. You can download a trial version of the required solution, and if you find the add-on to be useful, you can proceed to pay and obtain a full version. 

Summary

The custom solutions that are built-in right way will surely delight the users as it simplifies their job. This makes them a loyal customer for the product and the customisation as well.