Сообщения без ответов | Активные темы Текущее время: Ср апр 25, 2018 4:07 am



Ответить на тему  [ Сообщений: 42 ]  На страницу Пред.  1, 2, 3  След.
Письмо ФНС от 7 августа 2006 г. N ММ-6-06/771@ 
Автор Сообщение
Новичок

Зарегистрирован: Сб апр 09, 2005 7:35 am
Сообщения: 74
Сообщение 
"...Игнорировать письмо ФНС я бы не рекомендовала, самый лучший вариант – посоветоваться с местными налоговиками..."

А уведомляла ли компания "Штрих-М" (хотя бы на сайте) о том, что такое письмо существует и надо бы поосторожнее пользоваться продуктами компании, пока не посоветуешься с местными налоговиками?


Пн ноя 06, 2006 4:09 am
Профиль
Новичок

Зарегистрирован: Пн мар 14, 2005 4:32 pm
Сообщения: 230
Сообщение 
Внешнее программное обеспечение для ФР не регламентируется специальными требованиями и не подлежит сертификации. Разработчики, естественно, закладывают в ПО максимум возможностей, а Вам решать, пользоваться ими или нет.

В области применения контрольно-кассовой техники существует множество регламентирующих документов. Мы не можем предугадать, о существовании какого именно документа Вы не в курсе, и заложить такую подсказку в программу. Технические требования к ФР и расчетному узлу компьютерно-кассовой системы, использующей ФР, были приняты много лет назад, а письмо налоговой всего лишь напомнило об их существовании.

_________________
С уважением,
руководитель отдела экспертизы ЗАО "Штрих-М"
Шибина Ольга Михайловна


Вт ноя 07, 2006 1:12 pm
Профиль
Новичок

Зарегистрирован: Сб апр 09, 2005 7:35 am
Сообщения: 74
Сообщение 
У налоговой кончились деньги. :( В связи с этим нами получено письмо такого содержания (цитирую с сокращениями):
"Предписание об устранении нарушений законодательства о применении ККТ.
Инспекция ФНС по ... сообщает, что Вашей организацией нарушаются требования ст.1 ФЗ от 22.05.03 №54-ФЗ "О применении ..." и технические требования "Фискальный регистратор", утвержденные ГМЭК по ККМ 27.12.95, протокол №9/25-95, а именно:
Вашей организацией применяются в составе одного расчетного узла компьютерно-кассовой системы несколько фискальных регистраторов, в том числе принадлежащих разным пользователям, что приводит к нарушению порядка и условий применения контрольно-кассовой техники, а также может повлечь за собой нарушения в части обеспечения несанкционированной корректировки итоговой информации до ее регистрации в фискальной памяти фискального регистратора.
Учитывая вышеизложенное ....
1. Немедленно устранить ...
2. В случае невыполнения ... Ваша организация будет привлечена в соотв. со статьями 19.5 и 14.5 КоАП РФ к админ. ответственности"

У нас существуют две организации, POS-ы организованы как на основе POS-систем от Штрих-М, так и на основе обыкновенных компьютеров. ФР реально правильно зарегистрированы в ИФНС, на POS стоит купленное ваше программное обеспечение Штрих-М:Кассир 1.9 и используется ее возможность работы с несколькими ККМ - в составе POS два ФР от разных организаций, товары первой организации закреплены за секцией 1, второй - за секцией 2. Также закреплены и ККМ. Что нам ответить налоговой, как вы думаете?


Ср май 02, 2007 9:50 am
Профиль
Новичок

Зарегистрирован: Пн мар 14, 2005 4:32 pm
Сообщения: 230
Сообщение 
Я думаю, что налоговая инспекция в своих действиях опирается на технические требования в расчетному узлу компьютерно-кассовой системы, поэтому оспорить предписание практически невозможно.

_________________
С уважением,
руководитель отдела экспертизы ЗАО "Штрих-М"
Шибина Ольга Михайловна


Ср май 02, 2007 12:30 pm
Профиль
Постоянный участник
Аватара пользователя

Зарегистрирован: Пт апр 01, 2005 12:51 pm
Сообщения: 342
Откуда: г.Киров
Сообщение 
стоп вопрос :

Вы бъете товары 1 фирмы на фискальник 2 фирмы просто в другую секцию?


Ср май 02, 2007 12:35 pm
Профиль ICQ
Новичок

Зарегистрирован: Сб апр 09, 2005 7:35 am
Сообщения: 74
Сообщение 
Цитата:
Вы бъете товары 1 фирмы на фискальник 2 фирмы просто в другую секцию?

Нет, конечно. В 1С мы приходуем товары от двух фирм. При выгрузке (самописная обработка) она формирует файл для загрузки в POS в котором товары первой фирмы считаются закрепленными за 1-й секцией, товары второй - за второй. В программе за 1-й секцией закреплена ККМ первой фирмы, за второй - второй. Т.о. при продаже товаров сразу от двух фирм естественно программа пробивает чеки на товар от первой фирмы в первой ККМ, от второй - на второй. покупателю отдаются оба чека. Удобно, т.к. в большом супермаркете продаются товары обоих фирм (товар в зале разделен на зоны по фирмам, ценники висят каждый от своей фирмы, т.е. никакого смешивания), а кассы стоят на одном выходе. Еще загвоздка в том, что кассир, работающий в первой фирме продает товары на кассе от другой фирмы, а также деньги от покупателей лежат в одном кассовом ящике, но это уже из другой оперы.
Теперь придется получается делать два выхода, разные POS ставить, покупателя к двум кассам гонять ... дурдом какой-то. У нас в городе много других фирм работающих по этой схеме. Я предложил нашему юристу собраться вместе с другими фирмами и решить что делать. Посмотрим какой выход из ситуации они найдут.
Дурацкое государство ...


Чт май 03, 2007 2:06 am
Профиль
Постоянный участник
Аватара пользователя

Зарегистрирован: Пт апр 01, 2005 12:51 pm
Сообщения: 342
Откуда: г.Киров
Сообщение 
У нас была похожая ситуация !

Решили мы ее так. Сказали коротко типа.: Че хотите товар приходит на разные фирмы , на разных фискальниках и бьется. Чего еще надо. Учет верный Регистрация продаж идет верно проверяйте и обороты и продажи поднимайте бухгалтерию и т.д.

ПОсле этого они отвязались.

Пытались этим же законом отмазаться но так как они сами в этом мало что понимают ушли :)

