Purpose of the document
Many personnel need to document the ledger balance logic and inventory balance logic from the transaction details of the software. Turbodata offers written specifications for critical features like sales, purchase, profit and loss, cash flow and inventory valuation.
By this document the Chartered accountant or the auditor has complete visibility into the accounting numbers. The accountant also has the option of choosing the variations that it desires from the software.
Whom is this document intended for?
a.) Chartered accountants
b.) Accountants
c.) Personnel having to file taxes for international firms
d.) External auditors
e.) Software companies desiring to integrate their modules with Tally
Turbodata definition for sales,purchase, profit and loss statement, inventory valuation and gross profit
Sales Movement: sales movement is classified within Tally by using the sales register. The sales register gives the ledger and the inventory movements. The following is the logic from the single table for sales movement for ledger, inventory, batch and bill movements.
The numbers from our logic are to be signed off by the client and could be different from the odbc extract of Tally.
a.) The voucher movement types are classified as follows:
· Isinvoice=’yes’
· Ivoid=’No’
· Iscancelled=’No’
· Isoptional=’no’
· Isdeleted=’No’
b.) The ledger primary account for the invoice should belong to ‘sales accounts’ or the reserve name for the invoice associated with the ledger from the group hierarchy should belong to the ‘sales accounts’.
c.) The group associated with one of the ledgers in the invoice should be classified as following:
· Isrevenue=’Yes’
The calculation for the points b and c have been done based on companynames and masterid for the invoices.
In case all the 3 conditions above have been fulfilled then the invoices associated with the given masterid and the companynames are said to be assumed to belong to sales for the calculation of Profit and loss statements.
Derivation of the ‘sales accounts’: the same can be deduced from the ledgerprimary of the ledger or from ‘Level1’ after the ledger flattening exercise in the single table.
The single table shall give the complete ledger(along with group hierarchy), partyledgername(along with group hierarchy) and the item(along with stock group hierarchy) in the output.
The above shall be incorporated as part of “container 1”.
Sales Movements incorporating the non invoiced entries: There would be certain cases where the client would like to incorporate entries for sales entries that include entries that have not been invoiced. In such a scenario the following is the logic from the Tally source code:
· Isvoid=’No’
· Iscancelled=’No’
· Isoptional=’no’
· Isdeleted=’No’ or blank
Vouchertypeparent involving ‘order’ entries are excluded for the same.
b.)The ledger primary account for the invoice should belong to ‘sales accounts’ or the reserve name for the invoice associated with the ledger from the group hierarchy should belong to the ‘sales accounts’.
This shall be classified as “container 2”
The following steps have been used by our team to calculate the non invoiced sales entries:
Container 3= Container 2-container 1
Container 3 shall have only ledger movements and movements involving(ledger and inventory)[“Order” entries have been excluded before]
We assumed that the non invoiced inventory entries shall have only the voucher type parent ‘delivery note’ and ‘receipt note’[based on our understanding of the source TDL code].
Container4(subset of container 3 with voucher type parent ‘delivery note’ and ‘receipt note’)
Container 5(subset of container 3 excluding voucher type parent of ‘delivery note’ and receipt’ note’)
Handling of container 4: For calculating the pending delivery notes and receipt notes we have used the tracking number link with the sales invoice.
Container 6: container 4(delivery notes and receipt notes with tracking numbers having pending quantities with the sales invoice).
Thus the total sales value(invoiced and not invoiced is as follows)
Container 1+container 6+container 5. These details shall be used for the following:
Calculation of sales order pending and for inventory valuations.
[Note: we get frequent errors in calculation of ‘container 6’ in our projects]
Purchase Movement: sales movement is classified within Tally by using the sales register. The purchase register gives the ledger and the inventory movements. The following is the logic from the single table for sales movement for ledger, inventory, batch and bill movements.
The numbers from our logic are to be signed off by the client and could be different from the odbc extract of Tally.
a.) The voucher movement types are classified as follows:
· Isinvoice=’yes’
· Ivoid=’No’
· Iscancelled=’No’
· Isoptional=’no’
· Isdeleted=’No’
b.) The ledger primary account for the invoice should belong to ‘purchase accounts’ or the reserve name for the invoice associated with the ledger from the group hierarchy should belong to the ‘purchase accounts’.
c.) The group associated with one of the ledgers in the invoice should be classified as following:
· Isrevenue=’Yes’
The calculation for the points b and c have been done based on companynames and masterid for the invoices.
In case all the 3 conditions above have been fulfilled then the invoices associated with the given masterid and the companynames are said to be assumed to belong to sales for the calculation of Profit and loss statements.
Derivation of the ‘purchase accounts’: the same can be deduced from the ledgerprimary of the ledger or from ‘Level1’ after the ledger flattening exercise in the single table.
The single table shall give the complete ledger(along with group hierarchy), partyledgername(along with group hierarchy) and the item(along with stock group hierarchy) in the output.
The above shall be incorporated as part of “container 1”.
Purchase Movements incorporating the non invoiced entries: There would be certain cases where the client would like to incorporate entries for sales entries that include entries that have not been invoiced. In such a scenario the following is the logic from the Tally source code:
· Ivoid=’No’
· Iscancelled=’No’
· Isoptional=’no’
· Isdeleted=’No’ or blank
Vouchertypeparent involving ‘order’ entries are excluded for the same.
b.)The ledger primary account for the invoice should belong to ‘purchase accounts’ or the reserve name for the invoice associated with the ledger from the group hierarchy should belong to the ‘purchase accounts’.
This shall be classified as “container 2”
The following steps have been used by our team to calculate the non invoiced sales entries:
Container 3= Container 2-container 1
Container 3 shall have only ledger movements and movements involving(ledger and inventory)[“Order” entries have been excluded before]
We assumed that the non invoiced inventory entries shall have only the voucher type parent ‘delivery note’ and ‘receipt note’[based on our understanding of the source TDL code].
Container4(subset of container 3 with voucher type parent ‘delivery note’ and ‘receipt note’)
Container 5(subset of container 3 excluding voucher type parent of ‘delivery note’ and receipt’ note’)
Handling of container 4: For calculating the pending delivery notes and receipt notes we have used the tracking number link with the sales invoice.
Container 6: container 4(delivery notes and receipt notes with tracking numbers having pending quantities with the sales invoice).
Thus the total sales value(invoiced and not invoiced is as follows)
Container 1+container 6+container 5. These details shall be used for the following:
Calculation of purchase order pending and for inventory valuations.
[Note: we get frequent errors in calculation of ‘container 6’ in our projects]
Cash flow Movement: sales movement is classified within Tally by using the cash flow report. The cash flow report gives the cash balance at the end of the DSPTodate in Tally.
The numbers from our logic are to be signed off by the client and could be different from the odbc extract of Tally.
a.) The voucher movement types are classified as follows:
· Isinvoice=’yes’
· Ivoid=’No’
· Iscancelled=’No’
· Isoptional=’no’
· Isdeleted=’No’
b.) From the single table we have used the Ledger_level_3 after ledger level flattening. The following filter parameters are used.
· Level_2 contains “current assets” or the Reserve name has “Current Assets”
· Level_3 has entries related with “Bank” and “Cash”.
The single table will give up to 9 levels of hierarchy at ledger and partyledger levels.
All the entries related with criteria a and b are part of the cash flow statement.
Complications: we have had complications with regards to branch transfer of cash. Such branch transfers need to be excluded. Those customizations need to be done.
Post dated checks are not handled by our logic.
Profit and loss Movement: The attached specification for profit and loss incorporates the voucher ledger movements. These specifications have been developed over a number of implementations.
These specifications have been used to develop dynamic profit and loss statements across number of companies. The logics of subledgers has not been included in our specifications currently.
Note: we have excluded all the non invoiced entries in the given statements.
d.) The voucher movement types are classified as follows:
· Isinvoice=’yes’
· Isvoid=’No’
· Iscancelled=’No’
· Isoptional=’no’
· Isdeleted=’No’ or blank
The group details associated any of the ledgers in the invoices should confirm to the following:
· Isrevenue=’Yes’
The debit and credit entries for the ledgers chosen for the masterids associated with such invoices are to be calculated within the profit and loss statements for the end clients for the given fiscal time period.
The group hierarchy flattening gives the schedule 6 and schedule 3 profit and loss statements
Similarly for the analysis of gross profits by ledger we use the following formulae:
All the masterids along with the ledgers having affectsgrossprofit=’yes’ . Thereafter the debit and credit ledger entries for the masterids associated with the partyledgernames and ledgernames are used to calculate the gross profits over periods in time.
Gross profit calculations at the item level entails the above logic. The masterids selected above are then used to filter entries at the voucher inventory and voucher batch inventory levels.
Calculation of the perpetual gross profit for income filing purposes: The Tally software uses report level calculations for the calculation of the gross profit. That is the weighted average shall be calculated for each fiscal date.
Turbodata calculations entail the complete historical calculations for the inward movements(stockitem movement and stock item value) up to the given fiscal date.
Inward movement quantity: Inward movement quantity shall include all inward movements are inventory and batch levels conforming to the following:
· Isvoid=’No’
· Iscancelled=’No’
· Isoptional=’no’
· Isdeleted=’No’ or blank
Based on the client requirements for the masterids to be picked up at the voucher ledger levels one or more of the filters are chosen for one of the ledgers of the vouchers. The conditions are as follows:
a.) Isrevenue:yes
b.) Affectsgrossprofit:Yes
c.) Ledger primary associated with the voucher should belong to the purchase accounts or the sales accounts.
Weighted average rate is given by the division off the following two parameters marked as numerator_a and denominator_b
Numerator_a=This is the total value of the inward value chosen above for the fiscal dates less than or equal to the date for analysis
Denominator_b=this is the total quantity for the inward quantity movement for the fiscal dates less than or equal to the date of analysis
Weighted average rate for the given fiscal date by batch and non batch movement is Numerator_a/Denominator_b
The attached weighted average calculations are used for gross profit, closing balance value calculations.
Contact: Apoorv Chaturvedi
Phone:+91-8802466356
email: support@turbodatatool.com;support@mndatasolutions.com
