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

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

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-соединение.

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

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

(0) цель поста какая?
Не могу представить что такое можно сделать на клюшках чего не потянет снеговик

А почему именно 77? Есть уверенность, что найдутся клиенты, желающие приобрести еще и 77?

(3) а она разве просто так продается? Может тогда уж Delphi-2?

В качестве фреймворка

лучше в Акцесс :)

(0) Это странно.

(2) > цель поста какая?

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

> Не могу представить что такое можно сделать на клюшках чего не потянет снеговик

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

(7) Это продолжение темы ЗУП 3.1 Начисление доплаты до МРОТ

Там было много интересного, но автор предлагаемой методики перестал заходить в нее, а вопросы остались ...

> А почему именно 77? Есть уверенность, что найдутся клиенты, желающие приобрести еще и 77?

Интересно, а есть статистика по отношению «семерки» к «восьмерке»? Я думаю, что у нас это процентов 80, а в России пусть даже 20, что тоже как бы не мало. Это раз. Далее, сейчас «семерка» используется для скорости кодирования, так как опыта там больше. Но в принципе ничто не мешает переписать поделку и под 8.х, это два.

(4) > а она разве просто так продается?

Продается! Смотрел недавно на сайте 1С. Хотя требуют обоснования.

> Может тогда уж Delphi-2?
> В качестве фреймворка

Работал в свое время на Object Professional - 1.2. Скажем так, С / С++ мне нравится больше.

(6) > лучше в Акцесс :)

Лучше уж в Qt c SQLite’ом.

(9) > а вопросы остались ...

Как по мне, для сложного учета ЗУП не слишком удобен. Другое дело, вести внешний учет и выгружать первичные данные в ЗУП ради построения регламентированной отчетности.

(13) Пошел за попкорном :)

(8) > В ЗУПе нет нормального учета рабочего времени

конкретизируй чего именно нет

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

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

Вот собственно и вся вилка выбора

(11) Обосновать новыми поделками не удастся

(15) > конкретизируй чего именно нет

Нет первого, второго, седьмого и шестнадцатого! Легче уж описать, что есть. Тебе этого достаточно? Мне нет! На скринах видно, какой учет рабочего времени я хочу видеть. Причем показано только очень малая часть того, что есть. А сколько еще предстоит сделать в этом направлении.

(13) придумывать лишние сущности без крайней надобность - ЗЛО!!!
ну хотите отдельно - прикрутите ну пусть свою подсистему, будет просто ми-ми-ми

(0) Вот примерно такой лютый пи@дец был у нас. До 77 конечно дело не дошло, реализовали на 8.2 в ЗУП 2.5, но от этого менее лютым он не был)))

(20) Был? Уже не используете?

(16)  > Но как только вы перейдете на другую работу - велик шанс что все встанет колом.

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

> В тоже время учет раб. времени штатными средствами ЗУП вполне возможен (наверное для вашего конкретного случая менее удобен, не более того).

Вот именно, что только «возможен». А у меня не специфичное, а вполне типичное предприятие.

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

Ну, ну. Да сама Елена Грянина не вполне понимает смысла табелей. Её слова: «Табель рабочего времени не нужен. НЕ НУЖЕН!!! Вот введу сюда данные, НЕ ЗНАЮ, ПРАВДА, ЗАЧЕМ? ...».

На курсах обучают пользователей стандартным алгоритмам действий. Весь учет демонстрационный. Грянина показывает ДЕМО-учет. Гилев тоже учит ДЕМО-учету. Все демонстрируют, как приспосабливаться к ЗУПу. А надо, как ЗУП приспособить к себе. Если мне бухи говорят, что твоя программа не делает то или не так быстро как хотелось бы, то я иду и исправляю свою программу, а не говорю им – меняйте свои бизнес-процессы.

> Вот собственно и вся вилка выбора

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

(21) Написали свой, с преферансом и поэтессами.

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

(22) На какие предприятия рассчитана эта система и на какое количество сотрудников и подразделений?

(19) > придумывать лишние сущности без крайней надобность - ЗЛО!!!

Здесь необходимость вполне себе крайняя. У вас лично производственное предприятие или просто офис?

> ну хотите отдельно - прикрутите ну пусть свою подсистему, будет просто ми-ми-ми

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

(20) > Вот примерно такой лютый пи@дец был у нас. До 77 конечно дело не дошло, реализовали на 8.2 в ЗУП 2.5, но от этого менее лютым он не был)))

А в переводе на русский, как будет звучать?

(26)имел я в виду лоскутную автоматизацию! Просто зае...ла уже в край к хренам!

(23)Не понял. У вас был "лютый пи@дец" с табельным учетом написанный кем-то. И вы вместо него написали свой "лютый пи@дец"?
Те же яица вид сбоку? Только еще с преферансом и поэтессами?

Я делал в своё время нечто похожее

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

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

ЗЫ. у меня было 2500 сотров.. И если ввалить все ТабУры по всей массе работников, да в этой куче-малой сам черт не разобрался-бы..

+(30) И если ввалить все ТабУры по всей массе работников, и сгенерировать документы...

(24) > Не хочется по новой заводить карусель из прошлой темы, тем более что там все остановилось на середине.

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

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

http://www.ittex.ru/Automatization/b_Katalog_1C/HomeProduct1.php?ELEMENT_ID=194&BACK=99#remote-tab-2

(32) "Когда все завершено, то какой смысл в дискуссии?"

Вот именно, когда завершено. А там не ответили на очень много вопросов.

"ЗУП можно и нужно концептуально улучшать"

Бесспорно, полностью согласен.

"Вообще, наверное, надо опубликовать свою концепцию зарплаты в явном виде"

Не обижайтесь, но напомнило анекдот про собрание в колхозе, где на повестке дня было 2 вопроса:
1) Постройка сарая
") Построение коммунизма

(25) > На какие предприятия рассчитана эта система и на какое количество сотрудников и подразделений?

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

Количество сотрудников не ограниченно. Тысячу первая версия считает за час. Но там только фактический учет рабочего времени, но нет планового. Ну а, скажем, десять тысяч сотрудников не должны быть принципиальным препятствием. Смысл в том, что бы пользователю как можно меньше делать телодвижений. Ничего не должно быть лишнего. В терминалке «семерка» может поддерживать достаточно много пользователей.

Бе<b>с</b>платный отпуск

(0) блин забыл как тут выделять шрифт. отпуск Бесплатный, а не Безплатный.

