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

А чем вам (расчетчику) мешают записи в РС?

К примеру, простая задача : вывести отчет по всем штатникам и их лицевым счетам с помощью типового отчета. Если в РС "ЛицевыеСчетаРаботниковОрганизации" несколько записей и только 1 "незакрытая" документом "ЗаявкаНаЗакрытиеСчетов", то в отчет попадут ВСЕ записи.
Еще одна мысль: РС имеет реквизит "Документ" типа "ДокументСсылка.ЗаявкаНаОткрытиеСчетов, ДокументСсылка.ПереносДанных". Т.е. если бы при проведении документа "ЗаявкаНаЗакрытиеСчетов" хотя бы значение в реквизите "Документ" изменялось на "ДокументСсылка.ЗаявкаНаЗакрытиеСчетов", то через этот реквизит можно было бы сделать отборы. Но и этого нет!
Либо есть некий методологический смысл в этом всем. Либо это недоработка типовой.

в общем и целом вы правы. Методологически правильно было бы сделать РС ЛицевыеСчетаРаботниковОрганизации зависимым (с регистратором) и наверное периодическим.
Если делать подписку, то тут легче доработать и обновлять. если делать реквизит или регистратор, то это придется менять и в типовых отчетах.
У вас получается сотрудник (физлицо) имеет несколько счетов в разных банках?

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

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

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

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

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

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

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

1.

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

2.

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

3.

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

Снова продолжу тему (может статью написать отдельную?).
Структура РС "ЛицевыеСчетаРаботниковОрганизации" содержит только 1 ресурс "НомерЛицевогоСчета". Но обмен с некоторыми банками предполагает миграцию информации о номере карты сотрудника (это не номер лицевого счета!), коде валюты карты, типе карты (Visa, VisaGold и пр.). Вопрос: почему в типовом в РС нет таких очевидных и нужных реквизитов? Обмен с такими реквизитами характерен, например, для банка ВТБ. Т.е. это значительный объем рынка допила ПО средних и крупных компаний, которые вынуждены сейчас решать свои проблемы по автоматизации сами и с разной степенью успеха.

Имеющиеся в программе "1С: ЗиУП 2.5" документы по работе с лицевыми счетами разрабатывались "1С" в рамках проекта взаимодействия со Сбербанком.

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

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

Мое субъективное мнение...

Не пойму какая взаимосвязь между наличием зарплатного и не зарплатного проекта и ограничением прав доступа на РС "ЛицевыеСчетаРаботниковОрганизации".

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

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

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

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

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

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

По сути то же написал и Scorpion1_77

Вы дважды дали ссылку на http://infostart.ru/public/83702/, поэтому и про эту статью выскажусь. Возможно, она неплохо описывает логику, которую подразумевали авторы типовой конфигурации, но для крупных предприятий эта логика не подходит по меньшей мере по 3 пунктам:

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

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

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

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

Вы же знаете ответ - форма 1С уже 1,5 года вообще не развивает НИКАКИЕ блоки 2.5. В 3-ке с вопросами, которые мы обсуждаем, получше.