Вход | Регистрация

  1  2
1С:Предприятие ::

Метки: 

v7: Разработка собственного учета рабочего времени для экспорта в ЗУП

Я
   Emery
 
23.10.17 - 09:10
При всей сложности ЗУПа логично некоторые вещи делать «снаружи», а затем экспортировать туда для дальнейшей обработки. Одним из таких моментов является, по моему мнению, учет рабочего времени сотрудников. Поскольку ничего путного в Интернете ничего найти не удалось, то решил наваять собственный вариант на «рабочей лошадке», то бишь «семерке».

Новая версия «самописки» еще не закончена, но некоторые скрины можно показать с целью контроля правильности выбранной концепции учета.

http://emery-emerald.narod.ru/Pics/Pic1.png – Здесь показан работник, точнее, назначение по его учетной записи (поэтому информация выводится обобщенная), возможность загружать данные, вести независимо учет плановых (далее фактических) рабочих графиков и их печать.

http://emery-emerald.narod.ru/Pics/Pic2.png – Здесь плановый график представлен в виде двух независимых записей, каждой из которых может быть подчинен фактический график (если его нет, то считаем, что фактический совпадает с плановым). В форме элемента видно распределение планового графика (переходящих через полночь смен) по дням месяца. Зеленым цветом выделены остатки переходящих смен.

http://emery-emerald.narod.ru/Pics/Pic3.png – Здесь все то же самое, но по отклонениям. Поля в третьей и четвертой строках, скорее всего, будут удалены.

http://emery-emerald.narod.ru/Pics/Pic4.png – А здесь показан итоговый обобщенный табель сотрудников. Вариантов подобных табелей у меня запланировано множество, в т.ч., подробные с начальными и конечными плановыми и фактическими отметками.

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

Первичный расчетный журнал можно будет экспортировать в текстовый формат, который подхватит 64-битный расчетный бинарный модуль, скомпилированный в MinGW с поддержкой SQLite. Он обработает данные в базе данных, созданной в памяти, и выгрузит вторичный расчетный журнал в текстовый формат, который заберет назад (все на автомате) «семерка». Промежуточный обмен данными может быть осуществлен по DDE-каналу, поскольку 1С77 является DDE-сервером (этот вариант является рабочим в первой версии описываемой программы). Хотя ничто не мешает использовать и COM-соединение.

Кстати, из всего этого следует вывод, что весь учет в заработной плате должен вестись в рабочих часах исключительно! Рабочие дни / смены должны использоваться только для информации. Оклад по дням в ЗУПах это лишь способ переложить ответственность за расчет на плечи пользователей. За такие игры разработчиков надо бить по рукам.

В принципе, если ЗУПовский регистр расчетов и другие используемые регистры окажутся способными воспринять данные из моих расчетных журналов, то их можно будет туда перегонять и регламентные отчеты строить уже в ЗУПе. Но это уже будет актуально для товарной версии «самописки» :) .
 
 
   Genayo
 
101 - 23.10.17 - 21:15
(0) Зачем вообще столько ресурсов тратить на учет рабочего времени? Зачем 8 подвидов оплат выходных и праздничных дней? В чем от этого польза для бизнеса?
   Бертыш
 
102 - 23.10.17 - 21:36
ИМХО. Кроме ЗИК 7.7 и ЗУП 2.5 и ЗУП 3.1 в природе существует Каминовская конфигурация. Камин? Ну это те ребятта которые в своё время зарплату для 7.7 делали на компоненте бухгалтерский учет. Вообще по своему опыту соприкосновения с расчетчиками я пришёл к выводу что сколько расчетчиков столько и мнений. Добавьте ещё письма с толкованиями из налоговой и всяческих фондов. Говорите что Гарянина и Гилёв учат демо учёту? Хрень всё это. Любой учёт вне специфики нашего предприятия демо. Так что кто бы что Вам не показывал для Вас это будет демо, а не то что Вы хотите. Исключение тут пожалуй будет если Вам будут показывать внедренцы на ваших данных. Допилить тот же ЗУП до специфики конкретного предприятия стоит. Проблема в том что допилив нельзя останавливаться из-за изменений мнений расчетчиков, управленцев и законодательства. Говорите расчет зарплаты на 8000 сотрудников? Это копейки. Кроме переводов конкретных предприятий с ЗИК на ЗУП и с Каминовской семёрошной Зарплаты  я так же как то писал свой кусочек зарплаты. Только там требования были со стороны пользователя к юзабилити. У меня графики работы вводились в табличном документе в режиме ввода данных и в рамках одного подразделения пользователь, введя график скажем по одному сотруднику, отключал защиту у табличного документа дабы прокопировать как в екселе значения ячеек между работниками. Потом включалась защита табличного документа и по щелчку на служебной ячейке все расставленные часы втягивались в табличную часть документа. В вашем случае это было бы автоматическое заполнение справочника. Роли не играет. Так же я участвовал во внедрении ЗУП в ФГУп Почта России. Там 13 тымсяч было, только не тринадцать тысяч расчитываемых сотруудников, а тринадцать тысяч рабочих мест. И да. Там был ЗУП взятый за основу.
   Бертыш
 
103 - 23.10.17 - 21:44
Про Почту России по понятным причинам я рассказывать ничего Вам не буду, но по своему опыту успешных мои внедрений скажу - Для минимизации накладных расходов на перенос доработок и перепиливание БД под требования законодательства ставится неизменный и неизменяемый управленческий контур с возможностью учета всяческих параметров типа прибыли и себестоимости и он обменивается с внешним регламентированным контуром. Внешний регламентированный контур безболезнено обновляется. В успешных внедрениях у меня таким образом несколько небольших фирм которые до сих пор работают на приятной управленцам 1С 7.7 Торговля и склад редакции 8.7. Обновления затрагивают только отдельно стоящую Бухгалтерию и то не всегда. Расходы на 1С мизерные и касаются только доработки внешних печатных форм типа счета фактуры
   Бертыш
 
104 - 23.10.17 - 21:46
Нашёл свою старую ветку про табель
Выложил на суд кусок конфигурации Табель
   Бертыш
 
105 - 23.10.17 - 21:47
11 лет прошло
   Бертыш
 
106 - 23.10.17 - 21:48
(101) Если бы у рыбы была шерсть, то у неё были бы блохи, а блохи подразделяются....
   Emery
 
107 - 24.10.17 - 07:03
Разработка собственного учета рабочего времени для экспорта в ЗУП

(101) > Зачем вообще столько ресурсов тратить на учет рабочего времени?

Потому, что здесь еще много ручной работы. Кроме того, много ошибок при отражении сложных случаев. Да и просто показать как НАДО вести учет. Не в смысле, что у меня лучше всех, а что политика «прокрустовых лож» в программировании – ущербная. Если какая-та модель охватывает 95-99% процентов всех случаев, а для вас актуальны оставшиеся 1-5%, то аргументы, что вы должны прогибаться под типовой вариант почему-то плохо воспринимаются.

> Зачем 8 подвидов оплат выходных и праздничных дней?

Отчасти потому, что так хотят бухи. А их хотелки связаны с тем, что у разных подвидов разный ФОТ. Именно поэтому они хотят показать отдельно от основной работы «оплату в праздничный день по графику» и «доплату в праздничный день по графику». Тоже самое «вне графика» влияет на другую статистику.

> В чем от этого польза для бизнеса?

Наверное, собственно бизнесу это ультрафиолетово. Руководство и собственники подобными вещами не интересуются и даже не в курсе, что они существуют. Но кроме них есть еще внешние контролирующие и прочие органы, которым все наши возражения по барабану. Им просто «вынь и положь».
   Филиал-msk
 
108 - 24.10.17 - 07:39
(0) Если слить все воду, то получается, что главный недостаток ЗУПа - то, что он написан не вами и не укладывается в ваше мироздание.
   Филиал-msk
 
109 - 24.10.17 - 07:49
(107) Слово "НАДО" улыбнуло и принесло отличное утренние настроение. Спасибо.
   Dotoshin
 
110 - 24.10.17 - 08:27
(107) >>Отчасти потому, что так хотят бухи.
Половина хотелок бухов от неграмотности. А разный ФОТ скорей всего не у подвидов оплаты, а у видов работ, оплата которых выполняется этими подвидами. Появятся у вас еще какие-то работы с отдельным ФОТ, еще 8 подвидов оплаты наплодите?
Сделайте уже аналитический признак к виду оплаты и не плодите сущности.
 
 Рекламное место пустует
   Emery
 
111 - 24.10.17 - 08:50
(102) > ИМХО. Кроме ЗИК 7.7 и ЗУП 2.5 и ЗУП 3.1 в природе существует Каминовская конфигурация. Камин? Ну это те ребятта которые в своё время зарплату для 7.7 делали на компоненте бухгалтерский учет.

Про Камин я в курсе. Кроме него есть и другие зарплатные конфигурации. Но они все юзают документы-объеты, а я предпочитаю документы строить на справочниках. Опыт показывает эффективность этой идеи.

А на бухгалтерской компоненте «семерки» я видел даже реализацию производственного учета. Просто у народа видимо не хватило ума и знаний приобрести компоненту «оперативный учет». У меня собственно расчет (в первой версии) ведется снаружи, на движке VFP (а во второй будет на SQLite), хотя при большом желании можно организовать и внутри «семерки», если правильно спланировать предварительные вычисления и промежуточный данные (ну это чтобы скорость обработки была приемлемой).

> Вообще по своему опыту соприкосновения с расчетчиками я пришёл к выводу что сколько расчетчиков столько и мнений.

Согласен. У моего друга тоже собственная «зарплата», которую он запилил на акцессе-97. Так вот, даже с ним мы не могли прийти к согласованной концепции учета и расчета заработной платы. То, что нравится ему, не нравится мне и наоборот.

Кстати, фирма 1С когда-то утверждала, что по просторам России бродит не менее 200 тысяч различных вариантов зарплатных конфигураций. Интересно, столько их сейчас?

> Добавьте ещё письма с толкованиями из налоговой и всяческих фондов.

Тут больше зависит от универсальности структуры и настроек программы. Например, вся «математика» 1С основана на кусочно-линейных функциях. Разве, что УПП и ЕРП задействуют еще кусочно-линейную оптимизацию (достижение минимакса на линейных неравенствах) и решение матричных уравнений. И я не уверен, что 1С сильно выйдет за эти пределы. Вряд ли бухи будут использовать когда-либо кубические корни. Хотя если попытаться квартальную налоговую амортизацию (по украинскому законодательству) свести к эквивалентной месячной, то кубические корни как раз и понадобятся. В реальности наши бухи-налоговички тупо делили квартальную сумму на три. Но если применить налоговый метод амортизации к этим месячным суммам, то на квартальную мы, естественно, не выйдем.

>  Говорите что Гарянина и Гилёв учат демо учёту? Хрень всё это. Любой учёт вне специфики нашего предприятия демо. Так что кто бы что Вам не показывал для Вас это будет демо, а не то что Вы хотите.

Демо-учет, который демонстрировался, опирался на произвольные данные. Народ просто стучал вслепую по цифровой клавиатуре и вводил абы что. Т.е., все было лоскутно, вне общей логики. Подобная фигня встречается даже в литературе. Так в одной из книг, описывающей общий сквозной пример по бухучету, непрерывность логики и данных не соблюдалась. Закон сохранения был придуман явно не для  них. А репутация у бухгалтеров была: «докапываются до каждой копейки».

А как должно быть?

Данные должны быть максимально похожи на реальные, демонстрирующие все разнообразия нюансов. Именно их должны содержать демо-базы 1С, а не куцые от бадлы-дверца взятые с потолка цифры, коих даже по количеству не очень много, причем созданных еще в допотопные времена.

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

В идеале, такие данные могли бы служить основой для тестовых нагрузок конфигураций 1С. Скажем, вы сгенерировали миллион операций и смотрите, сколько времени они проводятся, преобразуются и формируются отчеты. И тому подобное.

