1.  Новый комплекс «Коммунальные платежи», который позволяет:- Вести базу договоров с организациями на прием наличных средств в их пользу с ограничением прав доступа конкретного кассира к данному договору. Настройка договора позволяет, при вводе платежей на конкретного получателя, автоматически определять следующие параметры: транзитный счет для зачисления наличных средств, реквизиты получателя для перечисления (зачисления) средств, кассовый символ, назначение платежа на перечисление, тип комиссии за прием платежа (с получателя, плательщика, аккумулировать на специальном счету с последующим погашением задолженности самой организацией и т.д.), сумму комиссии (фиксированная плата, процент от суммы, тарифная сетка), перечисление (зачисление) средств получателю (подокументно – на каждую принятую сумму будет сформирован отдельный документ, консолидировано – общей суммой, по кодам платежей данного получателя – общими суммами по кодам платежей), настройки параметров платежа для конкретного договора с последующим вводом ТОЛЬКО с необходимыми данными для конкретного получателя (например, для Укртелеком нужен № телефона, а для Киевэнерго – показания счетчика и т.д. Данная возможность существует для того, чтобы кассир при вводе платежа видел только необходимые для заполнения поля).- Настройку кодов назначения платежа (при необходимости) для конкретного получателя, с последующей возможностью выбора при вводе платежа для данного получателя и автоматическим формированием назначения платежа.- Прием всех видов платежей от физических и юридических лиц в пользу различных организаций (электроэнергия, платежи для ГИВЦ , Укртелеком, Киевстар, UMC и т.д.) как для организаций с заключением договора, так и разовых платежей (без заключения договора, согласно реквизитов предоставленных плательщиком) с возможностью печати документов (нет необходимости заполнять плательщику от руки) и оттиска. Проверка правильности заполнения реквизитов получателя на этапе ввода платежа (МФО, ключ счета, ОКПО).- Ведение базы всех получателей с автоматическим определением реквизитов по МФО и № счета на этапе ввода платежа.

   — Ведение базы плательщиков в разрезе конкретного получателя с автоматическим определением реквизитов плательщика (Ф.И.О. адрес и т.д.) по № счета, № телефона, идентификационному коду на этапе ввода платежа. Возможность настройки параметра платежа, который идентифицирует плательщика для данного получателя и параметров, которые необходимо сохранить для данного плательщика.

   — Протоколирование ввода, редактирования, удаления конкретного платежа.

   — Возможность настройки процедуры формирования отчетных реестров для получателя.

   — Настройка произвольной схемы формирования бухгалтерских проводок в ОДБ согласно принятых платежей (прием средств в кассу, взимание комиссии и перечисление средств получателю) согласно принятым платежам.
   — Ведение истории платежей за весь период работы с системой.

2. В контрактных системах добавлена возможность настройки безопасности на кнопку «Сохранить» через секретные пункты меню.
3. Новые системные роли:
   — 0.10.3. Операции над документами (SR_OPERATION_DOCUMENT_VIEW) — Роль для выполнения операций по F9 в документах (3.1) . Видимость операций настраивается на закладке «Дополнительно» — «Операции над документами».
   — 0.13 Видимость доступных отчетов (SR_REP_ITEM_VIEW) — Видимость отчетов, вызываемых через менеджер печати, дерево отчетов.
   Соответственно существует возможность выдачи прав на отчетные формы в разделе Права – Дополнительно — Отчеты.
4. Изменения в логике работы «Секретных пунктов меню». В глобальном реестре (ветка «Безопасность») добавлен ключ ‘SECURITYSECURITY_MENU_BEHAVIOUR’ , который определяет логику работы секретных пунктов меню.
   — ‘F’ (старый вариант) – выдача пункта меню на роль запрещает возможность его выполнения.
   — ‘T’ – добавление пункта меню в справочных секретных делает его недоступным для всех пользователей. Выдача пункта меню на роль разрешает возможность его выполнения.
5. В контрактные системы добавлена возможность просмотра протокола выполнения регламентных операций (без возможности внесения изменений в настройки).
   Находиться в п.5.1 Контракты / Операции / Протокол регламентных операций.
6. На третий уровень генератора проводок добавлен счетчик номера документа для этого шага генератора.
7. Банк «Киев». Добавлены параметры управленческого учета в документы и счета.
8. В контрактных системах добавлена возможность добавлять новый контракт на узле дерева типов, который не является типом сделки. Также эти узлы выделены жирным шрифтом.
9. Добавлена возможность запрета редактирования значений вертикальных гридов (доп. параметры, справочники п. 19.5), с помощью установки в поле R$_INFO_FIELD.READONLY – «Т» для необходимых полей.
   Например, если указать данный признак для полей табл. *_ATTR, то на закладке доп.параметры, все значения будут только для чтения.
