PS (к предыдущему моему):
пока нащупано только одно, казалось бы неубиенное, решение - забаланс. Но нет ли и на нем пятен?
И как мне провязать документ, по которому проводки, проведенные по 62.02 отдублированы еще и забалансовой проводкой - с этой самой забалансовой проводкой? Если ручками добавить забалансовые проводки в проводки документа - то бухи испугаются ссобщения о
1СДвижения документа отредактированы вручную и не могут быть автоматически актуализированы.
а если забаланс вести отдельной ОперацияБух-ой - то не будет связи с доком.

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

Не понял смеха :-).а что испугало? Ирония по части свежести идей? так не берите в голову. Перефразируя - "Забаланс - последнее прибежище <определение опционально>"

ПаляКакое слово пугает? вручную?где вы вычитали слово "пугает"? Речь только о том, что то, что нормально по той самой "теории БУ" отражается одной записью по балансовым счетам (тут точнее - субсчетам), почему-то должно делаться двумя идентичными записями фактически по 2-м разным ПланамСчетов - Баланс/Забаланс (кстати, не понял, почему 1С еще не выяснил для себя, что Забаланс - это _иной_ ПланСчетов), и то, что могло свестись к изменению последнего регистра вглубь т.с. "[пользовательской суб-иерархии] Иерархии Балансового счета" должно делаться выкопировыванием все проводки, и, заметим в скобках - задвоением всех записей учетных регистров (т.е. в т.ч. и записей сопутствующих оборотных и накопительных табличек)

ПаляПроводки по 62 возникают при проведении первичных документов.
Флажка - "Гарантийный Взнос" в первичных документах нет.
Поэтому вручную некую галочку поставить придётся.. как вы ещё хотите??

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

Ну значит логика создания забалансовых проводок добавляется в документ имеющий этот флажок
либо в отдельный.
Слово "вручную" в данном вопросе я как-то двусмысленно воспринимаю :-)
От юзера в любом случае как минимум потребуется одно логическое действие, отличающее аванс от гарантийного взноса. вот и вся "ручность".Одно действие пользователя не пугает, неприятны некие побочные последствия - см проблемы привязки забалансовой проводки к документу в моем предыдущем посте. - На беглый взгляд альтернатива - либо иметь пугающую Буха пометку после ручной (внеконфовой) правки проводок по доку, либо не иметь внятной связи с документом. (Либо вставать на могущую далеко завести дорогу самопальной правки конфы). Я не прав?


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

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

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

Палязы. с точки зрения совместимостей и обновлений:
1)трогать в плане счетов 62.02 и его иерархию нельзя.
2)проводки отдельным документом - идеальный вариант.вот это бы хотелось знать наверняка. (т.е. то, что всё настолько погано, и иного пути, кроме
1. забаланса, и
2. потери связи с доками
- нет (если не трогать конфу) - т.е. учет забаланса превращается в несвязное (с доками и балансовыми проводками) мн-во проводок, разобраться в коем опосля можно будет только самолетиками и т.п. бумажно-йоксельными инструментами и привлечением "общих соображений", "здравого смысла" и прочих плохоформализуемых бубнов)

ПаляДля этого есть документ КорректировкаЗаписейРегистров. (подозреваю что корректировка проводок вручную им и пользуется. хотя у меня нету 1.6.)ок. Спасибо за наводку. Посмотрел.


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

ПаляТут такой тонкий вопрос - насколько они должны отслеживаться отдельно, что значит на субсчет другой их можно положить а на другой договор нельзя.. парадокс по моему..
В чем отличие? - это будет тот-же аналитический разрез. который в том же ручном режиме должен заполняться.. гм. по субсчету я свёртку могу сделать (по всем контрагентам). Т.е. выделить эту статью. А как свернуть контрагентов по типу "договоров"? Договора-то - это вообще говоря не отдельный (полностью ортогональный) разрез аналитики. Это (в случае 1с, по крайней мере) - подразрез Контрагентского разреза.

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

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

DmitryOrlovПример на той неделе получил - на 44.01 открыт субконто 2 (Подразделения), 1-ый родной - статьи затрат. При закрытии месяца - закрытие 44-го счета, второй уровень субконто не обрабатывается, в проводку не подставляется. Конфигурация БП 1.6.2.9. В последней конфигурации (1.6.5.4) эта ситуация также не обрабатывается.мда-ссс. Чудны дела твои, господи.

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

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

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

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

Пока вижу возможность пользовать еще разве только само Договоры.Наименование , но это уже совершенное кю.


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

PS все оговорки предыдущего поста еще надо наложить на необходимость дублировать все договора контрагентов. Например
- можно будет и по "наименованию" группировать. При этом поиск по реальному наименованию договоров удлинится.

DeosfenМожно уточнить?

Может ли быть у контрагента + договор
1. оплата аванс
и 2. гарантированный взнос
одновременно?
именно так и будет. Договор включает в себя такую позицию, как гарантийный взнос. Но она не единственна.
DeosfenЕсли да, то что такое гарантированный взнос,
чем же он будет отличаться от обычного аванса, в терминах бух. учета?гарантийный взнос - это подвид аванса ("суб-аванс" - так вам понятнее его "суб-счетная" природа). Его надо уметь быстро выделять. Работа такая.


ЗЫ бухучёт и "видимость бухучёта"(1С) - немного таки разные вещи. В бухучёте я могу добавить субсчета более низкого уровня на счёт (субсчёт), и это не изменит принципа бухучёта, а в 1С это сопряжено с риском получить необходимость переписывания конфигурации.

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

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