DATE_BEGIN <> DATE_BEGINING
|
| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
KhrushchevAV
Участник со стажем
Вступление в Клуб: 17.10.2014
|
 Чт Окт 06, 2016 07:57 DATE_BEGIN <-> DATE_BEGINING |
 |
Полезность: Нет оценки
|
Добрый день, коллеги!
Как известно есть, в таблице PRODUCT две даты:
Дата создания договора DATE_BEGIN
Дата начала действия договора DATE_BEGINING
Это если в администраторе словаря (Admin*.exe) смотреть.
Не важно, смотрим мы на Продукты, Кредиты, Депозиты и т.п.
/* Бить больно за такие названия полей! Ну да не о том речь. */
Из названия, да и из документации ЦФТ ясно, что дата создания она постоянна. А дата начала действия может быть позднее, если например, договор начинает действовать с момента поступления средств.
Т.е. DATE_BEGIN <= DATE_BEGINING
Однако, наткнулись случайно на ошибку с депозитами.
"Дата договора не может быть больше даты начала действия договора!"
Ну думаю, как пользователи умудряются накосячить...
Как обычно, пришлось играть в следователя.
В результате, вскрытие показало, что в DEPOSIT.EDIT#AUTO прагма написана наоборот:
| Код: |
if (P_DATE_BEGINING > P_DATE_BEGIN) then
pragma error('Дата договора не может быть больше даты начала действия договора!');
end if;
|
Ну и в других дистрибутивных операциях по депозитам, в формах, датой создания договора названа DTAE_BEGINING а датой начала DATE_BEGIN. (т.е. наоборот! Не верь тому, что видишь в администраторе).
Кто сталкивался и разбирался.
Правильно я понял, что ЦФТ запуталось в собственных наименованиях полей?! (А не надо так путано называть! Чем плохо было DTAE_CREATE, например?).
И теперь разработчик должен иметь в виду. Если ты видишь запись в PRODUCT, то если это кредит, то дата договора это DATE_BEGIN а дата начала - DATE_BEGINING, а если это депозит, то все наоборот!
Дочитавшие до этого места, Вы еще не запутались? Молодцы! Возьмите печенку  .
Дак, я что-то недопонял? Или так и живем? Нарушая азы теории БД. "НИКОГДА не делайте так, что поля в одной таблице означают разное, для разных записей".
А если кто вдруг поверил названию полей в администраторе, то сам виноват? |
|
 |