10. В модуле «Налоговые накладные» добавлена выгрузка Реестров НН в формате dbf.
11. В тип кредитного контракта добавлено значение по умолчанию для «Тип расчета суммы для амортизации дисконта»
12. В SrMessage добавлены всплывающие окна, отображающее содержимое сообщения и отправителя. Механизм регулируется ключом в Глоб. Реестре.
13. В контрагентах добавлена возможность разграничения прав пользователей с помощью разделения на интерфейсе «Все», «По своему отделению».
14. Включена автоматическая сортировка по возрастанию дат в задаче Кредиты – «История выплат-погашений»
15. В задаче SrTemplldr.exe реализована SRBank безопасность, включена возможность импортировать/экспортировать отчеты под пользователями.
16. Доработан механизм при сохранении карточки счета контроля заполнения Доппараметров, которым установлен признак не пустое (not null)
17. Включен режим просмотра доппараметров на локальном счете контракта.
18. Реализована возможность запрета редактирования полей Кол-во дней в году (календарное или задать) в кредитном/депозитном договоре, настройкой на типе договора.
19. В задаче п.10.1 Отправка информации в налоговую – Неотправленные — добавлено попадание на отправку счета 2620 с R013=4 , открываемые для адвокатов и частных нотариусов.
20. Доработан механизм блокировки возможности ручной правки значений в карточке счета закладка Доп.реквизиты — Параметров: лимит овердрафта, неснижаемый/неповышаемый остатки, арест. Данная возможность регулируется ключами в глобальном реестре: Настройки массива счетов — EDITABLE_LIMIT / IS_EDIT_MIN_AMOUNT_ACCOUNT / IS_EDIT_MAX_AMOUNT_ACCOUNT / IS_EDIT_LIMIT_AREST
21. При занесении в РГР в разделев параметр < Список блокировки по Дт для балансовых счетов при открытии LIST_LOCK_ACC_OPEN > для блокировки счета значениe 2620 теперь учитываются только с параметром контрагента KL_K013=4. (cчета адвокатов и нотариусов 2620 работают на отправку в ГНА в режиме аналогичном счетам 2600). Счета 2620 KL_K013<>4 не блокируются по открытию.
22. Поле ВОЗМОЖНОСТЬ ПРОЛОНГАЦИИ вынесена в НАСТРОЙКА – Типов депозитных договоров, закладка ДЕПОЗИТЫ.
23. При выполнении пункта меню «Операции-Регламентные операции»(Shift-F9) во всех контрактных системах(п.п. 14.1, 14.2, 14.3, 30.1) имеется возможность исполнить дополнительные процедуры, теперь отображаются только настроенные задачи с признаком «активный» (поле IS_ACTIVE = T/F).
24. Добавлена вьюшка r$_table_sec/sr$r$_table_sec и для п.19,5 безопасность можно теперь отрезать по данному представлению.
25. В ImpDbf.exe – добавлена возможность разграничения прав пользователей. Добавлена возможность импортировать DBF файлы в WIN кодировке. (Импорт — импорт DBF в WIN кодировке).
26. В настройке счетов на тип договора (общие) активирована работа параметров Для всех валют / Для всех отделений. Логика работы – сначала ищем в настройках типа договора по параметрам, код макроса, валюта операции, код отделения. Если не нашли, то ищем с флагом, для всех отделений; не нашли – пробуем с флагом для всех валют, не нашли – пробуем с флагами для всех отделений и для всех валют. Если в типе нужная настройка не найдена, ищем на типе ALL_TYPES, в той же очередности
27. Исправлен Не корректный отбор масок счетов при открытии нового счета При открытии нового счета и выборе маски из справочника, в справочник не попадали маски с заполненной еще не наступившей датой закрытия, запрос исправлен на s.account_group_id (+)= g.id and (g.d_close is null or g.d_close > p_calendar.get_active_day)
28. В грид просмотра контрактов (кредиты/депозиты) добавлено отображение информации таблицы BANK_BUSINES. Для корректной настройки видов бизнеса в справочнике 20,33 Вид бизнеса добавлено поле is_type c разрешенными значениями (‘I’, ‘K’, ‘M’,’P’,’MK’,’S’)
29. В п 16,1 Заявки на покупку/продажу/конверсию валюты в закладке Реализация добавлены поля сумма реализации в межах банку и сумма реализации по результатам участия в СПЗ (система подтверждения заявок) для возможности настройки генераторов документов при расчете с клиентами с разными кодами для файла 2А
30. 30. Появилась возможность автоматической подстановки тарифного плана по умолчанию при ручном открытии счета в зависимости от балансового счета, типа валюты счета и параметра «К013» — «Класификатор кодов видов клиентов банка» (статпараметр в карточке контрагента).
    Ранее была возможность подстановки тарифного плана при открытии счета только в разрезе балансового счета и типа валюты счета.
31. Добавлена возможность формирования обязательной отчетности банка в п.11 по «кусту» (родительское отделение плюс подчиненные).
    Список отчетов Оборотно-сальдовая ведомость / Баланс в національній валюті / Баланс в іноземній валюті / Виписка по особових рахунках / Сальдова відомість по особових рахунках / Перевірочна відомість. Разграничены права доступа
    — пользователь Головного банка (Division_type “M”) может строить отчеты по любым отделениям.
    — остальные пользователи могут строить по своему кусту, по своему отделению, по подчиненным отделениям
    — опция «По всем счетам банка» активна только для пользователей Головного банка.

Изменения в депозитной подсистеме.

1. В настройке тарифной сетки для задания процентной ставки при добавлении договора появилась возможность использовать эквивалент суммы договора.Соответственно, если проставлена галочка в поле «Использовать эквивалент суммы», то диапазон сумм в настройке тарифной сетки будет рассматриваться как диапазон эквивалентов сумм договоров.
2. Снят обязательный запрет редактирования % ставки по договору при включенной тарифной сетке по типу договора.Теперь для запрета редактирования % ставки по договору используется стандартный метод, т.е. включенная галочка в поле «Недоступно для ред.» в блоке «% ставка» при настройке типа договора (закладка «Генерация»).
3. Работа с агентами.Добавлена в интерфейсе возможность настройки и контроля работы с агентами. Соответственно в настройке типов договоров появилась закладка «Агент».

   Где график выплаты вознаграждения агенту может быть единоразовым (в начале или конце срока) или периодическим (ежемесячным и т.д., например с учетом остатка по депозитному договору). Поле «Тип выплаты %» используется для настройки генерации процентной ставки агента при заведении или корректировки депозитного договора. Соответственно, если выбран тип «Фиксированная ставка», то ставка будет просто взята или из поля «Фиксированная», или вычислена по тарифной сетке. Если же выбран тип «Разница между клиентской %-й ставкой и максимальной по типу договора», то процентная ставка агента будет вычислена как разница между ставкой, под которую заключается депозитный договор, и максимальной по типу договора (фиксированной или вычисленной по тарифной сетке), но ограниченной максимальной, указанной в поле «Мах % ставка». Поля «Мах % ставка» и «Мin % ставка» также имеют смысл, особенно при снятой галочке в поле «Запрет редактирования процентной ставки». Поля «Запрет редактирования …» имеют смысл только для договора со статусом «Свободен», т.к. при действующем договоре все поля относящиеся к агенту будут запрещены к редактированию.

   В интерфейсе депозитного договора также добавлена закладка «Агент»:

   Где поле «Контрагент» является не обязательным, т.к агент может не быть контрагентом банка.

4. Использование аккумулирующих счетов в разрезе контрагента при автооткрытии счетов.При настройке автооткрытия счетов можно использовать аккумулирующие счета в разрезе контрагента. Т.е. аккумулирующие счета, открытые для конкретного контрагента, настраиваются для автооткрытия на конкретные макросы счетов, и соответственно при выполнении операции «Автооткрытие счетов договора» будут открыты субсчета на этих аккумулирующих счетах, а для контрагентов, по которым нет настроек по аккумулирующим счетам, будут открыты обычные аналитические счета.
   Настройка аккумулирующих счетов по контрагентах производится на закладке «Акум. счета по контрагентам» при настойке автооткрытия локальных макросов счетов.
5. Появилась возможность настройки собственных процедур при выполнении операций DEPO_OPEN, DEPO_CLOSE.Для этого в таблице DEPOSIT_EVENT_PROC добавляем запись с названием процедуры в поле PROC_NAME, а в поле EVENT указываем событие DEPOSIT_OPEN или DEPOSIT_CLOSE.
   В настраиваемых процедурах параметры не используются.
6. Исправлены следующие ошибки:• Проставление некорректных дат при операции простановки плавающей процентной ставки, которое вызывалось спецификой работы системной функции Oracle – add_months, которая при попадании входящей даты на конец месяца результатом всегда выдает дату на конец месяца. Т.е. если у нас есть дата, например 28.02., то добавление 1 месяца давало дату 31.03., а не 28.03.• Неверный контроль выплаты процентов, который иногда вызывался спецификой работы системной функции Oracle – add_months.