India Localization use its own tax engine for all tax calculations. India Localization works with one tax engine, which need to be used for handling both input and output type of taxes. For taking advantage of the functionality’s provided in India Localization, user need to perform the tax setups only in Localized tax engine and not in standard application tax engines.
In India, we have different type of taxes and each tax has its own rules, procedures and reports. Using India Localization product, the user can define multiple taxes for different tax types like Excise, Customs, Sales tax, Octroi, Service tax etc. etc. These will be used for generation of basic statutory reports that need to be maintained under different taxes like Excise, Sales tax etc.
Through India Localization product, the user can also track other add on costs like freight, Insurance, discounts etc. Provision for generating III party invoices for expenses like freight, insurance, handling charges etc. is also built in Localization product.
Users can define the precedence required to calculate the taxes defined. This will take care of tax-on-tax type of calculations including cumulative and compounded tax calculations.
There is a provision to define taxes which are not dependent on the price of goods. User can define adhoc type of taxes, for which the actual tax amounts be captured at the transaction level.
There is a provision to set up rounding off factor to be considered for the tax calculations at the time of transactions.
Provision is made to define negative tax rates and amount so that the discount can also be handled in a similar way. However, if the discounts are applied in this manner then taxes are calculated on the base amount unless the precedence is defined properly.
For all the taxes applicable at the transaction level, which are not to be charged to the acquisition cost, is charged to the individual tax account and will not be reflected in the acquisition cost of the item. This is not applicable to all Excise and Customs type of taxes.
There is a facility to define the excise registration details for the inventory organizations (e.g. factory, warehouse etc.) defined in the system. Excise related information of the organization/Location like, jurisdictional range /Division/ Commissionarate, ECC number etc. can be stored in the system.
Information regarding the excise details of the suppliers and customers is required can be specified. Similar to the excise registration details for an organization, details are captured for the customers and suppliers. There is an additional supplier information screen, where the basic excise related information of the supplier, the user need to define the document type and category type of the customer are captured. This information will be used for generating Cenvat reports prescribed under Central Excise Rules.
These details are defined for a supplier or customer and are available for the customer / supplier at their sites unless changed specifically.
System allows different types of excise duties viz. Basic, Additional and Special duty to be specified separately. Provision to calculate the tax on tax as required for additional duty is also be available.
Users can define advelorem rate of duties or specific rates of excise duties. Through the tax precedence calculation functionality, the user can work out duty on duty if required.
Each cenvatable item need to be assigned to an Excise tariff on the basis of declaration filed under Rule 173 G by the user. The excise/customs tariff of item can be captured in the system.
There is a provision to define all the taxes applicable for a given item. These taxes can be defaulted based on the setups done and can be edited at the transactions level based on the controls set.
From the taxes applicable at the item level, users will be able to define the taxes which will be loaded to the inventory, to compute per item landed cost. In the case of partially recoverable taxes, the user can define the recoverable percentage of the specified tax while defining the tax.
India Localization supports all Cenvat transactions prescribed under Rule 57 of the Central Excise Rules. The user can avail cenvat credit on the duty paid on his inputs and capital goods. In the case of capital goods, the user can take partial credit and the balance can be availed later. There is an option for the user to avail credit on inputs either at the time of receipt through automatic mode or to claim credit later through a separate option.
There is an option for the user to specify the cenvat credit that can be availed for each tax. The user can define the percentage of credit that can be availed on a tax. User will be able to use this functionality effectively when there is a change in the percentage of credit that can be availed under excise procedures. Based on the percentage defined by the user, system will work out the tax on which Cenvat cannot be claimed will be taken into account while deriving the acquisition cost of the item in the case of average costing setup.
User will be able to capture accounts where the CENVAT on capital goods and raw material will be tracked. The user in the additional organization information screen need to specify different ledger accounts for Cenvat credit on inputs, capital goods and cenvat receivable (in case of capital goods the amount that need to be claimed later) These accounts need to be specified for each organization/Location. Accounts set at the organization level will default at the location level and will be modifiable. At any stage the register balance and these accounts can be tallied.
Users will be able to set the preferences for the register selection. The user can map all his duty payment transactions through PLA register by enabling the check box “allow negative balances in PLA” and set it off with the cenvat credit available in his input and capital goods cenvat registers. For performing this transaction, user need to use RG Consolidation screen
The user can view the balances available in different excise duty registers at any point of time. This can be used as an effective tool by the user to answer to the telephonic queries regarding the balances by the Central Excise departmental officials as well as by the finance team of the organization.
System will not allow the user to run his cenvat registers out of balance at any point of time. In the case of PLA, based on the parameter, allow negative balance in PLA, the balances can be overdrawn. At the time of performing each transaction for payment of duty, system will check the availability of funds in the respective register and put the transaction to hold, if sufficient balance is not available.
When the material is shipped out of the cenvatable unit, it will be shipped out on an excise invoice. It will have cross reference to the register selected for excise payment. Serial number for register entry will also appear.
Localization provides Cenvat on input (RG 23 A Part II), Cenvat on Capital goods (RG 23 C Part II) and PLA registers. Cenvat registers will get credited at the time of taking credit on the duty paid by the supplier. PLA will get credited with payments through TR-6 challans. Payment of duty can happen from any of the three registers based on the parameters specified in the Organization/Location.
When the quotations are to be analyzed, the quote analysis will be performed considering the taxes that are loaded on to Inventory. This will not consider the Cenvatable taxes.
While creating the purchase order, excise information defined will be defaulted. If the purchase order is being created from a quotation, then the taxes defined for the quotation will be considered. Tax defaulting will be proportional to the quantity specified at the PO level.
When the material is received against a Purchase Order, the taxes defined at the PO level will default. Defaulting will be proportional to the quantity received. Since the taxes specified on the invoice are actually applicable, user will be able to modify the taxes as per the available invoice. This will be applicable only for the first receipts against the PO. i.e. if an item is received in part shipments, the taxes could be modified only for the first receipt. All subsequent receipts will be at the taxes specified for the first receipt.
Localization provides the functionality to modify the taxes at the time of receipt. This functionality can be effectively used by the user, when there are changes in tax rates due to change in the statute/budget etc. In case of any change in taxes from the PO, the user needs to take care to update the taxes immediately while performing the receipt. Tax changes will not be allowed once the user comes out from the receipt screen for the first time.
For unordered receipts, users will not be able to attach / specify the taxes applicable. As a result the tax amount will not be calculated or defaulted (as the item price and currency is not known). Taxes defined at the time of purchasing will be applicable here. RG and accounting entries will be passed when this unordered receipt is matched to purchase order.
In the case of unordered receipts, user need to take care to ensure that the taxes attached to the purchase order match with the taxes at the time of receipt as localization do not support change of taxes at the time of receipt for unordered receipts.
The user has an option to generate consolidated cenvat report or to continue with RG 23 registers. There is a provision to update the RG23A/C Part-I registers immediately on receipt of the material. Option has been provided to the user either to avail cenvat credit immediately on receipt of the goods or to defer taking credit for a later time. In the case of capital goods, provision to avail partial credit at the time of receipt and balance later is being provided.
Provision to pay to the vendor other than the PO vendor are provided. This will be required for paying the services offered by other vendors related to that PO. An un approved invoice will be created immediately on receipt for payments to vendors other than PO Vendor. This functionality of India Localization can be effectively used for expenses like freight, insurance etc. where payment in normal case will be done directly to such agencies.
In Release 11-I, the user has an option to specify whether the invoice need to be matched to a receipt or to a Purchase Order. If the user opts for ‘match to PO’, at the time of matching, the localization taxes attached to PO will be taken into consideration and taxes will be apportioned based on the quantity matched. In this case taxes will be calculated based on the taxes defined in the purchase order.
If the user opts for receipt matching, system will work out the taxes based on the taxes available for the particular receipt and based on the matched quantity, taxes will be apportioned.
In India, as the occurrence of variance in the taxes defined in PO with actual receipt being very frequent, it is suggested to opt for receipt matching, so that the taxes in AP will be in sink with the taxes at the time of receipt.
Pay on receipt functionality in Oracle Applications will also consider taxes payable to the PO Vendor for the payment of receipts entered. Localization support Pay on receipts based on receipt number as well as packing slip number. If the user opts for packing slip number, he need to take care to enter the packing slip number at the time of creating a receipt. In Release 11 i , Pay on receipt program takes into account the RTV transactions against the receipt. Localization program will also consider the tax impact on RTV transactions and the invoice will have taxes and base amount only for the quantity received less RTV transactions.
Provision to pay the excise duty even if the item is not charged to the customer is provided.
While performing return to vendor transaction, system can take care of the reversal of Cenvat credit that need to be done before removal of goods. Based on the user defined parameters, the proportionate amount of cenvat credit availed will get reversed in excise records. The user can generate the excise document that need to be issued under Rule 52 A for such removals. Provision for defining user definable prefixes for the excise document that is generated for RTV transactions is also provided.
System will put a hold to RTV transaction for a Cenvatable item on which credit was not availed. In such cases, user need to take credit and then perform the RTV transaction. This check has been built for ensuring that payment of duty do not happen if credit is not availed.
There is a provision to update the Excise Registers on performing miscellaneous transactions. The user can effectively use this functionality whenever he need to make adjustments in the excise registers for various reasons. The user can make manual adjustments in excise registers by using this functionality. User need to take care to define the appropriate GL accounts or else will have far reaching consequences as far as accounting is concerned.
Oracle Application allows the stocks to be adjusted through various transactions. On updating of these transactions the RG registers must also be updated and appropriate CENVAT amount is to be reversed. Updation of RG registers is done automatically however, the CENVAT amount reversal will have to be done using the data entry screens provided. User need to take care to define the correct ledger accounts for such transactions.
User is provided with a facility to maintain the Bond Register. Bond register can be defined for the registered unit (organization and location). On exporting the material under bond the available bond balance will be reduced. Bond register balance will be restored when the proof of export number is entered.
User can make use of this facility either for export transactions under bond or for other transactions relating to clearance of goods without payment of duty under bond (like clearance for exhibitions etc).
If the credits are availed wrongly, then these credits availed will be revered. In certain cases if the material is brought for production purposes but later used for other purposes, the Cenvat claimed has to be reversed. This facility is provided by a general purpose data entry screen for Excise registers. The user is advised to take care while defining the ledger account for such transactions.
By using this functionality, the user will be able to view the cenvat related transactions and transactions in RG-1 register in detail.
The user has the option to use Localization taxes while creating an invoice in the Receivable module. If the user selects the excise type of taxes, the user can generate an excise invoice for the transaction and all excise related registers will get updated on completion of the transaction. While performing a transaction in AR, the user can attach the Localization taxes/precedence Logic and taxes will be worked out automatically. This functionality can be used effectively by customers performing item related transactions from AR module and for those who do not use OM module of Oracle Applications.
When the receivables invoice created has the taxes applicable, and if the credit note or debit note is created against the given invoice, then it will also consider all the taxes applicable for the invoice (proportional to the quantity or percentage as specified).
As per the statutory requirements following registers are maintained:
Statement of Finished Goods
Personal Ledger Account
Consolidated cenvat reports
*RG23A Part I
Quantitative records for the Raw Material
Value record for the Raw Material
*RG23C Part I
Quantitative records for the Capital Material
RG23C Part II
Value record for the Capital Material
Bond Register for Export Businesses
* By considering the view of existing users of Oracle Applications, in release 11-I, we continue to provide RG 23 registers. The user can take the print out of these registers for reconciliation purposes and forward the consolidated cenvat register report to the excise authorities.
Following tax related reports will be printed in addition to the printing of Excise registers mentioned above.
· Printing of Purchase Order
· Printing of Excise Invoice to Customers (For Shipments)
· Printing of Excise Invoice for Purchase Returns
· Purchases within the state report (Sales tax)
· Purchases outside the state report (Sales tax)
· Purchases from un registered dealers (Sales tax)
· Form 16 (TDS)
The above are only few reports generated from Localization. For details, please refer to the chapter relating to Reports.
User is provided with a facility to handle the customer returns. Different options to the user is being provided to the user to handle complex sales return transactions. .
User is provided with a facility use a separate price list for the excise tax calculation this will be the assessable value price list for the purpose of excise duty calculation and can be defined like any other price list. User will be able to select a price list for every customer either at customer level or customer address level called assessable price list. If defined, only excise duty will be calculated on this price else sale price (list price - discounts) will be used. All other taxes will be calculated on the sales price only. This facility will be available in Oracle Order Management and Purchasing modules.
Whenever the material received or Issued from inventory to WIP, RG registers are updated. This includes the update of RG23A Part I for the issue and receipt of raw material and RG-I for issue and receipt of finished goods (and captive consumption).
Following Applications transactions will be supported:
1. Push / Pull transaction from WIP.
2. Issue of material from Inventory to WIP.
3. Return of material from WIP to Inventory.
4. Return of scraped material from WIP.
5. Finished goods transfer from WIP to Inventory.
User can set up different series of excise invoice numbers for different types of transactions. An option to define user definable prefixes for excise invoice numbers generated for different transactions.
The user need to define the Order type/Transaction type in the Define Bond register screen and the same need to be mapped with the excise generation region of Additional organization information screen.
A report on forecast of credit available on account of Cenvat credit can be generated for effective fund planing for excise requirements. The following transactions are taken into consideration while generating the above report
· .Purchase Receipts
· Orders issued
· Rejections (Vendor)
· Return to Receiving
· RMA Orders
· Material received but no Cenvat claimed
User is provided with a facility to debit the excise liability under Rule 57 CC. This can be done by defining a tax type with ‘Modvat Recovery’. A separate account code can be defined for these taxes.
User will be able to classify the orders for applicable excise exemptions (CT2/CT3/Excise exempted). There is a provision to track AR3A forms also.
System allows the different types of customs duties viz. Basic and Additional customs duty & Surcharge to be specified separately. CENVAT
Users will be able to define the customs duty rates either as a fixed percentage of the value or as a rate depending upon the amount per specified unit or an adhoc value.
Provision will be available to define the customs duties applicable for an item. These can be defaulted based on the setups done (like any other tax) and can be edited at the transactions level based on the controls set.
From the customs duty applicable at the item level, users will be able to identify the taxes which will be loaded on to the inventory, so that the landed cost can be computed per item. User need to ensure that all cost elements attributable to the item cost is loaded the quantity received while performing a receipt in the system.
Users will be able to define the precedence required to calculate applicable tax amounts. This will take care of tax-on-tax type of calculations including cumulative and compounded tax calculations. This will be required to calculate CVD and surcharge as they are dependent upon the base customs duty.
Provision to allow users to claim CENVAT for the additional customs duty paid, if applicable. While availing the CENVAT it will be restricted to the percentage specified for availing CENVAT at the tax level. Also, the appropriate Excise registers will be updated.
For the taxes where CENVAT can not be claimed or the percentage of customs duty for which the CENVAT is not available, acquisition cost of the item will be increased to that effect.
The process of claiming CENVAT is similar to that of the excise duty CENVAT. The accounts set for the excise duty CENVAT will be used in this case.
Since, the customs duty is to be paid in the functional currency (INR), user will be allowed to change the applicable currency at the transaction level. However, the provision to change currency will depend upon the parameters set while defining the tax in the ‘Tax Definition India Localization’ option.
Since, the customs duty is always paid in advance. i.e. the amount is paid before the material is received in stores, There is a facility where the duty could be paid before receiving the material. For this purpose, an on account (prepayment) payment can be made in the name of Customs Authorities. Bill of Entry (BOE) as given by Customs Authorities is then entered in the system. BOE is settled against the prepayment.
Provision to apply the BOE to the receipt is required. Only the fully paid Bill of Entries will be considered for application at the time of receipt. This will identify the BOE used for any particular receipt. The Bill of Entry can only be applied against the customs duty type of taxes i.e. Basic and Additional Customs Duty.
During receipts, the BOE amount applied to the line will be considered as the applicable customs duty amount, instead of the amount specified at the receipt level.
There is a report provided giving the details of Bill of Entries which are unapplied , to establish control over them and to tally the same manually with GL balances.
There is an account code captured to account for write off balance in Bill of Entry at Organization / location level.
There is a provision to force close Bill of Entries which are open and to write off the prevailing balances. The balance amount is accounted under write off bill of entry account, defined at Organization / location level.
AP accrual reconciliation and write off function of Oracle Applications will consider localization taxes also.
User is provided with a facility to enter sales tax registration details for the inventory organizations defined in the system. Both local sales tax registration details and central sales tax registration details will be captured for an organization or an organization and location. This can done in the same setups where the excise registration details are entered.
Information regarding the sales tax registration numbers of the suppliers and customers is captured. Similar to the organizational sales tax details, details will be captured for the customers and suppliers. These details can be entered for a supplier or customer at the address level, where they can be changed if different. Suppliers / Customers whose sales tax registration details are not available will be treated as non registered parties and can be used to remit taxes on purchases from an unregistered dealer.
System allows two types of sales tax definitions viz. Local sales tax sales taxes like works contract tax are not supported. The user can define multiple sales taxes including works contract tax. The tax calculations will work in sink with the tax precedence logic defined by the user for each transaction.
In the case of works contract tax, the user need to define the tax authority as a vendor with vendor type TDS and at the time of approving the invoice, the prescribed WCT will be deducted through a negative credit memo and an invoice will get generated to the Tax authority.
Like other taxes, users will be able to define the sales tax rates either as fixed percentage of the value or as a rate depending upon the quantity per specified unit or an adhoc value.
Like all other taxes, provision will be available to define the applicable taxes for a given item at the transaction level. These taxes can be defaulted based on the setups done and can be edited at the transactions level based on the controls set.
The following reports are provided to facilitate the Sales tax set off feature.
· Purchases and sales tax on purchases within the state
· Purchases and sales tax on purchases outside the state
· Purchases from unregistered dealers
From the taxes applicable at the item level, users will be able to define if the tax will be loaded to inventory, so that per item landed cost can be computed.
Even though the sales tax is usually loaded to the item, provision to allow users to load it to the sales tax account are provided. This is useful when the landed cost of the item is defined irrespective of the sales tax.
In the event of purchase returns, all the taxes applicable to the item will be reversed and for average costing organization the new average cost of the item will re-calculated.
Since, the applicable sales tax forms will be specified at the tax level, depending upon taxes applied, applicable sales tax forms to be received will be captured.
In addition to other reports, the user is provided with the following reports
· Purchase Return beyond the specified period, where the period has been provided as a report parameter.
· Status of Sales tax form issued / not issued against purchases.
After capturing the applicable tax forms to be received, the actual receipt of these forms will be tracked per Purchase Order. Information regarding the tax forms received, it’s number and amount can be maintained in the system.
Facility to default the taxes at the transaction based upon the customer and it’s address for the item selected are provided. For this purpose the users will have to specify the tax categories applicable to the item and maintain an item-tax category link called item category list. This can be specified at the customer and customer address level so that the applicable taxes can be defaulted through defaulting of tax category.
In the event of sales returns, corresponding sales taxes need to be reversed. User is provided with a report of credit notes against sales returns, for claiming the sales tax return.
After capturing the applicable sales tax forms to be received, the actual receipt of these forms will be tracked per Order or Invoice basis. Information regarding the sales tax forms received, it’s number and amount will be maintained.
User is provided with a facility to capture the Registration details for TDS for the Organization in the systems. The details include the TAN Number, PAN Number and also the Ward reference for each organization defined.
User will also be able to capture the tax registration details for the Vendor and customers defined in the systems. The details include the TAN Number, PAN Number and also the Ward reference where ever applicable in case of all suppliers and customer defined in the system.
The user is provided with an option to define the tax year. This period is independent and all TDS limits and reports like annual report will be based on the period. This year can be different from the Accounting calendar year as specified in the application. With this the user will have the flexibility of having a different year for the purpose of Accounting and another year for the purposes of Tax Deduction at Source.
Addresses tax deduction at Source for following types of payments
· Payment to Contractors / Subcontractors
· Professional / Technical Fees
· Other transactions where TDS need to be deducted
· Deductions as per works contract Act
· User definable transaction where amounts need to be withheld under any other provisions of Law/procedures (for eg. Deductions towards ESI)
User can define various sections which can be associated to TDS taxes. These sections will be useful for TDS certificates generation and printing.
User is provided a facility to define the various TDS sections and the corresponding limits applicable for each section as defined in the Act. The limits for each supplier will be tracked based the limits specified for each section. The user can set limits based on each Contract and as well period based limits. The limits will be tracked by the system for each supplier against each section as defined in the act at the Supplier level irrespective of the number of sites each supplier has got. However, the limits internally will be controlled at the Operating unit level as defined by the user.
The user will be able to define various taxes with the rate of tax on the Invoice line to be applied under the category Tax deduction at Source. The user will be able attach a tax so defined to each Supplier. This will be defaulting tax for the purpose of TDS for such supplier at the transaction level. This default can be set at the Invoice level as well as at the Invoice line level.
The systems is set to deduct the Tax at Source at the base Invoice line amount. In case there is a tax applied on the Invoice line, then the user will modify the tax rate accordingly and apply the revised rate on the Invoice line amount.
The system based on the TDS Tax applied to an invoice line will recover the TDS and create a credit memo against the same invoice line. The system will also create an invoice for the same amount for the Tax authorities supplier account. The Credit memo and also the Invoice will be created with an approved status automatically by the system. The due date can be accordingly set for the Tax supplier and on due date the system will automatically create payment.
The user is provided with a facility to track the TDS recoveries by their customers based on payment received and also based on invoices. The user will be able to take a report on the TDS recovered by their customer with a break up on payments received and also based on the invoice raised by the user.
There is a provision to maintain Certificates for Concessional rates of TDS along with their validity period, for individual vendors and also for specific invoices.
There is a provision to deduct tax at source on prepayments and also to pass appropriate accounting entries to GL.
At the time of making standard Invoice payments, there is a provision to apply Prepayments. At the same time TDS amount also gets adjusted against the TDS, already paid on prepayment.
The reports like
· Invoice Register
· Vendor paid Invoice History
· Posted Invoice Register
will now show both Invoice amount and net of TDS as applicable.
User can cancel the previous TDS invoice automatically, if the original invoice on which this TDS is deducted, is canceled and the old TDS invoice is not paid to I T Authorities, till date.
User can consolidate all the payments made to a vendor and TDS deducted, during a given period.
Tax Deduction Certificates would be issued with an unique identification number generated and maintained. This will eliminate overlapping of TDS Certificates.
TDS certificates will be printed with an identification ‘Original’ for the first time printing of TDS certificate. For any additional copy that is printed, it will be printed as ‘Duplicate’.
User can generate the following reports for annual returns on TDS
· Details of Tax credited or paid during the period and of TDS at prescribed rate - in the case of companies
· Details of Tax credited or paid during the period and of TDS at lower rate or no tax deducted in accordance with the provision of section 197- in the case of companies
· Details of Tax credited or paid during the period and of TDS at prescribed rate - in the case of persons other than companies
· Details of Tax credited or paid during the period and of TDS at lower rate or no tax deducted in accordance with the provision of section 197- in the case of persons other than companies
There is facility to raise credit memo on the customers outstanding amount which will be linked to the receipts and / or to the invoices raised by the user against the TDS certificate received from the customers.
Following are the important transactions supported against this functionality.
· TDS on pre-payments
· TDS on invoices
· Works contract tax on pre-payments
· Works contract tax on invoices
· Applying/Un applying prepayments to invoices
· Cancellation of invoices(TDS entries will be reversed only if the payment to the TDS authority is not made)
· Other type of witholding tax (for eg. ESI)
The user will have a facility to define different service tax names with different rates under the service tax type category.
The user will be able to define multiple service tax rates in the system and attach the same to the transactions depending on the requirement. The system will calculate the service tax on the invoice line in which the tax is attached. However if the user wants to compute service tax on a portion or part of the invoice line then the user is define the rates accordingly and attach the same to the invoice line.
The system will provide a service tax report based on the parameters set for the report with the details of all collections for the invoices where service tax is charged. The user has to create an invoice in AP for the payment of the same to the tax authorities.
Is a provision for the User to classify an organization locations to be trading, in addition to the capturing of their excise registration particulars. This will be applicable for all sub inventories coming under trading organizations and user can also identify individual sub inventories as trading.
User will have a provision to capture Excise department approved numbers for Excise invoices being generated for shipments from these Trading Organizations.
User will have a provision to associate original excise invoice reference on the basis of LIFO or FIFO. There is a provision to specify the invoice number at the transaction, so as to allow override with each shipment ( at the time of completing sale invoice, in the case of only AR installation) happening from trading organization location.
User will be able to maintain Register RG23D for each organization location which is identified as trading. The following transactions are considered for the above register.
Provision to print Register RG 23 D will be available.
User will have a provision to add records manually to register RG23D. User will not be able to update or delete the existing records.
User will be able to define the tax rate changes with a reference to its old tax name to be considered for supplementary transactions of the sales cycle.
User will be able to define the price changes with a reference to its old price list (similar one for changes in Assessable value) to be considered for supplementary transactions of the sales cycle.
Is a provision to consider all the invoices and credit memos created during a given period and work out retrospective difference in amounts, as applicable.
Is a provision to print retrospective difference in amounts on all invoices and credit memos during a given period due to price / tax changes in Sales Cycle.
User will be able to choose the action to be taken on the supplementary transactions. Is an option to generate a supplementary invoice or credit memo or not to consider the transaction for retrospective price changes at the choice of the user.
The following interfaces are provided through localization.
· PO Requisitions
· Purchase Orders with Taxes
· Receipts interface including Taxes
· Material transactions
· Tax categories
· Sales Order Interface
· AR Interface
· Interface of externally calculated taxes (except Excise) on OE transactions
· RG 23 A Register (Part I & Part II)
· RG 23 C Register (Part I & Part II)
· PLA Register
User will be able to define block of assets by having the asset categories defined with highest level of details as required for Income Tax.
User is provided with a facility to enter Opening balances for block of assets (one time facility).
User is provided with a report which will facilitate arriving at asset category wise Gross Block of Assets and written Down Value as required for Income Tax purpose.
User is provided with a facility generate monthly closing balances of Block of assets.
User is provided with option to capture duty drawback claimable with each tax name of type ‘Customs’ or ‘CVD’.
User is provided with an option to chose the mode of operandi to calculate duty draw back. It can be either automatic or manual. If automatic the system will further provide an option for LIFO or FIFO on receipts. If manual, the user will be able to choose the receipts at his choice.
User is provided with facilities for
· Generation of Duty drawback claims
· Report to help tracking duty draw back.
There is a provision to print purchase register along with tax components.
User will be able to inquire on accounting entries being generated through localization by source wise.
User is provided with the following additional reports
· Debtors Ledger
· Creditors Ledger
· Cash Book
· Bank Book
· Purchase Register
· Debtors Trail Balance
· Creditors Trail Balance
· Depreciation Detail Report
· Income Tax act Fixed Asset Schedules
· AR3A Forms Status Report
· Excise Duty Claim report against RMA Receipts
· Consolidated Supplementary Invoices Report
· Journal Voucher Report
· Commercial Invoice U/S 57G or 57T
User is provided with the following reports enhanced for taxes to do audit trail
· Receiving Account Distribution Report
· AP accrual rebuild reconciliation report
· AP accrual reconciliation report
In the base product, an option is being provided to match the receipts with a invoice generated in Oracle Payables module. While making invoice matching to receipts, proportionate localization taxes will get accounted in the distribution lines of the appropriate invoice.
Oracle Purchasing will automatically capture and store the exchange rate at the time of receipt. When you use Oracle Payables to match invoices to purchase order receipts, the exchange rate at the time of receipt will be used to calculate the exchange rate variance. Localization taxes will also consider the exchange rate at the time of receipt.
While making a receipt, accounting entries related to localization taxes for this transaction can be viewed by navigating through the view accounting functionality.
The updation of excise registers on performing a receipt can be viewed from this menu.
While performing a pay on receipt system will consider the return to vendor transactions performed and the proportionate localization taxes will be adjusted in the Oracle Payables invoice.