newsletter release notes trp2014 jan
TRANSCRIPT
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
1/25
Release NotesTreasury Release Package January
V 1.0 (2014-03-22)
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
2/25
Release Notes TRP2014-Jan
2 | P a g e
Financial Applications
Table of Contents
Part 1
Newsletter____________________________________________________________ 4
Part 2 Release Note __________________________________________________________ 5
General Description ________________________________________________________________ 5
General _________________________________________________________________________________ 5
New Features ___________________________________________________________________________ 5
Modifications/Enhancements of Existing Features _____________________________________________ 6
Bug Fixing ______________________________________________________________________________ 7
Short Term______________________________________________________________________________ 8
New Features ___________________________________________________________________________ 8
Modifications/Enhancements of Existing Features ____________________________________________ 10Bug Fixing _____________________________________________________________________________ 10
Frequently Asked Questions ______________________________________________________________ 11
Bonds__________________________________________________________________________________ 12
New Features__________________________________________________________________________ 12
Modifications/Enhancements of Existing Features ___________________________________________ 12
Bug Fixing ____________________________________________________________________________ 13
Known Issues __________________________________________________________________________ 14
Loans __________________________________________________________________________________ 14
New Features__________________________________________________________________________ 14
Modifications/Enhancements of Existing Features ___________________________________________ 15
Bug Fixing ____________________________________________________________________________ 15Swaps__________________________________________________________________________________ 15
New Features__________________________________________________________________________ 15
Modifications/Enhancements of Existing Features ___________________________________________ 16
Bug Fixing ____________________________________________________________________________ 16
Exposure_______________________________________________________________________________ 17
New Features__________________________________________________________________________ 17
Modifications/Enhancements of Existing Features ___________________________________________ 17
Bug Fixing ____________________________________________________________________________ 17
OCP____________________________________________________________________________________ 18
New Features__________________________________________________________________________ 18
Rates and Prices ________________________________________________________________________ 18Modifications/Enhancements of Existing Features ___________________________________________ 18
Payments ______________________________________________________________________________ 19
New Features__________________________________________________________________________ 19
Bug Fixing ____________________________________________________________________________ 19
Accounting _____________________________________________________________________________ 19
Bug Fixing ____________________________________________________________________________ 20
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
3/25
Release Notes TRP2014-Jan
3 | P a g e
Financial Applications
Reporting ______________________________________________________________________________ 20
New Features__________________________________________________________________________ 20
Modifications/Enhancements of Existing Features ___________________________________________ 20
Bug Fixing ____________________________________________________________________________ 21
SWIFT _________________________________________________________________________________ 21
Modifications/Enhancements of Existing Features ___________________________________________ 21
Bug Fixing ____________________________________________________________________________ 21
Hints_________________________________________________________________________________ 22
It is necessary not only to enable the SWIFT functionality (standard parametrisation script), but also to
define the code for the Logical SWIFT Terminal (country-specific parametrisation sript), before being able to
generate Swift Messages. ________________________________________________________________ 22
Part 3 Country-Specific Tools _________________________________________________ 23
New Features __________________________________________________________________________ 23
Modifications/Enhancements of Existing Features ____________________________________________ 23
Change Control ______________________________________________________________ 25
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
4/25
Release Notes TRP2014-Jan
4 | P a g e
Financial Applications
Part 1 Newsletter
This is the first Treasury Release Package in 2014, and we are trying to improve the way we document
the announcement. In previous years, the Release Notes were containing details necessary for theBusiness Departments as well as for the IT Department, and the official announcement was made via a
short eMail containing a short description of mayor topics.
Now, the shipping to the Banks will be made through the Regional Offices, via Help Desk for
Maintenance/Support Projects, and via the Project Platform Gemini for the Implementation Projects.
And, the documentation has been separated in two main documents, this Newsletter_ReleaseNtes-
TRP214-Jan.docx, for the Business Departments, and a separated UpgradeGuide_TRPOct2013
_TRPJan2014.docx for the technical details related to the specific Upgrade Process, but also to Tool
availability and versions and integration/compatibility questions.
The following major topics are included in the Treasury Release Package January 2014, developed till
end-of-January, and tested and bug-fixed in February and the first weeks of March:
With the purpose of increasing work efficiency, all Tickets sent to Back Office for confirmationare now collected in a single List of Pending Confirmations and can be Reviewed, and
Confirmed/Rejected from inside this list. Previously this feature was available for Loans and
Bonds, but not for Short Term Tickets.
For Asset-side Bonds, the handling of Custody Accounts has been included and the registration ofthe Payment Agent has been removed. All Forms used for Bonds and Loans have been reviewed
and improved, based on Users feedback.Guarantors can now also be registered for Bonds.
FX Swaps are now handled with a special Ticket Format, including all details for the Near Leg andthe Far Leg. Via a special new mode in List Tickets, the daily monitoring and reporting needs
for Swaps can be covered, and further details accessed in an user-friendly way.
The report used for monitoring of the Open Currency Position now includes also the daily impactof interest accrual for Interbank Loans.
The new version of the Accounting Balances report include not only accrued interests for allproducts, but also accrued taxes, and a new currency filter combined with the possibility to see
the total net balance by currency for all balances related to Treasury Deals and Accounts.
The number of decimals to be used for interest rates, exchange rates, prices and paymentamounts is now fully parametrisable, in order to adapt better to local needs and changes.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
5/25
Release Notes TRP2014-Jan
5 | P a g e
Financial Applications
Part 2 Release Note
General Description
This part lists the General changes, the ones which are available and can be applied to all countries. Theyare grouped per Product or per Area, as listed below.
General
New Features
1. The number of decimals used for the display/capture of rates, prices, and amounts was reviewedonce more, now implemented as fully parametrisable. For payment amounts, now also the
amounts in TWA are handled based on the number of decimals defined for the currency of the
payment. Our current database standard is 2 for payment amounts, 5 for interest rate codes, 7
for exchange and cash rates and 8 for Prices. There is an upper limitation set to 9 decimals. If the
number of decimals is changed, old Deals still will show the rate precision using the old standard,
(the create time of the message is relevant). If a new Deal is created, the Remarks always reflect
current database settings. An information about the current parameter settings related to the
precision is returned by the Mercury Service getInfo(), the key being DealwarePrecision.
2. Up to now, Ticket data was containing the Registration Date. With TRP January 2013, theattribute storing the Registration Date has been changed and in now keeping the Registration
Time. The Registration Time is shown in List Tickets, Pending Confirmationand in the Ticket
Printouts/Previews for Short Term Tickets (including the new FS Ticket).
3. The Calendar Control, used in different Dealware dialogs for the selection of dates, has beenchanged in order to be in line with the ISO standard weeks are now starting on Mondays, and
not on Sundays, like previously.
4. To make screenshots from Dealware easier to analyse, the DATAVERSION has been included asadditional information in the status bar.
5. An additional parametrisable DateAdjust has been created, in order to restrict the number ofbank working days between an interest accrual date and the corresponding interest payment
date for MM/LN/BN/BO. This restriction is working in both directions, back and forth. A default
value of 5, if no specific parametrisation is found. An information about the current parameter
settings returned by the Mercury Service getInfo(), the key being DealwareDealDateAdjust.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
6/25
Release Notes TRP2014-Jan
6 | P a g e
Financial Applications
6. An additional parametrisable MaxReconciliationDiff has been created, in order to restrict theamount differences accepted as normal during Reconciliation of paid amounts with agreed
payments. The default value is set to 0.99. The adaptation of the Reconciliation dialog is not yet
included in this Release Package.
7. Documentation: Due to frequent questions during installation/uprade of Mercury, especially incombination with the Dealware-Infoware connection, a document Mercury_Server_FAQs.docx
has been prepared (ftp.quipugmbh.com/Quipu Software/Mercury)
Modifications/Enhancements of Existing Features
1. User-defined columns in List Tickets. By using a specific substring format in the comments(=[ColumnContents]), users are able to dynamically add more columns into this
dialog. Previoulsy, was restricted to 7bit ASCII text without special charactersand whitespaces and the whitespace being the only allowed separator. Therefore, e.g., user-
defined Cyrillic Column Names were not possible. This has been changed now: The column name
can contain any character except whitespaces, ;, ,, and *,; additionally, the set of allowed
delimiters is now whitespace, ;, and ,.
2. Previously, just an empty page was shown by TWA if logging in with Read-Only access rights.Now, users can login, but cannot do anything more, and a message is displayed to explain the
situation, e.g. asking them to ask for a permission change.
3.
In the login dialog, where the password can be changed, there is now a help button explainingthe password complexity rules, in the same manner as it was displayed up to now after a missed
attempt by the user, but allowing an earlier information.
4. In the Account dialog, the Product Type control has been moved up and is located nowdirectly under the Account Type control. This has been made to facilitate the Create if
Accounts, where the Product Type represents a kind of Account Sub-type or sub-category.
5. Additional Party Types have been included: CentralBank, DomesticBank, PublicInstitution.They are needed in relationship to the implementation of Automatic Bookings, and in order to
make a differentiation between the Institutions ruling a certain currency (FinancialCentre) and
the Central Banks acting in a similar role as a Commercial Bank.
6. An additional Account Type has been created: Transitory. This Account Type is needed ascounter-account for payments to and from Loro Accounts. Deal Accounts of type Transitory can
be created, with the following restrictions: Own Bank as Account Holder as well as Account
Provider, Product Type Standard, related to Trade Group TG900 (NoRisk). In TRP January,
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
7/25
Release Notes TRP2014-Jan
7 | P a g e
Financial Applications
there is still no functionality related to this specific type of accounts; instead, as workaround,
nostro accounts with OurBank=AccountHolder and OurBank=AccountProvider are used.
7. There is now the possibility to have On-Site and Off-Site ATM balances monitored separately inDealwares Cash Status Report, but only for Customware.Net Banks having implemented asmall database structure change, and only after having installed TwisterCWN Client V.0.6.9 and
TwisterUserSrvCWN V.0.6.5.
8. Spanish Translations have been updated, the ones missing in TRP October and also the new onesfrom this TRP January.
9. Technical: The tool called previously DeleteQuipuUsers.exe, and existing in two differentversions for Bankware and for Dealware, is now existing in two variants with different names:
DwDeleteQuipuUsers.exe and BwDeleteQuipuUsers.exe
10.Technical: Starting with version 13.52, the Database Maintenance Tool DealwareSQL returns areliable return code: 0 (no error) or 1 (error). Based on this, instructions like if errorlevel 1 can
be used by DBA. For all previous DealwareSQL versions, the usage of the return codes does not
make sense at all.
Bug Fixing
1. The Mercury Service getCounterPartyInfo() was not returning updated information after a limitregistration; realized during debugging of IW load in PCH (loan failed after a limit update via
DW, only solution was restarting Mercury). Fixed.
2. Previously, the crosscheck of access rights during login was not deep enough, the Valid-To-Datewas not taken into account. Corrected.
3. For databases parametrised years ago, some Dealware users may not have a defined ShortCode. For Users without Short Code it is not possible e.g. to change the Dealer Type. The
Short Code is needed only for Front Officer when registering a Trade, before sending this Trade
to confirmation by Back Office; in this pre-ticket situation, the temporary Deal ID is constructed
based on the TimeStamp and the Short Code. Following change has been implemented: When
a Dealer Type is changed, and there is no Short Code, the Short Code field is automatically
filled with a short code proposal and the user has the possibility to edit this proposed short code.The Short Code control is enabled in the described way whenever there is a change in the Dealer
Type or a change in the Short Name of the Dealer.
4. There is a specific scenario where the user can avoid the forced shutdown which we included forusers not shutting down Dealware in the evening, before leaving. If there is an open dialog, with
not applied changes, the functionality of the forced shutdown displays in the morning a message
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
8/25
Release Notes TRP2014-Jan
8 | P a g e
Financial Applications
about a Login error and remind the users to shutdown correctly in the evenings, and a Lose
Changes? box appears. If the user presses Cancel to this message box, the applications stays
open; other open dialogs outside the one with the unsaved changes are closed, but the
application not, and the user can continue to make changes/registrations without being correctly
registered as logged-in. Fixed (the message box does not appear anymore in this situation andthe database is blocked for any writing activity).
5. In the small password dialog used for password changes during login, the [Cancel] button wasproducing an exception. Fixed in DW 4.3.x and 4.2.x
6. In List Currencies, there is a checkbox (marked by default) used to show only active currencies.This was giving the expected result for cases where Currencies are currently active and for
currencies which have never been activated. But, for the special case where a Currency was
active for a while, but is not active anymore, the currency was shown under the "active"
currencies. Fixed.
7. Some sorting problems have been solved for List Tickets.8. There was an exception when clicking on the Logo at the Left upper corner, and also a missing
graphic in Help > About section, same origin. Fixed now.
9. For several DW installations there was the need to re-set a parameter used for the maximaldifference between rates calculated from interest amounts registered by users in the LN/BO/BN
Payment Plan and the rates registered by the user for the Tickets included in these Payment
Plans. If the gap between the given and the calculated rate is higher than defined by the
parameter, it is not possible to send a Ticket to Back Office for confirmation. During the Upgrade
to TRP January, this gap definition will be automatically be set to the current default. It may be
necessary to change the parameter for cases where Banks do register e.g. Loans with very small
amounts and many installments. If there is a need for, your Regional Office will prepare and
deliver a compiled script for reparametrisation.
Short Term
New Features
1. The new feature refers to Short Term Deals (MM including Rollover, FX, TR, CI, CH, CN):Short-term tickets still not confirmed by Back Office, but already Sent by Front Office are now
displayed also in the list of "Pending Confirmations", and - when selected - the "Confirm"
button enables. If the "Confirm" button is used or if the selected Ticket is double-clicked, in
the List of Confirmations, the Ticket Printout is displayed, with an additional header allowing
the registration of a Comment, and the usage of the "Reject" or the "Confirm" button. If the
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
9/25
Release Notes TRP2014-Jan
9 | P a g e
Financial Applications
selected Ticket has already expired, the small dialog "Ticket expired" opens and displays a
text like "This Ticket was created 2012-12-17 and is now expired; Ticket status changed from
pending confirmation to expired" (this dialog is closed via the "OK" button). If a Ticket
changes the status to "expired" like explained, it disappears automatically from the
Confirmation List.
If the button "Reject" is used without filing in a comment, a small dialog pops up (called
"Reject Ticket") displaying the message "You have to enter a reason remark for the Reject".
(The button "Confirm" can be used with empty comment). If "Yes" is used, a message pops
up displaying "This Ticket was created 2013-07-12 and is now expired; Ticket status changed
from pending confirmation to expired", and the Ticket ID in the header is shown as "TR-
61961/1 [expired][Rejected]". If a comment is entered and then the "Reject" button used, a
message (called "Reject Ticket") is shown displaying a message like "Ticket TR-61961/1 was
registered 2013-07-12. If you reject this Ticket it will immediately expire. Do you want to
proceed?"; the buttons "Yes" and "No" can be used. Remarks are created automaticallydisplaying the status change during the reject, the reason, and the status change during the
expiration.
The number of Tickets shown in "Pending Confirmation" and the number of Tickets shown in
"List Tickets" is equal, if Status = "pending confirmation" and the correct period FromDate -
ToDate is selected. From "List Tickets", if the button "Ticket/SWIFT..." is used, a very similar
Ticket Printout is shown as when using the "Confirm" button in "List Confirmation" (to be
tested for each Ticket type) - the difference is only the Header part in the Confirmation
dialog. From "List Tickets", if the button "Open Ticket..." is used, the Ticket dialog is opened.
A ticket in status "pending confirmation" opened by a Back Officer (or a Demo User not
having created this ticket as Front Officer) via the "Open Ticket.." dialog from "List Tickets",
will show buttons "Confirm", "Reject" and "Ticket/SWIFT" (as long as the ticket is not
expired). If "Confirm" is used and the Ticket is confirmed, an opened "Pending Confirmation"
dialog will NOT be refreshed automatically ... if this ticket is opened from the Confirmation
List without a refresh, the Ticket Confirmation dialog will open displaying the message
"ERROR: Ticket status Confirmed but Pending Confirmation required" (after closing the
message, the "Confirmation List" will not anymore contain this ticket). If "Reject" is used and
the Ticket is rejected, a message like "Ticket MM-30743/1 was registered 2013-12-09. If you
reject this Ticket it will immediately expire. Do you want to proceed?" is shown, if "Yes" ischosen, a small dialog called "Reject Remark for Ticket MM-30743/1" is displayed and can
be used for the mandatory registration of a reject message. A "Reject" changes the status of
a Ticket to "Under Negotiation" (will immediately expire if opened later than on Registration
Date) and changes the status of the related Entries to "Deleted".
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
10/25
Release Notes TRP2014-Jan
10 | P a g e
Financial Applications
A ticket in status "pending confirmation" opened by the Front Officer we can have different
scenarios. On the Registration Date, the same Front Officer can make a Cancel/Storno as
long as the Ticket has status "Pending Confirmation"; other Front Officer need to be working
in "maintenance mode" in order to use the Cancel/Storno button . Outside the Registration
Date (as long as the ticket is not expired), a Ticket in status "Pending Confirmation" can onlybe Cancel/Storno by a Front Officer in "maintenance mode". An Expire is identical to the
usage of the Cancel/Storno button by a Front Officer (just another status set), and very
similar to a Delete (Front Office, before sending to Back Office).
The default behaviour in "List Tickets" is now changed, a double-click in the grid list is
opening by default the DealSwiftReport (for all Ticket types outside Swaps, for Swaps the
"old" Swap dialog opens, the one reachable from the menu), same as the button
"Ticket/SWIFT...". In order to open the DealTicket dialog, the "Open Ticket..." button needs to
be used. TicketList has now two buttons, "Ticket/SWIFT..." and "Open Ticket..." (in general,
the only remaining way to open a DealTicket dialog is TicketList button "Open Ticket...").
ConfirmationList is being refreshed automatically when the Confirmation dialog is being
closed.
Modifications/Enhancements of Existing Features
1. In Ticket Printouts related to Short Term Tickets (incl. FS), the field Registration Date has beenchanged to Registration Time. For Tickets already registered with Dealware 4.3.2 or higher,
where the Registration Time is captured, the exact timestamp will be displayed. For Tickets
registered before, the date and a text message is displayed in the box Registration Time (e.g.
2014-02-20 (Registration Date)).
2. As the menu option Cash Nostro (DealTickets related to cash deposits/withdrawals to/fromNostros) is now required by almost all Banks, this option existing since Dealware 3.8.0 - has
been included as standard. The menu option can be removed for specific Banks, on demand, via
a compiled script.
Bug Fixing
1. Realized during the testing phase in PCB UKR, but later also mentioned by users in PCB DEU: IfOperative System User Names do contain non-7bit-ASCII symbols, TRP April, TRP August, and
TRP October have problems with Logins, the attachment of Files to Deal Tickets, the usage of the
SWIFT confirmation messages, comments/remarks related to Deal Tickets, and some more
features related on one or the other form to paths.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
11/25
Release Notes TRP2014-Jan
11 | P a g e
Financial Applications
Regarding the topic of using Dealware under Windows 7 or Windows 8 (Russian version),
combined with User Names containing Cyrillic characters, there was a need for an additional
database structure change (included in UpgradeForRel425, DealwareSQL 13.48) in order to
adapt a database field storing a Registry Key for a specific Terminal. Login with non-ASCII OS
login name works fine as well as handling files with 'strange' filenames (append, show; literalcomments tested as well). The fix has been tested for file handling with Cyrillic, Arabic/Farsi,
Greek, Armenian, Japanese (katakana, kanji), Ivrit and 'fancy' letters/filenames. Showing files
after double click on them only works if a handling application is registered under Windows OS,
e.g. MS Office for Word and Excel files.
As Windows XP reaches end of life 2014-04-08, Microsoft will quit any further support for this OS
on this day; no changes related to an usage under Windows XP will be made, therefore (see also
GITIS).
2. NOT a bug, but maybe looking like a bug before analyzing FX Tickets, effective rate shown incomments: We do have the case of a Deal of 1,000.00 in Currency#1, equivalent to 1,123.46 in
Currency#2, based on calculations made with the Rate of 1.1234567. There are 7 digits after the
decimal point used for the Rate, but the amounts in Currency#1 and Currency#2 are rounded to 2
digits after the decimal points (as defined/parametrised for payments in this specific currency).
The bigger the amounts, the more you will see "effective rates" shown in comments with 7
decimals ... but, as the calculation of the "effective calculated rate" in the Remark section is the
rate calculated based on the two amounts, the rounding can be different. Let's go to an extreme
situation: We use 1.00 as Currency#1 amount and a DealRate of 1.1234567, giving 1.12 in
Currency#2; the calculation of the effective rates gives 1.1200000. This is to explain why the Deal
Rate is NOT the same as the effective rate shown in the comments.
Frequently Asked Questions
1. calculated effective rate shown in comments for FX Deals, if the Deal involves two ForeignCurrencies: For the case of two foreign currencies involved in one FX Deal, he stored official
exchange rates are used t identify the average local currencyamount, and this single average
local currency amount is used to calculate the calculated effective rate. Stored official
exchange rates are valid until further notice, but they expire after a certain number of days
(parametrizable). A calculation example: EUR 250,000.00 with the stored rate of 10.851297 gives
a local currency amount of 2,712,824.25 and USD 337.675.00with the stored rate of 7.00300
gives a local currency amount of 2,699,036.28; we sum up the two local currency amounts,divide by 2 and et the virtual local currency amount of 2,705,930.26; this virtual local currency
amount is now used to split the FCY-FCY Deal into two FX Deals involving local currency, EUR
250,000.00 @ LCY 2,705,930.26 gives a calculated effective rate of 10.8237210 and USD
337,675.00 @ LCY 2,705,930.26 gives a calculated effective interest rate of 8.0134160.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
12/25
Release Notes TRP2014-Jan
12 | P a g e
Financial Applications
Bonds
New Features
1. A Guarantor can be captured and stored now optionally -for Debt Securities (GuaranteedBy),similar to the already previously existing Issuer (IssuedBy), when creating or updating a Debt
Security. It is also possible to delete previously registered Guarantor.
2. For asset-sided Bonds, a Custody-To and a Custody-From Account can be now optionally captured and stored. Only accounts existing with product type Custody can be selected for this
purpose. The mechanism is the same as used for the Deal Accounts involved in money transfers
related to a Ticket, referring to the account from which we make outgoing payments, the
account on which we receive incoming payment and the counterparty account to which we make
outgoing payments. Custody accounts are only available for selection in the corresponding
controls, but not in the controls related to standard settlement accounts.
3. BUY and SELL activities for BN-Bonds: The settlement controls of a ticket are now taken out ofthe BUY/SELL pop-up windows and are shown if required to be selected by the user - below the
Payment Plan. Depending on the next item to be sent as a ticket (coupon or buy/sell of principal),
the counter-party, counter-party accounts and custody accounts are shown. If the next item is a
coupon, only the control WeReceiveOn is shown.
As the user selects the counter-party and its accounts, the chosen values are shown in the
Payment Plan grid for verification before sending to back office.
4. As temporal solution, until an implementation of a Delete for Debt Securities can be included inTWA, a tool called DeleteUnusedDebtSecurities has been compiled, removing DebtSecurities not
related to any Trade, together with the registered Coupon Dates, Prices, and Ratings.
Modifications/Enhancements of Existing Features
1. List Bond Deals hasbeen enlarged with the columns Notional Traded, Trade date, MaturityDate) and allows filtering by Issuer, Currency, ISIN, Counterparty.
2. List Registered Bonds improved, the column Notional has been renamed to Notional Owned,and the report allows filtering by Issuer, Currency, ISIN, Bond Type.
3. For BN-Bonds, the Payment Agent has been removed (Database, Mercury, and TWA). For BO-Bonds, the Counterparty is called Payment Agent, based on his role, like before.
4. It is possible now to refresh the settlement accounts in a user-friendly way. An extra control hasbeen placed near the [SEND] and [UPDATE] buttons, allowing users optionally to fix a new
account for the We receive On part.The account WeReceiveOn can be changed for next next
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
13/25
Release Notes TRP2014-Jan
13 | P a g e
Financial Applications
ticket or all unsent future entries by selecting the account and pressing SEND or UPDATE.
Pressing SEND will additionally create a ticket from the next unfixed row of the Payment Plan.
The saved changes will be visible in the Payment Plan and in the List of AccountEntries in
Dealware.
5. The label of the Deal ID was added for BO-Bonds.6. When TWA shows a bond where the issuer does not currently have the state Certified Issuer in
the database, TWA will show the name of the issuer with the suffix Not Certified Issuer.
7. A review was done related to the allowed Bond Types for BN-Bonds (Senior Bond, TreasuryBill, Commercial Paper, Covered Bond (Public Pfandbrief), Covered Bond (Mortgage
Pfandbrief) and for BO-Bonds (Senior, Subordinated (KWG), Subordinated (Other). If a
Bond was stored in the database a time ago, and an inconsistent/not-allowed value is retrieved,
TWA will prevent the users from pressing other buttons like [SAVE], [SEND], [UPDATE], etc.,
forcing the user first to select one of the permitted option.
8. Enlarging attributes for BN Mode and BO Mode in List Tickets. The Bond Modescan bereached (as up to now) via selection of BN/BO in the Deal Group control or by using BN/BO
as prefix for the search string in Ticket ID Prefix. Additional columns added are not Ticket
related, but Deal related: Deal DCF, and Deal Accrual Method.
9. In List Tickets, for BO and BN Modus, Day Count Fraction and Accrual Method has been addedas additional information.
Bug Fixing
1. Bug with the cursor when choosing a date. In the example reported, the Maturity Date falls on aSunday; the cursor was active for Saturday but not for Sunday, and the user was forced to enter
manually the date.
2. The Trade Date must now be on or before the Settlement Date of a bond.3. Previously it was possible to register Starting Date earlier than Trade Date, but not anymore.4. The First Coupon Date has been restricted to be strictly greater than the Issue Date and less or
equal to the Maturity Date.
5. Based on a problem in Beta Test Unit, for a zero bond which could not be saved: Now, an errormessage is shown when the Bond is Adjusted and the maturity date is on a holiday, causing the
[SAVE] button to be disabled.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
14/25
Release Notes TRP2014-Jan
14 | P a g e
Financial Applications
6. For the case of Bonds with an issued volume of more than 99,999,999.99, in previous versionsthere was a problem with the width of the columns (all tickets could be seen, but not in a very
nice way). Fixed.
7.
For bonds with Accrual Method Adjusted, where accrual date and payment date always needto be the same, it was not possible to edit the payment plan but it was possible to edit the
Coupon Schedule. But, changing the coupon date to a different one in the Coupon Schedule,
changed automatically the accrual date in the payment plan, but not the payment date, leading
to an inconsistent situation. Now, changing the coupon date changes the linked payments
accrual and payment dates.
8. Additionally, editing the last Coupon date has been disabled, as it needs to be always the sameas the Maturity Date.
9. All restrictions related to Blocking Dates during registration of Bonds have been removed. Bondsthat are meant to be issued need to have all its dates set to newer dates than the blocking date..
10.Notional Issued has been changed into Notional Traded, following the BusinessRequirements.
11.Problems fixed, related to the manual registration of wrong formatted dates (e.g. 2013 -3-12),where the filed for the coupon rates was not getting enabled, and the only possibility to correct
was removing the manually types date and selecting the correct date via the Calendar Control.
Known Issues
1. As users are allowed to edit the Coupon Schedule, e.g. modifying an interest rate, and as we donot have an automatic update for all related Deals, we may run in an inconsistent situationbetween an interest rate changed at the level of the Coupon Schedule and an interest rates
stored at the level of the Deal, especially if several Deals are related to the same Bond. If this
occur, it will not be possible to send further changes done in the Payment Plan (e.g. a SELL) to
Back Office for confirmation. A specialized compiled script need to be prepared in these
situations
Loans
New Features
1. For Loans (and technically also for Bonds, but probably not needed), a new database attributehas been added, allowing the possibility to make a differentiation between payment plans
having just one single principal repayment and payment plans initially agreed with several
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
15/25
Release Notes TRP2014-Jan
15 | P a g e
Financial Applications
instalments. This attribute is set automatically in the moment of first registration of a Loan. The
corresponding Mercury RPCs have been adapted.
Modifications/Enhancements of Existing Features
1. Enlarging attributes for LN Mode in List Tickets. The Loan Mode can be reached (as up tonow) via selection of LN in the Deal Group control or by using LN as prefix for the search
string in Ticket ID Prefix. Additional columns added are not Ticket related, but Deal related:
Deal Init. Rate, Deal Maturity (last principal repayment), DealFirst Disb., Deal DCF, Deal
Acc.Meth. and Bullet (Yes/No).
Bug Fixing
1. During the registration of a new Loan, it was possible to change the counterparty and/or thecurrency, without a removal of the data registered before in the We Pay To control. Fixed, now
the We Pay To control resets in these cases.
Swaps
New Features
1. A special Deal Ticket printout has been implemented for FX Swaps, containing details for theNear Leg as well as for the Far Leg (including the FX Ticket ID and Status) in separated boxes.
The FS-Deal ID is now included in the header part and the Ticket Type is displayed as FX SWAP
DEAL TICKET. In the box where the activity is shown for FX Tickets, we do have in this case
SWAP. Swap Points and Profit/Loss are displayed in a box between the Legs and the Signature
part. This Ticket Printout can be viewed from List Tickets (FS mode) as well as Swap using the
standard button *SWIFT/Ticket+.This new FS ticket layout includes also the Registration Time
(instead of the previously existing Registration Date), displaying a timestamp for Tickets
registered with Dealware versions 3.2 or higher. For Tickets registered before the change of the
database field was implemented, the date and a text message is displayed in the box
Registration Time (e.g. 2014-02-20 (Registration Date).This Ticket Printout can be reached
via the button *Ticket/SWIFT+ from the FS-Ticket dialog or from List Tickets in FS-Mode.
2. New mode FS (swap)included in List Tickets.In order to be able to include certain detailsrelevant only for the FX Swap case, this separated mode has been included. This special mode
can be reached via selection of FS in the Deal Group control or by using FS as prefix for the
search string in Ticket ID Prefix.The mark [ERROR9] is displayed for cases where there is no
matching amount between the Near Leg and the Far Leg (should not be the case, but was
technically possible before); for these Swaps, the 2 FX Tickets need to be unlinked: Use [Open
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
16/25
Release Notes TRP2014-Jan
16 | P a g e
Financial Applications
Ticket + in order to reach the Swap dialog, remove the warning shown, and Un-link. Additionally
to the standard columns Deal Type, Ticket Is, Trade date, Counterparty and Comments,
this mode includes:
At Deal level: Ccies (e.g. EURUSD), Swap Points (e.g. -0.25), Profit/Loss (e.g. 122.26)
For the Near Leg: Near Leg (e.g. FX-20710/1), Value Date, Our Move (e.g. WE SELLEUR), Amount, Cp. Move (e.g. CP BUYS < USD), Amount, Deal Rate
For the Far Leg: Far Leg (e.g. FX-20711/1), Value Date, Our Move (e.g. WE BUYEUR), Amount, Cp. Move (e.g. CP SELLS < USD), Amount, Deal Rate
3. Remarks can now be attached to the FS-Ticket itself (new media message type calledSwapIndividual). This kind of remarks are created being in the TicketPrintout (similar as we are
doing for LN/BO/BN), and stored simultaneously in both FX-Tickets; they are visible from each of
the involved FX, marked with the prefix *SWAP+. For this type of remarks, the Print Flag cannotbe changed from inside one of the FX-Tickets. Re: messages can be created in one of the FX
but are then only valid for this FX (and not visible in the FS or the other FX ticket). The Print Flag
can be changed inside the FS Ticket Printout. No additional Re: messages can be created inside
the FS (this feature can be added on demand later).
Modifications/Enhancements of Existing Features
1. Reviewed Swap dialog: All references to a Deal for both legs changed to Ticket. FS Swap TicketID displayed now additionally above both legs, SwapPoints/Profit/Loss line moved below both
legs. *Details+ buttons for both legs removed, new button *SWIFT/Ticket+ created, opening the
Ticket Printout for FS.
2. For List Tickets, in modes (all exc. swap) and FX, the underlying FX Tickets are shown insteadof the FS-Ticket, but marked like e.g. FX-20710 *FS+.
3. For List Tickets, uniformly for all modes, Short Term Tickets (incl. FS) can be reached via thebutton *Open Ticket+, and all Ticket Printouts can be reached via the button *Ticket/SWIFT+
Bug Fixing
1. Some minor bugs fixed in List Tickets, for FX Swaps.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
17/25
Release Notes TRP2014-Jan
17 | P a g e
Financial Applications
Exposure
New Features
1. The third grid inside Product-Specific Exposure report has got a button for showing details ofthe mentioned Tickets, similar as already before existing for Country Exposure and Daily
Exposure, but also including information for e.g. Nostros (the Account Statement is shown).
Modifications/Enhancements of Existing Features
1. Counterparties with Exposures but without at least Global Exposures should theoretically - notexist. Previously, they were not shown in Product-Specific Exposure. Now they have been
included. When there is no Limit defined, the exposure shows up as negative amount in Free
Total Limit.
2. Counterparties without Exposures and without Limits are not anymore shown in the first grid ofProduct-Specific Exposure.
3. In Product-specific Exposures, when a Trade Group is selected in the second grid, the statusshown for the 3
rdgrid is now displayed as Retrieving data (as it can be quite lengthy to fill the
3rdgrid with all the Deals making up the Exposure shown in the second grid).This way the user
knows that something is being calculated.
4. In Product-specific Exposure, Daily Exposure, and Country Exposure, thepreviouslydisplayed Complete Namefor a Financial Party has been replaced by the Short Name.
Bug Fixing
1. By mistake, the report Product-Specific Exposure was showing always figures as of today,independently of the Report Date selection in the header part of the dialog. This has been
fixed, the specific settlement date is now taken into account for the decrease of an exposure.
2. In previous versions, Nostros being overdrawn were also taken into consideration for theExposure, with their real (negative) balance, leading to wrong (too low) exposures and high
unused limits. Fixed now.
3. A bug was fixed related to the selection of Counterparties shown in the first grid.4. A bug was fixed related to the parametrization of the Duration Code for Limit Agreements. In
the TRP October, the Duration Codes 7D and 14D have been replaced by the corresponding
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
18/25
Release Notes TRP2014-Jan
18 | P a g e
Financial Applications
1W and 2W codes for future processing, but no deep enough analysis made related to already
stored Limit Agreements using this code. For PCB ROU, there was a warning
LimitAgreement::DurationCode Enum Item undefined shown in the logfile produced during
recreate of Backups. A specialized Recoding Script will be prepared for the repair.
UpgradeForRel434 also contains the recoding.
OCP
New Features
1. The impact of Accrued Interests for LN/BO/BN/MM is now included in Balance Position report.Additionally, the FX Contra Account Balances are calculated based on the Report Day Official
Exchange Rates, from the FX Position Account Balances (and not anymore transaction-based as
before). A line for totals has been added, amounts are calculated and shown only for LocalCurrency columns. The Entry Type box in the header has been replaced by the Viewpoint,
allowing the selections Include Agreed Entries (default: marked), Include Expected Entries
(default: not marked), and Include Accrued Interest (default: marked).The previously existing,
right-side button *Trades+ has been replaced by *ShowDetails+, enabled if there is anything
displayed in the grid, opening the Accounting Balances report, carrying over the Report Date
and for the case a row in the grid is highlighted carrying over also the Currency from this line.
If the checkbox for the accrued interests has been marked, on top of the FX Position Account
Balances, the accrued interest for Value Date = Report Date are calculated and added to the
displayed amounts (same calculation as in Accounting Balances).
Rates and Prices
Modifications/Enhancements of Existing Features
1. TwisterCWN is now importing also the Commercial Rates used in the Banking Module for FXOperations, and storing it in DW database. The report List Account Entries is showing this rate
in the comment part. This info is especially important for the case of FC/FC Trades with
Customers, not showing any rate in the Rate column of the report.
2. Price Import: When price for a value date and published datetimeis available, if theMercuryPriceImport tries to update the price again for same ISIN and if published date is
different than the one in the table for the same value date then it updates the price instead
skipping (like before). Tool was adapted to import the price together with yield or price alone.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
19/25
Release Notes TRP2014-Jan
19 | P a g e
Financial Applications
3. There is now the possibility to store Units (e.g. 100, if the official exchange rate is publishedas: 100 HRK = 25,538697) in the database. All Rate Import tools will be adapted during next
weeks, and the way Rates are published by Mercury Services (for consumers like e.g. Infoware,
Customware.Net) will be enlarged. But, the List Rates dialog will be adapted only for TRP April.
Payments
New Features
1. An additional parameter can now be stored, describing the maximum amount of differentallowed for the (later to be implemented) feature of automatic Reconciliation between an
agreed payment and a performed payment. Default is 0.99
Bug Fixing
1. TwisterCWN was showing an error when run in RESYNC mode. Fixed in versionTwisterUserSrvCWN 0.6.6 & TwisterCWN 0.6.10
2. The initial balance in the report Account Statement, for the case the checkbox include agreedones being NOT checked, was including the agreed entries in the calculation. Now, also for
Banks not being up to date with the confirmation of payments (a situation which is frequent
during Implementation Projects), the verification of Balances is possible and accurate. The initial
balance calculation is now refreshed every time the checkbox include agreed payments
changed.
Accounting
Modifications/Enhancements of Existing Features
1. Accrued Interest amounts for MM are now included in Accounting Balances. For the specialcase that a Money Market has Value Date as well as Maturity Date in the period selected for the
evaluation, the accrued interest appears in the Paid in Period column, if the Money Market is
still outstanding, the accrued interest appears in the Amount (Value Date End) column. For all
other cases, the behavior of the report is the same as already known for Bonds and Loans.
2. Accounting Balances: By Currency Filtering and Total Open Position. In order to improve thelink resp. comparison with the Balance Position report,The Type box in the left header part is
now separated in two sections, left-handed the Assets and right-handed the Liabilities. A
Currency control has been added, default selection (all). If a single Currency has been
selected, the new Open Position control displays the total in this currency, for the type of
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
20/25
Release Notes TRP2014-Jan
20 | P a g e
Financial Applications
assets resp. liabilities chosen and displayed in List of Deals.The date selection controls have
been cut in width and placed once beside the other.
3. A checkbox Include Taxes exists now in Accounting Balances, default un-checked. By settinga mark in tis checkbox, the accrued taxes are shown as additional component in the List ofDeals, for Loans and Bonds,in a very similar manner as it is done for accrued interests.
Bug Fixing
1. Nostro balance bug fixed. Mismatch in the NostroBalance when compared to AccountStatementdialog. The bug was final balance on the blocking date was not included.
Reporting
New Features
1. The database has been modified in order to allow the storage of local accounting and reportingcriteria, together with their relationship to international accounting and reporting
characteristics. The functionality for filling/adapting these criteria via the applications, and the
publication of these criteria via Mercury WebServices will be included in the next Treasury
Release Package.
2. Another database modification was made to have the possibility to capture the 2-digit alpha-numeric country ISO code, needed for official reporting in e.g. ECU.
3. The new WebService getPayment() is now publishing both the incoming payments and outgoingpayments. By default, the outgoing payment is returned, by specifying the Payment Type as
'incoming', incoming payments returned and when None, both the outgoing and incoming
payments is returned. When comparing to the getOutgoingPayments Call, the prefixes 'Omt' and
'Imt' have been added to all the attributes, in order to have an easier differentiation between
attributes related to the incoming money transfers and attributes related to the outgoing money
transfers. For Incoming Payments, if existing (and this is the case if a SSI account has been
defined for this Counterparty), the Source Account will be also published.
Modifications/Enhancements of Existing Features
1. The Mercury WebService getBalances() is now publishing accrued interest for MM/LN/BO/BN,additionally. The dataset published now is: PrincipalOutstanding', 'AccruedNotPaidInterest',
'DealId', 'Currency', PrincipalContractual', 'AccruedInterestContractual', 'ProductId'.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
21/25
Release Notes TRP2014-Jan
21 | P a g e
Financial Applications
2. Additional information related to Rollovers (RolloverId, RolloverAmount) for Money Markets ispublished now also in getMoneyMarketPayments().
3. Addition information CreatedAsBullet is published in getLoanContracts(), getBondContracts(),getLoanPayments(), getBondPayments().
4. Additional information InterestTransfer (related to the accrued interest accumulated in themoment of a BUY/SELL activity, part of the payment amount) is published in getBondPayments()
Bug Fixing
1. The Mercury WebService getBondPayments() was not returning the part of the payment relatedto the accrued coupon in the moment of buying/selling, now fixed.
2. Already in Mercury V.1.5.2.8, but not detected before, and fixed now for TRP October (MercuryV.2.0.2.1) as well as for TRP January: The Mercury Web Services getExchangeRates() and
getInterestRate(), getInterestRates() were showing an exception when used.
3. Mercury 2.0.2 was by mistake returning unsigned amounts in getExchangePayments(), detectedby the IW/BRP in PCB DEU. Fixed for version 2.0.2.1 (TRP October) and version 2.1.2 (TRP
January).
SWIFT
Modifications/Enhancements of Existing Features
1. Previously, the SWIFT message for Confirmation of an FX Deal (MT300) and the SWIFT messagecontaining the settlement instruction for the outgoing payment related to an FX Deal (MT202)
were generated together. Now, the MT202 part has been removed, as for Banks using
Customware.Net the MT202 is generated by the Payments Module (on Value Date). The part
related to the Confirmation of the Deal is like before generated by the Treasury Module (on
Trade Date). Also included in DW 4.2.5.5.
Bug Fixing
1. The generated MT300, for confirmation of FX Deals, was never tested before (but alreadyexisting for several years). Now, it was tested by several Banks, and PCB DEU compiled a detailed
gap analysis between the implemented MT300 and a modified MT300 accepted by the SWTFT
Server. Based on this description, MT300 has been adapted and can now be used to interchange
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
22/25
Release Notes TRP2014-Jan
22 | P a g e
Financial Applications
confirmations with other Banks (tested between PCB ARM and PCB DEU). Also included in DW
4.2.5.5.
Hints
It is necessary not only to enable the SWIFT functionality (standard parametrisation script), but also todefine the code for the Logical SWIFT Terminal (country-specific parametrisation sript), before being able
to generate Swift Messages.
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
23/25
Release Notes TRP2014-Jan
23 | P a g e
Financial Applications
Part 3 Country-Specific Tools
New Features
1. A new tool for the automatic background import of Official Exchange Rates has been preparedfor Colombia: COL: QuipuRateImportForCOL (V1.0.1)
2. A new tool for the automatic background import of Official Exchange Rates has been preparedfor Colombia: UKR: QuipuRateImportFoUKR (V1.0.0)
3. A new tool for the historic import of Official Exchange Rates for BNR has been prepared forRomania: ROU: QuipuRateImportForBNR (V1.0.0)
Modifications/Enhancements of Existing Features
1. The Rate Import tool for Ecuador needed an adaptation, the website rates were previously takenfrom was not working anymore. Adaptations for the new location has been included in
QuipuRateImportForECU (V1.2.1).
2. All interest rates needed for NSR purposes as raw data for the calculation of the monthlyhistorical swap curves are now captured additionally with the tool QuipuRateImporForDEU
(V2.2.0), taking the data from the Bloomberg FTP and storing them in a separated Rate Stream
called Isdafix inside the PCH DW database. The tool runs automatically in the background,
capturing USDSwap (published at 20:00), EURSwap (published at 12:30), and USDLibor(published at 13:30) rates.
3. The Rate Import tool for Romania needed an additional function for the Proxy userauthentication, to provide encrypted password instead clear text password. Adaptation was
included in QuipuRateImportForROU (1.2.0).
4. Mercury Client importing Prices from text files (very similar to the case of the RateImports). Lastchanges: Yield can also be imported in addition to the price if available, when not only price can
be imported skipping the yield information. Adaptation was included in MercuryPriceImport.exe
(1.1.0).
5. Mercury password, possibility to specify clear text password instead MD5 password. For Proxyauthentication password, possibility to specify encrypted password instead clear text. The
creation of encrypted password is described in the user manual delivered together with the tool.
Adaptation was included in QuipuRateImportForALB (1.2.0).
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
24/25
Release Notes TRP2014-Jan
24 | P a g e
Financial Applications
6. Mercury password, possibility to specify clear text password instead MD5 password. For Proxyauthentication password, possibility to specify encrypted password instead clear text. The
creation of encrypted password is described in the user manual delivered together with the tool.
7.
Adaptation was included in QuipuRateImportForARM (1.2.0).
8. Proxy authentication password, possibility to specify encrypted password instead clear text. Thecreation of encrypted password is described in the user manual delivered together with the tool.
Adaptation was included in QuipuRateImportForBIH (1.2.0).
9. Mercury password, possibility to specify clear text password instead MD5 password. Proxyauthentication included. For Proxy authentication password, possibility to specify encrypted
password instead clear text. The creation of encrypted password is described in the user manual
delivered together with the tool. Adaptation was included in QuipuRateImportForBOL (1.1.0).
10.Technical Update. Adapted was included in MercuryRateImport.exe (1.1.0).11.Technical Update. Adapted was included in QuipuRateImportForECB (1.2.0).12.Mercury password, possibility to specify clear text password instead MD5 password. For Proxy
authentication password, possibility to specify encrypted password instead clear text. The
creation of encrypted password is described in the user manual delivered together with the tool.
Adapted was included in QuipuRateImportForMKD (1.2.0).
13.Technical Update. Adapted was included in QuipuRateImportForNIC (1.1.0)
-
8/12/2019 Newsletter Release Notes TRP2014 Jan
25/25
Release Notes TRP2014-Jan
25 | P a g e
Fi i l A li ti
Change Control
Version Date Reviser Changes
0.1 2014-01-30 Inga Initial draft
0.2 2014-02-15 Inga updated
0.3 2014-03-11 Inga updated
0.4 2014-03-12 Christian updated
0.5 2014-03-12 Inga updated
0.6 2014-03-15 Sudhakar updated
0.7 2014-03-17 Inga Format updates, only
0.8 2014-03-20 Inga Including last minute changes
1.0 2014-03-22 Inga Final version