RS-Bank кто скажет хорошего
Artem Kaushan
Вот думают ставить, кто может сказать, и/или дать по ней доку с
возможностями.
С искренним приветом - Артем.
Dmitri Chipiga
Artem Kaushan wrote:
> Вот думают ставить, кто может сказать, и/или дать по ней доку с
> возможностями.
Дичь какая-то, как ты себе эту доку представляешь?.
А просто в Рстайл сходить - или www.softlab.ru.
--
С уважением
Дмитрий Чипига
E-mail: doc...@mmbank.ru
ICQ: 7578181
Ilya Vinichenko
> Вот думают ставить, кто может сказать, и/или дать по ней доку с
> возможностями.
>
Смотря какие у Вас требования.
Для банка с 200-300 живыми клиентами ЮЛ, до 20'000 ФЛ, с не очень широким
кругом операций и без особенных требований со стороны руководства к качеству
системы поддержки принятия решений - RS-Bank почти идеальная система.
Если же, ФЛ > 30'000, живых ЮЛ > 2000, активное кредитование, а руководство
хочет знать влияние роста инфляции на ликвидность банка через 6 месяцев
(например), то надо искать что-то по-круче
Accounter
IV> Смотря какие у Вас требования.
IV> Для банка с 200-300 живыми клиентами ЮЛ, до
IV> 20'000 ФЛ, с не очень широким
IV> кругом операций и без особенных требований со
IV> стороны руководства к качеству
IV> системы поддержки принятия решений - RS-Bank
IV> почти идеальная система.
Интересно, почему Вы так думаете? На RS-Bank работают ОЧЕНЬ большие
банки типа Банка Москвы, Собинбанка или региональных тербанков СБ РФ.
Теперь по физлицам. RS-Retail реально поддерживает базы порядка 600.000
счетов и все работает.
--
C Уважением. Accounter
Отправлено через сервер Talk.Ru - http://www.talk.ru
Vladimir Andreev
Accounter <zemb...@softlab.ru> сообщил в новостях > Ilya Vinichenko
<v...@dor.ru> пишет:
>
> IV> Смотря какие у Вас требования.
> IV> Для банка с 200-300 живыми клиентами ЮЛ, до
> IV> 20'000 ФЛ, с не очень широким
> IV> кругом операций и без особенных требований со
> IV> стороны руководства к качеству
> IV> системы поддержки принятия решений - RS-Bank
> IV> почти идеальная система.
>
> Интересно, почему Вы так думаете? На RS-Bank работают ОЧЕНЬ большие
> банки типа Банка Москвы, Собинбанка или региональных тербанков СБ РФ.
> Теперь по физлицам. RS-Retail реально поддерживает базы порядка 600.000
> счетов и все работает.
но никто при этом не упоминает, что под эти _конторы_ пишется нечто
особенное (под заказ %-) ), не имеющее к стандартной поставке никакого
отношения.
дело даже не в используемом инструменте и платформах, а в возможности
самописной доделки и шлифовки напильником. ;-) как таковое - оно
присутсвует, но говорить о банках с одним-двумя автоматизаторами, на которых
еще помимо АБС висит достаточно много дел, имхо, неразумно.
впрочем, так везде...
> C Уважением. Accounter
wbr, sd.
Accounter
VA> но никто при этом не упоминает, что под эти
VA> _конторы_ пишется нечто
VA> особенное (под заказ %-) ), не имеющее к
VA> стандартной поставке никакого
VA> отношения.
Повторю - RS-Retail (штатный, без всяких доработок под клиента)
работает в Новосибирске с 600,000 счетами (большое ОСБ сбера) и
работает хорошо! Да и не станет никто делать отдельные сборки под
каждого клиента, даже под богатого, это же только сопровождать
исходники - застрелиться можно! Или Вы думаете, что R-Style всем
продает под Pervasive 2000, а особо крутым - тоже самое под Oracle?
Бред, согласитесь. Хотя, если кому надо - можно и под AS/400 RS-Bank
поставить, благо прецеденты есть.
VA> дело даже не в используемом инструменте и
VA> платформах, а в возможности
VA> самописной доделки и шлифовки напильником. ;-)
VA> как таковое - оно
VA> присутсвует, но говорить о банках с одним-двумя
VA> автоматизаторами, на которых
VA> еще помимо АБС висит достаточно много дел, имхо,
VA> неразумно.
Дык я все-таки не понял при чем тут маленькие банки? В больших банках и
народу больше, соответсвенно, больше тех самых "напильников".
VA> впрочем, так везде...
Согласен. "Коробочных" АБС типа Plug-and-Play не бывает. И быть не
может.
Izmailov Felix
По моему мнению, ближе всего к истине ответ Ильи Виниченко (если правильно
транслировал имя и фамилию).
Можно цифры в его сообщении, правда чуток приподнять (кол-во счетов), и он
не отметил документооборот Банка, до 2500 документов в день - терпимо, потом
начинаются проблемы, как то - закрытие дня, выпуск баланса, сводный баланс
(это правда больше зависит от количества откр.счетов)
Как учетное ядро, для старта небольшого Банка - годится, потом начинает
трещать по швам, но это в будущем, а оно может быть разным.
Система прописана грамотно, работает с Бтривом - хорошо.. Но все определяют
объемы...
С уважением Измайлов Феликс
<fe...@mail.itbank.orc.ru>
Artem Kaushan пишет в сообщении <9711...@p1.f277.n465.z2.ftn> ...
> Хаюшки, многоуважаемый и глубокопочитаемый , All!
>
> Вот думают ставить, кто может сказать, и/или дать по ней доку с
>возможностями.
>
Ilya Vinichenko
> IV> Для банка с 200-300 живыми клиентами ЮЛ, до
> IV> 20'000 ФЛ, с не очень широким
> IV> кругом операций и без особенных требований со
> IV> стороны руководства к качеству
> IV> системы поддержки принятия решений - RS-Bank
> IV> почти идеальная система.
>
> Интересно, почему Вы так думаете? На RS-Bank работают ОЧЕНЬ большие
> банки типа Банка Москвы, Собинбанка или региональных тербанков СБ РФ.
> Теперь по физлицам. RS-Retail реально поддерживает базы порядка 600.000
> счетов и все работает.
Я так думаю, так как имею 7 лет опыта работы с RS-Bank.
RS-Bank как раз коробочный продукт - в этом одно из его преймуществ и в этом
же много его недостатков.
Ilya Vinichenko
> не отметил документооборот Банка, до 2500 документов в день - терпимо,
потом
> начинаются проблемы, как то - закрытие дня, выпуск баланса, сводный баланс
> (это правда больше зависит от количества откр.счетов)
> Как учетное ядро, для старта небольшого Банка - годится, потом начинает
> трещать по швам, но это в будущем, а оно может быть разным.
> Система прописана грамотно, работает с Бтривом - хорошо.. Но все
определяют
> объемы...
Феликс, должен выразить несогласие с некоторыми твоими постулатами:
"система прописана грамотно" - а как быть с тем, что внутри транзакции
выдается запрос с ожиданием ответа от пользователя (речь идет о расчете
процентов) ? а нестандартный тип DOUBLEL, который делает бесполезным массу
полезного стандартного софта и вызывает ошибку при округлении функциями RSL
? а множественные списки клиентов (из-за чего простейший отчет о мат выгоде
невозможно выпустить корректно) ?
"все определяют объемы" - к сожалению это так лишь на 50%, много определяет
сложность конкретных банковских продуктов, которые пытается продавать банк
Но еще раз повторюсь (несмотря на мои наезды на RS-Bank) , для небольшого и
"несложного" банка, RS-Bank - система почти идеальная,
так как у нее есть ряд замечательных качеств, о которых я здесь ничего не
говорил
Igor Kuznetsov
12 Oct 00 15:01, Accounter wrote to Ilya Vinichenko:
IV>> Смотря какие у Вас требования.
IV>> Для банка с 200-300 живыми клиентами ЮЛ, до
IV>> 20'000 ФЛ, с не очень широким
IV>> кругом операций и без особенных требований со
IV>> стороны руководства к качеству
IV>> системы поддержки принятия решений - RS-Bank
IV>> почти идеальная система.
A> Интересно, почему Вы так думаете? Hа RS-Bank работают ОЧЕHЬ большие
A> банки типа Банка Москвы, Собинбанка или региональных тербанков СБ РФ.
A> Теперь по физлицам. RS-Retail реально поддерживает базы порядка
A> 600.000 счетов и все работает.
600 тыс. счетов это как ????
Я так понимаю - это куча филиалов отделения Сбера, которые работают с одной
центральной базой ??? Так ??? Или десятки баз (по одной на филиал) просто на
одном компе ?
Меня тоже интересует этот вопрос. Когда стал разбираться подробнее..... то
оказалось все не так просто. Теоретически в одноф физической базе можно завести
все базы наших филиалов.... но проблема тут самая простая.... что делать, если
в одном из филиалов потребовалось востановить базу по состоянию на начало
операционного дня ? (Hе буду вдаваться для чего это нужно но увы такое иногда
необходимо). Как это сделать в рамках центральной базы ? Востановить вчерашний
архив со _всеми_ филиалами ?
К сожалению на этот вопрос я так и не нашел ответов.
До встpечи, Igor.
Igor Kuznetsov
12 Oct 00 17:07, Accounter wrote to Vladimir Andreev:
A> Повторю - RS-Retail (штатный, без всяких доработок под клиента)
A> работает в Hовосибирске с 600,000 счетами (большое ОСБ сбера) и
A> работает хорошо!
Вот и нашел человека с кем поговорить ..... :)
У нас происходит некоторый выбор системы для филиалов. В течении месяца
разглядывали RS-Retail. Hекоторые принципиальные вещи не дают запуска.
А теперь вопросы:
1. Вы работаете с одной базой на все филиалы ? или на каждый филиал по базе?
2. Если с центральной базой то как востановить один филиал не прерывая работу
остальных?
3. Сколько филиалов ?
4. Линии связи ?
5. Объем базы ? Прирост базы в год ? За какой период предполагается держать
историю счетов?
У нас около 500 тыс. счетов. К началу следующего года прибавиться еще около 50
тыс. (Объединение). В 80% филиалах имеется on-line > 128Kb.
Да, количество филиалов > 30.
Izmailov Felix
Ilya Vinichenko пишет в сообщении ...
Соглашусь почти со всем, только хотел уточнить, что я имел ввиду, когда
говорил "система прописана грамотно". Две вещи, логическая целостность, ее
поддержание, и скорость работы с данными, если уж совсем опуститься до
низменных материй - то это логика работы по ключам, я общался с людьми,
которые работали на Кворуме, они выражали недоумение медленной работой
системы по этим показателям (поиск, выборка данных), потом я
проконсультировался у людей из РСтайла (нормальные люди, которые не будут
приукрашивать действительность), все дело в том - как с Бтривом работать...
это их ответ.
Ладно, это уже к теме мало относится.. Что еще хотел сказать. Все
перечисленные тобой моменты имеют место быть, но они вылезут в банке только
тогда, когда появятся знания этой системы, и знания глубокие. На старте -
это еще не важно.
Последние слова поддерживаю обеими руками.
Accounter
IK> Вот и нашел человека с кем поговорить ..... :)
Ok! Только я не в том банке работаю :)
IK> А теперь вопросы:
IK> 1. Вы работаете с одной базой на все филиалы ?
IK> или на каждый филиал по базе?
База последконтроля - единая. Про БД филиалов - ниже.
IK> 2. Если с центральной базой то как востановить
IK> один филиал не прерывая работу
IK> остальных?
Зачем востанавливать, если база работает на зеркальном сервере и не
падает?
IK> 3. Сколько филиалов ?
Всего 20 филиалов. В on-line работают 10, в режиме off-line со своими
базами 8, еще 2 неавтоматизированные и данные по ним вводятся руками.
IK> 4. Линии связи ?
Для нормальной работы трехзвенки хватает 5 кб на клиента. Новосиб
пользуется как выделенкой, так и радиомодемами, скорость 30-50 мс,
пакет 32 также ISDN 90 мс и более.
IK> 5. Объем базы ? Прирост базы в год ? За какой
IK> период предполагается держать
IK> историю счетов?
На 01.09.00:
Счетов - 589,000
Операций в БД - 4,350,000
Прирост базы 500-700 МБ/год
Одновременно работающих операционистов - 30-60
Вся эта красота крутится на Compaq PROLIANT 3000 / 256М / RAID - 18Гб
IK> У нас около 500 тыс. счетов. К началу следующего
IK> года прибавиться еще около 50
IK> тыс. (Объединение). В 80% филиалах имеется
IK> on-line > 128Kb.
IK> Да, количество филиалов > 30.
Нормально. Сейчас Архангельский СБ и Стерлитамакский ОСБ хотят все свои
филиалы в единой базе крутить с общим доступом, чтобы можно было
обслужиться в любом сбере города.
Vyacheslav Vankevich
IV>> Смотря какие у Вас требования.
IV>> Для банка с 200-300 живыми клиентами ЮЛ, до
IV>> 20'000 ФЛ, с не очень широким
IV>> кругом операций и без особенных требований со
IV>> стороны руководства к качеству
IV>> системы поддержки принятия решений - RS-Bank
IV>> почти идеальная система.
A> Интересно, почему Вы так думаете? Hа RS-Bank работают ОЧЕHЬ большие
A> банки типа Банка Москвы, Собинбанка или региональных тербанков СБ РФ.
A> Теперь по физлицам. RS-Retail реально поддерживает базы порядка
A> 600.000 счетов и все работает.
А думает он так потому, что видимо имел опыт работы с RS-Bank. Могу только
подтвердить вышесказанное.
Я бы сказал даже так: более-менее рабочий модуль - это опердень, но и в нем
предостаточно граблей( картотека к примеру ). Вообще, если бы не RSL ( спасибо
Кубрину ) - погибель бы наступила. Ради интереса можно почитать файлик из
дистрибутива с описанием ошибок в RS-Bank - волосы дыбом встают.
P.S. Все вышесказанное относится к версиям ( сборкам ;) ниже пятерки.
sf...@online.ru WBR, Vyacheslav.
Konstantin Krasnovski
Izmailov Felix пишет All:
IF> По моему мнению, ближе всего к истине ответ Ильи Виниченко (если правильно
IF> транслировал имя и фамилию).
IF> и он не отметил документооборот Банка,
IF> до 2500 документов в день - терпимо,
IF> потом начинаются проблемы, как то - закрытие дня, выпуск баланса,
IF> сводный баланс (это правда больше зависит от количества откр.счетов)
А откуда информация про проблемы? Я знаю банк с 15-20 тысячами операций в день.
Закрытие дня занимает от 30 до 40 минут, выпуск баланса за день - 5-7 минут,
баланс за месяц - немного быстрее.
Может быть проблемы не в скорости? о вылетов тоже не замечено. База архивных
документов за 6 месяцев подобралась, правда, к 1.5 Гигам. о ничего
криминального в этом не обнаружено...
Да и не перебраться ли с этой темой в RU.RSBANK? А то, боюсь, модератор плюсами
закидает. И ведь будет прав... :)
Удачи,
Константин
E-Mail: cost...@mail.ru
Alexander Kalyazin
13 Окт 00 09:09, Vyacheslav Vankevich wrote to Accounter:
A>> Интересно, почему Вы так думаете? Hа RS-Bank работают ОЧЕHЬ
A>> большие банки типа Банка Москвы, Собинбанка или региональных
A>> тербанков СБ РФ. Теперь по физлицам. RS-Retail реально
A>> поддерживает базы порядка 600.000 счетов и все работает.
VV> А думает он так потому, что видимо имел опыт работы с RS-Bank. Могу
VV> только подтвердить вышесказанное.
А может все же грабли на большом количестве счетов не из-за RS'а?
Так как сервер приложений работает на NT, базы на Pervasive. Продуктов, скажем
мягко, не шибко известных своей надежностью и безошибочностью. Три системы с
99% надежностью, что нам дадут в комплексе? :)
И тем не менее за шесть лет работы с RS'ом имел только четыре-пять серьезных
случаев с базой - все были связаны со слабым или старым железом. А вот примеров
криворукой настройки NT,NW,Pervasive или просто кривописанных макросов - можно
привести уйму. И здесь особой вины системы RS-Bank я не вижу.
VV> Я бы сказал даже так: более-менее рабочий модуль - это опердень, но и
VV> в нем предостаточно граблей( картотека к примеру ).
Hазови, плиз, продукт где граблей нет. В конце концов, при покупке системы у
тебя есть возможность проплатить RSLabs этап внедрения и последующего
сопровождения по полной программе. Причины, почему это делают нечасто, ясны.:)
Что касается подсистем, то открытость баз и возможность влезть почти в любую
транзакцию RSL'ем решает многие проблемы, в том числе и с картотеками. Те
недостатки что в подсистемах есть связаны только с остающейся местами
невозможность "влезть RSL'ем", но от билда к билду таких входов больше.
VV> Вообще, если бы не RSL ( спасибо Кубрину ) - погибель бы наступила.
VV> Ради интереса можно почитать файлик из дистрибутива с описанием
VV> ошибок в RS-Bank - волосы дыбом встают.
Пардон, не надо мешать мух и котлеты. Весь RS настроен именно на возможность
использования RSL. Причем почти на всех этапах работы банка. RS-Bank без RSL
просто нельзя рассматривать. Да и нет в упомянутом файлике столь уж страшных
ошибок. Проблемы известна? Известна - обойди ее на RSL и дело с концом.
VV> P.S. Все вышесказанное относится к версиям ( сборкам ;) ниже пятерки.
:-) Самый классной была версия 4.1. Hо и порулить RSL'ем можно было в основном
в отчетной части.
VV> sf...@online.ru WBR,
VV> Vyacheslav.
/*WBR,*/ *Александр.*
_E-mail: al...@mail.ru_ /ICQ: 527282/
Oleg Verhovec
Hекогда, в 13 октября 2028, 07:59 какой(ая) то
Ilya Vinichenko отписал(а) к All
на тему: "Re: RS-Bank кто скажет хорошего"
IV> Hо еще раз повторюсь (несмотря на мои наезды на RS-Bank) , для
IV> небольшого и "несложного" банка, RS-Bank - система почти
IV> идеальная, так как у нее есть ряд замечательных качеств, о которых я
IV> здесь ничего не говорил
А какие? У нас стоит РС-Банк, полгода уже стоит, но доказать своему коллеге его
прелесть не могу :(.
[Team КРИВЫЕ РУКИ]
С уважением Oleg Verhovec.
Девочка тинэйджер, позвони на пейджер: 99999#6115
Igor Kuznetsov
13 Oct 00 16:33, Accounter wrote to Igor Kuznetsov:
IK>> Вот и нашел человека с кем поговорить ..... :)
A> Ok! Только я не в том банке работаю :)
Уже понял...
IK>> А теперь вопросы:
IK>> 1. Вы работаете с одной базой на все филиалы ?
IK>> или на каждый филиал по базе?
A> База последконтроля - единая. Про БД филиалов - ниже.
IK>> 2. Если с центральной базой то как востановить
IK>> один филиал не прерывая работу
IK>> остальных?
A> Зачем востанавливать, если база работает на зеркальном сервере и не
A> падает?
"Падение" базы (физическое разрушение) случается видимо не так часто.... зато
бывают различного рода програмные "падения" (%% ставки, условия ... съехал
скрипт и пр....), которые гораздо дешевле востановить путем повторного ввода
документов за день по одному проблемному филиалу. Особенно это актуально в
период запуска системы, когда вероятность программных ошибок выше.
Так все же как быть ?
IK>> 3. Сколько филиалов ?
A> Всего 20 филиалов. В on-line работают 10,
10 филиалов работают именно с одной базой на сервере или все же это 10
отдельных базок но на одном сервере ?
Это принципиально.
A> в режиме off-line со своими
A> базами 8, еще 2 неавтоматизированные и данные по ним вводятся руками.
IK>> 4. Линии связи ?
A> Для нормальной работы трехзвенки хватает 5 кб на клиента. Hовосиб
A> пользуется как выделенкой, так и радиомодемами, скорость 30-50 мс,
A> пакет 32 также ISDN 90 мс и более.
С этим все ясно.
А что с шифрацией канала ?
IK>> 5. Объем базы ? Прирост базы в год ? За какой
IK>> период предполагается держать
IK>> историю счетов?
A> Hа 01.09.00:
A> Счетов - 589,000
A> Операций в БД - 4,350,000
A> Прирост базы 500-700 МБ/год
При конвертации 50 тыс. счетов с историей за полгода база RS = 600 Мб.
A> Одновременно работающих операционистов - 30-60
A> Вся эта красота крутится на Compaq PROLIANT 3000 / 256М / RAID - 18Гб
IK>> У нас около 500 тыс. счетов. К началу следующего
IK>> года прибавиться еще около 50
IK>> тыс. (Объединение). В 80% филиалах имеется
IK>> on-line > 128Kb.
IK>> Да, количество филиалов > 30.
A> Hормально. Сейчас Архангельский СБ и
A> Стерлитамакский ОСБ хотят все
^^^^^^^^^^^^^^^^^^^^^^^
Это я и есть :)
A> свои филиалы в единой базе крутить с общим доступом, чтобы можно было
A> обслужиться в любом сбере города.
Вот только нужно решить некоторые принципиальные вопросы....
До встpечи, Igor.
Alexander Turchin
> А откуда информация про проблемы? Я знаю банк с 15-20 тысячами
операций в день.
> Закрытие дня занимает от 30 до 40 минут, выпуск баланса за день - 5-7
минут,
> баланс за месяц - немного быстрее.
Прошу прощения за то, что влезаю в разговор, не имея опыта общения с
сабжем. Однако же я слышал краем глаза, что при работе в "архивных" днях
в RS возникают бааальшие тормоза. У нас, например, работа в закрытых
днях на два-три дня назад - обычное дело (для ограниченной группы
пользователей, естественно), а баланс формируют раз 50 в день - для
контроля и "прикидок".
WBR, Александр Турчин.
-- Заходите ко мне в гости на http://aturchin.travel.ru --
Accounter
IK> видимо не так часто.... зато
IK> бывают различного рода програмные "падения" (%%
IK> ставки, условия ... съехал
IK> скрипт и пр....), которые гораздо дешевле
IK> востановить путем повторного ввода
IK> документов за день по одному проблемному филиалу.
IK> Особенно это актуально в
IK> период запуска системы, когда вероятность
IK> программных ошибок выше.
IK> Так все же как быть ?
Выгрзить все операции за день в сессию. Восстановить базу и повторно
подгрузить операции за день.
IK>>> 3. Сколько филиалов ?
IK> A> Всего 20 филиалов. В on-line работают 10,
IK> 10 филиалов работают именно с одной базой на
IK> сервере или все же это 10
IK> отдельных базок но на одном сервере ?
IK> Это принципиально.
База единая.
IK> A> в режиме off-line со своими
IK> A> базами 8, еще 2 неавтоматизированные и данные
IK> по ним вводятся руками.
IK>>> 4. Линии связи ?
IK> A> Для нормальной работы трехзвенки хватает 5 кб
IK> на клиента. Hовосиб
IK> A> пользуется как выделенкой, так и
IK> радиомодемами, скорость 30-50 мс,
IK> A> пакет 32 также ISDN 90 мс и более.
IK> С этим все ясно.
IK> А что с шифрацией канала ?
Шифруют трафик сберовской DLL. В спецификации трехзвенки - 4 уровень
шифрации.
IK> A> Hа 01.09.00:
IK> A> Счетов - 589,000
IK> A> Операций в БД - 4,350,000
IK> A> Прирост базы 500-700 МБ/год
IK> При конвертации 50 тыс. счетов с историей за
IK> полгода база RS = 600 Мб.
Ну нормально. Основные данные (счета, вкладчики, прочие настройки)
внесены - дальше прирост будет меньше.
IK> A> Одновременно работающих операционистов -
IK> 30-60
IK> A> Вся эта красота крутится на Compaq PROLIANT
IK> 3000 / 256М / RAID - 18Гб
IK> A> Hормально. Сейчас Архангельский СБ и
IK> A> Стерлитамакский ОСБ хотят все
IK> ^^^^^^^^^^^^^^^^^^^^^^^
IK> Это я и есть :)
Ха! Здорово!
IK> A> свои филиалы в единой базе крутить с общим
IK> доступом, чтобы можно было
IK> A> обслужиться в любом сбере города.
IK> Вот только нужно решить некоторые принципиальные
IK> вопросы....
IK> До
IK> встpечи, Igor.
Да. Надеюсь встретьтся в Уфе.
Valera Ivanichkin
16 Oct 28 12:13, you wrote to Igor Kuznetsov:
о нас и без нас, оригинально ;-)))
IK>>>> 4. Линии связи ?
IK>> Hовосиб пользуется как выделенкой, так и
IK>> радиомодемами, скорость 30-50 мс,
от 10 мс и до 200 в зависимости от маршрута к
филиалу (количества ретрансляторов)
IK> A>> пакет 32 также ISDN 90 мс и более.
^^^^ мин. 90, обычно 120-250 мс (сильно зависит от
качества isdn линии, воды в кабельный системах и прочих погодных напастей)
IK> A>> Одновременно работающих операционистов -
IK>> 30-60
IK> A>> Вся эта красота крутится на Compaq PROLIANT
IK>> 3000 / 256М / RAID - 18Гб
устарело ^^^^ 512М / 2х18Гб
Valera
Sergey T Volodin
В вторник 10 октября 2000г., в 08:04, Artem Kaushan писал(а) к All:
AK> Вот думают ставить, кто может сказать, и/или дать по ней доку с
AK> возможностями.
Зря вообще связались, единственное достоинство - наличие
встроенного языка - RSL, а остальном. :(((
Ранее работал под ОДБ "Мебиус", разница в удобстве работы разительна.
Hе видел еще человека, каторый был бы в восторге от RS, если
он ранее работал с какой-нибудь другой ОДБ.
С уважением,
Сергей.
Accounter
Надо чаще... в эху заглядывать :)
Извини, Валера, только сегодня узнал откуда товарисч Igor. Если ты не
против, то я ему твой телефончик дам для консультаций? Пусть все лично
спросит.
IK>>>>> 4. Линии связи ?
IK>>> Hовосиб пользуется как выделенкой, так и
IK>>> радиомодемами, скорость 30-50 мс,
VI> от 10 мс и до 200 в
VI> зависимости от маршрута к
VI> филиалу (количества ретрансляторов)
IK>> A>> пакет 32 также ISDN 90 мс и более.
VI> ^^^^ мин. 90, обычно
VI> 120-250 мс (сильно зависит от
VI> качества isdn линии, воды в кабельный системах и
VI> прочих погодных напастей)
IK>> A>> Одновременно работающих операционистов
VI> -
IK>>> 30-60
IK>> A>> Вся эта красота крутится на Compaq
VI> PROLIANT
IK>>> 3000 / 256М / RAID - 18Гб
VI> устарело ^^^^ 512М / 2х18Гб
Поздравляю! У меня просто ваши данные были от первого сентября.
Igor Kuznetsov
16 Oct 00 12:13, Accounter wrote to Igor Kuznetsov:
IK>> "Падение" базы (физическое разрушение) случается
IK>> видимо не так часто.... зато
IK>> бывают различного рода програмные "падения" (%%
IK>> ставки, условия ... съехал
IK>> скрипт и пр....), которые гораздо дешевле
IK>> востановить путем повторного ввода
IK>> документов за день по одному проблемному филиалу.
IK>> Особенно это актуально в
IK>> период запуска системы, когда вероятность
IK>> программных ошибок выше.
IK>> Так все же как быть ?
A> Выгрзить все операции за день в сессию.
Хорошо.... (Сколько времени потребуется примерно?)
A> Восстановить базу
Как востановить базу ?
A> и повторно
A> подгрузить операции за день.
Я правильно понял, что необходимо выгрузить все операции за текущий день по
_всем_ филиалам (при этом ни один из филиалов больше не должен работать дабы
новых операций не появилось), затем востановить базу порядка 10-15 Гиг и
наконец прогрузить все сохраненные документы.....
Теперь еще вопрос: Сколько времени будут простаивать _все_ филиалы по причине
одного филиала? Учитывая, что кол-во филиалов более 30 то и вероятность простоя
всех филиалов увеличивается до невероятной величины... или точнее сказать
вероятность нормальной работы уменьшается :)
Вот это на сегодня меня больше всего волнует....
IK>>>> 3. Сколько филиалов ?
IK> A>> Всего 20 филиалов. В on-line работают 10,
IK>> 10 филиалов работают именно с одной базой на
IK>> сервере или все же это 10
IK>> отдельных базок но на одном сервере ?
IK>> Это принципиально.
A> База единая.
IK> A>> в режиме off-line со своими
IK> A>> базами 8, еще 2 неавтоматизированные и данные
IK>> по ним вводятся руками.
IK>>>> 4. Линии связи ?
IK> A>> Для нормальной работы трехзвенки хватает 5 кб
IK>> на клиента. Hовосиб
IK> A>> пользуется как выделенкой, так и
IK>> радиомодемами, скорость 30-50 мс,
IK> A>> пакет 32 также ISDN 90 мс и более.
IK>> С этим все ясно.
IK>> А что с шифрацией канала ?
A> Шифруют трафик сберовской DLL. В спецификации трехзвенки - 4 уровень
A> шифрации.
Производительность?
IK> A>> Hа 01.09.00:
IK> A>> Счетов - 589,000
IK> A>> Операций в БД - 4,350,000
IK> A>> Прирост базы 500-700 МБ/год
IK>> При конвертации 50 тыс. счетов с историей за
IK>> полгода база RS = 600 Мб.
A> Hу нормально. Основные данные (счета, вкладчики, прочие настройки)
A> внесены - дальше прирост будет меньше.
Хорошо.
IK> A>> Одновременно работающих операционистов -
IK>> 30-60
IK> A>> Вся эта красота крутится на Compaq PROLIANT
IK>> 3000 / 256М / RAID - 18Гб
IK> A>> Hормально. Сейчас Архангельский СБ и
IK> A>> Стерлитамакский ОСБ хотят все
IK>> ^^^^^^^^^^^^^^^^^^^^^^^
IK>> Это я и есть :)
A> Ха! Здорово!
:)
IK> A>> свои филиалы в единой базе крутить с общим
IK>> доступом, чтобы можно было
IK> A>> обслужиться в любом сбере города.
IK>> Вот только нужно решить некоторые принципиальные
IK>> вопросы....
IK>> До
IK>> встpечи, Igor.
A> Да. Hадеюсь встретьтся в Уфе.
Hадеюсь на решение принципиальных проблем.
До встpечи, Igor.
Edward Koryagin
>- можно и под AS/400 RS-Bank
А поподробнее можно про AS/400?
Vasiliy Lyapun
13 Окт 00 09:09, Vyacheslav Vankevich -> Accounter:
IV>>> Смотря какие у Вас требования.
IV>>> Для банка с 200-300 живыми клиентами ЮЛ, до
IV>>> 20'000 ФЛ, с не очень широким
IV>>> кругом операций и без особенных требований со
IV>>> стороны руководства к качеству
IV>>> системы поддержки принятия решений - RS-Bank
IV>>> почти идеальная система.
IMHO Это идеальная система для 95 года но не сейчас.
Плавали знаем :-)
A>> Интересно, почему Вы так думаете? Hа RS-Bank работают ОЧЕHЬ
A>> большие банки типа Банка Москвы, Собинбанка или региональных
A>> тербанков СБ РФ.
То что эти банки используют RS, это не значит что система хорошая.
Тут Вам надо уточнить какую часть этой кучи, называемой RS-BANK,
эти банки используют. В этих банках часть RSа используется как
часть общего винегрета.
A>> Теперь по физлицам. RS-Retail реально
A>> поддерживает базы порядка 600.000 счетов и все работает.
Про это сказать ничего не могу, очевидно что написано позже,
значет учли ошибки сделаные в RS-BANK.
VV> А думает он так потому, что видимо имел опыт работы с RS-Bank. Могу
VV> только подтвердить вышесказанное.
VV> Я бы сказал даже так: более-менее рабочий модуль - это опердень, но и
VV> в нем предостаточно граблей( картотека к примеру ). Вообще, если бы не
VV> RSL ( спасибо Кубрину ) - погибель бы наступила. Ради интереса можно
VV> почитать файлик из дистрибутива с описанием ошибок в RS-Bank - волосы
VV> дыбом встают.
Основные грабли в том что база данных не нормализована.
(Относится к RS-BANK). В базе _первой_нормальной_формой_ не пахнет.
Одно то, что остаток по счету хранится в четырех местах Ж:-О
чего стоит. И если писать макрос, надо знать в каком месте
он правильный в данный момент. :) Справочник счетов хранится
в нескольких таблицах с почти одинаковой структурой.
И совершенно нет смысла переносить систему на другую платформу
СУБД : первасив или оракл, все равно кривые структуры остануться
кривыми.
И еще много чего плохого, например то, что в языке RSL не предусмотрен
отладчик.
VV> P.S. Все вышесказанное относится к версиям ( сборкам ;) ниже пятерки.
Это относится ко всем сборкам.
Главная проблема в том что:
1. Структура базы данных кривая (не нормализована)
2. Под эту кривую структуру юзерами понаписано куча макросов.
3. Фирма R-STYLE _HЕ_БУДЕТ_ менять структуры никогда, потому что
у юзеров перестанут работать макросы. А это скандал.
Фирме надо писать совершенно новый продукт,
с нормализованной базой данных, а не дурить клиентов всякими "пятерками".
"Пятерка" - чисто рекламный финт. Структуры те же.
Все остальное то что в RS плохо - это производное от кривых структур,
а если что и хорошо - это потому что трудности были кем-то героически
преодолены.
Удачи всем
Ляпун Василий
Dim
>Прошу прощения за то, что влезаю в разговор, не имея опыта общения с
>сабжем. Однако же я слышал краем глаза, что при работе в "архивных" днях
>в RS возникают бааальшие тормоза.
Александр, я работал и с Кворумом, и с RS. Если сравнивать быстродействие -
RS выигрывает (за счет 32-х разрядных модулей, или за счет 3-х звенной
архитектуры, или еще за счет чего - х.з.)
--
---
Успехов ! Жуков Дмитрий.
e-mail: d...@chat.ru
http://dd.chat.ru/
Alexander Turchin
>>Прошу прощения за то, что влезаю в разговор, не имея опыта общения с
>>сабжем. Однако же я слышал краем глаза, что при работе в "архивных"
днях
>>в RS возникают бааальшие тормоза.
> Александр, я работал и с Кворумом, и с RS. Если сравнивать
быстродействие -
> RS выигрывает (за счет 32-х разрядных модулей, или за счет 3-х звенной
> архитектуры, или еще за счет чего - х.з.)
Охотно верю - вполне может быть (если некий господин К* не возразит :-),
однако я спрашивал именно про работу в "архивных" днях. И не из
праздного интереса - некий банк, который должен нам предоставлять
ежедневную отчётность, тормозит и объясняет это геморройностью работы в
RS в архивной дате. Вот и хотелось бы выяснить, насколько эти байки
близки к действительности...
Alexander Cornett
19 Окт 00 09:30, Alexander Turchin" <tur...@psbank.ru> Reply-To: "Alexander
Turchin wrote to All:
[skp]
At> Охотно верю - вполне может быть (если некий господин К* не возразит
At> :-), однако я спрашивал именно про работу в "архивных" днях. И не
At> из праздного интереса - некий банк, который должен нам
At> предоставлять ежедневную отчётность, тормозит и объясняет это
At> геморройностью работы в RS в архивной дате. Вот и хотелось бы
At> выяснить, насколько эти байки близки к действительности...
мммм... что они имеют ввиду под работой в архивной дате?
если чето там править в документах, то imho это шарашкина контора.
отчеты за архивные дни работают нормально.
с достаточно приемлимой скоростью...
все, конечно, зависит от того, как танцуют танцы с бубнами шаманы,
настроившие всю эту систему. ;-)
Alexander Cornett
http://cornett.da.ru, mailto:cor...@mail.ru
Alexander Turchin
> мммм... что они имеют ввиду под работой в архивной дате?
Это когда проводки (АКА документы) задним числом делаются, меняются или
удаляются. А что ещё можно иметь в виду ?
> если чето там править в документах, то imho это шарашкина контора.
Why так безапелляционно ?
> отчеты за архивные дни работают нормально.
> с достаточно приемлимой скоростью...
> все, конечно, зависит от того, как танцуют танцы с бубнами шаманы,
> настроившие всю эту систему. ;-)
И всё же, может кто мне ответит - чтобы, например, исправить в RS'е
документ недельной давности - надо просто сменить опердень ? Или админ
должен выгнать юзеров из АБС и, выдёргивая волосы из носа и ушей,
творить заклинания и вызывать демонов ?
RomanM
> документ недельной давности - надо просто сменить опердень ? Или админ
> должен выгнать юзеров из АБС и, выдёргивая волосы из носа и ушей,
> творить заклинания и вызывать демонов ?
Опердень -> Балансовые счета -> Документы -> Архивные документы ->
Ввод архивного документа (пункты в меню)
Текущий опер день не меняется, никто не выгоняется. Только отчеты
перепечатать если в них что-то задето архивным документом.ъ
-----------------------
RomanM m...@fia.volga.ru
Alexey Donskoy
Среда Октябрь 18 2000 19:46, Vasiliy Lyapun послал Vyacheslav Vankevich:
VL> Все остальное то что в RS плохо - это производное от кривых структур,
VL> а если что и хорошо - это потому что трудности были кем-то героически
VL> преодолены.
Кроме качества структур баз данных есть еще критерии:
- функциональная полнота (не обеспечиваются все стандартные банковские
операции в соответствии с действующим законодательством, особенно в части
корсчетов и картотек);
- поддержание целостности баз данных (элементарно разрушается, например, при
удалении документа подсистемы вкладов или внебалансового документа от оплаты
картотеки);
- защита от ошибок пользователя (ее не только нет, ошибки провоцируются
кривизной интерфейса и вышеописанным недержанием целостности);
- открытость (если бы _все_ было б написано на RSL, можно было б все и
переписать. А тут - какой-то глюк можно обойти, какой-то - никак, потому что он
внутри системы производится);
- порочный принцип построения документации "по описанию интерфейса" вместо
описания конкретных операций (процессов); отсутствие документации по структуре
и взаимосвязи данных...
C уважением, Алексей Донской (aka Alek)
Oleg Kosolapov
Alexander Turchin <tur...@psbank.ru> сообщил в новостях
следующее:8sm0r1$1gd$1...@gavrilo.mtu.ru...
> >>Прошу прощения за то, что влезаю в разговор, не имея опыта общения с
> >>сабжем. Однако же я слышал краем глаза, что при работе в "архивных"
> днях
> >>в RS возникают бааальшие тормоза.
> Охотно верю - вполне может быть (если некий господин К* не возразит :-),
> однако я спрашивал именно про работу в "архивных" днях. И не из
> праздного интереса - некий банк, который должен нам предоставлять
> ежедневную отчётность, тормозит и объясняет это геморройностью работы в
> RS в архивной дате. Вот и хотелось бы выяснить, насколько эти байки
> близки к действительности...
Вопросы скорости построения отчетов относятся скорее к СУБД - битриву. Глюки
в большинстве случаев, имхо, дарит нам он же.
Если работал с этим зверем - скорость можешь прикинуть сам.
Размеры записей :
документ - 1кб.
счет - 1кб
остаток на дату 42 байта.
А дальше твои реалии.
Пользователей-идиотов, ставящих фильтр на список архивных документов за год
не рассматриваем. Нехитрые структуры баз и связей определяют незамысловатые
алгоритмы работы с ними. Так что тормозов в основных отчетах почти нет.
Баланс за день/месяц/квартал можно строить на основе только файла счетов.
Вроде так оно и делается, не поручусь, но довольно быстро. Свои отчеты
писать очень удобно. Логика хранения данных прозрачная. Индексов хватает. Да
их можно и добавить, в принципе. Если не лень писать отчеты с их
использованием :), выпускать их можно быстро. Плюс есть в битриве нечто SQL
подобное, работает, говорят ахово, но есть.
Логическая целостность данных разработчиков имхо не трогает абсолютно, что в
смысле скорости опять-таки хорошо :)
Вот и думай. Имхо RS хорош как удовлетворительная проводочная машинка +
великолепный инструмент создания отчетов.
Для больших банков вряд ли хорош, но какой банк для RS'а слишком большой
сказать очень трудно.
--
С уважением,
Косолапов Олег
Мне лучше писать на
Koso...@hotmail.ru
Oleg Verhovec
Hекогда, в 19 октябpя 2028, 16:10 какой(ая) то
Alexander Turchin отписал(а) к All
на тему: "Re: RS-Bank кто скажет хоpошего"
AT> И всё же, может кто мне ответит - чтобы, напpимеp, испpавить в RS'е
AT> документ недельной давности - надо пpосто сменить опеpдень ? Или админ
AT> должен выгнать юзеpов из АБС и, выдёpгивая волосы из носа и ушей,
AT> твоpить заклинания и вызывать демонов ?
^^^^^^^^^^^^^^^^^^^^^^^^
Hе то и не дpугое, пpосто заходишь в аpхивные документы и пpавишь/вводишь
документ.
Хотя подчеpкнутое можно изобpажать, а то любить не будут.
Alexander Cornett
19 Окт 00 16:10, Alexander Turchin" <tur...@psbank.ru> Reply-To: "Alexander
Turchin wrote to All:
>> мммм... что они имеют ввиду под работой в архивной дате?
At> Это когда проводки (АКА документы) задним числом делаются, меняются
At> или удаляются. А что ещё можно иметь в виду ?
>> если чето там править в документах, то imho это шарашкина
>> контора.
At> Why так безапелляционно ?
потому что это _не_нормально_!
масимум допустимого, я считаю, исправление в предыдудыщем архивном дне.
и то это должно быть достаточно строго.
>> отчеты за архивные дни работают нормально.
>> с достаточно приемлимой скоростью...
>> все, конечно, зависит от того, как танцуют танцы с бубнами
>> шаманы, настроившие всю эту систему. ;-)
At> И всё же, может кто мне ответит - чтобы, например, исправить в RS'е
At> документ недельной давности - надо просто сменить опердень ? Или админ
At> должен выгнать юзеров из АБС и, выдёргивая волосы из носа и ушей,
At> творить заклинания и вызывать демонов ?
там есть вообщемто исправление архивных проводок и пересчет архивных дней.
чем дальше от текущего опердня исправление,
тем дольше пересчет, естественно.
гораздо эффективней не допускать таких ситуаций, но это уже проблема
организации труда и внутренней дисциплины, которая к RS-Bank отношения
не имеет.
Alexander Kalyazin
19 Окт 00 16:10, Alexander Turchin wrote to All:
>> мммм... что они имеют ввиду под работой в архивной дате?
AT> Это когда проводки (АКА документы) задним числом делаются, меняются
AT> или удаляются. А что ещё можно иметь в виду ?
>> если чето там править в документах, то imho это шарашкина
>> контора.
AT> Why так безапелляционно ?
может потому что это действительно напрягает. Хотя нам самим, из-за пунктов по
приему платежей от населения, работать с архивными приходится каждый день, но
невозможность получения реального балланса и части отчетности в момент закрытия
- не есть хорошо.
>> отчеты за архивные дни работают нормально.
>> с достаточно приемлимой скоростью...
>> все, конечно, зависит от того, как танцуют танцы с бубнами
>> шаманы, настроившие всю эту систему. ;-)
И все же RS'овцам следовало бы изначально установить в базе архивных документов
дополнительные ключи. Одно дело работа с документами дня, другое выборка по
табле размером 1.5-2-3.... гига. Приходится под определенные задачи сначала
формировать свои базы с индексами, потом делать работу :(
AT> И всё же, может кто мне ответит - чтобы, например, исправить в RS'е
AT> документ недельной давности - надо просто сменить опердень ? Или админ
нет, просто сделать проводку за эту дату(изменить сумму проводки), если ему это
позволено своими правами в RS-Bank'е. Остатки поправятся системой.
AT> должен выгнать юзеров из АБС и, выдёргивая волосы из носа и ушей,
AT> творить заклинания и вызывать демонов ?
Угу, только не демонов, а главбуха: отчеты то все придется перепечатывать :-)
Alexey Donskoy
В Четверг Октябрь 19 2000 16:10, Alexander Turchin писал All:
>> мммм... что они имеют ввиду под работой в архивной дате?
AT> Это когда проводки (АКА документы) задним числом делаются, меняются
AT> или удаляются. А что ещё можно иметь в виду ?
А еще можно иметь в виду объективные организационные проблемы. Hапример,
мыполучаем итоговую выверку из РКЦ на следующий день утром. Следовательно,
утром же подбиваются бабки за вчерашний день и одновременно операционисты уже
должны начинать бить сегодняшние платежки. Способы решения могут быть такие:
- банки с большим количеством персонала могут ввести 2 смену, чтобы получать
выверки поздно вечером и закрывать день ночью;
- нормальные АБС позволяют держать открытыми одновременно несколько дней.
Поскольку RS-bank позволяет иметь только один текущий день, а закрытие дня -
процесс длительный (у нас занимает обычно больше часа с учетом резервного
копирования, ревизии счетов и проч.), то можно:
- утром всем работать в "планируемых документах", к примеру, до обеда, а в
обед закрывать день;
- закрывать день верчером, а утром подбивать бабки, работая в "архивных
документах".
И то, и другое чревато постоянными ошибками пользователей, равно как и
глюками RS при такой работе (особенно опять же с картотеками - труба дело).
Hаконец, ситуация (у нас) усугубляется тем, что мы филиал, и утром же должны
представить полную отчетность в центральный офис ;(
Alexander Cornett
20 Окт 00 08:24, Alexander Kalyazin wrote to Alexander Turchin:
[skp]
AK> может потому что это действительно напрягает. Хотя нам самим, из-за
AK> пунктов по приему платежей от населения, работать с архивными
AK> приходится каждый день, но невозможность получения реального балланса
AK> и части отчетности в момент закрытия - не есть хорошо.
а в чем проблема с пунктами по приему платежей?
у нас данные с обменных пунктов в конце дня приходят по модему,
и проводки делаются реальным днем.
т.е. на утро мы имеем все данные с пунктов и до завершения дня
формируются необходимые документы.
>>> отчеты за архивные дни работают нормально.
>>> с достаточно приемлимой скоростью...
>>> все, конечно, зависит от того, как танцуют танцы с бубнами
>>> шаманы, настроившие всю эту систему. ;-)
AK> И все же RS'овцам следовало бы изначально установить в базе архивных
AK> документов дополнительные ключи. Одно дело работа с документами дня,
AK> другое выборка по табле размером 1.5-2-3.... гига. Приходится под
AK> определенные задачи сначала формировать свои базы с индексами, потом
AK> делать работу :(
тут уж говорили об этом. все дело в кривизне инфологической модели.
мы поступаем проще.
всю неоюходимую информацию для аналитики заливаем в MS SQL,
ну, а дальше - "счастье есть" ;-)
Alexander Cornett
20 Окт 00 09:28, Alexey Donskoy wrote to Alexander Turchin:
>>> мммм... что они имеют ввиду под работой в архивной дате?
AT>> Это когда проводки (АКА документы) задним числом делаются,
AT>> меняются или удаляются. А что ещё можно иметь в виду ?
[skp]
AD> Поскольку RS-bank позволяет иметь только один текущий день, а
AD> закрытие дня - процесс длительный (у нас занимает обычно больше часа с
AD> учетом резервного копирования, ревизии счетов и проч.),
"ну вы, блин, даете" ;-))
т.е. более часа у вас клиенты сидят и ждут, когда же уже можно...
завершение операционного дня у нас занимает от 5 до 15 минут.
завершение происходит с 9 до 10 утра...
AD> то можно: - утром всем работать в "планируемых документах", к
AD> примеру, до обеда, а в обед закрывать день; - закрывать день
AD> верчером, а утром подбивать бабки, работая в "архивных документах". И
AD> то, и другое чревато постоянными ошибками пользователей, равно как и
AD> глюками RS при такой работе (особенно опять же с картотеками - труба
AD> дело).
мдааа... а с отложенными документами не пробовали работать?
в отложенные ты можешь хоть послезавтрашние документы вколачивать,
а потом по наступлении нужного операционного дня проводить.
ошибки пользователей это уже не проблема RS.
пару раз сотруднику обратите внимание на недопустимость безалаберного
отношения к процессу производства - будет делать все быстро и правильно.
проверено неоднакратно.
Alexander Kalyazin
20 Окт 00 13:24, Alexander Cornett wrote to Alexander Kalyazin:
AK>> может потому что это действительно напрягает. Хотя нам самим,
AK>> из-за пунктов по приему платежей от населения, работать с
AK>> архивными приходится каждый день, но невозможность получения
AK>> реального балланса и части отчетности в момент закрытия - не есть
AK>> хорошо.
AC> а в чем проблема с пунктами по приему платежей?
AC> у нас данные с обменных пунктов в конце дня приходят по модему,
AC> и проводки делаются реальным днем.
AC> т.е. на утро мы имеем все данные с пунктов и до завершения дня
AC> формируются необходимые документы.
проблема в количестве субъектов получения платежей, так как помимо коммуналки,
газа и т.п. имеются платежи в бюджет, внебюджет и другие, где требуется, в
отличие от первых, заводить данные отдельной строкой на платеж. А на
большинстве пунктов автоматизация только делается. То есть пока стоит кассовый
аппарат и никакого АРМ'а. Информация о платежах поступает после инкассации. В
общем, все справедливо - работа в архиве есть нонсенс, вызванный плохой
организацией работы.
Alexey Donskoy
В Пятница Октябрь 20 2000 13:37, Alexander Cornett писал Alexey Donskoy:
AC> "ну вы, блин, даете" ;-))
Цыц! ;-0
Тут был сабж, и тут был ответ на вопрос, какая необходимость работать в
архивном дне, а вовсе не обсуждение конкретной технологии!
AC> завершение операционного дня у нас занимает от 5 до 15 минут.
AC> завершение происходит с 9 до 10 утра...
Сам перечитай свои слова и ответь - таки 5 минут или 60 минут? ;)
Разумеется, длительность процесса зависит от мощности техники и пропускной
способности сети. От архитектуры тоже (у вас, поди, трехзвенка). Hу и от
размера баз и количества документов.
Btw, в моей программе день переключался меньше чем за секунду ;) О чем все
это говорит? О кривизне соответствующих технологических решений. ИМХО, само
наличие процесса "завершение дня" выглядит странно. Как должно быть? А примерно
так: народ работает (каждый в том дне, который ему нужен). Главбух (или кто там
ответственный) смотрит баланс нужного дня и говорит "все, день такой-то закрыт.
Все дальнейшие изменения - только через меня" - и вешает флаг, запрещающий
доступ в указанный день. И все.
AC> мдааа... а с отложенными документами не пробовали работать?
Как бишь операции по вкладам в отложенные класть, а? Или частичное списание
из Картотеки-2? Или сложные проводки по валюте?
AC> в отложенные ты можешь хоть послезавтрашние документы
AC> вколачивать, а потом по наступлении нужного операционного дня
AC> проводить.
Ага, понял, вы ж, поди, RS-bank используете как машину проводок, а картотеки
девочки ручками ведут? ;)
AC> ошибки пользователей это уже не проблема RS.
AC> пару раз сотруднику обратите внимание на недопустимость
AC> безалаберного отношения к процессу производства - будет делать все
AC> быстро и правильно.
А это мнение уже показательно. Оно обычно характеризует отношение софтверной
фирмы к эксплуатации своего продукта. "Hа то банковским служащим такую зарплату
и платят, чтобы ошибок не делали" (с) R-Style Software Labs.
Однако ты же, надеюсь, не маркетолог производителя, зачем говоришь себе в
убыток? ;)
Alexander Cornett
20 Окт 00 12:41, Alexander Kalyazin wrote to Alexander Cornett:
AK>>> может потому что это действительно напрягает. Хотя нам самим,
AK>>> из-за пунктов по приему платежей от населения, работать с
AK>>> архивными приходится каждый день, но невозможность получения
AK>>> реального балланса и части отчетности в момент закрытия - не
AK>>> есть хорошо.
AC>> а в чем проблема с пунктами по приему платежей?
AC>> у нас данные с обменных пунктов в конце дня приходят по
AC>> модему, и проводки делаются реальным днем. т.е. на утро мы
AC>> имеем все данные с пунктов и до завершения дня формируются
AC>> необходимые документы.
AK> проблема в количестве субъектов получения платежей, так как помимо
AK> коммуналки, газа и т.п. имеются платежи в бюджет, внебюджет и другие,
AK> где требуется, в отличие от первых, заводить данные отдельной строкой
AK> на платеж. А на большинстве пунктов автоматизация только делается. То
AK> есть пока стоит кассовый аппарат и никакого АРМ'а. Информация о
AK> платежах поступает после инкассации. В общем, все справедливо - работа
AK> в архиве есть нонсенс, вызванный плохой организацией работы.
ясно.
непочатый край работы по малой механизации умственного труда ;-))
Vyacheslav Vankevich
VL> 13 Окт 00 09:09, Vyacheslav Vankevich -> Accounter:
IV>>>> стороны руководства к качеству
IV>>>> системы поддержки принятия решений - RS-Bank
IV>>>> почти идеальная система.
VL> IMHO Это идеальная система для 95 года но не сейчас.
VL> Плавали знаем :-)
Вообще-то это не мне объяснять надо было.
VL> Основные грабли в том что база данных не нормализована.
VL> (Относится к RS-BANK). В базе _первой_нормальной_формой_ не пахнет.
VL> Одно то, что остаток по счету хранится в четырех местах Ж:-О
VL> чего стоит. И если писать макрос, надо знать в каком месте
VL> он правильный в данный момент. :) Справочник счетов хранится
VL> в нескольких таблицах с почти одинаковой структурой.
;) Я полагаю, что в начале разработки у р-стайловцев и мысли не было ни о каких
нормальных формах ;) Вообще, глядя на сишные хэдеры от 4.1 создается
впечатление, что писалось все на коленке.
VV>> P.S. Все вышесказанное относится к версиям ( сборкам ;) ниже
VV>> пятерки.
VL> Это относится ко всем сборкам.
Приятно было узнать что ничего не изменилось. Значит правильно сделали, что не
перешли на 5-ку ;)
VL> "Пятерка" - чисто рекламный финт. Структуры те же.
sf...@online.ru WBR, Vyacheslav.
Dim
>Приветствую Вас, Дмитрий Жуков !
>
>RS в архивной дате. Вот и хотелось бы выяснить, насколько эти байки
>близки к действительности...
Думаю, проблемы чисто организационные и к RS никакого отношения не имеют.
V. Papkov
> Hello Alexey!
>
> AD> Поскольку RS-bank позволяет иметь только один текущий день, а
> AD> закрытие дня - процесс длительный (у нас занимает обычно больше часа с
> AD> учетом резервного копирования, ревизии счетов и проч.),
>
> "ну вы, блин, даете" ;-))
> т.е. более часа у вас клиенты сидят и ждут, когда же уже можно...
>
> завершение операционного дня у нас занимает от 5 до 15 минут.
> завершение происходит с 9 до 10 утра...
В RS- Bank'e тоже день не долго закрывается. Потом (или перед) базы долго
сохраняются на предмет сбоя. А так очень даже все быстро.
Работа в архиве - эта тема для поддерживающих RS-Bank непонятна приблизительно
так же, как вопрос рыбе - а как ты плаваешь? Нет такого вопроса для поддержки -
работа в архиве. Для выпускающих отчеты - есть. И они обращаются к
администраторам RS для ограничения доступа. Но с технологической точки зрения, в
случае проводки (изменении даты проводки, изменении суммы и тп) в архиве никто
(включая администратора) может не знать, что это происходит.
И поэтому, на счет "ну вы блин даете". Приняли выписку, закрыли день, а дальше
работа как в текущем дне, та и в архиве. Много геморроя? Много. Есть другие и
варианты.
Но нет маразма с перезакрыванием дней. И все это потому, что в RS не такого
понятия как остаток по балансовому счету.
И еще вопрос к <Ляпун Василий>. И где ж ты увидел хранение остатков по л/с в 4
местах? И как в навигационной БД должна поддерживаться 1НФ.
Ну а качестве хаяния, а могу сказать, что пытаюсь сейчас автоматизировать расчет
срочных расшифровок. для Ф1. И очень геморройно все это. И в RS этого нет. Не
смотря на ихнюю подсистему отчеты ЦБ.
Так вот, если у кого то есть пример на основе стандартных АБС о полной, или
частичной, автоматизации этих ежемесячно требуемых данных, поделитесь, как это
происходит. И на основе конкретного параметра для ЦБшных отчетов, мы уже сможем
сделать вывод о ..., ну скажем так, возможности АБС снять часть напряжения с
отдела автоматизации.
В. Папков
Alexander Kalyazin
22 Окт 00 00:19, V. Papkov wrote to All:
[...]
VP> Hу а качестве хаяния, а могу сказать, что пытаюсь сейчас
VP> автоматизировать расчет срочных расшифровок. для Ф1. И очень
VP> геморройно все это. И в RS этого нет.
в RS'е, в таблах счетов есть поля срока и начала действия. В экранных формах
л/c они не видны. Заполнение и юзание через соответствующие подсистемы. Hо для
отчетов по вкладным и кредитным используем параметры договоров - легче сделать
перекрестные прверки на некорректное ведение договоров юзерами. Депозитный
модуль не используем - поэтому работа с этими полями реализована своими
макросами.
VP> Hе смотря на ихнюю подсистему отчеты ЦБ.
да, к сожалению, "отчеты ЦБ" потрясающе криво продуманы с точки зрения
использования экономистом средней сообразительности. Хотя что-то из
представленного там весьма облегчает жизнь автоматизаторов.
Alexander Turchin
> >> если чето там править в документах, то imho это шарашкина
> >> контора.
> At> Why так безапелляционно ?
> потому что это _не_нормально_!
> масимум допустимого, я считаю, исправление в предыдудыщем архивном
дне.
> и то это должно быть достаточно строго.
Это идеал с кочки зрения автоматизатора... Реальность - у нас
исправления идут в течение месяца.
[skip]
> гораздо эффективней не допускать таких ситуаций, но это уже
проблема
> организации труда и внутренней дисциплины, которая к RS-Bank
отношения
> не имеет.
В отношении ошибок операционистов - согласен. Однако внутрибанковские
операции специалистам по учёту довольно часто нужно править "задним
числом" (по крайней мере у нас) - по тысяче причин, не связанных с
понятием "ошибка". Причем речь идёт о правке, НЕ затрагивающей уже
сданную ЦБшную отчётность. Конечно, запретить "архивную" деятельность
проще, но кто сказал, что это есть хорошо для банка ?
Alexander Cornett
20 Окт 00 13:57, Alexey Donskoy wrote to Alexander Cornett:
[skp]
AC>> завершение операционного дня у нас занимает от 5 до 15 минут.
AC>> завершение происходит с 9 до 10 утра...
AD> Сам перечитай свои слова и ответь - таки 5 минут или 60 минут? ;)
повторяю, для особо умных, с 9 до 10 утра по состоянию готовности
документов дня, связанных с различными задержками, происходит
процедура завершения операционного дня, которая длится от 5 до 15 минут.
;-)
AD> Разумеется, длительность процесса зависит от мощности техники и
AD> пропускной способности сети. От архитектуры тоже (у вас, поди,
AD> трехзвенка). Hу и от размера баз и количества документов. Btw, в моей
AD> программе день переключался меньше чем за секунду ;)
что значит переключался? ;-)
AD> О чем все это говорит? О кривизне соответствующих технологических
AD> решений. ИМХО, само наличие процесса "завершение дня" выглядит
AD> странно. Как должно быть? А примерно так: народ работает (каждый в
AD> том дне, который ему нужен). Главбух (или кто там ответственный)
AD> смотрит баланс нужного дня и говорит "все, день такой-то закрыт. Все
AD> дальнейшие изменения - только через меня" - и вешает флаг,
AD> запрещающий доступ в указанный день. И все.
вот я и говорю - шарашкина контора. ;-)
банк это не склад малого предприятия, где как хочу так и ворочу.
AC>> мдааа... а с отложенными документами не пробовали работать?
AD> Как бишь операции по вкладам в отложенные класть, а? Или частичное
AD> списание из Картотеки-2? Или сложные проводки по валюте?
так и класть. формируешь документы, проверяешь и проводишь. ;-)
AC>> в отложенные ты можешь хоть послезавтрашние документы
AC>> вколачивать, а потом по наступлении нужного операционного дня
AC>> проводить.
AD> Ага, понял, вы ж, поди, RS-bank используете как машину проводок, а
AD> картотеки девочки ручками ведут? ;)
ммм... а разве речь шла о том, как картотеки вести и вклады?
AC>> ошибки пользователей это уже не проблема RS.
AC>> пару раз сотруднику обратите внимание на недопустимость
AC>> безалаберного отношения к процессу производства - будет делать
AC>> все быстро и правильно.
AD> А это мнение уже показательно. Оно обычно характеризует отношение
AD> софтверной фирмы к эксплуатации своего продукта. "Hа то банковским
AD> служащим такую зарплату и платят, чтобы ошибок не делали" (с) R-Style
AD> Software Labs. Однако ты же, надеюсь, не маркетолог производителя,
AD> зачем говоришь себе в убыток? ;)
ни в коем разе... ;-)
я, конечно, же как и многие тут, поплевываюсь от RS.
но тем не менее, считаю, что при наличии некоторой сноровки с ним
можно жить, не обращаясь в саму фирму-производитель, ибо это
(по моему опыту) ничего путного не даст ;(
Alexander Turchin
> AD> О чем все это говорит? О кривизне соответствующих технологических
> AD> решений. ИМХО, само наличие процесса "завершение дня" выглядит
> AD> странно. Как должно быть? А примерно так: народ работает (каждый
в
> AD> том дне, который ему нужен). Главбух (или кто там ответственный)
> AD> смотрит баланс нужного дня и говорит "все, день такой-то закрыт.
Все
> AD> дальнейшие изменения - только через меня" - и вешает флаг,
> AD> запрещающий доступ в указанный день. И все.
>
> вот я и говорю - шарашкина контора. ;-)
> банк это не склад малого предприятия, где как хочу так и ворочу.
Учёт в банке - это не самоцель, а средство (в ряду многих других)
зарабатывания и/или недопущения потери денег. И настоящий рулез состоит
совсем не в том, чтобы в целях поддержания бухгалтерского орднунга
запрещать работу в архивном дне. А в том, чтобы иметь возможность
корректировать документы "задним числом", не устраивая при этом бардака
в учёте и чтобы ЦБшные проверки и прочие налоговые инспекции не могли
придраться. Имхо.
WBR, Александр Турчин.
-- Заходите ко мне в гости на http://aturchin.travel.ru --
ЗЫ. А не "шарашкина контора" - это та, которая закрывает ОД день в день
и ещё, по - видимому, честно налоги всяческие платит, не выгадывая на
несовершенстве законов и инструкций себе ни копейки, так, что ли ? Эдак
и проторговаться недолго...
Vasiliy Lyapun
22 Окт 00 00:19, V. Papkov -> All:
VP> И поэтому, на счет "ну вы блин даете". Приняли выписку, закрыли день,
VP> а дальше работа как в текущем дне, та и в архиве. Много геморроя?
VP> Много. Есть другие и варианты. Hо нет маразма с перезакрыванием дней.
VP> И все это потому, что в RS не такого понятия как остаток по
VP> балансовому счету.
И это хорошо :-), только вот реализация плана счетов кривовата. :(
Для того что бы получить баланс
по второму порядку - нужен один план счетов
по третьему порядку другой, и т.д.
И для всего этого несчастные бухгалтера "вяжут"
счета к двум планам счетов, а ведь можно использовать
один, при условии грамотного построения базы и алгоритмов.
VP> И еще вопрос к <Ляпун Василий>. И где ж ты увидел хранение остатков
VP> по л/с в 4 местах?
Виноват..., не четырех, а только в трех. :-)
Для рублевых счетов таблицы ACCOUNT, RESTDATE, VALDAT.
Справочник валютных счетов хранится в двух таблицах со схожими структурами, и
соответственно еще три таблицы
валютных остатков.
VP> И как в навигационной БД должна поддерживаться 1HФ.
Вот уже и отсутствие 1HФ, а есть еще две таблицы счетов
для остальных глав баланса и соответственно шесть таблиц для них.
И при чем тут навигационная база и 1HФ ?
Тут я действительно чего-то не понимаю.
Всего получается двенадцать таблиц остатков
и четыре таблицы счетов.
(где-то в недрах RS есть еще таблицы с остатками я уже не помню, раньше
когда-то, когда знимался RS-ом,
насчитал 18. Уже два года как отбодался от него)
А вот как надо бы:-)
1. Одна таблица счетов.
2. Одна таблица остатков четырмя полями для остатков:
Рубли по дате в балансе, рубли по дате валютирования,
валюта по дате в балансе , валюта по дате валютирования.
Удачи
Ляпун Василий
Alexander Cornett
23 Окт 00 18:55, Alexander Turchin" <tur...@psbank.ru> Reply-To: "Alexander
Turchin wrote to All:
[skp]
At> ЗЫ. А не "шарашкина контора" - это та, которая закрывает ОД день в
At> день и ещё, по - видимому, честно налоги всяческие платит, не
At> выгадывая на несовершенстве законов и инструкций себе ни копейки, так,
At> что ли ? Эдак и проторговаться недолго...
история показывает, что гораздо выгоднее быть честным, делать все
вовремя и корректно.
надо быть проще и клиенты сами потянутся :-))
Alexander Turchin
> At> ЗЫ. А не "шарашкина контора" - это та, которая закрывает ОД день
в
> At> день и ещё, по - видимому, честно налоги всяческие платит, не
> At> выгадывая на несовершенстве законов и инструкций себе ни копейки,
так,
> At> что ли ? Эдак и проторговаться недолго...
>
> история показывает, что гораздо выгоднее быть честным, делать все
> вовремя и корректно.
:-) Неужели город Е-бург находится на Марсе и там не действуют
российские реалии экономической жизни ? "Честность" в бухучёте - понятие
весьма относительное... Вот если вернуться к предыстории вопроса про
работу в архивных днях : какая инструкция ЦБ запрещает, скажем, 15
октября поправить документ за 3 октября таким образом, что это не
затронет ни одну из многочисленных ранее сданных форм отчётности ?
> надо быть проще и клиенты сами потянутся :-))
Это так надо понимать, что стаи курлыкающих клиентов потянутся в более
тёплые места, чем "правильный" банк ? :-)
Alexander Cornett
24 Окт 00 14:50, Alexander Turchin" <tur...@psbank.ru> Reply-To: "Alexander
Turchin wrote to All:
[skp]
At> :-) Hеужели город Е-бург находится на Марсе и там не действуют
At> российские реалии экономической жизни ? "Честность" в бухучёте -
At> понятие весьма относительное... Вот если вернуться к предыстории
At> вопроса про работу в архивных днях : какая инструкция ЦБ запрещает,
At> скажем, 15 октября поправить документ за 3 октября таким образом, что
At> это не затронет ни одну из многочисленных ранее сданных форм
At> отчётности ?
ну если в архивных документах не менять суммы и счета, то
такие изменения не затронут никакой отчетности.
или, скажем, разбить одну проводку на несколько...
но речь то не об этом или я чего не понимаю?
Alexey Donskoy
Сначала не хотел отвечать, потом решился, справедливости ради, чтобы у народа
не осталось слишком радужного представления ;)
Поскольку реь шла не о распальцованном базаре, у кого техника круче и
скорость выше, а о техническом решении отличия архивного дня от текущего.
В Понедельник Октябрь 23 2000 08:46, Alexander Cornett писал Alexey Donskoy:
AD>> Разумеется, длительность процесса переключения зависит от мощности
AD>> техники и пропускной способности сети. От архитектуры тоже (у вас,
AD>> поди, трехзвенка). Hу и от размера баз и количества документов. Btw,
AD>> в моей программе день переключался меньше чем за секунду ;)
AC> что значит переключался? ;-)
Значит, что было тоже неоптимальное техническое решение, в котором день
текущий был некоторым образом выделенным. Потому требовался специальный процесс
"закрытие дня" ака "переключение дня". Единственное, чем такое решение можно
оправдать - это огромным объемом ежедневных документов. Да и то - неоднозначно.
В остальном - сплошные минусы. Если процесс проводки документа текущего дня и
архивного дня существенно различается (как в RS-bank) - это а)потенциальное
снижение надежности системы, б)экспоненциальное усложнение сопровождения
(написания всяких выборок, отчетов (а если еще учесть _разную_ структуру баз в
RS))...
Btw, вот глюк навскидку припомнил - при автоматическом формировании архивных
проводок напрочь теряется ИHH плательщика/получателя (хотя поле в архивной базе
имеется). Как уж они такое исхитрили? ;)
Потому грамотная система должна обеспечивать _одним и тем же механизмом_
проводку документов за любой день, а допустимость даты документа - зависит от
подсистемы санкционирования доступа. И процедуры "закрытия дня" тоже быть как
таковой не должно вообще - должно быть опять же управление доступом.
Btw, если ты предложишь нормальному бухгалтеру систему без возможности работы
в "архивных днях", он не будет даже с тобой разговаривать ;)
AC>>> мдааа... а с отложенными документами не пробовали работать?
AD>> Как бишь операции по вкладам в отложенные класть, а? Или
AD>> частичное списание из Картотеки-2? Или сложные проводки по
AD>> валюте?
AC> так и класть. формируешь документы, проверяешь и проводишь. ;-)
Так попробуй ;) Частичная оплата картотеки-2 - идет, естественно, в
планируемые. И это, в общем-то, правильно. А вот вклады вообще не работают:
"дата проводки не может быть больше текущей". ;(
AC>>> в отложенные ты можешь хоть послезавтрашние документы
AC>>> вколачивать, а потом по наступлении нужного операционного дня
AC>>> проводить.
AD>> Ага, понял, вы ж, поди, RS-bank используете как машину
AD>> проводок, а картотеки девочки ручками ведут? ;)
AC> ммм... а разве речь шла о том, как картотеки вести и вклады?
Хочешь, я тебе, такому быстрому, байку расскжу? ;) Вот пристали ко мне
мои бухгалтеры с очередной просьбой автоматизации некоего действия. Я, конечно,
упираюсь - опять в структуре кривых баз разбираться, макросы писать ;( А вот,
говорят мне, там-то и там-то все давно автоматизировано, позвони и наберись
опыта ;) Звоню и выясняю - они там, оказываются, считают на калькуляторе,
делают ручками проводку в RS, потом цифирки из выписки ручками вбивают в Excel
и получают то, что требовалось. И при этом искренне думают, что у них все
автоматизировано - ведь компьютер же в процессе используется ;) М-м...да-а...
Alexander Kalyazin
25 Окт 00 09:35, Alexey Donskoy wrote to Alexander Cornett:
[...]
AD>>> тоже (у вас, поди, трехзвенка). Hу и от размера баз и количества
AD>>> документов. Btw, в моей программе день переключался меньше чем
AD>>> за секунду ;)
AC>> что значит переключался? ;-)
AD> Значит, что было тоже неоптимальное техническое решение, в котором
AD> день текущий был некоторым образом выделенным. Потому требовался
AD> специальный процесс "закрытие дня" ака "переключение дня".
AD> Единственное, чем такое решение можно оправдать - это огромным объемом
AD> ежедневных документов.
я так думаю, что такое решение вытекает из формирования технологии работы с
упором на документы, а не на счета и действия над ними. Сама идея достаточно
здравая, но минимизируя элемент процесса до документа, следует максимизировать
и скорость реакции системы на изменения в таблицах. Что на базе Btrieve
достаточно криво. Отсюда и дополнительные надстройки ввиде накопления по счетам
и самой процедуры "закрытия". В конце-концов изначально RS позиционировался как
инструмент для средних и мелких банков. Проектировали бы сразу на SQL, так ,
может, и накопления по счетам бы не пришлось делать, а решать на основании
текущего запроса.
AD> Да и то - неоднозначно. В остальном - сплошные
AD> минусы. Если процесс проводки документа текущего дня и архивного дня
AD> существенно различается (как в RS-bank) - это а)потенциальное снижение
да чем же уж так он существенно отличается? Тем что транзакция затронет не
один, а несколько дней? Какое-то не програмистское понимание процесса :-)
AD> надежности системы, б)экспоненциальное усложнение сопровождения
AD> (написания всяких выборок, отчетов (а если еще учесть _разную_
AD> структуру баз в RS))...
пардон, о чем речь? ARHDOCviaDOCUMENT? Дык они не отличаются, кроме
использования в одном случае в качестве ключа даты проводки, в другом -
автоинкрементного ключа. И некоторых отличий в ключах вообще. В остальном одна
структура мягко ложится в другую. А то что эти две базы разнесены - так слава
богу. Согласись, что 99% процентов работы банка в текущем дне, зачем же
лопатить постоянно архив?
AD> Btw, вот глюк навскидку припомнил - при
AD> автоматическом формировании архивных проводок напрочь теряется ИHH
AD> плательщика/получателя (хотя поле в архивной базе имеется). Как уж они
AD> такое исхитрили? ;)
специально сделал несколько проводок из разных мест в архив - не заметил
данного эффекта. Хотя когда-то что-то, припоминаю, было. Либо сами исправили,
либо с очередной сборкой ушло.
AD> Потому грамотная система должна обеспечивать _одним и тем же
AD> механизмом_ проводку документов за любой день, а допустимость даты
AD> документа - зависит от подсистемы санкционирования доступа. И
AD> процедуры "закрытия дня" тоже быть как таковой не должно вообще -
AD> должно быть опять же управление доступом.
Это просто другой подход к формированию информационной базы банка, RS дает
один, но существуют и другие.
AD> Btw, если ты предложишь нормальному бухгалтеру систему без
AD> возможности работы в "архивных днях", он не будет даже с тобой
AD> разговаривать ;)
AC>>>> мдааа... а с отложенными документами не пробовали работать?
AD>>> Как бишь операции по вкладам в отложенные класть, а? Или
AD>>> частичное списание из Картотеки-2? Или сложные проводки по
AD>>> валюте?
AC>> так и класть. формируешь документы, проверяешь и проводишь.
AC> >; -)
AD> Так попробуй ;) Частичная оплата картотеки-2 - идет, естественно, в
AD> планируемые. И это, в общем-то, правильно. А вот вклады вообще не
AD> работают: "дата проводки не может быть больше текущей". ;(
И правильно! Hо, строго говоря, лучше бы сказать иначе - "почему в RS'е не
реализован системный механизм привязки из вкладов планируемых и архивных
документов". И послать в саппорт :-)
А если бы рстуловцы это сделали, то я постарался бы все работу юзеров по
кредитам/вкладам/депозитам в будущее - прикрыть. Ибо нефиг, 39-П никто не
отменял и лепить проводки в будущее при существующей системе отчетности по
привлеченным/размещенным - усложнять жизнь автоматизаторам поиском очередных
экономически безграмотных действий.
AC>>>> в отложенные ты можешь хоть послезавтрашние документы
AC>>>> вколачивать, а потом по наступлении нужного операционного дня
AC>>>> проводить.
AD>>> Ага, понял, вы ж, поди, RS-bank используете как машину
AD>>> проводок, а картотеки девочки ручками ведут? ;)
AC>> ммм... а разве речь шла о том, как картотеки вести и вклады?
AD> Хочешь, я тебе, такому быстрому, байку расскжу? ;) Вот пристали ко
AD> мне мои бухгалтеры с очередной просьбой автоматизации некоего
AD> действия. Я, конечно, упираюсь - опять в структуре кривых баз
AD> разбираться, макросы писать ;( А вот, говорят мне, там-то и там-то все
хе-хе, а за что вы, батенька, зарплату получаете, как не за это? :-)
WBR, Alexander.
Pavel Kingsep
Wednesday October 25 2000 09:35, you написал(а) Alexander Cornett:
AD> Потому грамотная система должна обеспечивать _одним и тем же
AD> механизмом_ проводку документов за любой день, а допустимость даты
AD> документа - зависит от подсистемы санкционирования доступа. И
AD> процедуры "закрытия дня" тоже быть как таковой не должно вообще -
AD> должно быть опять же управление доступом.
Хорошо. Hо есть объективное понятие - смена дня. Hа которое повешены события
"переоценка", "парные счета", "расчет наращенных процентов" и т.п. Оно ведь всё
равно остается, разве нет?
С уважением, Паша
Nikolay Belov
message news:9723...@p114.f20.n5021.z2.ftn...
Э-эх... Специалисты по "нормальным формам".
Делается одна таблица остатков, (это правильно), а в ней - _две_ колонки -
одна - "тип остатка", вторая - "сумма остатка", впрочем, в "сумму остатка",
при желании, можно включить несколько колонок - сумма в валюте, приведенная
сумма...
> Удачи
>
> Ляпун Василий
--
Николай Белов.
Alexey Donskoy
В Среда Октябрь 25 2000 14:10, Pavel Kingsep писал Alexey Donskoy:
AD>> И процедуры "закрытия дня" тоже быть как таковой не должно вообще
AD>> - должно быть опять же управление доступом.
PK> Хорошо. Hо есть объективное понятие - смена дня. Hа которое повешены
PK> события "переоценка", "парные счета", "расчет наращенных процентов" и
PK> т.п. Оно ведь всё равно остается, разве нет?
Остается, к сожалению. И это сильно усложняет алгоритмы. Хотя таки поддается
автоматизации.
Тем не менее, в том же RS-bankе разработчики решили голову не ломать - там
переоценки и регулирования парных счетов никак к закрытию дня не привязаны и
выполняются бухгалтерами отдельно. В т.ч. и после архивных проводок, если
возникла такая необходимость.
Dim
>И это хорошо :-), только вот реализация плана счетов кривовата. :(
>Для того что бы получить баланс
>по второму порядку - нужен один план счетов
>по третьему порядку другой, и т.д.
>И для всего этого несчастные бухгалтера "вяжут"
>счета к двум планам счетов, а ведь можно использовать
>один, при условии грамотного построения базы и алгоритмов.
Ну ты, Vasiliy, LyapNUL !!! :-0
Кто же тебе запрещает использовать один ?
>Всего получается двенадцать таблиц остатков
>и четыре таблицы счетов.
Разные (по смыслу) остатки - разные таблицы. Можно, конечно, все хранить в
одной, навесить на нее доп.поля (и соответствующие ключи), только зачем ?
Скорость работы от этого не выиграет. Ради приближения к теоретическому
постулату ?
И кроме того, так исторически сложилось, что был отдельно рублевый и
валютный опердень, вклады, кредиты и еще куча модулей, которые банки могут
устанавливать в любом сочетании. Для всех этих модулей изобрести единую
прекрасную и универсальную структуру базы, которая бы еще не менялась во
времени, отвечала бы всем нормальным и ненормальным формам, учитывала
возможные закидоны ЦБ, и т.д. и т.п. - это задача практически нерешаемая (то
есть порешать ее ты можешь в течение всей своей жизни, но банку надо
работать уже сейчас).
>А вот как надо бы:-)
>1. Одна таблица счетов.
>2. Одна таблица остатков четырмя полями для остатков:
> Рубли по дате в балансе, рубли по дате валютирования,
> валюта по дате в балансе , валюта по дате валютирования.
Надеюсь, в твоей системе все действительно так прекрасно. Кстати, что за
система ?
И сидят ли в этих таблицах счета и остатки: частных вкладчиков, основных
фондов, зарплаты и т.п. ?
Pavel Kingsep
Wednesday October 25 2000 16:57, you написал(а) me:
AD> Тем не менее, в том же RS-bankе разработчики решили голову не ломать
AD> - там переоценки и регулирования парных счетов никак к закрытию дня не
AD> привязаны и выполняются бухгалтерами отдельно. В т.ч. и после архивных
AD> проводок, если возникла такая необходимость.
Я это знаю - не могу сказать, что восхищен их решением. Скажем так - логично,
если урегулирование парных выполняется в конце дня, а переоценка - в начале.
И нет простого алгоритма обхода теоретически возможной ситуации - изменили
архивный документ -> изменилась переоценка -> изменились доходы/расходы ->
вместо убытков стала прибыль.
С уважением, Паша
Alexey Donskoy
В Четверг Октябрь 26 2000 14:27, Pavel Kingsep писал Alexey Donskoy:
PK> Я это знаю - не могу сказать, что восхищен их решением. Скажем так -
PK> логично, если урегулирование парных выполняется в конце дня, а
PK> переоценка - в начале. И нет простого алгоритма обхода теоретически
PK> возможной ситуации - изменили архивный документ -> изменилась
PK> переоценка -> изменились доходы/расходы -> вместо убытков стала
PK> прибыль.
А интересно, эта ситуация вообще однозначно решается ли? Помнится, летом
1997, при обсуждении HПС, представителям ЦБ был задан подобный вопрос - ничего
вразумительного так и не ответили ;(
Pavel Kingsep
Friday October 27 2000 10:07, you написал(а) me:
PK>> дня, а переоценка - в начале. И нет простого алгоритма обхода
PK>> теоретически возможной ситуации - изменили архивный документ ->
PK>> изменилась переоценка -> изменились доходы/расходы -> вместо
PK>> убытков стала прибыль.
AD> А интересно, эта ситуация вообще однозначно решается ли? Помнится,
AD> летом 1997, при обсуждении HПС, представителям ЦБ был задан подобный
AD> вопрос - ничего вразумительного так и не ответили ;(
Hу, согласно 61-м правилам, такого быть не может вообще - замеченные ошибки
исправляются днём выявления. Соответственно, и проблемы (этой) не возникает.
С уважением, Паша
Vasiliy Lyapun
25 Окт 00 22:30, Nikolay Belov -> All:
>> (где-то в недрах RS есть еще таблицы с остатками я уже не помню,
>> раньше когда-то, когда знимался RS-ом, насчитал 18. Уже два года как
>> отбодался от него) А вот как надо бы:-) 1. Одна таблица счетов. 2.
>> Одна таблица остатков четырмя полями для остатков: Рубли по дате в
>> балансе, рубли по дате валютирования, валюта по дате в балансе ,
>> валюта по дате валютирования.
NB> Э-эх... Специалисты по "нормальным формам".
NB> Делается одна таблица остатков, (это правильно), а в ней - _две_
NB> колонки - одна - "тип остатка", вторая - "сумма остатка", впрочем, в
NB> "сумму остатка", при желании, можно включить несколько колонок - сумма
NB> в валюте, приведенная сумма...
Согласен, так еще лучше. :)
Удачи
Ляпун Василий
Vasiliy Lyapun
26 Окт 00 10:55, Dim -> All:
>> И это хорошо :-), только вот реализация плана счетов кривовата. :(
>> Для того что бы получить баланс
>> по второму порядку - нужен один план счетов
>> по третьему порядку другой, и т.д.
>> И для всего этого несчастные бухгалтера "вяжут"
>> счета к двум планам счетов, а ведь можно использовать
>> один, при условии грамотного построения базы и алгоритмов.
D> Hу ты, Vasiliy, LyapNUL !!! :-0
D> Кто же тебе запрещает использовать один ?
Да никто не запрещает. Просто в момент внедрения
этой хрени у нас "специалисты" из фирмы RS-STYLE так научили.
Уже два года как этим не занимаюсь.
>> Всего получается двенадцать таблиц остатков
>> и четыре таблицы счетов.
D> Разные (по смыслу) остатки - разные таблицы. Можно, конечно, все
D> хранить в одной, навесить на нее доп.поля (и соответствующие ключи),
D> только зачем ? Скорость работы от этого не выиграет. Ради приближения
D> к теоретическому постулату ?
Вот тут не соглашусь. Дело не в постулате, а в том
что для получения по сути одних и тех же отчетов
(например выписки по счету по счетам разных глав баланс, внебаланс)
нужно в коде городить вские IIFы на разные таблицы. А это геморойно.
D> И кроме того, так исторически сложилось, что был отдельно рублевый и
D> валютный опердень, вклады, кредиты и еще куча модулей, которые банки
D> могут устанавливать в любом сочетании.
То что структура базы данных сложились именно исторически
я не сколько не сомневаюсь.
Сначало была программуля для обслуживания юр-лиц,
затем к ней прилепили баланс (несколько планов счетов),
затем картотеку и внебаланс, затем валюту.
Вот и посчитай сколько уже исторических заплаток.
D> Для всех этих модулей изобрести единую прекрасную и универсальную
D> структуру базы, которая бы еще не менялась во времени, отвечала бы
D> всем нормальным и ненормальным формам, учитывала возможные закидоны
D> ЦБ, и т.д. и т.п. - это задача практически нерешаемая (то есть
D> порешать ее ты можешь в течение всей своей жизни, но банку
D> надо работать уже сейчас).
Все мне понятно.Те кто уже сидят на RSе, и их устраивает, пусть
сидят. Hо то что куча банков его использует, не аргумент
что этот софт нужно покупать СЕЙЧАС, тем кто еще не "осчастливлен".
Я ведь и писал что RS (наверное) был уместен пять лет назад.
Сейчас его покупать просто глупо.
>> А вот как надо бы:-)
>> 1. Одна таблица счетов.
>> 2. Одна таблица остатков четырмя полями для остатков:
>> Рубли по дате в балансе, рубли по дате валютирования,
>> валюта по дате в балансе , валюта по дате валютирования.
D> Hадеюсь, в твоей системе все действительно так прекрасно.
D> Кстати, что за система ?
Сиситема самопальная на фоксе: рубли-валюта, юр-лица,
навороченная комиссия за обслуживание юр-лиц,
внутренняя бухгалтерия, отчеты, коррсчета, интерпретатор языка
"логических проверок", баланс, много планов счетов.
Физ лиц нет (они в отдельном софте). Кредивание собственное,
но в отдельном модуле, из-за гребаного RSа.
Дело в том что я не предлагаю собственную систему на продажу,
на фоксе это не серьезно. о после покупки RS, руководство
пришло к выводу наша система лучше.
Сейчас в большом отделении объем базы (счета/документы)
в нашей проге больше чем в RS раза в полтора и еще тянет.
Для RS купили первасив и пятерку чтобы не он не лопнул.
D> И сидят ли в этих таблицах счета и остатки:
D> частных вкладчиков, основных фондов, зарплаты и т.п. ?
Если бы наша воля, сидели бы на своем, пока на рынке
не появится достойный продукт по нашим деньгам.
Удачи
Василий Ляпун
Papkov Vladimir
Привет Александр.
Прошу прощения за задержанный ответ, были проблемы.
Херня (я очень сильно извиняюсь за это слово) эти поля в счете.
А вы что, для каждого договора по каждому контрагенту открываете новый счет (я имею
ввиду 474 счета). А как вам ситуация кагда на 603 счет одной суммой заносятся
средства с разной датой оплаты.
Только не надо о требованиях ЦБ. Они нас неоднократно проверяли, и претензий, что
куча МБК учитывается (естественно в непересекающиеся отрезки времени) на одном
счете, не было.
А знаешь, что еще интересно.
Судя по тому, что ты один за это время ответил на мой вопрос, впечатление, что
основная масса банковских автоматизаторов, которые здесь обитают, как бы это по
мягче выразиться, смутно представляют себе как Ф1, так и ф101, ф102 и (я не говорю
о ф601) тд.
И разговор о достоинствах и недостатках АБС ведут исключительно на основании
скорости закрытия опердня.
Возможно, я кого то обидел. Возможно очень сильно. Возможно кто то очень (и даже
чрезвычайно) крут в Novell или, например, в Windows или в С++. Но это не есть
банковский автоматизатор Это есть сетевик, или программер или еще что.
Так вот к банковским автоматизаторам, тусующимся здесь.О сквозной автоматизации
банковских процессов речи в принципе идти не может. Но хотя бы отчеты ЦБ где то как
то автоматизируются. Ну и давайте попытаемся сравнить системы хотя бы с этой точки
зрения.
А для затравки ф 102.
Итак
1. Как контролируется правильности заполнения номера лс 701, 702.
2. Как реализован механизм округления с учетом накопительного результата по
кварталам.
3. Есть ли эспорт в текстовый файл для загрузки в прграмму ЦБ
4. ...
Кто то может здесь сказать, что это все полностью автоматизированно?
И соответственно похвалиться своей АБС?
Владимир Папков
PS Я могу сказать, что у меня это автоматизированно. Но в этом заслуга RSLab не
более 85% (а именно rsl + макросы инициализации и проверки). Остальное - мое.
Vasiliy Lyapun
06 оя 00 23:23, Papkov Vladimir -> All:
PV> Так вот к банковским автоматизаторам, тусующимся здесь.О сквозной
PV> автоматизации банковских процессов речи в принципе идти не может.
Совершенно верно,
"Правительство не может дать всего, всем, и сразу" :)
PV> Hо хотя бы отчеты ЦБ где то как то автоматизируются. Hу и давайте
PV> попытаемся сравнить системы хотя бы с этой точки зрения.
PV> А для затравки ф 102.
PV> Итак
PV> 1. Как контролируется правильности заполнения номера лс 701, 702.
PV> 2. Как реализован механизм округления с учетом накопительного
PV> результата по кварталам.
PV> 3. Есть ли эспорт в текстовый файл для
PV> загрузки в прграмму ЦБ
PV> 4. ...
PV> Кто то может здесь сказать, что это все полностью автоматизированно?
PV> И соответственно похвалиться своей АБС?
PV> Владимир Папков
Итак продолжу с того что :
1. повторю база данных в RS-BANK не нормализована
2. на ненормализованной базе построено куча отчетов.
3.....
С по правилам нормализации нельзя чтобы в одном поле таблицы
"хранились разные характеристики сущности".
По сложившейся традиции номер лицевого счета
состоит из (как минимум) четырех сущностей
1. код валюты
2. балансовый счет
3. порядковый номер счета
4. всякие символа (для некоторых балансовых счетов)
5. мож еще что нибудь :) (для некоторых балансовых счетов)
Так вот мы своих юзеров к этому приучили, что:
1. Цифирки в номере счета у нас не определяют балансовый счет.
Т.е. конечно, если юзера открывают новый счет, то программа
автоматически предлагает балансовый счет в соответствии
с первыми пятью цифрами, но юзера при сильном желании
могут "привязать" другой балансовый счет, который хранится
где-то там внутри программы.
Балансовый счет юзера могут _осмысленно_ поменять после
открытия счета и выполнения операций по нему. Это иногда нужно
для исполнения очередных дурацких команд сверху. Hапример
после введения счетов третьего, четвертого порядка и т.п.
Конечно при этом может поменятся баланс но гл. бух
знает (или должен знать) этот механизм.
2. Цифирки в номере счета у нас не определяют валюту счета.
Т.е. конечно, если юзера открывают новый счет, то программа
автоматически предлагает валюту счета в соответствии
с шестой - восьмой цифрами, но юзера при сильном желании
могут указать другую валюту. Валюта счета (для юзера) хранится
где-то внутри программы и отображается в случае надобности.
Задавать валюту счета у нас разрешается один раз
при открытии счета, корректировка валюты счета запрещена.
Даже если юзер изменит номер у действующего счета, валюта счета
останется прежней.
3. Цифирки в конце номера счета у нас не определяют символа 102 формы.
Т.е. конечно, если юзера открывают новый счет, то программа
автоматически предлагает символ в соответствии правилами 102 формы
но юзера при желании могут "перепривязать" счет к другому символу
102 формы. Даже если счет открыт давно и привязан к какому либо
"символу" юзера могут в любое время _осознано_ перепривязать к другому.
Дело в том, что проницательные гл. бухгалтера часто открывают несколько
разных счетов доходов расходов с одним и тем же символом, предвидя
то что символ 102 формы могут разделить по подстатьям.
Или несколько лицевых счетов на одном балансовом счете.
Так вот мы свою систему построили так что номер счета нужен
юзеру только для ввода документов. Таким образом номер счета
у нас служит лишь "внешним идентификатором" для юзера.
Все поиски в базе основаны на внутреннем идентификаторе счета.
В RSе номер счета является одновременно и внешним, внутренним
идентификатором счета и определяет символа отчетности и т.д.
Все отчеты у нас строятся на основании других реквизитов счета,
т.е. можно бесконечно наращивать различные реквизиты
счетов для разных отчетов и самое главное отчеты не зависят
от номера счета. Конечно есть некоторый (мягкий) программный
контроль за соответствием внутренних реквизитов счета его номеру.
Дело в том, что двадцати разрядов номера счета не хватит
чтобы "зашить" туда все возможные характеристики счета
Строить отчеты опираясь на номер счета, я считаю
не хороший стиль построения системы.
Удачи
Василий
Sergey Zakharov
B понедельник нoябpя 06 2028 в 23:23, Papkov Vladimir (2:5020/400) отписал к
All:
PV> О сквозной
PV> автоматизации банковских процессов речи в принципе идти не может.
Очень смелое, неpавильное и - главное - ВРЕДHОЕ заявление.
PV> Hо хотя
PV> бы отчеты ЦБ где то как то автоматизируются.
Как pаз отчетность ЦБ можно автоматизиpовать самыми пpозаическими сpедствами,
вплоть до екселя ;) Главное - чтобы была инфа, котоpую в этот ексель гpузить. И
удобный механизм загpузки. К сожалению, большинство отечественных pазpаботок
стpадает нездоpовым кpеном именно в стоpону отчетности ЦБ, забывая, что деньги
банки заpабатывают отнюдь не отчетностью, а уж ЦБ-шной - подавно. Пpавда, в
последнее вpемя наметилась тенденция к ипсpавлению ситуации (ИМХО).
<
Best Regards, >er⌡ (z...@mmbank.ru)
Dmitry Provodnikov
[DPskip]
S> большинство отечественных pазpаботок стpадает нездоpовым кpеном именно
S> в стоpону отчетности ЦБ, забывая, что деньги банки заpабатывают отнюдь
S> не отчетностью, а уж ЦБ-шной - подавно.
согласен, но:
на отчетности ЦБ можно очень легко _потерять_ деньги.
WBR, Dmitry.
Dim
>Привет Papkov!
>
>06 оя 00 23:23, Papkov Vladimir -> All:
>
> PV> автоматизации банковских процессов речи в принципе идти не может.
Vasiliy, ты опять LyapNUL ! :-))
Дело в том, что твои пункты 1, 2 и 3 реализуются в рамках RS без всякого
напряга.
Если ты не разобрался в системе - это не ее вина.
Что касается любимой тобой нормализации - согласен, лучше жить в прекрасной
стране, получать кучу красивых денежек и по вечерам гулять на берегу
океана... Мы же с тобой пока - "здесь и сейчас" :-(
----
Успехов ! Жуков Дмитрий.
Papkov V.
Привет Сергей.
Ты что хочешь сказать? Что RS, DIA и прочие менее распространенные системы могут
хотя бы в первом приближениее построить настоящую сквозную АБС? Приведи пример
такой системы, и я начну грызть начальство на предмет покупки онной.
И на счет слива информации в эксель. Так вот и интересно, есть такая ПОЛНАЯ
информация в различных АБС, или ее нет. Про механизм загрузки я не говорю - это в
конце концов можно как то решить, но если система не содержит всех необходимых
данных, это уже хуже.
А вот еще тема для дискусии. Некоторые ну очень продвинутые автоматизаторы хотят
от АБС не менее как систему поддержки принятия решений (естественно наряду с
другими функциями). Возможно, в России есть 5 -10 банков, где это уже желательно.
Но в основной массе банков, и это будет еще долго, основная цель автоматизации -
это уже мое утверждение - минимизировать персонал банка. По этому мне и интересны
такие приземленные вещи, как отчеты ЦБ, ибо денег там, конечно, не заработаешь, но,
во первых нужен очень ответственный и квалифицированный персонал для составления
этой отчетности (ну-ка вспомним 17), а во вторых как правильно сказал Dmitry
Provodnikov, пиз~~й можно получить таких, что ой-ей-ей.
Владимир Папков
Papkov V.
Vasiliy Lyapun wrote:
> Привет Papkov!
>
> 06 оя 00 23:23, Papkov Vladimir -> All:
>
> Итак продолжу с того что :
>
> 1. повторю база данных в RS-BANK не нормализована
> 2. на ненормализованной базе построено куча отчетов.
> 3.....
>
> С по правилам нормализации нельзя чтобы в одном поле таблицы
> "хранились разные характеристики сущности".
>
А где ты увидел такое поле и в какой таблице в РСтуле?
>
> По сложившейся традиции номер лицевого счета
> состоит из (как минимум) четырех сущностей
> 1. код валюты
> 2. балансовый счет
> 3. порядковый номер счета
> 4. всякие символа (для некоторых балансовых счетов)
> 5. мож еще что нибудь :) (для некоторых балансовых счетов)
>
>
По какой традиции? Вася, ты что?
Ну-ка привесь номера автомобиля не спереди и
сзади, а на боках, и покатайся так по городу. Если ты не держишь в кармане
всю ГИБДД, домой пойдешь пешком.
Так вот, я охотно верю, что ты работаешь в крутом банке, который плюет на
требования ЦБ, но не все это могут себе позволить.
Владимир Папков