В Казахстане на 14/04/2014 зарегистрировано 370,169 юридических лиц, представительств и филиалов.
Допустим что на текущий момент так и осталось 370 169.

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

С трудом представляю себе размер полученной базы данных.
Как думаете через сколько встанет колом вся их система? Какого размера будет база? Как они собираются бэкапить всю эту инфу?
И вообще взлетит ли это все?
Такое ощущение что просто спустили приказ сверху, сделать электронные счет-фактуры, а возможно ли это даже не задумывались.
У меня есть друг, который автоматизировал филиальную сеть на 1с8 более 1000 розничных точек в РФ. Так там столько сил потратили, а тут 370 169 юридических лиц!

(0) с чего она должна встать?

(1) Размер базы и количество транзакций, очень большие.

На семинаре по электронным счет-фактурам правила работы примерно такие.
В конце дня выгрузить СФ за день в xml и отправить их разом.
Если все 370 169 в конце дня отправят, что будет?

(2) Сравни с количеством сотовых абонентов и количеством транзакций в их системах.

(2) Не встанет. Всё за тебя уже посчитано. И у них нет прямых записей в базу. Просто хранилище. Образно современную кору дуба хватит с лихвой для хранения всех ваших с/ф в таком формате.

(2) а какие там транзакции?? эта база может быть разбита по районам или по КПП (или что там в Казахстане), не обязательно все в одной таблице хранить и крутить ее

И что? Технологии на месте не стоят, к тому же это вполне себе технологии big data на структурированных данных, проверенные временем. Не на 1С же это работать будет.

(6) Да вряд ли, на базе одного датацентра реализуют.

370,169 юридических лиц это в общем где-то 370 169 Мегабайт если отчёт в среднем 1 Мб. В месяц это немного.

Таблички в базе: Контрагенты, Номенклатура, Шапка СФ, Строки СФ. Загружать пакетами СФ какому-то кол-ву СФ максимум от 1 ЮЛ. Загрузка всего пакета в 1 транзакции... или загрузился весь пакет или не загрузился полностью...
Не вижу никаких проблемм

Кстати, из этих 370к дай б-г, чтобы треть реально функционировала :)

(0) Я думаю там просто текстовая инфа будет в разрезе идентификаторов.
Не страшно.

Кстати, для сведения - предлагаю оценить объем инфы по регистрации сделок с недвижимостью, вынесения судебных актов, регистрации новых юр/физлиц - это все функционирует на базе гос. датацентра. Одного.

а вот когда заставят сдавать не только СФ выданные но и СФ полученные - вот тут смогут организовать очень интересное сравнение сколько НДС зачли и сколько его учли :)

кранты ВАМ :)

(13) На то и расчет. У нас еще и всеобщее декларирование вводить собираются постепенно.

кстати у нас обязали сдавать в электронном виде книгу покупок и продаж в разрезе ГТД (что бы левак не прикрывали, а то раньше ввезли 100 телефонов по гтд а через торговлю прошло 10000 по этому же гтд), а ведь Россия сильно больше и база наверно в разы больше...

(13) Мы с РФ товар завозим.
В электронной счет-фактуре при продаже некоторых групп товара ввезенных к нам с РФ, должны указать по номер по какому документу завезли в каждой строке.

Будут проверять сколько ввезли и сколько продали.

Почему возникла такая мысль (0).

Потому что когда наши предприятия раз в год, в конец марта сдают в электронном виде годовые отчеты.
То вся их налоговая система начинает висеть примерно с 20 марта. Бывают бухи эти отчеты ночью могут только сдать.
Поэтому главбухи стараются сдать отчетность до 20 марта.

А тут нагрузка в разы увеличивается.

(17) Налоговая и ее СОНО - это отдельный звездец, угробище, созданное коммерческой фирмой в формате распила в свое время, требует тотального рефакторинга. Напрочь. Пытаются исправить ситуацию с "Кабинетом налогоплательщика", но пока там недостаточно возможностей для полноценной сдачи деклараций для юрлиц.