Смешно, но на просторах Интернета вполне можно найти десятки рабочих баз с реальными данными. Особенно на фтп-серверах. Причем там даже нет пароля на архив. Странно, что даже серьезные конторы допускают такие проколы. Эти данные удобно анализировать для себя, хотя публикация их незаконна. Просто для понимания реальной логики работы «а как у других?».

> Исключение тут пожалуй будет если Вам будут показывать внедренцы на ваших данных.

Это в теории, а на практике я себе это плохо представляю. Если они могут продемонстрировать работу на моих данных, то они уже практически внедрили у нас свои поделки, разве не так?

> Допилить тот же ЗУП до специфики конкретного предприятия стоит.

Не уверен. Иерархичность данных на уровне документов ЗУП не поддерживает. Менять его в этом направлении себе дороже. Проще вести первичный учет на стороне, экспортировать элементарные данные и операции в ЗУП ради построения регламентированной отчетности, а изменять конфигурацию разве что только косметически. Тогда можно вообще обойтись одной версией файловой ЗУП даже для большого предприятия.

> Кроме переводов конкретных предприятий с ЗИК на ЗУП и с Каминовской семёрошной Зарплаты  я так же как то писал свой кусочек зарплаты.

У меня ситуация сложнее, я переношу данные (для тестового учета) из своей программы в ЗУП. На уровне справочников без особых проблем. А на документах пока затык ибо слишком разная у нас логика работы. Вот я посмотрел их структуру регистра расчетов, но она совершенно не годится на роль реального журнала элементарных операций. Значит, там, где у меня будет один плоский внешний расчетный журнал, в ЗУПе для этих целей привлекается целый пучок всевозможных регистров. Но разбираться с этим зоопарком видимо еще придется.

> Только там требования были со стороны пользователя к юзабилити.

Очень важное требование, как на мой взгляд.
   Emery
 
112 - 24.10.17 - 08:53
(103) > Для минимизации накладных расходов на перенос доработок и перепиливание БД под требования законодательства ставится неизменный и неизменяемый управленческий контур с возможностью учета всяческих параметров типа прибыли и себестоимости и он обменивается с внешним регламентированным контуром. Внешний регламентированный контур безболезнено обновляется.

Ну, поскольку я иду не этим путем, то пока для меня не особо актуально.
   Emery
 
113 - 24.10.17 - 09:06
(108) > Если слить все воду, то получается, что главный недостаток ЗУПа - то, что он написан не вами и не укладывается в ваше мироздание.

Не-а! Главный недостаток ЗУП это его явно избыточная жесткость, просто вызванная зловредностью разрабов (по принципу: «Я начальник, ты дурак»).

А что касается мировоззрения, то тут все просто. ЗУП это продукт монополиста рынка. А интересы монополиста и простого потребителя совпадают отнюдь далеко не всегда. И совершенно бесполезно обвинять в этом монополиста, как волка, который хочет скушать ягненка. Просто, монополисту – монополистово, а потребителю – свое собственное, если он на это способен, иначе, пусть «плачет, колется, но ест кактус» :) . Вот когда начнется эпоха «Цифрового Коммунизма» или хотя бы «Цифрового Социализма», вот тогда ситуация измениться в лучшую сторону, а пока в этом направлении движется только опенсорс, который, на мой взгляд, надо тайно или явно спонсировать на уровне государственных структур, ориентированных на Социализм-2.0 (в СССР-2.0 :) ).
   El_Duke
 
114 - 24.10.17 - 09:23
(107) "Если какая-та модель охватывает 95-99% процентов всех случаев, а для вас актуальны оставшиеся 1-5%, то аргументы, что вы должны прогибаться под типовой вариант почему-то плохо воспринимаются."

Эти аргументы отлично воспринимаются.
Рассмотрим ситуацию с точки зрения физики. Если некий результат получен с точностью в 10% это называется инженерной точностью. Если с точностью 1-5% это уже прецезионная точность.
Переходя на понятия ЗУП, если у 95% сотрудников удается учитывать рабочее время методом отклонений и лишь 5% требуют ввода индивидуальных табелей (кстати почему их нельзя предлагать, вы ведь в своей самописке делаете именно инд.табель ?) - это прекрасный результат и никакого внешнего инструмента тут не надо.

"Отчасти потому, что так хотят бухи. А их хотелки связаны с тем, что у разных подвидов разный ФОТ. Именно поэтому они хотят показать отдельно от основной работы «оплату в праздничный день по графику» и «доплату в праздничный день по графику». Тоже самое «вне графика» влияет на другую статистику"

Про хотелки бухов без комментариев. Они много чего хотят, а попроси мотивированно ! написать ! зачем это - сдуваются и кроме как "хочу" объяснений нет.
Про разный ФОТ. На этом заглохла прошлая тема. Вы не смогли объяснить откуда он берется. Если начать докапываться до сути то все сведется к оплате по окладу либо по среднему, рассчитываемому на основании оклада. Никакого другого ФОТа российское законодательство при оплате праздника по графику, доплаты за праздник по графику  и др. не предусматривает. Вне графика кстати тоже.
Все эти оплаты в ЗУП делаются автоматом при настройке сменного графика. Зачем нужны 8 разных доплат - непонятно ни тогда, ни сейчас.

"Руководство и собственники подобными вещами не интересуются и даже не в курсе, что они существуют."

Здесь легко верю, конечно не в курсе.
Если бы они осознавали что их учетная система завязана на одного человека и случись что с ним - наступит хаос и никто не сможет сказать когда он кончится - думаю не позволили бы провести автоматизацию подобным образом ...
   Филиал-msk
 
115 - 24.10.17 - 09:36
(113) > Главный недостаток ЗУП это его явно избыточная жесткость, просто вызванная зловредностью разрабов (по принципу: «Я начальник, ты дурак»)

Ффффатит, у меня монитор уже зажироточил!
   Dotoshin
 
116 - 24.10.17 - 09:45
(114) >>Про разный ФОТ. На этом заглохла прошлая тема. Вы не смогли объяснить откуда он берется.

Стопудово проблема не в разном ФОТе, а в разном месте возникновения затрат (МВЗ) или шифре производственных затрат (МВЗ). Наверняка тетенька, которая требует 8 подвидов оплат потом переписывает итоговую цифру по виду оплаты из свода начислений/удержаний в какой-нить экономический отчетик в экселе.
Я бы на месте ТС поинтересовался этим вопросом.
   Dotoshin
 
117 - 24.10.17 - 09:48
+ (116) А внятно объяснить они не могут потому что понимают, что как только они дадут такое пояснение, вся их ручная работа по сборке "мегаважного" отчета будет моментально автоматизирована, либо выяснится, что этот отчет нарен никому не нужен и тетенька остнется не у дел.
   Злопчинский
 
Ведущий
118 - 24.10.17 - 09:55
Чего ты так впилился в эту иерархичность данных? Какая от неё польза - конкретного ответа кроме как удобно по папочкам разложено - не прозвучало. Поэтому плевок в сторону документов об отсутствии иерархичности - против ветра
   Злопчинский
 
Ведущий
119 - 24.10.17 - 09:56
Ты вот эту свою ветку на Кубани выложи. Там зарплатный народ активно тусуется - будет гораздо интереснее/полезнее
   Genayo
 
120 - 24.10.17 - 09:59
(107) Ну как я и думал, это просто дурная работа ради работы.
   Злопчинский
 
Ведущий
121 - 24.10.17 - 10:00
Универсализм типовых есть и кузь и бяка. Кузяво то, что отвалился расчетчик или фикс - любой расчетчик сядет и посчитает и Франс если что подхватить и подстрахует.
Бяка потому что где-то неудобно, где-то излишества, где-то тормоза.
По моему мелкому мнению все-таки типовые использовать предпочтительнее (закрыв бяки хорошей обвеской например).
Да и большие сомнения у меня в том, что самописка следует нормам законодательства...
   Emery
 
122 - 24.10.17 - 10:18
(104) > Нашёл свою старую ветку про табель 
> Выложил на суд кусок конфигурации Табель

Интересно, но разбираться с программой без данных и основных скринов скучновато. Это лишний раз доказывает, что когда я выложу свою поделку в общее пользование, надо будет сначала показать ее работу в картинках, а потом уже предоставить версию с реально-подобными данными.
   Emery
 
123 - 24.10.17 - 10:43
(110) > Половина хотелок бухов от неграмотности.

Неграмотность бухов обычно существенна в финансовых проколах предприятия. Но у нас такого я пока не наблюдал. Кроме того, бухи несут ответственность. Когда приходят разные проверки, смысл зарплат и премий которых найти ошибки у нас, то это вызывает нервный стресс не у меня, а у бухов (именно сам факт проверкм). Меня, слава Богу, они для своих разборок не привлекают. Именно поэтому я уважают их пожелания.

> А разный ФОТ скорей всего не у подвидов оплаты, а у видов работ, оплата которых выполняется этими подвидами.

Меня интересует именно техническая сторона реализации. Хотя я не вижу здесь особых проблем. Хоть в анфас, хоть в профиль, какая разница? Пусть даже для бухов это сила привычки. Конечно, я им свое мнение всегда скажу, но последнее слово все же оставляю за ними.

> Появятся у вас еще какие-то работы с отдельным ФОТ, еще 8 подвидов оплаты наплодите?

Не важно, пусть даже просто ради удобства обзора данных во внутренних отчетах. Детализация расчета заработной платы может быть какой угодно, если это не влияет на правильность результата. У меня разработана собственная классификация видов расчетов, которых там несколько сотен, хотя использовались у нас не более пары из них. Новый вид расчета (под ответственность пользователя) легко создается и без проблем модифицируется старый. Они легко настраиваются и обслуживаются. Поддерживается даже соответствие моих кодов (как бы универсальных) и теми, что приняты на предприятии. Я даже не пытаюсь заставить расчетчиков использовать мою систему кодирования, хотя могу. Пусть получают информацию в тех разрезах, которые для них удобны.

> Сделайте уже аналитический признак к виду оплаты и не плодите сущности.

Этот принцип противоречит утверждению «клиент всегда прав». Поэтому останемся при своих мнениях.
   KnightAlone
 
124 - 24.10.17 - 11:04
только написал, что табель не нужен и обнаружилося такой баг - у сотрудника (уже человек 6 таких нашли) за первую половину месяца 0 отработннных дне (отпуск, больничный, невыход), в расчете за первую половину месяца считает 1 рабочий день. Если сформировать на сотрудника табель по данным документам отклонений- начинает считать нормально за первую половину месяца. 3.1 последний релиз, сталкивался кто? по регистрам нигде не вижу, чтобы этот рабочий день где-то отдельно выделялся. такое впечатление, что игнорится невыход. Получается очень странная ситуация - алгоритм сбора табеля по данным отклонений и алгоритм сбора расчета за первую половину месяца по учетам отклонений - работают по-разному (
   KnightAlone
 
125 - 24.10.17 - 11:08
лазить отладчиком по 3.1 тот еще ад... 15 переходов между разными модулями только чтобы получить выполнение одной строки кода - это для них норма
   KnightAlone
 
126 - 24.10.17 - 11:13
в РН данные оперативного учета рабочего времени сотрудников Отпуск неоплачиваемый с разрешения работодателя делает движения, только если это внутрисменная неявка. если отсутствие полный день - движений нет. Это так и задумано было?
   KnightAlone
 
127 - 24.10.17 - 11:17
ща отдельную тему создам под это
   KnightAlone
 
128 - 24.10.17 - 11:22
   Emery
 
129 - 24.10.17 - 11:33
(114) > Рассмотрим ситуацию с точки зрения физики. Если некий результат получен с точностью в 10% это называется инженерной точностью. Если с точностью 1-5% это уже прецезионная точность.
Переходя на понятия ЗУП, если у 95% сотрудников удается учитывать рабочее время методом отклонений и лишь 5% требуют ввода индивидуальных табелей (кстати почему их нельзя предлагать, вы ведь в своей самописке делаете именно инд.табель ?) - это прекрасный результат и никакого внешнего инструмента тут не надо.

Некорректное сравнение! Все равно, что сравнивать теплое с мягким.

У меня не индивидуальные табеля для всех, а общие, позволяющие делать индивидуальную настройку любому, с максимально возможной гибкостью. В ЗУПе индивидуальные табеля заполняются вручную. У меня даже этот процесс полуавтоматизирован. У них он идет в одну строку, а у меня поддерживает несколько. Причем отклонения вносятся параллельно плану, фактические данные (со считывателей) подчинены плановым, но могут отсутствовать, если совпадают), детализация отклонений (до видов расчетов) подчинена обобщенным отклонениям (только для отображения в обобщенных табелях).

