darkduck написал:
Yozhhhhh написал:
при обычной проводке вставить МВЗ в позицию счета, к которому счета затрат нет, невозможно.
А мне кажется, что можно. Система ругнется желтым цветом, но разрешит создать документ.
Не должно такого быть. Неоднократно пытался. Не думаю, что это как-то от уровня системы зависит или подавляется в OBA5. Я даже в некоторых разработках, которые работают с пакетным вводом и гибко умеют проводить затраты на разные счета, проверяю существование вида затрат к счету ГК. И если он есть, то в if делаю дополнительную обработку на МВЗ с экраном. Дак вот, как раз и пришлось прибегнуть к этой методике, потому что черти что в системе - часть 91 счетов создана с видом затрат, часть нет. Ну это легко проверить, при случае посмотрю еще раз.
catnixon написал(а):
Действительно 91* счет (убытки прошлых лет) создан с Видом счета - Первичные затраты или выручка.
Я очень не хочу показаться навязчивым...

Но если счет создан как вид затрат, то позицию по данному счету нельзя сохранить без контировки (хотя бы какой-нибудь, это не обязательно должно быть МВЗ). И глупо я не хочу выглядеть, но такое
catnixon написал(а):
Пользователь "проваливается" в список всевозможных контировок позиции 91* счета и, убирая значение поля МВЗ, выбирает ПУСТЫМ поле учета результата.
невозможно

Значит, присутствует какая-то другая контировка. Я бы сейчас, конечно, попробовал угадать, но если бы такое прокатывало, то мне следовало бы курить трубку и иметь Ватсона под рукой. Вы уверены, что к данному счету в транзакции OKB9 нет какой-либо контировки по умолчанию (не МВЗ)? Другой вариант также возможен: у счета есть контировка по умолчанию в виде МВЗ, при вводе позиции в документе амортизации система кушает сначала его, потом берет МВЗ из карточки ОС, а потом отрабатывает замещение, которое его затирает. Вот тут загвоздка: либо есть другая контировка (и тогда затертый замещением МВЗ не попал под красное сообщение), либо... замещение, затирающее МВЗ, реализовано не самым правильным способом. Дело в том, что в замещениях есть могучие дырки и порой не по злому умыслу у людей получается заместить поле так, что оно уже не попадает под проверки этого момента или всех последующих. Более того, таким способом можно заместить поля на несуществующие значения (веселился я однажды с неверно написанным замещением на счет главной книги, которое привело к сохранению документа вообще с несуществующим счетом и, конечно же, не обновило ни итоговых таблиц, ни сторнировать себя не давало).
Варианты неверной реализации замещения на поле:
- на втором моменте реализуется замещение поля через параметр using field, но внутри программы человек замещает не это поле, а ряд других через написание bseg-... =
- на третьем моменте используется класс bool_data, где через assign меняются поля, которые замещаться должны были через другие структуры (МВЗ сидит в COBL, а не в BSEG).
В общем, если работает, то хорошо, конечно... Но все же крайне любопытно, как же Вы смогли сохранить позицию по счету с видом затрат без какой бы то ни было контировки.
darkduck написал:
Думается, что возможно изначально счет 91* , выбранный бизнесом для отражения амортизации прошлых лет, создан не совсем корректно, но ...это уже другая история...
Сам по себе подход с 91 счетом прошлых лет правильный, а вот МВЗ на 91 счетах - не айс. Всегда можно начать использовать другой счет, а этот после реформации баланса заблокировать для проводок.
У Вас-то хоть 91 счета расхода с МВЗ. А у меня у заказчика 91 счета дохода с МВЗ
