Галактика в вопросах и ответах

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

Возникла проблема - не утверждался приказ на ликвидацию подразделений, ругался на наличие сотрудников в них. Причину вроде нашел - для некоторых ставок в таблице appointments были записи, которые с одной стороны полем appointments.staffstr ссылались на ставку, но с другой стороны полем appointments.person ссылались на несуществующие в persons записи. Удаление таких кривых записей помогало, пока не нашлось подразделение, для которого с этой точки зрения все в порядке. Тем не менее Галка ругается на одну ставку и даже называет конкретного человека, который на ней типа сидит. Интерфейс "Штатное расписание" показывает, что эта ставка свободна и даже закрыта. Этот сотрудник давно уволен, в его назначении на эту ставку проставлена дата ухода и оно не является текущим (и поле persons.APPOINTCUR у этого сотрудника нулевое). В таблице vacancy для этой ставки нет записей. Куда еще копать? Как Галка проверяет, свободна ли ставка? Точнее, все ли ставки в подразделении свободны.

А кроме основного/совместительского назначения у него не было замещения должности в этом подразделении когда нибудь ?
Была одна логическая недоработка в 5.85.02 , не в курсе , исправили ли ее ... Дело в том, что третья вкладка назначений/перемещений ,"Заместительства", не имеет поля даты ухода с данного назначения(DISMISSDATE) и оно пустое в базе , а система , невзирая на тип назначения (поле LPrizn), видя привязанное и незакрытое назначение к данному подразделению, отказывается его ликвидировать. Исправил конфигуратором, выведя в этой вкладке это поле, которое заполняли руками. Если у Вас по данному человеку есть такие записи - просто забейте эту дату.

Других назначений у него нет, но на вкладке "Внутр. совммест-ва, совмещения" у него абсолютно пустое назначение помечено как "ОСНОВНОЕ НАЗНАЧЕНИЕ". И как снять эту пометку? Средствами Галки не нашел как (по кнопке "Вид назн." его только можно "Определить как основное"). В таблице appointments по этому сотруднику только одна запись (правильная, с его нормальным основным назначением и датой ухода), поле persons.APPOINTCUR нулевое...

Пустое - это скорее всего сформированная на пустом наборе данных на Browse фантомная запись в буфере (LPrizn основного как раз ноль)

Имел я ввиду не внутреннее совмещения, а следующую вкладку, "ЗАМЕЩЕНИЯ" ...

В любом случае Appointments по данному подразделению надо посмотреть все с пустым DismissDate

А почему эта фантомная запись создается с признаком "ОСНОВНОЕ НАЗНАЧЕНИЕ"? У других сотрудников подобные записи помечены как "ТЕКУЩЕЕ ЗАМЕЩЕНИЕ"... ну да ладно, если дело не в этом, то фиг с ним...
Но по этому подразделению нету назначений с пустой DismissDate. Всего три записи по нему в appointments, и у всех дата заполнена. Блин...

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

Помогите плиз!
Столкунулся с такой же проблемой, Галка не дает ликвидировать подразделение. Просмотрел всех сотрудников по подразделению у всех стоит уволен, дата закрытия подр-я позже чем даты уволенных, ставок нет. Ругается на две должности без указания сотрудников. Нашел эти должности и сотрудников, просмотрел что они уволены, дата увольнения раньше даты закрытия должности, ставок по должностям нет. В ШР так же все просмотрел, сотрудников за этими должностями не закреплено. Дата закрытия этих должностей 26.04.07, а подразделение закрываю 03.05.07. В чем проблема, где копать?

У меня так ругалась, когда в APPOINTMENTS были записи со ссылкой на ШР но с нулевым APPOINTMENTS.PERSON.

varvara
А по конкретнее где все это искать и что нужно исправить, как решили проблему?

Сделате такой запрос
select * from appointments where(appointments.person=0);

Если в вашей базе есть такие записи, то это фактически отвязанные
от конкретного работника назначения.Я их просто удалила.
Как они появляются еще не выяснила.Может кто-то знает?

Т.е получается я удалю назначения, а не работника?

Сейчас выяснила, причиной возникновения таких записей может быть наличие в базе не утвержденных приказов.Если у вас висят такие приказы удалите их сначала их Галактики.

select * from titledoc where((0==wstatus));

Спасибо! Приказ утвердил путем запроса поиска отвязанных назначений от работника как Вы указывали раньше. Удалил эти записи и все. Вопрос: а как это удаление записей может сказаться далее на БД?

ZIV писал(а): Приказ утвердил путем запроса поиска отвязанных назначений от работника как Вы указывали раньше.

Не поняла, у вас был только один неутвержденный приказ?
Вы запрос сделали на поиск неутвержденных приказов? Если и после утверждения или удаления таких приказов еще остаются отвязанные
назначения значит существует еще какая-то причина .
Как повлияет удаление этих записей? Думаю, что не должно быть серьезных последствий, хотя кто ее знает... А что еще остается делать? Подразделение то нужно закрывать. Надо докапываться до причины возникновения таких назначений. В нашей базе причина - в неутвержденных приказах.

Нет, приказы никакие не удалял. Запрос делал на поиск отвязанных назначений к работникам (select * from appointments where(appointments.person=0); после удалил все нулевые и после утвердился приказ на ликвидацию подразделения.