Хорошо, возьмем только общие искомые 95%. Но даже в этом случае работать с моими графиками удобней, чем с ЗУПовскими. Вы полагает иначе, кто же против? Ведите табеля в ЗУПе. Мы же договорились, у нас демократия. Я не собираюсь делать конкуренцию ЗУПу, это не в моих силах. Но меня лично напрягает первичный учет там, поэтому я использую собственный и собираюсь реализовать экспорт внешних первичных данных в ЗУП. Будут у меня в этом деле клиенты или нет, не суть важно. Главное иметь комфорт в работе.

Вспомним цитату одного маститого литературного автора: «Вы можете написать хороший роман и у него будут поклонники. Вы можете написать посредственный роман и у него найдутся сторонники. И вы можете написать просто ужасный роман, и он не останется без почитателей». Цитирую по памяти.

Так что я за свою программу не переживаю и вам предлагаю больше здорового равнодушия.

> Про разный ФОТ. На этом заглохла прошлая тема. Вы не смогли объяснить откуда он берется.

Очевидно, что эта тема мне не особо интересна. Формально у нас разное законодательство. Ну, хорошо, раскопаю я вам необходимые детали, вы скажите, что да в ЛНР действует пока еще не 100%-но российское законодательство. Так чего мы будем копья ломать из-за этого. Мне лично достаточно того, что приходит начальник ОТиЗ и говорит, что ей нужно для статистики то, то и то. Ну, раз нужно, значит делаем. И еще наш новый главный бухгалтер много чего поменяла в работе нашего предприятия, но указанных вопросов это не коснулось, значит, ее устраивает как есть, меня лично тоже. Например, она поменяла структуру предприятия, при том, что расчетчики не хотят отказываться от старой. В итоге, моя система поддерживает одновременно три структуры, основную, альтернативную и управленческую (на уровне категорий должностей, это тоже хотят видеть в органах статистики). При этом и плановое штатное расписание у меня допускает реализацию на трех деревьях, с детализацией до разрядов должностей подразделений. Сложно, согласен. Но, во-первых, дополнительные структуры использовать не обязательно, а, во-вторых, если вдруг кому-то понадобиться, то вот оно, под рукой.

> Если начать докапываться до сути то все сведется к оплате по окладу либо по среднему, рассчитываемому на основании оклада. Никакого другого ФОТа российское законодательство при оплате праздника по графику, доплаты за праздник по графику  и др. не предусматривает. Вне графика кстати тоже.

Я уже писал, что законодательство ЛНР лишь частично пересекается с законодательством Российской Федерации.

> Все эти оплаты в ЗУП делаются автоматом при настройке сменного графика. Зачем нужны 8 разных доплат - непонятно ни тогда, ни сейчас.

Неужели и сейчас непонятно? Тогда хоть в Книгу рекордов Гинесса заноси :) .

> Если бы они осознавали что их учетная система завязана на одного человека и случись что с ним - наступит хаос и никто не сможет сказать когда он кончится - думаю не позволили бы провести автоматизацию подобным образом ...

Да, наверное, тогда меньше вопросов бы задавали коллегам, фигаля там этот программист делает, когда и так все работает. Собственники и руководство («круговорот олигархов в природе») у нас все новые и меня еще плохо знают, так что «не позволили бы», это не к ним. Кстати, это уже третья группа собственников на моей памяти. У первых двух не было проблем со мной, почему должны быть у третьей? Так, что логично, по-моему, уже съехать с этой темы, тем более что я высказывался по ней уже не раз.
   Emery
 
130 - 24.10.17 - 11:48
(116) > Наверняка тетенька, которая требует 8 подвидов оплат потом переписывает итоговую цифру по виду оплаты из свода начислений/удержаний в какой-нить экономический отчетик в экселе.
> Я бы на месте ТС поинтересовался этим вопросом.

Этот вопрос полностью под контролем главбуха, именно она переносит наши данные (с бумажных отчетов) в конфу «Производство и Услуги» для Украины (частично модернизированную мною под законодательство ЛНР). Даже если это избыточная информация для нее, то она ее не напрягает, почему тогда должна напрягать меня. Меня смущают технические ограничения ЗУП. Если бы их не было, то его можно было бы легко адаптировать под ЛНР или там ДНР. Но они есть, поэтому это сделать несколько труднее. Легче уж вести первичный учет на стороне, а регламентная отчетность ЗУПа нам пака совершенно неинтересна, разве, что если соберусь работать в российском правовом поле. С этих позиций и РСБУ и МСФО и собственно сам ЗУП также интересны, но, естественно, не абсолютно.

Другое дело, что главбух может захотеть автоматическую выгрузку из моей «зарплаты» в ее относительно типовую. По крайней мере, я к этому морально готов, хотя сам собираюсь заняться этим попозже.
   Emery
 
131 - 24.10.17 - 12:04
(118) > Чего ты так впилился в эту иерархичность данных? Какая от неё польза - конкретного ответа кроме как удобно по папочкам разложено - не прозвучало.

Если удобство работы пользователей для вас не имеет значения, то, что тогда говорить. И потом, легко и приятно поддерживать и сопровождать именно собственную программу, а не чужую. У нас тут программистов в провинции вообще никого не осталось, все уехали в Россию. Поэтому проблемы для предприятий были бы даже, если бы все их конфигурации были 100%-типовые. Хотя я не представляю себе, какие могут быть типовые конфигурации в ЛНР и ДНР?

Ну а коли уж приходится поддерживать программы, то почему я должен отказывать себе в удовольствии работать именно с той программой, которая мне нравится? По крайней мере, мне не на кого пенять, кроме как на самого себя. Согласитесь, что это лучше, чем «есть чужой кактус» :) .

> Поэтому плевок в сторону документов об отсутствии иерархичности - против ветра

Неужели вы думаете, что я тут ищу себе сторонников моего стиля программирования? Нет, я просто считаю важным показать наличие альтернативы. Использовать именно ее никого не принуждаю. Мне лично интересны возражения по существу, они могут положительно повлиять на мои дальнейшие разработки. А эмоции меня интересуют гораздо меньше.
   Emery
 
132 - 24.10.17 - 12:10
(119) > Ты вот эту свою ветку на Кубани выложи. Там зарплатный народ активно тусуется - будет гораздо интереснее/полезнее

Наоборот, я вот уже думаю, наверное, надо было бы опубликовать тему на форуме sql.ru. Там народ более пассивный, чем здесь, а я уже притомился отвечать, на основную работу времени не остается. Но, как говориться, «взялся за гуж, не говори, что не дюж». Сам не люблю, когда авторы создают тему, а потому по-быстрому сваливают с нее. Все очень просто, перестанут спрашивать, перестану отвечать.
   El_Duke
 
133 - 24.10.17 - 12:13
(129) "Некорректное сравнение! Все равно, что сравнивать теплое с мягким"

Абсолютно корректное.

"У них он идет в одну строку, а у меня поддерживает несколько"

Коллега, вам надо таки изучить типовой ЗУП 3.1 подробнее. Там в Табеле уже давненько доступна Форма редактирования дня, в которой можно задавать кучу видов времени, в том числе своих. Можно выбирать Территории, оплата работы на которых настраиваема. Табель насколько я помню тоже заполняется автоматом, потом правится. Вот вам и полуавтомат.

"Но меня лично напрягает первичный учет там, поэтому я использую собственный"

Ну т.е. все уперлось в личные предпочтения, а не в возможности ЗУП ? Изначально в первой теме Вы писали что ЗУП  всего того что вы сделали не умеет.

"Очевидно, что эта тема мне не особо интересна. Формально у нас разное законодательство"

И очень жаль что не интересна.
Делать за юзером каждый пук что выдаст его творческий разум - сомнительный подход. Консультант по учету сначала разберется нужно ли это в реальности, если нужно то может уже есть типовой механизм. Кидаться кодить все 146% хотелок юзеров не следует. Я считаю совершенно нормальной ситуацию когда консультант отказывает главбуху в автоматизации чего то им выдуманного и не нужного в реальности.
О том под какое законодательство работаешь тоже вопрос задавался, ответа не было.

"Неужели и сейчас непонятно? Тогда хоть в Книгу рекордов Гинесса заноси :) "

Если в этой теме я один этого не понимаю - заноси

"Ну а коли уж приходится поддерживать программы, то почему я должен отказывать себе в удовольствии работать именно с той программой, которая мне нравится?"

Работай, кто против - я никогда
Только не говори что ты сделал нечто что не умеют типовые решения. Умеют они это
 
 
   Лохматые Уши
 
134 - 24.10.17 - 12:16
(0) Изучай ЗУП 3.1. Узнаешь много интересного и полезного для себя. Версию КОРП тоже глянь.
Не зря сейчас появляются позиции в вакансиях - программист-консультант. То есть быть хорошим программистом уже недостаточно. Нужны специалисты со знанием методик учета в типовых конфигурациях.
У нас среднее предприятие. ЗУП 3.1 решает 98% всех проблем по взаиморасчетам с сотрудниками.
   Злопчинский
 
Ведущий
135 - 24.10.17 - 12:19
(131) все понятно и все нормально.
Чужие программы г..о , моя - лучше. Потому что моя.
Это нормально.
В чужом разбираться и выкручивать под свои нужды - всегда поначалу тяжелее.
Но писать свой велосипед когда есть промышленные образцы - в целом путь в никуда. В частностях - да, кое где свой удобнее, что хочу то и навешаю - хоть багажник, хоть спутниковую антенну.
Но это все фигня. Ровно до того момента пока жив самоделкин. Гикнется/уедет/пропадает - с полгодика-годик ещё на последнем пинке приедет, потом или вообще откажутся и ручками будут делать или промышленный образец поставят.
   Emery
 
136 - 24.10.17 - 12:20
(121) > По моему мелкому мнению все-таки типовые использовать предпочтительнее (закрыв бяки хорошей обвеской например).

В России я бы так, наверное, и действовал бы.

> Да и большие сомнения у меня в том, что самописка следует нормам законодательства...

Нашим следует, не забывайте, что проверяющие и контролирующие органы нам расслабляться не дают. Вот из последнего, заставили все руководство поубирать премиальные доплаты, которые они начислили самим себе. Плюс штрафные санкции за это, при том, что формально мы не являемся государственным предприятием. Собственник спрашивает, почему согласились, руководство отвечает, мы не согласны, но хозяйственные суды в ЛНР практически не работают, оспорить противоправные действия негде. На том и порешили.
   Emery
 
137 - 24.10.17 - 12:26
(124) – (128) Что и требовалось доказать. Хотите иметь меньше душевных рубцов, работайте с той программой, которую способны полностью контролировать.
   El_Duke
 
138 - 24.10.17 - 12:31
(134) "Золотые слова Виктор Харитонович !"

Именно знание методологии ценно. Это гораздо важнее умения накодить "то что скажут" 

(137) Скорее всего рубцы там на чьих то кривых руках, неправильно сделавших первичку
   Emery
 
139 - 24.10.17 - 13:08
(133) > Там в Табеле уже давненько доступна Форма редактирования дня, в которой можно задавать кучу видов времени, в том числе своих. Можно выбирать Территории, оплата работы на которых настраиваема. Табель насколько я помню тоже заполняется автоматом, потом правится. Вот вам и полуавтомат.

