Документ ЗаявкаНаЗакрытиеСчетов в "1С:ЗУП" 2.5.90.2 не делает (и не делал) движений.

1. RailMen 829 22.04.15 13:33 Сейчас в теме
Документ ЗаявкаНаЗакрытиеСчетов в "1С:ЗУП" 2.5.90.2 не делает (и не делал) движений по РС "ЛицевыеСчетаРаботниковОрганизации". Милейший расчетчик лезет руками в РС "ЛицевыеСчетаРаботниковОрганизации" и руками удаляет записи: 1) по уволенным сотрудникам; 2) сотрудникам, которые написали заявление о смене банковской карты. На вопрос любезного расчетчика "Почему после проведения документа ЗаявкаНаЗакрытиеСчетов не удаляются записи из РС" - ПОКА ответ "это не предусмотрено идеологией типовой конфигурации". Как думаете, имеет ли смысл сделать подписку ОбработкаПроведения (ну соответственно, ОбработкаУдаленияПроведения), чтобы при проведении документ записи удалялись автоматически? Если нет, то почему?
Вознаграждение за ответ
Показать полностью
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. Gray-SV-02 22.04.15 13:46 Сейчас в теме
А чем вам (расчетчику) мешают записи в РС?
3. RailMen 829 22.04.15 14:07 Сейчас в теме
(2) Gray-SV-02, есть отчеты разные(например, "Списки сотрудников организаций"), в которых могут выводится ВСЕ ЗАПИСИ РС "ЛицевыеСчетаРаботниковОрганизации", даже есть был проведен документ "ЗаявкаНаЗакрытиеСчетов". Что несколько вводит в заблуждение пользователей. Вопрос надо ставить так: зачем в РС активные записи с закрытыми счетами? Тут либо удалять их надо, либо признак добавлять в ресурс РС о закрытии и фильтроваться по нему в отчетах и других местах. Не забываем, что многие пользователи просто открывают форму записей РС, фильтруются по физ лицу и делают неправильные выводы.
4. RailMen 829 22.04.15 14:16 Сейчас в теме
К примеру, простая задача : вывести отчет по всем штатникам и их лицевым счетам с помощью типового отчета. Если в РС "ЛицевыеСчетаРаботниковОрганизации" несколько записей и только 1 "незакрытая" документом "ЗаявкаНаЗакрытиеСчетов", то в отчет попадут ВСЕ записи.
Еще одна мысль: РС имеет реквизит "Документ" типа "ДокументСсылка.ЗаявкаНаОткрытиеСчетов, ДокументСсылка.ПереносДанных". Т.е. если бы при проведении документа "ЗаявкаНаЗакрытиеСчетов" хотя бы значение в реквизите "Документ" изменялось на "ДокументСсылка.ЗаявкаНаЗакрытиеСчетов", то через этот реквизит можно было бы сделать отборы. Но и этого нет!
Либо есть некий методологический смысл в этом всем. Либо это недоработка типовой.
5. Gray-SV-02 22.04.15 14:41 Сейчас в теме
в общем и целом вы правы. Методологически правильно было бы сделать РС ЛицевыеСчетаРаботниковОрганизации зависимым (с регистратором) и наверное периодическим.
Если делать подписку, то тут легче доработать и обновлять. если делать реквизит или регистратор, то это придется менять и в типовых отчетах.
У вас получается сотрудник (физлицо) имеет несколько счетов в разных банках?
6. RailMen 829 22.04.15 15:07 Сейчас в теме
(5) Gray-SV-02!
1) РС ЛицевыеСчетаРаботниковОрганизации не сделан зависимым типовыми 1Снэгами по той причине, что кроме выплат в рамках так называемого "зарплатного проекта" (договор работодателя и банка), могут быть еще и выплаты в пользу сотрудников, которые выступают в роли как бы контрагентов. В этом случае нет необходимости проводить документы "ЗаявкаНаОткрытие/ЗакрытиеСчетов". Рынок переполнен обработками, которые в работе используют свойство независимости РС и если его сделать зависимым, то все эти свистелки (некоторые написаны программистами банка) перестанут работать (тут я двумя руками "ЗА").