(30) > Поскольку это отчет - то все документы, введенные кадровиками и расчетчиками, отражались в нём, и в отделах оставалось только проверить, внести исправления и подписать.

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

> Но обратная процедура - по табур восстановить все документы по расчету зарплаты - это нонсенс..

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

По вторичным данным вполне уже можно делать всю необходимую отчетность, в т.ч. внешнюю.

> Конфликтов в БД будет немерено, и исправлять документы расчетчикам не будет времени. Проклянут программу, если инфаркт не хватит..

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

> ЗЫ. у меня было 2500 сотров.. И если ввалить все ТабУры по всей массе работников, да в этой куче-малой сам черт не разобрался-бы..

У меня ведь не используются объекты «Документ» или там «Журнал документов». Собственно документы я строю на справочниках. А они в 1С – ИЕРАРХИЧЕСКИЕ! Уже за одно это я люблю 1С! Выгоду это дает сплошь и рядом. А использование внешнего движка SQLite для расчетов в зарплате, сводит на нет проблемы движка БД «семерки». К тому же в SQLite’е можно поля, имена таблиц и файлов БД писать по-русски, даже с пробелами (но в квадратных скобках). А памяти такая база данных просто летает как дурная :) .

А не проще ли без отклонений?
Заполнить с начала месяца табель данными из графиков работы и производственного календаря, а потом пусть рисуют "отклонения"? Зачем городится это все?

(18) в ЗУПе можно сделать сколько угодно своих графиков работ

(38) Ну, что-ж.. успеха тебе.
Для меня это 10 лет назад было, так что быльём поросло.
Разговоров было много по поводу, и в кадрах, и с расчетчиками, и с цеховыми.. Вариант, что я описал, был согласован со всеми.

Где-то в инфостартовских анналах валяется мой отчет.. Но он - для ЗиК-7.7

(34) > Не обижайтесь, но напомнило анекдот про собрание в колхозе, где на повестке дня было 2 вопроса:

А чё обижаться, я сам люблю юмор. Но если бы кто-то в явном виде, без воды, опубликовал бы свою «концепцию зарплаты», то с удовольствием почитал бы. А уж 1С-овцы это должны были бы сделать по умолчанию. Вопросов по работе ЗУП могло бы быть меньше.

(39) > А не проще ли без отклонений?

Так учет отклонений ведется при нажатии соответствующей кнопки (рис. 1). Не нажимайте ее и будет вам счастье :) . Но чтобы строить полные табеля на подпись, нужно показывать все.

> Заполнить с начала месяца табель данными из графиков работы и производственного календаря, а потом пусть рисуют "отклонения"? Зачем городится это все?

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

(42) >>Но если бы кто-то в явном виде, без воды, опубликовал бы свою «концепцию зарплаты»
Сколько предприятий, столько и концепций. Обобщенная концепция реализована в ЗУПе, но она тебя не устраивает, концепция какого-то другого предприятия тоже вам скорей всего не подойдет. Даже если кто-то опишет концепцию в точности такого же предприятия как у вас, наверняка будут какие-то моменты, которые не впишутся в вашу концепцию.

(42) вот моя концепция
http://www.consultant.ru/document/cons_doc_LAW_34683/

(40) > в ЗУПе можно сделать сколько угодно своих графиков работ

И что из этого?

(46) ты же указал, что это проблема

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

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

(40) > Где-то в инфостартовских анналах валяется мой отчет.. Но он - для ЗиК-7.7

Я могу кратко рассказать свою историю. Когда меня наняли на внедрение ЗиК-7.7 для Украины я очень быстро пришел к мнению, что это совершенно не то, что нам нужно. Наш новый главбух рассказывала, что на ее старой работе трое программистов изменяли, в течение двух лет, 80% кода в ЗиКе. Но я этого тогда не знал и решил написать 100%-но свою «зарплату». Кстати, мой друг сделал тоже самое, но на Акцесс-97.

Через три месяца моя программа уже делала первые примитивные расчеты. Еще не было никаких отчетов, но «семерка» оказалась настолько эффективной, как система быстрой разработки, что я ею восхищаюсь до сих пор. До этого я три года делал зарплату на FoxPro-2.6a в ДОСе, но так и не привел ее в божий вид. А на семерке моя конфигурация «взлетела». Еще через год она стала рабочей программой, и мы наконец-то слезли с районного вычислительно центра, где зарплата обсчитывалась (из рук вон плохо) до этого.

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

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

Потом ещё для фактического времени можно прикрутить счетчик прихода-ухода сотрудников на основе смарт-карты или биометрический - и тогда вообще будет полная автоматизация)

(44) > Сколько предприятий, столько и концепций.

Мы, наверное, по-разному понимаем термины. Концепция для меня, в данном случае, это описание обобщенного алгоритма работы программы по учету и расчету заработной платы на сложном производственном предприятии. Далеко не на всех предприятиях программисты пишут 100%-но собственные программы по «зарплате». Поэтому предприятий может быть много, а концепций мало.

> Обобщенная концепция реализована в ЗУПе,

Реализована, но не опубликована. Хотя подобный документ наверняка есть в недрах фирмы 1С. Интересно, кто ее автор?

> но она тебя не устраивает,

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

> концепция какого-то другого предприятия тоже вам скорей всего не подойдет.

Наверное, да, чтобы мы не понимали под этим словом. Именно поэтому я, скорее всего, опубликую свою.

> Даже если кто-то опишет концепцию в точности такого же предприятия как у вас,

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

> наверняка будут какие-то моменты, которые не впишутся в вашу концепцию.

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

(45) > вот моя концепция

Это описывает «что», но не описывает «как».

(52) Ну тогда непонятно, что вообще в данном случае понимается под концепцией...

(47) > ты же указал, что это проблема

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

(48) > Попробуй посмотреть на проблему не со стороны табеля, а со стороны сотрудника. Ну то есть в конечном итоге для каждого сотра нужно каким-то образом указать когда и сколько он отработал и совершенно по барабану всякие там наложения совмещения и прочая хрень. С точки зрения учета есть сотрудник и его отработанное время.

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

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

В ЗУПе жесткий учет, а мне нужен гибкий. У него документы и журналы плоские, а мне нужны иерархические. Кстати, у меня расчетный журнал для SQLite'а тоже будет плоский, как классический журнал элементарных операций, но его результаты будут загружаться назад в 1С в иерархические справочники. А демонстрировать плоский журнал расчетов пользователям это, на мой взгляд, очень неправильно.