Допустим, что табель в ЗУПе решает все проблемы учета рабочего времени. Если так, то хорошо, меньше будет проблем при конвертации данных. Но эта информация может быть важна для меня, моим табельщицам она бесполезна. Они скорее продолжат ручной ввод в экселе, чем «кулютерно» делать это в ЗУПе. Тут достаточно много причин, чтобы останавливаться на этом. Поэтому чисто практически мне нужно сначала закончить свою вторую версию, особенно в части учета рабочего времени и обучить работать на ней табельную. Поскольку уровень у них не самый высокий, то даже этот процесс не обещает быть легким. А про ЗУП и говорить нечего. Единственное, успокаивает, что это только тестовое внедрение для получения опыта работы в основном. В последствии можно будет привлекать постепенно табельную и кадры к ЗУПу, в который сначала все данные будут просто импортироваться. Если разберутся и смогут работать и плюс куча других если, тогда можно говорить о внедрении ЗУПа уже всерьез, а пока так, грубо говоря, баловство.

> Ну т.е. все уперлось в личные предпочтения, а не в возможности ЗУП ? Изначально в первой теме Вы писали что ЗУП  всего того что вы сделали не умеет.

Приятно, когда тебя внимательно читают :) . Я могу быть прав в своих суждениях или не очень, но сейчас тот же ЗУП заставляет меня временно сместить акценты. Именно он активизировал мою работу над второй версией зарплатной конфигурации. Чуть позже я снова вернусь к нему, сначала продолжу перенос данных, потом разработку нужных нам отчетов (из того, что есть нам подходят только несколько) и т.п. Не исключено, что возникнут новые вопросы и необходимость их обсуждения.

> И очень жаль что не интересна.

Когда очередь дойдет до бухгалтерской составляющей, то не исключено, что заинтересуюсь, но пока не горит.

> Я считаю совершенно нормальной ситуацию когда консультант отказывает главбуху в автоматизации чего то им выдуманного и не нужного в реальности.

У меня таких проблем просто не было. Главбух всегда ставила адекватные задачи. А когда надо было исправить ошибки типовой по амортизации основных средств и создать дополнительную отчетность, то вообще нарисовала требуемый ей макет в экселе с подробно на примерах показала ошибки в расчетах. В этом смысле с ней легко работать.

Другое дело, если главбух капризным окажется и скажет: «Несите мне другого консультанта» :) .

> О том под какое законодательство работаешь тоже вопрос задавался, ответа не было.

Странно, я отвечал на этот вопрос множество раз. На всякий случай еще раз повторю, для меня актуально законодательство ЛНР.

> Только не говори что ты сделал нечто что не умеют типовые решения. Умеют они это

А можно говорить: «Умеют, но хуже»? Или пусть даже не хуже для других, а только меня?

Ты можешь быть десять раз прав, я даже не буду спорить, но когда есть возможность работать на своей программе вместо чужой, я выберу свою. Нервы ведь мои, а не твои :) .
   Филиал-msk
 
140 - 24.10.17 - 13:24
(139) > когда есть возможность работать на своей программе вместо чужой, я выберу свою.

А тему-то зачем создал?
   Emery
 
141 - 24.10.17 - 13:24
(134) > Изучай ЗУП 3.1. Узнаешь много интересного и полезного для себя. Версию КОРП тоже глянь.

Кто спорит? Тестовое внедрение у меня пока никто пока не отменял. Хорошо, конечно, что в шею не гонят. Но вопросы в любом случае будут. Как бы ты адаптировал программу для РФ под ЛНР? Просто опиши стратегию действий.

> Не зря сейчас появляются позиции в вакансиях - программист-консультант.

Раньше была актуальна вакансия «консультант 1С», тогда я уже начал думать, что профессия программиста 1С отмирает (а тут еще Герман Греф высказался на эту тему). А сейчас уже «программист-консультант». Прогресс, однако. Или восстановление справедливости?

> То есть быть хорошим программистом уже недостаточно. Нужны специалисты со знанием методик учета в типовых конфигурациях.

Если надумаю пополнить поток программистов ЛНР, уехавших в Россию, то обязательно учту твой совет :) .

> У нас среднее предприятие. ЗУП 3.1 решает 98% всех проблем по взаиморасчетам с сотрудниками.

А сменные графики у вас есть? И сколько, если не секрет, у вас человек на предприятии и пользователей ЗУП? Пока никто не решается ответить на эти мои вопросы :) .
   Emery
 
142 - 24.10.17 - 13:28
(135) > Но это все фигня. Ровно до того момента пока жив самоделкин.

Ну, хорошо, тогда я вам тоже задам вопрос: Как бы вы адаптировали программу для РФ под ЛНР? Просто опишите свою стратегию действий.
   Emery
 
143 - 24.10.17 - 13:35
(140) > А тему-то зачем создал?

Я уже отвечал на это в 32-м посте. Но повторю, чтобы не искать долго:

Откровенно говоря, я хотел сделать реплику в « Табель ЗУП3, куда дели место? », но тему закрыли, поэтому создал свою. Смысл ее простой. ЗУП можно и нужно концептуально улучшать. Если разрабы не сделают это сами, то первичный учет мы будем вести самостоятельно, во внешней программе. А ЗУП использовать только как контейнер для регламентной отчетности.

Честно говоря, не думал, что выльется в полторы сотни постов.
   tgu82
 
144 - 24.10.17 - 13:58
Когда-то в юности на турбопаскале (еще 5.5.) написал большой пакет зарплаты для трамвайно-троллейбусного предприятия, куча всяких-всяких заморочек была включая печать сначала на барабанном принтере - отпахала больше 10 лет (3000 сотрудников и куча подразделений видов оплаты и прочего включая табели рабочего времени), потом уж заменили на 1С. правда в постановщиках я имел умнейшую начальницу отдела АСУ. До этого знал только фортран, СУБД не знал вообще, все индексные файлы и прочее - все придумал Сам. Файлы баз данных были бинарными. Общался с ними через прямой доступ с помощью своих индексов. Меню было как в Нортон-диск докторе (понравилось по цветам - использовал прерывания на ассемблере). Оверлейные модули использовал из-за нехватки ресурсов (должна была работать в том числе и на ПК Искра). Все было на английском, включая документацию. Но больше такое вряд ли напишу. ЗУП вещь вроде неплохая, можно и на ЗИК работать только это значит постоянно его самому дописывать типа для больничных и т.д.
   El_Duke
 
145 - 24.10.17 - 14:51
(139) Подытоживая дискуссию можно сказать: твое решение сгодится для автоматизации зарплатного блока на предприятии вашей республики, в условиях неопределенности законодательных положений и неясности дальнейших путей развития законодательства.

Но автоматизацию такого же предприятия в правовом поле РФ безусловно стоит делать в типовой зарплатной конфе.
   Emery
 
146 - 24.10.17 - 14:57
(144) У меня ситуация была сильно похожа. Купили ObjectProfessional-1.2 в исходниках. Тогда были интересные времена. Программы продавались всегда с кучей книг и стоимость имели символическую. Нам всегда казалось, что главная часть цены в книгах, а не в программе. Это было время, когда программы для MS-DOS продавались в исходных кодах. Это была мощнейшая библиотека по тем временам, тоже на паскале, которая поддерживал все, кроме баз данных.

После создания на ней первой учетной программы для налоговой, я открыл для себя базы данных в лице FoxPro-2.6a для MS-DOS, на котором три года затем писал собственный вариант зарплаты. Но писал неправильно, как сейчас выясняется, ибо идеологию баз данных не понимал совершенно.

Зато когда появился 1С77, я сразу понял, что это то, что мне нужно. Сразу начал там писать свою «зарплату», которая через 15 месяцев была уже внедрена на нашем предприятии. Где и успешно «фунциклирует» до сих пор. Теперь вот решил по-быстрому наваять вторую версию (лучше поздно, чем никогда!), стимулом которой послужила попытка тестового внедрения ЗУП. Просто некоторые вещи в моей программе проще делать, чем в ЗУПе, особенно с учетом того, что здесь пока еще не Россия, но уже и не Украина, а ЛНР. А эта тема должна была быть всего лишь комментарием в другом, закрытом уже топике.
   Emery
 
147 - 24.10.17 - 15:08
(145) > Подытоживая дискуссию можно сказать: твое решение сгодится для автоматизации зарплатного блока на предприятии вашей республики, в условиях неопределенности законодательных положений и неясности дальнейших путей развития законодательства.

Я рад, что наконец-то получил моральное право использовать нашу программу в наших условиях :) . Но почему тогда проблемы адаптации российской ЗУП для ЛНР вызвали так много споров? Об этом же и шла речь, что без большого напильника ваша программа у нас не взлетит.

> Но автоматизацию такого же предприятия в правовом поле РФ безусловно стоит делать в типовой зарплатной конфе.

До тех пор, пока не появится ЗУП-4.0 и нам не объявят, что поддержка ЗУП-3.х прекращена, в силу ее морального устаревания. И, может быть, разрабы расщедрятся и кинут нам со своего барского плеча пару десятков настроек, с помощью которых конфу можно будет адаптировать (неофициально, конечно, под ЛНР и ДНР) :) .
   El_Duke
 
148 - 24.10.17 - 15:40
(147) Экий вы изворотливый персонаж, прямо за язык ловить надо

В теме ЗУП 3.1 Начисление доплаты до МРОТ
в посте 25 вы писали "Есть масса предприятий, когда смены и графики у одного человека меняются по нескольку раз в месяц. Просто специфика работы такая. Масса сложностей может быть и другого плана, которые в ЗУПе не решаемы от слова «совсем». "

Теперь же выясняется что никакого "от слова «совсем»" нет, а есть частный случай предприятия с промежуточным законодательством. Именно этот случай вы решили.
А написали так, будто ЗУП не умеет считать рабочее время. В до конца не ясном законодательном поле конечно не умеет. Но об этом у вас ни слова не было сказано.
   Emery
 
149 - 24.10.17 - 18:29
(148) > Экий вы изворотливый персонаж, прямо за язык ловить надо

Не буду оправдываться, надоело уже. Будем считать, что вы правы. Но теперь, когда вы все как бы знаете, ответьте на мой вопрос, как бы вы адаптировали программу для РФ под ЛНР? Просто общая стратегия действий.

А к вопросу, что теоретически в ЗУПе можно сделать все, в смысле учета и расчета зарплаты, пусть только в российском правовом поле, мы еще как-нибудь вернемся. И можно будет еще сравнить эффективность работы. В вашей программе и в моей.
 
 Рекламное место пустует
   Amra
 
150 - 24.10.17 - 18:53
(149) Ну для Крыма были адаптации, логично сделать так же. Правда "ЛНР ненаш" )
   Emery
 
151 - 24.10.17 - 19:18
(150) > Ну для Крыма были адаптации, логично сделать так же. Правда "ЛНР ненаш" )

Хорошая постановка вопроса. Дело в том, что не факт, что нам в ЛНР / ДНР адаптированные версии 1С нужны больше, чем самой фирме 1С. Это мне напоминает начало распространения компьютеров еще в позднем СССР. Была продукция двух фирм IBM и Macintosh. Macintosh вел себя как сноб, воротил нос, оттопыривал мизинец. А IBM продавал свою технику по демпинговым ценам. Ее выгодно было даже покупать в СССР и продавать на Западе. В итоге IBM-PC совместимые компьютеры завоевали весь рынок СНГ, а Мак только недавно начал отвоевывать кое-какие позиции.

То же с программами под непризнанные республики. Кто первым предложит хорошее решение на местном уровне, тот и снимет все сливки. А спрос пока явно превышает предложение. И мне лично, откровенно говоря, выгодно продвигать свою конфигурацию на «семерке» здесь. Потому, что на «безрыбье и рак – рыба». Вопрос только в том, успею ли я предложить свой продукт раньше других. Но республики сейчас относительно бедные и много фирме «1С» никто платить не будет, но демпинговые цены потянут. Если фирма 1С не сглупит, как M$ в свое время с Интернетом, то может, в конечном счете, получить больший выигрыш, чем, если подключится к процессу позже. Я лично не жадный и меня устраивают оба варианта. Ну, а с фирмы 1С, если она прислушается к моему совету – презент, сколько не жалко :) .
   Филиал-msk
 