2)Если допиливать типовую ЗУП, то, разумеется, ТОЛЬКО с помощью подписок. Тут соглашусь на 142%.

3)Строго говоря, сотрудник может иметь несколько счетов в разных банках. Это разрешено действующим законодательством. Более, того он может иметь несколько счетов в одном банке (что много хуже, если посмотреть на структуру метаданных ЗУПа). Конкретно в нашем случае, один банк купил другой банк и мы стали клиентами ВТБ24. В РС теперь несколько записей по старому банку и по ВТБ24. Хотя и провели документ "ЗаявкаНаЗакрытиеСчетов", в который попали все сотрудники с реквизитами счетов старого банка.

Короче, нужно подписки делать. Так? Или все таки есть какое то объяснение с точки зрения методологии и лучше ничего не трогать?
7. Gray-SV-02 22.04.15 15:16 Сейчас в теме
думаю лучше сделать подписку и удалить. НО при условии, что эти старые данные вам никогда не понадобятся
8. RailMen 829 22.04.15 15:19 Сейчас в теме
(7) Gray-SV-02, данные о старых лицевых счетах хранятся в документах "ЗаявкаНаОткрытиеСчетов" и "ЗаявкаНаЗакрытиеСчетов". Никаких потерь данных не произойдет. Надо учесть, что при проведении документа "ЗаявкаНаОткрытиеСчетов" записи смогут опять создаться. Но это маловероятно, так как период закрыт, и чтобы открыть его надо быть в нашем случае бессмертным суперменом.
9. RailMen 829 23.04.15 12:40 Сейчас в теме
Продолжу тему.
Пусть у физ лица в РС "ЛицевыеСчетаРаботниковОрганизации" хранятся две записи: 1 запись о счете в банке ТКБ, 2 запись о счете в ВТБ24. При текущей методологии "1С:ЗУП" даже после проведения документа "Заявка на закрытие счета" с указанием закрытия счета физ лица в банке ТКБ, соответствующая запись из РС удалена не будет (руками удалять записи при проведенном документе - это двойная работа). Об этом мы писали выше.

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

Теперь посмотрим на "поведение" типового "1С:ЗУП" в столь ответственный момент.
Расчетчик выбирает в шапке документа "Зарплата к выплате организации" старый банк-контрагент ТКБ и нажимает кнопку "Заполнить".
В табличную часть попадет и выше упомянутое физ лицо, по которому зафиксирован долг (поскольку в РС 2 записи). Хотя ранее был проведен документ "Заявка на закрытие счета" с указанием закрытия счета этого физ лица в банке ТКБ. Т .е. деньги могут пойти на "старую" карту. И с точки зрения учета - это НОРМАЛЬНО. Но с точки зрения бизнес процесса по перечислению ДС в рамках перехода в новый банк - НЕТ. Если бы документ "Заявка на закрытие счета" удалял бы записи из РС "ЛицевыеСчетаРаботниковОрганизации", то это ГАРАНТИРОВАЛО бы правильное направление перечисление ДС.

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

Думаю это исчерпывающее решение проблемы с адекватной архитектурой.
Если кто-то предложит свое решение или напишет тут о каких-то подводных камнях или случаи из практики, т.е. уменьшит энтропию задачи, - тому немного "попугаев ИС" (вознаграждение).
10. RailMen 829 23.04.15 13:38 Сейчас в теме
Лучше не константу (см. выше), а независимый периодический регистр сведений с измерением "Организация". С ресурсом "В организации есть зарплатный проект".
Так же советую изучить очень хорошую статью:
Перечисление зарплаты в банки
11. v12345 19 24.04.15 07:19 Сейчас в теме
1.
"Типовые разработчики специально не удаляли эти записи по каким-то причинам"


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

2.
"Если допиливать типовую ЗУП, то, разумеется, ТОЛЬКО с помощью подписок. Тут соглашусь на 142%".


Во многих других случаях я бы подписался под этой фразой, но здесь считаю это излишней приверженностью идее "не трогать типовую конфигурацию". Да, это правильная идея в отношении таких регламентированных блоков, как расчет среднего, работа с НДФЛ, со с/взносами. Но в отношении таких блоков, как лицевые счета, зачем за это цепляться? Вообще говоря, не может быть в большом и сложном предприятии (а судя по вашим репликам, оно у вас такое) ТИПОВОГО ЗУПа, поскольку в этой сфере очень большая вариативность процессов. Любой заказчик, решивший использовать зарплатную конфигурацию для учета больше 100-150 сотрудников должен это понимать, принимать и быть готовым за это платить. Поэтому смелее правьте ЗУП на тех участках, которые не относятся к высокорегламентированным. Тем более, что хорошо известно, что развитие ЗУПа 2.5 оставновлено, в нем даже ошибки явные уже не все правятся. Почти неверноятно, что переколбасив сегодня регистр Лицевых счетов и связанные документы, вы себе создадите проблемы при последующем обновлении. В этих обновлениях уже нет ничего, кроме налогов.

3.
не лишнем будет сделать для документа "Заявка на закрытие счета" реквизит "В рамках зарплатного проекта" типа булево, который заполнять при создании нового документа значением нетиповой константы "В организации есть зарплатный проект". Если в документе флаг "В рамках зарплатного проекта" установлен, то при его проведении должна отрабатывать подписка на удаление записей из РС "ЛицевыеСчетаРаботниковОрганизации". Флаг нам нужен, чтобы гарантированно удалять записи РС только при конкретно нам подходящем условии


Сама идея делить счета на "зарплатно-проектные" и прочие достаточно искусственна. С точки зрения последующей работы в ЗУПе не вижу между ними разницы. Или приведите примеры, где именно вы ее видите.
Вообще считаю, что можно смело придерживаться простой логики, что в регистре должны быть только актуальные счета. Все неакутальные - удалять без всяких оговорок и констант, хоть документом, хоть руками, но удалять :).
Если так совсем страшно - ну заведите архивный регистр, т. е. кроме ЛицевыеСчетаРаботниковОрганизации пусть будет АрхивныеЛицевыеСчетаРаботниковОрганизации, и пусть действия документа Заявка на закрытие сводится к переносу данных из одного регистра в другой. Такая схема, конечно, с точки зрения теории дилетансткая, но зато позволяет не переделывать структуру основного регистра и запросы к нему, т к. в основном регистре у вас будут только актуальные счета.
12. RailMen 829 24.04.15 11:43 Сейчас в теме
(11) v12345, спасибо за потраченное время на такое количество букв. Позвольте "пройтись" по вашему комментарию.

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

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

3. Выделять "зарплатные проекты" и не "зарплатные" - это не идея. А данность работы многих предприятий. Вот ссылка на "не зарплатный проект" и его тонкости: http://infostart.ru/public/83702/
Сам факт того, что РС "ЛицевыеСчетаРаботниковОрганизации" независимый с этим связано.
Я выше писал, что данные о старых "закрытых" счетах хранятся в документах. По этой причине вообще не надо создавать дополнительные архивные РС.
13. RailMen 829 24.04.15 11:53 Сейчас в теме
Снова продолжу тему (может статью написать отдельную?).
Структура РС "ЛицевыеСчетаРаботниковОрганизации" содержит только 1 ресурс "НомерЛицевогоСчета". Но обмен с некоторыми банками предполагает миграцию информации о номере карты сотрудника (это не номер лицевого счета!), коде валюты карты, типе карты (Visa, VisaGold и пр.). Вопрос: почему в типовом в РС нет таких очевидных и нужных реквизитов? Обмен с такими реквизитами характерен, например, для банка ВТБ. Т.е. это значительный объем рынка допила ПО средних и крупных компаний, которые вынуждены сейчас решать свои проблемы по автоматизации сами и с разной степенью успеха.
14. Scorpion1_77 24 24.04.15 12:34 Сейчас в теме
Имеющиеся в программе "1С: ЗиУП 2.5" документы по работе с лицевыми счетами разрабатывались "1С" в рамках проекта взаимодействия со Сбербанком.

