ЗИКовцам возможно будет интересно..? да и нам что скажут зиковцы?
 

тестовка здесь:
[url]http://www.forum.mista.ru/topic.php?id=641335[/url]

Сомневаюсь я...

в чем?

2-Чучундер > В месте крепления конечностей...

0-Чучундер > большей частью правда:( мусорные перерасчеты возникают редко, но случаются... (когда пересчитываются/переначисляются "зависимые" периоды в расчетах среднего) тоже как-то писала об этом. и, главное, ничем потом не удаляются... в модуле дока начисления з/п давно поставила ПравилоПерерасчета.Применять(0); в некоторых случаях приходится вырезать эту гадость обработкой.

[quote=Buhta;27906844] в модуле дока начисления з/п давно поставила ПравилоПерерасчета.Применять(0);[/quote]
имеется ввиду процедура ОбработкаУдаленияПроведения

никак не получу зависшие записи в демо...

приведите свою последовательность доков, только чётко - для моделирования

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

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

но меня интересует другой вопрос - а зачем при удалении переначисления за прошлый период вообще вводятся эти записи перерасчёта с круговой красной стрелкой?

придётся лезть в модуль...

8-Гена > а (5) не подходит? и вообще, вкладку среднего заполнять надо...

(5) подходит... но надо понять смысл методологии лучших программистов всех времён и народов...

кажется понял идеологию... хотите послушать сказку?

11-Гена > сказку завсегда рады:)

давным давно... когда деревья были большими... задумались лучшие программисты всех времён и народов над исправлением прошлых периодов...

и придумали встроенный в компоненту Расчет оператор ПравилоПерерасчета

если вы в конфигураторе зайдёте в виды расчётов, то вверху будет группа Правила Перерасчета... для каждого ВР или объединения ВР видна следующая структура работы данного оператора:
При вводе ВР ... Необходимо пересчитать следующий ВР ...
1. только в текущем периоде ЖР (по периоду регистрации)
2. в том же периоде ЖР (по периоду действия)
3. в следующих N периодах (после периода действия)

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

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

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

в результате у всех перерасчётов поснимали слева крыжики на "При вводе ВР", предоставив пользователю уточнять самостоятельно вкладку среднего в подчинённом доке по кнопке "Исправление" с новым номером И-**

если интересно, то можно продолжить...

у оператора ПравилоПерерасчета есть два положения:
Применять(0) и Применять(1)

в ГМ описана переменная Перем ИспПравилПерерасчета Экспорт, которая жёстко в Процедура ПриНачалеРаботыСистемы() задана:
ИспПравилПерерасчета = ПравилоПерерасчета.Применять(1);

исключение дано в интересной процедуре:

Процедура ПриОтменеПроведенияДокумента(Документ)

...
Если Найти("НачислениеЗаработнойПлаты,НачислениеОтпуска,НачислениеОтпускаГосслужащим,ПриказНаОплатуПоСреднему,НачислениеСохраняемогоДенежногоСодержанияГосслужащему,Невыходы,ПриказОбУвольнении,КадровоеПеремещение,КадровоеПеремещениеВоеннослужащего,",Документ.Вид())>0 Тогда //БольничныйЛист,
ИспПравилПерерасчета = ПравилоПерерасчета.Применять(0);
КонецЕсли;

КонецПроцедуры // ПриОтменеПроведенияДокумента

-----------
самое интересное, что данная процедура НИГДЕ не используется... т.е. её просто-напросто забыли... могу предположить, что тот, кто её писал - вскоре уволился, а сменщику было фиолетово...

в результате в каждом модуле вышеперечисленных документов в конце стоит Процедура ОбработкаУдаленияПроведения(), в которой:
[b]ПравилоПерерасчета.Применять(ИспПравилПерерасчета);[/b]
всегда имеет только одно значение Применять(1)

отсюда и лечение, любезно предложенное Леной:

в модуле дока НачислениеЗаработной платы в самом конце вместо:
ПравилоПерерасчета.Применять(ИспПравилПерерасчета);

надо жёстко задать:
ПравилоПерерасчета.Применять(0);

и тогда больше не будут возникать записи-перерасчёта при удалении данного дока...