152 - 24.10.17 - 19:37
Сдается мне, в команде мечты Мани и Еврейчика открывается зарубежное направление...
   Злопчинский
 
Ведущий
153 - 24.10.17 - 20:33
(149) в сравнение в обязательном порядке д.б. включены тесты по запуску программы в сторонней фирме сторонними 1сниками и сторонними расчетчиеами.
А то получится как
"Опрос, проведённый в интернете, показал что 100% россиян пользуются интернетом"
   Злопчинский
 
Ведущий
154 - 24.10.17 - 20:36
(151) фирме 1с на все клюшечное - начхать  с высокой колокольни. Так что если не будешь дубом и не будешь пилить только под свою организацию, а более-менее продуманно  - то шанс откусить свой кусок рынка есть и неплохой ...
   Злопчинский
 
Ведущий
155 - 24.10.17 - 20:39
У нас, в РФ, с кризисом народ тоже ожабился. Клиент относительно недавно - ууууу, дорого! Ну так надо было покупать года три-четыре назад - и тогда тоже было дорого? Ну сейчас ещё дороже получилось... Кто виноват?
   Emery
 
156 - 25.10.17 - 07:03
(154) > фирме 1с на все клюшечное - начхать  с высокой колокольни.

Тем не менее, никто сорсы «семерки» выкладывать в общий доступ не собирается. Как ответил Нуралиев, на вопрос почему (цитирую по памяти): «Мы не враги самим себе, чтобы создавать себе конкурента». На самом деле эти сорцы давно уже не актуальны, т.к., исходники Qt либо wxWidgets совместно с кодом SQLite или подобных БД вполне могу претендовать на их роль (частично, конечно, но, ведь и код «семерки» пришлось бы серьезно переделывать, будь он открыт), однако здесь важен сам факт признания потенциальной важности 1С77. Ее более 10 лет уже не поддерживают, но потенциал ее еще не иссяк (при правильном подходе). Так что, это «дитя» в заботе «родителей» уже давно не нуждается, но в качестве «рабочей лошадки» сгодится еще не раз.

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

К сожалению, я понял это только сейчас, сравнивая свою программу с ЗУПом. Но еще раз повторю: «Лучше поздно, чем никогда». Внешний спрос уже есть и я его чувствую, так что будем работать :) .
   Бертыш
 
157 - 25.10.17 - 10:21
Emery чтобы Вас услышать и как-то понять надобно вспоминать клюшечные плюшки и времена. Порой читая Ваши сообщения Вы мне часто напоминаете рассуждения студента из анекдота выучившего единственный билет про блох и взявшего билет про рыб "Если бы у рыбы была шерсть, то у неё были бы блохи, а блохи подразделяются..."
Ну как прикажете понять Ваше отторжение документов и превознесение справочников и иерархии? С трудом вспоминается что у клюшек по сравнению со снеговиками был ряд узких мест для обхождения которых приходилось устраивать пляски с бубном. Два наиболее известных узких места это общий журнал документов  в виде таблицы в которую пишутся и которую в момент записи лочат все документы как один и периодические реквизиты в которые в свою очередь пишутся все в один файл. Дело в том что в восьмёрке, коллега, всё по другому... Здесь этих узких мест нет. В восьмёрке для отображения тех же документов можно применить динамический список, можно просто выгрузить и/или выгружать документы в объект дерево значений.
Рекомендую Вам, коллега, всё таки освоить восьмёрку. В сравнении с 7.7 решения на восьмёрке более производительны, более масштабируемы и более кросплатформены. После 7.7  неудобен восьмёрошный синтаксис помощник, но это мелочи. Скорость разработки возрастает по сравнению с 7.7 весьма и весьма существенно. Всяческие сложные отчёты ради написания которых на 7.7 приходилось крутить таблицы значений, если не было возможности использовать прямые запросы, на восьмёрке делаются мышкой. Попробуйте Вам понравится.
   Alexandr_U1982
 
158 - 25.10.17 - 10:51
(156)Вот вы все утверждаете, что ваша программа лучше ЗУПа.
А расскажите про функциональность вашей программы:
1. Могут ли пользователи вашей программы изменять структуру отчетов: произвольно изменять состав полей отчета, группировоки отчета, накладывать произвольные отборы?
2. Можно ли подключаться к вашей программе через интернет-браузер?
3. Могут ли пользователи вашей программы корректировать печатные формы?
4. Возможно ли в вашей программе настраивать произвольные формулы расчета начислений/удержаний?
5. Можно ли вести в вашей программе воинский учет? Я понимаю, что вы находитесь в ЛНР, но какой-либо воинский учет у вас все же есть?
6. Есть ли в вашей программе учет дополнительного страхования?
7. Есть ли в вашей программе учет отгулов?
8. Можно ли в вашей программе правильно рассчитать Северную надбавку? С учетом работы сотрудника в различных северных условия.

Я правильно понял, что в вашей программе отсутствует следующая функциональность (т.к. у вас ЛНР, а не РФ):
1. Расчет больничных листов с учетом РК и льгот сотрудника.
2. Обмен электронными листками нетрудоспособности с ФСС.
3. Расчет налога на доходы физических лиц.
4. Расчет страховых взносов.
5. Регламентированная отчетность для ИФНС, ФСС, ПФР и органов статитстики.
   Alexandr_U1982
 
159 - 25.10.17 - 10:58
(111)>Иерархичность данных на уровне документов ЗУП не поддерживает. Менять его в этом направлении себе дороже.
Тут работы на полчаса максимум, что в ЗУП 2.5, что в  ЗУП 3.1.
Делаете иерархический справочник, в шапке документа делаете реквизит со ссылкой на этот справочник. На форме списка документов отображаете документы в соответствии с иерархией справочника.
   mikeA
 
160 - 25.10.17 - 11:52
(94) Опыт у всех разный.

18250 человек, ЗУП КОРП "с неипическим механизмом расчёта премии". Три часа. ТРИ ЧАСА, КАРЛ!!!

Отсюда и (20).
"Поскольку времени немного, я вкратце матом объясню". (С)

Имею право.
   Emery
 
161 - 25.10.17 - 14:09
(157) > Ну как прикажете понять Ваше отторжение документов и превознесение справочников и иерархии?

Ну, это же очевидно! Меньше проблем с производительностью и больше комфорта с интерфейсом.
Причем не только для учета зарплаты, но и произвольных ресурсов вообще.

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

Я эти объекты не использую в принципе, разве что позволяю себе периодические реквизиты в константах. К вашим двум добавлю третье «узкое место» – слабый встроенный движок «семерки». Но все эти проблемные места для меня несущественны. Все документы и журналы строю на справочниках, проведение реализую самостоятельно, без механизма регистров. А проблемы с движком легко решаются сторонними средствами. Каналы связи – DDE, COM, OLE, файловый обмен, наконец. Система внешних компонент 1С, особенно с возможностью их нестандартного использования, например, «шаблона Орефкова», позволяет развивать «семерку» в любом направлении.

> Дело в том что в восьмёрке, коллега, всё по другому... Здесь этих узких мест нет. В восьмёрке для отображения тех же документов можно применить динамический список, можно просто выгрузить и/или выгружать документы в объект дерево значений.

Верю, но документы меня и в «восьмерке» мало привлекают. А вот скажем деобфускация байт кода «восьмерки» более интересна, поскольку основана на нетривиальных моментах, вроде алгоритма минимизации количества левосторонних связей для ориентированного циклического графа (DCG). При этом коммерческий WiseAdvice обходится очень даже ничего. Код восстанавливается со скоростью порядка пяти килобайт в час. Кстати, у Авы защита и то немного лучше.

> Рекомендую Вам, коллега, всё таки освоить восьмёрку. В сравнении с 7.7 решения на восьмёрке более производительны, более масштабируемы и более кросплатформены.

Ну, этот процесс идет как бы между прочим. Я уже упоминал здесь, что пишу для себя на «восьмерке» учет литературных структурных шаблонов. Идея простая, между литературой и программированием можно провести некоторые параллели. Но это так, к слову.

Производительность «семерки», с учетом дополнительных возможностей, меня вполне устраивает. Зато сильная экономия в железе и ПО. С масштабируемостью на уровне локальной сети тоже особых проблем нет. А если сервер имеет статический IP, то можно подключаться и по удаленному рабочему столу через Интернет. В общем, до сотни терминальных клиентов вполне можно иметь без особого напряга. Кроссплатформенность кому-то сильно нужна, кому-то чуть менее. В общем, для относительно легких задач, которых еще хватает, «семерка» очень даже ничего.

> Скорость разработки возрастает по сравнению с 7.7 весьма и весьма существенно.

А как насчет качества и удобства интерфейса? В типовых он просто ужасен. Обычно сделан по принципу, нам с ним не работать. Приведите пример хоть одной конфигурации с реально дружелюбным интерфейсом.

> Всяческие сложные отчёты ради написания которых на 7.7 приходилось крутить таблицы значений, если не было возможности использовать прямые запросы, на восьмёрке делаются мышкой. Попробуйте Вам понравится.

Мышкой хорошие отчеты не построишь. Опять же где в типовых хоть один приличный отчет? Сложный, информативный, красивый и компактный (не вылезает за пределы принтера).

Не надо считать это возражениями протии «восьмерки». Что-нибудь профессиональное на ней я делать все равно буду. Просто сейчас у последних релизов платформы появилось слишком много всего и важно правильно выбрать приоритет использования различных ее инструментов, поэтому пока внимательно присматриваемся.
   Emery
 
162 - 25.10.17 - 15:18
(158) > Вот вы все утверждаете, что ваша программа лучше ЗУПа.

Я, естественно, не могу тягаться с фирменным продуктом по всем параметрам. Об этом речь и не шла. Много раз уже говорил, что иногда выгодно первичный (элементарный) учет вести во внешней программе, потом экспортировать его в ЗУП ради получения регламентной и вообще все доступной отчетности и ради всякого там электронного обмена данными. Такая тактика позволит задействовать меньшее количество лицензий ЗУП.

Делать альтернативу всему ЗУПу абсолютно бессмысленно.

А в случае ЛНР / ДНР ЗУП, откровенно говоря, малополезен. И, как ни странно, я рад этому, потому, что тем самым возрастает ценность моей программы, здесь в непризнанных республиках. Интересно, а как в Приднестровье обстоят дела с этим? Вопрос только в том, чтобы перейти в конфигурации от ориентации на одно предприятие, к ориентации на более-менее произвольное предприятие. Плюс попутно устранить имеющиеся косяки и сделать оптимизацию. И уже сейчас, когда я начал больше говорить вслух о своей программе, уже слышны вопросы: «Ну, когда ты будешь уже готов?». Ибо народ вполне понимает, что покупка любой типовой «зарплаты» его проблем не решит. А некоторые предприятия у нас считают зарплату на таких программах, которые даже называть стыдно, вроде написанных на языке «массачусетского госпиталя» времен начала 60-х годов прошлого века, про который практически никто не знает. Берут количеством, а не качеством и если еще возражают против внедрения других программ, то потому что боятся остаться без работы, когда до пенсии осталось всего ничего. Хотя хватает и тех, которые согласны на внедрение уже сейчас.

> А расскажите про функциональность вашей программы:

Сразу скажу, что функциональности уровня ЗУП у меня нет. Программа минималистская, с фиксированным количеством нескольких десятков реально необходимых отчетов (была попытка реализовать универсальный механизм отчетов, но отказался, опыт показал, что быстрее наваять новый отчет самому, чем обучать пользователей как работать с универсальным отчетом, даже тех, которые рядом).

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

> 1. Могут ли пользователи вашей программы изменять структуру отчетов: произвольно изменять состав полей отчета, группировоки отчета, накладывать произвольные отборы?

