-
О НАУФОРСтандартыИнформационные материалыОценка квалификации и обучение
Все сообщения пользователя
1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #21 от 01.12.2010 20:28 
Перейти >>
Цитата:
Начиная с 11.11.2010....
Вообще интересная дата... У вас случайно это не связано с изменением вышестоящего депозитария ?
Т.к. в этот день НДЦ превратился в НРД. Может вы в программе изменили место хранения (кодировка и т.п.)?1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #22 от 02.12.2010 12:45
Перейти >>
Если принять во внимание, что Вы опытный пользователь и знаете как работать с программой, то из вашего сообщения:Цитата:
...Самое интересное, что после автоввода появляется как обычно сообщение: автоввод прошел успешно. Открываю журнал сделок- там этих сделок РЕПО нет. А вот в СОБЫТИЯХ--->03 СДЕЛКИ--->РЕПО обратное они есть...
можно предположительно сделать вывод о нарушении целостности данных внутри программы. У компаний использующих Фондовый центр 2.0 такой ситуации не возникало ни разу, т.к. она исключена по определению. Может вам стоит перейти на более надежное ПО?1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #23 от 02.12.2010 13:00
Перейти >>
Компания продаст Фондовый центр 2.0 (новый).
Сделайте себе подарок к Новому году!
Продайте устаревшее ПО здесь http://naufor.ru/forum.asp?id=12429
и приобретите готовый современный комплекс проверенных технологий.
Это настоящий автоматический сервис, а не офис с большим числом менеджеров.
Автоматика не требует зарплаты!
Контакты: 1c@rts-soft.ru
P.S: Сэкономьте свое время и деньги на подарки к Новому году. :)1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #24 от 03.12.2010 17:32
Перейти >>
Вообще-то проверенные технологии - это аббревиатура.
В понимании нашей команды разработчиков - это проверенные временем технологии внутреннего учета профучастника РЦБ. Их еще можно назвать бизнес процессами внутри компании брокера, дилера и ДУ. Мы предлагаем целый комплекс таких технологий в виде автоматизированного решения.
Каждый вправе ассоциировать выражения со своим видением и осознанием, кто-то под этим понимать название компании разработчика, кто-то в более широком и профессиональном понимании.
Ваша ГАММА Дмитрий тоже может для некоторых ассоциироваться например с наборов цветов (желтый-зеленый-синий....), но вообще Вы как представитель команды продающей свое ПО прекрасно понимаете что имелось ввиду.
С уважением, RTS-Soft.ru1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #25 от 07.12.2010 10:51
Перейти >>
Цитата:
Однако имхо, менять дату сделки с 12го ноября на 13 ноября будет неправильно. Нужно так и давать отчет за 13 ноября, в котором будут содержаться также сделки вечерней сессии 12го ноября.
quest-83, на самом деле Nikolaevna имела ввиду выдачу отчета клиенту а не смену дат в документах. Сделки за 12го ноября будут иметь дату совершения сделки = 12 ноября, а вот расчеты-клиринг (это ″Дата клиринга″ в биржевом отчете) по ним (как я уже писал ранее) будут 13 ноября на утро (т.е. до начала торгов след.дня). Именно так ФОРТС клирингует сделки вечерней сессии.
В отчете клиенту они естесственно попадут в предыдущем дне, только за 12-е число они будут незакрытыми, т.к. дата их исполнения 13-е число. ПО бэк-офиса должно иметь для сделок связку расчетных документов (для движения контрактов по сделке и списанию/зачислению ВМ). Именно такая структура документов в ПО ″Фондовый центр 2.0″ позволяет правильно выдавать отчетность клиентам с самого начала появления вечерних торгов на ФОРТС.
Клиенту всегда выдается отчет в текущем дне за предыдущий/предыдущие по технологическим причинам внутреннего учета профучастника. Т.е. дать отчет клиенту за сегодня вы не можете по определению, т.к. еще не списали свое вознаграждение и т.п.
Это значит что всегда отчет будет не менее чем Т-1, поэтому получив например сегодня информацию о вечерних сделках за вчера вы вносите их в систему учета датой совершения вчера, а датой движений контрактов и ВМ (если она есть!) утром на сегодня (например 10:00). Только в этом случаем ваши остатки по позициям контрактов и денежные остатки будут сходится с биржевыми.
P.S.: Разумеется если вечерние торги были в пятницу, то расчеты по ним будут на утро в понедельник. :))1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #26 от 08.12.2010 11:30
Перейти >>
Цитата:
Также в РТС разъясняли мне, что Позиция возникает в момент заключения сделки, а в момент клиринга происходит переоценка позиции и требований по ней.
Вам все правильно разъяснили в РТС.
Совершение срочных сделок регулируются «Правилами совершения срочных сделок», а расчеты (клиринг) по этим сделкам регулируются другими правилами http://fs.rts.ru/files/4907 т.е. это разные понятия.
Если вы посчитаете сальдо движений по позициям контрактов, то контракты вечерней сессии будут отражены в отчете об обязательствах по фьючерсным контрактам и сделкам (fposXXYY.dbf) следующего торгового дня.
Другими словами позиция на начало отчетного периода (POS_BEG) не будет учитывать сальдо от вечерней сессии отчета fposXXYY. Таким образом отражая движения по контрактам вечерней сессии в этот же день ваш начальный остаток по позициям на утро след.отчетного дня не будет совпадать с данными биржевого отчета.
Полный список отчетов ФОРТС здесь: http://www.rts.ru/a208711c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #27 от 08.12.2010 20:34
Перейти >>
Цитата:
Т.е. когда клиенту выдается отчет на 01 число с 00:00 по 23:59, то сделок вечерней сессии там нет? Они будут в отчете за 02 число, но с датой сделки от 01 числа, а движения по позициям будет 14-00 02 числа?
Да :))) Только с точностью до наоборот.
Когда клиенту выдается отчет на 01 число с 00:00 по 23:59, то сделки вечерней сессии за этот день там будут. А вот разделы отчета открытые позиции по контрактам, состояние ДС и ГО будут отражать состояние на начало вечерней сессии, что будет соответствовать биржевому отчету за этот день. Данные по движениям от сделок повлияют на эти разделы в след.дне.
1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #28 от 17.12.2010 14:19
Перейти >>
Цитата:
Поручения при проверках могут сравниваться либо по файлу заявок, который можно выгружать из Квика, либо по реестру заявок, который формирует биржа. Ни в том, ни в другом случае время у Вас не будет совпадать.
На самом деле все электронные поручения должны соответствовать биржевым отчетам (для ММВБ это файл SEM03). На квик или др.трейдинговые системы ориентироваться нельзя по двум причинам:
1. По техническим причинам время некоторых заявок поданных через Квик не совпадает с биржевыми отчетами.
2. Отчеты биржи единственный первичный документ (если вы имеете прямой доступ торговли на бирже).
Ваша программное обеспечение в бэке должно уметь читать биржевой файл с заявками и корректировать установку правильного времени заявки, если вы до этого в режиме Он-Лайн загрузили заявки в течении дня.
Самое главное надо понимать что ММВБ работает по московскому времени, как и ваш квик, но в отличие от квика биржа является первоисточником информации и любая проверка будет сравнивать биржевой файл с вашим внутренним учетом.
P.S.: Разумеется речь идет только про электронную торговлю. Т.е. брокерский клиент торгует сам через Квик.1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #29 от 17.12.2010 15:04
Перейти >>
Цитата:
А что в этом такого? совпадать не будет, потому что на сервер брокера заявка поступила раньше, чем на биржу. Но поручения поступают брокеру. И брокер также должен обеспечить сохранение (выгрузку файла) всех заявок, поступивших ему на сервер.
Сервер брокера - это шлюз электронной торговле на ММВБ для клиента. Поэтому заявка клиента идет не ″НА СЕРВЕР БРОКЕРА″, а ″ЧЕРЕЗ СЕРВЕР БРОКЕРА″ и ″НА БИРЖУ″. Трейдинговая система квик это инструмент обеспечения электронных торгов, а не источник первичной информации в понимании ФСФР. Отсюда следует что серверное время квик это техническая составляющая, а не основа информации для журнала поручений.
P.S.Насчет файла с заявками ММВБ все верно, небольшая опечатка :).1c@rts-soft.ru
Рег.: 23.08.2010
Сообщений: 32
Сообщ. #30 от 10.06.2011 11:11
Перейти >>
Maria, если подЦитата:
Реестр ДСвы имеете ввиду ″Регистр внутреннего учета денежных средств и расчетов по сделкам и операциям с ценными бумагами″ то в 32-м для него есть обязательное поле ″Сумма расчетной операции по счету″. Т.е. фактическое движение фактической валюты, а не переоценка ее в рублях. Добавив поле ″Валюта расчетной операции″ в регистр вы сможете его правильно вести в разрезе валюты. Исходящий остаток последнего движения регистра конкретной валюты должен совпадать с остатком ДС в отчетах клиенту по такой же валюте.