КАроче... Диагнос в (1) и (2). Вы, господа, программисты, или так, погулять вышли?
7-GSokolov > "потому как глюк платформы" - "глюк" на левом переднем месте, сиденье греет. Удаляешь документ - удаляются движения документа. Все - это объявленное свойство, и оно выполняется. Но шарить по всем регистрам, и искать связи платформа не обучена. Разгильдяйкам простителен каприз, чтоб прога их косяки и сопли заботливо подтирала, но [b]программист[/b]-то обязан знать пределы возможного?!
Можно, конечно, обвинить разработчиков, что не заложили это безобразие в процедуру ПриУдаленииДокумента, но они и не обязаны, вообще-то это делать: это совковое стремление переписать славное прошлое противоречит основам учета...

> они и не обязаны, вообще-то это делать

Ты это заказчику заяви.

16-Секвестр > Сделай сам, чО. Только вот "заказчик", в учете не заинтересованный, замордует тебя своими постоянными косяками.
И в конечном счете, рано или поздно, подведет к логическому тупику.

(17) Понятно, что надо все делать воворемя и правильно. Но по факту описанного в (0) - откуда это берется...? из ачем..? и почему?

> все делать воворемя и правильно

Они всё делали правильно и хорошо, но у них ни черта не получалось....(с) не моё

18-Чучундер > Потому. Что не вовремя, и не правильно. И за базой ухаживать надо. И комп надо [b]правильно[/b] настроить. И количество рученок надо строго лимитировать необходимым (не путая [em]необходимость[/em] с [em]хотением[/em]). И знать, например, ограничения ДБФ...
Судя по тому, как аффтар с Мисты излагает "проблему", следует подумать, а не проще ли сменить прокладку?

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

так все осталось непонятным отчего и почему

(22) дык... написали же - появляются из-за лишнего ИспПравилПерерасчета=1 в процедуре ОбработкаУдаленияПроведения(), а не удаляются - потому что привязаны к прошлопроведённым докам и надо туда лезть мягким откатом и перепроводить...

что непонятно?

(23) прости, барин, холопа неразумного.. ;-)
Просто тебя VZ как-то не поддержал... я вот и сумлеваюсь...

24-Чучундер > Я назвал более общую причину, касающихся не только "отпусков". А когда делаем [b]правильно[/b] (не забывя про доки перерасчета, и двигаясь строго против временного вектора), то и правила перерасчета не мешают ;)

> (не забывя про доки перерасчета, и двигаясь строго против временного вектора),
- не понял. имеется в виду делаем все правильно и последовательно..?

26-Чучундер > Ну да. Ради чего, собственно, плач? Делают начисление (первый док), затем его правят (второй док) - появляются сторнировочные записи, затем эти проктологи залезают глубоко взад и удаляют первый... А потом клянут 1С, такую-сякую нехорошую...
Если уж выделываешь такие кульбиты, то и двигайся назад по своим следам. Как-то так...

27-VZ > ты может опять не понял про что речь?

[quote=VZ;27940371] затем эти проктологи залезают глубоко взад и удаляют первый... [/quote]Чтобы получить засаду, взад лезть не надо, достаточно удалить исправление и получаем неудалённый перерасчет. С точки зрения [b]правильности[/b] действий пользователя всё логично. Причем, иногда этих записей при проведении исправления может и вовсе не быть, а появляются после пометки на удаление исправления.

ИМХО, Валера просто очень далек от реальной жизни:) у него слишком идеалистические представления об учете зарплаты. типа после начисления уже ничего не должно измениться - и заболеть в отпуске никто права не имеет, и приказ об изменениях условий оплаты не могут принести с опозданием, и правительство никогда не меняет задним числом правила игры... а уж если расчетчица случайно ошиблась и попыталась исправить ошибку [b]типовыми[/b] средствами - за это как минимум расстрелять надо:) поэтому ситуацию, когда вводится переначисление за прошлый период, а потом удаляется, он просто представить не может, когда никаких проктологов, а мусорные перерасчеты полезли...

30-Buhta > Дададада.... Я оторвался от жизни. Несомненно. Лет эдак 12 ("одноэсных" токмо). И никогда не встречался с вытеснением отпуска больничным. И всегда приказы об повышении ставок/окладов были заранее. Аж за квартал. И расчетчицы никогда случайно не ошибались...
Несомненно.
Именно поэтому, и только поэтому я даже не понял, о чем говорил чел по ссылке в (0)...