У нас прикопались что типа кассир оформлен на одной организации а работет с двумя :)


Чт май 03, 2007 6:21 am
Профиль ICQ
Новичок

Зарегистрирован: Сб апр 09, 2005 7:35 am
Сообщения: 74
Сообщение 
Цитата:
Сказали коротко типа.: Че хотите товар приходит на разные фирмы , на разных фискальниках и бьется. Чего еще надо. Учет верный Регистрация продаж идет верно проверяйте и обороты и продажи поднимайте бухгалтерию и т.д.

Если бы все так было просто. Я так понимаю, что в нашей бухгалтерии все равно не все в порядке и на такой шаг они не пойдут - а вдруг возьмут и придут, и начнуть проверять? :o
Мне кажется, что в основном налоговая боится вот этого в основном:
Цитата:
нарушения в части обеспечения несанкционированной корректировки итоговой информации до ее регистрации в фискальной памяти фискального регистратора

И сыр-бор именно из-за этого. Вот если бы программа "Штрих-М:Кассир" была бы сертифицирована и имела бы подлинный сертификат о том, что это сделать невозможно (имеется в виду коррекция до регистрации в памяти) и т.п. сертификации ... Но опять же - процедуры сертификации нету....


Пт май 04, 2007 8:26 am
Профиль
Новичок

Зарегистрирован: Пн мар 14, 2005 4:32 pm
Сообщения: 230
Сообщение 
Akam писал(а):
И сыр-бор именно из-за этого. Вот если бы программа "Штрих-М:Кассир" была бы сертифицирована и имела бы подлинный сертификат о том, что это сделать невозможно (имеется в виду коррекция до регистрации в памяти) и т.п. сертификации ... Но опять же - процедуры сертификации нету....

Плюньте через левое плечо, уважаемый. Сертификация программного обеспечения фискальных регистраторов существенно усложнит жизнь организациям, применяющим ККТ, не говоря уже об удорожании системы. Тем более что к реальной защите фискальных данных сертификация не имеет никакого отношения. ФР гарантирует, что данные, напечатанные на чеке, будут занесены в фискальную память (при условии применения штатного внутреннего программного обеспечения) От внешнего ПО запись информации в фискальную память не зависит.

