Безумству храбрых поем мы славу

[Aleksei_kr]

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

[v0str]

+1
Когда я презентовал новую систему, то познакомил слушателей со средством просмотра и правки XML-файлов.
Меня очень просили дать переписать XML-блокнот от Microsoft.
Все бухгалтера, с которыми я работаю, умеют пользоваться этой программой, т.к. прибавить рубль или исправить адрес бывает быстрее в XML-Notepad'e, чем заново собрать отчетность в формирующей программе.

[v_i_b]

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

Лет 1о назад у меня клиенты вместо того чтобы позвонить и установить набивалку для 2-НДФЛ набрали несколько сотен справок в редакторе и успешно отчитались.

[osg_54]

-100
Во-первых, исправить адрес в выгруженном файле - это еще куда ни шло, но даже в этом случае такие "продвинутые" бухгалтеры часто забывают исправить его в базе ЗЛ и наступают на грабли каждую отчетность.
Во-вторых, манипуляция суммами может привести к возврату в будущем всей отчетности и переделке не только предыдущего периода, но и текущего, так как в ПФР вводят ИС с большим опозданием. Только сейчас, например, обнаруживают переплату по 2010 году, в итоге придется переделывать 1 квартал.
В третьих, после "шаловливых ручек" появляется расхождение между базой ИС страхователя и ПФР, что крайне затрудняет поиск и исправление ошибок.

[VinnieThePOOH]

-100
Во-первых, исправить адрес в выгруженном файле - это еще куда ни шло, но даже в этом случае такие "продвинутые" бухгалтеры часто забывают исправить его в базе ЗЛ и наступают на грабли каждую отчетность.
Во-вторых, манипуляция суммами может привести к возврату в будущем всей отчетности и переделке не только предыдущего периода, но и текущего, так как в ПФР вводят ИС с большим опозданием. Только сейчас, например, обнаруживают переплату по 2010 году, в итоге придется переделывать 1 квартал.
В третьих, после "шаловливых ручек" появляется расхождение между базой ИС страхователя и ПФР, что крайне затрудняет поиск и исправление ошибок.

не успел )))

Автор верно определил такие действия как безумство.

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

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

После чего программисту приходится разбираться, откуда вообще пошли расхождения в поданном отчете и в программе, причем автору еще повезло, что ему бухгалтера похвалились (научились править файлы)

Чаще бывает так, что либо упираются - мы ничего не трогали, это ваша программа так работает, или по честному не помнят - вопрос решили и забыли.

Но проблема остается.

Примеры из реальной жизни:

1. правят отчет в XML как у автора
2. считают больничные, что-то не нравится, правят прямо в распечатке (!!!), потом спрашивают, почему в распечатке одна сумма, на основании которой они выплатили. а начислена совсем другая
3. правка платежной ведомости в распечатке, проводится на выплату естественно другая сумма.
4. правка любого документа, печать, а потом выход из документа без сохранения изменений.

P.S. А так я женщин люблю ) не люблю только когда отрицают содеянное.

[Анастасия]

Когда правили файлы ПФР в текстовом формате это удивления не вызывало?

[v0str]

-100
Во-первых, исправить адрес в выгруженном файле - это еще куда ни шло, но даже в этом случае такие "продвинутые" бухгалтеры часто забывают исправить его в базе ЗЛ и наступают на грабли каждую отчетность.

Проблема в том, что мы ходим по полю, усеяному граблями. Адрес в базе ЗЛ может быть и верный, но в следующий отчет изменят КЛАДР и адрес будет неправильный. Поэтому это не аргумент.

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

Не далее как вчера мы манипулировали суммами. Индивидуальные сведения мы не трогали, т.к. они соствалены в рублях и копейках. А вот итоговые суммы в паре пачек исправили на 3-7 копеек, т.к. из-за изуверского округления в программе приема (мне кажется, что это была ПЕРСО) у нас "идет разница в 2 рубля".
Почуствуйте тонкость момента! Добавили 3 копейки - два рубля нашлись!

В третьих, после "шаловливых ручек" появляется расхождение между базой ИС страхователя и ПФР, что крайне затрудняет поиск и исправление ошибок.

Я бы сказал, что шаловливые ручки присутствуют не только со стороны страхователя. В отделении ПФ тоже шалят.

Ну, и еще +100500
Бухгалтер, который знает структуру XML-файла, - это больше чем бухгалтер. С ними проще работать, чем просто с бухгалтером, который на каждый чих требует прихода программиста. (ИМХО)

[VRALD]

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

[v0str]

Пока проблем нет.
Пока переводим дух, пытаемся осмотреться. Оказывается на улице весна!

Но расслабляться нельзя... Скоро отчет за второе полугодие!

[Alex007]

Ну, и еще +100500
Бухгалтер, который знает структуру XML-файла, - это больше чем бухгалтер. С ними проще работать, чем просто с бухгалтером, который на каждый чих требует прихода программиста.
Пока переводим дух, пытаемся осмотреться. Оказывается на улице весна!

Но расслабляться нельзя... Скоро отчет за второе полугодие! (ИМХО)

абсолютно согласен. только отчет за первое полугодие будет=)
сам несколько раз правил XML в блокноте, например адреса в 2НДФЛ, когда ЧЕК ругался, хотя КЛАДР всегда последний ставим. а в PsvRsv при выгрузке персучета остаются пустые тэги с адресом - ЧЕК тоже на это ругается ошибкой, поэтому я их просто удаляю руками. Если делать все со знанием дела - то никаких проблем не возникнет

[osg_54]

...поэтому я их просто удаляю руками. Если делать все со знанием дела - то никаких проблем не возникнет

"Со знанием дела" должна работать программа у бухгалтера, а для этого - прежде всего, её разработчик.

[VinnieThePOOH]

"Со знанием дела" должна работать программа у бухгалтера, а для этого - прежде всего, её разработчик.

А для этого у разработчика должна быть налажена обратная связь с бухгалтером.

Хорошо, что у автора темы она налажена, и он в курсе изменений.

[Alex007]

"Со знанием дела" должна работать программа у бухгалтера, а для этого - прежде всего, её разработчик.

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

[osg_54]

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

Если Вы имеете в виду конкретного разработчика, то, возможно так и есть. Что касается других, он не только должен, но и обязан учитывать, иначе это халтурщик

[Алексей К.]

Это вопрос, наезд или подколка?
А если по существу вопроса в теме, к сожалению, спор безконечен. Истину в нем единую не выработать, так как разные люди, разные ситуации, разные обстоятельства, разные последствия.