Только модифицируя исходный код конфигурации. Он будет открыт. Закрыт будет только 64-х битный бинарный модуль внешнего расчета внешнего журнала. Хотя используемые sql-запросы движка SQLite будут доступны для редактирования во внешних файлах. Бинарный расчетный модуль предоставит возможность бесплатной работы в течение года. Если кто-то сможет написать свой вариант этого модуля, то тогда вообще все без ограничений.

> 2. Можно ли подключаться к вашей программе через интернет-браузер?

Делайте статический IP-адрес на сервере и соединяйтесь через удаленный рабочий стол. А так конфигурация будет оптимизирована под терминальный сервер. Другие варианты пока не рассматриваются.

> 3. Могут ли пользователи вашей программы корректировать печатные формы?

Естественно, редактор Moxel «семерки» поддерживает эти фичи плюс выгрузку в эксел. А отключать я их не собираюсь. Теоретически есть и другие варианты, но пока и этого хватит.

> 4. Возможно ли в вашей программе настраивать произвольные формулы расчета начислений/удержаний?

Можно будет через редактирование внешних sql запросов, если они не нарушат структуру внешней БД. Сама структура будет опубликована и размещаться целиком в памяти сервера.

> 5. Можно ли вести в вашей программе воинский учет? Я понимаю, что вы находитесь в ЛНР, но какой-либо воинский учет у вас все же есть?

Не планирую, но если сильно попросят, то могу сделать. Технически тут ничего сложного.

> 6. Есть ли в вашей программе учет дополнительного страхования?

У нас нет системы страхования как в России, поэтому пока не будет, со временем, почему бы и не реализовать?

> 7. Есть ли в вашей программе учет отгулов?

Это все будет входить в достаточно мощную систему учета рабочего времени, которую я надеюсь сделать лучше, чем в ЗУПе.

> 8. Можно ли в вашей программе правильно рассчитать Северную надбавку? С учетом работы сотрудника в различных северных условия.

Почему бы и нет? План видов расчета (в первой версии реализованной на плане счетов, во второй, скорее, всего на справочниках) легко будет редактировать. Логика работы там простая и прозрачная. Классификация видов расчетов по умолчанию моя собственная (с миру по нитке), но можно будет через соответствие видов расчетов настраивать свою систему кодирования и отбора.

> Я правильно понял, что в вашей программе отсутствует следующая функциональность (т.к. у вас ЛНР, а не РФ):

> 1. Расчет больничных листов с учетом РК и льгот сотрудника.

Больничные и отпуска у нас считаются почти как в России. Но системы ваших льгот у нас, естественно, нет. Кстати, что такое «РК»? У нас такая аббревиатура не используется.

> 2. Обмен электронными листками нетрудоспособности с ФСС.

Понятно, что у нас это исключено. Но если появятся смысл, время и силы, то буду ориентироваться на экспорт данных в ЗУП. В идеале связка двух программ должна быть удачной, но это на перспективу.

> 3. Расчет налога на доходы физических лиц.

Ваших вычетов у нас, конечно, нет, просто тупо берется 13% почти со всех видов начислений. Так что вопрос открыт.

> 4. Расчет страховых взносов.

Пока только по нашему законодательству – 31% со всех категорий работников, хотя дифференциация их осталась. Плюс регламентная отчетность и выгрузка данных для загрузки на соответствующие сайты.

> 5. Регламентированная отчетность для ИФНС, ФСС, ПФР и органов статитстики.

Естественно, только для наших структур. Сама отчетность у нас в целом проще, чем у вас. Теоретически решаемо, через экспорт-импорт между программами.
   Skylark
 
163 - 25.10.17 - 15:52
А у меня вопрос, сколько в итоге зарплата рабочего, посчитанного по этим многоуровневым графикам?
   Skylark
 
164 - 25.10.17 - 15:55
Вообще создается ощущение, что речь идет о каком-то предприятии-динозавре. С мизерной зарплатой вследствие которой работники занимаются совмещениями откуда возникает необходимость в дичайшем учете рабочего времени и куче графиков.
   Emery
 
165 - 25.10.17 - 18:49
(159) > Тут работы на полчаса максимум, что в ЗУП 2.5, что в  ЗУП 3.1.
Делаете иерархический справочник, в шапке документа делаете реквизит со ссылкой на этот справочник. На форме списка документов отображаете документы в соответствии с иерархией справочника.

В этом направлении я немного думал, только наоборот, не в документе ссылка на справочник, а в справочнике ссылка на документ. Пока ничего не могу сказать, не экспериментировал. Но в целом в «восьмерке» возможностей на порядок большей, чем в «семерке», так что изгаляться можно по-разному. Дела там с документами обстоят немного лучше, чем в 7.7, но о собственном стиле в 8.3 говорить пока рано.
   Alexandr_U1982
 
166 - 25.10.17 - 19:04
(162)>А в случае ЛНР / ДНР ЗУП, откровенно говоря, малополезен. И, как ни странно, я рад этому, потому, что тем самым возрастает ценность моей программы,
В свое время делал адаптацию ЗУП 2.5 для одного крупного холдинга под законодательство Таджикистана и Кыргызстана. Трудозатрат потребовалось не так уж и много.
ИМХО: Проще взять типовой ЗУП 2.5/3.1 и адаптировать его под законодательство ЛНР/ДНР, чем писать с нуля свою программу.
   Alexandr_U1982
 
167 - 25.10.17 - 19:05
(162)>> 1. Могут ли пользователи вашей программы изменять структуру отчетов: произвольно изменять состав полей отчета, группировоки отчета, накладывать произвольные отборы?
>Только модифицируя исходный код конфигурации.

Получается, что для модификации вашей программы потребуется специально обученный программист.
Восьмерка же содержит в себе систему компоновки данных (СКД) - механизм для построения отчетов, с помощью которого пользователи могут самостоятельно без помощи программиста менять структуру отчета.
СКД позволяет пользователям в режим предприятия изменять группировки отчета, удалять/добавлять поля, накладывать отборы, изменять оформление отчетов и т.д.
Программист требуется только для создания отчета и для модификации запроса/кода получающего данные для отчета.
Сделав свою программу на 7.7, вы лишаете своих пользователей этого мощного инструмента, и для любой модификации отчета они вынуждены бежать за программистом.
   Alexandr_U1982
 
168 - 25.10.17 - 19:05
(162)> 2. Можно ли подключаться к вашей программе через интернет-браузер?
>> Делайте статический IP-адрес на сервере и соединяйтесь через удаленный рабочий стол.

Платформа 8.2/8.3 позволяет подключаться сразу к базе 1С через интернет-браузер. Удаленный рабочий стол становиться не нужен.
   Alexandr_U1982
 
169 - 25.10.17 - 19:05
(162)>> 3. Могут ли пользователи вашей программы корректировать печатные формы?
>Естественно, редактор Moxel «семерки» поддерживает эти фичи плюс выгрузку в эксел.

Здесь я неправильно сформулировал вопрос. Под "печатными формами" имел ввиду "макеты печатных форм".
ЗУП 3.1 позволяет пользователям в режиме предприятия модифицировать макеты печатных форм.
Модифицированные макеты сохраняются в базе и в дальнейшем печатные формы уже формируются с учетом пользовательских изменений.
Насколько мне известно, на семерке такого сделать нельзя.
   Alexandr_U1982
 
170 - 25.10.17 - 19:06
(162)>> 4. Возможно ли в вашей программе настраивать произвольные формулы расчета начислений/удержаний?
>Можно будет через редактирование внешних sql запросов, если они не нарушат структуру внешней БД

Здесь снова получается, что для изменения формулы расчета начисления или удержания требуется бежать за программистом.
В ЗУП 2.5/3.1 пользователи могут составлять произвольные формулы расчета самостоятельно, без помощи программиста.
   Emery
 
171 - 25.10.17 - 19:06
(160) > 18250 человек, ЗУП КОРП "с неипическим механизмом расчёта премии". Три часа. ТРИ ЧАСА, КАРЛ!!!

Поздравляю, СЭР! Я обязательно передам эту информацию другу. Шесть десятых секунды на человека это круто! Вот если бы ваша система делала бы полный протокол расчета в текстовом виде, тогда можно было бы говорить и об относительном уровне сложности расчетов. Кстати, только что глянул свои текстовые полные протоколы за последний месяц. Максимальный размер более 250 КБ, а минимальный порядка 7 КБ. Соответственно время расчета этих людей сильно отличается. У меня в первой версии программы скорость расчета примерно 3,5 секунды на человека, во второй, надеюсь будет быстрее, поскольку вся расчетная БД будет целиком в памяти и будут делаться предрасчеты для средних.
   Alexandr_U1982
 
172 - 25.10.17 - 19:06
(162)>> 8. Можно ли в вашей программе правильно рассчитать Северную надбавку? С учетом работы сотрудника в различных северных условия.
>Почему бы и нет?

Для правильного расчета северной надбавки с учетом работы сотрудника в различных условиях работы, необходимо хранить стажи работы сотрудника в различных северных условиях.
Также необходимо точно отслеживать дату, в которую сотрудник наберет стаж для смены размера северной надбавки.
Если сотрудник вахтовик, то из северных стажей необходимо выбрасывать периоды нахождения сотрудника на межвахтовом отдыхе.
В настоящее время ни ЗУП 2.5, ни 3.1 не считают северную надбавку в точности с законодательством.
Сомневаюсь, что ваша программа также ее сможет посчитать правильно.
   Alexandr_U1982
 
173 - 25.10.17 - 19:07
(162)>Кстати, что такое «РК»?
РК - это районный коэффициент. Бывает федеральный и региональный. В северных районах больничные листы рассчитываются с учетом федерального районного коэффициента.

ИМХО: Лучше было бы взять за основу типовой ЗУП, и в нем реализовать свою новую подсистему "с преферансом и поэтессами", чем разрабатывать свою программу с нуля.
В таком случае пользователи не были бы лишены возможностей современных платформы и конфигурации, и в дополнение получили бы новый функционал.
Не нужны были бы замудренные обмены и расчеты с использованием внешних компонент.
   Emery
 
174 - 25.10.17 - 19:25
(166) > Проще взять типовой ЗУП 2.5/3.1 и адаптировать его под законодательство ЛНР/ДНР, чем писать с нуля свою программу.

Моя первая версия моей программы работает успешно уже более десяти лет. Сейчас речь идет о второй версии, а это не совсем с нуля.

А так я уже давно начал предлагать народу адаптировать под ЛНР любой из ЗУПов, от 2.1 (для Украины) до 3.1 (для России). Но вы первый, кто на это повелся. Предлагайте более конкретно свои варианты, хотя бы на уровне общей стратегии. Выкладывайте на сайт свою версию, может кто купит. По крайней мере, мне будет интересно услышать вашу концепцию адаптации и внедрения.

Первый простейший вопрос на вскидку. Как решить вопрос с округлением НДФЛ? В России он до рубля, у нас до копейки.

Потом можно будет обсудить другие вопросы, если будет интересно.
   Emery
 
175 - 25.10.17 - 20:02
(167) > Получается, что для модификации вашей программы потребуется специально обученный программист.

Вы интересно рассуждаете. Я делаю открытый продукт, но ориентированный на конечного пользователя. Типичные пользователи у нас не слишком квалифицированные. «Не только лишь все» могут в экселе сами написать формулу для суммы ячеек. Я вот переживаю, как я внедрю в табельной свой учет рабочего времени, поскольку они обучаются ооочень медленно. А как бы они все работали с ЗУПом я вообще не представляю. Только стоять над каждым и диктовать под запись последовательность нажатий мышки и клавиш и то будет не быстро. Все «специально обученные программисты», соображающие хоть чуть-чуть ухали в Россию. Захарченко зовет в ДНР программистов из «неньки», то бишь нынешней Украины.

