Вот то, что это зло - всем вроде как понятно. Но время от времени находятся пользователи, пытающиеся выморозить всеми доступными средствами "малюсенькое исправленьице, которые вообще ни на что не повлияет". Товарисчи, поделитесь какими-нибудь мыслями, а лучше статьями или просто разъяснениями где было бы до безобразия просто и понятно сказано, что так делать низзя. Уверен, что есть куча разъяснений, в том числе самой фирмы 1С на этот счет, только вот найти что-то никак не получается, может ищу хреново.

паяльник в штаны и разговор закончен

(0) покажи как летит себестоимость при изменении числом

Простое объяснение - Прострел коленки за такое.

Просто. Доступно. И всерьез.

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

(0) закрывай период

(6) как не позволить это сделать я знаю, я хочу аргументы

(7) если не была соблюдена последовательность в периоде и будет какой-то документ перепроведён - то могут оказаться другие движения документа

(7) забей на аргументы, сами увидят...

малюсеньких исправлений не бывает

+9 если нет здравого смысла, то ссзб

ну или пишите регламент подписанное гендиром: любое малюсенькое исправление - 5000руб в кассу компании, и будет тебе малюсенькое исправление. будет самый весомый аргумент

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

(0) Актуальность данных самое простое объяснение.

(13) добавляй программно без перепроведения, обработкой

(13) перепиши код

в котором можно будет указать : при изменений каких рекизитов нужно/или нет провождить документ

(16) Вот именно. Хотя казалось бы такая простая вещь должна контролироваться платформой. То есть должна быть Модифицированность() и МодифицированностьУчётныхДанных() то есть данных влияющих на движения документа.

(17) Почему эти авнокодеры так не делают при написании типовых конфигураций?

(19) вот в комплексной 77 есть такое
там реализовано следующим образом
в общем журнале есть такое действие с название "редактировать документ"

открывается форма обработки с реквизитами документа, которые не повлияют на движения
юзер изменяет что ему нужно и записывается документ программно

думаю, что в 8ке есть что-то подобное

(20) За все конфы не скажу, но в КА нету. Так же не было такого в ЗУП, Бух и УТ. Но последних версий не видел.

(19) Сделай (с) Волшебник (?)

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

+21 Кстати общего журнала там тоже нет, как такового :-)

Если не нужна себестоимость и не контролируете остатки, то изменения задним числом не страшны

ЕМНИП Групповая обработка справочников и документов позволяет менять реквизиты без перепроведения.

(22) Сделать свою платформу? :-)))
Нет уж. Я ещё не окончательно шизанулся :-)

А есть какие-то ссылки на объяснение самой 1С?

да, точно! во всем виноват Нуралиев.. быгага

Итак что мы имеем по делу:
(2) - показать как летит себестоимость при изменении задним числом.
(8) - если не была соблюдена последовательность в периоде и будет какой-то документ перепроведён - то могут оказаться другие движения документа.
(14) - Актуальность данных.
(25) - Если не нужна себестоимость и не контролируете остатки, то изменения задним числом не страшны.

Не густо, однако, а я прям был уверен, что закидают ссылками. Почему-то кажется, что пользователями эти доводы будут восприниматься типа так:
"Если документ будет перепроведен задним число случится СамЗнаешьЧто" или "Ты что нельзя, все сломается", - такие ответы ИМХО только раззадорят пытливое юзерское "ПОЧЕМУ".

хотя про наказание рублем мысль тоже хорошая :)

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

(0) Чего программисту то об этом париться? Есть ГБ, который отвечает за весь учет. Вот пусть он и решает, малюсенькое это исправленьеце, или нет, повлияет оно на что-либо, или не повлияет.

(32) Согласен и с тобой.
(33) А вот эта мысль мне больше всего, кстати нравится. Осталось только как-то ее внедрить.

(0) так делать можно и нужно.
Нужно всего лишь забить на типовые механизмы и использовать свои.

(34) А чо её внедрять? Я тупо все обращения на открытие периода переводил на ГБ. И ффффсё, дальше уже она пусть сама разбирается.

(35) и иметь отряд программеров, которые будут все это поддерживать? А если нет такой возможности?

(0)По моему так 1сники придумали что нельзя чтоб не работать. На самом деле должно быть можно, но должен стоять киллограмм контролей, чтоб учет не нарушить.

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

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

+(40)Но перепроводить доки задним числом, хоть пару штук, но надо каждый божий день, естественно доверить обычным пользователям ты не можешь это, приходиться самому и тут встает вопрос, что это за прогер, который выполняет тупую работу каждый день и не может оптимизировать ее(в данном случае устронить)?

+(41)Точнее даже сказать, это работа не прогера, но и учет не должны загнуть пользователи вот и встает вопрос как дать работать предприятию, но при этом выполнять только свою работу и чтоб учет не загнулся?)

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

(0) исходя из логики проведение документов будующей датой - ДОБРО :)))

ты даже не предстовляешь сколько у нас ДОБРЫХ пользователей готовых проводить документы БУДУЮЩЕЙ датой :)

(43) да это легко делается созданием корректирующих проводок будущего отчетного незакрытого периода. вопрос стоит в "малюсеньких" исправлениях.

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

в 7-ке у меня, многие реквизиты документов не влияющие на проведение вынесены в отдельные справочники. Но человеческий фактор - непобедим, то товар неправильно указали, то гтд, то количество. Еще бесит когда клиент оплачивает древний счет, и теперь его надо подредактировать, номера что ли в справочник выносить.

(44)Думаю это даже не рассматривается, доки проводяться только оперативно.
(46)Ну поставьте мне памятник тогда, на старой работе, только начиная изучать 1с, я сделал чтоб можно было проводить задним числом, уже наверное год как прогер только отчет за месяц смотрит для контроля "не слетел ли учет", и пока как часики все работает.
Для прогера нет слова невозможно. Нет механизма - сделай.

(48) >>>>Для прогера нет слова невозможно

Боян:
сделай семь перпендекулярных красных линий проходящих через одну точку, при этом 2 красных линии должны быть зелеными и одна невидимой


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

(48) круто! бухия сдала отчетность - циферки сдала в ФНС, а тут ты со своим механизмом. штраф тоже тебе выписывать будут?

(49)Хорошо не попросил вечный двигатель изобрести.

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

(50)А, что я со своим механизмом?

(52) задним числом корректируешь

(53)Я то как раз делаю механизм, чтобы я не корректировал) Корректируют как раз пользователи с разрешения ГБ)

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

(55)Стоит дата запрета периода(дата сдачи отчетности). Если перепроведения задним числом за этот период то все норм, ГБ беспокоить не надо, если пролым периодом, то ГБ проконтролирует чтоб все соответствовало отчетности и все. А механизм мой не дает учет накрыть не зависимо от разрешенности периода.

+(56)Если б Гб сдавал отчет по программе, то и контролировать ей ничего не надо было бы, но так как она корректирует его, то уж измените я не телепат.

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

(50)Кстати и эта фигня решаема, пусть при сдачи Отчета ГБ все расхождения отчета из 1с и отчета к сдаче в ФНС вносит в 1с и можно будет сделать механизм без закрытия периодов и контроля ГБ.

(59) была решена проблема отрицательных остатков путем проверки самых последних? это решает проблему пересчета себестоимости, да???

(60)Не понял вопрос.

(60)Короче, все что пользователи могут сделать на бумажке в жизни, должно быть реализовано в программе и это возможно сделать, дальше остается только думать прогеру.

Это не ЗЛО это косяк 1С.

1С не признает косяков, если что-то не работает то это ФИЧА !!! 1С :)))