id|State|Adt_Created_By|Adt_Created_On|Owner|Headline|Adt_Functional_Area|Adt_Stage_Found|ADT_Defect_Type 10020|Adt_Defect_Priority|Build_Defect_Fix|Adt_Defect_Cause|Adt_Defect_Resolution|Adt_Custom1 CR|Adt_Custom2 BE|Adt_Custom3 Interface|Adt_Custom4 PVU_Areas|Adt_Custom5|Adt_Custom6|Adt_Custom7 Time to fix:|Adt_Custom8 Itilium|description TIA-31871|Open|nazarovayy|2011-01-28 11:10:31|jdmitrieva|MCK-745_УП_ввод премии с дробной частью|ProductsOther||Bug|Trivial||||||||||||При вводе договора УП с премией, не равной целому числу при нажатии на кнопку "Заполнить премию", возникает ошибка, см. скриншот После этой ошибки система зависает и не позволяет ничего делать, сообщение не закрывается. TIA-31878|Closed|torlova|2011-01-31 10:41:38|truhovaea|Закрыть задания в убытке C720370|Claims|Deploy|Bug|Trivial|||||||||||0000008417|Закрыть задания в убытке C720370: 134 TIA-31886|Closed|minasovpk|2011-01-31 17:20:58|sapozhkovav|Исправление записей таблицы acc_item|Acc_accounting||Bug|Minor|||||||||||8189|Таблица acc_item: в записи acc_item_no = 131515 в поле n04 значение 32237 заменить на 32239. в записи acc_item_no = 131519 в поле n04 значение 32239 заменить на 32237. TIA-31877|Closed|minasovpk|2011-01-28 17:22:03|truhovaea|Исправление отображения в акте п/п|Acc_accounting||Bug|Critical|||||||||||8399|Акт п/п TIA-2367262-20101228-A0-88 Не отображается взнос по 2180693 Акт п/п TIA-283746-20101214-A0-119 задвоена одна и та же оплата Акт п/п TIA-1420364-20101228-A0-22 P2884836 премия задвоена По полису АТС/52020149958 очередной платеж не отразился в акте Акт п/п TIA-57541-20110105-A0-90 Acc_item 2931341 P2381222 TIA-31887|Closed|oosipova|2011-01-31 17:49:22|zuyevva|УП_загрузка мастер-данных по агентам|Commisions||Improvement|Major||||||||||||Прошу загрузить мастер-данные (КВ и Лимиты) по агентам, см. вложение TIA-31792|Closed|torlova|2011-01-14 12:42:03|truhovaea|Необходимо убрать авторизацию убытков ПВУ-ОТВ (субриск 5) необходимо убрать|Claims_PVU|Deploy|Bug|Minor|||||||||||0000008237|Для убытков ПВУ-ОТВ (риск = 1, субриск = 5, линия = А11) необходимо убрать полностью авторизацию, т. к. по данным убыткам деньги списывают с компании автоматически и выплат не происходит (даже третьему лицу и представителю потерпевшего). Фиксированную сумму (тип оценки СО) также списывают согласно регламенту. Оценка по данным убыткам формируется автоматически. В function_auth должна быть запись для tia_user по кодам 50, 52, 53 для USER_ID = 'TIABATCH' где LIMIT = 120 000 и END_DATE = Null Как пример: C712290 C490271 C514714 TIA-31844|Closed|torlova|2011-01-24 10:16:34|sapozhkovav|кривое представление cla_cover_view|Claims|Deploy|Bug|Minor|||||||||||0000008167|C714227 кривое представление cla_cover_view - в нем отображается левый бсо (на этот бсо был заведен точно такой же договор, впоследствии расторгнутый 91м кодом) При подтягивании к убытку полис АТС/5202/0050321 (код дог. 1552694) в карточке убытка отображается договор АТС/5202/0050320 (код. 5165872), а договора с таким кодом нет в страховом покрытии. +изменить сортировку: изначально выводить действующие полиса, затем DUMMY В таблице object создать новый объект с object_id = АТС/52020050321 и привязать его к agreement_line_no = 5165872 TIA-31680|Closed|torlova|2010-12-10 12:29:00|kuschenkosv|***Некорректное округление при применении коэф.выплаты|Claims|Deploy|Bug|Major|||||||||||8064|при применении коэфициента выплаты и % износа сумма на форме округляется до сотых, но в таблицу пишется без округления. acc-item тоже округляется (в поле amt округляется, а в поле currency_amt - нет). платеж формируется на основании неокругленного cla_item. проблема, в частности, в сопоставлении 3 и 6 (которая формируется с округлением до сотых) необходимо при применении расчета с % износа или коэф. выплаты на 5640 округлять до двух знаков после запятой не только на форме, но и в таблице cla_item acc-item и платеж тоже должны быть с округлением до 2 знаков. TIA-31862|Closed|oosipova|2011-01-27 12:30:46|jdmitrieva|УП_непроизвольное очищение Причина операции|ProductsOther||Bug|Minor|||||||||||8404|Прошу разобраться с ошибкой, когда при расторжении договора очищается поле "Причина операции" на линиях договора, см. скриншот После заполнения полей "Причина операции" на каждой линии, после нажатия кнопку "Подтвердить изменения" система выдает сообщение что данные поля не заполнены. После повторного заполнения полей система говорит что незаполнено поле причина операции на ipa12, так происходит несколько раз. Только после этого возможно подтвердить изменения. Тоже самое с продуктом ЛИА_5203. Ошибка скорей всего общая, так же как и с КВ TIA-31889|Closed|nazarovayy|2011-02-01 10:45:57|jdmitrieva|MCK-749_Продукт ИМА/5103. Ошибка при сохранении скопированной линии.|ProductsOther||Bug|Trivial|||||||||||8444|Договор по продукту ИМА\5103. Ввод линии осуществялется копированием уже созданной линии. Все обязательные поля заполнены. При сохранении объекта (и по ОК и по Apply) выдается сообщение об ошибке (скриншот приложен). информация не сохраняется. TIA-31888|Duplicated|nazarovayy|2011-02-01 10:45:56|jdmitrieva|Продукт ИМА/5103. Ошибка при сохранении скопированной линии.|ProductsOther||Bug|Trivial|||||||||||0000008444|Договор по продукту ИМА\5103. Ввод линии осуществялется копированием уже созданной линии. Все обязательные поля заполнены. При сохранении объекта (и по ОК и по Apply) выдается сообщение об ошибке (скриншот приложен). информация не сохраняется. TIA-31882|In Progress|torlova|2011-01-31 14:40:09|kuschenkosv|Убыток в статусе EC, платеж реверсирован (сторнирован). Система должна позволять исправить полис.|Claims|Deploy|Improvement|Major|||||||||||0000008430|Необходимо добавить условие: если по полису есть убыток (в статусе EC или DC) и оплата по убытку (acc_item 3 класса) сматчена с acc_item 4 класса, то полис можно расторгнуть 91 кодом, если к полису не привязаны оплаты. И полис можно расторгнуть любым другим кодом (но смотреть соответствие кодов расторжения и продуктов) если он полностью оплачен (кв не учитываем). Как пример: P1284045. По данному полису убыток в статусе EC, платеж реверсирован (сторнирован) acc_item 4 класса. Необходимо данный полис расторгнуть 91 кодом, но возникает ошибка (см скрин) TIA-31884|Open|nazarovayy|2011-01-31 16:50:44|sapozhkovav|Добавление параметра поиска клиента (форма F2000)|Party_Client_data||Improvement|Trivial|||||||||||0000008401|Добавить на форму поиска клиента F2000 параметр ВУ серия, номер в соотвествии с приложенным описанием. TIA-31879|Open|torlova|2011-01-31 11:11:51|truhovaea|По убытку 472276 непонятно, каким образом появилась последняя запись|Claims||Bug|Trivial|||||||||||0000008393|Первоначально была выплачена сумма 135821.Кто-то после забил заявленную сумму 200000 и теперь не могуn сделать страховой акт. select * from cla_item where cla_item_no = '93622' --cla_case_no = '472276' ; непонятно, каким образом появилась последняя запись. вероятно, ее нужно прибить и поставить newest = 'Y' предпоследней. TIA-31826|Closed|oosipova|2011-01-19 19:24:01|jdmitrieva|УП_Изменения численных полей на тип "целое число"|ProductsOther||Improvement|Major|||||||||||8323|Необходимо изменить численные поля согласно списка на тип "целое число" TIA-31824|Configuration|nazarovayy|2011-01-19 17:05:35|truhovaea|Ошибка при выгрузке в EXCEL Отчета агента TIA-20101216-70258|Reporting||Bug|Trivial|||||||||||0000008317|Не выгружается в Excel Отчет агента TIA-20101216-70258. при нажатии кнопки Выгрузить отчет и подтверждения сообщения о выгрузке в Excel выдается ошибка (см скрин-шоты). Отчет не формируется. TIA-31892|Closed|oosipova|2011-02-01 14:23:12|jdmitrieva|MCK-750_УП_не настроены группы продуктов|ProductsOther||Bug|Critical||||||||||||Не настроены новые группы продуктов по УП это продукты, по которым менялись группы КВ, см. вложение закладка Группы продуктов TIA-31312|Configuration|nazarovayy|2010-10-15 08:29:00|ykorupayev|Необходимо доработать форму 1190|Sales_Policy_administration|Deploy|Sub-task|Minor|||||||||||6840|1. При выборе причины операций «Досрочное расторжение договора» и «Некорректный ввод данных» не позволять оставлять «договор в силе» в поле код расторжения. 2. Добавить проверку, которая не позволит изменить расторгнутый договор. Сейчас есть возможность расторгнутый договор изменить и даже сделать его вновь «Договор в силе». По п.1. Необходимо сделать 2 проверки: - если у линии указана причина операции не D и не E, то код расторжения на линии не должен быть = 0 - если по всем линиям причина операции не D и не E, то код расторжения на полисе не должен быть = 0 TIA-31827|In Progress|nazarovayy|2011-01-19 20:28:56|jdmitrieva|MCK-735_УП_изменение продуктов ЛИА|ProductsOther||Improvement|Major|||||||||||8324|Необходимо внести изменения в продукты ЛИА в соответствии с описанием во вложении TIA-31767|Closed|oosipova|2011-01-11 15:43:23|jdmitrieva|Загрузка 6-го пакета УП и доработки по результатам тестирования|ProductsOther||Improvement|Major|||||||||||8219|Загрузка 6-го пакета продуктов TIA-31639|In Progress|torlova|2010-12-03 13:54:00|kuschenkosv|Не заполняется поле member_no в таблице ssg_cla_stoa_case|Claims|Build|Bug|Minor|||||||||||7999|Не заполняется поле member_no в таблице ssg_cla_stoa_case TIA-31769|Resolved|torlova|2011-01-11 18:02:38|zuyevva|задвоение субрисков|Claims||Bug|Minor|||||||||||0000008218|Необходимо убрать задвоение субрисков в представлении subrisk_master как пример: select * from subrisk_master where RISK_NO = '2' and PRODUCT_LINE_ID = 'A01' and DESCRIPTION = 'Повреждение (Уничтожение)' cla_type_combination product_line_covercodes cla_cube вот три настроечные таблицы может эта ошибка вообще в интерфейсе, а не в таблицах? т. к. переделывали функцию, чтобы не выводились непокрывемые субриски TIA-31728|Closed|minasovpk|2010-12-27 12:35:22|zuyevva|Необходимо удалить задублированные проводки по курсовым разницам|Acc_accounting|Deploy|Bug|Minor|||||||||||0000008160|Удалить следующие проводки с gl_batch_no = 411 posting_id= 890CUR9043 890CUR7984 890CUR2159 890CUR12047 890CUR12045 890CUR12046 TIA-31117|Deffered|kuschenkosv|2010-09-21 14:27:00|kuschenkosv|*** Изменить способ хранения пароля к роли TIA_USER|Technical|Deploy|Improvement|Minor|||||||||||7087|Коллеги, в системе TIA существует потенциальная угроза безопасности. Каждый пользователь имеет разрешение на использование роли 'TIA_USER'. Нормальная работа пользователей в TIA возможна только при использовании этой роли (так устроено ядро системы). Данная роль содержит очень внушительный список привелегий, включая возможность изменять записи в таблицах и удалять таблицы. Проблемма заключается в том, что пароль к роли tiar_user хранится в открытом виде в одном из файлов библиотек. Соответственно, для изменения пароля необходимо не только выполнить команду смены пароля в oracle, но и править файл. Средств правки данных файлов у администраторов нет, даже если мы получим средство для правки файла, пароль всё-равно будет виден в открытом виде в этой библиотеке. Помимо прочего, так как к файлу происходят частые обращения есть вероятность что для его изменения в случае плановой смены или компрометации будет необходима полная остановка сервера приложения TIA, что не представляется мне хорошей идеей. Предлагаю вынести установку роли в отдельную хранимую процедуру, вызываемую с правами пользователя, и зашифровать эту процедуру срандартными средствами ORACLE (WRAP), таким образом, мы избавимся от хранения пароля в открытом виде, облегчим процесс плановой смены пароля и смены пароля при его компрометации. *** Помимо скрытия пароля, предлагаю ограничить набор программ, которые могут получать роль TIA_USER. Роль TIA_USER должны иметь возможность получить только пользователи, сессия которых открыта сервером приложений (программой frmweb.exe или javaw.exe). Данная мера позволит уменьшить вероятность извлечения и изменения данных сторонней программой в случае компрометации пароля роли TIA_USER. Название процесса текущей сессии можно получить запросом: SELECT s.program FROM gv$session s WHERE s.audsid = USERENV ('sessionid') TIA-31806|In Progress|nazarovayy|2011-01-18 10:43:49|ykorupayev|Доработать форму F1190 (раcположение полей, просмотр Акта приема-передачи из формы полиса), реализация контролей ввода информации|Interfaces||New Feature|Major|||||||||||0000006839|Требуется изменить форму регистрации полиса и параметры контроля ввода информации (реализован ряд контролей, при которых проверка на правильность отражения информации осуществляется на ДАТУ ВВОДА полиса в систему, необходимо проверять на ДАТУ ВЫДАЧИ ПОЛИСА). Требуется внедрить функциональность, которая из формы ввода полиса разрешает просмотр акта приема-передачи. TIA-31890|Closed|nazarovayy|2011-02-01 13:22:00|truhovaea|Указать Код расторжения в полисе ИФА/51010037084 (P3683265)|Sales_Policy_administration||Bug|Trivial|||||||||||0000008446|На форме F1190 для последней версии полиса ИФА/51010037084 (P3683265) указать Код расторжения - 91 Ошибочно созданный договор TIA-31808|Rejected|torlova|2011-01-18 14:39:37|truhovaea|В убытках на форме F5620 (закладка "Задания") не отображается Код и Наименование некоторых заданий|Claims|Deploy|Bug|Trivial|||||||||||0000008253|В убытках на форме F5620 (закладка "Задания") не отображается Код и Наименование некоторых заданий Как пример, убыток C18941 (см скрин) Необходимо для всех убытков, у которых поле SSG_CLA_TASKLIST_AUDIT_VIEW.TASK_ID не пусто, и при этом поле CLA_TASKLIST.TASK_ID пусто, заполнить поле CLA_TASKLIST.TASK_ID значением из SSG_CLA_TASKLIST_AUDIT_VIEW.TASK_ID. Также необходимо проверить, почему возникает данный баг TIA-31286|Deffered|minasovpk|2010-10-11 15:19:00|kuschenkosv|Исправить процедуру по отвязке оплаты, когда остаются 'лишние' КВ + проверка+ датафикс|Commisions|Deploy|Improvement|Minor|||||||||||7264|Хочу обратить ваше внимание на еще один кандидат в CR: При сопоставлении задолженности страхователя с оплатой напрямую формируется КВ к выплате. Но при разработке не было предусмотрено обратного действия - если сопоставление ошибочное, то его рассопоставляют, но КВ при этом остается. В итоге - лишние записи КВ к выплате и риск выплатить лишние деньги агентам. В службу поддержки с этой проблемой обращаются мало, поскольку пользователи это видят в только определенной ситуации, но проблема, на мой взгляд, серьезная. 1. доработать функционал, как только будут ресурсы 2. сделать проверку на консистентность данных, чтобы выявить «лишние» КВ и удалить их (как можно быстрее) TIA-31362|Validate_fix|torlova|2010-10-20 14:54:00|kuschenkosv|Прошу внести изменения в пакет определения статуса убытка. Текст пакета прилагается.|Claims|Deploy|Bug|Minor|||||||||||7475|Прошу внести изменения в пакет определения статуса убытка. Текст пакета прилагается. TIA-31789|In Progress|minasovpk|2011-01-13 19:48:53|truhovaea|исправление алгоритма расчёта К1|Sales_Policy_administration||Bug|Minor|||||||||||8184|Внести изменение в алгоритм расчёта коэф. К1: (Form FA010, Block name: Object, Table name: Obj_A0o1, Field name: K1_1). Вместо даты начала страхования (Form F1190, Table name: Policy, Field name: Cover_Start_Date) в расчёте должна участвовать дата выдачи полиса (Form F1190, Table name: Policy, Field name: Document_Date). Пример: полис № 3447030. Интерфейс: Открыть форму 8008. В окно № клиента ввести "P" и номер договора. Открыть нужный договор из табличного списка. Встать на линию. Нажать кнопку "объекты". Встать на закладку "Тарифы". Расчёт запускается по кнопке "Расчёт". TIA-31802|Resolved|torlova|2011-01-17 14:27:07|zuyevva|Договор нельзя перевести в статус полиса|BSO||Bug|Trivial|||||||||||0000008248|Договор P2995751 находится в статусе котировка, при этом, бланк БСО прикреплен к договору (поле C01 таблица Policy заполнено). Но бланк БСО находится в некорректном статусе 003 (должен быть 002). Необходимо изменить статус бланка ВВВ0165116925 с 003 на 002. TIA-31836|Open|nazarovayy|2011-01-21 15:45:43|jdmitrieva|MCK-736_УП_заполнение выгодоприобретателя|ProductsOther||Improvement|Trivial|||||||||||8340|При наличии в продуктах УП полей «Выгодоприобретатель=Страхователь?» необходимо, чтобы при установке чек-бокса сразу же заполнялось поле Выгодоприобретатель. Сейчас это поле заполняется только при переходе на другое поле или при нажатии кнопки Enter. Данный функционал уже реализован в договорах АВТО, см. скриншот TIA-31894|Open|torlova|2011-02-02 10:49:12|jdmitrieva|MCK-645 Ошибка код ОКАТО|Claims|Build|Bug|Minor|||||||||||MCK-645|Не генерится код ОКАТО, для Зеленограда, если не указать населенный пункт во вкладке Случай TIA-31885|Open|nazarovayy|2011-01-31 17:05:08|kuschenkosv|Изменение профиля "Curat1"|TIA_audit||Improvement|Trivial|||||||||||0000008413|Изменить существующий профиль прав CURAT1 следующим образом: 1. Отключить доступ ко всем операциям с агентским отчетом, разрешить только просмотр 2. Отключить доступ коперации подтвержденияя Актов приема - передачи (разрешить только создание, просмотр и т.д. , т.е. все операция до момента подтверждения) Разработать скрипт, с помощью которого можно перевыдавать права сотрудникам (группе). TIA-31852|Validate_fix|atelezhnikov|2011-01-25 10:49:07|ykorupayev|Изменения в отчете о направлениях на СТОА|Reporting|Analyze|Improvement|Trivial|||||||||||0000008141|Необходимо внести изменения в отчет для отображения информации всех созданных направлениях на СТОА включая и те, по которым не было создано платежей. Т.е. которые не отражены в acc_item. Отчет в интерфейсе: "Хранилище данных" -> "Выгрузка СТОА" Форма: fs774 Пакет с запросом: ssg_rep_stoa Прилагаю спецификацию, на основании которой был создан данный отчет и запросы. TIA-31837|Closed|nazarovayy|2011-01-21 16:09:12|jdmitrieva|Ошибка при создании доп. соглашений (instl_req)|Sales_Policy_administration||Bug|Major|||||||||||8255, 8335, 8241|Пользователь создает доп. соглашение ( примеры договоров на боевой среде 2222590, 1603825, 3673545 (расторжение)). Подтверждает изменения. Отменяет печать и нажимает ОК (Cancel) в форме F1095 Печать документов. В этот момент возникают системные ошибки типа: Отсутствуют данные в instl_req, Сумма записей в instl_req не равна нулю (см. скриншот). Ошибка возникает при создании допника первый раз. Второй раз создать допник позволяет. TIA-31895|Open|torlova|2011-02-02 11:18:10|jdmitrieva|MCK-691_Не требует ввода франшизы при сохранении РЗУ.|Claims|Build|Bug|Trivial|||||||||||MCK-691|Не требует ввода франшизы при сохранении РЗУ. Позволяет сохранить оценку без указания франшизы. 1. При создании убытка для объекта с франшизой нет проверки строки оценки EX 035 (франшиза), т. е. если по полису франшиза = 5000, то строка оценки с типом 035 = 5000, но не больше. Необходимо при сохранении РЗУ требовать ввод франшизы, т.к. оценку вводим по конкретному объекту, в полисе франшиза так же привязывается к объекту. 2. Признак франшизы не отображается на алетбаре Информация и Франшиза. Необходимо отображать общий признак наличия франшизы по всем объектам полиса (Y/N), указывать только признак без конкретной суммы. TIA-31841|Closed|oosipova|2011-01-21 21:15:26|jdmitrieva|УП_изменение настроек 6-го пакета|ProductsOther||Sub-task|Major|||||||||||8344|Внести изменения в настройки 6-го пакета. изменения во вложении выделено красным цветом TIA-31842|Closed|oosipova|2011-01-21 21:46:00|jdmitrieva|УП_изменение линии ИПА/5200 Имущество|ProductsOther||Improvement|Major|||||||||||8345|Внести изменения в линию продукта ИПА/5200 Имущество. Изменения во вложении выделены красным цветом. TIA-31839|Closed|oosipova|2011-01-21 17:08:34|jdmitrieva|УП_изменить обязательность заполнения поля год постройки|ProductsOther||Improvement|Major|||||||||||8416|В продукте ИФА/5203 поле "Год постройки" сделать необязательным для заполнения. TIA-31900|Open|torlova|2011-02-02 18:25:48|torlova|Прошу исправить ошибку формы 5640.|Claims|Build|Bug|Trivial|||||||||||0000008435|Добрый день. Прошу исправить ошибку формы 5640. По каким - то причинам не срабатывает триггер при указании вручную статуса CL на оплаченной оценке. Причем статусы EC DC записываются стабильно. При попытке сохранить статус CL значение автоматически возвращается в статус ОР или RO, курсор перемещается в поле ТИП TIA-31901|Open|nazarovayy|2011-02-02 18:26:47|nazarovayy|Изменить страхователя в полиcе P1105280|Sales_Policy_administration||Bug|Trivial|||||||||||0000008420|Полис 1105280 «висит» на неверном клиенте, ошибка ввода. Страхователь должен быть - Ольга Арефьева (сейчас Вячеслав Арефьев № ТИА 1671596) , копию полиса прилагаю. Расторгнуть 91 кодом не можем, выплачено КВ. Переименовать карточку клиента тоже не можем, т.к. на клиенте еще есть полис ОСАГО, расторгать тоже нельзя. Исправьте, пожалуйста, способом data fix, если есть возможность. Иначе мы не можем корректно урегулировать убыток. TIA-31843|Closed|oosipova|2011-01-21 21:58:21|lsproge|УП_ошибка при расторжении 91-м кодом|Sales_Policy_administration||Bug|Minor|||||||||||8346|При расторжении договора ID=3557561 91-м кодом выдается ошибка, расторгнуть договор невозможно. см. описание в файле TIA-31897|Open|nazarovayy|2011-02-02 15:43:39|zuyevva|В полисе ВВВ0544572252 (P2928450) в форме F1190 не отображается информация по объекту|Sales_Policy_administration||Bug|Trivial|||||||||||0000008418|В договоре ВВВ0544572252 (P2928450) в форме F1190 не отображается информация по объекту. Договор включен в Акт ПП TIA-289361-20101015-A1-321, при просмотре акта строка договора отсуствует. Договор находится в статусе ПОЛИС, оплачен. Акт ПП в статусе подтвержден. скриншоты приложены TIA-31893|Configuration|nazarovayy|2011-02-01 20:59:26|ykorupayev|Доработка контролей на дату выдачи полиса|Sales_Policy_administration||Improvement|Critical||||||||||||1. Выдавать сообщение об ошибке при незаполненной дате выдачи полиса (не давать возможность выдачи БСО) 2. Во всех процедурах, которые подтягивают данные по агенту (куратор, МВП, группы КВ, ...) заменить текущую дату на дату выдачи полиса Описание с примерами см. во вложении TIA-31902|Open|torlova|2011-02-02 18:31:14|torlova|Добрый день, ввожу счет - ТИА не дает сохранить и выдает ошибку. Счет введен правильно..|Acc_accounting|Build|Improvement|Trivial|||||||||||0000008439|Добрый день, ввожу счет - ТИА не дает сохранить и выдает ошибку. Счет введен правильно.. TIA-31804|In Progress|minasovpk|2011-01-17 18:15:21|sapozhkovav|Исправление проводки по исходящим регрессам|Acc_accounting||Bug|Minor|||||||||||8185|В SAP не создётся проводка Дт76022200 - Кт22000000. Причиной может быть то, что эта проводка должна создаваться на основании аналогичной в ТИА. В ТИА создётся проводка: Дт76022200 - Кт TECH_ACC. Вариант решения: Заменить Кт TECH_ACC на Кт22000000. Проверить выгрузку проводки в файле ACC_DOC. Описание - в спецификации. Пример: убыток № 26674. Договор № 336602. TIA-31752|Validate_fix|minasovpk|2010-12-29 10:44:52|zuyevva|Квитанции А7 и сервисные карты КАСКО|BSO||New Feature|Major|||||||||||7761|Разработка согласно спецификации дополнительного функционала по учёту квитанций А7 и сервисных карт КАСКО TIA-31903|Open|torlova|2011-02-02 18:36:05|torlova|Необходимо доработать функционал по проводкам ПВУ|Acc_accounting|Build|New Feature|Minor|||||||||||0000008441|1. Необходимо доработать функционал по проводкам ПВУ: при отмене платежа в ТИА (реверс платежа) необходимо, чтобы в САП уходила проводка, обратная той, которая выгружается при создании платежа. Инициатор Шлиммер О. Аналитиком прошу назначить меня. Спс! TIA-31904|Open|torlova|2011-02-02 18:37:36|torlova|Необходимо доработать функционал по БСО|BSO|Build|New Feature|Trivial|||||||||||0000008442|1. Необходимо доработать функционал по БСО: добавить возможность удаления БСО из документов (значительно уменьшит кол-во датафиксов) TIA-31905|Open|torlova|2011-02-02 18:38:39|torlova|По полису P1284045 необходимо поменять клиента на 537063|Sales_Policy_administration||Bug|Trivial|||||||||||0000008455|По полису P1284045 необходимо поменять клиента на 537063 TIA-31906|Open|torlova|2011-02-02 18:39:44|torlova|внести изменения в печатную форму страховых актов|Claims|Build|Improvement|Trivial|||||||||||0000008464|Прошу внести изменения в печатную форму страховых актов. При формировании страхового акта в иностранной валюте выводить вместо размерности у.е признак валюты в которой сформирована оценка по убытку для получателя, указанного в страховом акте. TIA-31907|Open|torlova|2011-02-02 18:40:53|torlova|изменить статус бланка БСО ВВВ0161720339|BSO|Deploy|Bug|Trivial|||||||||||0000008463|прошу Вас изменить статус бланка БСО ВВВ0161720339, так как при вводе договора в систему TIA мне выдается сообщение о том, что данный бланк имеет некорректный статус. TIA-31801|Closed|torlova|2011-01-17 11:58:31|sapozhkovav|Бланк АТС/52020049590 необходимо удалить из документа Списание № 012591-2010 от 03-AUG-10|BSO|Deploy|Bug|Trivial|||||||||||0000008254|Бланки (АТС/52020049590, АТС/52020035214) необходимо удалить из документа Списание № 012591-2010 от 03-AUG-10 TIA-31908|Open|torlova|2011-02-02 18:42:05|torlova|Необходимо запретить регистрацию дублей реквизитов|Acc_payments|Build|New Feature|Trivial|||||||||||0000008466|Необходимо запретить регистрацию дублей реквизитов. При попытке сохранить реквизиты при полном совпадении с ранее зарегистрированными реквизитами выводить сообщение «Реквизиты уже зарегистрированы. Перейти к этим реквизитам?» Да/Нет. Позволять сохранять ранее введенные дублированные реквизиты с указанием кода приостановки. Позволять переоткрывать ренее введенные реквизиты с последним BVTYP, по которому корректно прошла транзакция в САП. При этом все остальные дубли должны быть приостановлены. На форме платежей осуществлять проверку на привязку не заблокированных реквизитов. В случае попытки привязать заблокированные реквизиты выводить сообщение «Реквизиды заблокированы, выберите другие реквизиты» «Ок». Показывать на форме S662 BVTYP. Запретить редактирование ранее зарегистрированных реквизитов за исключением полей приостановления, по которым была произведена корректная транзакция в САП. TIA-31909|Open|torlova|2011-02-02 18:43:27|torlova|Необходимо сделать так, что бы найдя собственника по клиентскому поиску или выгодоприобретателя или водителя, можно было определить, с каким договором они связаны.|Claims|Build|New Feature|Trivial|||||||||||0000008469|Необходимо сделать так, что бы найдя собственника по клиентскому поиску или выгодоприобретателя или водителя, можно было определить, с каким договором они связаны. TIA-31910|Open|atelezhnikov|2011-02-02 18:43:29|atelezhnikov|Доработка графика платежей|Sales_Policy_administration|Analyze|Improvement|Trivial|||||||||||0000008232|Необходимо сделать доработку ТИА в части изменения функционала работы Графика платежей 1. Удобный интерфейс для корректировки записей ГП 2. Реализация рассрочки для УП a. Раз в полгода b. Раз в квартал c. Ежемесячно d. Единовременно - аналогично АВТО Необходимо, чтобы рассрочка отличалась от АВТО и не было возможности выбирать ее в ОСАГО и разные списки в КАСКО и продуктах УП. TIA-31911|Open|torlova|2011-02-02 18:44:47|torlova|Исправлено описание значения тега clam.001.001.01/GENL/Hldng.|Claims|Build|Improvement|Trivial|||||||||||0000008470|Прошу внести необходимые изменения. Основные изменения относительно версии 24.1 Исправлено описание значения тега clam.001.001.01/GENL/Hldng. TIA-31913|Resolved|torlova|2011-02-02 18:46:54|truhovaea|По убытку C581154 изменить Риск оценки (Тип СО, Субтип 001) на 2|Claims|Deploy|Bug|Major|||||||||||0000008473|По убытку C581154 изменить Риск оценки (Тип СО, Субтип 001) на 2 на форме 5640 TIA-31915|Open|torlova|2011-02-02 18:51:24|torlova|Учет одного вида бланка по нескольким продуктам|BSO||Improvement|Trivial||||||||||||Доработка ТИА для учета одного вида бланка для нескольких продуктов например, ЛИА/5200 и ЛИА/5200_дети TIA-31846|Closed|oosipova|2011-01-24 14:13:06|jdmitrieva|УП_изменение продукта КАА/5100|ProductsOther||Sub-task|Trivial|||||||||||8356|Линия продукта "КАА_5100 ущерб грузу" изменить название поля «Товаросопроводительный документ» на «Товаросопроводит. док-т» TIA-31898|Open|torlova|2011-02-02 17:16:05|truhovaea|Не учитывать начисления по субтипу оценки 055 для авторизации убытка по кодам 50, 52, 53|Claims|Build|Improvement|Major|||||||||||0000007337|Не учитывать начисления по субтипу оценки 055 для авторизации убытка по кодам 50, 52, 53. Необходимо сделать доработку с возможностью изменять настройку субтипов оценки по кодам авторизации без дополнительного программирования. Доступ к форме данных настроек должен быть у администраторов системы. см спеку TIA-31415|In Progress|minasovpk|2010-10-27 08:13:00|sapozhkovav|***При взаимозачете рождается КВ к выплате|Commisions|Deploy|Bug|Minor|||||||||||7559|При взаимозачете возврата по расторжению рождается КВ к выплате. Этого быть не должно. КВ к выплате рождается только при переносе задолженности или при прямом сопоставлении 1 с 5. 1. нужно исправить логику 2. нужно найти все кв к выплате, которые родились от сопоставления 1 на счету страхователя с 2 от другого полиса и удалить их, если они еще не включены в подтвержденный отчет. если они в подтвержденном отчете - будем рассматривать такие случаи отдельно. TIA-31425|In Progress|minasovpk|2010-10-28 08:07:00|sapozhkovav|***Поправить логику возникновения КВ к выплате при переносе на агента прямых продаж|Commisions|Deploy|Bug|Trivial|||||||||||7568|P1944746 перенос задолженности по второму взносу был сделан на сотрудника прямых продаж, не указанного в полисе. то есть группа кв нулевая. КВ с этого переноса родилось на счету '-2'. В случаях, когда перенос делается на сотрудника с нулевой КВ, КВ к выплате вообще не должно рождаться. В данном случае нужно: 1. Поправить логику, чтобы кв в таких случаях не рожделось 2. Перенести родившееся КВ к выплате: acc-item 1812798 на счет 8385 acc-item 1812800 на счет 10220 пункт 2 перенесен в cq 5867 TIA-31918|Open|minasovpk|2011-02-03 12:06:14|truhovaea|Исправление отображения в полисе|Sales_Policy_administration||Bug|Major|||||||||||8456|Договор № 1149598. 1. При переходе на просмотр 1 линии договор перескакивает со второй на первую версию полиса (чего быть не должно). Неверно отображается срок страхования в 1 версии договора. Должно быть 26.01.10-25.01.11г. (поле cover_end_date) был фикс по отмене переноса 0000004880 2. Исправить сбой при отображении информации по линии А04 (см. вложение) 3. Codefix: при сохранении изменений версии договора (версия договора - 2-я и более) должна быть проверка: "Дата выдачи полиса" (document_date) >= "Срок страхования с" (first_start_date) (таблица Policy) TIA-31523|In Progress|nazarovayy|2010-11-15 07:43:00|sapozhkovav|Изменения по VIP клиентам|Party_Client_data|Deploy|Improvement|Minor|||||||||||7398|В целях более полного отражения в системе TIA информации по ВИП клиентам Компании, прошу вас добавить в карточку Клиента в системе TIA следующие поля: - «персональный менеджер по заключению и сопровождению договоров страхования: Страхование имущества: Автострахование»; - «персональный менеджер по урегулированию убытков: Страхование имущества: Автострахование». Для ориентира направляю вам информацию о том, как эта задача реализована в 1С. TIA-31575|Closed|torlova|2010-11-24 08:10:00|zuyevva|*** Оптимизация запросов к yru_bso_departments_view и yru_bso_emp_view|BSO|Build|Bug|Trivial|||||||||||7769|в системе существует 2 нехороших запроса SELECT d.dep_id, d.dep_name, d.bso_rel, d.dep_center_code FROM yru_bso_departments_view d WHERE d.center_code = :1 AND d.bso_rel NOT IN ('DTYPO') AND (:2 IS NULL OR EXISTS (SELECT e.dep_id FROM yru_bso_emp_view e WHERE e.emp_id=:3 AND e.dep_id =d.dep_id )) ORDER BY dep_name; и SELECT d.dep_id, d.dep_name, d.bso_rel, d.dep_center_code FROM yru_bso_departments_view d WHERE d.center_code = :1 AND d.bso_rel NOT IN( 'DCOMP','DTYPO') AND (:2 IS NULL OR EXISTS (SELECT e.dep_id FROM yru_bso_emp_view e WHERE e.emp_id=:3 AND e.dep_id =d.dep_id )) ORDER BY dep_name; Предлагаю поменять эти запросы на SELECT d.dep_id, d.dep_name, d.bso_rel, d.dep_center_code FROM yru_bso_departments_view d, yru_bso_emp_view e WHERE d.center_code = :1 AND d.bso_rel NOT IN('DTYPO') AND :2 IS NOT NULL AND e.emp_id=:3 AND e.dep_id = d.dep_id union SELECT d.dep_id, d.dep_name, d.bso_rel, d.dep_center_code FROM yru_bso_departments_view d WHERE d.center_code = :1 AND d.bso_rel NOT IN( 'DTYPO') AND :2 IS NULL ORDER BY dep_name; и SELECT d.dep_id, d.dep_name, d.bso_rel, d.dep_center_code FROM yru_bso_departments_view d, yru_bso_emp_view e WHERE d.center_code = :1 AND d.bso_rel NOT IN('DCOMP','DTYPO') AND e.emp_id=:3 AND :2 IS NOT NULL AND e.dep_id = d.dep_id union all SELECT d.dep_id, d.dep_name, d.bso_rel, d.dep_center_code FROM yru_bso_departments_view d WHERE d.center_code = :1 AND d.bso_rel NOT IN( 'DCOMP','DTYPO') AND :2 IS NULL ORDER BY dep_name соответственно. Полностью не протестировано, возможно 'схлопывание' одинаковых строк в результатах запросов. TIA-31919|Resolved|nazarovayy|2011-02-03 15:54:21|truhovaea|Присвоить архивный номер полису АТС/5202/0151896 (P3834670)|Archive||Bug|Trivial|||||||||||0000008484|Для полиса АТС/5202/0151896 (P3834670) в форме F1190 указать: Архивный номер - 05-2011-000000233043 № акта передачи в архив - 4915593-2011-0004 Добавить договор в архивный акт 4915593-2011-0004 TIA-31880|Closed|nazarovayy|2011-01-31 13:01:49|kuschenkosv|Доработка модуля Агентские договоры/доверенности|Sales_Policy_administration||Improvement|Major|||||||||||00000008440|Нужно доработать функционал агентские договоры/доверенности следующим образом: Необходимо при расторжении или прекращении агентского договора закрывать все действующие группы КВ (форма 4666), которые относятся к данному договору, датой расторжения или прекращения. См. подробное описание во вложении TIA-31723|Closed|minasovpk|2010-12-21 14:21:00|sapozhkovav|Необходимо перевыставить проводки из ТИА в САП|Interfaces|Deploy|Bug|Minor|||||||||||8127|В САП обнаружено большое кол-во ошибочно загруженных проводок за второй и третий кварталы 2010 года. Необходимо убедиться в актуальности проводок в ТИА (проверить существование acc_item_no, дебит = кредиту, и отсутствие повторно выгруженных проводок по данным acc_item_no). По актуальным проводкам необходимо отправить контрагентов в САП и после повторно сформировать проводки и отправить их в САП. По перечисленным dimension10 необходимо удалить данные из всех необходимых таблиц. Важным моментом так же является указание даты проводки в открытом периоде. Файл с перечисленными DImension10 в приложении. Отдельно проверить следующие Dimension10 100000841551 TIA-31750|Closed|minasovpk|2010-12-28 14:20:27|sapozhkovav|Необходимо перевыставить платеж одной суммой по аг. отчету.|Acc_payments||Bug|Major|||||||||||8168, 8341, 8342|1. Агентский отчет № TIA-20101206-68820: - перевести статус платежа из 7 в 1 для каждой записи в отчёте класса 3 "КВ к выплате". - отменить у агентского отчёта состояние "подтверждён". 2. Агентские отчеты № TIA-20110119-74888 и TIA-20110119-74921: - отменить платёж в САП, статус для каждой записи в отчёте класса 3 "КВ к выплате" должен поменяться с 3 на 7. - перевести статус платежа из 7 в 1 для каждой записи в отчёте класса 3 "КВ к выплате". - отменить у агентского отчёта состояние "подтверждён". TIA-31821|Closed|minasovpk|2011-01-19 13:43:35|ykorupayev|Доработка формы S601|Acc_accounting||New Feature|Critical|||||||||||8296|1. Выровнить левые и правые границы полей в каждой половине окна. 2. По полю Payer_id сделать возможность поиска. 3. Вместо поля Trans_Date ввести поля: «Дата платежа: с» и «по» для поиска. 4. В блоке Accitems около каждой строки ввести поля Check для отметки каждой записи. 5. Ввести поле «выбрать все». 6. Кнопку «сопоставить» переименовать в «автосопоставление». 7. Кнопку «перенести» переименовать в «сопоставить». 8. Ввести кнопку «перенести» справа от поля Account_no блока Accheaderd. 9. При нажатии на кнопку «перенести» происходит безусловный перенос отмеченных записей на счёт, указанный в поле Account_no блока Accheaderd. a. Механизм переноса: создание записи класса «7», по старому счёту и создание записи на новом счёте согласно записи класса «5» или «3» на старом счёте. b. Ограничение: если для переноса отмечена запись класса «3», то её перенос возможен только логину «Admin», остальным предупреждающее сообщение. 10. Если отмечена только одна запись в блоке Accitemd, то поле Bso_no блока Accheaderd должно автоматически быть заполнено из поля Bso_no блока Accitemd. 11. Старый функционал не меняется. TIA-31896|Rejected|minasovpk|2011-02-02 15:01:13|truhovaea|CLONE - Отмена переноса задолженности|Acc_accounting||Bug|Major|||||||||||8387|Полис № 2491877. Удалить: - операции в таблице acc_item с acc_item_no: 2743441, 2743442, 2743445, 2743446. Сторнировать: - операции в таблице acc_item с acc_item_no: 2743439, 2743440, 2743443, 2743444. Восстановить баланс: - в операции с acc_item_no = 2462606 (18675,20 руб) - в операции с acc_item_no = 2462609 (720,00 руб) - в операции с acc_item_no = 2460934 (-12679,74 руб) - в операции с acc_item_no = 2460935 (-403,2 руб) TIA-31921|Resolved|nazarovayy|2011-02-04 10:44:12|kuschenkosv|УП_обязательность поля ИФА/5102|ProductsOther||Improvement|Trivial|||||||||||0000008507|Необходимо в линии IFA03 продукта ИФА/5102 сделать поле Общая площадь необязательным для заполнения. см. скриншот TIA-31926|Configuration|oosipova|2011-02-04 12:55:56|ykorupayev|УП_загрузка новых продуктов СХА|ProductsOther||New Feature|Major||||||||||||Необходимо загрузить новые продукты СХА. настройки во вложении TIA-31923|Open|minasovpk|2011-02-04 11:11:47|kuschenkosv|Добавление новой спецпрограммы|Sales_Policy_administration||New Feature|Critical|||||||||||8452|См. спецификацию в приложенном файле TIA-31922|Validate_fix|minasovpk|2011-02-04 11:07:23|kuschenkosv|Добавление новой спецпрограммы|Sales_Policy_administration||New Feature|Critical|||||||||||8460|См. спецификацию в приложенном файле TIA-31927|Open|minasovpk|2011-02-04 14:19:48|sapozhkovav|Исправление проводок по начислению|Acc_accounting||Bug|Critical|||||||||||8498|Необходимо исправить последствия отработки TIABATCH за 03.02.11. В таблице SSG_GL_ACC_ITEM_SOURCE в проводках по начислению (Item_class = 1) старое значение trans_date изменилось на 01.01.11. Выявить все таким образом искажённые проводки и исправить данные по состоянию на 02.02.11. Пример: договор № 2183234. TIA-31924|Open|minasovpk|2011-02-04 12:08:10|ykorupayev|Агентский отчёт|Acc_reporting||Improvement|Minor|||||||||||8234|В печатной форме агентского отчёта подпись "Мельникова И.В." заменить на "Ефремов С.И." TIA-31323|In Progress|nazarovayy|2010-10-15 15:33:00|kuschenkosv|Прошу зарегистрировать доработку ТИА для массовой пролонгации договоров.|Sales_Policy_administration|Deploy|Improvement|Minor|||||||||||7410|Прошу зарегистрировать доработку ТИА для массовой пролонгации договоров.Описание бизнес-требований во вложении. Работы будут выполняться группой разработчиков компании iTree TIA-31920|Resolved|nazarovayy|2011-02-03 15:59:07|truhovaea|Присвоить архивный номер полису ВВВ0550432637 (P3830470)|Archive||Bug|Trivial|||||||||||0000008489|Для полиса ВВВ0550432637 (P3830470) в форме F1190 указать: Архивный номер - 05-2011-000000236106 № акта передачи в архив - 276103-2011-0006 Добавить договор в архивный акт 276103-2011-0006 TIA-31855|Validate_fix|aandreev|2011-01-25 15:23:42|sapozhkovav|Доработка печати полисов ОСАГО|||Improvement|Major|||||||||||0000008152|Скорректировать печатную форму полиса ОСАГО TIA-31929|Open|oosipova|2011-02-04 17:24:22|kuschenkosv|УП_изменение настроек ИПА/5200|ProductsOSAGO||Improvement|Minor||||||||||||Необходимо изменить настройки продукта ИПА/5200 все изменения выделены красной заливкой во вложении JIRA-2|Open|aandreev|2011-02-04 19:01:34|admin|Педоставить доступ|||Task|Major||||||||||||Предоставить доступ в JIRA Бабутовскому М., Горбачевву М., Цымбалу В. TIA-31930|Configuration|nazarovayy|2011-02-04 18:45:17|jdmitrieva|MCK-697_Авторизация 238 - не должна срабатывать на авто|||Bug|Minor||||||||||||Код написан таким образом, что может сработать на авто продукты TIA-31928|Configuration|nazarovayy|2011-02-04 16:23:24|truhovaea|Присвоить архивный номер полису ВВВ0550433609 (P3841588)|Archive||Bug|Trivial|||||||||||0000008500|Для полиса ВВВ0550433609 (P3841588) в форме F1190 указать: Архивный номер - 05-2011-000000234017 № акта передачи в архив - 58912-2011-0009 Добавить договор в архивный акт 58912-2011-0009 TIA-31916|Validate_fix|minasovpk|2011-02-02 20:35:47|kuschenkosv|Добавление новой спецпрограммы|Sales_Policy_administration||New Feature|Critical|||||||||||8461|В настроечной таблице (INS_PROG_TYPE) необходимо создать новую программу «БПК» (Код «89»). Дата открытия 01.01.2011. Дата закрытия 31.12.2011. TIA-31799|Resolved|nazarovayy|2011-01-17 10:08:35|zuyevva|MCK-747_ИФА/5101 : добавить в классификатор значения|ProductsOther||New Feature|Minor|||||||||||8268|Название_классификатора Линия: "ИФА/5101 Имущество" Классификатор "Тип имущества" Добавить значения: 1) installation(Инженерное оборудование) 2) interior(Внутренняя отделка) TIA-31856|Closed|oosipova|2011-01-25 16:29:55|ykorupayev|УП_загрузка БСО по новым продуктам|BSO||Improvement|Minor||||||||||||Загрузить новые бланки, выложенные в папке J:\Мастер данные\БСО\продуктивная выгрузка БСО из 1С\3я итерация Разобраться с ошибками загрузки TIA-31925|Configuration|nazarovayy|2011-02-04 12:46:02|truhovaea|Исправить некорректное расторжение полиса ВВВ0167166369 (P3837580)|Sales_Policy_administration||Bug|Trivial|||||||||||0000008492|При расторжении 91 кодом полиса ВВВ0167166369 (P3837580) произошел сбой ПО. Полис в интрефейсе отображается как расторгнутый 91 кодом, БСО статус сменил верно. Но ввести полис вновь правильным образом система не позволяет. Поправить данные полиса в базе для исправления ситуации. TIA-31891|Resolved|nazarovayy|2011-02-01 13:58:40|jdmitrieva|MCK-751_Продукт ИФА. Ошибка при смене статуса полиса, находящегося в котировке|ProductsOther||Bug|Trivial|||||||||||0000008448|Полис ИФА/52020012785 (P3790231) находится в статусе Котировка. При попытке перевести его в другой статус выдается ошибка (см скриншот). Кнопка Изм полис - не активна. TIA-31914|Configuration|torlova|2011-02-02 18:48:00|zuyevva|Не работает режим запроса по номеру документа|BSO|Build|Improvement|Trivial|||||||||||0000008474|SELECT ROWID,blk.NEWEST,blk.BLANK_TYPE,blk.BLANK_SERIES,blk.FULL_NUMBER,blk.CENTER_CODE,blk.BSO_STATUS,blk.BSO_SUB_STATUS,blk.RSA_DEP_ID,blk.RSA_STATUS,blk.RSA_SUB_STATUS,blk.PRICE,blk.POLICY_NO,blk.BLANK_TIA_NO,blk.BSO_TRX_SEQ_NO,blk.DOC_TIA_NO,blk.OWNER_DEP_ID,blk.OWNER_EMP_ID,blk.CUST_NO,blk.IS_BLOCKED,blk.IS_SAP,blk.CONTRACT_ID,blk.FROM_DEP_ID,blk.FROM_EMP_ID,blk.TO_DEP_ID,blk.TO_EMP_ID,blk.PRODUCT_ID,blk.OLD_SIST_REF,blk.LOC_SIS_REF FROM yru_bso_blanks blk order by blank_type,blank_series,full_number,bso_trx_seq_no Как видно из sql предложения, серверу баз данных приходится полностью просмотреть все записи в таблице yru_bso_blanks, отсортировать их и выдать клиенту. TIA-31931|In Progress|torlova|2011-02-07 10:12:53|jdmitrieva|MCK-752_Невозможно указать правильный риск, невозможно закрыть оценку как ошибочную.|Claims|Deploy|Bug|Critical|||||||||||0000008473|MCK-752_У убытков, риск/субриск которых на форме 5610 отличается от риска/субриска на форме 5620, невозможно указать правильный риск, невозможно закрыть оценку как ошибочную (см скрин). Необходимо реализовать следующее: подстановку риска/субриска в зависимости от класса дела оставить,но добавить возможность исправления риска/субриска. TIA-31775|In Progress|torlova|2011-01-12 17:26:32|ykorupayev|доработка отчета "Остатки БСО-количественный и номерной по подразделениям"|BSO||Bug|Critical|||||||||||0000008233|доработка отчета "Остатки БСО-количественный и номерной по подразделениям" необходимо выводить остатки БСО по конкретному агенту без выбора ID Подразделения для всех бланков в статусе 002 P03: 283320 P04: 3752054, 61492 select * from yru_bso_blanks y where y.bso_status = '002' and y.bso_sub_status is null and to_emp_id = 61492 and y.newest = 'Y' или select * from yru_bso_blanks y where y.bso_status = '002' and y.bso_sub_status is not null and to_emp_id = 61492 and y.newest = 'Y' TIA-31805|Closed|minasovpk|2011-01-17 18:55:35|kuschenkosv|Исправление формы агентского отчёта|Acc_reporting||Bug|Minor|||||||||||8150|В представлении yru_com_report_items_view перед строкой UNION ALL необходимо добавить строку AND ai.account_no = ai8.account_no(+) В противном случае возможен результат, при котором в отчёте появляются лишние строки. Александр Семёнов. TIA-31737|In Progress|torlova|2010-12-27 15:40:06|truhovaea|Авторизация убытков (оценка на снижение)|Claims|Deploy|Bug|Critical|||||||||||0000008149|У сотрудника лимиты по кодам 50, 52, 53 соответственно 300 000, 250 000, 250 000. Оценка превышающая лимит таким образом не видна в авторизации, но зато видна отрицательная оценка на снижение. Проведя авторизацию по этой строке оценки одновременно сотрудник авторизует убыток свыше своей квоты. Авторизации по кодам 50, 52, 53 не должны возникать при снижении лимитов (т. е. при изменении суммы оценки на снижение (EX и RC) не должны заново выставляться авторизации по кодам 50, 52, 53). Возможны следующие варианты: 1. Изначальное формирование РЗУ (оценки). Оценка формируется первый раз. 2. Автоматическое восстановление оценки. Оценка формируется после переоткрытия убытка RO (После статуса CL) TIA-31899|Open|nazarovayy|2011-02-02 18:24:30|ykorupayev|Исправить премию в полисе перестрахования P3119904|Reinsurance||Bug|Trivial|||||||||||0000008373|В ТИА по договору Игнатова Анастасия Михайловна № АТС/5202/0085449, неправильно введена премия. Нужно 152 540,00 руб, а введено 126 240,00. Откатить бордеро № пакета 49261 в предыдущий статус (д.б. не принят), дата транзакции 21.12.10. Сторнировать проводки в бухгалтерию (сумма 126240руб), которые были сформированы по акцепту бордеро. Для контракта перестрахования №441 на форме F7520 указать 152 540,00 в полях Премия по договору (Net_premium_Contract, таблица Rei_Contract), Брутто (N04, таблица Rei_Contract_Reinsurer), Нетто (N06, таблица Rei_Contract_Reinsurer). Формируем бордеро вновь по этому полису и подтверждаем - формируем проводки, аналогичные сторнированным только на правильную сумму. TIA-31917|Closed|torlova|2011-02-03 10:40:44|kuschenkosv|Необходимо определить количество сторнированных и заново созданных заявок на выплату по ПВУ (76160000-7810000)|Claims_PVU|Build|New Feature|Minor|||||||||||0000008481|По убыткам ПВУ прямое урегулирование (риск 1, субриск 6) линия A11, необходимо отобрать все убытки, по которым есть 3 сматченная с 4. У ACC_ITEM_NO класса 3 поле REVERSED_TO_ACC_ITEM_NO будет не пусто и имеет значение равное ACC_ITEM_NO сторнирующей записи 4 класса (как пример убыток 710606) Выборка должна содержать: № БСО (CLA_COVER_VIEW.OBJECT_ID), сумма платежа (ACC_ITEM.CURRENCY_AMT), дата платежа (ACC_ITEM.TRANS_DATE), кредитор (ACC_ITEM.DIMENSION08) ID проводки в SAP (SSG_ACC_GL_ITEM_SOURCE.GL_ACCOUNT_CODE), номер убытка (ACC_ITEM.CLAIM_CASE_NO) SSG_ACC_GL_ITEM_SOURCE связь с ACC_ITEM по ACC_ITEM_NO TIA-31912|Open|torlova|2011-02-02 18:45:58|kuschenkosv|На промышленном сервере КЛАДР от 28.01.2011 года начнет действовать с 7 февраля 2011 года.|Claims_PVU|Build|Improvement|Trivial|||||||||||0000008471|Необходимо внести исправления в КЛАДР. На промышленном сервере КЛАДР от 28.01.2011 года начнет действовать с 7 февраля 2011 года. TIA-31840|Closed|oosipova|2011-01-21 18:28:13|jdmitrieva|УП_не формируется КВ по ДС и 2-ой линии продукта ИПА/5103|Acc_accounting||Sub-task|Major|||||||||||8343|Не сформировалось КВ 10% на доп.соглашение по продукту ИПА/5103 на среде TEST2 Так же не сформировалось кв по одной из линий... В общем отсутствует начисление по 1 линии и д/с. TIA-31831|Open|torlova|2011-01-20 15:47:46|kuschenkosv|Обновление документации АПК ИРЦ ОСАГО«АПК_ИРЦ_ОСАГО_Информационное_обеспечение» и «АПК_ИРЦ_ОСАГО_Форматы_сообщений»|Claims_PVU|Build|Improvement|Critical|||||||||||0000008318, 0000008470|Обновление документации АПК ИРЦ ОСАГО«АПК_ИРЦ_ОСАГО_ Информационное_обеспечение» и «АПК_ИРЦ_ОСАГО_Форматы_сообщений». Версия Сообщаем, что на тестовый сервер установлено обновление «Заявка по судебному решению»: 1. Добавлено необязательное поле «Судебное решение» в сообщение clam.001.001.01 («Заявка. Копия Заявки»). Расположение: clam.001.001.01/GENL/Hldng. Тип: Строка. 2. Добавлено необязательное поле «Sysref предыдущей заявки» в сообщение clam.001.001.01 («Заявка. Копия Заявки»). Расположение: clam.001.001.01/GENL/PrevClmRef. Тип: Строка. + Исправлено описание значения тега clam.001.001.01/GENL/Hldng TIA-31932|Open|minasovpk|2011-02-07 21:19:16|kuschenkosv|Добавление начисления КВ|Acc_accounting||Bug|Critical|||||||||||8251|Договор № 571709. - таблица acc_item: создать запись по начислению комиссии TRANS_DATE = текущая дата ITEM_CLASS = 3 ITEM_TEXT = Autocreated Commission Item, risk independent ACCOUNT_NO = 9394 AMT = -3949,05 AMT_BALANCE = -3949,05 policy_no = 571709 dimension08 = 282901 REVERSED_TO_ACC_ITEM_NO = (null) Остальные поля - как у acc_item_no = 299718. Или заполняются из процедуры. - таблица com_item: создать запись TRANS_DATE = текущая дата AGENT_NO = 282901 AGR_LINE_NO = 5075045 TRANS_ID = 114203 COM_AMT = 3949,05 premium_amt = 48510 acc_item_no = номер созданной выше записи в acc_item policy_no = 571709 Остальные поля - как у seq_no = 82218. Или заполняются из процедуры. - в акте TIA-282901-20091208-A0-6 в строке полиса № 571709 в результате должны появиться %КВ = 25% (форма FS461 поле real_comm_pct) и сумма КВ = 3949,05 (форма FS461 поле real_comm_amt). TIA-31233|Closed|torlova|2010-10-05 07:00:00|kuschenkosv|Неактивна форма FS506 во время просмотра документа по убытку|Claims|Deploy|Improvement|Minor|||||||||||7215|Неактивна форма FS506 во время просмотра документа по убытку, прошу исправить. Требуется перенос соответствующего функционала из FS505 TIA-31857|Open|nazarovayy|2011-01-26 15:20:27|jdmitrieva|MCK-748_ИФА/5101. Ограничить размер поля Год постройки|ProductsOther||Improvement|Trivial|||||||||||8388|Ограничить размер поля четырьмя знаками. TIA-31860|Closed|nazarovayy|2011-01-27 10:27:18|truhovaea|Присвоить архивный номер АТС/52020175501 (P3779173)|Archive||Bug|Trivial|||||||||||0000008402|Для полиса АТС/52020175501 (P3779173) в форме F1190 указать: Архивный номер - 05-2011-000000232313 № акта передачи в архив - 291439-2011-0038 Добавить договор в архивный акт 291439-2011-0038 TIA-30697|In Progress|minasovpk|2010-08-05 12:13:00|ykorupayev|Изменить печатную форму агентского отчета|Sales_Policy_administration|Deploy|Improvement|Minor|||||||||||6359|Доработки ТИА для ОПЕРУ: 3.Изменить печатную форму агентского отчета (в соответствии с приложенным файлом) TIA-31863|In Progress|nazarovayy|2011-01-27 13:47:43|ykorupayev|Доработка печатной формы полиса АВТО (поле Выгодоприобретатель)|Sales_Policy_administration||Improvement|Trivial|||||||||||0000008334, 0000008419|Доработать вывод на печать информации по Выгодоприобретателю, если ТС находится в залоге банка. Исправить форматирование текста на оборотной стороне полиса. Спецификация приложена. TIA-31866|Closed|nazarovayy|2011-01-27 14:51:32|truhovaea|Исправить срок страхования в полисе АТС/22021423200 (416088)|Sales_Policy_administration||Bug|Trivial|||||||||||0000008405|Исправить срок страхования в полисе АТС/22021423200 (416088) на " с 11.11.2009 по 10.11.2010" TIA-31867|Resolved|torlova|2011-01-27 17:27:32|ykorupayev|Доработка отчета "Остатки БСО-количественный и номерной по подразделениям"|BSO|Deploy|Bug|Minor|||||||||||0000008369|При построении отчета Остатки БСО - количественный и номерной по id 56960 Мариновой Е.В. и выборе вида бланка СГ Дачаа (ИФА/5102) появляется с некооректными данными. В отчете выгружаются номера 10-тизначные, а должны быть 7-значные. TIA-31876|Closed|minasovpk|2011-01-28 16:49:05|zuyevva|Удаление объекта в договоре|Sales_Policy_administration||Bug|Major|||||||||||8396|Договор № 3272095. Линия № 5325621. В таблице object удалить запись с object_no = 342697, seq_no = 445219. TIA-31858|Closed|nazarovayy|2011-01-26 15:27:35|sapozhkovav|Присвоить архивный номер полису АТС/52020209589 (ID 3755584)|Archive||Bug|Trivial|||||||||||0000008392|На форме F1190 для полиса АТС/52020209589 (ID 3755584) указать: Архивный номер - 05-2010-000000211082 № акта передачи в архив - 276103-2010-0167 Добавить полис в архивный акт 276103-2010-0167 TIA-31869|Closed|torlova|2011-01-27 17:51:55|zuyevva|Заказ № 000645-2011 выполнен, но бланки ИФА/5300 с 0806011 по 0806210 не созданы, дальнейшее создание документа Поступления невозможно|BSO|Deploy|Bug|Major|||||||||||0000008391|Заказ № 000645-2011 выполнен, но бланки ИФА/5300 с 0806011 по 0806210 не созданы, дальнейшее создание документа Поступления невозможно Необходимо по бланкам ИФА/5300 с 0806011 по 0806210 создать записи в yru_bso_blanks с bso_status = 001 TIA-31873|Closed|oosipova|2011-01-28 12:02:15|jdmitrieva|УП_изменение УГ в КАА|ProductsOther||Bug|Minor||||||||||||Необходимо изменить учетные группы и названии вида страхования в линии продуктов КАА/5105 и 5106, см. вложение, правильные значения выделены желтым цветом TIA-31872|Open|nazarovayy|2011-01-28 11:37:15|truhovaea|Отменить аннулирование Акта ПП TIA-2001063-20110117-A0-229|Sales_Policy_administration||Bug|Trivial|||||||||||0000008408|В форме Регистрация акта агента (FS461) для Акта TIA-2001063-20110117-A0-229 указать следующую информацию: поле Дата изменения акта установить значение 17.01.2011 поле Статус - Редактирование чек-бокс Аннулировать акт - снять отметку TIA-31870|Open|nazarovayy|2011-01-28 10:24:18|sapozhkovav|Доработка отображения действующих записей Агент/Куратор в форме FS461 (Акт ПП) и записей в форме F2011 (Связи)|Commisions||Improvement|Trivial|||||||||||0000008411|Доработать отображение записей при поиске Агента, Куратора в форме Регистраиция актов агента и записей в форме Связи. Спецификация приложена. TIA-31194|In Progress|nazarovayy|2010-09-30 10:19:00|zuyevva|CRL - Доработка для ОПЕРУ: Полисы без БСО|Sales_Policy_administration|Deploy|Improvement|Minor|||||||||||7089|При страховании парков машин оформляется генеральный договор, и каждая машина вводится как отдельный полис, а бланк на каждую машину выдается по пожеланию клиента. Когда клиент не желает получить полис на каждую машину, приходится заводить и использовать виртуальные бланки, что искажает учет BСО. спецификация во вложении TIA-31874|Closed|minasovpk|2011-01-28 15:13:04|truhovaea|Отмена переноса задолженности|Acc_accounting||Bug|Major|||||||||||8387|Полис № 2491877. Удалить: - операции в таблице acc_item с acc_item_no: 2743441, 2743442, 2743445, 2743446. Сторнировать: - операции в таблице acc_item с acc_item_no: 2743439, 2743440, 2743443, 2743444. Восстановить баланс: - в операции с acc_item_no = 2462606 (18675,20 руб) - в операции с acc_item_no = 2462609 (720,00 руб) - в операции с acc_item_no = 2460934 (-12679,74 руб) - в операции с acc_item_no = 2460935 (-403,2 руб) TIA-31875|Open|nazarovayy|2011-01-28 15:24:11|sapozhkovav|Оптимизация процесса поиска группы КВ Агента при вводе ручного КВ в форме F4660.|Sales_Policy_administration||Improvement|Trivial|||||||||||0000008415|Оптимизировать запрос поиска групп КВ агента в форме F4660 (поле Agent_N). Поиск информации по полю № Агента выполняется порядка 2 минут, должен отрабатывать макс 10 сек. TIA-31258|Validate_fix|torlova|2010-10-07 09:27:00|kuschenkosv|Разработать форму выгрузки реестра по убыткам|Claims|Deploy|Improvement|Minor|||||||||||4700|Спецификация во вложении. TIA-31663|In Progress|minasovpk|2010-12-09 08:07:00|sapozhkovav|***Необходимо реализовать в ТИА проводку по сторнированию проводки Начисление расхода по регрессному иску|Acc_accounting|Deploy|Bug|Minor|||||||||||7973|Необходимо реализовать в ТИА проводку по сторнированию проводки Начисление расхода по регрессному иску TK-2|In Progress|torlova|2010-12-13 10:57:00|aandreev|Исправление классификаторов в форме КАСКО.||Build|Bug|Trivial|||||||||||8077|Исправление классификаторов в форме КАСКО. TIA-31511|In Progress|nazarovayy|2010-11-13 07:36:00|kuschenkosv|CR 7293 Автоматический расчет КБМ при пролонгации договора|ProductsOSAGO|Deploy|Improvement|Minor|||||||||||7293|Необходимо реализовать функционал согласно приложенной спецификации TIA-31542|In Progress|nazarovayy|2010-11-17 12:54:00|lsproge|исправление функционала Возобновления договора|Sales_Policy_administration|Deploy|Bug|Trivial|||||||||||7737|исправление функционала Возобновления договора. 1. Необходимо при возобновлении договора, в котором Тип вступления в силу указан После полной оплаты, менять на тип Сразу 2. Не работает функционал подтягивания данных по агенту и пр. при указании БСО вручную. TK-1|In Progress|gornovpk|2010-11-18 09:50:00|aandreev|Разработка тарифного калькулятора||Deploy|Improvement|Major|||||||||||7835|Разработка тарифного калькулятора согласно спецификации TIA-31601|Validate_fix|torlova|2010-11-26 14:42:00|kuschenkosv|*** Исправление ошибок в работе батча ПВУ|Interfaces|Build|Bug|Minor|||||||||||7919|Исправление ошибок в работе батча ПВУ + за 2 декабря (не принята заявка, отв. водитель Деревянко Александр Николаевич, страна UKR, КЛАДР 0000000000000) - ssg_dch_imp.seq_no = 915397 TIA-31606|Resolved|torlova|2010-11-29 12:37:00|kuschenkosv|Изменить тип платежа по умолчанию на Bank_out в форме f5700|Claims|Deploy|Improvement|Minor|||||||||||6961|спецификация во вложении TIA-31624|Closed|kuschenkosv|2010-12-01 15:09:00|kuschenkosv|*** Рост trace_text|Technical|Build|Bug|Minor|||||||||||7968|Вы, таки будете смеяться, но trace_text опять начал расти, пусть и не теми дикими темпами что раньше. 'TRACE_NAME' 'COUNT(1)' 'BSOUPDST26112010' 1417152 TIA-31709|In Progress|torlova|2010-12-20 09:16:00|truhovaea|Субдело 1562 не отображается в интерфейсе.|Claims|Deploy|Bug|Minor|||||||||||8121|субдело 1562 не отображается в интерфейсе select * from CLA_SUBCASE csc where csc.cla_case_no = '2343'; Дело в третьем лице, если его очистить, то все отображается. НО нужно таки разобраться как это должно работать.