(49) > "а если у вас в месяце было три периода работы по разным сменам" то делается индивидуальный табель

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

> Ты фактически делаешь тоже самое, только в сторонней программе.

А что делать, если разрабы типовых считают себя слишком умными и заставляют всех «изменять свои бизнес-процессы» и вписываться в именно их «прокрустово ложе»?

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

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

(55) пример приведи, когда нужна иерархия

(51) > Я делал отдельным документом в ЗУПе документ из трех ТЧ: Плановый, фактический и регламентный. Заполнялся полуавтоматом, и в итоге данные из этого документа переносились в регламентированный и документы премий и надбавок.

Если вас это устраивает, то прекрасно. Меня документы-объекты не устраивают именно в силу своей «плоскости». Зачем ими пользоваться, когда есть иерархические справочники, которые к тому же могут быть подчиненными? 1С поддерживает классические четыре вида отношений между таблицами (справочниками): Один к одному; Один ко многим; Многие к одному и Многие ко многим. Плюс супер важное свойство – иерархичность данных. Ну что еще нужно для полного счастья? А документы это что? Возврат в прошлое, в смысле реализации объекта.

> Потом ещё для фактического времени можно прикрутить счетчик прихода-ухода сотрудников на основе смарт-карты или биометрический - и тогда вообще будет полная автоматизация)

А отклонения как будем учитывать?

(54) > Ну тогда непонятно, что вообще в данном случае понимается под концепцией...

Описание обобщенного алгоритма программы.

(58) > пример приведи, когда нужна иерархия

Специально для тебя выгрузил скрины:

http://emery-emerald.narod.ru/Pics/Pic5.png
http://emery-emerald.narod.ru/Pics/Pic6.png
http://emery-emerald.narod.ru/Pics/Pic7.png
http://emery-emerald.narod.ru/Pics/Pic8.png

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

Ничеготне понял что такое иерархический табель и для чего он нужен

(61) лол, хранить период в наименовании группы, рукалицо

(61) и что?
Какую задачу решает такая иерархия (а по сути группировка) отображения наборов табелей?
Зачем она?

Табеля в справочнике?

Чем это лучше - условно -
Табеля в виде документа где в шапке указан отчетный год и отчетный месяц?
Как в твоём представлении быстро отобрать все табели за все сентября? В варианте дока - двумя клипами типовой отбор

(60) Общего алгоритма чего?
Расчета начислений/удержаний?
или расчета отработанного времени?
или еще какой-то алгоритм?
Если ты имел ввиду бизнес-процесс начисления з/п, то он везде выглядит одинаково:
1. Заполнение НСИ
2. Ввод первичных документов(начисления/удержания, отпускные, больничные и т.д.)
3. Расчет
4. Формирование отчетности

(62) > Ничеготне понял что такое иерархический табель и для чего он нужен

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

Кроме лицевых счетов иерархичными у меня могут быть любые документы. Особенно ярко это было выражено в моем учете ресурсов.

(68) Сознайся, тебе просто нравится кодить :)

(63) > лол, хранить период в наименовании группы, рукалицо

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

(61) А открой пожалуйста секрет, зачем в табеле нужна расценка и сумма?
Это уже какбэ не совсем табель получается.
Я бы даже сказал совсем не табель, а некая расчетная ведомость.

(68) Ну и что ?
Чем это лучше индивидуального графика или табеля ?

(64) > и что?

Был вопрос и был ответ.

> Какую задачу решает такая иерархия (а по сути группировка) отображения наборов табелей?

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

> Зачем она?

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

(72) На сколько я понял это не совсем табели. Это больше похоже на расчетные листки и похоже по ним-то и строится вся отчетность. Для этого собсно и нужна удобная навигация, которой так гордится ТС. Вообще есть некоторое изящество в таком решении.
(73) Я угадал?

64) > Табеля в виде документа где в шапке указан отчетный год и отчетный месяц?

Не совсем понял, все нужные отчеты у меня есть. Здесь проблем нет.

> Как в твоём представлении быстро отобрать все табели за все сентября? В варианте дока - двумя клипами типовой отбор

Эта структура покрывает 99% реальных потребностей пользователей. Нестандартные запросы я могу сделать внешним образом, с помощью запросов на VFP (который работает в 15 раз быстрее встроенного движка «семерки»), либо указать в обработке для построения отчетов в списке групп данных соответствующий перечень групп, по которым нужно вести отбор.

(67) Общего алгоритма чего?

Правильные вопросы! Точнее будет описать структуру базы данных и способы работы с этой структурой. Собственно алгоритмы будут уже на втором плане, что не понижает их важности.

(69) > Сознайся, тебе просто нравится кодить :)

Зарплату мне получать тоже нравится :) . И иметь минимум нареканий от руководства и пользователей.

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

в общем табель есть смысл создавать, когда там какие-то ручные правки идут по ситуациям, которые нельзя разрулить доками отклонений. если удалось все внести отклонениями табель и не нужен, о чем и говорила Грянина

(71) > А открой пожалуйста секрет, зачем в табеле нужна расценка и сумма?

Слово (вторичный) «табель» сохранилось по аналогии от первичных табелей (рапортов). Туда, к собственно документам табельной, ОТиЗ добавлял свои расценки и прочее.

> Это уже какбэ не совсем табель получается.

Согласен! Во второй версии название будет другое: «Вторичный расчетный журнал».

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

Точнее, это подробные лицевые счета сотрудников. У нас они называются «табульки».

(74) Изящество может и есть, но как написал в начале это может дорого обойтись предприятию.

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

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

(72) > Чем это лучше индивидуального графика или табеля ?

Я уже отвечал, они плоские, а мне нравится работать с иерархическими. Другим словами, гибкости у меня больше.

(76) >>Точнее будет описать структуру базы данных и способы работы с этой структурой.
Если все это описать то Елена Грянина останется без работы, ибо каждый сможет прочитать как оно внутри там устроено и понять как этим можно пользоваться :)

(80) Ну все так и есть. Это утверждение справедливо для любой самописки.

(74) > На сколько я понял это не совсем табели. Это больше похоже на расчетные листки и похоже по ним-то и строится вся отчетность.

Да, это подробные лицевые счета сотрудников, название к которому мы давно привыкли, а вам режет слух. Во второй версии изменим :) .

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

> Для этого собсно и нужна удобная навигация, которой так гордится ТС. Вообще есть некоторое изящество в таком решении.