_________________
С уважением,
руководитель отдела экспертизы ЗАО "Штрих-М"
Шибина Ольга Михайловна


Пт май 04, 2007 11:26 am
Профиль
Новичок

Зарегистрирован: Сб апр 09, 2005 7:35 am
Сообщения: 74
Сообщение 
Цитата:
Сертификация программного обеспечения фискальных регистраторов существенно усложнит жизнь организациям, применяющим ККТ, не говоря уже об удорожании системы

Чем усложнит? Поставил программу и на все нападки налоговой тыкаешь им в нос сертификатом. А вот что удорожание - это верно.
Цитата:
Тем более что к реальной защите фискальных данных сертификация не имеет никакого отношения

Я не говорил про защиту фискальных данных, я говорил про корректировку информации ДО ее записи в фискальную память.
У меня две организации, например, одна работает по общей системе налогообложения, вторая по ЕНВД. Подключены два фискальника (как у меня) и подходит покупатель, у которого в корзине товар А на 100 рублей от первой орг-ции и товар Б на 50 рублей от второй. Покупатель обычно не берет чеки, а если и возьмет - ему по барабану кто по какой системе у меня облагается налогами, главное, чтобы в сумме 150 рублей было и его не обманули (ИМХО). А мы в программе обозначаем, что в такой ситуации мы на фискальник первой организации даем не 100 рублей, а 10 рублей, а на второй - 140. Выгода? Очевидна. А вот в сертифицированной программе такого бы не произошло - это противоречит требованиям, заявленным при сертификации. Ну вот как-то так сумбурно объяснил ...[/quote]


Сб май 05, 2007 3:07 am
Профиль
Новичок

Зарегистрирован: Чт июл 07, 2005 3:48 pm
Сообщения: 101
Сообщение 
Вот с подачи таких личностей, похоже и начался весь сыр-бор...
Akam писал(а):
Чем усложнит? Поставил программу и на все нападки налоговой тыкаешь им в нос сертификатом. А вот что удорожание - это верно.

А Вы подумайте получше чем усложнит. Если лень, то я подскажу - любой прикладной софт, работающий с фискальным регистратором нужно будет сертифицировать. Мир не сошелся клином на Штрих:Кассире, и под эти требования попадут, к примеру, 1Свские конфигурации, как типовые (1С:Бухгалтерия, 1С:Торговля и Склад), так и собственной разработки. Сертифицировать нужно будет ВЕСЬ софт. И по логике вещей получается, что, пройдя однажды сертификацию со своим софтом, если ты внес какие-то изменения в свою программу, то сертификацию нужно будет проходить заново. А это время и деньги. Причем Ваши.

Akam писал(а):
Я не говорил про защиту фискальных данных, я говорил про корректировку информации ДО ее записи в фискальную память.

Попробуйте привести пример как вы сможете откорректировать данные до записи в ФП.
А пример, расписанный Вами, с двумя корзинами с товарами по ЕНВД и по общей схеме учета, так это проблемы вашего внутреннего товароучета. И в случае сертифицированного ПО ничто не помешает весь товар также пробить как проходящий по ЕНВД.

Корректировка информации до ее записи в фискальную память, подразумевает такую ситуацию, когда чек покупателю выдается на будто-бы 100рублей, а в ФП с ЭКЛЗ мы отдельными какими-то средствами отображаем 10 рублей. Соответственно, при снятии Z-отчета показываемая выручка будет занижена в несколько раз.
И невозможность этого действия должен обеспечивать как раз драйвер и сам фискальный регистратор - то что жирная сумма ИТОГО в чеке будет соответствовать сумме в ФП и ЭКЛЗ. И прикладное ПО верхнего уровня здесь совершенно не при чем. И проводимая сейчас или ранее сертификация фискального регистратора вкупе с протоколом обмена, как раз должна гарантировать невозможность подделки фискальных признаков чека из ПО верхнего уровня. Опять же уточняю - подделать средствами протокола обмена.

Если вспомнить времена до ЭКЛЗации, то были сторонние технические и программные средства, которые позволяли на некоторых ККМ до закрытия смены откорректировать данные находящиеся в оперативной памяти по незакрытой еще смене. И уже после корректировки производилось закрытие смены и в ФП попадала меньшая сумма, которая и фигурировала в отчете с гашением. Именно для решения этих проблем и была проведена эклзация. А еще ранее была проведена эталонизация.

