Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
Васильев Николай Профи
Вступление в Клуб: 29.06.2007
|
Чт Дек 18, 2008 10:45 |
|
Полезность: Нет оценки
|
Алексей туда щас и напишет по нашим проблемам |
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Пт Дек 19, 2008 14:37 |
|
Полезность: Нет оценки
|
Оказывается в кредитах не работает групповое урегулирование резерва. ЦФТ сей факт уже известен. На следующей неделе планируется выпуск очередного дополнения. |
|
 |
Alexsey Эксперт
Вступление в Клуб: 06.09.2007
|
Вт Дек 23, 2008 07:09 |
|
Полезность: Нет оценки
|
После перехода на 8,7 поимели томоз в представлениях типа MAIN_DOCUM... кто нибудь сталкивался с таким? _________________ всегда есть как минимум 2 выхода |
|
 |
Васильев Николай Профи
Вступление в Клуб: 29.06.2007
|
Вт Дек 23, 2008 08:07 |
|
Полезность: Нет оценки
|
Самое первое - собрать статистику! И никогда не забывать об этом!
Но у нас однажды слетел индекс на MAIN_DOCUM-было.
Посмотри план выполнения , например , список документов |
|
 |
Alexsey Эксперт
Вступление в Клуб: 06.09.2007
|
Вт Дек 23, 2008 08:24 |
|
Полезность: Нет оценки
|
Статистику собрали... а вот план выполнения не оптимальный.. заявка в ЦФТ _________________ всегда есть как минимум 2 выхода |
|
 |
Alexsey Эксперт
Вступление в Клуб: 06.09.2007
|
Вт Дек 23, 2008 08:45 |
|
Полезность: Нет оценки
|
Выяснили...
ЦФТ ввело ограничения на выборки по представлениям по датам..
теперь поле дата документа и дата проводки обязательны к дополнению.. и если эти поля не заполнять фильтр не применяется...
осталось не ясным как быть с не проведенными документами у которых дата создания отличается от даты документа _________________ всегда есть как минимум 2 выхода |
|
 |
Васильев Николай Профи
Вступление в Клуб: 29.06.2007
|
Вт Дек 23, 2008 11:14 |
|
Полезность: Нет оценки
|
У нас после перехода на 8,7 замедления не обнаружено, работаем как обычно. Посему вроде как то не вяжется с датами. Но...
Попробовал, ставлю фильтр по счету дебета(список документов)- фильтр прекрасно отрабатывает. Правда , было бы абсолютно логично ввести такое ограничение в случае НЕИСПОЛЬЗОВАНИЯ индексов совсем при запросе. |
|
 |
Alexsey Эксперт
Вступление в Клуб: 06.09.2007
|
Вт Дек 23, 2008 11:18 |
|
Полезность: Нет оценки
|
нам дали ответ официально в ЦФТ... счас боремся с замедлением _________________ всегда есть как минимум 2 выхода |
|
 |
