CftClub.ru
Клуб специалистов ЦФТ-Банк

Переход на версию 8.6 (IBSO и RBO)
На страницу Пред.  1, 2, 3
 
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Обновления и тестирование
Предыдущая тема :: Следующая тема  
Автор Сообщение
Alex
Участник со стажем


Вступление в Клуб: 06.07.2007
СообщениеПт Ноя 21, 2008 09:24    Ответить с цитатой
Полезность: Нет оценки
Дмитрий, спасибо огромное - очень помогли!
timochev
Эксперт


Вступление в Клуб: 02.07.2007
СообщениеПн Ноя 24, 2008 09:19   Переадресация в РЦ удаляет и не пересоздает комиссию Ответить с цитатой
Полезность: Нет оценки
Переадресация в РЦ удаляет и не пересоздает комиссию.
Имеем документ Дт 40702 Кт 30102. В тарифном плане договора РКО настроена комиссия с признаками "формировать документ", "комиссия за безналичный документ", "момент удержания комиссии при проводке", "Не объединять". Когда документ РЦ доходит до 10-го статуса, то успешно формируется документ комиссии. Далее сотрудник РЦ вызывает операцию над документом РЦ "Переадресовать" и выбирает другого участника. В результате комиссия удаляется (в момент ликвидации платежного документа). И она не появляется вновь в момент проводки.
Проблема в операции DOCUMENT.DEL_COMISS. Там появился новый анализ, который видимо не совсем протестирован. На свой страх и риск вернул старый алгоритм работы в локальной функции del_doc_com. Для этого написал там
Код:
p_del_com := true;
timochev
Эксперт


Вступление в Клуб: 02.07.2007
СообщениеСр Ноя 26, 2008 16:30   Re: Переадресация в РЦ удаляет и не пересоздает комиссию Ответить с цитатой
Полезность: 1
timochev пишет:
Переадресация в РЦ удаляет и не пересоздает комиссию.
Имеем документ Дт 40702 Кт 30102. В тарифном плане договора РКО настроена комиссия с признаками "формировать документ", "комиссия за безналичный документ", "момент удержания комиссии при проводке", "Не объединять". Когда документ РЦ доходит до 10-го статуса, то успешно формируется документ комиссии. Далее сотрудник РЦ вызывает операцию над документом РЦ "Переадресовать" и выбирает другого участника. В результате комиссия удаляется (в момент ликвидации платежного документа). И она не появляется вновь в момент проводки.
Проблема в операции DOCUMENT.DEL_COMISS. Там появился новый анализ, который видимо не совсем протестирован. На свой страх и риск вернул старый алгоритм работы в локальной функции del_doc_com. Для этого написал там
Код:
p_del_com := true;

Оказывается, в голом дистрибутиве все работает нормально. Проблема была из-за локальной дорабботки, которая считала, что для комиссий с формированием документа не может быть записи в массиве "операции договора" без ссылки на порожденный документ. Оказывается в 8.6 такое может случаться в момент проводки первичного документа.

Таким образом, возвращаем дистрибутивный вариант обратно. Будем менять локальные настройки.
timochev
Эксперт


Вступление в Клуб: 02.07.2007
СообщениеПн Дек 01, 2008 13:54    Ответить с цитатой
Полезность: 2
Зарегал кучу заявок по депозитам ФЛ
Кое-что уже на форуме упоминалось, но не все.

Цитата:
Операция "Изменить" в справочнике "Виды депозитных договоров" искажает реальность и меняет настройки.
У нас настроенывиды деаозитов с признаком "Причислять проценты ко вкладу" = FALSE. При просмотре настроек в экранной форме галочка стоит независимо от
значения в БД!!! В коде секции Проверка присутствует код:
P_PRC_BY_ACCOUNT := true;
Причем если нажать ОК, то неверное значение настройки перезаписывается.

Цитата:
При редактировании депозита искажается значение "Причислять %%". По договорам установлено значение соответствующего реквизита PRC_TO_ACCOUNT. В
базе имеем значение NULL, а при вызове операции "Изменить депозитный договор" видим "ДА", а не "ПУСТО". Более того у вида договора настроено "НЕТ". Таким
образом вообще непонятно, откуда взялось значение "ДА".
Если открыть операцию и нажать ОК, не внося изменений, то реквизит меняется в базе

Цитата:
Про признаки "Выплачивать %%" и "Причислять %%" в документации написано:
"По умолчанию значение определяется с вида депозитного договора".
Это утверждение целиком соблюдается для первого признака - когда вызывается операция "Добавить депозитный договор" сначала значение параметра NULL, после
выбора вида договора считывается настройка вида договора.
Для параметра "Причислять %%" почему-то сначала значение ДА и оно не меняется при выборе вида депозита!!!

Цитата:
Странное считывание значения "Выплачивать %%" из вида договора в операции "Добавить депозитный договор".
В документации написано: "По умолчанию значение определяется с вида депозитного договора".
Если в виде депозитного договора стоит TRUE, то параметр устанавливает в ДА. Это логично. Если в виде договора стоит FALSE, то параметр устанавливается в
ПУСТО, что нелогично.

Цитата:
В коде операций NEW#AUTO и EDIT#AUTO присутствует анализ вида:
V_PAY_ADD_PRC.[0] <> 2.
Под это условие попадают значения 1 и 3, что соответствует ПУСТО и НЕТ. Согласно документации: "если установлено Пусто, то значение анализирует настройку
в Виде депозитного договора". В виде договора могут быть два значения настройки ДА или НЕТ. Таким образом, видно, что Вы эти значения не различаете, т.е.
не анализируете, что не соответствует документации. Прошу исправить.

Цитата:
В операции "Изменить депозитный договор" имеем параметр "Выплачивать %%". Если этот параметр установлен в ДА, то есть возможность задать счет
для зачисления процентов. Это логично. Если параметр = НЕТ, то фрейм становится недоступным. Это тоже логично. Но при значении параметра ПУСТО, счет тоже
недоступен. Причем это не зависит от настройки вида договора. Куда в таком случае вводить счет? При выполнении операции капитализации в этом случае
выдается ошибка, несмотря на то, что документация допускает установку параметра в значение ПУСТО.

Цитата:
У работающих (подписанных) договоров в операции "Изменить депозитный договор" недоступны для изменения многие реквизиты. Например, "Запрещены
пополнения", "Запрещены снятия", "%% ставка" и др.
В то же время реквизиты "Причислять %%" и "Выплачивать %%" в настоящее время доступны.
Объясните, пожалуйста, идеологию этого факта?
Нельзя ли заблокировать изменение этих реквизитов у работающих договоров в дистрибутивной версии? Думаю, что каждый банк подпишется под тем, что вид
договора уже подразумевает определенный способ капитализации процентов.
timochev
Эксперт


Вступление в Клуб: 02.07.2007
СообщениеПт Дек 05, 2008 08:49   Резервирование 283-П Ответить с цитатой
Полезность: 2
В продукте "Резервирование" неправильно определяется группа риска по счету 47423 (учет требований к клиенту по документам комиссий в картотеке) в случае, когда резервирование выполняется вчерашней датой, а операционист в сегодняшнем ОД отозвал комиссию с К2, поставленную туда более 30 дней назад. Счет начинает обрабатываться как "без просрочки".
Это следствие условий в RES_PORT.LIB.group_and_percentage:
Код:
and a2.[DOC_IN_CARD]%state in ('PAY', 'TO_KART')

Здесь не учтено состояние ISNULL
Поправил так:
Код:
and a2.[DOC_IN_CARD]%state in ('PAY', 'TO_KART', 'ISNULL')
Kozyrev
Участник - экстремал


Вступление в Клуб: 03.09.2007
СообщениеПт Дек 26, 2008 12:59   Re: генерируется кривой Адрес строкой Ответить с цитатой
Полезность: Нет оценки
timochev пишет:
Мною зарегистрирована заявка:
Цитата:
При редактировании адресов ФЛ операцией "CL_PRIV.EDIT#AUTO" генерируется кривой Адрес строкой. Это происходит при удалении улицы, ее выборе из справочника заново, при очистке ссылки на нас. пункт и его выборе заново. В результате добавляется несколько раз один и тот же кусок. Например, название города, или весь адреса.
Вот пример того, что получается:
"РОССИЯ,190000,г Санкт-Петербург,,г Санкт-Петербург,РОССИЯ,190000,г Санкт-Петербург,,г Санкт-Петербург,пр-кт Дачный,,корпус 2,кв. 85,,корпус 2,кв. 85"
Прошу срочно исправить и выслать хранилище, т.к. неверные адреса сохраняются в базе.

До устранения проблемы ЦФТ предложило перекрыть хук HOOK GET_PRINT_ADDR_1

timochev, подскажите, пожалуйста, как нужно поправить хук чтобы все работало как надо?
timochev
Эксперт


Вступление в Клуб: 02.07.2007
СообщениеПт Дек 26, 2008 13:27   Re: генерируется кривой Адрес строкой Ответить с цитатой
Полезность: Нет оценки
Kozyrev пишет:
timochev пишет:
Мною зарегистрирована заявка:
Цитата:
При редактировании адресов ФЛ операцией "CL_PRIV.EDIT#AUTO" генерируется кривой Адрес строкой. Это происходит при удалении улицы, ее выборе из справочника заново, при очистке ссылки на нас. пункт и его выборе заново. В результате добавляется несколько раз один и тот же кусок. Например, название города, или весь адреса.
Вот пример того, что получается:
"РОССИЯ,190000,г Санкт-Петербург,,г Санкт-Петербург,РОССИЯ,190000,г Санкт-Петербург,,г Санкт-Петербург,пр-кт Дачный,,корпус 2,кв. 85,,корпус 2,кв. 85"
Прошу срочно исправить и выслать хранилище, т.к. неверные адреса сохраняются в базе.

До устранения проблемы ЦФТ предложило перекрыть хук HOOK GET_PRINT_ADDR_1



timochev, подскажите, пожалуйста, как нужно поправить хук чтобы все работало как надо?

Перекрыть пустым хуком
Код:
begin
   -- ЦФТ предложило до момента устранения ошибки перекрыть этот хук.
   -- Я закомментировал этот кусок, а не создавал наш хук, чтобы посмотреть на решение ЦФТ - можно оно будет полезным
   --AddressAsString := ::[PERSONAL_ADDRESS].[LIB].Addr_Struct_To_Str(P_ADDR, 'COUNTRY,ZIP,REGION,DISTRICT,CITY,STREET,HOUSE,KORPUS,FLAT',',');
   --return substr(AddressAsString,1,250);
   return null;
end;
Показать сообщения:   
Ответить на тему    Клуб специалистов ЦФТ-Банк (IBSO) -> Обновления и тестирование Часовой пояс: GMT + 3
На страницу Пред.  1, 2, 3
Страница 3 из 3

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Рейтинг@Mail.ru