Inscribed V2 is a new TCP format introduced in TallyPrime Developer Release 7.2. It uses stronger encryption to provide enhanced protection for your TDL customisations and intellectual property. The original TDL source code cannot be recovered from an Inscribed V2 TCP, including by Tally.

With the introduction of Inscribed V2, the existing Inscribed format is referred to as Inscribed V1 to clearly distinguish between the two versions. There is no change in the functionality of the existing format.

Inscribed V2 is the latest version of the Inscribed TCP format, introduced in TallyPrime Developer Release 7.2. It uses stronger encryption to provide enhanced protection for TDL customisations and intellectual property, with decompilation not supported.

• Regular TCP can be decompiled and is compatible with Tally.ERP 9 Series A Release 1.0 and later.

• Inscribed V1 does not support decompilation and is compatible with Tally.ERP 9 Series A Release 5.4 and later.

• Inscribed V2 does not support decompilation and is compatible with TallyPrime Release 7.2 and later.

Partners can choose the TCP format based on their solution’s compatibility requirements. However, we recommend using an Inscribed format to safeguard your TDL code.

No. Inscribed V2 is required for new add-ons listed on the upcoming Marketplace.

For customers using earlier TallyPrime releases, Inscribed V1 can be used to maintain backward compatibility.

We recommend encouraging customers to upgrade to TallyPrime Release 7.2 or later wherever possible so that Inscribed V2 can be used.

Yes. Existing solutions can be compiled using Inscribed V2 with the original TDL source code, using TallyPrime Developer Release 7.2 or later.

We recommend moving customers to TallyPrime Release 7.2 or later and using Inscribed V2 wherever possible. If a customer needs to continue using an earlier release, an appropriate existing TCP format, such as Inscribed V1, can be used to maintain backward compatibility.

The upcoming Marketplace will support only Inscribed V2 TCPs for new add-ons.

Therefore, if you are developing a new solution with the intention of listing it on the Marketplace, the solution must be compiled using Inscribed V2.

New add-ons on the upcoming Marketplace must use Inscribed V2. Regular and Inscribed V1 TCPs will not be accepted for new add-ons.

No. Existing TallyShop solutions will be migrated to the Marketplace in their current compilation formats.

Further guidance on updates to these solutions after migration will be shared closer to the Marketplace launch.

Yes. You can recompile an existing solution using Inscribed V2 with the original TDL source code and TallyPrime Developer Release 7.2 or later.

If your customers are using TallyPrime Release 7.2 or later, you can use Inscribed V2. If they need to continue using an earlier release, use an appropriate existing TCP format, such as Inscribed V1, to maintain backward compatibility.

No exceptions are currently planned. The upcoming Marketplace will support only Inscribed V2 TCPs for new add-ons.

The requirement will come into effect when the upcoming Marketplace launches.

From the launch, all new add-ons intended for the Marketplace must be compiled using Inscribed V2.

Existing TallyShop solutions will continue to be migrated in their current compilation formats. The exact Marketplace launch date will be communicated separately.

Existing TallyShop solutions will be migrated to the Marketplace in their current compilation formats, ensuring continuity for these solutions.

The introduction of Inscribed V2 does not, by itself, require existing TallyShop solutions to be recompiled in V2 for migration.

No. Existing TallyShop solutions do not need to be recompiled in Inscribed V2 for migration to the Marketplace. They will be migrated in their current compilation formats.

If you choose to recompile an existing solution in Inscribed V2 later, you can do so using the original TDL source code and TallyPrime Developer Release 7.2 or later.

Solution continuity will be maintained with the Marketplace. Existing TallyShop solutions will be migrated in their current compilation formats.

Further details on the availability of existing solutions after migration will be communicated closer to the Marketplace launch.

No. Existing customers will not receive any change to their TCP.

Existing TallyShop solutions will be migrated in their current compilation formats to ensure continuity for existing customers and solutions.

Yes. Existing licenses and activations will continue to work as they do today.

The introduction of Inscribed V2 does not introduce any new licensing or activation requirements.

No. Inscribed V2 TCPs can be loaded only in TallyPrime Release 7.2 and later. They cannot be loaded in earlier releases.

Yes. Regular and Inscribed V1 TCPs will continue to be supported in TallyPrime Release 7.2 and later.

Continue using the appropriate existing TCP format to maintain backward compatibility.

Inscribed V2 cannot be used for customers who are on TallyPrime releases earlier than 7.2.

It depends on the TallyPrime releases you need to support.

Inscribed V2 works only with TallyPrime Release 7.2 and later. If some customers are on earlier releases, you will need to use an appropriate existing TCP format, such as Inscribed V1, for those customers.

Yes. If you need to support customers on different TallyPrime release ranges, you can use the appropriate TCP format for each.

Use Inscribed V2 for customers on TallyPrime Release 7.2 or later, and an appropriate existing TCP format, such as Inscribed V1, for customers on earlier releases.

Yes. An Inscribed V2 TCP cannot be loaded in releases earlier than 7.2.

Therefore, customers who need to use an Inscribed V2 TCP must be on TallyPrime Release 7.2 or later.

Regular and Inscribed V1 TCPs will continue to work with TallyPrime Release 7.2 and later, alongside Inscribed V2.

The introduction of Inscribed V2 does not discontinue the existing formats.

The error message is shown in the following scenarios

1. An attribute started without a valid definition line

2. The loaded file is corrupted

3. TCP file is incompatible with this version of TallyPrime

To know more about the same, refer to the link.

Inscribed V2 is available as a TCP compilation format in TallyPrime Developer Release 7.2.

The TallyPrime Developer interface has also been simplified to make it easier to select the required TCP compilation format.

Detailed step-by-step compilation instructions are provided in the TallyPrime Developer Release Notes/Developer Reference.

In TallyPrime Developer Release 7.2, you can select the required TCP compilation format from:

Project Properties -> Build Options → TCP Format

No. No TDL changes are required specifically for compiling in Inscribed V2.

Yes. The same TDL source code can be compiled into Regular, Inscribed V1, or Inscribed V2 without any other considerations.

Inscribed V2 is introduced with TallyPrime Developer Release 7.2.

Developers who intend to compile Inscribed V2 must therefore use a supported TallyPrime Developer release that provides the V2 compilation option.

No. There are no changes to compilation time, TCP size, prerequisites, or performance.

You can load the Default TDL SDK of the required release in TallyPrime Developer Release 7.2 and build the TCP in Inscribed V1 format by selecting the appropriate TCP format in Project Properties.

No. The original TDL source code cannot be recovered from an Inscribed V2 TCP.

Developers should retain the original source code securely for future development and reference.

No. The source code cannot be recovered from an Inscribed V2 TCP, including by Tally.

This makes retaining the original TDL source code particularly important for partners and developers.

The source code cannot be recovered from the compiled Inscribed V2 TCP.

Therefore, you should retain the original TDL source code securely and maintain appropriate backups as part of your development and release process.

No. An Inscribed V2 TCP cannot be directly converted to another TCP format.

Since the source code cannot be recovered from V2, partners should retain the original TDL source code if they need to create another TCP format.

Retain the original TDL source code for every solution you develop.

This should be standard practice for all solutions, irrespective of the TCP format used. Partners and developers should follow their usual secure backup and version-control practices and should not rely on decompilation to recover source code when it is needed.