InNesKA Участник со стажем
Вступление в Клуб: 05.06.2008
|
Пн Дек 29, 2008 06:32 |
|
Полезность: Нет оценки
|
timochev пишет: | Оказывается в кредитах не работает групповое урегулирование резерва. ЦФТ сей факт уже известен. На следующей неделе планируется выпуск очередного дополнения. |
Не подскажите данное дополнение вышло!?  |
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Пн Дек 29, 2008 09:57 |
|
Полезность: Нет оценки
|
InNesKA пишет: | timochev пишет: | Оказывается в кредитах не работает групповое урегулирование резерва. ЦФТ сей факт уже известен. На следующей неделе планируется выпуск очередного дополнения. |
Не подскажите данное дополнение вышло!?  |
Нет, не вышло. Говорят, будет завтра - 30 декабря. |
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Пн Дек 29, 2008 14:37 |
|
Полезность: 2
|
Зарегал по дополнению 8.7.15
Цитата: | ф.102. Расчет ругается на настройку С0:
******************************
ВНИМАНИЕ! Не найдена вспомогательная настройка в справочнике настроек с кодом "С0" на дату 22/12/2008
(либо не заведен аналитический признак)
******************************
Настройка имеется, аналитические признаки заданы!
Программист в запросе соединил в F_102_DATA.SLIB несовместимые условия:
and (t.[CODE] = 'С0' and P_CALC_BS = 1)
and (t.[CODE] = 'С1' and P_CALC_BS = 2)
Дамы и господа, такой запрос всегда дает NO_DATA_FOUND.
Интересно, как такое могло нормально сработать при тестировании? |
|
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Пн Дек 29, 2008 15:16 |
|
Полезность: 2
|
Зарегал еще. Видать конвертилка в ф.102 кривая.
Цитата: | ф.102. При печати отчета за декабрь, расчитанного после установки 8.7.15, получается ошибка:
************************************
ORA-20300: APP-INTEGR_FORMS.F_102: ВНИМАНИЕ! На итоговую настройку с кодом Р28 (id=815303882) ссылается более 1 настройки [2]
Необходимо внести изменения в справочник настроек отчета (F_102_TUNING)
ORA-06512: at "IBS.MESSAGE", line 24
ORA-06512: at "IBS.Z$INTEGR_FORMS_F_102", line 489
ORA-06512: at "IBS.Z$INTEGR_FORMS_F_102", line 1222
ORA-06512: at "IBS.Z$INTEGR_FORMS_F_102", line 1647
ORA-06512: at "IBS.Z$U$8059353", line 197
ORA-06512: at line 1
************************************
Конвертация настроек при установке обновления произведена дистрибутивная. Прошу исправить. |
В операции U20081220_REP_1 ЦФТ привязывает новые настройки к старым записям через реквизит PARENT. Для исправления превратил процедуру copy_tun в функцию с возвращением следующего результата
И далее в теле скорректировал присвоения tun_id_P28 и tun_id_res:
Код: | --copy_tun(u.tun_id,'Глава III. Финансовый результат после налогообложения и его использование',date_begin);
--tun_id_res := u.tun_id;
tun_id_res := copy_tun(u.tun_id,'Глава III. Финансовый результат после налогообложения и его использование',date_begin);
...
--copy_tun(u.tun_id,'Раздел 8. Налог на прибыль (балансовый счет № 70611, при составлении годового отчета , балансовый счет № 70711)',date_begin);
--tun_id_P28 := u.tun_id;
tun_id_P28 := copy_tun(u.tun_id,'Раздел 8. Налог на прибыль (балансовый счет № 70611, при составлении годового отчета , балансовый счет № 70711)',date_begin);
|
|
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Пн Дек 29, 2008 17:10 |
|
Полезность: 2
|
И еще про ф.102 зарегал:
Цитата: | ф. 102. Ошибка объединения ячеек при выводе в Excel уже рассчитанной реализации после установки дополнения 8.7.15:
"Выделенная область содержит несколько значений данных. Объединение ячеек приведет к потере всех значений, кроме левого верхнего".
Со старым шаблоном ошибки не возникает. Прошу скорректировать шаблон из обновления, чтобы ошибки не возникало. |
|
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Сб Янв 10, 2009 15:20 |
|
Полезность: Нет оценки
|
Зарегал
Цитата: | При запуске простой операции "Синхронизировать группу риска" над одной записью неверно определяется группа риска - 2 вместо 1. Запуск производится с указанием даты 31.12.08 и двух признаков "Синхронизировать по резервированию" и "Синхронизировать по группе риска клиента". При снятии признака "Синхронизировать по резервированию" группа риска вычисляется правильная - 1. По всем экземплярам продукта "Резервирование" по этому клиенту действующая группа риска = 1. Хотя некоторое время назад она была 2. Оказалось, что запрос в AC_FIN.RES_RISK_GROUP
Код: | select res(max(res.[NUM])
, max(res.[RES_RATE])
)
in
( select g(g.[RISK_GROUP].[NUM] : NUM
,g.[RES_RATE] : RES_RATE
)
in ::[RES_GR_RATE]
, (::[RES_BASE_ACCS] : rba) all
where g%collection = rba.[GR_RATE]
and rba.[CUST] = l_res.[CUST]
and trunc(g.[BEG_DATE]) <= trunc(P_DATE)
and ::[RES_PORT].[LIB].cmp_date(rba.[DATE_BEGINING], rba.[DATE_CLOSE], P_DATE, null) = '1')
into l_gr_num, l_prc;
|
находит макисмальную группу риска не только среди действующих записей, но и старых. На один экземпляр продукта "Резервирование" подзапрос возвращает 2 записи - одну с 1-ой группой, а вторую - со 2-ой.
Прошу исправить. |
Пришлось исправлять запрос  |
|
 |
timochev Эксперт
Вступление в Клуб: 02.07.2007
|
Ср Янв 14, 2009 10:36 ЮЛ не проверяются на террор при вводе и редактировании |
|
Полезность: 1
|
А знаете ли Вы, что...
... при вводе и редактировании клиента ЮЛ при его подозрительности на причастность к терроризму НЕ выдается соответствующее сообщение?
В операции CL_ORG.EDIT#AUTO можно увидеть замечательный пример "качественного" кода ЦФТ:
Код: | -- уже при вводе должны проверить клиента на причастность к терроризму и запросить подтверждение
declare
terr ref [TERRORS];
begin
terr := ::[TERRORS].[CHECKS].find_suspect(P#NAME);
if terr is not null then
V#ERR := '?Клиент подозрителен на причастность к терроризму(Запись в справочнике: '||terr.[NAME]||').'||chr(10)||'Продолжить?';
end if;
end;
V#ERR := ::[CLIENT].[LIB].Check_Inn_For_Script(cl, P#COUNTRY, P#INN); |
Сначала в переменную V#ERR информацию напишем, а потом мы же ее и перетрем! |
|
 |
|