_________________
Евгений.


Сб май 05, 2007 10:41 am
Профиль
Новичок

Зарегистрирован: Сб апр 09, 2005 7:35 am
Сообщения: 74
Сообщение 
Будем переходить на личности? Тогда давайте: купите очки и внимательней прочитайте, что написала Shibina Olga:
Цитата:
Сертификация программного обеспечения фискальных регистраторов существенно усложнит жизнь организациям, применяющим ККТ

Я применяю ККТ, немного, всего 47 штук и то, что у организации Штрих-М или другой, разрабатывающей программы типа Штрих:Кассира, будет болеть голова о том, что после изменений или т.п. нужно будет заново сертифицировать программу - меня мало волнует. То, что это приведет к удорожанию - я согласен. Все остальное - не мои проблемы. Сам я изменения не вношу, если они мне будут нужны - я буду разговаривать с разработчиками. И где тут (кроме удорожания) усложнение моей жизни?
Не подумайте, что я ратую за сертификацию. Понимаю, что это будет усложнением (а для всех еще и удорожанием) ПО, поэтому и пытаюсь разобраться - как сейчас мне выйти из ситуации с налоговой, описанной выше. Просто помечтал - да, если бы сертифицировано было, было бы с налоговой легче разговаривать.
Цитата:
Попробуйте привести пример как вы сможете откорректировать данные до записи в ФП

Я уже привел - с помощью прикладного ПО верхнего уровня. Которое выдаст неправильные данные для записи драйверу.
Цитата:
И в случае сертифицированного ПО ничто не помешает весь товар также пробить как проходящий по ЕНВД
Да ну? А если программа сертифицирована и сертификат гарантирует что данные не будут изменены во время всего прохождения данных до записи в ФП и ЭКЛЗ? Если сертификат будет гарантировать, что данные предназначенные для одной ККМ не попадут в другую ККМ или вообще будут занижены до передачи драйверу для последующей записи? А если я все-таки сам смогу изменить код программы - это уже нарушение лицензионного соглашения будет (можно так сделать) и сертификации, что автоматически лишает данную копию программы сертификата и как следствие налоговая (да и не только она наверное) может на меня, как говорится, "наехать".
Цитата:
И невозможность этого действия должен обеспечивать как раз драйвер и сам фискальный регистратор - то что жирная сумма ИТОГО в чеке будет соответствовать сумме в ФП и ЭКЛЗ. И прикладное ПО верхнего уровня здесь совершенно не при чем. И проводимая сейчас или ранее сертификация фискального регистратора вкупе с протоколом обмена, как раз должна гарантировать невозможность подделки фискальных признаков чека из ПО верхнего уровня. Опять же уточняю - подделать средствами протокола обмена.
Дак вот это-то и самое главное, о чем я и говорю! Каким образом влияет ПО верхнего уровня, а также установка двух или более ФР в один кассовый узел на то, что будет подделана информация ПОСЛЕ того, как она попадет к драйверу и начнется запись в ФП и ЭКЛЗ? Никак. Возможность изменить информацию возникает только на одном уровне - уровне прикладного ПО верхнего уровня или сторонними программами, вклинивающимися до того, как информация начнет попадать в драйвер и т.д. ниже. Вот скажите мне - как объяснить налоговой, что если мое ПО правильно обработало информацию и выдала правильные данные для записи в те ККМ, что находятся в кассовом узле, сколько бы их там ни было, то дальше их уже изменить нельзя. Поэтому количество ККМ на одном узле не имеет значения. Имеет значение правильность тех данных, что им дано для записи. А это уже проблемы прикладного ПО верхнего уровня. А налоговая пошла по более легкому пути, который возможен в данный момент - гораздо легче не просматривать это ПО, которое не сертифицировано и может делать что угодно и выдавать данные какие угодно, а заставить иметь на одном узле только один ФР. Проверять одно куда легче, чем разбираться - а куда ушли не те данные? В какую из ККМ, которые еще подключены? Или вообще растворились до того, как попали к драйверу?

Может я что-то не так понимаю? Объясните, пожалуйста.


Пн май 07, 2007 2:57 am
Профиль
Новичок

Зарегистрирован: Чт июл 07, 2005 3:48 pm
Сообщения: 101
Сообщение 
Не буду сильно много цитировать. Я попробую еще раз объяснить основные моменты, а Вы постарайтесь их понять.
1.Помимо штрих:кассира есть масса другого софта, который используется в качестве кассового. Причем, если в сфере розницы, преобладают стандартизированные решения, то в оптовой торговле или при оказании услуг чаще используется ПО собственной разработки, в котором реализованые определенные особенности учета. Теперь попробуйте всю эту массу сертифицировать. И какой будет порядок внесения изменений в софт в случае необходимости, если, например, в нашем случае в ПО изменения вносятся каждые два-дня? Предлагаете мне каждый раз по новой проходить сертификацию?
2."Разбивка" чека на несколько ККМ - это целиком и полностью задача прикладного ПО. Принцип разбивки определяется особенностью ведения учета. Ваш пример с разбивокй по ЕНВД/неЕНВД это всего лишь частный случай. Насколько реально это будет сертифицировать?
3.Все ККМ, включенные в госреестр, проходили предварительную аттестацию в ЛЭО и должны гарантировать соответствие печатаемого чека той информации, которая заносится в ФП и ЭКЛЗ. И причем тут сертификация "верхнего" ПО? Команда регистрации протоколом обмена предусмотрена только одна, безо всяких вариантов типа "не записывать в ЭКЛЗ".

Цитата:
Вот скажите мне - как объяснить налоговой, что если мое ПО правильно обработало информацию и выдала правильные данные для записи в те ККМ, что находятся в кассовом узле, сколько бы их там ни было, то дальше их уже изменить нельзя. Поэтому количество ККМ на одном узле не имеет значения. Имеет значение правильность тех данных, что им дано для записи.

Тут все верно. Есть сумма покупки - есть два чека с фискальными признаками. Есть отчет по чекам в ЭКЛЗ, по которому можно проверить что данные по чекам были учтены.
Цитата:
Проверять одно куда легче, чем разбираться - а куда ушли не те данные? В какую из ККМ, которые еще подключены? Или вообще растворились до того, как попали к драйверу?

А вот тут неверно. Опубликованный протокол обмена с ФР не предусматривает разных методов отдельно для печати чека и для записи в ФП. Все делается одним набором команд - печать чека, и фиксирование сумм в ФП и ЭКЛЗ при закрытии чека.

Причина претензий налоговой по поводу подключения нескольких ФРов состоит в том, что не получилось всю розницу перевести на ООО под нормальное налогообложение, когда "закручивали гайки" "алкоголикам". Установить два ФР на кассовый узел и продолжать торговать неалкогольной продукцией дальше по ЕНВД оказалось достаточно простой задачей. Основанием для придирок послужили технические требования к ФРам, в котором прописано, что кроме ФРа с составе кассового узла других печатающих устройств быть не должно. Честно говоря, на эти требования местные налоговые просто закрывают глаза, так как повсеместно стоят те же офисные принтера параллельно с ФРом. В ресторанах в баре стоят принтера заказов. И т.д. В данном случае были просто сделаны частные выводы в отношении именно подключения двух или более ФРов.
А сертификация ПО Вас никак не спасет - раз прописано, что должен быть только один ФР, значит только один. А то что там были сделаны, честно говоря, бредовые предпосылки, так это вполне очевидно. И выводы, соответственно, получились такие же.

_________________
Евгений.


Пн май 07, 2007 9:50 am
Профиль
Новичок

Зарегистрирован: Сб апр 09, 2005 7:35 am
Сообщения: 74
Сообщение 
Все, что Вы написали - это было мне понятно. И даже то, что Вы посчитали, что я понял неверно. Просто я видимо плохо объяснил свою точку зрения и вопросы. Ладно, не в этом сейчас дело. А последний абзац - это тоже верно и понятно. Только не все налоговые, видимо, закрывают глаза на это и наша их сейчас "приоткрыла" :) Вобщем наш юрист сказала, что мы не будем пока предпринимать никаких действий по этому письму, а вот когда налоговая решит начать привлекать нас по тем статьям КоАП, то мы начнем "бодаться". Прецедентов пока не было в этом вопросе, посмотрим что они "предъявят" другим фирмам в нашем городе и как они будут выкручиваться. Если будет интересно - сообщу как будет продвигаться это дело.
Спасибо за разъяснения.


Пн май 07, 2007 10:50 am
Профиль
Новичок

Зарегистрирован: Пн мар 14, 2005 4:32 pm
Сообщения: 230
Сообщение 
Цитата:
Я применяю ККТ, немного, всего 47 штук и то, что у организации Штрих-М или другой, разрабатывающей программы типа Штрих:Кассира, будет болеть голова о том, что после изменений или т.п. нужно будет заново сертифицировать программу - меня мало волнует. То, что это приведет к удорожанию - я согласен. Все остальное - не мои проблемы. Сам я изменения не вношу, если они мне будут нужны - я буду разговаривать с разработчиками. И где тут (кроме удорожания) усложнение моей жизни?

Если сейчас время исправления ошибки в программе или доработки ПО под изменившиеся требования пользователя зависит только от возможностей разработчика, то при обязательной сертификации к этому сроку надо будет добавить 120 дней на проведение экспертизы. Вы готовы ждать полгода?

Цитата:
У меня две организации, например, одна работает по общей системе налогообложения, вторая по ЕНВД. Подключены два фискальника (как у меня) и подходит покупатель, у которого в корзине товар А на 100 рублей от первой орг-ции и товар Б на 50 рублей от второй. Покупатель обычно не берет чеки, а если и возьмет - ему по барабану кто по какой системе у меня облагается налогами, главное, чтобы в сумме 150 рублей было и его не обманули (ИМХО). А мы в программе обозначаем, что в такой ситуации мы на фискальник первой организации даем не 100 рублей, а 10 рублей, а на второй - 140.

Все это ерунда. С таким же успехом можно поставить две автономные кассы и ручками пробивать 140 и 10 рублей. Кодекс об административных правонарушениях предусматривает единственную причину, по которой может быть наложен штраф – это неприменение ККМ. Под неприменением понимается фактическое неиспользование ККМ, использование ККМ, не включенной в ГР, использование незарегистрированной ККМ, использование ККМ без ФП, использование ККМ с поврежденной пломбировкой, а также пробитие чека с указанием суммы, менее уплаченной покупателем (постановление Пленума ВАС от 31.07.2003 №16). Если вы продаете товары на 100 и 50 руб. и выдаете чеки на 140 и 10 руб., то либо вам придется доказать, что товары стоят 140 и 10 руб. (с учетом наценок, скидок, рекламных акций и т.п.), отразить это на ценниках и объявлениях, представленных в магазине и официально провести это по обеим бухгалтериям, либо с вторым чеком вы попадаете на неприменение контрольно-кассовой техники. Если вы сможете официально обосновать такое превращение цен, то неважно, на чем пробиваются чеки (на ФР или других типах ККМ), и даже если введут сертификацию внешнего ПО, оно будет обязано уметь реализовать такую возможность.
Еще раз повторяю, что в контроле за применением ККТ есть три момента: во-первых, данные должны быть отражены на чеке, во-вторых, эти же данные должны быть записаны в фискальную память, в-третьих, они должны совпадать с суммой, уплаченной покупателем. Все, что происходит до момента пробития чека, не регулируется законом о применении ККТ, но регулируется другими нормативными актами – ГК, законом о защите прав потребителей, правилами торговли и т.п.

Цитата:
Если сертификат будет гарантировать, что данные предназначенные для одной ККМ не попадут в другую ККМ или вообще будут занижены до передачи драйверу для последующей записи?

А если данные будут занижены до передачи во внешнее ПО? Хитрый сканер с памятью, который подменяет цены – будем сертифицировать все подключаемое оборудование? Хитрый кассир со злым умыслом, нажимающий не те кнопки – будет сертифицировать кассиров?

Цитата:
Поэтому количество ККМ на одном узле не имеет значения. Имеет значение правильность тех данных, что им дано для записи. А это уже проблемы прикладного ПО верхнего уровня.

Имеет значение только то, что напечатано на чеке и что попадает в фискальную память. Именно эти суммы будут сравниваться с ценниками, накладными и т.п.

_________________
С уважением,
руководитель отдела экспертизы ЗАО "Штрих-М"
Шибина Ольга Михайловна


Пн май 07, 2007 2:20 pm
Профиль
Показать сообщения за:  Поле сортировки  
Ответить на тему   [ Сообщений: 42 ]  На страницу Пред.  1, 2, 3  След.

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.
Русская поддержка phpBB