Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нужна свежая мысль. / 8 сообщений из 8, страница 1 из 1
28.10.2004, 07:55
    #32758255
Oleg K
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
Пишу зряплату на предприятие. Своя специфика. Это так, к слову.

Короче имею таблицу с работниками (ф.и.о, таб. № и т.п.)
Имею справочник видо начислений/удержаний ( далее н/у ).
Так вот. Требуют:

Чтобы на каждый вид н/у (например, аванс) выводился список работников с суммой в виде таблице в которой можно напрямую вносить ИЗМЕНЕНИЯ.
Сделал представление и связал Сотрудников с таблицей н/у.
Для просмотра - проблем нет. А для правки? Ведь при наличии 3000 человек, в таблице н/у строк нет (вначале месяца), а загонять их туда на 200 видов н/у - не очень то...
Решил загонять из представления данные во временную таблицу и править в ней. Но вот вопрос следущий. А как сохранять? Ведь могут несколько человек вызвать все предприятие и испарвить по одному значению. При записи данные друг-друга "перезатруться".
Решил делать битовое поле - признак редактирования. И апдейтить постоянную таблицу только такими строками (одного сотрудника с одним видом н/у не могут одновременно править более 1 пользователя - железяка).

Так вот вопрос: лучший ли это вариант или есть более УМНЫЕ подходы?
...
Рейтинг: 0 / 0
28.10.2004, 08:53
    #32758289
iSestrin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
>Ведь при наличии 3000 человек, в таблице н/у строк нет (вначале месяца), а загонять их туда на 200 видов н/у - не очень то...<
>Решил делать битовое поле - признак редактирования. <

а во временную "очень"? в чем смысл дополнительных преседаний со времянкой? - меня бы такое количество данных ни разу не смутило, бахнул неиспользованные виды н/у при закрытии месяца и все, табличка почистилась...

или так: загоняем все н/у, или лучше по шаблону ... т.е. изучив специфику разных категорий работкников, создать для этих категорий шаблоны используемых видов н/у и их загонять. возможно еще другое: один раз пробить лапами, а на следующий месяц брать из предыдущего. вобщем необходим анализ для выбора решения...

>И апдейтить постоянную таблицу только такими строками (одного сотрудника с одним видом н/у не могут одновременно править более 1 пользователя - железяка).<
просто поместить timestamp в табличку и предупреждать юзера, что во время редактирования кто-то поменял данные... стандартный подход, остальное разруливается правами доступа
...
Рейтинг: 0 / 0
28.10.2004, 11:49
    #32758731
VadimS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
Вопрос: У вас клиент-серверное приложение или файл-серверное?
Может ли один бухгалтер сразу редактировать все предприятие из 3000 чел., и на клиента перегоняется все орава записей? Или он в один момент времени работает с одним подразделением (10-200 чел.)?
...
Рейтинг: 0 / 0
28.10.2004, 13:08
    #32759001
ASCRUS
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
Oleg KПишу зряплату на предприятие. Своя специфика. Это так, к слову.
Эх, зря Вы ее пишете - могу точно сказать. Слишком большой проект. У нас только в тестовой эксплуатации находиться, в следующем году будем выпускать на рынок. Может быть легче готовую купить и подогнать под специфику ?

Oleg KКороче имею таблицу с работниками (ф.и.о, таб. № и т.п.)
Сразу по постановке - сотрудник может быть один, а работать по совместительству, т.е. иметь по каждому табельному номеру (пусть они и одинаковые) свои ставки, график работ, отдел и свои соотвествующе начисления. Так что как минимум 2 таблицы - Сотрудники и ТабельныеНомера, причем стоит помнить о внешних совместителях.

Oleg KИмею справочник видо начислений/удержаний ( далее н/у ).
Так вот. Требуют:
Чтобы на каждый вид н/у (например, аванс) выводился список работников с суммой в виде таблице в которой можно напрямую вносить ИЗМЕНЕНИЯ.
Сделал представление и связал Сотрудников с таблицей н/у.
Для просмотра - проблем нет. А для правки? Ведь при наличии 3000 человек, в таблице н/у строк нет (вначале месяца), а загонять их туда на 200 видов н/у - не очень то...
В зп есть понятие расчетного месяца. Когда он закрывается, данные в нем править нельзя - это запрещено законодательством. На их основе рассчитываются налог на физических лиц и ЕСН, оформляются переводы и выдача денег через кассу, печатается куча отчетов, которая передается в налоговую и пенсионный фонд. Так что если они Вам наменяют за прошлый месяц, то та же НДФЛ и отчеты по ЕСН просто в конце года не сойдутся, чему страшно обрадуется налоговая инспекция и пенсионный фонд. Кстати уж говоря если они ручками все заносить хотят, то это не расчет зп получается, а просто калькулятор, где юзер посчитал, внес, а программа распечатала отчетные формы. В качестве действенного калькулятора могу посоветовать 1С Зарплата. Если хочется, чтобы действительно считала сама, то из отработанных и проверенных временем зарплата Паруса. В следующем году у нас если все будет хорошо на рынок выйдет продукт, который будет позволять расширять систему пользователям, 100% все считать сам, поддерживать экспорт в бухгалтерское ПО, довольно дешево стоить и главное - не требовать от нас сопровождения, работая по принципу отслеживание законодательства - наши проблемы, расширение и настройка системы - дело диллеров, АСУ предприятий или даже просто продвинутых пользователей. Непродвинутые и так смогут работать, просто тут зависит насколько у них хватит ума через визарды добавить новую надбавку, начисление или удержание и понаставлять галочки в конфигурации :)

