Bankir.Ru
6 декабря, вторник 13:18

Объявление

Свернуть
Пока нет объявлений.

Отзывы по опердню МИМ

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Отзывы по опердню МИМ

    Прошу откликнутся тех, кто работал в обозримом ( примерно год ) прошлом с оперднем "МИМ-технология" и их банк-клиентом и клиент-банком. Интересуют ВСЕ проблемы, с которыми Вам удалось столкнуться.
    Кстати, если дадите ссылку на БСС, буду очень благодарен.

  • #2
    Для банка на 40-50 мест оптимальная система по соотношению цена-качество.
    Одна из лучших систем на нашем рынке, но , к сожалению, слабо раскручена.
    Проблемы? Они есть всегда . Что конкретно вас интересует? Отсутствует поддержка удаленных рабочих мест, хотя и здесь можно найти решение. Пишите

    Комментарий


    • #3
      Работали на этом опердне с 1994 года и довольно плотно. До сих пор используем их версию 3.04 от 98 г. правда несколько переточенную. Использовали также их "Вклады населения" и Клиент Банк, от последнего использовали только клиентскую часть и тоже основательно её переделывали (перекомпилировали исполнитель чтоб он мог ЛанКрипто).

      Проблем было много, но опять же всех их так сразу не вспомнить, а те что вспомнить - устану перечислять. Пишите, спрашивайте - с удовольствием ответим.

      Есть правда одна проблема, которая мучает именно сейчас. Может кто поможет: Недавно заменили сервер Novell на Win2000 - и начались жуткие глюки. База стала виснуть, работать криво, стали накапливатся ошибки. И причина пока толком не ясна. Толи надо менять настройки базы, толи сервера, толи плюнуть, снести Винды и опять поставить Novell.

      Комментарий


      • #4
        С апреля 1998 года много воды утекло - меняемся мы , меняется и МИМ. Хотя проблемы , конечно , были, есть и будут.
        По поводу Win2000 - попробуйте убрать IPX протокол на сервере и рабочих станциях. Должно помочь. Какой у вас исполнитель? Поддерживает ли он режим "Грязного чтения" (DIRTYREAD=2) ? Это влияет на скорость работы и блокировки.

        Комментарий


        • #5
          IPX на сервере нет, по винндовой сети используется только TCP/IP, на станциях IPX убрать пока не могу т.к. на старом серваке остался один принтер принтсервером которого служит 486 комп, который под виндовсй сеткой стать принсервером не сумеет.
          Исполнитель режим DIRTYREAD поддерживет, но мы его не используем, правда в моем mimini.txt написано Режим "грязного чтения" ("1"-Да,"0"-Нет) т.е. 2-ки там нет.
          А вообще со скоростью то проблем как раз и нет. мне кажется что-то с локировками. База по моему бьется в момент внешней загрузки с режимом ".NOCHECK" либо в момент модификации #mod() в каком-то из отчетов...
          В общем будем думать, крутить и пробовать...

          Комментарий


          • #6
            1. База "бьется" - непонятно, у вас нарушается физическая целостность базы ? или что-то другое ?
            2. Судя по всему, вы используете утилиту быстрой загрузки uni_imp.exe с режимом NOCHECK . Чему равен параметр DIRTYREAD в файле mim_nt.ini ?
            3. Насколько старые утилита импорта и исполнитель ? Может быть они не поддерживают режим грязного чтения (DIRTYREAD=2) ?
            4. Проблемы с WIN2000 не будут решены , пока не уберете IPX протокол с рабочих станций.

            Комментарий


            • #7
              2 О.Дима.
              Самое правильное, конечно, снести Винды и поставить обратно Novell NW. Хотя и самое трудоемкое.

              Комментарий


              • #8
                2 gsd
                1. каждую ночь отрабытывает uni_check и в реднем раз в три дня появляются ошибки - лечим выгрузкой загрузкой документов в архи предыдущего дня

                2-3. UNI_IMP.EXE и исполнитель от 14.07.98, а файла mim_nt.ini вообще нету, но мысль интересная межет его создать...
                и чем DIRTYREAD=2 отличается от DIRTYREAD=1?

                4. честно говоря трудно предствить как одно может влиять на другое. но рано или поздно IPX снесем вот только купим принтсерверок

                2alexalex
                конечно правильное, но мы не ищем легких путей. Да и людей к сожелению нет кто Новел хорошо умеет.

                Комментарий


                • #9
                  О.Дима
                  Странно как у Вас еще что-то работает. Не пробовали работать на версии от 95-го или 92-го года? По-моему, утилиты от 98-го года - это скорее всего beta-версия. Советую Вам обратиться к доктору, в смысле к автору (http://www.mimtech.com/index_r.html ). Думаю там помогут и более профессионально объяснят все отличия DIRTYREAD=1 от DIRTYREAD=2. В кратце, во втором случае нет блокировок при навигации по БД для пользователей типа "аналитик".

                  Для проверки физической целостности БД рекомендую использовать родную утилиту Vista - checkdb.exe для версии 3.0. Я проверяю базу 1 раз в неделю, последний раз проблемы были года 3 назад, когда пробовали режим "грязного" чтения, как раз где-то в начале 98-го года. Так что, скорее всего Вы сидите на какой-то проблемной версии, тем более, что сейчас уже версия БД UNI 4.17. Сделайте обновление версии - глядишь проблемы и исчезнут.

                  Как не странно, но наличие протокола IPX на рабочих станциях приводит в негативным последствиям с БД при работе под NT. Мне об этом говорили в МИМ-е (кто-то из их клиентов на этот гвоздь уже напарывался). У меня 1,5 года работает база под W2000 - ни одного падения. Есть другая проблема - W2000 работает гораздо более неустойчиво, чем Novell. Т.е. требует большего внимания администратора сети. А Novell запустили и забыли. Чистишь тома периодически и все. Так что думайте.

                  Пока.

                  Комментарий


                  • #10
                    О.Дима

                    Вернись, я все прощу !!!

                    Комментарий


                    • #11
                      gsd

                      ...отличия DIRTYREAD=1 от DIRTYREAD=2. В кратце, во втором случае нет блокировок при навигации по БД для пользователей типа "аналитик".

                      Огромное вам спасибо - мне сейчас дороги даже такие крупицы информации.

                      Для проверки физической целостности БД рекомендую использовать родную утилиту Vista - checkdb.exe для версии 3.0

                      Именно так и делается, каждую ночь - и каждое утро таит в себе загадку...

                      Советую Вам обратиться к доктору, в смысле к автору... Сделайте обновление версии - глядишь проблемы и исчезнут.

                      Ах, если б всё было так просто, если б небыло кризиса в в 98 году, если б выжил тот банк, где МИМтех обкатывал на нас все свои новые версии, если б не был утрачен секрет перекомпиляции исполнителей, ну или если б были просто добрые доктора...

                      Спасибо вам еще раз за советы. Я тут чуток подразгебу горячку и погоняю крэш-тесты - может что-нибудь и придумаем, а нет - найдем человека который вернёт нам Новель, ну или есть Линукс еще на худой конец - под ним то же попробуем.

                      mimtech
                      Я конечно вернусь, весь в друзьях и в мечтах, не пройдет и полгода... ну или в 2017-м уж точно приползу на обновление.

                      Комментарий


                      • #12
                        А мы тоже на МИМе с 1994 года сидим, и пока переползать пока не собираемся. Многие, ушедшие в другие банки, скучают по его интерфейсу.
                        Утилиты под Windows работают раз в 5 быстрее DOS-исполнителя, здорово выручают. Навигация по базе в DOS выше всяких похвал. Мощный генератор отчетов, их можно создавать "на лету", на работающей базе и тут же выполнить. Все по русски. У нас на Netware 4.10.

                        Минусы - при смене счета в оплаченном документе рушится таблица оборотов в лицевых счетах. При удалении операции по карточке - ошибка "Незакрытые DD_LOCK". Очень медлительна при большом кол-ве одновременно работающих пользователей и числе записей. Нет прав доступа к макросам и отчетам для отдельных пользователей (точнее, в последних версиях есть, но жутко неудобно). При крахе базы можно лечить DBDoctor'ом (занятие не для слабонервных) или экспорт/импорт, что не гарантирует результата.
                        Документооборот ок. 800 документов в день; база 500мб

                        Комментарий


                        • #13
                          pit

                          Если документ находится в состоянии "Оплата" (включен в баланс), но есть "бухгалтерские" ошибки (не те счета и/или сумма), то есть два пути:
                          а) "сторно" документа путем его удаления (автоматически откатываются обороты и история счетов, если 0-й параметр в файле par.txt установлен в 1);
                          б) перевести документ в состояние "Откат", далее изменяешь все, что надо, далее опять в состояние "Оплата".

                          Сообщение про "незакрытые DD_LOCK" у вас возникает всегда при удалении или иногда (нерегулярно)? У нас тоже подобное было, забыл как лечили. Скорее всего дело в исполнителе. По-крайней мере давно не помню, чтобы юзера говорили про это сообщение.

                          Скорость - это да. Боремся только за счет увеличения мощности железа (память на рабочих станциях, мощный сервер, сеть 100 Мб, концентраторы и т.д.). А что еще ждать от файл-серверной архитектуры?

                          Программа DBDOC.EXE - классная штука. В свое время (97-98г.г.), когда были проблемы с базой, я ее очень активно использовал в купе с checkdb.exe. В принципе, ничего сложного там нет. Жаль вот только, что нет нормального хелпа для нее. А так, послушал на каком-то МИМ-ом семинаре (тогда они устраивали подобные штучки) Седристого, почитал литературу по db_Vist-е и вперед.

                          Документооборот около 1500 в день, база около 2Гб, юзеров более 30.

                          Комментарий


                          • #14
                            To All !!!

                            Следующий семинар планируем проводить в мае-июне 2002 г.

                            Ваши предложения отсылайте kvf@mimtech.com.

                            Комментарий


                            • #15
                              gsd
                              А мы каждый год "с нуля" начинаем - т.е. без документов и операций; только каротечные. Кому надо - идет в архивную базу. Отсюда и БД небольшая. Юзеров в среднем 15, в пик 20-25. Да еще и на коаксиале сидим.
                              DD_LOCK возникает всегда при удалении проводки из записи "Проводки по карточкам". И так и висит на экране, пока не выйдешь. Версия у нас старая, еще без отката.

                              По поводу наежности... Вот не далее как в пятницу unicla.key вдруг ни с того ни с сего вырос вместо обычных ~11Мб до 1,4Гб (!) :-(
                              Пришлось два часа лечить bldkey'ем. Правда, такое крайне редко возникает.

                              mimtech
                              Ну наконец-то летом!!! -)

                              Комментарий


                              • #16
                                pit

                                Если DD_LOCK возникает каждый раз при удалении карточных проводок, то это проблема исполнителя (100%). Похоже у вас с О.Дима одна проблема - отсутствие поддержки (нет обслуживания).
                                Увеличение длины файлов БД (обычно это файлы ключей) связано исключительно с проблемами локальной сети. Возможно на какой-то станции "умирает" карта, возможно из-за коаксиала (лучше делать витую пару).
                                2 часа идет перестройка ключей на такой небольшой БД - это круто! Похоже, что вы делаете эту процедуру на 10 Мб сети, либо на 486-м компе.

                                mimtech
                                Надуюсь, что доживем до этого события...

                                Комментарий


                                • #17
                                  Не знаю, как для компьютерщиков, но для меня как для пользователя просто ......
                                  Дойти до нужного документа или получить нужную аналитику, это просто .........

                                  В итоге, вся аналитика размещена в другой программе.

                                  Комментарий


                                  • #18
                                    bill2001

                                    По моей информации, в Поволжье среди наших клиентов, в настоящий момент, нет ни одного банка на обслуживании.

                                    Не могли бы Вы представиться, а то по Вашему профилю не понятно с кем общаться.

                                    Комментарий


                                    • #19
                                      Э-э-эх! Когдаж уважаемый МИМ сменит свою технологию? Под NT она или под DOS - качество-то не меняется (правда можно мышкой порулить).
                                      Мое примитивное представление существующей технологии:
                                      На файл-сервере (или на той же рабочей станции) размещается каталог с файлами базы данных (какая операционная система на сервере - неважно, системные процессы все равно не работают). На рабочих станциях запускаются приложения (МИМ-исполнители). Сколько пользователей - столько МИМ-исполнителей, каждый откусывает свою долю системных и сетевых ресурсов. Любые объекты, в т.ч. SQL-запросы вызываются на исполнение МИМ-исполнителем.
                                      Почему не перенести эти процессы на сервер?
                                      Предвижу мощный апперкот от г-на Седристого - и я в нокауте...
                                      ЗЫ У деда в гараже старый добрый надежный запорожец (покрашеный и с новыми фарами), а ему хочется на опеле покататься...

                                      Комментарий


                                      • #20
                                        AllG
                                        Э-э-эх! Когдаж уважаемый МИМ сменит свою технологию [зачем ее менять ? она отлично работает и сэкономила людям раз в 100 больше чем мы на ней заработали, то что она не решает всех проблем (как говорят КВН-щики), так это и ежу ясно (как и большинство других), зато те что решает, решает достаточно эффективно и эффектно.]? Под NT она или под DOS - качество-то не меняется (правда можно мышкой порулить) [качество меняется: во первых где еще вы видели систему, которая одновременно на одной базе работает как DOS программа так и с Windows интерфейсом. Во-вторых, для тех кто под Windows в качестве нового заметил только мышку наверное мало что изменилось, для всех других могу сообщить что и без этого очень эффективная система навигации, поиска данных и доступа к ним в значительной мере улучшена благодаря (стандартным) возможностям Windows].
                                        Мое примитивное представление [очень уважаю самокритичных, сам такой] существующей технологии:
                                        На файл-сервере (или на той же рабочей станции) размещается каталог с файлами базы данных (какая операционная система на сервере - неважно, системные процессы все равно не работают). На рабочих станциях запускаются приложения (МИМ-исполнители). Сколько пользователей - столько МИМ-исполнителей, каждый откусывает свою долю системных и сетевых ресурсов. Любые объекты, в т.ч. SQL-запросы вызываются на исполнение МИМ-исполнителем. Почему не перенести эти процессы на сервер?
                                        Если короче, то все что товарищ хотел сказать это то, что МИМ-Банк работает в режиме файл-сервер, а по его мнению это ну просто очень плохо, архинесовременно и наиболее современная (то есть подходящая для современного банка) система должна быть клиент-серверной. Ну не знали мы этого, ну спасибо что глаза открыли.
                                        А если серьезно, то не боясь ошибиться можно сказать, что 90% (а может и больше) банков работает (и достаточно неплохо) на файл-серверных системах. Несовременные они однако – ну что бы им не взять да не потратиться на клиент-серверную систему, так нет же экономят – не хотят. Но как говорят – от добра добра не ищут. Потратиться придется значительно больше и в сумме эффект для небольшого и среднего банка гарантированно будет отрицательным.

                                        Предвижу мощный апперкот от г-на Седристого - и я в нокауте...
                                        На апперкот можно рассчитывать если противник ударил, а если так, чуть-чуть потрепал снисходительно (в основном языком), то и отвечать приходится в таком же стиле – общими словами. Из необщих слов могу сказать, что клиент-серверный вариант МИМ-Технологии в целом, а следовательно и МИМ-Банка находятся в стадии завершения.
                                        ЗЫ У деда в гараже старый добрый надежный запорожец (покрашеный и с новыми фарами), а ему хочется на опеле покататься...
                                        На счет надежный – это большое спасибо. А то что старый, так это же причина того, что
                                        Надежный (в отличие от автомобилей здесь зависимость прямо обратная). Но самое главное это не фары и краска (хотя тоже важно) – готовится новый движок. Ну а управление этой машиной всеми даже недоброжелателями признано очень гибким. Ну а если просто покататься, то почему опель – может Ауди или Мерс. А работать надо на тракторе.

                                        Все сказанное (кроме клиент серверной версии) прошу воспринимать как добрую шутку и не (автору сообщения) сердиться на меня как и я на него.

                                        Комментарий


                                        • #21
                                          mimtech
                                          система должна быть клиент-серверной. Ну не знали мы этого, ну спасибо что глаза открыли
                                          Мой ответ был предназначен не Вам, а автору этой конференции (см. первый постинг).
                                          чуть-чуть потрепал снисходительно (в основном языком), Желаю Вам такого же эмоционального подъема в освоении клиент-серверных технологий

                                          Комментарий


                                          • #22
                                            Уважаемые!
                                            Хочу высказать свое мнение, работаем с МиМовской системой с 95 года.
                                            С точки зрения программиста база великолепна, а вот с точки зрения конечного пользователя, я бы назвал все это хранилищем документов с элементарными функциями учета каких-то остатков, но никак не Автоматизированной Банковской Системой.
                                            При работе с этой "АБС" постоянно приходится, что помнить или писать на бумажке, различные модули типа "вклады", "кредиты","пластиковые карты","учет основных средств и МБП","UNI"знают друг друга только по на уровне файлов, т.е. одну и туже операцию приходится вводить 2 раза или пытаться научить конечного пользователя выгружать - загружать информацию
                                            В самой UNI также куча недоработок, например такие понятия как Картотека 1 и Картотека 2 только декларируются, никакой системной поддержки, все на уровне запросов и отчетов, про которые надо помнить . В результате огромное количество ошибок.
                                            Насчет применения для средних банков - сомневаюсь, за неполный год база разбухла до 1 Гб при 290 тыс документов т.е. в среднем 1000-1500 документов в день, даже на сети 100 Мб некоторые запросы очень продолжительные ( прокачать по сети 1 Гб), что ждет тех у кого по 2000-2500 тыс документов ?

                                            Комментарий


                                            • #23
                                              Pus
                                              Ну. насчет "вкладов" - ты его модулем зря обозвал, это прикладное учебное пособие для программиста. Кто еще не приложил к нему руку? Вас еще ЦБ не проверяли? А нам они написали кучу замечаний к программе учета вкладный операций. В частности:
                                              1.) Нумерацию лицевых счетов физических лиц привести в соответствие с Приложением № 1 к Правилам № 61 "Схемой обозначения лицевых счетов и их нумерации (по основным счетам)". Т.е. 20 знаков с ключом.
                                              2.) В карточке вкладчика отсутствуют поля № договора и дата заключения договора.
                                              3) Если вклад открыт с признаком "С" (депозитный), то некорректно проходят операции начисления процентов при пополнении вклада, особенно, если срок не кратен 30-и дням, н-р, 101 день.
                                              4) Если вклад открыт 31 числа с признаком "С" (депозитный), проценты начисляются со 2-го числа следующего месяца.
                                              5) Если подвид вклада допускает операцию причисления процентов, возникают трудности при досрочном закрытии вклада, т.к. проценты увеличили остаток (н-р, месяц назад), а пересчет по ставке "до востребования" должен идти от первоначального остатка.
                                              6) Невозможно сделать откат по уже проведенным операциям (в этом случае восстанавливается ближайшая копия).
                                              7) Никто, кроме администратора не может открыть счет, поэтому операционисты работают с правами администратора (нарушение принципов разделения ответственности)
                                              Программа не оптимизирована. В соответствии с 39-П проценты должны отражаться не реже 1 раза в месяц на 474 счете, выплачиваться или причисляться с него же, а если вкладчик не востребовал вклад/проценты, нужно зачислить опроценты с остатком на вклад "до востребования". Операционисты в конце срока руками открывают 474 и 423 "до востребования", набивают мемориальные, а у главбуха в глазах обреченность.

                                              Комментарий


                                              • #24
                                                Pus
                                                При работе с этой "АБС" постоянно приходится, что помнить или писать на бумажке, различные модули типа "вклады", "кредиты","пластиковые карты","учет основных средств и МБП","UNI"знают друг друга только по на уровне файлов, т.е. одну и туже операцию приходится вводить 2 раза или пытаться научить конечного пользователя выгружать - загружать информацию

                                                [Если нормально настроить систему, то не надо будет помнить ничего лишнего.
                                                Даже когда покупаем "вражеский" телевизор, и то нужна настройка каналов.
                                                Правда, в этом случае, ничего платить не надо, но у нас вполне приемлимые цены.]

                                                В самой UNI также куча недоработок, например такие понятия как Картотека 1 и Картотека 2 только декларируются, никакой системной поддержки, все на уровне запросов и отчетов, про которые надо помнить . В результате огромное количество ошибок.

                                                [У Вас, даже в центре стоит версия от мая 2000г. Хотя мы регулярно высылаем в головной банк наши новые версии. ]

                                                Насчет применения для средних банков - сомневаюсь, за неполный год база разбухла до 1 Гб при 290 тыс документов т.е. в среднем 1000-1500 документов в день, даже на сети 100 Мб некоторые запросы очень продолжительные ( прокачать по сети 1 Гб), что ждет тех у кого по 2000-2500 тыс документов ?

                                                [Существует технология, при которой объем оперативной базы не превышает 200 мб]

                                                Комментарий


                                                • #25
                                                  Pus

                                                  я бы назвал все это хранилищем документов с элементарными функциями учета каких-то остатков, но никак не Автоматизированной Банковской Системой.

                                                  Любую банковскую систему (БД) можно рассматривать, как хранилище документов. Является ли МИМ-ий опердень АБС - вопрос спорный. Все зависит, что вы вкладываете в это понятие. Вот чем точно не является МИМ, так это ИАБС (интегрированной АБС).

                                                  различные модули типа "вклады", "кредиты","пластиковые карты","учет основных средств и МБП","UNI"знают друг друга только по на уровне файлов, т.е. одну и туже операцию приходится вводить 2 раза или пытаться научить конечного пользователя выгружать - загружать информацию

                                                  Модуль "кредиты" мне лично не знаком. Может это ваш "самопальный"? По существу. Связь с различными модулями осуществляется через внешний мир в виде процедур экспорта/импорта. Это нормальное явление в автоматизации. Делать эту процедуру может как администратор, так и любой "продвинутый" пользователь. Все это делается 1 раз в день и никаких двойных набивок документов нет, если конечно вам делать нечего. Более того, как правило это консолидированные проводки.
                                                  С точки зрения удобства работы конечного пользователя с МИМ-ми БД, то это чисто субъективное мнение. У нас есть есть юзера, которым нравится, есть, конечно, и наоборот. На всех не угодишь. Если уж так припекло, так надо уходить на другие системы, тем более, что выбор сейчас - только плати деньги.

                                                  AllG

                                                  Мы тоже использовали модуль "вклады" до 98г. Потом учет решили вести в основном опердне. При переходе на новый план счетов версия "вкладов" была еще не готова, да и денег руководство решило не давать (экономия понимаешь).
                                                  Судя по вашим отзывам, МИМ-у так и не удалось реализовать 39-П во "вкладах".

                                                  Комментарий


                                                  • #26
                                                    gsd
                                                    учет решили вести в основном опердне
                                                    Разумное решение и, к сожалению, единственное.
                                                    Ну что мы, правда, кряхтим на МИМовцев? Денег платите и работайте. Это еще наш начальник говорил, известный своим расположением к МИМу, (не по этой ли причине и оставившим свою должность?).

                                                    Комментарий


                                                    • #27
                                                      1.) Нумерацию лицевых счетов физических лиц привести в соответствие с Приложением № 1 к Правилам № 61

                                                      Ужасы какие! Неужто это до сих пор у них не сделано?
                                                      Верится с трудом, честно говоря, тем более работа-то плёвая.

                                                      Товарищ mimtech, Вы ведь, наверное, можете это заявление опровергнуть?

                                                      Боря

                                                      Комментарий


                                                      • #28
                                                        Borya

                                                        Товарищ mimtech, Вы ведь, наверное, можете это заявление опровергнуть?

                                                        Учет вкладов населения в настоящее время ведется в основном опердне и , естественно, там проблем с нумерацией лицевых счетов нет.

                                                        Комментарий


                                                        • #29
                                                          mimtech
                                                          Проблем с нумерацией нет, зато вырастает другая:
                                                          При количестве открытых счетов 3.5 тыс на получение пакета ежедневной отчетности (без выписок) уходит почти 1 час, а если туда добавить 15- 20 тыс депозитных, что будет?
                                                          Как бы поподробнее узнать о технологии сжатия ?

                                                          gsd
                                                          Рядовому бухгалтеру очень трудно объяснить отличия АБС от ИАБС и еще труднее заставить ее выполнять те операции, которые она не понимает (Выгрузка-загрузка), а отсюда огромное количество ошибок. В одном месте забыла выгрузить а другом -загрузить или наоборот
                                                          А тут еще сама МиМ подставляется - случайное нажатие на ESC во время выполнения сложного запроса и результат не предсказуем - отчет то получен будет, но вот его содержание

                                                          Комментарий


                                                          • #30
                                                            Учет вкладов населения в настоящее время ведется в основном опердне

                                                            Круто!
                                                            И все прибамбасы типа плавающие процентные ставки в зависимости от остатков, расходы будущих периодов, материальная выгода, автопролонгация и тому подобная ритейловая радость - Ваш опердень всё это тянет?

                                                            Боря

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X