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

Дело в том, что к тому моменту я три года проработал на разработке и поддержке зарплатных систем на Foxpro, и уже имел то, что называют "насмотренностью". У меня уже было глубокое понимание особенностей зарплатных расчетов Украины и России - как брать базу для различных типов налогов, какие расчеты с удержаниями друг друга вытесняют, какие алгоритмы расчета отпускных и больничных (забавно, что в 00х для РФ больничные считали по правилам украинских отпусков, а отпускные по правилам украинских больничных). А так же я знал про регулярные изменения законодательства, когда внезапно на правительственных ресурсах публикуют, что в прямо сейчас ты считаешь некое начисление по старинке, а с нового месяца уже по обновленным правилам; при чем, если нужно будет кому-то доначислить за прошлый период, то все еще старая формула; но одновременно сохраняется преемственность и в зарплатных ведомостях все суммы должны проходить по единому "итого".

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

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

Я не мог понять "зачем?". Одно дело оперировать с общепринятыми в международном делопроизводстве концепциями "справочников" и "документов" (но и тут не все однозначно, тот же "договор" мог быть реализован по разному), но совсем другая история, когда в платформу затягивают кусок локального "изменчивого" законодательства. Когда я только знакомился с 1С 8.0, у меня сложилось ощущение, что компании 1С именно этот кусок придётся поддерживать тщательнее всего. Ведь его будут поддерживать тщательно? Ведь его будут поддерживать? Ау, есть тут кто..?

Так вышло, что в мире конфигураций 1С сейчас есть два монстра: 1) Документооборот, который героически на костылях расширяет возможности недоработанных бизнес-процессов, и 2) ЗУП, который точно так же героически на костылях пытается дать максимально понятный пользовательский опыт. И это в то время, когда платформа настолько зрела, что новые документы и отчеты создаются буквально накликиванием мышкой за считанные минуты, после чего довольные пользователи сразу их используют ☝️

#1c #зарплата #критика