Поэтому квалифицированный пользователь это скорее исключение, чем правило. Даже в Донецке и Луганске полно вакансий программистов 1С. Тяжело здесь с этим. Проблемы с внедрением будут даже с хорошими программами. Вот почему я не стремлюсь иметь много клиентов. Каждого из них нужно будет нянчить на руках. А так, продал программу и забыл про нее, я в это здесь не очень верю. Продай за небольшие деньги, обучи, научи, внедри, поддержи и сопровождай постоянно.

Я не отговариваю, просто у нас такая ситуация, что держать себе на уме особо нечего.

> Восьмерка же содержит в себе систему компоновки данных (СКД) - механизм для построения отчетов, с помощью которого пользователи могут самостоятельно без помощи программиста менять структуру отчета.

Смотрите выше. Пользователи, самостоятельно, без помощи программиста, менять – ну, ну, хочу посмотреть на

> СКД позволяет пользователям в режим предприятия изменять группировки отчета, удалять/добавлять поля, накладывать отборы, изменять оформление отчетов и т.д.

Вы мне еще про КД-3 расскажите или про XDTO или про внешние источники данных. Можно еще про технологию внешних компонент. Интересно будет послушать :) .

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

Почти как философская дилемма. У вас «вы лишаете», у меня «я предлагаю». Стакан наполовину пуст или наполовину полон?

Просто я исхожу из местных, провинциальных реалий. Ваши идеи могут быть полезны, только в Донецке / Луганске и других крупных городах независимого Донбасса. В провинции пользователя, как правило, надо водить за ручку. И то он еще нос воротить будет, мол, начальство напрягает, а денег не дает, а тут еще этот как его, программист какой-то пристает, требует правильно и без ошибок делать что-то там забесплатно. Ага, щас! Вопросы мотивов и стимулов здесь еще те. Может быть, именно поэтому я свою программу десять лет особо не развивал, работает и ладно, все уже привыкли, никого напрягать не надо, как в начале внедрения.
   Emery
 
176 - 25.10.17 - 20:11
(168) > Платформа 8.2/8.3 позволяет подключаться сразу к базе 1С через интернет-браузер. Удаленный рабочий стол становиться не нужен.

Ну, хорошо, пусть все решают свои проблемы с помощью 8.2/8.3. Это все кажущаяся легкость. Выиграете в одном, проиграете в другом. Кто ж в этих вопросах абсолютно честен? И сразу «предлагает весь список»?
   Emery
 
177 - 25.10.17 - 20:21
(169) > ЗУП 3.1 позволяет пользователям в режиме предприятия модифицировать макеты печатных форм.

Это не свойство ЗУП, а возможности самой платформы, реализовано практически во всех типовых.

> Модифицированные макеты сохраняются в базе и в дальнейшем печатные формы уже формируются с учетом пользовательских изменений.

И не только это можно, но и много чего еще. Но это «вообще», а для решения конкретной проблемы этого мне явно недостаточно.

> Насколько мне известно, на семерке такого сделать нельзя.

Вот нашли проблему. У нас говорили, что это не проблема, а всего лишь задача. И вполне решаема.

П.С. Зря вы меня отговариваете от «семерки» и навязывает «восьмерку». Не тратьте зря время, все равно я буду делать по-своему.
   Emery
 
178 - 25.10.17 - 20:40
(170) > Здесь снова получается, что для изменения формулы расчета начисления или удержания требуется бежать за программистом.

Наверное, исходя из моих предыдущих ответов, вы сможете уже ответить за меня :) . Пусть внедряют программу, не требующую услуг программиста. Я хочу посмотреть на такую, в наших условиях. А вот в ЗУПе, который как бы не требует услуг программиста, я, как программист, не могу ничего безболезненно изменить. Только с помощью большого напильника. Вот заменил почти в десяти местах кода округление НДФЛ до нуля, на округление до двух знаков после запятой, а он зараза, все равно округляется до рубля. Для снятия блокировок настройки базы средних в редакторе формул тоже пришлось шерстить код. Зато постоянно слышу: «строго в соответствии с законодательством». Хотеть своего ничего нельзя, только следовать парадигме разрабов. Ну и следуйте на здоровье! А свои проблемы для себя я сам решу. Не хотите пользоваться моими программами и не надо, можно подумать, что я кого-то уговариваю. Мое дело предложить – ваше дело отказаться!

> В ЗУП 2.5/3.1 пользователи могут составлять произвольные формулы расчета самостоятельно, без помощи программиста.

Ура!!! Отличная информация, за исключением того, что ( ЗУП 3.1 Начисление доплаты до МРОТ ) :

«Насколько я понимаю, формульный редактор ЗУП имеет ряд ограничений:

1. Он не имеет доступа с произвольным параметрам / показателям базы данных, только тем, которые заранее предопределены; 

2. Он не может работать с UDF (user defined function, т.е. процедурами и функциями, определенными пользователем), а в вашем случае нужен именно алгоритм, а не формула;

3. Часть параметров предопределены на уровне кода конфигурации и не редактируемы извне (на уровне пользователя).

Одним словом, на первый взгляд, формульный редактор имеет больше рекламный смысл, чем практический.»
   Emery
 
179 - 25.10.17 - 21:00
(172) > Для правильного расчета северной надбавки с учетом работы сотрудника в различных условиях работы, необходимо хранить стажи работы сотрудника в различных северных условиях.

У меня уже хранятся три вида стажа сотрудников. Могу добавить еще 33, какие проблемы. Ввел новое поле нового стажа сотрудника (по конкретному назначению его учетной записи), записал туда данные и все, это поле становится доступным для sql-запросов. Т.е., достаточно просто обновить спецификацию данных для использования.

> Также необходимо точно отслеживать дату, в которую сотрудник наберет стаж для смены размера северной надбавки.

Каждый месяц делаем нужные предрасчеты для всех. При очередном расчете проверяем все из них на допустимые значения, если удовлетворяют – используем, нет – не используем. Просто общая техника для любых контрольных параметров учетных объектов.

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

Создаем пользовательскую функцию (UDF), назначаем ей приоритеты и все такое. При расчете, автоматом будет задействована. Только завязана она будет на качественный учет рабочего (лучше сказать, учетного) времени. Иначе, вводите фиксированные суммы по любым видам расчета.

> В настоящее время ни ЗУП 2.5, ни 3.1 не считают северную надбавку в точности с законодательством.

Потому, что самоограничили себя редактором формул, тогда когда нужен, вообще говоря, редактор пользовательских алгоритмов (т.е. созхдание процедур и функций с возможностью доступа к данным БД).

> Сомневаюсь, что ваша программа также ее сможет посчитать правильно.

Вы неправильно ставите вопрос. Программа может и не считать, потому что в стране могут использоваться десятки тысяч различных алгоритмов различных видов расчетов. Но она будет в состоянии обеспечить поддержку пользовательских алгоритмов, на уровне собственных внешних sql-запросов, которые система будет подхватывать автоматически. А зная структуру БД, вы сможете обращаться непосредственно к любым ее данным. Возможно это избыточная гибкость. Но кому нужна жесткость – вот, пожалуйста, есть ЗУП.
   Emery
 
180 - 25.10.17 - 21:15
(174) > ИМХО: Лучше было бы взять за основу типовой ЗУП, и в нем реализовать свою новую подсистему "с преферансом и поэтессами", чем разрабатывать свою программу с нуля.

Ну и возьмите! Я предлагаю вам, вы предлагаете мне. Так и будем в пинг-понг играть? Мне не нравиться ЗУП своей жесткостью и мегатоннами кода. Мне хватило одной попытки заблокировать округление НДФЛ до рубля. Десяти прямых изменений не хватило для этого. Уж лучше я напишу свою программу с нуля. Первый раз я прошел этот путь и не жалею и второй раз собираюсь пройти, тогда мне не придется, хаять разрабов. И им будет хорошо и мне. А вы мне хотите усложнить жизнь. Т.е., «хотели как лучше, а получится как всегда» или «благими намерениями вымощена дорога в ад».

> В таком случае пользователи не были бы лишены возможностей современных платформы и конфигурации, и в дополнение получили бы новый функционал.

Вам надо идти работать проповедником. Еще немного вашей агитации и я стану вашим адептом :) .

> Не нужны были бы замудренные обмены и расчеты с использованием внешних компонент.

Давайте уже открываете сайт «свидетелей восьмерки», че зря пропадать таланту. Честно говорю, вы слишком глубоко проникаете своими словами, меня удерживает от сектанства только понимание их малого смысла.
   Злопчинский
 
Ведущий
181 - 25.10.17 - 21:21
Эмери, блин
Ваять что-то на клюшках - это сейчас путь в никуда (только если как хобби или тестовый стенд) - поверь старому клюшечнику.
Лучше бы свои мегаидеи реализовал в виде зарплатной восьмерочной конфигурации. Имхо даже в среднесрочной перспективе выгоднее чем пилить свою какую-то версию.
Это может быть только от безысходности пилить на клюшках что-то новое или развитие старого. Бесперспективняк это.
   Emery
 
182 - 25.10.17 - 21:37
(181) > Ваять что-то на клюшках - это сейчас путь в никуда (только если как хобби или тестовый стенд) - поверь старому клюшечнику.

Мы все можем ошибаться. Как бы там ни было мои проблемы «семерка» пока решает.

> Лучше бы свои мегаидеи реализовал в виде зарплатной восьмерочной конфигурации. Имхо даже в среднесрочной перспективе выгоднее чем пилить свою какую-то версию.

Скажем так, пример «Магазьки» у меня перед глазами. Товарищ реализовал себя и в «семерке» и в «восьмерке». Мне бы повторить его подвиг!

> Это может быть только от безысходности пилить на клюшках что-то новое или развитие старого. Бесперспективняк это.

Если новая программа на «семерке» взлетит, то обязательно займусь ее версией на «восьмерке». Но только в такой последовательности. Сейчас меня очень привлекает внешний модуль на SQLite. Его реализация это уже совсем «семерка». Этот опыт очень пригодится и независимо от 1С вообще и применительно к SQL-серверу для 1С8. Но все должно быть последовательно. Перефразируя товарища Сталина: «То, что товарищ Магазька осуществил за 10-15 лет, мы должны пробежать за два-три года, иначе успеха не будет!» :) .
   Злопчинский
 
Ведущий
183 - 25.10.17 - 23:16
(182) время потеряешь
Пока новую версию сваяешь - ну полгода, пока обкатаешь - итого год. Если щвпустишь в массы - ну пусть ещё год-два.
Это же не белочка, это писец! 2-3 года на мёртвый продукт.
Вместо того чтобы вторую версию сваять на 8-ке. С её скоростью разработки получилось бы все быстрее.
   Alexandr_U1982
 
184 - 26.10.17 - 00:13
(174) >Первый простейший вопрос на вскидку. Как решить вопрос с округлением НДФЛ? В России он до рубля, у нас до копейки.

Сначала нужно прошерстить все объекты метаданных, в которых хранится посчитанный НДФЛ и заменить целочисленный тип данных на числовой тип с разрядность 2 знака после запятой.
Затем нужно прошерстить весь код и в расчете НДФЛ изменить целочисленное округление на округление до двух знаков после запятой.
Вот что-то подобное и делал в свое время при адаптации ЗУП 2.5 под законодательство Кыргызстана или Таджикистана.
   Alexandr_U1982
 
185 - 26.10.17 - 00:21
(177) >>ЗУП 3.1 позволяет пользователям в режиме предприятия модифицировать макеты печатных форм.
> Это не свойство ЗУП, а возможности самой платформы, реализовано практически во всех типовых.

Это не "возможности самой платформы", а одна из универсальных подсистем входящая в библиотеку стандартных подсистем (БСП). Все типовые решения для платформы 8.3 построены с использованием БСП, следовательно, они содержат возможность модификации в режиме предприятия макетов печатных форм.
   Alexandr_U1982
 
186 - 26.10.17 - 00:27
(178) Ничто не мешает в конфигураторе добавить свой предопределенный показатель и прицепить к нему свой алгоритм расчета.
   Alexandr_U1982
 
187 - 26.10.17 - 00:39
(179) >> В настоящее время ни ЗУП 2.5, ни 3.1 не считают северную надбавку в точности с законодательством.

> Потому, что самоограничили себя редактором формул, тогда когда нужен, вообще говоря, редактор пользовательских алгоритмов (т.е. созхдание процедур и функций с возможностью доступа к данным БД).

Редактор пользовательских алгоритмов - зло. Вот, представьте, существует такой редактор. Вы написали в нем какой-то алгоритм, обратились к каким-либо регистрам для получения данных. И тут в один прекрасный светлый день выходит долгожданное обновление, вы накатываете его. А в этом обновлении регистр, который вы использовали для получения данных, переименован. И ваш пользовательский алгоритм не работает. И что вы будете делать? Переписывать все пользовательские алгоритмы расчета начислеий/удержаний? И так после каждого обновления?

Типовой редактор формул покрывает 90% потребностей в написании формул. Если вам не хватает его возможностей, то никто не запрещает вам расширить его возможности. Также никто не запрещает вам дописать свои предопределенные показатели и использовать их в формулах расчета.
   Alexandr_U1982
 
188 - 26.10.17 - 00:44
(180) >Вам надо идти работать проповедником. Еще немного вашей агитации и я стану вашим адептом :) .

Ну теперь-то вы просто обязаны стать моим адептом)) В противном случае все ваши посты - это просто демагогия)
   Emery
 
189 - 26.10.17 - 07:57
(183) > время потеряешь

Да его и так уже немеряно потеряно. Но видимо у меня «судьба такой».

> Пока новую версию сваяешь - ну полгода, пока обкатаешь - итого год. Если щвпустишь в массы - ну пусть ещё год-два.

Это нормально.

> Это же не белочка, это писец! 2-3 года на мёртвый продукт.

Как раз выйдут на пенсию те, кто из рядом стоящих крупных клиентов не шибко заинтересован в обновлении их допотопной программы по зарплате. А ЗУП они все равно не поятнут.

> Вместо того чтобы вторую версию сваять на 8-ке. С её скоростью разработки получилось бы все быстрее.

У вас может быть опыта разработки на «восьмерке» больше. У меня меньше. Ту программу для себя, что я делал, по скорости разработки не показывала чудес производительности. Поскольку система 1С8 достаточно сложная, то с наскока ее брать не оптимально. Еще предстоит определиться с подмножеством инструментов платформы, которые стоит использовать, а которые не стоит. Что привлекать из внешних компонент и привлекать ли? Примеры типовых и нетиповых, даже защищенных конфигураций, меня как-то не сильно впечатляют. Очень многое в их стиле не нравится, но как сделать лучше, пока не знаю. Та же «Магазька» на «восьмерке», вроде сделана с любовью, защита прикручена как бы профессиональная, успехом пользуется баснословным, но стиль ее оформления мне совершенно не нравится. А что именно, объяснить не могу. Правда, мои попытки переноса данных из моей конфигурации в ЗУП (без использования КД), сильно помогают вникать в структуру и логику работы типовой «зарплаты». Так что пока собираюсь ограничиться этим. Плюс по необходимости изучение чужого кода, пока не выработаю собственный стиль программирования в 8.3. Поэтому начинать сейчас писать рабочую конфигурацию на «восьмерке» считаю пока нецелесообразным.
   Emery
 
190 - 26.10.17 - 08:34
(187) > Редактор пользовательских алгоритмов - зло. Вот, представьте, существует такой редактор. Вы написали в нем какой-то алгоритм, обратились к каким-либо регистрам для получения данных. И тут в один прекрасный светлый день выходит долгожданное обновление, вы накатываете его. А в этом обновлении регистр, который вы использовали для получения данных, переименован. И ваш пользовательский алгоритм не работает. И что вы будете делать? Переписывать все пользовательские алгоритмы расчета начислеий/удержаний? И так после каждого обновления?

Ну, если вы обратили внимание на описание моего подхода в этом вопросе, то проблем особых здесь не возникает. Смотрите, вы запускаете расчет зарплаты в 1С77. Можно даже в монопольном режиме. При этом «семерка» выгружает в текстовом виде все необходимые данные для этого расчета. Это не займет много времени даже для больших баз, поскольку «лишних» данных здесь не будет. Бинарный 64-х разрядный (хотя может быть и 32-разрядный для адептов соответствующих ОСей) модуль, содержащий в себе (статически либо динамически) движок SQLite подхватывает эти данные и размещает их базе данных, полностью находящейся в памяти (хотя опционально можно и на диске, для тех, у кого мало памяти). Вся бизнес логика будет вынесена во внешние текстовые файлы, содержащие запросы, команды и т.п. для движка SQLite (т.е. в файлы с расширением *.sql). Эти запросы бинарный модуль обрабатывает по мере необходимости. Часть из них может работать по принципу плагинов, например, все *.sql файлы из некоторой пользовательской папки будут выполнены в определенный момент времени. Естественно, туда вы сможете кидать свои собственные алгоритмы и обращения к базе данных. Вся структура данных будет на русском языке. SQLite поддерживает это. Общая структура базы данных в 7.7 будет открыта, спецификация доступна. Если даже какое-то поле будет удаленно или переименовано, а ваш пользовательский скрипт обратиться к нему, то ничего страшного, система выдаст предупреждение, а подробности вы сможете посмотреть в журнальном логе. Буду стараться обрабатывать эти ситуации корректно, чтобы системе не валилась по пустякам. Затем полученные данные первичного расчетного журнала преобразуются в расчетном модуле во вторичный расчетный журнал, он выгружается из памяти в текстовые данные на диске, а те уже подхватываются «семеркой» и импортируются в ее собственный формат (внутренними либо внешними средствами). Текущий обмен сообщениями между двумя процессами можно будет осуществлять по любой технологии межпроцессного взаимодействия (проще всего, использовать встроенный в 1С DDE-канал).

Теперь, допустим, вы накатили такое обновление, которое слабо совместимо с вашими пользовательскими плагинами (sql-скриптами). Для корректной работы программы, нужно будет просто удалить эти файлы и затем тестировать каждый из них по отдельности, с учетом новой спецификации базы данных.

Если это для вас потенциально сложно, то тогда можете искать другую систему. Я ведь не претендую на то, чтобы нравиться всем. Предлагайте и реализуйте(!) собственный вариант, кто же против? Мне этот вариант нравиться и этого вполне достаточно, чтобы я его реализовывал.

>Типовой редактор формул покрывает 90% потребностей в написании формул. Если вам не хватает его возможностей, то никто не запрещает вам расширить его возможности. Также никто не запрещает вам дописать свои предопределенные показатели и использовать их в формулах расчета.

Этот вариант я уж лучше предоставлю вам. Вы сэкономите свои усилия по созданию независимой системы учета и гораздо быстрее получите собственный профит. Но чужие проблемы вас не должны особо интересовать, верно?
   El_Duke
 
191 - 26.10.17 - 09:25
(149) "Но теперь, когда вы все как бы знаете, ответьте на мой вопрос, как бы вы адаптировали программу для РФ под ЛНР?"

Никак.
Я не знаю соответствующего законодательства, поэтому просто не взялся бы за такое.
Единственное что могу сказать - наверное адаптировать стоит какую то украинскую типовую зарплатную конфу от 1С. Там проблем с округлением копеек по НДФЛ быть не должно. Не будучи знатоком украинских конфигураций и законодательства не стану рассуждать далее в этом направлении.

Хочу однако напомнить что вся тема началась с того типовой ЗУП "ничего не умеет от слова совсем". Теперь выясняется что это не так, речь идет об очень специфической ситуации когда требуется автоматизировать переходное законодательство и все внедрять при очень малоквалифицированных пользователях. Если бы это сразу было озвучено, то 2/3 всей дискуссии просто не было бы. Вам бы просто говорили какой вы молодец.
   kumena
 
192 - 26.10.17 - 09:57
> Пока новую версию сваяешь - ну полгода, пока обкатаешь - итого год.

год - это сильно оптимистично, я уже полгода один суммированный учет на внешке долблю.
   Emery
 
193 - 26.10.17 - 10:35
(191) > Единственное что могу сказать - наверное адаптировать стоит какую то украинскую типовую зарплатную конфу от 1С. Там проблем с округлением копеек по НДФЛ быть не должно.

С ЗУП-2.1 для Украины я и начинал, потом ЗУП-2.5 / 3.1 для России. В принципе, вопрос адаптации любой из них это просто вопрос ресурсов и стимулов. Если исходить из минимума всего, что есть у меня, то 2.1 в целом хуже, чем 2.5 (хотя, как ни странно, местами лучше), а 3.1 лучше 2.5, хотя в целом более жесткая (как говорят, не позволяет нарушать законодательство). Для нас в 2.1 самые главные проблемы, не считая глюков «толстых» форм (в 2.5 тоже самое, один в один), это расчет средних (в ЛНР они уже считаются почти как в России) и военный налог. Военный налог удалось отчасти победить (путем его обнуления в десятке мест кода, но полностью заблокировать вывод надписи с нулевой суммой в промежуточных расчетах пока нет). Со средними вопрос тоже можно частично решить, если получать промежуточные данные на стороне и импортировать в 2.1 плюс косметическое изменение кода. Из существенного остается только проблемы с отчетностью. Нужных нам отчетов там всего несколько, пальцев одной руки хватит. Мы же реально используем несколько десятков плюс формирование регламентных данных для экспорта во внешние органы. Но глюки обычных форм реально доставляют. Их зато нет в управляемых формах в 3.0 / 3.1, однако дублировать десятки отчетов в любом из ЗУПов, которые уже есть в моей «самописке» на 7.7 как-то не греет.

Пока остановился на варианте: вести первичный учет у себя, экспортировать данные в ЗУП-3.1 ради формально кадрового и управленческого учета и если эта затея не заглохнет, то дублировать там все необходимые нам отчеты и т.п. Да, код придется тоже изменять, но так, чтобы это не мешало обновлениям. Короче смысл для меня только в том, чтобы получить опыт работы с российским ЗУП, вдруг еще придется работать в России, хотя бы удаленно. А у нас внедрять ЗУП реально я особого резона не вижу. Очень мало квалифицированных пользователей и желания забесплатно работать дополнительно, как у меня, у них нет. Начальство тоже раскошеливаться особо не торопиться, так что на особо крупные успехи в этой области не рассчитываю.

> Хочу однако напомнить что вся тема началась с того типовой ЗУП "ничего не умеет от слова совсем". Теперь выясняется что это не так, речь идет об очень специфической ситуации когда требуется автоматизировать переходное законодательство и все внедрять при очень малоквалифицированных пользователях. Если бы это сразу было озвучено, то 2/3 всей дискуссии просто не было бы. Вам бы просто говорили какой вы молодец.

Думаю и дискуссия и конструктивная критика имела смысл, я стал четче понимать свои «хотелки» и возможности. А иначе, критики бояться, на форум не ходить :) .
   Emery
 
194 - 26.10.17 - 10:43
(192) > год - это сильно оптимистично, я уже полгода один суммированный учет на внешке долблю.

Я уже писал, что первую версию программы написал с нуля и внедрил за 15 месяцев. Именно на ней мы работаем уже более 10 лет. На вторую версию, ориентированную и на других пользователей, рассчитываются тоже уложиться в эти сроки. Обновление будет процентов 90.
   Злопчинский
 
Ведущий
195 - 26.10.17 - 11:58
(189) "Та же «Магазька» на «восьмерке», вроде сделана с любовью, защита прикручена как бы профессиональная, успехом пользуется баснословным, но стиль ее оформления мне совершенно не нравится"
- вот тут я к тебе присоединюсь на 100%!
.
и это - я на 8-ке не прогаю...
   Злопчинский
 
Ведущий
196 - 26.10.17 - 12:00
(192) не хотел автора в депрессию вводить.. ;-)
   AliAksA
 
197 - 26.10.17 - 12:25
(0) а не проще ли самому дописать 7-ку, чем эту ... юзать и иметь геморой с перекачкой устраивать ?

  1  2

Список тем форума
Рекламное место пустует Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует