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

конечно

пускай все проверяют

(+2) один отчет пусть проверят 2-3 буха!

а если бухи невменяемые?

(4) хех
а зачем таких вообще держать :)

Я где то слышал, что 1С сама заявляет, мол "фирма 1С не несёт ответственности за достоверность  информации, полученной с помощью её программы. Вся информация требует дополнительной проверки специалистом". За точность не ручаюсь, но где то что то такое мелькало.

(6)Под "специалистом" что понимается интересно? Куча сертификатов?

(7) Бухгалтером-специалистом

жалко их...их уже по скорой увозят одного за одним...годовой-с...

стрелочник...

(9) А тут - кто на что учился...

Робяты. Кто работает с булгахтерами не первый день - знает одну непреложную истину - ВСЕГДА виноват программист. Поэтому нада быть философом (что не отменяет хор.знание предмета и ответственность). Программист виноват внутри конторы. А вне - ГБ. Так что уважайте друг дружку

(12) Это верно, что корайними всегда оставляют (или пытаются) программистов. Но как часто возникают ситуации типа "Ваша программа считает неправильно". Проверяем - накосячил бухгалтер. На нашу реплику ответ "А почему ваша программа не остановила бухгалтера и не предупредила об ошибке?" Это было всегда, это будет всегда, НО... от этого отбиваться надо любыми способами. ну не может знать программист (особенно приходящий) особенности ведения учёта на конкретной конторе. И сколько реально должно получиться, например, прибыли он тоже представления не имеет.

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

(13) А юзера-то у вас грамотные вопросы задают. :-)
Про контроль правильности ввода. :-)

(14) Верно, но конкретно мучить юзеров - тоже не дело...

Есть ошибки 2 типов:
1) от незнания основ учета,его неправильное ведение и неправильного ввода данных
2) ошибки алгоритма расчета

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

(14)Да-да. Когда (т.е. сегодня) у бухгалтера спрашивает глбух как он начисляет амортизацию по пробегу, а этот бухгалтер у меня, я начинаю сомневатся в себе - на том ли месте я работаю.

Ну это еще цветочки.
у меня как-то глав бух подразделения спрашивал какой план счетов ей сделать...

(15) А какую проверку ты предлагаешь поставить, если по требованию ГБ установлено разрешение отрицательных остатков. Юзер приходует один товар, а продаёт другой (товары называются одинаково) и при этом вылазят отрицательные остатки? Какую проверку поставить на ручные операции, которые некоторые пользуют где угодно и когда угодно? Как можно отследить факт изменения периодики справочника, которые в последствии вызывают колапс 1С? Всего предусмотреть невозможно. Если идти по пути "максимальная защита от дурака" то можно допрограммироваться до паранойи и код проверки от ошибок и фиксации возможных косяков юзеров превысит рабочий код программы.

(20) Вот именно. Грамотный персонал... Голубая мечта любого 1С-ника...

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

(20) "А какую проверку ты предлагаешь поставить, если по требованию ГБ установлено разрешение отрицательных остатков. Юзер приходует один товар, а продаёт другой (товары называются одинаково) и при этом вылазят отрицательные остатки? "

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

"Какую проверку поставить на ручные операции, которые некоторые пользуют где угодно и когда угодно?"

Запретить их. Особенно рядовым юзерам. Их "необходимость" просто означает недоработки в программе, и частичное решение какой-то проблемы за счет ручной деятельности пользователя.

"Как можно отследить факт изменения периодики справочника, которые в последствии вызывают колапс 1С? "

Это недостаток Торговли. Плохо так оставлять как у них сделано - все движения, в т.ч. по справочникам, должны быть строго документами.

"Всего предусмотреть невозможно."

А я почему-то уверен в обратном. Необходимо предусматривать именно все, чтобы ни одна обезьяна не могла "все испортить".

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

Не скажи - там не так много проверок. Их объем конечен, а если что-то забыл, то надо по факту ошибки добавлять недостающую проверку.

