Ну дело в том, что не только сама 1С создает прикладные конфигурации, в которых ведется учет.
Например, стандартный продукт от 1С, который называется «Зарплата и управление персоналом» достаточно сложен и удобен, если сотрудников у предприятия более 20-30.
Для более мелких организаций чаще применяется продукт от калужских работников ножа и кода, называется Камин :) Там с багами не так хорошо, вернее, гораздо хуже.
Благодарю за алгоритм, но увы, данные сотрудников даже близко не хранятся в базе, по которой можно гонять T-SQL. Кроме того, правильное хранение ФИО сотрудника обычно не касается того вопроса, что алгоритм, который делает выгрузку, сам по ошибке вставляет эти пробелы.
А в раздел «Алгоритмы» это пришло потому, что не лишне будет в очередной раз помнить — любые строчные данные на входе нужно trim, а уже потом разговаривать.
Вы путаете. ПФ в целом только с 2010 начал принимать что-то в электронке. До этого у них было достаточно мало отчетности, всего раз в год носили «файлик на дискетке».
1. Пенсионный фонд изначально (и до сих пор) не имеет концепции «специализированный оператор». Из-за этого куча проблем, которые в налоговой даже не возникают, т.е. когда ты отправил отчет, это подтверждает оператор. ПФ в таких случаях говорит «ничего не знаю».
2. ПФ до последнего времени имел процедуру взаимодействия в электронном виде, которая даже законной не являлась, поскольку была принята просто в виде внутренней указивки правления ПФ. Это не смущало суды, хотя в нескольких случаях суд просто не принимал их указивку в роли действующей.
3. Только ПФ умудрялся отвечать сначала положительным протоколом, а потом отрицательным.
Я скажу так, что в налоговой бардака гораздо меньше.
Налоговая жрет этот кактус с 2003 года, поэтому у них на сегодня самая стройная и нормальная система. 3-НДФЛ только нельзя сдавать в электронке, но в остальном — крайне хорошо.
ПФ же проигнорировал вообще весь опыт налоговой и начал строить свой чудный мир. О том, как это ужасно было говорит только то, что автор в 2012 году несколько раз судился и выиграл у ПФ.
Автор сдавал, конечно, но тут дело вот в чем — все попытки сделать match по именам обычно лажают на всяких инстранцах, типа «Латыфджонаевич != Латыфджанаевич», только добавляя ада мглы.
В целом, если все платежи корректно идентифицированы, а они обычно без ошибок по СНИЛС, то никакого смысла дублировать эту информацию нет.
Баг в программе, которая отвечает за прием данных на стороне Пенсионного фонда. Это специлизированный софт, который я даже не знаю, как называется. Скриншоты проверки из программы Check-UFA, это написали ребята из ПФ УФЫ.
Удивитесь, но взносы платятся одним куском. Т.е. делается одна платежка, в месяц, за все предприятие. А вот кому какую сумму зачислить на будущую пенсию — это определяется другим особым отчетом, РСВ-1. В его составе есть раздел с делением по лицам.
Как раз дело в том, что установка чего-то свыше обычно не очень прокатывает в роутерах, например. Или разных встроенных системах, у которых бывает не очень с доступом в интернет.
В остальных случаях — да не вопрос. Но речь как раз о духе Unix, т.е. о том, что не надо плодить сущности сверх необходимого. И устанавливать, например, PHP из исходников только потому, что мне надо что-то обработать, а я не знаю регулярных выражений — ну как-то глупо, не находите?
Вы не путайте скриптовый язык, для которого надо что-то установить еще в систему (это не всегда возможно) и, допустим, sed, который ныне и присно и родной бинарно, хоть и не pcre.
Или, допустим, grep, который тоже ныне и присно, и тоже pcre может.
Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.
Например, стандартный продукт от 1С, который называется «Зарплата и управление персоналом» достаточно сложен и удобен, если сотрудников у предприятия более 20-30.
Для более мелких организаций чаще применяется продукт от калужских работников ножа и кода, называется Камин :) Там с багами не так хорошо, вернее, гораздо хуже.
Ну а локальные версии просто хранят это в таком виде, где T-SQL особо не побалуешь.
А в раздел «Алгоритмы» это пришло потому, что не лишне будет в очередной раз помнить — любые строчные данные на входе нужно trim, а уже потом разговаривать.
1. Пенсионный фонд изначально (и до сих пор) не имеет концепции «специализированный оператор». Из-за этого куча проблем, которые в налоговой даже не возникают, т.е. когда ты отправил отчет, это подтверждает оператор. ПФ в таких случаях говорит «ничего не знаю».
2. ПФ до последнего времени имел процедуру взаимодействия в электронном виде, которая даже законной не являлась, поскольку была принята просто в виде внутренней указивки правления ПФ. Это не смущало суды, хотя в нескольких случаях суд просто не принимал их указивку в роли действующей.
3. Только ПФ умудрялся отвечать сначала положительным протоколом, а потом отрицательным.
Налоговая жрет этот кактус с 2003 года, поэтому у них на сегодня самая стройная и нормальная система. 3-НДФЛ только нельзя сдавать в электронке, но в остальном — крайне хорошо.
ПФ же проигнорировал вообще весь опыт налоговой и начал строить свой чудный мир. О том, как это ужасно было говорит только то, что автор в 2012 году несколько раз судился и выиграл у ПФ.
В целом, если все платежи корректно идентифицированы, а они обычно без ошибок по СНИЛС, то никакого смысла дублировать эту информацию нет.
А вот разделить пришедшие за три месяца взносы на конкретных людей можно и с квантом времени «раз в квартал» — для этого и нужен РСВ-1.
Будете удивлены, но на Хабре часто пишут тогда, когда найти разработчиков просто не получается в силу разных причин. Это как раз тот самый случай.
Индексация пенсий работающим пенсионерам ушла только когда подешевела нефть, раньше этот вопрос никого не волновал.
Бюджет пенсионного фонда из субсидий состоял всегда, 50% и более.
Продолжать? Это факты.
1. У нас слишком много бухгалтеров (которые делают отчеты, в которых простые смертные тупо не могут разобраться)
2. Надо бы сделать очередной ежемесячный отчет (который тоже без спец. инструментов не сделать).
Л — логика
В остальных случаях — да не вопрос. Но речь как раз о духе Unix, т.е. о том, что не надо плодить сущности сверх необходимого. И устанавливать, например, PHP из исходников только потому, что мне надо что-то обработать, а я не знаю регулярных выражений — ну как-то глупо, не находите?
Или, допустим, grep, который тоже ныне и присно, и тоже pcre может.
Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.