Во всех остальных случаях в них нет абсолютно ни какого смысла и хорошо, что они не являются регистраторами РС "ЛицевыеСчетаРаботниковОрганизации".

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

Мое субъективное мнение...
15. RailMen 829 24.04.15 13:20 Сейчас в теме
(14) Scorpion1_77, да, про историю обмена со Сбербанком писал Харитонов в первых редакциях "Секреты проф работы в ЗУП". С тех пор прошло, наверное, более 5 лет. Вопрос в том, почему фирма 1С не желает развивать этот блок типовой конфигурации, хотя потребность в этом на рынке есть. Неужто более рентабельно опустить эту проблему на уровень франчайзи? Может тогда, самой фирме 1С вовсе отказаться от дальнейшего тиражирования типовых конфигураций имени самой себя? Пусть все работают с продуктами фирм франчайчи, а те конкурируют за место под солнцем в равных условиях?

РС "ЛицевыеСчетаРаботниковОрганизации" независимый в типовой по разным причинам. Если в организации есть симбиоз "зарплатного проекта" и "не зарплатного", то блочить права на доступ к этому регистру нельзя. Чем отличаются эти проекты - можно прочитать выше (см. ссылки).
16. Scorpion1_77 24 24.04.15 14:25 Сейчас в теме
Не пойму какая взаимосвязь между наличием зарплатного и не зарплатного проекта и ограничением прав доступа на РС "ЛицевыеСчетаРаботниковОрганизации".

Например, в компании которой я работаю, в базе данных более 2К сотрудников, работающих в 18 организациях Мск и Спб. Есть зарплатный проект и сотрудники, которые написали заявление на перечисление з/п в другой банк.

И я не наблюдаю проблем с вводом данных в РС "ЛицевыеСчетаРаботниковОрганизации".

Думаю, что ограничение количество пользователей, которые будут редактировать этот РС снизит риск не адекватных действий пользователя т.е. решение таких проблем должно быть в административной сфере, а не технической.
Можно также на событие удаление записи в этом регистре организовать отправку email ответственному сотруднику.
17. RailMen 829 24.04.15 15:05 Сейчас в теме
(16) Scorpion1_77, ограниченное число пользователей конечно снизит риск. Чем меньше пользователей - тем меньше риска, а если их нет - то и риск =0 ))))) На самом деле речь идет о том, что некоторые пользователи имеют согласованный в письменном виде доступ к этому РС (у нас есть понятие "ролевая модель" и документ "Заявка на доступ к данным", который проходит согласование с владельцами данных). Так вот, эти пользователи могут работать в типовом РС так, как предполагает типовая идеология, т.е. и руками тоже. И несут за это ответственность. При "зарплатном проекте" руками никто туда не лезет - оформляются документы "Заявка на открытие/закрытие счетов". При перечислении ДС в не рамок "зарплатного проекта" (как контрагентам в иные банки) - могут и руками залезть, осознавая все последствия своих действий. Это несколько другой подход. Более гибкий и с четко прописанной ответственностью.
18. v12345 19 25.04.15 04:31 Сейчас в теме
Выделять "зарплатные проекты" и не "зарплатные" - это не идея. А данность работы многих предприятий.


Это бесспорно, и у меня тоже есть такое деление. Но мы обсуждали КОНКРЕТНЫЙ ВОПРОС - ПОРЯДОК ВВОДА СЧЕТОВ. И именно ПОРЯДОК ВВОДА я имел в виду, когда написал, что "сама идея делить счета на "зарплатно-проектные" и прочие достаточно искусственна."
Пока вы не запретили прямой ввод в регистр, счета обоих типов - и зарплатные проекты, и персональные, вы равным образом можете ввести как документом, так и напрямую - это никак не изменяет последующие этапы работы с ним.

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

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