Однако все можно улучшить. Жалею, что не занялся этим раньше.

> Я угадал?

Похоже, что так :) .

(81) Вот это вообще не ответ
Что значит плоские ? Что нельзя с их помощью сделать такого, что потребовалась такая самописка

Не, я отдаю должное кодерскому мастерству, с этой стороны все даже очень круто. Но зачем оно все ???

(84) прям перед глазами стоит, запускается обработка, и в строке статуса Обрабатывается Сотрудник Иванов, потом статично Год, месяц, бежит мелькая день, меняется сотрудник. Запросы запрещены из-за тупой организации "на именах справочников", расчет не прозрачен из-за "эскуэльлайт компоненты х64". Увольнение расчетчика в связи с выходом на пенсию повод для суицида. Поиск ошибки просто невозможен т.к. нет никакой хронологии единой и вообще временной шкалы. Жестокий убийца ЗИК

(86) 1Сник может навалить кучу на стол генеральному и ему ничего не будет

(78) > в общем табель есть смысл создавать, когда там какие-то ручные правки идут по ситуациям, которые нельзя разрулить доками отклонений. если удалось все внести отклонениями табель и не нужен, о чем и говорила Грянина

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

(88) Это не её модель, это типовая методика. Учите матчасть

Методики учета

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

Метод отклонений  —  расчет времени выполняется на основании периодов отклонений от нормального графика работы. Фактически использованное время рассчитывается исходя из нормы времени, зафиксированной в общем графике работы учреждения или в индивидуальном графике работы сотрудника с учетом всех отклонений от этого графика, введенных различными документами (по причине отпуска, болезни, командировки и т. п.).
Метод сплошной регистрации  —  наряду с регистрацией документов-отклонений ведется регистрация фактически использованного времени путем ввода таких первичных документов, как Табель учета рабочего времени
http://v8.1c.ru/budghrm/test/wt.htm

(88) >>Грянина исходит из собственной модели учета...
Это не собственная модель, это как раз концепция.
Есть основной график, который отражает основное отработанное время и есть корректировки этого основного времени и неважно, что корректировки могут вытеснять все 100%  основного времени.

(80) > Без него предприятию песец, всех за яйки держит железной рукой

Все имеет свою цену. Скорее всего, предприятие пригласит кого-нибудь со стороны, ну хотя бы тех трех программистов, что два года меняли 80% ЗиКа. Заплатит им приличную цену, но смешную по российским меркам, несколько месяцев посчитает вручную в экселе или даже на калькуляторе, пусть даже с большими ошибками (потом пересчитают). С большим стрессом и потерей в деньгах справятся, но так, чтобы фирма полностью остановилась, это вряд ли. Мы тоже в стрессе съезжали с чужих программ, но съехали ведь. Так что, как говорил Владимир Путин на Валдае: «будут скучать», но не сильно более.

(76) > Если все это описать то Елена Грянина останется без работы, ибо каждый сможет прочитать как оно внутри там устроено и понять как этим можно пользоваться :)

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

(68) так и непонятно зачем это? Чтобы быстро визуально навигацию делать?

(85) > Вот это вообще не ответ

Вы учет на сложных производственных предприятиях вели? Если нет, то трудно будет добавить что-то новое, сверх того, что я уже говорил.

Вот недавно ко мне друг приезжал из России (тот который делал одновременно со мной зарплату на Акцессе-97). Он там хорошо устроился. В их компании порядка 18 тысяч человек. Зарплату они считают на программе, которую, по его словам: «ты не найдешь в Интернете». Хотя программу делала фирма. От ЗУПа там все открещиваются всеми имеющимися руками и ногами, хотя начальство сильно настаивает. Что меня удивило, так это время расчета – трое с половиной суток!

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

(86) Вас случайно звать не Стивен Кинг? Ужастики описаны похлеще, чем у него. На самом деле «бывает и хуже, но реже»

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

(93) > так и непонятно зачем это? Чтобы быстро визуально навигацию делать?

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

(96) > не надо изображать универсальность решения, ценность этого за проходной около 0.

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

> Отсутствие разреза времени источник произвола и бесконтрольности в учете

А вот здесь хотелось бы услышать поподробнее.

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

(99) > автоматизировали табель? ну и хорошо, задача решена.

Как раз эта задача еще не решена. Так же как и вторая версия еще не закончена.

> За две темы Вы раз 100 ушли от любой конкретики по ЗИК ЗУП,

Какие две темы? Одна тут, а МРОТ это была не моя тема, я там выступал только в комментариях, как и вы здесь. ЗиК я не особо затрагивал, разве что вскользь упоминал, но он не был серьезной темой для меня. По ЗУП я приводил конкретные примеры, на которых был затык. Например, невозможность безболезненно разделить вид учета «оплата выходных и праздничных дней» на 8(!) подвидов (дополнительные критерии: по графику / не по графику и оплата / доплата) и объединить все вечерние в один вид и все ночные в один вид. В расчете средних, чтобы снять блокировки на вхождаемость видов, нужно было лезть в код и там менять. Нельзя было совместить пересекающиеся графики (индивидуальные не предлагать) и все такое прочее. Куда уж конкретней? Были и нюансы, важные для нас, связанные с проблемой отмены округления НДФЛ до рубля. А то, что нужных отчетов в ЗУПе раз, два и обчелся (не считая управленческих и регламентированных, которые для нас не актуальны) я тоже говорил. Так что, о каком уходе «от любой конкретики»  вы говорите, я совершенно не понимаю.

> и раз 100 обругали,

Разве? Я полагал это дружеской критикой. Жестковатая программа, да, но не самая худшая из тех которые я видел.

> уходя в бизнес процессы у знакомых.

Я бы на этом вообще не заострял внимание, просто пример к слову не более.

> При том что не смогли посмотреть, как в табеле обозначить явки и отпуска,

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

> приплели какие то технологии, завели внешнюю базенку

Ну, это уже эмоции, возражать в подобном стиле не хочется.

> Поподробнее уже не интересно,

Ну неинтересно, не пишите, у нас демократия.

> вполне вероятно, что Вы длл на делфи устраиваете

Делфи не использую, об этом уже писал. Предпочитаю С / С++. Но в первой версии он еще нигде не применяется, только Visual FoxPro, как внешнее приложение. Во второй вместо VFP будет С / С++, совместно с кодом SQLite, скомпилированный MinGW-64. А там имена полей таблиц и самих таблиц будут на русском языке, что заранее радует.

"перепроведение" на справочниках непосредственным удалением

Проведение у меня это просто запись / перезапись в подчиненные справочники. Естественно, что отмена проведения, пометит свои записи на удаление. Какие вы видите в этом проблемы? Хотя могу ограничится только внешним журналом расчетов на SQLite. Здесь еще возможны варианты. Процесс ведь не закончен.

В общем, я откровенно говоря, удивлен вашим наездом.

(0) Зачем вообще столько ресурсов тратить на учет рабочего времени? Зачем 8 подвидов оплат выходных и праздничных дней? В чем от этого польза для бизнеса?

ИМХО. Кроме ЗИК 7.7 и ЗУП 2.5 и ЗУП 3.1 в природе существует Каминовская конфигурация. Камин? Ну это те ребятта которые в своё время зарплату для 7.7 делали на компоненте бухгалтерский учет. Вообще по своему опыту соприкосновения с расчетчиками я пришёл к выводу что сколько расчетчиков столько и мнений. Добавьте ещё письма с толкованиями из налоговой и всяческих фондов. Говорите что Гарянина и Гилёв учат демо учёту? Хрень всё это. Любой учёт вне специфики нашего предприятия демо. Так что кто бы что Вам не показывал для Вас это будет демо, а не то что Вы хотите. Исключение тут пожалуй будет если Вам будут показывать внедренцы на ваших данных. Допилить тот же ЗУП до специфики конкретного предприятия стоит. Проблема в том что допилив нельзя останавливаться из-за изменений мнений расчетчиков, управленцев и законодательства. Говорите расчет зарплаты на 8000 сотрудников? Это копейки. Кроме переводов конкретных предприятий с ЗИК на ЗУП и с Каминовской семёрошной Зарплаты  я так же как то писал свой кусочек зарплаты. Только там требования были со стороны пользователя к юзабилити. У меня графики работы вводились в табличном документе в режиме ввода данных и в рамках одного подразделения пользователь, введя график скажем по одному сотруднику, отключал защиту у табличного документа дабы прокопировать как в екселе значения ячеек между работниками. Потом включалась защита табличного документа и по щелчку на служебной ячейке все расставленные часы втягивались в табличную часть документа. В вашем случае это было бы автоматическое заполнение справочника. Роли не играет. Так же я участвовал во внедрении ЗУП в ФГУп Почта России. Там 13 тымсяч было, только не тринадцать тысяч расчитываемых сотруудников, а тринадцать тысяч рабочих мест. И да. Там был ЗУП взятый за основу.

Про Почту России по понятным причинам я рассказывать ничего Вам не буду, но по своему опыту успешных мои внедрений скажу - Для минимизации накладных расходов на перенос доработок и перепиливание БД под требования законодательства ставится неизменный и неизменяемый управленческий контур с возможностью учета всяческих параметров типа прибыли и себестоимости и он обменивается с внешним регламентированным контуром. Внешний регламентированный контур безболезнено обновляется. В успешных внедрениях у меня таким образом несколько небольших фирм которые до сих пор работают на приятной управленцам 1С 7.7 Торговля и склад редакции 8.7. Обновления затрагивают только отдельно стоящую Бухгалтерию и то не всегда. Расходы на 1С мизерные и касаются только доработки внешних печатных форм типа счета фактуры

Нашёл свою старую ветку про табель
Выложил на суд кусок конфигурации Табель

11 лет прошло

(101) Если бы у рыбы была шерсть, то у неё были бы блохи, а блохи подразделяются....

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

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

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

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

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

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

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

(0) Если слить все воду, то получается, что главный недостаток ЗУПа - то, что он написан не вами и не укладывается в ваше мироздание.

(107) Слово "НАДО" улыбнуло и принесло отличное утренние настроение. Спасибо.

(107) >>Отчасти потому, что так хотят бухи.
Половина хотелок бухов от неграмотности. А разный ФОТ скорей всего не у подвидов оплаты, а у видов работ, оплата которых выполняется этими подвидами. Появятся у вас еще какие-то работы с отдельным ФОТ, еще 8 подвидов оплаты наплодите?
Сделайте уже аналитический признак к виду оплаты и не плодите сущности.

(102) > ИМХО. Кроме ЗИК 7.7 и ЗУП 2.5 и ЗУП 3.1 в природе существует Каминовская конфигурация. Камин? Ну это те ребятта которые в своё время зарплату для 7.7 делали на компоненте бухгалтерский учет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Очень важное требование, как на мой взгляд.

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

Ну, поскольку я иду не этим путем, то пока для меня не особо актуально.

(108) > Если слить все воду, то получается, что главный недостаток ЗУПа - то, что он написан не вами и не укладывается в ваше мироздание.

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

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

(107) "Если какая-та модель охватывает 95-99% процентов всех случаев, а для вас актуальны оставшиеся 1-5%, то аргументы, что вы должны прогибаться под типовой вариант почему-то плохо воспринимаются."

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

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

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

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

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

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

Ффффатит, у меня монитор уже зажироточил!

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

Стопудово проблема не в разном ФОТе, а в разном месте возникновения затрат (МВЗ) или шифре производственных затрат (МВЗ). Наверняка тетенька, которая требует 8 подвидов оплат потом переписывает итоговую цифру по виду оплаты из свода начислений/удержаний в какой-нить экономический отчетик в экселе.
Я бы на месте ТС поинтересовался этим вопросом.

+ (116) А внятно объяснить они не могут потому что понимают, что как только они дадут такое пояснение, вся их ручная работа по сборке "мегаважного" отчета будет моментально автоматизирована, либо выяснится, что этот отчет нарен никому не нужен и тетенька остнется не у дел.

Чего ты так впилился в эту иерархичность данных? Какая от неё польза - конкретного ответа кроме как удобно по папочкам разложено - не прозвучало. Поэтому плевок в сторону документов об отсутствии иерархичности - против ветра

Ты вот эту свою ветку на Кубани выложи. Там зарплатный народ активно тусуется - будет гораздо интереснее/полезнее

(107) Ну как я и думал, это просто дурная работа ради работы.

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

(104) > Нашёл свою старую ветку про табель
> Выложил на суд кусок конфигурации Табель

Интересно, но разбираться с программой без данных и основных скринов скучновато. Это лишний раз доказывает, что когда я выложу свою поделку в общее пользование, надо будет сначала показать ее работу в картинках, а потом уже предоставить версию с реально-подобными данными.

(110) > Половина хотелок бухов от неграмотности.

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

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

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

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

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

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

Этот принцип противоречит утверждению «клиент всегда прав». Поэтому останемся при своих мнениях.

только написал, что табель не нужен и обнаружилося такой баг - у сотрудника (уже человек 6 таких нашли) за первую половину месяца 0 отработннных дне (отпуск, больничный, невыход), в расчете за первую половину месяца считает 1 рабочий день. Если сформировать на сотрудника табель по данным документам отклонений- начинает считать нормально за первую половину месяца. 3.1 последний релиз, сталкивался кто? по регистрам нигде не вижу, чтобы этот рабочий день где-то отдельно выделялся. такое впечатление, что игнорится невыход. Получается очень странная ситуация - алгоритм сбора табеля по данным отклонений и алгоритм сбора расчета за первую половину месяца по учетам отклонений - работают по-разному (

лазить отладчиком по 3.1 тот еще ад... 15 переходов между разными модулями только чтобы получить выполнение одной строки кода - это для них норма

в РН данные оперативного учета рабочего времени сотрудников Отпуск неоплачиваемый с разрешения работодателя делает движения, только если это внутрисменная неявка. если отсутствие полный день - движений нет. Это так и задумано было?

ща отдельную тему создам под это

ЗУП 3.1.3 - расчет за первую половину месяца сори что тут нафлудил

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, наверное, тогда меньше вопросов бы задавали коллегам, фигаля там этот программист делает, когда и так все работает. Собственники и руководство («круговорот олигархов в природе») у нас все новые и меня еще плохо знают, так что «не позволили бы», это не к ним. Кстати, это уже третья группа собственников на моей памяти. У первых двух не было проблем со мной, почему должны быть у третьей? Так, что логично, по-моему, уже съехать с этой темы, тем более что я высказывался по ней уже не раз.

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

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

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

(118) > Чего ты так впилился в эту иерархичность данных? Какая от неё польза - конкретного ответа кроме как удобно по папочкам разложено - не прозвучало.

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

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

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

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

(119) > Ты вот эту свою ветку на Кубани выложи. Там зарплатный народ активно тусуется - будет гораздо интереснее/полезнее

Наоборот, я вот уже думаю, наверное, надо было бы опубликовать тему на форуме sql.ru. Там народ более пассивный, чем здесь, а я уже притомился отвечать, на основную работу времени не остается. Но, как говориться, «взялся за гуж, не говори, что не дюж». Сам не люблю, когда авторы создают тему, а потому по-быстрому сваливают с нее. Все очень просто, перестанут спрашивать, перестану отвечать.

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

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

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

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

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

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

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

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

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

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

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

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

(0) Изучай ЗУП 3.1. Узнаешь много интересного и полезного для себя. Версию КОРП тоже глянь.
Не зря сейчас появляются позиции в вакансиях - программист-консультант. То есть быть хорошим программистом уже недостаточно. Нужны специалисты со знанием методик учета в типовых конфигурациях.
У нас среднее предприятие. ЗУП 3.1 решает 98% всех проблем по взаиморасчетам с сотрудниками.

(131) все понятно и все нормально.
Чужие программы г..о , моя - лучше. Потому что моя.
Это нормально.
В чужом разбираться и выкручивать под свои нужды - всегда поначалу тяжелее.
Но писать свой велосипед когда есть промышленные образцы - в целом путь в никуда. В частностях - да, кое где свой удобнее, что хочу то и навешаю - хоть багажник, хоть спутниковую антенну.
Но это все фигня. Ровно до того момента пока жив самоделкин. Гикнется/уедет/пропадает - с полгодика-годик ещё на последнем пинке приедет, потом или вообще откажутся и ручками будут делать или промышленный образец поставят.

(121) > По моему мелкому мнению все-таки типовые использовать предпочтительнее (закрыв бяки хорошей обвеской например).

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

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

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

(124) – (128) Что и требовалось доказать. Хотите иметь меньше душевных рубцов, работайте с той программой, которую способны полностью контролировать.

(134) "Золотые слова Виктор Харитонович !"

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

(137) Скорее всего рубцы там на чьих то кривых руках, неправильно сделавших первичку

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты можешь быть десять раз прав, я даже не буду спорить, но когда есть возможность работать на своей программе вместо чужой, я выберу свою. Нервы ведь мои, а не твои :) .

(139) > когда есть возможность работать на своей программе вместо чужой, я выберу свою.

А тему-то зачем создал?

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

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

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

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

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

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

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

А сменные графики у вас есть? И сколько, если не секрет, у вас человек на предприятии и пользователей ЗУП? Пока никто не решается ответить на эти мои вопросы :) .

(135) > Но это все фигня. Ровно до того момента пока жив самоделкин.

Ну, хорошо, тогда я вам тоже задам вопрос: Как бы вы адаптировали программу для РФ под ЛНР? Просто опишите свою стратегию действий.

(140) > А тему-то зачем создал?

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

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

Честно говоря, не думал, что выльется в полторы сотни постов.

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

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

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

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

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

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

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

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

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

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

(147) Экий вы изворотливый персонаж, прямо за язык ловить надо

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

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

(148) > Экий вы изворотливый персонаж, прямо за язык ловить надо

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

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

(149) Ну для Крыма были адаптации, логично сделать так же. Правда "ЛНР ненаш" )

(150) > Ну для Крыма были адаптации, логично сделать так же. Правда "ЛНР ненаш" )

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

То же с программами под непризнанные республики. Кто первым предложит хорошее решение на местном уровне, тот и снимет все сливки. А спрос пока явно превышает предложение. И мне лично, откровенно говоря, выгодно продвигать свою конфигурацию на «семерке» здесь. Потому, что на «безрыбье и рак – рыба». Вопрос только в том, успею ли я предложить свой продукт раньше других. Но республики сейчас относительно бедные и много фирме «1С» никто платить не будет, но демпинговые цены потянут. Если фирма 1С не сглупит, как M$ в свое время с Интернетом, то может, в конечном счете, получить больший выигрыш, чем, если подключится к процессу позже. Я лично не жадный и меня устраивают оба варианта. Ну, а с фирмы 1С, если она прислушается к моему совету – презент, сколько не жалко :) .

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

(149) в сравнение в обязательном порядке д.б. включены тесты по запуску программы в сторонней фирме сторонними 1сниками и сторонними расчетчиеами.
А то получится как
"Опрос, проведённый в интернете, показал что 100% россиян пользуются интернетом"

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

У нас, в РФ, с кризисом народ тоже ожабился. Клиент относительно недавно - ууууу, дорого! Ну так надо было покупать года три-четыре назад - и тогда тоже было дорого? Ну сейчас ещё дороже получилось... Кто виноват?

(154) > фирме 1с на все клюшечное - начхать  с высокой колокольни.

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

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

К сожалению, я понял это только сейчас, сравнивая свою программу с ЗУПом. Но еще раз повторю: «Лучше поздно, чем никогда». Внешний спрос уже есть и я его чувствую, так что будем работать :) .

Emery чтобы Вас услышать и как-то понять надобно вспоминать клюшечные плюшки и времена. Порой читая Ваши сообщения Вы мне часто напоминаете рассуждения студента из анекдота выучившего единственный билет про блох и взявшего билет про рыб "Если бы у рыбы была шерсть, то у неё были бы блохи, а блохи подразделяются..."
Ну как прикажете понять Ваше отторжение документов и превознесение справочников и иерархии? С трудом вспоминается что у клюшек по сравнению со снеговиками был ряд узких мест для обхождения которых приходилось устраивать пляски с бубном. Два наиболее известных узких места это общий журнал документов  в виде таблицы в которую пишутся и которую в момент записи лочат все документы как один и периодические реквизиты в которые в свою очередь пишутся все в один файл. Дело в том что в восьмёрке, коллега, всё по другому... Здесь этих узких мест нет. В восьмёрке для отображения тех же документов можно применить динамический список, можно просто выгрузить и/или выгружать документы в объект дерево значений.
Рекомендую Вам, коллега, всё таки освоить восьмёрку. В сравнении с 7.7 решения на восьмёрке более производительны, более масштабируемы и более кросплатформены. После 7.7  неудобен восьмёрошный синтаксис помощник, но это мелочи. Скорость разработки возрастает по сравнению с 7.7 весьма и весьма существенно. Всяческие сложные отчёты ради написания которых на 7.7 приходилось крутить таблицы значений, если не было возможности использовать прямые запросы, на восьмёрке делаются мышкой. Попробуйте Вам понравится.

(156)Вот вы все утверждаете, что ваша программа лучше ЗУПа.
А расскажите про функциональность вашей программы:
1. Могут ли пользователи вашей программы изменять структуру отчетов: произвольно изменять состав полей отчета, группировоки отчета, накладывать произвольные отборы?
2. Можно ли подключаться к вашей программе через интернет-браузер?
3. Могут ли пользователи вашей программы корректировать печатные формы?
4. Возможно ли в вашей программе настраивать произвольные формулы расчета начислений/удержаний?
5. Можно ли вести в вашей программе воинский учет? Я понимаю, что вы находитесь в ЛНР, но какой-либо воинский учет у вас все же есть?
6. Есть ли в вашей программе учет дополнительного страхования?
7. Есть ли в вашей программе учет отгулов?
8. Можно ли в вашей программе правильно рассчитать Северную надбавку? С учетом работы сотрудника в различных северных условия.

Я правильно понял, что в вашей программе отсутствует следующая функциональность (т.к. у вас ЛНР, а не РФ):
1. Расчет больничных листов с учетом РК и льгот сотрудника.
2. Обмен электронными листками нетрудоспособности с ФСС.
3. Расчет налога на доходы физических лиц.
4. Расчет страховых взносов.
5. Регламентированная отчетность для ИФНС, ФСС, ПФР и органов статитстики.

(111)>Иерархичность данных на уровне документов ЗУП не поддерживает. Менять его в этом направлении себе дороже.
Тут работы на полчаса максимум, что в ЗУП 2.5, что в  ЗУП 3.1.
Делаете иерархический справочник, в шапке документа делаете реквизит со ссылкой на этот справочник. На форме списка документов отображаете документы в соответствии с иерархией справочника.

(94) Опыт у всех разный.

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

Отсюда и (20).

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

Имею право.

(157) > Ну как прикажете понять Ваше отторжение документов и превознесение справочников и иерархии?

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

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

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

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

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

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

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

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

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

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

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

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

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

(158) > Вот вы все утверждаете, что ваша программа лучше ЗУПа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Естественно, только для наших структур. Сама отчетность у нас в целом проще, чем у вас. Теоретически решаемо, через экспорт-импорт между программами.

А у меня вопрос, сколько в итоге зарплата рабочего, посчитанного по этим многоуровневым графикам?

Вообще создается ощущение, что речь идет о каком-то предприятии-динозавре. С мизерной зарплатой вследствие которой работники занимаются совмещениями откуда возникает необходимость в дичайшем учете рабочего времени и куче графиков.

(159) > Тут работы на полчаса максимум, что в ЗУП 2.5, что в  ЗУП 3.1.
Делаете иерархический справочник, в шапке документа делаете реквизит со ссылкой на этот справочник. На форме списка документов отображаете документы в соответствии с иерархией справочника.

В этом направлении я немного думал, только наоборот, не в документе ссылка на справочник, а в справочнике ссылка на документ. Пока ничего не могу сказать, не экспериментировал. Но в целом в «восьмерке» возможностей на порядок большей, чем в «семерке», так что изгаляться можно по-разному. Дела там с документами обстоят немного лучше, чем в 7.7, но о собственном стиле в 8.3 говорить пока рано.

(162)>А в случае ЛНР / ДНР ЗУП, откровенно говоря, малополезен. И, как ни странно, я рад этому, потому, что тем самым возрастает ценность моей программы,
В свое время делал адаптацию ЗУП 2.5 для одного крупного холдинга под законодательство Таджикистана и Кыргызстана. Трудозатрат потребовалось не так уж и много.
ИМХО: Проще взять типовой ЗУП 2.5/3.1 и адаптировать его под законодательство ЛНР/ДНР, чем писать с нуля свою программу.

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

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

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

Платформа 8.2/8.3 позволяет подключаться сразу к базе 1С через интернет-браузер. Удаленный рабочий стол становиться не нужен.

(162)>> 3. Могут ли пользователи вашей программы корректировать печатные формы?
>Естественно, редактор Moxel «семерки» поддерживает эти фичи плюс выгрузку в эксел.

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

(162)>> 4. Возможно ли в вашей программе настраивать произвольные формулы расчета начислений/удержаний?
>Можно будет через редактирование внешних sql запросов, если они не нарушат структуру внешней БД

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

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