Очень хорошо когда на этапе постановки задачи пишется ТЗ тогда можно сразу увидеть чья вина, бывает что и постановщик ошибается

О как наболело. А задачка не имеет решения. Идеальный программёр + идеальный юзер - это утопия. Еще лучший вариант программер и юзер (он же бух) в одном лице. Много раз приходилось идти по пути ужесточения прав. Потом приходилось многое делать либо самому, лтбо тому, у кого много прав. Как правило, это начальники, которые этим заниматься тож не хотят. Поэтому со временем все раскручивается в обратную. Хорошая программа и ее обслуживатель и улучшатель  -это хорошо. А человеческий фактор - все перекорежит.

Полгода назад, эта тема подробно обсасывалась на Кубани, вот что получилось
http://semensemenych.narod.ru/fl20.html

(23) Всё что ты написал ты объясни какому нибудь бухгалтеру. Если ты работаешь (работал когда нибудь) во франче, то наверняка знаешь, что перешибить устои ведения бухучёта на предприятии практически невозможно. В конце концов те же юзеры резонно отвечают "не мы для 1С, а 1С для нас".

(27) Вводить нормальный учет товаров по их числовым идентификаторам надо обязательно. В этом как раз легко всех убедить.

Если юзера говорят "почему программа не заблокировала действия бухгалтера", то они сами же этого хотят.

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

(+28) имхо

(1) ИМХО, предупредить нужно. Вообще, это очень сложная ситуация, но программисту нужно дружить с заказчиком. Соответственно, если заказчик не урод какой-нить, то всё понимает. Если же ГБ - сука, а баланс не идёт, то, естественно, крайним будет программист. Опять же - это вопрос этики. Нормальные люди всегда найдут компромис.
А ещё, смотря как смотреть. Что в твоих должностных обязательствах сказано, под чем подписываешься? Может, ты обязательства дала о сроках, например? Тут уже правовая точка зрения.

ИМХО, в таком случае ответственность несёт сам заказчик. Если конфа ещё не написана - значит и Акты выполненных работ не подписаны, т.е. заказчик САМ ещё не признал эту конфу соответствующей. Следовательно он сознательно использует несоответствующую на тот момент систему учёта. Его решение - ему за него отвечать.
Дело в том, что ошибки в отчётности чаще могут возникать не по вине программистов, пишущих программу, а по вине заказчика,не ведущего контроля за разработкой, развитием, изменением ЕГО (заказчика) системы учёта и, как следствие, незнание "слабых" мест СВОЕЙ системы учёта. Заказчик заведомо знает, что система работоспособна, но не до конца корректно работает. Потому Он и Акт ешё не подписал.Это пустые обвинения.
Принимаются только обвинения на тему: "У нас работало и ни кто её не трогал, а Вы пришли, потрогали - теперь не работает". Остальное - от лукавого. Нет предмета спора, способного причинить вред. Программа - это то, что работает, существует. Как качественная единица, как вещь.  Что по мнению заказчика не работает, то и не существует. Его решение укладывается в его предпринимательский риск.

Когда меня учили программировать, гуру говорил "юзер имеет право нажимать _любые_ клавиши на клаве, кроме сочетания Alt+Ctrl+Del, остальное ты _должен_ предусмотреть". С приходом NT/XP могут давить всЁ.
В 1С так тоталитарно реализовать по крайней мере трудно. В критических местах - предупреждать и писать логи. Или вот примерчик под рукой:
   МОтвет=Вопрос("За "+ДатаДня+" найден временный Z!"+РазделительСтрок+"Удалять?",4);
   Если МОтвет=6 Тогда
       Сообщить("Ок. Удаляю временный");
   Иначе
       Сообщить("Нет? Все равно удалю ;)");
   КонецЕсли;
   ДокерЗет.Удалить(1);
------
Конечно хозяин - барин, но если есть ощущуние, что от выполнения капризов может подкрасться известный зверек - то, плз, завизируйте каприз в письменной форме.