По сути то же написал и Scorpion1_77
МимохожийОднако; +1 Ответить
19. v12345 19 25.04.15 04:34 Сейчас в теме
Вы дважды дали ссылку на http://infostart.ru/public/83702/, поэтому и про эту статью выскажусь. Возможно, она неплохо описывает логику, которую подразумевали авторы типовой конфигурации, но для крупных предприятий эта логика не подходит по меньшей мере по 3 пунктам:

1. В этой статье предполагается, что на каждого сотрудника с персональным счетом нужно оформлять отдельный документ Зарплата к выплате организаций. Т. е. допустим у меня 1500 сотрудников, из них 1480 получают зп списочно по проекту, а 20 - на персональные счета. Мне что, лабать 20 документов? Я не видел бухгалтерий, которые вдохновятся такой перспективой и тут же не потребуют от ИТ-поддержки "что-то с этим придумать".

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

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

Как итог, самое простое решение персональных перечислений в ЗУП 2.5 может быть, например, таким:
а. Заводится контрагент под названием Сводный банк для персональных перечислений. По нему создаются условные лицевые счета, реквизиты которых не имеют ничего общего с реальными банковскими реквизитами для платежа.
б. В момент выплаты з/п по этому условному банку создается один документ Зарплата к выплате организаций. В примере выше в нем будет 20 строк.
в. К документу Зарплата к выплате делается печатная форма реестра, в которой в самом простом виде должны быть а) код получателя, под которым он хранится в БУ и/или казначействе б) ФИО или, точнее, его наименование в БУ/казначействе в) сумма к перечислению. Этот реестр выводится в файл, файл загружается в систему БУ/казначейства.
Дальше возможны разные навороты - в основном их степень зависит от того, как именно устроена интеграция с БУ и/или казначейством. Но основная идея все равно одна: "в подсистеме взаиморасчетов ЗУП есть лишь один псевдобанк, и только при загрузке в БУ/казначействе он разворачивается в настоящие счета в настоящих банках".
20. v12345 19 25.04.15 04:38 Сейчас в теме
Вопрос в том, почему фирма 1С не желает развивать этот блок типовой конфигурации, хотя потребность в этом на рынке есть


Вы же знаете ответ - форма 1С уже 1,5 года вообще не развивает НИКАКИЕ блоки 2.5. В 3-ке с вопросами, которые мы обсуждаем, получше.
21. RailMen 829 25.04.15 11:39 Сейчас в теме
(20) v12345, спасибо за внимание к вопросу (вы наверно с Дальнего Востока судя по времени комментариев).

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

Повторюсь.
Любые доработки и программные изменения НИКАК не выявляют ответственность пользователей и не разграничивают ее.
Ответственность всегда прописана на бумаге и согласована, а изменения/доработки ПО (в частности ЗУП) тут ничего не доказывают.
У нас решает проблему согласованная заявка на права доступа к РС + методические указания, в которых прописан запрет на ручные правки РС.
ВНИМАНИЕ: запрет только для 2 пользователей, у который согласованна заявка на доступ к этому РС. У остальных доступа к РС нет вовсе.
30 минутного обучения хватает на безошибочную работу.

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

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

Ну почему же? :) Мы проводки формируем на стороне ЗУПе с заполненной аналитикой по 70 (физ лица) и 76 счетам (> 1 тыс сотрудников в 1 филиале, есть еще). Как вы думаете для чего? В БП они перегружаются уже без аналитики. Мы можем в любой момент времени предоставить проводки по ФОТ со всей возможной аналитикой, хотя в ОСВ в БП вы ее не увидите. Есть возможность формировать резервы на остатки отпусков ТОЧНО по физ лицам, а не пальцем в небо как в типовой. И т.д. и .т.п. Такие требования и специфика. Поэтому не будьте так категоричны.

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

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот