Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2002.12.19;
Скачать: [xml.tar.bz2];

Вниз

Заработная плата   Найти похожие ветки 

 
Yury   (2002-11-29 09:52) [0]

Всем привет! Народ, может кто писал прогу для подсчета заработной платы для МП. Помогите, кто чем могет, может есть какие-нибудь наработки, примеры :), буду очень благодарен. Заранее, спасибо.


 
ЮЮ   (2002-11-29 10:23) [1]

А заработной платой поделишься? :-)


 
Sergey13   (2002-11-29 10:28) [2]

2Yury (29.11.02 09:52)
ИМХО, в условиях России (xUSSR), каждое МП извращается при начислении зряплаты как хочет. Поэтому и рекомендаций быть не может. Я помню делал один раз, еще на Клиппере, так там был даже справочник штрафов. Уж не знаю какой смайлик ставить 8-) или 8-(. Слава богу я у того хозяина работал не на постоянной основе - вот тут точно 8-). Так что спрашивай конкретнее.


 
Johnmen   (2002-11-29 10:43) [3]

1. Обращение к гл.бух-ру с просьбой описать алгоритм начисления ЗП.
2. Реализовать его в своем приложении...

Универсальных подходов для универсального приложения я не знаю...


 
LordOfSilence   (2002-11-29 11:25) [4]

2 Yury (29.11.02 09:52)
Если Вы задаете подобные вопросы, значит, наверное,
не очень знакомы с этой предметной областью (без обид),
поэтому позволю себе немного высказаться на эту тему.
Зарплату я писал, и не для МП, а для завода (и не только),
поэтому имею некоторое право пытаться давать советы.
Постарайтесь избежать привлечения для решения этой задачи
Delphi. Поймите меня правильно, дело не в том, что Delphi
плоха/хороша, удобна/неудобна, подходит/неподходит.
Выбор лежит совершенно в другой плоскости, не в плоскости
удобства, "классности", "крутизны" и т.п. программирования.
Постарайтесь посмотреть дальше того момента, как в последний
раз нажмете Ctrl-F9. Что будет дальше с этим проектом?
Имею большое подозрение, что у Вас есть все шансы нажить
себе долгоиграющий геморрой в виде сопровождения всего
этого хозяйства. Насколько Вы уверены, что задачу решили
сразу и методологически верно? 999 из 1000, что Вы еще не
раз будете клацать на "Compile". Насколько Ваша разработка
может быть расширяема без перекомпиляции? Насколько она
может быть вообще отчуждаема от первичного программиста,
то есть от Вас? Тут я имею ввиду, как клиент сможет
вносить изменения в схему расчетов при потере связи с Вами,
приеме на работу другого программиста, даже если у них и есть
на руках Ваши исходники.
Возможно, я выражаюсь витиевато и загадочно, но мой Вам совет
таков: постарайтесь не изобретать велосипед в этой области
(это вряд ли принесет Вам удовлетворение), постарайтесь взять
готовое решение какой-либо известной компании, которая
занимается автоматизацией в области финансов, бухучета и т.п., благо на рынке их, пожалуй, хватает, и "прикрутить" его к
Вашей непосредственной задаче. Обычно все серьезные и
конкурентноспособные пакеты в этой области позволяют
расширять свой функционал уже без участия программистов
ядра системы, то есть имеют встроенную возможность
"допрограммирования", настройки, переконфигурирования,
используя при этом некие свои внутренние "макроязыки"
и шаблоны.
Все давно придумано! :))

P.S. Все вышесказанное - немножечко ИМХО, но имеючи
определенный опыт в этой сфере.


 
MsGuns   (2002-11-29 12:01) [5]