Oleg KРешил загонять из представления данные во временную таблицу и править в ней. Но вот вопрос следущий. А как сохранять? Ведь могут несколько человек вызвать все предприятие и испарвить по одному значению. При записи данные друг-друга "перезатруться".
Решил делать битовое поле - признак редактирования. И апдейтить постоянную таблицу только такими строками (одного сотрудника с одним видом н/у не могут одновременно править более 1 пользователя - железяка).

Тут все зависит от клиентской части. Самый простой способ - возвращать на клиента такую табличку в виде Сотрудники LEFT JOIN ЗначениеНачисления, то есть будет полный список сотрудников на указанное начисление и только те начисления, которые проставлены. Для обновления такого набора данных можно написать хранимую процедуру, которой передаются параметры, а она в зависимости от ситуации добавляет, изменяет или удаляет сумму начисления на указанного сотрудника. Плюс стоит помнить, что расчетчики зп не могут одновременно менять одних и тех же людей (обосновывающие то документы в одном экземпляре все же)- у каждого есть свой круг отделов, на который он рассчитывает зарплату, значит можно сделать и разделение - каждому расчетчику показывать для редактирование только его круг сотрудников).

Oleg KТак вот вопрос: лучший ли это вариант или есть более УМНЫЕ подходы?
Мне кажется самое умное - купить готовое и подстроить для себя. Если уж сильно хочется калькулятор написать - то стоит помнить что обьем задачи гигантский, что с отчетами в зп легче рехнуться, что необходимо данные выгружать в бухгалтерию и пенсионный фонд и многое многое чего еще, даже если и не реализовывать сами непосредственно расчеты. Ну а насчет самой реализации - необходимо знать Вашу СУБД и клиентское приложение, для каждого инструмента наиболее удачная реализация будет своя.
...
Рейтинг: 0 / 0
28.10.2004, 13:19
    #32759053
Andrey
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
Для просмотра - проблем нет. А для правки? Ведь при наличии 3000 человек, в таблице н/у строк нет (вначале месяца), а загонять их туда на 200 видов н/у - не очень то...
На мой взгляд это вопрос написания запроса, а не структуры БД. Для получения такого представления совершенно не обязательно заносить в таблицу н/у записи по всем видам и для каждого сотрудника.

Но вот вопрос следущий. А как сохранять? Ведь могут несколько человек вызвать все предприятие и испарвить по одному значению. При записи данные друг-друга "перезатруться".
Как вариант: перед сохранением данного конкретного заначения проверять на предмет изменения (при выборке хранить старое сзначение для этого поля). И сообщать пользователю (цветом, звуком, подсказкой) что данные записи были изменены другим пользователем. В противном случае (с флагами), можно получить кучу проблем от недовольных пользователей.

Andrey
...
Рейтинг: 0 / 0
29.10.2004, 01:43
    #32760270
Oleg K
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
4 iSestrin - принято к исполнению.

4 VadimS - У меня клиент - сервер (MS SQL 2000). Пользователи ХОТЯТ возможность получения списка ВСЕГО или ЧАСТИ предприятия - как угодно.
Они могут вызвать 3000 человек в грид для занесения значения 1 человеку. Править хотят только в гриде (60% случаев) - поэтому и вопрос такой. Если бы вызывать бланк на каждого человека - тогда проблем нет, но это не удобно для них. Им нужна скорость и простота.

4 ascrus - пишу, потому как платят... :)) У нас уже 10 лет ДОС-овская программа работает и все нормально...

4 Andrey -
Код: plaintext
Для получения такого представления совершенно не обязательно заносить в таблицу н/у записи по всем видам и для каждого сотрудника.
- пример можно ? Я то думал представление из Сотрудники LEFT JOIN Начисления - не даст права редактировать те записи, где нет строк в таблице Начисления...
...
Рейтинг: 0 / 0
29.10.2004, 12:43
    #32760858
Andrey
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
Oleg K4 Andrey -
Код: plaintext
Для получения такого представления совершенно не обязательно заносить в таблицу н/у записи по всем видам и для каждого сотрудника.
- пример можно ? Я то думал представление из Сотрудники LEFT JOIN Начисления - не даст права редактировать те записи, где нет строк в таблице Начисления...

Все зависит на чем клиент пишется. Писать в БД можно, не обязательно непосредственно редактируя грид .... но к примеру используя дополнительные запросы.
...
Рейтинг: 0 / 0
29.10.2004, 17:15
    #32761536
PL99
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Нужна свежая мысль.
AndreyПисать в БД можно, не обязательно непосредственно редактируя грид .... но к примеру используя дополнительные запросы. IMHO, писать в БД можно независимо от того, на чем пишется клиент, если есть соответствующие права доступа и драйверы
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нужна свежая мысль. / 8 сообщений из 8, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]