Gobur
Профи
Вступление в Клуб: 06.11.2012
|
| Чт Окт 06, 2016 08:18 |
|
Полезность: Нет оценки
|
| просто у цфт разные продукты и куски от продуктов не то что разные люди, но и в разных городах пишут. Это нормально. В других АБС и похуже бывает. |
|
|
Andry
Участник - экстремал
Вступление в Клуб: 14.01.2009
|
|
|
yaffil
Профи
Вступление в Клуб: 18.08.2011
|
| Чт Окт 06, 2016 10:49 Re: DATE_BEGIN <-> DATE_BEGINING |
|
Полезность: 1
|
| KhrushchevAV пишет: | Ну и в других дистрибутивных операциях по депозитам, в формах, датой создания договора названа DTAE_BEGINING а датой начала DATE_BEGIN. (т.е. наоборот! Не верь тому, что видишь в администраторе).
Кто сталкивался и разбирался.
Правильно я понял, что ЦФТ запуталось в собственных наименованиях полей?! (А не надо так путано называть! Чем плохо было DTAE_CREATE, например?).
|
У ЦФТ руки не из того места растут, и я это давно понял, частенько с депозитами забываю эту хрень и отчеты не правильные получаются
А надо было всего то ЦФТ писать название не BEGIN и BEGINING, а CREATE и BEGIN. И вообще не было бы путаницы, но нет надо, чтобы жизнь малиной не казалась 
Поэтому я часто смарю представление "Полный список" и от туда вспоминаю что у ЦФТ наоборот в депозитах  |
|
|
vtar
Эксперт
Вступление в Клуб: 20.03.2009
|
| Чт Окт 06, 2016 11:10 |
|
Полезность: Нет оценки
|
| Gobur пишет: | | просто у цфт разные продукты и куски от продуктов не то что разные люди, но и в разных городах пишут. Это нормально. В других АБС и похуже бывает. |
в кусках ЦФТ продуктов куски пишут оленей куски, короче ))
AOT: в кредитах помню что то было такое, что в _begin писалась дата начала договора а в _begining - пусто или дата импорта, если кредит куплен или импортирован из другой системы. Как то так, или наоборот )) |
|
|
nobel
Профи
Вступление в Клуб: 28.09.2011
|
| Чт Окт 06, 2016 12:18 |
|
Полезность: Нет оценки
|
у гарантий есть такая же фишка.могут две даты совпадать,а если разные то это уже другое приложение.мол постановка требования будет другой дата и от этой даты должна начинаться гарантия.
плохо что по ЦФТ нету единого правила понимания реквизитов.
тем более далеко не во всех продуктах это используется из типа "Продукты".помню приводил в порядок "Резервирование"-ни дата закрытия,ни состояние ни другие общие параметры не ставятся. |
|
|
vtar
Эксперт
Вступление в Клуб: 20.03.2009
|
| Чт Окт 06, 2016 13:21 |
|
Полезность: Нет оценки
|
| nobel пишет: |
плохо что по ЦФТ нету единого правила понимания реквизитов.
|
а ещё меня сильно бесили 2 вещи:
1) однотипные реквизиты называются по разному, например
кредиты - CLIENT
гарантии - BENEFICIARY
2) нет единой нотации на однотипные реквизиты, типа
begin_date
date_begin
date_start |
|
|
KhrushchevAV
Участник со стажем
Вступление в Клуб: 17.10.2014
|
| Чт Окт 06, 2016 13:30 Re: DATE_BEGIN <-> DATE_BEGINING |
|
Полезность: Нет оценки
|
| Цитата: | У ЦФТ руки не из того места растут, и я это давно понял, частенько с депозитами забываю эту хрень и отчеты не правильные получаются
|
Спасибо, коллеги. Очень помогли!
А то я уж думал, что "меня глючит"... |
|
|
KhrushchevAV
Участник со стажем
Вступление в Клуб: 17.10.2014
|
| Чт Окт 06, 2016 14:00 Re: бардак |
|
Полезность: Нет оценки
|
Чисто "синдром отличника" не дает пропустить это утверждение.
| Цитата: | | никоим образом не защищая бардак в структуре БД и ЦФТ как контору - хочу заметить что я не смог сейчас соотнести данное высказывание ни с формами нормальности |
Признаете, что бардак, но формальные критерии вроде не нарушены?
Так не бывает!
Если соблюдены все формальности - то не бардак.
Не очевидно же нарушение, думаю, из-за формального языка, которым они изложены в википедии.
По-моему, нарушена 3 нормальная форма (3NF). И правило гарантированного доступа (2 правило Кода).
Поясню. Нужен атрибут "дата создания договора". Ключ договора есть. При нормальных данных этого достаточно.
| Код: | SELECT
C_DATE_BEGIN
FROM
Z#PRODUCT
WHERE
ID = 1
|
Наивные...
"А вот фиг вам!" - Отвечает ЦФТ.
"В зависимости от вида договора, возможно, вам нужно совсем другое поле. Например C_DATE_BEGINING".
Т.е. налицо зависимость атрибута не только от первичного ключа, но и от другого атрибута (CLASS_ID).
(Никогда так не делайте! Сэкономите уйму сил в будущем).
Согласны? |
|
|
Ghost
Профи
Вступление в Клуб: 24.11.2007
|
| Чт Окт 06, 2016 16:14 |
|
Полезность: Нет оценки
|
| Ха, это вы еще в Аккредитивы международные не погружались, там такие чуйдеса с датами окончания и закрытия, прям обнять и горько рыдать. |
|
|
Эмиралька
Эксперт
Вступление в Клуб: 09.11.2015
|
| Чт Окт 06, 2016 17:05 |
|
Полезность: Нет оценки
|
| не только депозиты, но и межбанк BANKS_LOANS |
|
|
kai
Профи
Вступление в Клуб: 16.08.2012
|
| Пт Окт 07, 2016 06:23 |
|
Полезность: Нет оценки
|
В 2011 г. по заявке одного из алтайских банков дорабатывал отчёт "Выписка" - региональное ЦБ вдруг стал требовать отображать в печатной форме не только наименование счёта, но и его обозначение ))) а что это - это много чего (см. 302-П или доку по отчёту).
Так тоже намучились с этими 2-мя реквизитами - спасибо аналитику - разобралась, благодаря своему богатому опыту работы разработчиком и аналитиком.
Если кому-то поможет, посмотрите комментарии в библиотеке:
| Код: | | [AM_DESIGN_ACC]::[SLIB] |
p.s. Кстати, мы видели при тестировании, что в "Выписке" ([AC_FIN]::[ACCMOVE]) теперь стала интересная и динамичная информация. Но отзывов ни от кого так и не получили, кроме заказчиков, что ЦБ был благосклонен к реализации. |
|
|
OlegFB
Участник - экстремал
Вступление в Клуб: 11.07.2007
|
| Ср Окт 12, 2016 08:57 |
|
Полезность: Нет оценки
|
| vtar пишет: | | Gobur пишет: | | просто у цфт разные продукты и куски от продуктов не то что разные люди, но и в разных городах пишут. Это нормально. В других АБС и похуже бывает. |
в кусках ЦФТ продуктов куски пишут оленей куски, короче ))
AOT: в кредитах помню что то было такое, что в _begin писалась дата начала договора а в _begining - пусто или дата импорта, если кредит куплен или импортирован из другой системы. Как то так, или наоборот )) |
Сейчас занимаюсь внедрением и просто в ахуе от подобного!
Например:
1.
В ЦФТ есть класс "Денежные единицы" (FT_MONEY) где по идее должны быть только валюты с которыми работает банк - т.е. те валюты, в которых в банке открыты счета.
НО! Для шлюза с процессингом (шлюз авторства цфт-шного же!!!) требуется чтобы в этом классе были ВСЕ валюты! Например, расплатился клиент карточкой в ОАЭ - будьте добры нац. валюту ОАЭ ввести, иначе шлюз сломается.
Для SWIFT-овых переводов с внешней конвертацией - то же самое, но ещё должен быть указан и курс! И это при том, что в ЦФТ существует справочник "Общероссийский классификатор валют", где все эти валюты есть по умолчанию.
2.
Для продукта "Операции с ценностями" требуется заведение инкассаторов в Пользователях с соответствующей должностью. А вот в продукте "Инкасация" нужно чтобы эти инкассаторы были заведены в клиентах И ПРИВЯЗАНЫ к банку через "Отношения с Банком".
3.
Для шлюзов с процессингом и с Золотой Короной требуется, чтобы телефонные номера в досье клиентов были заведены в РАЗНЫХ форматах!
И такой фигни больше чем до фига! |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
