Ну наконец-то. Поспорю. The Bell правильно всё нашёл, но смешал в кашу. "Например, покупатели софта — обычные люди или предприниматели, которые работают по упрощенной системе налогообложения, не принимают к вычету НДС. В этом случае производителям софта придется либо поднимать цену, либо смириться с тем, что нести расходы по НДС придется самостоятельно"  Лол что? Они похоже не поняли как работает НДС и основной мессадж того же Битрикса

Да, у них неидеально, но лучшего подробного описания ситуации я пока не встретил.

Ну точнее они кашу замешали. Я после третьего прочтения понял, что хотел сказать эксперт. Проблема в том, что так как он сказал работает только система в вакууме и голове чиновников. В реалии это так не работает. Ценник всё равно конъюнктурный, ОСНО не любят ничего закупать у УСН (понятно почему). УСН всегда и есть плательщик НДС если что-то покупает. И УСН вынужден крутиться. Поднять цену на НДС? Человек вообще пробовал бизнес вести?

При этом, для софтовой компании важен ФОТ. И крутиться УСН будет в рамках разумного

А никто не посчитал сколько сейчас 14%? Даже я кстати упомянул это просто у себя в ФБ

И кстати - прямо антиофтопик. Посчитать это трудно, потому что реестр Минифры... Правильно - "протухший"

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

А о каком конкретно из протухших реестров Минцифры речь? Потому как у Минцифры реестров много и протухли из них не только лишь все

Очевидно реестр 14%-ников

Надеюсь все знают, что соцвзносы 30%, а не 14% у обычных людей?

14% - это у аккредитованных ИТ-компаний? Которые у Минцифры в Эксельной табличке записаны?

Да

Приветствуем Вас!  
В качестве подтверждения, что Вы не бот, просьба  представиться и рассказать о себе. Если окажется что Вы не человек, то Вы можете быть удалены из чата. Также в чате предусмотрен вечный бан за рекламу

Классическая модель работы с данными предполагает использование ETL инструментов где ETL - это Extract, Transform, Load [1], комплексный процесс описанный ещё в 70-е годы 20-го столетия исходящий из данные последовательно извлекаются, преобразуются и далее уже только загружаются в очищенном/преобразованном виде в базу данных, как правило, являющуюся часть хранилища данных (Data Warehouse) и используемую для аналитических расчётов, систем BI и так далее.

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

Важное изменение в последние годы - это появление нового подхода, ELT. ELT - это Extract, Load and Transform [2], модель построенная на потоковой обработке данных и замену стадий L и T. При ELT данные вначале извлекаются, но ещё до их обработки они загружаются в финальное хранилище и уже инструментами предоставляемыми этим хранилищем они обрабатываются и превращаются очищенные/обработанные данные. Преобразование может производится самыми разными способами, от процедур в SQL, до внешних инструментов по преобразованию данных (data wrangling) и специализированных платформ.

Такой подход резко сокращает время загрузки данных и даёт возможность создавать на базе собранных первичных данных разные итоговые продукты, это могут быть:
- базы для аналитической работы и BI
- базы эталонных (золотых) записей
- срезы данных для использования в data science
и иные продукты.

При этом, для ELT хранилище данных - это не обязательно data warehouse с тщательно прописанными метаданными и тд. Зачастую это озёра данных с куда как менее тщательными требованиями по интеграции данных между собой.

Это не значит что у ELT нет недостатков.
Как минимум можно говорить о том ELT:
1. Требует хранения большего объёма первичных данных.
2. Требует значительных процессорных мощностей в хранилище необходимых для обработки данных.
3. Требует значительного более внимательного отношения к персональным и чувствительным данным, потому что в ETL процессе они, как правило, вычищаются на стадии трансформации и не попадают в целевую систему. А в ELT данные уже в системе и на неё накладываются ограничения связанные с обработкой данных и их хранением в определённой юрисдикции.


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

ELT неразрывно связано с концепцией data pipelines и его отличия подробно разобраны во многих источниках компаний создающие свои продукты по этой концепции:
- блог XPlenty [3]
- блог Panoply [4]
- блог Talend [5]
- блог OpenBridge [6]
- блог DataForm [7]

Спросить чем отличаются ELT от ETL или попросить привести в пример несколько продуктов обоего типа - это хорошие вопросы на собеседовании инженера по работе с данными (дата инженера). ELT применимо не для всех задач, но уже настолько распространено, что нельзя не знать о том что это такое и как устроено.

Ссылки:
[1] https://ru.wikipedia.org/wiki/ETL
[2] https://en.wikipedia.org/wiki/Extract,_load,_transform
[3] https://www.xplenty.com/blog/etl-vs-elt/
[4] https://blog.panoply.io/etl-vs-elt-the-difference-is-in-the-how
[5] https://www.talend.com/resources/elt-vs-etl/
[6] https://blog.openbridge.com/etl-tools-elt-vs-etl-process-89bb1f71c7b3
[7] https://dataform.co/blog/etl-vs-elt

#etl #elt #data #datalakes #datawarehouse

Коммерсант пишет про то что портал Госуслуг хотят сделать единой системой (фронэндом) для работы с обращениями граждан [1].

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

У меня много вопросов по поводу конкретно этой инициативы:
1. Будут ли охвачены обращения по 59-ФЗ или по 59 и по 8-ФЗ?
2. Что делать с обращениями от юридических лиц?
3. Как будут принимать обращения от уязвимых групп граждан (заключённые, не имеющие телефона, не граждане) и тд?

Ссылки:
[1] https://www.kommersant.ru/doc/4396978

#gosuslugi

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

Да, похоже что так и сделают

И снова приходится упоминать Коммерсант, который пишет про то что Правительство РФ не дало монополии Сбербанку на платформу Гостех [1].

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


Ссылки:
[1] https://www.kommersant.ru/doc/4396914

#digital #it #government

На госуслугах можно к организации и сотрудников привязывать, только не помню может ли сотрудник от организации подавать обращение

Да, там прям расширяются горизонты. На самом деле, и неплохо.