Народ, вспомнили, что Надбавка должна быть не 3.6 процентов, а 36. Конечно вспомнили в апреле. ЗП была начислена за январь, февраль, март. И вот в  апреле решили пересчитать. Сделали кадровое перемещение с изменением процента. И программа предлагает перерасчет, не вопрос. НО проблема с теми людьми, у которых не было ещё кадровых переводов. Человек устроился в марте. В марте ему насчитали 3.6 процентов и выплатили. В апреле вспомнили, что надо 36. Заходим в Приём на работу, ставим 36, проводим и... Не предлагает программа сделать перерасчёт. Ну ни как. Хотя задним числом. Получается, что Перерасчет двигают только кадровые перемещения, а если задним числом перепровести Приём на работу, тогда как?

Хотите прикол? Такого я не видел ещё. Что делали: заходили в документ Приём на работу. Меняли надбавку на 36. Проводили. Программа 0 эмоций. Если зайти в документ, то надбавка стояла 36 процентов как положено. Что я делаю, захожу в документ, в качестве эксперимента меняю дату приёма. Надбавка становится 3.6! Сама! Меняю надбавку на 36, возвращаю на место дату приёма. Провожу и вуаля! Перерасчет зарегестрирован.
Вопрос снимается, но вот такую забавную особенность Приёма на работу я нарыл.

зарплата - перерасчет - добавить сотрудника для перерасчета

Я так понял, Приём на работу надо отменять проведение, потом менять, а потом проводить. А то хрень получается.

(4) Да, это один из вариантов. Можно и как в (2), но тогда надо указывать каждый месяц и самому определять, какие документы начисления будут основанием для пересчета.

(0) > Получается, что Перерасчет двигают только кадровые перемещения…

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

(5) Отлично, а за изменением отчетности гнаться успеваешь?

Я вот свою самописку по зарплате закрыл волевым решением, когда надоело переделывать отчеты постоянно.

(6) > Отлично, а за изменением отчетности гнаться успеваешь?

Успеваю! Я ведь не в России, а в ЛНР. У нас тут поспокойнее, если не брать линию фронта.

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

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

(7) Согласен.

Я для себя приемлемым симбиозом считаю написание проверочных отчетов к ЗУП 3.1.

Разработчики ЗУП 3.1 почему-то упускают этот момент. Иногда проверка вроде бы и есть, и неплохая, но работает на одном объекте (сотруднике). Хочешь проверить всех - запускай отчет столько раз, сколько сотрудников. А у меня клиенты от 200 до 3500 человек в базе.

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

Сейчас закрыл вопросы с проверкой НДФЛ, взносов, дни по отпуску, закрываю вопросы с расчетом среднего отпуска итп.

В целом ЗУП 3.1 рабоатет верно, но доказать это не так просто.

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

И так во всем...

такое впечатление, что очень не хватает расчета с комментарием, причем их нужно делать двух видов: сводно - на все начисление в целом, подробно - на каждого работника в расчете.

(0) Частично эта проблема закрывается просмотром показателей в документе начисления и формулой начисления.

жаль, что есть только механизм пересчетов, но нет мехазма изменения в документах (например, табельные переделали)

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

(8) ЗУП – жесткая система, рассчитанная только на законодательство РФ. И не очень прозрачна: «Прошелся отладчиком, увидел алгоритм, понял что верно.» :) . Также, даже в рамках российского законодательства, можно было бы дать пользователям больше свободы действий. А не заставлять их ломать свои бизнес-процессы через колено.

Однако в силу популярности этой программы есть смысл над ней «поработать». Например, у нас недавно приняли расчет средних почти один в один, как в России. Следовательно, типовые для Украины уже менее интересны типовых для России. Однако у вас НДФЛ округляется до рублей, а у нас до копеек. Заменил в общем модуле «УчетНДФЛ» с округления до нуля на округление до 2-х знаков после запятой. Не помогло! Сейчас вот посмотрел, оказывается еще и соответствующие реквизиты определены как целые числа. А их туева хуча. Придется исправлять.

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

