| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Alex2019
Профи
Вступление в Клуб: 02.07.2007
|
 Вт Дек 15, 2009 16:10 |
 |
Полезность: Нет оценки
|
Дима, приведенная цитата из доки по какому-то конкретному продукту? Потому как в доке 1-06-1 сказано | Цитата: | | Признак "Проводить документы по одному" – определяет технологию проводки папки документов. Если данный признак установлен, то каждый документ папки будет проводиться отдельно, т.е. отправка на проводку любого документа папки приводит только к проводке данного документа, проводка папки платежей не выполняется. При ликвидации документа из папки, которой установлен признак "Проводить документы по одному", состояние папки не изменится. Ликвидирован будет только один документ. В случае работы с финансовыми распоряжениями, перевод их в состояние "Исполнено" после проводки всех документов папки выполняется операцией "На проводку". |
Без уточнения, что под понятием "документ" понимаются только платежные. Приведенные в Вашей цитате ограничения достаточно неприятны, поскольку различные документы, порожденные ФР, зачастую должны обрабатываться (проводиться) различными подразделениями независимо. Подобная проблема была содержанием заявки BS00105235 от 12.05.2009 (!), в частности, о переходе ФР в таких папках в состояние "Исполнено" после проводки всех плат.док-тов, но она пока не решена |
|
 |
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Вт Дек 15, 2009 16:19 |
|
Полезность: Нет оценки
|
| Alex2019 пишет: | | Дима, приведенная цитата из доки по какому-то конкретному продукту? |
Моя цитата - из кредитов "Глава_6-08_(Работа_с_финансовыми_распоряжениями_и_платежными_документами).chm" версии 9.5
раздел "Виды финансовых распоряжений".
Видимо, постепенно внедряется механизм проводки документов внутри кредитных ФР "по-одному", о котором и была заявка BS00105235. Только в документации по кредитной подсистеме пока такая технология не описана.
Может она уже и работала у нас вчера?  Нашим кредитчикам не понравилась. Заставили вернуть все взад. |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Вт Дек 15, 2009 16:33 |
|
Полезность: Нет оценки
|
Зарегистрировал
| Цитата: | При формировании нового сообщения в справочнике "Противодействие легализации. Архив подозрительных операций" появляется следующее сообщение: "Предупреждение: Банки, участвующие в операции, должны быть действующие. Проверте поле "BIK_B0"
Это возникает, например, при вводе БИК 044030791 или CHASUS33XXX.
В справочниках банков банки с такими кодами присутствуют в нескольких экземплярах, среди которых есть действующие и закрытые. Несмотря на это, проверка находит первый попавшийся банк и ругается, если он закрыт. Т.е. отсутствует приоритет выборки действующих банков.
Прошу "Проверте" заменить на "ПроверЬте".
Прошу внести корректировки в алгоритм поиска ссылки на банк по БИК. |
У нас ответственный сотрудник очень пугается таких сообщений, поэтому пришлось поправить LEGAL_161P.LIB_FUNCS:
| Код: | --locate b1 in ::[CL_BANK_N] where p_bic in (b1.[BIC],b1.[SWIFT_C]);
locate b1 in ::[CL_BANK_N] where p_bic in (b1.[BIC],b1.[SWIFT_C]) order by b1.[ACTIVE] desc;
...
--locate b2 in ::[CL_BANK_F] where p_bic = b2.[SWIFT_C];
locate b2 in ::[CL_BANK_F] where p_bic = b2.[SWIFT_C] order by b2.[DATE_CL] desc;
|
|
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Вт Дек 15, 2009 16:35 |
|
Полезность: Нет оценки
|
Зарегал:
| Цитата: | При формировании некоторых безналичных платежных документов (при копировании и при создании нового) появляется ошибка: "Указанный КПП не найден в массиве Дополнительных КПП плательщика". Плательщиком в этих документах является сам банк, а вот КПП задается не тот, что введен в досье национального банка, а другой.
Получается, что для банка необходимо заполнить ввод дополнительных КПП, как и по ЮЛ, но такая возможность в дистрибутиве мною не найдена.
Прошу описать, как можно заполнить массив КПП по нац.банку имеющимся функционалом, либо доработать имеющийся функционал. |
Пришлось массив дополнительных КПП вынести в представление и занести туда нужные КПП. |
|
|
Alex2019
Профи
Вступление в Клуб: 02.07.2007
|
| Вт Дек 15, 2009 16:50 |
|
Полезность: Нет оценки
|
| timochev пишет: | | Видимо, постепенно внедряется механизм проводки документов внутри кредитных ФР "по-одному", о котором и была заявка BS00105235. |
Нет, эта заявка несколько о другом, и непосредственного отношения к кредитам не имеет.
| timochev пишет: | | Может она уже и работала у нас вчера? Нашим кредитчикам не понравилась. Заставили вернуть все взад. |
Вряд ли, нормальная работа и на 9.6 не реализована, хотя какие-то изменения вполне могли закрасться  А вообще-то в тех б/о, где все документы одрабатываются одним подразделением, крыж "проводить по одному" большого смысла ИМХО не имеет. Только там, где надо |
|
|
belousov_aa
Участник
Вступление в Клуб: 26.11.2009
|
| Ср Дек 16, 2009 10:48 Задваивание данных в ФОР значения в тысячах |
|
Полезность: Нет оценки
|
Есть ли у кого проблемы с задваиванием данных в тысячах в ФОР в приложении 2 и 5
1. Приложение 2. Задвоились значения по счетам на 01.11.2009 и на 01.12.2009:сч.: 40807, 40817, 40820, 42301, 42303, 42304 и др.
(однако сч.: 42605, 42606 - значения по счетам не задвоились).
2. Приложение 5. Задвоились значения по счетам на 01.11.2009 и на 01.12.2009:сч.: 20202, 20208. (однако сч.: 20207 - значения по счету не задвоились).
P.s. Был прислан из ЦФТ вроде как последний накат по ФОР |
|
|
korneev
Профи
Вступление в Клуб: 02.07.2007
|
| Ср Дек 16, 2009 11:01 Депозиты ф.л. Капитализация %% |
|
Полезность: Нет оценки
|
При капитализации %% по договору (Alt-C), у которого отсутствует счет для учета процентов 47411 возникает ошибка:
************************************
ORA-20300: APP-DEPN.CAP_PRC: Не открыт счет учета %%
ORA-06512: at "IBS.Z$DEPN_CAP_PRC", line 789
************************************
Дело в том, что по этому договору счет и не нужен, т.к. капитализация происходит ежемесячно в последний день месяца (Д 70606 - К 423..).
На 9.3 все нормально работало!
Сейчас в коде появилась проверка, которая описана в документации: "При капитализации процентов проверяется наличие открытого счета учета процентов". Причины появления такой проверки в операции капитализации непонятны.
ЦФТ-шники пообещали исправить в будущих версиях. Поэтому можно смело закомментировть в [DEPN].[CAP_PRC] вот так:
/* 15.12.2009 Корнеев BS00124148 KOB: после перехода на 9.5
выдавал сообщение: "Не открыт счет учета %%", даже по тем договорам, где счет 47411 не должен быть открыт
if nvl(P_SUMMA_NOT_REG,0) + nvl(P_SUMMA_REG,0) > 0 then
-- проверим/откроем счет учета (может быть не открыт
-- если учеты не делались и открытие счета учета только по необходимости)
&debug('проверим счет учета процентов',0)
if [GET_ACC_WITH_OP]('TRM_INTS_LBS_ACC', P_DATE_VAL, null, P_PROV) is null then
pragma error('Не открыт счет учета %% '||TRM_INTS_LBS_ACC);
end if;
end if;
*/ |
|
|
belousov_aa
Участник
Вступление в Клуб: 26.11.2009
|
| Ср Дек 16, 2009 11:20 Re: Депозиты ф.л. Капитализация %% |
|
Полезность: 1
|
| korneev пишет: | При капитализации %% по договору (Alt-C), у которого отсутствует счет для учета процентов 47411 возникает ошибка:
************************************
ORA-20300: APP-DEPN.CAP_PRC: Не открыт счет учета %%
ORA-06512: at "IBS.Z$DEPN_CAP_PRC", line 789
************************************
/* 15.12.2009 Корнеев BS00124148 KOB: после перехода на 9.5
выдавал сообщение: "Не открыт счет учета %%", даже по тем договорам, где счет 47411 не должен быть открыт
if nvl(P_SUMMA_NOT_REG,0) + nvl(P_SUMMA_REG,0) > 0 then
-- проверим/откроем счет учета (может быть не открыт
-- если учеты не делались и открытие счета учета только по необходимости)
&debug('проверим счет учета процентов',0)
if [GET_ACC_WITH_OP]('TRM_INTS_LBS_ACC', P_DATE_VAL, null, P_PROV) is null then
pragma error('Не открыт счет учета %% '||TRM_INTS_LBS_ACC);
end if;
end if;
*/ |
Предлагаю закомментировать только if /*nvl(P_SUMMA_NOT_REG,0) +*/ nvl(P_SUMMA_REG,0) > 0 then
этого я думаю будет достаточно |
|
|
belousov_aa
Участник
Вступление в Клуб: 26.11.2009
|
| Ср Дек 16, 2009 11:59 По задваиванию в ФОР |
|
Полезность: Нет оценки
|
если убрать крыж "Расчет на основе формы 101" - то данные не задваиваются  |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Ср Дек 16, 2009 12:44 Re: По задваиванию в ФОР |
|
Полезность: Нет оценки
|
| belousov_aa пишет: | | если убрать крыж "Расчет на основе формы 101" - то данные не задваиваются |
Саша, привет! Рад, что ты присоединился к нашему клубу!
А мы рассчитываем без этой галочки. Задваивание не замечено. |
|
|
Ghost
Профи
Вступление в Клуб: 24.11.2007
|
| Пн Дек 21, 2009 09:23 Кредиты. Плановые операции. Изменить. |
|
Полезность: Нет оценки
|
| Какой-то "специалист" закоментировал пересчет плана в операции "Изменить" в плановых графиках. Сказал много "добрых" слов в адрес этого "умника", пока искал почему план после изменения не пересчитывается... |
|
|
belousov_aa
Участник
Вступление в Клуб: 26.11.2009
|
| Пн Дек 21, 2009 11:19 расчет по форме 401 |
|
Полезность: Нет оценки
|
После перехода на 9.5 стали по иностранным валютам считаться в 10 раз больше данные, по рублям все ОК  |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Пн Дек 21, 2009 11:26 |
|
Полезность: Нет оценки
|
а у нас расчет архива баланса почти в 2 раза дольше стал считаться.
сижу трейсы сравниваю |
|
|
belousov_aa
Участник
Вступление в Клуб: 26.11.2009
|
| Пн Дек 21, 2009 11:39 по расчету формы 401 |
|
Полезность: Нет оценки
|
| Я имею в виду что сами данные удесятеряются по валютам, т.е. один и тот же валютные счет почему-то 10 раз считается. Вот что странно. На 9.3 было все ОК. |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Пн Дек 21, 2009 12:46 |
|
Полезность: 1
|
| timochev пишет: | а у нас расчет архива баланса почти в 2 раза дольше стал считаться.
сижу трейсы сравниваю |
В новой реализации PL_ARC_USV.USV_ARC_SALDO в курсорах cur_template, cur_dep, cur_all по [AC_FIN] была вставлена конструкция
| Код: | and (not depoz or GET_CHAPTERV(ac.[MAIN_USV])<>::[CHAPTERS]([CHAPTER]='Д'))
|
В результате при выборке каждого(!) финансового счета (в т.ч. и закрытого) вызывается функция GET_CHAPTERV. Если закомментировать эти новые строки, то все возвращается в прежнее русло.
В функциях (их там две) реализовано многоступенчатое разыменование, что порождает простейшие запросы по primary key вида
| Код: | SELECT C_CHAPTER
FROM
Z#NEW_RASD WHERE ID=:B1
|
Такие запросы вызываются столько раз, сколько счетов в базе!
Буду писать в Службу Сопровождения. И ведь даже несоответствие не могу формально зарегистрировать. Только заявку на развитие.
СЗОТ Вот оно - качество Системы за млн. у.е. |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
