| Регистрация Правила Главная форума Поиск |
| 0
- 27.11.2012 - 23:47
|
тестовка здесь: http://www.forum.mista.ru/topic.php?id=641335     | | |
| 1
- 27.11.2012 - 23:56
| Сомневаюсь я... | | |
| 2
- 28.11.2012 - 00:38
| в чем? | | |
| 3
- 28.11.2012 - 01:10
| 2-Чучундер > В месте крепления конечностей... | | |
| 4
- 28.11.2012 - 07:03
| 0-Чучундер > большей частью правда:( мусорные перерасчеты возникают редко, но случаются... (когда пересчитываются/переначисляются "зависимые" периоды в расчетах среднего) тоже как-то писала об этом. и, главное, ничем потом не удаляются... в модуле дока начисления з/п давно поставила ПравилоПерерасчета.Применять(0); в некоторых случаях приходится вырезать эту гадость обработкой. | | |
| 5
- 28.11.2012 - 07:09
| Цитата:
| | |
| 6
- 28.11.2012 - 07:26
|
никак не получу зависшие записи в демо... приведите свою последовательность доков, только чётко - для моделирования | | |
| 7
- 28.11.2012 - 08:59
| Чаще всего такое бывает, когда делают исправление документа в новом периоде в связи с изменением условий начисления (например, неверно ввели какую-то доплату), делается перерасчет зарплаты, а потом оказывается, что делать нужно по-другому или вообще это ошибка. Документы, связанные с этим исправлением, помечаются на удаление, их записи в ЖР исчезают, кроме записей-перерасчетов. Вот с ними засада, потому как глюк платформы, ИМХО. | | |
| 8
- 28.11.2012 - 09:53
|
(7) это да... раз заведенные записи перерасчёта крепятся не к доку, который их ввёл, а к доку первоначальной записи, который и надо перепроводить для удаления перерасчётных записей... а это неудобно, т.к. док основных записей - в прошлом периоде... но меня интересует другой вопрос - а зачем при удалении переначисления за прошлый период вообще вводятся эти записи перерасчёта с круговой красной стрелкой? придётся лезть в модуль... | | |
| 9
- 28.11.2012 - 10:24
| 8-Гена > а (5) не подходит? и вообще, вкладку среднего заполнять надо... | | |
| 10
- 28.11.2012 - 10:27
| (5) подходит... но надо понять смысл методологии лучших программистов всех времён и народов... | | |
| 11
- 28.11.2012 - 10:32
| кажется понял идеологию... хотите послушать сказку? | | |
| 12
- 28.11.2012 - 10:34
| 11-Гена > сказку завсегда рады:) | | |
| 13
- 28.11.2012 - 10:58
|
давным давно... когда деревья были большими... задумались лучшие программисты всех времён и народов над исправлением прошлых периодов... и придумали встроенный в компоненту Расчет оператор ПравилоПерерасчета если вы в конфигураторе зайдёте в виды расчётов, то вверху будет группа Правила Перерасчета... для каждого ВР или объединения ВР видна следующая структура работы данного оператора: При вводе ВР ... Необходимо пересчитать следующий ВР ... 1. только в текущем периоде ЖР (по периоду регистрации) 2. в том же периоде ЖР (по периоду действия) 3. в следующих N периодах (после периода действия) идея хорошая... тогда отпуска и средние, напомню, рассчитывались из 3-х предыдущих месяцев... поэтому можно было настроить перерасчёт следующим образом: при изменении любого ВР прошлого периода (например, оплата по окладу), входящего в базу отпуска или среднего - вводились бы записи перерасчёта отпуска или среднего, найденного на расстоянии трёх месяцев... это грамотно... однако, гладко было на бумаге да забыли про овраги... расчёт отпуска или среднего определялся вкладкой среднего, а там ведь автоматом не изменяются данные... в результате у всех перерасчётов поснимали слева крыжики на "При вводе ВР", предоставив пользователю уточнять самостоятельно вкладку среднего в подчинённом доке по кнопке "Исправление" с новым номером И-** если интересно, то можно продолжить... | | |
| 14
- 28.11.2012 - 11:18
|
у оператора ПравилоПерерасчета есть два положения: Применять(0) и Применять(1) в ГМ описана переменная Перем ИспПравилПерерасчета Экспорт, которая жёстко в Процедура ПриНачалеРаботыСистемы() задана: ИспПравилПерерасчета = ПравилоПерерасчета.Применять(1); исключение дано в интересной процедуре: Процедура ПриОтменеПроведенияДокумента(Документ) ... Если Найти("НачислениеЗаработнойПлаты,НачислениеОтпуска ,НачислениеОтпускаГосслужащим,ПриказНаОплатуПоСред нему,НачислениеСохраняемогоДенежногоСодержанияГосс лужащему,Невыходы,ПриказОбУвольнении,КадровоеПерем ещение,КадровоеПеремещениеВоеннослужащего,",Докуме нт.Вид())>0 Тогда //БольничныйЛист, ИспПравилПерерасчета = ПравилоПерерасчета.Применять(0); КонецЕсли; КонецПроцедуры // ПриОтменеПроведенияДокумента ----------- самое интересное, что данная процедура НИГДЕ не используется... т.е. её просто-напросто забыли... могу предположить, что тот, кто её писал - вскоре уволился, а сменщику было фиолетово... в результате в каждом модуле вышеперечисленных документов в конце стоит Процедура ОбработкаУдаленияПроведения(), в которой: ПравилоПерерасчета.Применять(ИспПравилПерерасчета) ; всегда имеет только одно значение Применять(1) отсюда и лечение, любезно предложенное Леной: в модуле дока НачислениеЗаработной платы в самом конце вместо: ПравилоПерерасчета.Применять(ИспПравилПерерасчета) ; надо жёстко задать: ПравилоПерерасчета.Применять(0); и тогда больше не будут возникать записи-перерасчёта при удалении данного дока... | | |
| 15
- 28.11.2012 - 11:22
|
КАроче... Диагнос в (1) и (2). Вы, господа, программисты, или так, погулять вышли? 7-GSokolov > "потому как глюк платформы" - "глюк" на левом переднем месте, сиденье греет. Удаляешь документ - удаляются движения документа. Все - это объявленное свойство, и оно выполняется. Но шарить по всем регистрам, и искать связи платформа не обучена. Разгильдяйкам простителен каприз, чтоб прога их косяки и сопли заботливо подтирала, но программист-то обязан знать пределы возможного?! Можно, конечно, обвинить разработчиков, что не заложили это безобразие в процедуру ПриУдаленииДокумента, но они и не обязаны, вообще-то это делать: это совковое стремление переписать славное прошлое противоречит основам учета... | | |
| 16
- 28.11.2012 - 11:36
|
> они и не обязаны, вообще-то это делать Ты это заказчику заяви. | | |
| 17
- 28.11.2012 - 12:49
|
16-Секвестр > Сделай сам, чО. Только вот "заказчик", в учете не заинтересованный, замордует тебя своими постоянными косяками. И в конечном счете, рано или поздно, подведет к логическому тупику. | | |
| 18
- 28.11.2012 - 13:51
| (17) Понятно, что надо все делать воворемя и правильно. Но по факту описанного в (0) - откуда это берется...? из ачем..? и почему? | | |
| 19
- 28.11.2012 - 14:07
|
> все делать воворемя и правильно Они всё делали правильно и хорошо, но у них ни черта не получалось....(с) не моё | | |
| 20
- 28.11.2012 - 14:49
|
18-Чучундер > Потому. Что не вовремя, и не правильно. И за базой ухаживать надо. И комп надо правильно настроить. И количество рученок надо строго лимитировать необходимым (не путая необходимость с хотением). И знать, например, ограничения ДБФ... Судя по тому, как аффтар с Мисты излагает "проблему", следует подумать, а не проще ли сменить прокладку? | | |
| 21
- 29.11.2012 - 19:01
|
Был у меня случай несколько лет назад, приключился вот такой "баг" программы, расчетчица не заметила, а заметила ГБ, так как перерасчет вылез именно у нее. Пытался я объяснить что бывает такое, редко, но вылезают эти перерасчеты когда происходит перерасчет перерасчета при неоднократных попытках переначисления зарплаты и пометках на удаления этих документов. Клиент оказался неадекватным, ГБ взбесилась, стала бить по клавиатуре, утверждая какое говно эта программа, что каждое действие надо за ней перепроверять, что и я негодяй не могу ее нормально настроить... Пришлось расстаться с клиентом. Был даже рад, что избавился от неадекватов благодаря этому "багу" ЗиК. Нормальные клиенты обычно с пониманием относились. | | |
| 22
- 29.11.2012 - 19:13
| так все осталось непонятным отчего и почему | | |
| 23
- 29.11.2012 - 20:00
|
(22) дык... написали же - появляются из-за лишнего ИспПравилПерерасчета=1 в процедуре ОбработкаУдаленияПроведения(), а не удаляются - потому что привязаны к прошлопроведённым докам и надо туда лезть мягким откатом и перепроводить... что непонятно? | | |
| 24
- 29.11.2012 - 20:39
|
(23) прости, барин, холопа неразумного.. ;-) Просто тебя VZ как-то не поддержал... я вот и сумлеваюсь... | | |
| 25
- 29.11.2012 - 23:01
| 24-Чучундер > Я назвал более общую причину, касающихся не только "отпусков". А когда делаем правильно (не забывя про доки перерасчета, и двигаясь строго против временного вектора), то и правила перерасчета не мешают ;) | | |
| 26
- 30.11.2012 - 00:58
|
> (не забывя про доки перерасчета, и двигаясь строго против временного вектора), - не понял. имеется в виду делаем все правильно и последовательно..? | | |
| 27
- 30.11.2012 - 02:05
|
26-Чучундер > Ну да. Ради чего, собственно, плач? Делают начисление (первый док), затем его правят (второй док) - появляются сторнировочные записи, затем эти проктологи залезают глубоко взад и удаляют первый... А потом клянут 1С, такую-сякую нехорошую... Если уж выделываешь такие кульбиты, то и двигайся назад по своим следам. Как-то так... | | |
| 28
- 30.11.2012 - 07:02
| 27-VZ > ты может опять не понял про что речь? | | |
| 29
- 30.11.2012 - 08:02
| Цитата:
| | |
| 30
- 30.11.2012 - 08:02
| ИМХО, Валера просто очень далек от реальной жизни:) у него слишком идеалистические представления об учете зарплаты. типа после начисления уже ничего не должно измениться - и заболеть в отпуске никто права не имеет, и приказ об изменениях условий оплаты не могут принести с опозданием, и правительство никогда не меняет задним числом правила игры... а уж если расчетчица случайно ошиблась и попыталась исправить ошибку типовыми средствами - за это как минимум расстрелять надо:) поэтому ситуацию, когда вводится переначисление за прошлый период, а потом удаляется, он просто представить не может, когда никаких проктологов, а мусорные перерасчеты полезли... | | |
| 31
- 30.11.2012 - 10:01
|
30-Buhta > Дададада.... Я оторвался от жизни. Несомненно. Лет эдак 12 ("одноэсных" токмо). И никогда не встречался с вытеснением отпуска больничным. И всегда приказы об повышении ставок/окладов были заранее. Аж за квартал. И расчетчицы никогда случайно не ошибались... Несомненно. Именно поэтому, и только поэтому я даже не понял, о чем говорил чел по ссылке в (0)... | |
Интернет-форум Краснодарского края и Краснодара |