На 90% согласен с Лордом
Я писал несколько зарплат, в т.ч. для ПК. Могу сказать одно - каждая из них мне сейчас НЕ нравится. А вообще многое зависит от того, какие цели преследуются этой программой. Если просто типа хранилища для просмотра и печати справок, сводов и т.д., то либо ексел, либо простеннькая БД с тривиальным интерфейсом и тупыми, но универсальными запросами. Если же полноценная функционалка, то это - гиганский труд, особенно в условиях наших законодательств о труде (главным, образом, их чудовищной нестабильности). Да много еще зависит от специфики: для здравоохранения свои прибамбасы, для образования - свои, для МП - свои и т.д. Очень большую роль в таких делах играет ЛИЧНОЕ отношение Главбуха или директора. Если оно доброжелательное, то начинать стОит, если же равнодушное, я бы лично даже не брался. Чисто потому, что бухгалтера (в основном немолодые женщины) без нажима сверху все воспримут в штыки.


 
Yury   (2002-11-29 15:32) [6]

Все, что вы пишете, конечно, верно, но я ведь и не стремлюсь сделать ее универсальной! :)) А писать я ее вздумал, потому что одно МП предложило заработать денег и как они говорят 1С: Бухгалтерия и тому подобное для них слишком круто и дорого, и это логично. Им и нужна специфическая прога, именно под ИХ фирму.
Вот Лорд пишет, что писал и для завода и не только. Я, конечно, ламер, но разве они отличаются в корне??? Принцип ведь тот же. Для заводе намного больше наворотов и т.д.
Меня интересуют общие принципы (какие таблицы, их структура, связи между ними и т.д.) Спасибо!


 
MsGuns   (2002-11-29 16:00) [7]

Общие принципы для задачи "Зарплата" сводятся к тому, что надо считать и хранить данные о начисленных и удержанных суммах почеловечно. А вот дальше все зависит от особенностей и КОНКРЕТНОГО ТЗ. Если прога должна считать и заполнять 8ДР, например, - это одно, если не надо,- это совсем другое. Если нужен табель (учет отработанного времени, ис-ся, например, для расчета больничных), значит БД должна включать соотв.сущности (включая таблицы).

А в общем-то все сводится к тому, чтО должен вводить юзер, а чтО считается самой прогой. В 1С, например (в большинстве релизов), юзеру отдается "под ответственность" от 50 до 100 % используемых сумм, в том числе аппарат формализации. А прога просто все это сбивает и записывает в БД, откуда потом выбирает для разного рода отчетов, справок и сводов. В крупных проектах типа R3, зарплата как таковая почти не вводится, а является произвольной величиной от массы других параметров и факторов (штатное, фондирование, коэффициенты и проч). Даже лицевой счет существенно отличается от реализации к реализации. В простейшем случае он имеет только строки начислений-удержаний и некоторые доп.реквизиты (оклад,стаж,премия,отработано дней и пр), используемые в блоках формализации (конфигурации). В более сложных случая он может состоять из доброго десятка таблиц (перемещения, льготы, доплаты и удержания, инфа о выплатах или погашениях долга, данные ОК и прочая и прочая и прочая). Кроме того может быть еще сетка с графиком работы, сетка замещений, сетка дополнительно оплачиваемого времени и т.д.) Короче для каждого монастыря - свой устав 8))


 
РВА   (2002-11-29 16:03) [8]

Не судите строго, предлагаю:
- Весь расчет в Excel сделать
- Результат в базу на усмотрение (PD,DBF)
Печать всех форм из базы: выдача справок т т.д.
Можно накапливать за все периоды,обощать если надо...
Я так делалаю уже лет пять особых проблем не было



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2002.12.19;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.48 MB
Время: 0.009 c
4-61868
dumb
2002-11-01 12:10
2002.12.19
CoCreateInstance проблема


3-61446
alxx
2002-11-29 15:55
2002.12.19
Как узнать существует ли временная таблица (в MSSQLServer)?


1-61564
Lizerginnn
2002-12-09 18:14
2002.12.19
ChartoOEM?


1-61662
Itap
2002-12-07 18:02
2002.12.19
Объединение файлов


1-61523
dimonf
2002-12-09 10:13
2002.12.19
Передача данных в TreeView!





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский