Если они вообще в состоянии будут просто декларации принять в апреле.
Запасаемся попкорном
 |
Если они вообще в состоянии будут просто декларации принять в апреле.
Запасаемся попкорном
Главное чтобы операторы приняли.Сообщение от Зета
Если они вообще в состоянии будут просто декларации принять в апреле.
Запасаемся попкорном
Меня радует что 25 апреля суббота. Если в последние дни будет не реально отправить, операторы будут перегружены десятками/сотнями мегабайт или даже гигабайт деклараций, как это например было с запуском сдачи 4-ФСС через их портал, то хотя бы в выходные нагрузка должна быть пониже.
alexstrel, за операторов я как-то меньше переживаю
Как обработают налоговики это уже не так важно, главное чтобы было подтверждение от оператора о своевременной отправки. А налоговые пусть хоть месяц их принимают, главное чтобы счета не блокировали, если за 10 дней не успеют загрузитьalexstrel, за операторов я как-то меньше переживаю
alexstrel, так я про попкорн как раз по этому поводу - будем наблюдать, как налоговики с приемом справляться будут
статистику проходили? знаете что такое выборка и что не всегда массивы обрабатывают сплошным методом,а иногда и через случайную выборку.. а если ты будешь знать что налоговая в любой момент запросит документы ты сто раз перепроверишь свои данные
Жесть. Если они будут так делать, то это просто жесть.
Вот именно перепроверка данных перед сдачей декларацией меня и напрягает больше всего.а если ты будешь знать что налоговая в любой момент запросит документы ты сто раз перепроверишь свои данные
и сто раз не увидишь букву "C" вместо буквы "С"
... поскольку вышеизложенное в свете вышеуказанного влечет нижеследующее по отношению к поименованному...
давным-давно уж инспектор всю эту лабуду подписывает без всяких начальников.
кто "они" и кому зададут?Но самое главное - обрабатывать ответы нужно вручную.
Смогут ли они это сделать? Надеюсь они зададут этот вопрос перед отправкой требования.
придумывание себе и нам глупой (или совсем идиотской) работы - любимое занятие всех властей.Может и так будет. Только работа очень глупая. Смысл запрашивать документы, если их проверить нереально по времени.
Надеюсь разработчики этого механизма в налоговой задумаются об этом.
классическое подметание плаца ломом неистребимо.
... поскольку вышеизложенное в свете вышеуказанного влечет нижеследующее по отношению к поименованному...
Посмеялся. Вы совсем не разбираетесь в том, о чем пишете. На досуге, посмотрите на размер выгружаемого файла.
Над чем вы смеетесь, над тем что не разбираетесь в сути вопроса?
Это размеры обычных деклараций измеряются килобайтами.
А представьте xml файл в котором будут данные из книг покупок и продаж крупных организаций. Вы представляете сколько счет-фактур на покупку и продажу у гигантов в виде Газпрома и им подобным. Даже у регионального крупняка. А они ведь обслуживаются у тех же самых операторов.
Про гигабайты это кстати слова крупных организаций. Они даже при налоговых проверках эти файлы в excel не могут через оператора отправить.
Добр день, подскажите пожалуйста в какой программе вести НДС 2015 самый удобный вариант? Налогопл ЮЛ или 1С 8, ???? Так как раньше в нашей организации был маленьк документо оборот и вели без бухг программ..................а теперь по 100 сч факт в день.............
в той в которой ведете учет
Добр день, подскажите пожалуйста в какой программе вести НДС 2015 самый удобный вариант? Налогопл ЮЛ или 1С 8, ???? Так как раньше в нашей организации был маленьк документо оборот и вели без бухг программ..................а теперь по 100 сч факт в день.............
Честно, не в какой ..............было 3 сч факт в месяц............вели в тетрадке и заносили цифру в деклар по НДС, а теперь 100 сч факт в день.........по опуту, какая программа удобнее в работе, ???
Что скажите???? какая программа удобная?
вы зачем спамите? кому будет интересна ваша тема тот ответит.. Налогоплательщик ЮЛ что умеет? от этого и пляшите
Вам надо думать, не в какой программе НДС вести, а в какой программе вообще учет вести, т.е. выбирать программу не для сдачи отчетности по НДС, а нормальную бухгалтерскую программу.
Для нас главное - подвести итоги... Пока итоги не подвели нас. ©
Спасибо за совет по поводу учета, поясню ситуацию, учет товара и финанс результатов велся в программе, которую компьютерщики разработали под мою деятельность, типа Торговля-Склад, единственный минус моей программы, что она не сможет выгрузить так, чтобы можно было отправить файл - в налоговую.
Поэтому и хотим перейти на программу, в которую можно было бы завести и в итоге выгрузить файл и отправить.........
Может кто разъяснить, чем различаются раздел 8 и приложение 1, и раздел 9 и приложение 1? Чем дополнительные листы книг отличаются от основных?
Я не бух, потому просьба тапками не кидать. Но делать придется именно мне.
Последний раз редактировалось Доктор Ватсон; 04.03.2015 в 19:20.
если программа нравится - пусть выгружает, как умеет; и к этой выгрузке дописывается конвертер в налоговский формат.
или переходить на другую программу. вам считать.
... поскольку вышеизложенное в свете вышеуказанного влечет нижеследующее по отношению к поименованному...
Как правило дополнительные листы к книгам сопутствуют уточненным налоговым декларациям. Раздел 8 - аналог книги покупок, раздел 9 аналог книги продаж
Подскажите: должны ли в книгу покупок счет-фактуры со ставкой 0% попадать? или необязательно?
Имхо нет.
спасибо за ответ!
Сравнивать XML и Excel не есть корректно. Составлял некоторое время назад ручками примеры файлов конкретных разделов деклараций для расчёта ориентировочных размеров файлов. Получились следующие результаты без обфускации XML:
NO_NDS.8 (КнПокСтр) - 560 байт с одним продавцом-юрлицом и одним посредником-ИП;
NO_NDS.9 (КнПродСтр) - 623 байт с одним покупателем-юрлицом и одним посредником-юрлицом;
NO_NDS.10 (ЖУчВыстСчФСтр) - 564 байт с одним продавцом и одним покупателем;
NO_NDS.11 (ЖУчПолучСчФСтр) - 529 байт с одним продавцом и одним посредником;
NO_NDS.12 (ВыстСчФ_173.5) - 258 байт с одним покупателем.
Доп. листы, думаю, тут пока указывать смысла нет, цифры по ним схожи. Попробую изложить своё представление ситуации (расчёты, конечно, очень условны).
Есть организация с большим количеством операций, сдающая НДС. Основной объём отражаемых в декларации операций сосредоточен в одном, максимум двух файлах. Если у неё в квартал получается 150 тысяч строк в книге продаж и 10 тысяч строк в книге покупок, то получаем:
основной файл декларации по НДС - 10-15 КБайт, не больше;
NO_NDS.8 (книга покупок) - 10 тысяч строк * 560 байт, плюс немного служебной инфы - примерно 5,5 МБайт;
NO_NDS.9 (книга продаж) - 150 тысяч строк * 623 байт - примерно 93,5 МБайт.
Цифры, конечно, немалые и с большими допущениями, но до гигабайтных объёмов оно если и дотянет, то в крайне редких случаях. В большинстве случаев считаю, что речь будет идти о тысячах строк и соответственно мегабайтных объёмах. Ранние редакции 535-го приказа ограничивали объём транспортного пакета в 15 МБайт, и крупняку отправить что-то подобных объёмов было проблематично. Нынешняя редакция разрешает отправлять значительно большие объёмы, особенно если дело касается НДС, и зиповать файлы. Надеюсь, СКЗИ, компьютеры и каналы абонентов, операторов и налоговой выдержат подобные объёмы.
С уважением,
Виктор
Это скорее оценка снизу. Если в счете-фактуре позиции с импортным товаром и информацию о каждой ГТД-шке выводить в показатель НомТД получается еще по 26 байт на каждую ГТД-шку. И если в счете-фактуре несколько сотен позиций, то уже в килобайтах получаются строки в книгах.
Что касается объемов файлов, если взять ритейлера с оборотом под 100 млрд. в квартал и посчитать, что средняя сумма по входящей счет-фактуре составляет 100 тыс. руб. (для примера), то его книга покупок будет состоять из одного миллиона строк, т.е. получится всего лишь несколько сотен Мбайт информации (которая легко сжимается в десятки раз архивированием).
Так декларации в xml не архивируются
Согласно схеме транспортного контейнера из п. 3.1 формата транспортного контейнера (535-й приказ), документ заключается в zip-архив, затем шифруется.
Вот ещё подробности по размеру для НДС:
По технологии сжатия:3.1.3.1. Для КНД=1151001 v.5.04 и приложений КНД=Индекс=0000080, 0000081, 0000090, 0000091, 0000100, 0000110, 0000120) к основному файлу (КНД=1151001 v.5.04), размер транспортного контейнера не должен превышать 1 гигабайт, а размер любого файла в контейнере не должен превышать 840 мегабайт. Исходный объем файла, zip-архив которого содержится в контейнере, не должен превышать 10 гигабайт. Транспортный контейнер передается в составе почтового сообщения, размер которого не превышает 1 гигабайт.
(п. 3.1.3.1 введен Приказом ФНС России от 23.01.2015 № ММВ-7-6/23@)
5.2. Объединение и сжатие файлов
5.2.1. Для объединения нескольких документов в один транспортный контейнер и для сжатия документов используется формат zip-архива.
5.2.2. Формат zip-архива описывается в открытой спецификации, доступной по адресу http://www.pkware.com/documents/casestudies/APPNOTE.TXT. Архивирование содержимого больше 4 ГБ должно производиться в соответствии с базовыми возможностями версии 4.5 (ZIP64) без использования шифрования, размеры менее 4 ГБ могут архивироваться в соответствии с базовыми возможностями версии 2.0 без использования шифрования.
(п. 5.2.2 в ред. Приказа ФНС России от 23.01.2015 № ММВ-7-6/23@)
С уважением,
Виктор
Тут согласен.
С уважением,
Виктор
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
