Showing posts with label settlement. Show all posts
Showing posts with label settlement. Show all posts

Saturday, October 10, 2015

Cross Rate - Settlement without Exchange Adjustment impact - AX 2009

Settlement of open transactions is an important task within the AX system. When there is only a single currency involved, it is a fairly simple task to settle one transaction against the other. But when there are multiple currencies involved, there is more to the settlement functionality than a straightforward "knock-off".

When a transaction is posted in the system, it is posted on the exchange rate defined on the currency master, unless over-ridden while posting. It is common that the transactions to be settled have been posted with different exchange rates, depending on the amount of exchange volatility the business allows. 

While settling, again, the exchange rate can be different. This leads to exchange rate gains/losses and adjustments to be posted in the Ledgers.

There are many cases wherein it is desired to settle open transactions at a particular rate as against the system defined rates. It may be to reduce exchange losses or to honor an agreement.

Cross Rate functionality in AX allows to do just that. One can use a cross rate to settle open transactions, and the lines are in a currency different from that of the reporting/default currency. One of the lines to be settled is marked as a primary payment and the cross rate is specified. This rate is then used to settle the selected transactions.

Note: This is applicable to both Payable and Receivables.

The process:

Go to Open transactions Editing form
Select the transactions to settle
Select the payment line and click on Mark Payment button
The cross rate field becomes editable on the marked line and the transaction gets marked as primary payment.
In the Cross Rate field, enter the exchange rate at which the transactions should be settled.
Update the transactions.

The transactions will now be settled at the rate specified on the line. There will be no exchange rate differences posted to the ledgers and the settlement is posted at the specified rate.

:)

Friday, February 13, 2015

Hand Mark - Voucher in use


Settling Open Customer and Vendor transactions is a regular process for businesses. However, in certain cases, it creates a discrepancy which throws the "Voucher in use" error.

The "voucher" that is causing the error is identified by a Hand mark against it in the Open Transactions editing form. (This is for both the Customer and Vendor).

The Cause:


There are several reasons for the Hand-mark in the Is Marked column:
-  User started to process the settlement, but deleted the adjustment voucher and did not uncheck the transaction. Hence the transaction remained
-  The marking was done for settlement, but there was an update conflict while processing the payment. In this case, the original transaction remained and the Offset transaction was lost
-  A temporary record created in the database is not released after the form is closed. The reasons for this discrepancy:

  • Power interruptions cause the transactions to be incorrectly recorded in the database
  • Connectivity issues between AX client and AOS


The Solution:


One way is to trace the User ID that was used to "mark" this transaction and with that ID, un-mark the transaction. This is cumbersome when there are many users who access this form.

Second, is to remove this hanging transaction from the system from the Database itself. To do so, follow the steps below:

  • For the affected transaction, get the RecID (take some technical help if you do not know how to do so). The RecID is an important identification to locate the transaction in the Database
  • Navigate to the SpecTrans table in the AOT. ( The SpecTrans table keeps track of the marked transactions by creating a record for the transactions)
  • Filter the RefID field with the value of the RecID of the affected transaction
  • Delete the record 
  • Save, Compile and Synchronize the table

Go back to the form to verify the marking has been removed.

Caution: Take care while noting the RecID of the affected transaction and navigating to the record in the table. In case any other transaction is removed, it will cause a discrepancy in the transactions that are being processed or already processed for settlement.

The issue may differ on a case-to-case basis. Consultant discretion is advised while exercising the solution.

P.S. If there are other work-arounds for the scenario, do leave your comments below.