[sava1]

Как вариант - обработка с выборкой чистой ЗП и расчетом алиментов, а дальше ручки+Операция

[Ryudik]

Как вариант - обработка с выборкой чистой ЗП и расчетом алиментов, а дальше ручки+Операция

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

[sava1]

Тогда документ - НачислениеЗП (форма,модуль) - дописываем свое

[Zaval]

Может я чего-то не заметил, но разве ДО по 661 в корреспонденции с 301 - это не то?

ВыполнитьЗапрос(<НачалоПериода>,<КонецПериода>,<Счет>,<КоррСчет>,<Валюта>,<ТипИтогов>,<Периодичность>,<ТипСуммы>)

Только кроме 301 может быть еще 311, а процент алиментов лучше сделать реквизитом Сотрудника.

[Домовик]

Zaval, а так в типовой операции можна? Выполнить запрос в типовой операции?
Да и почему учитывать выплаты при расчете удержаний, хоть и по формуле подходит....

Еще не очень этичный способ КО()- ДО() расчитать на дату начисления ЗП. С бухгалтером договориться вводить НАчислениеЗП на дату 27 числа....

метод БИ.Период(ДатаНАчалаПериода, ДатаОкончанияПериода)
но пробую, не получается пока.

[Zaval]

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

[Домовик]

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



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

[Zaval]

Отличный вариант.
Вот только это остается "на доверии" к юзерам, которые меняются, забывчивы и горазды во всем обвинять программу(
А еще очень любят нарушать хронологию работы.
Пару лет сопровождал ЗиК. Еще долго на любой вопрос юзера на языке вертелось "Журнал пересчитан?!")))
Я бы, скорее всего, сделал Обработку. Одна строчка с ее вызовом в модуле НачисленияЗП - не такая уж проблема при обновлении.

[Домовик]

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

[Zaval]

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

ЗЫ. Скорее всего, на Башорге, был такой диалог(за дословность не ручаюсь):
- Вот нравится мне в программировании, что одно и то же можно реализовать десятью разными способами!
- Ага, и за 8 из этих 10 огрести хороших люлей от ведущего программиста...

[Домовик]

добросовестность - единственный критерий.

По обработке - в документе НачислениеЗП реквизит типа Документ.Операция.

Типовая операция - хорошее быстрое временное решение. Но формулу- то до сих пор не написали.

[Домовик]

БИ.Рассчитать(Дата("27."+строка(датамесяц(ДатаОперации))+"."+строка(ДатаГод(ДатаОперации))), Дата("27."+строка(датамесяц(ДатаОперации))+"."+строка(ДатаГод(ДатаОперации))));
БИ.КО("661",1,,Дебет.Субконто(1),Дебет.Субконто(2))-БИ.ДО("661",1,,Дебет.Субконто(1),Дебет.Субконто(2));

но Документ НачислениеЗП нужно вводить строго нужным числом. приветствуются другие варианты