| 0
- 10.08.2012 - 13:24
|
Всем привет. Обновили в марте базу ЗИК на 322 релиз, после этого ничего не обновляли, все хорошо работало, периоды меняли до июля, вылетов не было. В июле начались проблемы. Проводим документ начисления зарплаты, запускаем расчет, вылетает программа. Делаем лечение исправление, делаем расчет по отдельности по каждому сотруднику, вылетает на ком-то, делаем тестирование исправление опять, опять выдает ошибки такого плана: Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Линкевич Маргарита Николаевна(90104) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Лаптева Елена Александровна(90170) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Кузнецова Ольга Николаевна(89788) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Климович Ирина Александровна(5307) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Климкина Елена Эдуардовна(90000) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Кашмирова Ирина Викторовна(5316) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Истомин Владимир Вячеславович(5202) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Исмаилова Елена Владимировна(89929) Опять тестирование исправление, продолжаем расчет по людям на ком был сбой, расчет проходит, сбой теперь уже на другом ком нибудь. *.DD файлы создавали по новой, подскажите что можно сделать с этим?     | | ||
| 401
- 14.12.2012 - 14:06
|
(399) ты сравни ведомости и отчетность за прошлые периоды, ну и в табличке расчет и в 1sjourn поправь поля (я не делал, ибо лень было) Тут я тебе только у документа ввод расчета по списку родительским документом задал "первый родительский" документ среди всех у этого конкретного документа. | | ||
| 402
- 14.12.2012 - 14:08
|
хотя это и не совсем верно, если открывать старые периоды и перепроводить усё заново - движения становятся "красившее".. видать это и есть правильный путь, ну а ежели тебе с этой базой только дожить до НГ - то тогда сойдет и этот. | | ||
| 403
- 14.12.2012 - 14:27
| А мягкий откат если сделать попробовать и перепровести все прошлые периоды? Как думаете? | | ||
| 404
- 14.12.2012 - 14:34
| Цитата:
Цитата:
| | ||
| 405
- 14.12.2012 - 14:55
|
Пробуй. Можно прибить все записи расчета и по новой перепровести всё открывая периоды.. Мот и есть поделки готовые для этого - поищи, должны валятся на проклабе или ис | | ||
| 406
- 14.12.2012 - 15:15
|
404-volk13 > "не совсем понял" - это я виноват, тут у меня одна заморочка своя вклинилась ;) В общем, имелось ввиду "зачем проверять факт корректного завершения"... Извини за небрежность. | | ||
| 407
- 14.12.2012 - 15:23
| ОК, поковыряюсь вечером. | | ||
| 408
- 14.12.2012 - 15:27
|
406-VZ > ну как-же зачем? Для того, чтобы если всё корректно, то никакой переиндексации не происходило. Для чего весь этот замут со скриптом? Для того, чтобы днём, работая в рабочее время, пользователь в случае некорректного завершения работы 1С, без монопольного режима мог переиндексировать БД и продолжать работу, а также не смог ответить "НЕТ" на вопрос о необходимости переиндексировать таблицы. Ведь переиндексацию нужно обязательно сделать! А нерадивый юзер может ответить "НЕТ". Поэтому мы и исключаем данный вопрос в принципе, не даём 1С его даже задать! Вот этот кусок скрипта: Function Check1SExit(PathToBase) retval = -1 Set oFileTxt = FSO.OpenTextFile(PathToBase & "\1susers.dbf",1) oFileTxt.Skip(98) retval = Int(LTrim(oFileTxt.Read(4))) oFileTxt.Close() Check1SExit = retval End Function 'Проверяем - задаст ли 1С вопрос о переиндексации: if FSO.FileExists(PathToBase & "\" & "1Cv7.LCK") = False Then 'Значит БД свободна. If Check1SExit(PathToBase) > 0 Then 'Значит был аварийный выход и был-бы задан вопрос. Не допустим этого!: MsgBox "Программа была завершена аварийно. Для автоматической переиндексации - нажмите кнопку ""ОК"" и дождитесь окончания процесса!",_ 16+4096, "Внимание!" 'Удаляем индексные файлы: Set FilesMaskCol = ShApp.NameSpace(PathToBase).Items() FilesMaskCol.Filter 192,"*.cdx" If FilesMaskCol.Count > 0 Then FSO.DeleteFile(PathToBase & "\*.cdx") End If 'Запускаем БД в пакетном режиме для переиндексации resp = WShell.Run(Dir1Cexe & " CONFIG /D" & PathToBase & SpecUserPass & " /@" & DirScript & "reindex.prm",3,true) MsgBox "Переиндексация окончена, можете продолжать работу.",_ 48+4096, "Готово!" End If End If 'Запускаем БД в обычном (разделённом) режиме: res = WShell.Run(Dir1Cexe & " enterprise /D" & PathToBase & UserPass,1,true) А ты как предлагаешь? Напиши свой кусок, тогда пойму о чём речь. | | ||
| 409
- 14.12.2012 - 15:34
|
+408 в ночное время конечно всего этого не надо, там просто запускается скрипт с удалением индексных файлов и последующей переиндексацией через пакетный режим. А мы говорим о ситуации, когда переиндексация требуется в рабочее время, если у юзера нет прав на монопольный режим и чтобы юзер не смог отказаться от переиндексации, дабы не продолжать работу с необновлёнными после сбоя индексами. | | ||
| 410
- 14.12.2012 - 15:42
|
408-volk13 > :) "Для того, чтобы если всё корректно, то никакой переиндексации не происходило" - а если произойдет? То что? Что случиться-то? Лишняя электроэнергия потратиться? Ну да, ну да :D Я полагаю, время написания твоего замечательного скрипта дороже сэкономленной электроэнергии :D В общем, переиндексация (а точнее - индексация, поскольку .cdx снесены) вреда не принесут. Затраты времени будут теми же, ибо время на возможную индексацию ты зарезервировал в расписании заранее. Надежность выше, ибо проще ;) Вот потому сам отказался от лишних мудорств - и после удаления .cdx сразу следует вызов 1С в пакетном режиме. Без затей. | | ||
| 411
- 14.12.2012 - 16:04
| Цитата:
Короче я тебя понял, что ты меня не понял. :) Этот замечательный скрипт нужен только для того, чтобы пользователь не смог ответить "НЕТ" на вопрос о переиндексации, так как этого вопроса впринципе не последует! И чтобы переиндексация запускалась при попытке входа в базу только в случае некорректного завершения 1С, а не при каждом запуске программы. Это НЕ НОЧНОЙ скрипт для сервера! А скрипт, через который юзеры запускают свои базы. Ну ладно, будем считать разобрались.. :) | | ||
| 412
- 14.12.2012 - 17:12
|
411-volk13 > "Это НЕ НОЧНОЙ скрипт для сервера!" - а какая разница? Что его ось запускает по расписанию, что юзер по команде - результат-то один. И когда его юзер запускает? Может, когда лапки зачесались? Или когда его база не пускает, требует переиндексации? Ну так зачем же проверять счетчики заходов/выходов? Заведомо будет переиндексация. | | ||
| 413
- 14.12.2012 - 17:22
| Цитата:
В статье написано: 1. Упрощённая строка подключения к БД 1С в режиме бесшовного терминала из линукса будет выглядеть так: rdesktop -A -s "c:\seamlessrdp\seamlessrdpshell.exe ""c:\scripts\start1c\start1c.bat D:\Basi1C\BasaN user1c pass1c""" -u usertest -p usertest 192.168.XX.XX где start1c.bat - сам батник D:\Basi1C\BasaN - 1-й параметр батника (путь к БД) user1c - 2-й параметр батника (юзер 1С) pass1C - 3-й параметр батника (пароль юзера 1С) 2. Содержимое start1c.bat : @echo off start C:\SCRIPTS\start1c\start1c.vbs %1 %2 %3 Тут всё просто - запускаем start1c.vbs с теми-же параметрами, что передали батнику, а батник завершает свою работу, сделав своё дело - запустив скрипт и передав ему параметры (путь к БД, имя юзера1С и пароль) ну а кусок кода из start1c.vbs мы сейчас и рассматриваем... :) т.е. если это даже не линукс, то в свойствах виндузового ярлыка запуска конктреной БД пропиши c:\scripts\start1c\start1c.bat D:\Basi1C\BasaN user1c pass1c и тогда всё будет происходить именно так, как я описал выше. Автоматически! Без всяких лишних заморочек для юзера. Единственное, что нужно сделать для этого - запускать БД 1С через волшебный батник+скрипт. Ну прочти внимательно ссылку на статью-то! :) | | ||
| 414
- 14.12.2012 - 17:44
|
+413 весь смысл этой затеи - ещё раз повторюсь: не дать ни малейшей возможности юзеру отказаться от переиндексации базы, в случае некорректного завершения работы и потребности в переиндексации. Чтобы не было случаев, как у ТопикСтартера!!! :) | | ||
| 415
- 14.12.2012 - 18:18
|
414-volk13 > Понял. Была такая мысль, я ее грубо затоптал и зарыл. Во-первых, теряется возможность пользования Стартером, который довольно-таки удобен. Во-вторых, Рабочий стол украшается многими значками, что ранит мою нежную душу. В третьих, как показал опыт, достаточно еженощной переиндексации, что бы не происходили безобразия, описанные в сабже ;) И наконец, вынудить юзера запустить переиндексацию оказалось совсем-совсем просто: для этого было достаточно запретить ему вход в монопольном режиме. И все :) | | ||
| 416
- 14.12.2012 - 18:20
| Вопрос такой, делаю я откат, достаточно ли перепровести "Начисление зарплаты" в каждом периоде, или ВСЕ документы нужно перепровести? | | ||
| 417
- 14.12.2012 - 18:25
| Не нашел обработок, которые бы только в открытом периоде делали перепроведение. А стандартная обработка не совсем подходит, бывает дата документа не входит в расчетный период... | | ||
| 418
- 14.12.2012 - 18:42
|
417-Fold > Вообще-то в ЗиКе надо обычно перепроводить не все документы. Многие просто расставляют ВР по вложенному списку сотрудников, и если ничего не изменять в данных, то будет тупое повторение списка ВР. Так что надо что-то делать интерактивно. А это вовсе не "обработка перепроведения". Кроме того, очень рекомендуется стиль, при котором каждому документу периода присваивается дата, входящий в этот период. Это нетрудно, если привыкнешь к порядку, но очень облегчает поиск документов в журнале. Способствует пониманию этого интенсивная работа ручками ;) И, наконец, можно переделать немножко стандартную обработку, заставив вводить период не "по бухгалтерски", а "по ЗиКовски": периодом. Надо только составление списка документов переделать с выборке по дате на выборку из записей ЖР указанного периода. | | ||
| 419
- 14.12.2012 - 18:52
| В понедельник посажу расчетчицу с кадровиками, буду открывать им периоды, пусть перепроводят все документы. | | ||
| 420
- 14.12.2012 - 19:01
|
415-VZ > Валер, я тебя тоже понял и услышал, спасибо за приятный и не побоюсь этого слова - профессиональный разговор! Так держать на Т1С!!! Всегда с уважением ко всем - Ваш Неизменный, но многоликий volk13 :) | | ||
| 421
- 14.12.2012 - 22:59
| 420-volk13 > А твой скриптик я таки сохранил в коллекцию ;) | | ||
| 422
- 15.12.2012 - 01:45
| я знад, я верил что Епрст - мегамозг!!! | | ||
| 423
- 15.12.2012 - 01:48
| Как при сидящих в базе юзверях, определить, нужна ли переиндексация...? - запускать типа такого же скрипта и проверять если бы кто-то стартанул, то был бы вопрос - значит переиндексация нужна...? ведь на самом деле имеет может быть простой вариант - юзверь отвалился по какой-то причине, но индексы - нормальные.. как определить когда действительно нужн апереиндексация? | | ||
| 424
- 15.12.2012 - 11:08
| Попробовал сегодня откатиться на январь 2010 года, вылетает опять база, вопрос как корректно прибить все записи в ЖР? Есть способ кроме как отмена проведения всех документов в каждом расчетном периоде? | | ||
| 425
- 15.12.2012 - 11:12
| Если в 447.dbf просто удалить все записи нормально будет? | | ||
| 426
- 15.12.2012 - 11:21
| Пометил на удаление в дбфе, вроде ТИИ молчит, не ругается. | | ||
| 427
- 15.12.2012 - 11:36
| Ручные исправления улетают если его убивать полностью. | | ||
| 428
- 15.12.2012 - 12:54
| наступил пятый день ... дурдома | | ||
| 429
- 15.12.2012 - 13:56
|
И кстати по поводу родительского документа, походу дела это нормально, что 2010 год показывает, там период действия без даты окончания стоит. Вот, поглядите запрос к ЖР и скрин документа. | | ||
| 430
- 15.12.2012 - 14:04
| Родительский документ это получается документ который произвел запись в текущем периоде в ЖР, а IDDOC это ссылка на первичный документ, на основании которого в текущем периоде вводится эта запись. | | ||
| 431
- 15.12.2012 - 14:23
|
425-Fold > Если прибить CJ447.DBF, всё нормально, может быть только упаковать базу, чтобы убрать лишние записи. При накопившихся косяках, после удаления CJ447.DBF, снять с проведения все документы и прогнать по всем периодам снова, после чего восстановить ручные правки сравнением баз, если таковое будет возможно, либо прописать то, что должно дать нужный результат и без ручных правок. p.s. Для Fold, если понадобится: Обновил ссылку по процедурам - добавил РасчетЗарплаты.ert с кнопкой "РасчВсе" делает РасчетЗарплатыПоВсемРежимамСразу: http://hdd.tomsk.ru/file/wlifokvp В процедурках удобно задействовать: СПИСОКВФАЙЛИИЗФАЙЛА.ERT - сохраняет список проведённых документов в файл, затем список из файла загрузить и по периодам проводить. - Использую в случаях, когда приходится с мягким откатом делать правки, требующие полного перепроведения по периодам. Если на периоде проведения документ вида "Начисление отпуска" не проводится, значит, документ требует сделать вручную Расчет, после чего проведётся. После проведения задействую у себя РасчетЗарплатыПоВсемРежимамСразу, чтобы не утомляться переключением закладок и установкой флажков - это стандартная процедура РасчетЗарплаты, к которой рядом с кнопкой "Рассчитать" добавил кнопку "РасчВсе" с процедурой прогона по всем режимам. Затем выставляю следующий период мягким откатом и так далее. Если есть документы Накопленная задолженность, их можно прогнать (перезаполнить и провести) потом, последовательно выбирая периоды мягким откатом. Однако, заметил, в декабре 2009г у вас есть начисление больничного, без Начисление заработной платы и отсутствует документ Ввод начального сальдо по расчетам с сотрудниками, что как-то противоречит имеющимся движениям. Ну и ещё идёт ругань на незаполненные календари в 2009г и в начале 2010г. Если начало 2010г как-то правильно оформить, то сам прогон по всем периодам не займёт много времени - сотрудников у вас не так уж и много. Удобно просматривать расчетную ведомость за произвольный период процедурой с инфостарта РАСЧЕТНАЯ_ВЕДОМОСТЬ_ЗА_ПЕРИОД.ERT. Для выгрузки проводок в бухгалтерию, использую процедуру ВыгрузкаПроводок.ert, - стандартная процедура, к которой приделал кнопку "ВыгрузитьПоПериоду", а в шапке - проставил выбор периода. В поле выбора файла выгрузки достаточно оставить путь типа E:\...\НашаБаза\КаталогПользователя\CDData.xml, при выгрузке будут формироваться файлы вида: CDData_201101_.xml, CDData_201102_.xml,... В базе бухгалтерии задействуем процедуру ЗагрузкаДанных.ert, дописанную для загрузки по периоду. Выбираем в каталоге выгрузки любой файл, выставляем период загрузки, загрузятся только файлы, соответствующие выбранному периоду. Прогнать базу за почти 3 года - не позавидуешь, но зато будет уверенность, что более не слетит. Хотя..., всё может быть... и каждый отработанный период лучше сохранять в архив, прежде, чем двигаться дальше. :-) | | ||
| 432
- 15.12.2012 - 16:32
|
Если я делаю мягкий откат с прибитием 447.dbf то все ручные записи улетают, а их там куча в каждом месяце, и получается нужно по новой расчитывать зарплату с 2010 года, за исключением ввода самих документов. И судя по 429 посту не совсем очевидно что проблема в IDDOC и в родительском документе. 431-perpetum > За обработки спасибо. Прогонять по новой 3 года это конечно жесть, вряд ли это выход. | | ||
| 433
- 15.12.2012 - 21:26
|
(432) если до сих пор вы маетесь дурью и не смогли точно локализовать (и тем более определить и устранить) причину сбоя - то приняв решение на пересчет, я бы для полной гарантии перенесла все документы в изначально чистую базу (перенеся документы и ручные исправления) и потом бы считала уже в ней.По крайней мере скрытых невыявленных нарушений целостности не будет. Обработки для переноса именно баз ЗП в инете валяются готовые | | ||
| 434
- 15.12.2012 - 21:58
| они сами не знают, чего хочут | | ||
| 435
- 16.12.2012 - 00:25
| ну так яне понял - всё уже? или где? | | ||
| 436
- 16.12.2012 - 00:59
| Мать вашу, база уже 435 постов сдохнуть не может! Нажмите уже Shift+Del... | | ||
| 437
- 16.12.2012 - 05:42
|
не надо они если захочут базу пристрелить, попадут опять в коленку и будет ещё хуже | | ||
| 438
- 16.12.2012 - 05:43
| некромонгеры | | ||
| 439
- 16.12.2012 - 10:56
|
435-Чучундер > В рабочем периоде ноябрь 2012г пробовал сотрудников фильтровать по группам, последовательно заполнял и проводил новый документ "Начисление зарплаты", затем смотрел "Проверка логической целостности" в "Тестирование и исправление информационной базы". Оттестированное, без замечаний, сохранял в очередной архив. На группе "Прочие физлица" произошло оно самое - каша внутренних идентификаторов. Надо смотреть теперь группу "прочих" - их там 198 - почему и что там у них не так...? - Если проблема в каком-то одном сотруднике, то примерно за 7 итераций можно будет его найти и затем смотреть, почему? | | ||
| 440
- 17.12.2012 - 10:00
| http://infostart.ru/public/14760/ вот эту поделку еще погляди | |