> Я для себя приемлемым симбиозом считаю написание проверочных отчетов к ЗУП 3.1.

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

> Хочешь проверить всех - запускай отчет столько раз, сколько сотрудников. А у меня клиенты от 200 до 3500 человек в базе.

Да, ЗУП требует хорошей обвязки, и на уровне «пред» и на уровне «пост». Кстати, давно хочу выяснить производительность расчетов в ЗУП. Сколько времени нужно, чтобы просчитать (пересчитать), допустим, 1000 человек? У меня на это уходит порядка часа.

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

(9) > такое впечатление, что очень не хватает расчета с комментарием, причем их нужно делать двух видов: сводно - на все начисление в целом, подробно - на каждого работника в расчете.

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

(11) > жаль, что есть только механизм пересчетов, но нет мехазма изменения в документах (например, табельные переделали)

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

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

С этим я бы не согласился. Для повременной оплаты труда главным является учет рабочего времени, который отображается в табеле (кратком, подробном либо итоговом / обобщенном). И никаких там записей типа «Я 8» либо «В 5», «Н 5.5» (Нормализация данных? – Нет, не слышал!). Процесс генерации табеля может быть автоматизирован через системы учета рабочего времени, что у меня также есть, но пока еще работает автономно.

(15) // С этим я бы не согласился

Дык, разработчики типовой приняли такой концепт и очень-очень маловероятно, что теперь смогут от этого отойти в рамках ЗУП 3.х

(16) > Дык, разработчики типовой приняли такой концепт и очень-очень маловероятно, что теперь смогут от этого отойти в рамках ЗУП 3.х

На фоне того, что мне там не нравиться почти все, это не имеет особого значения. К девятой или десятой версии платформы, может быть, созреют, а так, лично мне ЗУП не конкурент. Однако понимание его изощренной логики работы даст плюс мне. Сейчас с помощью программ 1С меряют уже мощность серверов, а освоение прикладной модели ЗУПа даст прекрасный повод оценить умственное развитие программиста 1С :) .

(17) Не подумай, что я издеваюсь, но что будет с твоими клиентами, если внезапно ты впадешь в кому?

(18) "будут крутить бамбук"

(18) там вообще все что угодно может внезапно произойти, даже если с самим разработчиком будет все успешно и замечательно

(18) > … что будет с твоими клиентами, если …?

По крайней мере, хуже, чем мне на этапе внедрения не будет. Меня привлекли к «зарплате» в 2004 году. В 2005 она была разработана с нуля и внедрена. Проблемой было заполучить данные из районного вычислительного центра, где мы были на поддержке (им возили первичку, они печатали вторичку и исправляли найденные ошибки). Понятно им был жалко терять такого хорошего клиента, а может быть просто хотели сшибить бабосы напоследок. Как бы там ни было, чтобы забрать данные за последний год (ради расчета средних и просто сравнительного расчета) нам пришлось привлекать спецслужбы. Данные мы забрали, хотя конвертировать их на мою программу было проблематично (совершенно другая концепция учета, у меня дифференцированная, у них интегрированная). Некоторые виды расчета так и остались нерасшифрованными, например, ВидРасч161, а лишний раз с ними связываться уже не хотелось.

Теперь смотрим, любой программист, не забывший, что такое «семерка» имеет хорошие данные и открытый для него код. Даже без кода иметь такие данные для меня было бы счастьем. Код, скорее всего, другому программисту не понравится (по принципу, все, что написано не мной – плохо :) !). Но, по крайней мере, программа работающая. Даже операторы, несколько месяцев, вполне потянут ее без меня. До первого серьезного изменения в законодательстве, которое, когда оно будет, никто не знает. В любом случае, типовых «зарплат» для ЛНР / ДНР нет, все, что есть это в той или иной мере самописки.

При этом я работаю над открытой версией своей программы, которую собираюсь выложить в Интернет. Если бы меня так спонсировали, как в первом случае, вторая версия была бы уже давно опубликована, а так хочется / не хочется, лучше я на Си++ что-нибудь поваяю ради удовольствия.