Люди будут пытаться сдать xml по электронным СФ в конце дня, а там все будет висеть.
Для примера возьмем 370 169, ну пусть из них 100 000 активных, которые в день делают 100 СФ.

То есть в день это как минимум 10 000 000 СФ.
Ну, а строк в них 100 000 000.
Объем приличный.

(18) Штат админов и прогеров у них то же. Думаете базу по СФ они лучше сделают?
Тем более зарплаты прогов и админов в налоговой меньше, чем в коммерческих предприятиях. Поэтому там не супер профи работают. Может в Астане они конечно супер команду собрали я не знаю.

(19) Количество организаций, делающих в день по 100 с/ф, измеряется не сотнями тысяч и даже не тысячами. Их десятки, максимум сотни.

(21) Сотни? Моя организация более 100 СФ в день делает.
Таких организации только в моем городе сотни.

(20) Там штат давно поменялся с момента создания СОНО. Но переделывать уже его никто не будет. Да и не штатные кодеры будут разрабатывать такую систему, наймут подрядчика.

(0) а база точно единая?

(22) Сотни организаций, в день толкающих сотням юр.лиц продукцию и услуги? Ну-ну.

(24) Сложно сказать думаю да.
Так как они планируют контролировать экспорт\импорт. Такое только единая база может себе позволить.
(25) Да наверно я не прав. Их наверно действительно не так много.

(26) Дык я и говорю. Ладно бы физикам счета-фактуры выписывали, тогда супермаркеты тысячами плодили бы их. А по юрикам всяко поменьше транзакций. Суммы только другие совсем.

файл хмл в среднем весит 20Кб
в среднем от каждого пусть 10 файлов за день.

360 000 * 20 * 10 = 72млн кб = 72Мб
72*30 = 2Гб файлов в месяц.

Если оптимально построить таблицу данных, то объем занимаемых данных на диске будет примерно такой же, как и файлы xml

хотя.. 3,6млн записей в таблице - это не 72Мб будет. хмм

(28) ещё заарзивируй этот хмл(по сути текст) 20 в 1 кб

Кто сказал что будет одна база на целую страну? В банковских системах и т.д. в каждом городе своя база, что мешает тут сделать так же?

(31) у нас в банковской системе одна база

(31) в банках всё по разному, говорю как тот, кто работал в кредитных организациях.

(26) куча региональных серверов которые собирают данные + главный сервер с натсроеной на него репликацией

кто вообще сказал, что это должна быть одна база?
можно порционировать по регионам, годам и т.д.

Где вы такие маленькие xml берете? )))
Для теста выгрузил сейчас в xml документ Реализация товаров, в которой 47 строк.
Размер 220 кб.

(36) Это что там за структура файла? Может, лишнего полно.

(37) У нас немного изменен документ Реализация товаров.
Но ничего лишнего.
Вот файл:
https://yadi.sk/d/mC9qKHXBoGKUk

(38) Характеристики... субконто... там реально куча лишних данных, совершенно не упирающихся никуда налоговой :)

Выгружал стандартной обработкой
ВыгрузкаЗагрузкаДанныхXML.epf

(40) Дык то-то и оно, что эта обработка в адинэсовом формате выгружает с избыточностью для возможности последующей загрузки в конфигурацию 1С.

(41) Да согласен, в налоговую будет поменьше этого xml.
Не подумал я. 20 кб реальный будет размер.

(0) Все нормально. Вы посмотрите на системы и на размеры баз данных у бирж. Базы данных в несколько десятков и даже сотен терабайт, это не фантастика, а вполне работающие системы. Только СУБД там настраивать приходится очень серьезно. Задача вполне решаема.

Декларация по НДС
Книга покупок 1 258 строк - размер xml файла 379 кб
Книга продаж 4 400 строк размер xml файла 1,23 Мб

Т.е. в среднем получается по 300 байт на 1 фактуру