ну и эту, заодно
[url]http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=3061[/url]

440-Ёпрст > Есть такая, январь 10 года вылетает если проведены документы будущих периодов.

441-Ёпрст > С 2010 года не будем восстанавливать, декабрь добить и в новую базу.

Перешли на декабрь, документы начисления все провелись, а расчет вылетает именно на совместителях. Сейчас расчетчица считает по одному человеку всех не совместителей, проверим в совместителях ли дело.

проверь, заполнен ли ОсновнойОбъект в справочнике сотрудники и чем именно.

445-Ёпрст > Заполнен у всех, ссылка идет у совместителей на основной элемент. Вылетает не толкьо на совместителях.

у тя вылет только в одном месте - неверный род.документ у НачислениеиУдержаниеСписком в ЖР..

447-Ёпрст > Ты у всех документов этого вида в IDPARDOC подставил IDDOC?

Вид документа в 1sjourn.dbf в колонке IDJOURNAL прописывается?

галактеко волнуеццо! держите в курсе бтвы!

(448) нет. В последнем варианте, у всех документов вида НачислениеИУдержаниеСписком поставил родительским документом первый встретившийся род. документ (по дате).
Т.е если было в табличке расчетов
Док1 Род1
Док1 Род12
..........
Док1 Род222
Док2 Род2
Док2 Род3
....
Док2 Род444


стало
Док1 Род1
...
Док2 Род2

Понятно, надо обработки писать.

Прашло фсиго 4 месяца, а база усё рушилась и рушилась. Фигля, адынесник за работай.

[quote=стёб;26335284] 15-Fold > Так база ни рухнула? Или рухнула? У нас тута с пацанами татализатар. Я бутылку пива паставил шта ты иё парушишь. [/quote]

Никак пива не дождешься )))))

Ёпрст если починит, то уже ящик коньяка по почасовке заработал ))) умеют жеж люди...

После перехода на новый период и ввода новых документов все повторяется.

Новую БД с НГ не предлагать? Если и она будет падать, то остается один рецепт - новый админ и новый 1С-ник.

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

(455) А чего за вид расчета у тебя такой, "У" ?
:)


И это, если целиком прибить ЖР и всё по-новой.. тоже не проходит ?

наблюдаем с интересом!

[quote=Чучундер;28246356]наблюдаем с интересом! [/quote]
Успеют ли починить базу до конца света?

хочу внести пожертвование
расчётный счёт есть?

458-Ёпрст > У это у. )) Если целиком прибивать ЖР это придется все лопатить с нуля, все ручные исправления убьются, решили что это нафиг не нужно никому. С НГ новая база.

460-bma1 > Да х.. ее починишь не зная причины точной.

2(463) Тогда не чини а заведи новую. неломаную.

если ТС так и не поймет в чем была проблема - грош цена ему как спецу
локализовать можно любую проблему
по крайней мере описать ее так, чтобы любой смог сымитировать и повторить
а тут полтыщи постов и что в итоге?
не стыдно?
тьху

465-Синегурочка > :)) Офигеть.

так в итоге-то что было?

[u]Для желающих поискать проблему...[/u] :-)
Здесь база:
[url]http://hdd.tomsk.ru/file/nfmrahmj[/url]

Действия в базе, приведшие к проблеме нарушения ссылочной целостности внутренних идентификаторов.
- Последовательно заполнялся и проводился докумен "НачислениеЗаработнойПлаты" на дату 30.11.2012г выбором сотрудников из групп - Штатные и т.д.
После каждого проведения делалось тестирование базы на наличие ошибок.
На группе Прочие физ-лица отловил сотрудника с кодом "90197", именем "347 347 347", по которому после проведения документа "НачислениеЗаработнойПлаты", произошло нарушение ссылочной целостности внутренних идентификаторов. При снятии с проведения документа "НачислениеЗаработнойПлаты", содержащего всего одного сотрудника, фиксировалась большая задержка в процессе снятия с проведения, по окончании которой, файл журнала "CJ447.DBF", при упаковке в конфигураторе через "Тестирование и Исправление информационной базы", очистился с 17 МГб до 600 байт.
Ссылка на вид документа с сотрудником, дающим проблему.
[url]http://hdd.tomsk.ru/file/gusyqgms[/url]

Да, для удобства эксперимента, на форму документа повесил реквизит ЗаполнятьПо - чтобы можно было быстро заполнять табличную часть документа нужным количеством физ-лиц.

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

(469) примерно в равных частях - сбой или тонкое вредительство. Вредительство доказать практически невозможно

[img]http://dabroz.scythe.pl/upload/2009/10/ocrblog.jpg[/img]

Что обнаружено: в просмотрщике id выглядит " I9 ", но в таблице есть запись с номером 45 с точно таким же (визуально) id (наименование "112 112 112")
Есть ли это "просто" дубль, или хитро испорченный управляющими символами id - не исследовал.
В любом случае, надо брать свежее значение id, подменять его в справочнике, подменять его в ЖР, подменять его во документах.
В ЖР это сделать просто, для исправления в документах достаточно удалить запись, и при помощи ТиИ найти все документы, где нарушится ссылочная целостность.
Впрочем, для "массового" документа НачисленияУдержанияСсылкой это можно сделать как и для ЖР.
И перепроводить ничего не надо.

+472 Оппа... Соврамжи. Слепые глазоньки не заметили, что в строке 45 id не " I9", а " 19".

А копаться не охота: бардак в ведении:
17.11.2010 - прием на работу.
04.08.2012 - увольнение.
07.08.2012 - прием на работу.
22.09.2012 - прием на работу (Повторно! Без увольнения! [b]Тем же самым документом![/b]! - это как?)
22.09.2012 - увольнение (Внезапно!)
01.10.2012 - перерасчет окладов (О, да, заслужил за мучения...)
Чего уж там в модулях при таком старании спрятать косяки расчетчиц.... Сие не ведомо. Может, самому "исправляльщику".

Вообщем, он был еще внутренним совместителем самого себя.
Бардак и не понимание структуры данных.

У меня кончился попкорн... :(

467-Чучундер > Не понятно в чем до сих пор.

474-VZ > При заключении с сотрудником срочного трудового договора в документе приема на работу ставится дата окончания. Поэтому в истории дважды строка о приеме на работу, это нормально. По перерасчету окладов, видимо заполнили по всем сотрудникам, не думаю что это может создать какую либо проблему, т.к. сотрудник все равно не является штатным и начислений по нему нету. По совместительству я вобще не вижу что этот сотрудник был совместителем.

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

478-Fold > Я же сказал, что нет понимания в конфе... И знаний, отчего приняты те, или иные решения.
Дата окончания в документе приема на работу есть дата окончания договора. Но! Вовсе [b]не означает[/b], что в этот день [b]трудовой[/b] договор расторгается!
Подробности: в Трудовом кодексе.
В конфе эта дата вызывает только предупреждение, что в данном периоде (месяце) заканчивается [b]срочный[/b] договор. Если не будет приказа об увольнении - срочный трудовой договор просто теряет первое слово.
И становится [b]бессрочным[/b].
"вобще не вижу что этот сотрудник был совместителем" - я увидел: после удаления пары 22.09.2012. В подробностях решил больше не копаться: а нафига при таком вольном обращении с конфой, и "правками", по всей видимости, связанных с обычной правовой неграмотностью.
При эксплуатации ЗиКи кто-то должен знать трудовое законодательство.
Расчетчик обычно не знает: это естественно. Кадровик не знает: это привычно. Остается что-то знать одноэснику, иначе - сабж.