Поздравляю, СЭР! Я обязательно передам эту информацию другу. Шесть десятых секунды на человека это круто! Вот если бы ваша система делала бы полный протокол расчета в текстовом виде, тогда можно было бы говорить и об относительном уровне сложности расчетов. Кстати, только что глянул свои текстовые полные протоколы за последний месяц. Максимальный размер более 250 КБ, а минимальный порядка 7 КБ. Соответственно время расчета этих людей сильно отличается. У меня в первой версии программы скорость расчета примерно 3,5 секунды на человека, во второй, надеюсь будет быстрее, поскольку вся расчетная БД будет целиком в памяти и будут делаться предрасчеты для средних.

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

Для правильного расчета северной надбавки с учетом работы сотрудника в различных условиях работы, необходимо хранить стажи работы сотрудника в различных северных условиях.
Также необходимо точно отслеживать дату, в которую сотрудник наберет стаж для смены размера северной надбавки.
Если сотрудник вахтовик, то из северных стажей необходимо выбрасывать периоды нахождения сотрудника на межвахтовом отдыхе.
В настоящее время ни ЗУП 2.5, ни 3.1 не считают северную надбавку в точности с законодательством.
Сомневаюсь, что ваша программа также ее сможет посчитать правильно.

(162)>Кстати, что такое «РК»?
РК - это районный коэффициент. Бывает федеральный и региональный. В северных районах больничные листы рассчитываются с учетом федерального районного коэффициента.

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

(166) > Проще взять типовой ЗУП 2.5/3.1 и адаптировать его под законодательство ЛНР/ДНР, чем писать с нуля свою программу.

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

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

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

Потом можно будет обсудить другие вопросы, если будет интересно.

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

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

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

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

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

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

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

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

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

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

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

(168) > Платформа 8.2/8.3 позволяет подключаться сразу к базе 1С через интернет-браузер. Удаленный рабочий стол становиться не нужен.

Ну, хорошо, пусть все решают свои проблемы с помощью 8.2/8.3. Это все кажущаяся легкость. Выиграете в одном, проиграете в другом. Кто ж в этих вопросах абсолютно честен? И сразу «предлагает весь список»?

(169) > ЗУП 3.1 позволяет пользователям в режиме предприятия модифицировать макеты печатных форм.

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

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

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

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

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

П.С. Зря вы меня отговариваете от «семерки» и навязывает «восьмерку». Не тратьте зря время, все равно я буду делать по-своему.

(170) > Здесь снова получается, что для изменения формулы расчета начисления или удержания требуется бежать за программистом.

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

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

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

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

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

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

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

Одним словом, на первый взгляд, формульный редактор имеет больше рекламный смысл, чем практический.»

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

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

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

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

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

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

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

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

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

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

(174) > ИМХО: Лучше было бы взять за основу типовой ЗУП, и в нем реализовать свою новую подсистему "с преферансом и поэтессами", чем разрабатывать свою программу с нуля.

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

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

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

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

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

Эмери, блин
Ваять что-то на клюшках - это сейчас путь в никуда (только если как хобби или тестовый стенд) - поверь старому клюшечнику.
Лучше бы свои мегаидеи реализовал в виде зарплатной восьмерочной конфигурации. Имхо даже в среднесрочной перспективе выгоднее чем пилить свою какую-то версию.
Это может быть только от безысходности пилить на клюшках что-то новое или развитие старого. Бесперспективняк это.

(181) > Ваять что-то на клюшках - это сейчас путь в никуда (только если как хобби или тестовый стенд) - поверь старому клюшечнику.

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

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

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

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

Если новая программа на «семерке» взлетит, то обязательно займусь ее версией на «восьмерке». Но только в такой последовательности. Сейчас меня очень привлекает внешний модуль на SQLite. Его реализация это уже совсем «семерка». Этот опыт очень пригодится и независимо от 1С вообще и применительно к SQL-серверу для 1С8. Но все должно быть последовательно. Перефразируя товарища Сталина: «То, что товарищ Магазька осуществил за 10-15 лет, мы должны пробежать за два-три года, иначе успеха не будет!» :) .

(182) время потеряешь
Пока новую версию сваяешь - ну полгода, пока обкатаешь - итого год. Если щвпустишь в массы - ну пусть ещё год-два.
Это же не белочка, это писец! 2-3 года на мёртвый продукт.
Вместо того чтобы вторую версию сваять на 8-ке. С её скоростью разработки получилось бы все быстрее.

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

Сначала нужно прошерстить все объекты метаданных, в которых хранится посчитанный НДФЛ и заменить целочисленный тип данных на числовой тип с разрядность 2 знака после запятой.
Затем нужно прошерстить весь код и в расчете НДФЛ изменить целочисленное округление на округление до двух знаков после запятой.
Вот что-то подобное и делал в свое время при адаптации ЗУП 2.5 под законодательство Кыргызстана или Таджикистана.

(177) >>ЗУП 3.1 позволяет пользователям в режиме предприятия модифицировать макеты печатных форм.
> Это не свойство ЗУП, а возможности самой платформы, реализовано практически во всех типовых.

Это не "возможности самой платформы", а одна из универсальных подсистем входящая в библиотеку стандартных подсистем (БСП). Все типовые решения для платформы 8.3 построены с использованием БСП, следовательно, они содержат возможность модификации в режиме предприятия макетов печатных форм.

(178) Ничто не мешает в конфигураторе добавить свой предопределенный показатель и прицепить к нему свой алгоритм расчета.

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

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

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

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

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

Ну теперь-то вы просто обязаны стать моим адептом)) В противном случае все ваши посты - это просто демагогия)

(183) > время потеряешь

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

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

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

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

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

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

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

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

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

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

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

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

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

(149) "Но теперь, когда вы все как бы знаете, ответьте на мой вопрос, как бы вы адаптировали программу для РФ под ЛНР?"

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

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

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

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

(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 всей дискуссии просто не было бы. Вам бы просто говорили какой вы молодец.

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

(192) > год - это сильно оптимистично, я уже полгода один суммированный учет на внешке долблю.

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

(189) "Та же «Магазька» на «восьмерке», вроде сделана с любовью, защита прикручена как бы профессиональная, успехом пользуется баснословным, но стиль ее оформления мне совершенно не нравится"
- вот тут я к тебе присоединюсь на 100%!
.
и это - я на 8-ке не прогаю...

(192) не хотел автора в депрессию вводить.. ;-)

(0) а не проще ли самому дописать 7-ку, чем эту ... юзать и иметь геморой с перекачкой устраивать ?