не ликвидируются подразделения

Программирование на Атлантисе (VIP, FCOM, ARD), FastReport

Модераторы: m0p3e, edward_K, Модераторы

Chak
Посетитель
Сообщения: 41
Зарегистрирован: 30 ноя 2005, 10:54
Откуда: Пермь
Контактная информация:

не ликвидируются подразделения

Сообщение Chak »

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

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

Сообщение Goblin »

А кроме основного/совместительского назначения у него не было замещения должности в этом подразделении когда нибудь ?
Была одна логическая недоработка в 5.85.02 , не в курсе , исправили ли ее ... Дело в том, что третья вкладка назначений/перемещений ,"Заместительства", не имеет поля даты ухода с данного назначения(DISMISSDATE) и оно пустое в базе , а система , невзирая на тип назначения (поле LPrizn), видя привязанное и незакрытое назначение к данному подразделению, отказывается его ликвидировать. Исправил конфигуратором, выведя в этой вкладке это поле, которое заполняли руками. Если у Вас по данному человеку есть такие записи - просто забейте эту дату.
Питаю патологические отвращение и ненависть в особо тяжелой и крайне запущенной формах к семейству программ Microsoft Business Solution !
Восславим господа Кришну за то, что у нас есть ГАЛАКТИКА !
Chak
Посетитель
Сообщения: 41
Зарегистрирован: 30 ноя 2005, 10:54
Откуда: Пермь
Контактная информация:

Сообщение Chak »

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

Сообщение Goblin »

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

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

В любом случае Appointments по данному подразделению надо посмотреть все с пустым DismissDate
Питаю патологические отвращение и ненависть в особо тяжелой и крайне запущенной формах к семейству программ Microsoft Business Solution !
Восславим господа Кришну за то, что у нас есть ГАЛАКТИКА !
Chak
Посетитель
Сообщения: 41
Зарегистрирован: 30 ноя 2005, 10:54
Откуда: Пермь
Контактная информация:

Сообщение Chak »

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

Сообщение Chak »

У, ё, как я стормозил... вот что значит "легких путей не ищем"... все банально просто - дата ликвидации подразделения оказалась меньше даты увольнения сотрудника...
Прошу прощения за беспокойство.
ZIV
Постоянный гость
Сообщения: 76
Зарегистрирован: 09 апр 2007, 11:11
Откуда: Ishim
Контактная информация:

Сообщение ZIV »

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

Сообщение varvara »

У меня так ругалась, когда в APPOINTMENTS были записи со ссылкой на ШР но с нулевым APPOINTMENTS.PERSON.
ZIV
Постоянный гость
Сообщения: 76
Зарегистрирован: 09 апр 2007, 11:11
Откуда: Ishim
Контактная информация:

Сообщение ZIV »

varvara
А по конкретнее где все это искать и что нужно исправить, как решили проблему?
varvara
Постоянный обитатель
Сообщения: 130
Зарегистрирован: 21 дек 2005, 19:12

Сообщение varvara »

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

Если в вашей базе есть такие записи, то это фактически отвязанные
от конкретного работника назначения.Я их просто удалила.
Как они появляются еще не выяснила.Может кто-то знает?
ZIV
Постоянный гость
Сообщения: 76
Зарегистрирован: 09 апр 2007, 11:11
Откуда: Ishim
Контактная информация:

Сообщение ZIV »

Т.е получается я удалю назначения, а не работника?
varvara
Постоянный обитатель
Сообщения: 130
Зарегистрирован: 21 дек 2005, 19:12

Сообщение varvara »

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

select * from titledoc where((0==wstatus));
ZIV
Постоянный гость
Сообщения: 76
Зарегистрирован: 09 апр 2007, 11:11
Откуда: Ishim
Контактная информация:

Сообщение ZIV »

Спасибо! Приказ утвердил путем запроса поиска отвязанных назначений от работника как Вы указывали раньше. Удалил эти записи и все. Вопрос: а как это удаление записей может сказаться далее на БД?
varvara
Постоянный обитатель
Сообщения: 130
Зарегистрирован: 21 дек 2005, 19:12

Сообщение varvara »

ZIV писал(а): Приказ утвердил путем запроса поиска отвязанных назначений от работника как Вы указывали раньше.
Не поняла, у вас был только один неутвержденный приказ?
Вы запрос сделали на поиск неутвержденных приказов? Если и после утверждения или удаления таких приказов еще остаются отвязанные
назначения значит существует еще какая-то причина .
Как повлияет удаление этих записей? Думаю, что не должно быть серьезных последствий, хотя кто ее знает... А что еще остается делать? Подразделение то нужно закрывать. Надо докапываться до причины возникновения таких назначений. В нашей базе причина - в неутвержденных приказах.
ZIV
Постоянный гость
Сообщения: 76
Зарегистрирован: 09 апр 2007, 11:11
Откуда: Ishim
Контактная информация:

Сообщение ZIV »

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