Переход на версию 8.6 (IBSO и RBO)
На страницу Пред. 1, 2, 3
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
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. Для этого написал там
|
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Ср Ноя 26, 2008 16:30 Re: Переадресация в РЦ удаляет и не пересоздает комиссию |
|
Полезность: 1
|
| timochev пишет: | Переадресация в РЦ удаляет и не пересоздает комиссию.
Имеем документ Дт 40702 Кт 30102. В тарифном плане договора РКО настроена комиссия с признаками "формировать документ", "комиссия за безналичный документ", "момент удержания комиссии при проводке", "Не объединять". Когда документ РЦ доходит до 10-го статуса, то успешно формируется документ комиссии. Далее сотрудник РЦ вызывает операцию над документом РЦ "Переадресовать" и выбирает другого участника. В результате комиссия удаляется (в момент ликвидации платежного документа). И она не появляется вновь в момент проводки.
Проблема в операции DOCUMENT.DEL_COMISS. Там появился новый анализ, который видимо не совсем протестирован. На свой страх и риск вернул старый алгоритм работы в локальной функции del_doc_com. Для этого написал там
|
Оказывается, в голом дистрибутиве все работает нормально. Проблема была из-за локальной дорабботки, которая считала, что для комиссий с формированием документа не может быть записи в массиве "операции договора" без ссылки на порожденный документ. Оказывается в 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; |
|
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
