создать новую тему раскрыть все
 
Такая проблема новичка. Имеется статья дохода А, по которой периодически поступают деньги (авансом). Но иногда часть выплат приходится возвращать. Раньше в другой примитивной программе я просто проводил отрицательную транзакцию по той же статье А, и в результате в конечном счете получал в отчете чистый размер заработка по этой статье.  Но здесь, в обсуждаемой программе проводить отрицательные операции невозможно. Как можно обойти это затруднение и решить проблему? Спасибо.
 
Но в настройках классификаторов (например, Статей) можно разрешить использовать одни и те же статьи и для приходов, и для расходов.
 
Тогда вместо двух раздельных деревьев статей "Все статьи прихода" и "Все статьи расхода" будет одно общее - "Все статьи".
 
Хоть это и решит вашу проблему, в использовании такой вариант не очень удобен.
 
Как вариант, можно завести дополнительный классификатор (скажем "Проекты") без разделения по типам операций.
И тогда поступление денег у вас будет проходить операцией прихода с Статья = Аванс, Проект = А
А возврат части выплат - операцией расхода с Статья = Возврат, Проект = А.
В отчётах тогда нужно будет смотреть баланс не по статье, а по проекту.
 
Про свойства классификаторов, и как создать дополнительные см. в разделе сайта "Документация".
 
Спасибо, Дим, за ответ.
Вы правы, первый вариант (все статьи в одну кучу) неудобен из-за неразберихи с приходом/расходом. По Вашему совету выбрал 2-й вариант - с классификатором "Проект". Но это тоже как-то коряво выходит. Например, в суммарном отчете по всем расходам будет приниматься во внимание статья расхода по проекту А, тогда как реально никакого такого расхода нет - это возврат лишних денег. Соответственно, суммарный приход тоже неверно отображается. Но видимо придется смириться - разве что Вы найдете какой-то еще вариант Well
Все-таки жаль, что невозможны отрицательные операции. Это мне чем-то напоминает исключение безусловного GOTO при переходе от Фортрана и подобных языков к языкам структурного программирования: хотя анализ программ упростился и вероятность ошибок уменьшилась, но в известной мере потерялась гибкость процесса программирования.
Если придумаете еще какой вариант, сообщите. пожалуйста. А пока спасибо огромное за Вашу помощь.
 
Тогда вместо двух раздельных деревьев статей "Все статьи прихода" и "Все статьи расхода" будет одно общее - "Все статьи".

В отчетах "Обороты" разнесение по приходу-расходу наличествует в любом случае. Объединить приход и расход в рамках одной статьи невозможно.
 
С новым годом!
С 1 января начал тестировать первый вариант, предложенный Дим(м). Для этого создал дубликат своей рабочей базы данных, в котором одно неразделенное дерево "Все статьи", но в нем 2 поддерева: "Все статьи прихода" и "Все статьи расхода". Таким образом, продублировал все статьи основной базы, но по ним уже можно проводить "красные проводки". И теперь веду все свои записи одновременно в обеих базах данных. Пока никаких проблем в новой (неразделенной) системе не встречаю, за исключением отмеченного ув. Amundsen факта, что в отчетах "Обороты" прямые и обратные проводки взаимно не компенсируются и появляются параллельно в соответствующих разделах прихода и расхода. Мне кажется пока, что с подобным недостатком вполне можно смириться, по сравнению с гибкостью, которую дает возможность отрицательных проводок. Однако, я не исключаю, что из-за непродолжительности эксперимента, пока не вижу каких-то еще подводных камней. Поэтому прошу, если Вы знаете или предвидите еще какие-то недостатки/проблемы такого варианта использования программы, сообщите, пожалуйста, о них. Спасибо.
 
... эта проблема является принципиальной: статьи прихода и расхода нужны исключительно для последующего их анализа, который, в свою очередь, является одной из важнейших целей учета. Инструментом анализа в программе являются отчеты.
И получается, что такое решение проблемы сторнирования никак этой задаче не способствует. Другими словами: что разделенное дерево статей, что общее - в рамках имеющегося функционала это без разницы.
 
я подумаю над Вашими словами, ув. Amundsen. Согласен, что в целях отчетности этот подход ничего не дает. Но мне сейчас важно знать, не отнимает ли он что-то важное. Ведь если эти отчеты не становятся полезны для анализа в случае сторнирования, так ведь при старом подходе не только этой пользы, но и возможностей самого сторнирования не было. А здесь можно, по крайней мере, проводку провести с удобством, не создавая новой статьи каждый раз, когда требуется повернуть проводку вспять. Поскольку я использую программу не для какого-то работодателя, а для собственной домашней бухгалтерии, то тонкости отчетности может быть и не так важны. Так что еще раз, мой вопрос: не столь важно, что этот подход не дает ожидаемого положительного результата; мне важно, не приведет ли он к каким-то отрицательным последствиям именно из-за отмены разделения по виду операции. Может быть я чего-то не понимаю?
И еще: я вижу какие-то различия в отчетах по Динамике оборотов, но не вполне понимаю их. Не видите ли Вы какого-либо важного упущения здесь?
Спасибо.
 
... который сделал уведомления на email.
 
А разделение статей по видам операций было сделано лишь для удобства, никаких последствий ее отмена не несет, насколько я понимаю.
 
Насколько я помню, в отчете "динамика оборотов" суммирование приходных и расходных операций в рамках одного классификатора работает корректно, т.е. "первый вариант" там работает.
 
...и Вам, ув. Amundsen, и конечно Loki за уведомления. Хотя об уведомлениях была тема, и там я отметился с благодарностью, но еще раз.
Поскольку Вы обнадежили, что отмена разделения никаких нехороших последствий (кроме отчета по оборотам), скорее всего не имеет, я продолжу эксперимент параллельного ведения записей в двух базах, а там видно будет.
Всего Вам доброго.
 
если очень нужно минусовать и не накручивать обороты, то со словами "иииээээхххх.....  *****" (подставить нужное) снимаем блокировку с проводки и изменяем в ней сумму.
сложно? не нравится? ищите другую программу.
эта программа очень хорошая. есть особенности.
можно привыкнуть.
 
Прочитал ветку, которую предложил ув. Amundsen. Спасибо Well. Ну что сказать? Все предложения обхода отрицательных транзакций, к сожалению, имеют серьезные недостатки. Предложение удалять или корректировать задним числом счет, по которому идет возврат, неприемлемо по причине несовпадения дат прямой и обраной транзакций и искажения сумм на счетах между этими датами. Открытие отдельного счета для возврата, использование переводов вместо прихода/расхода, или проведение обратной проводки как противоположной по смыслу (т.е. расхода вместо отр. прихода и наоборот) - все это приводит к искажению картины оборотов по статьям приходов и расходов, не говоря о разбухании планов счетов и статей. Отказ от разделения статей на приходные и расходные не годится по той простой причине, что это разделение нужно не столько по математическим, сколько по психологическим причинам. Вариант Димы(м) хорош, но не универсален, поскольку эти "другие", для которых надо создать долговые счета, сегодня одни, завтра другие, не можете же вы так нагромождать план счетов.
И все эти головоломки только из-за нежелания автора (хотя это и его право) ввести в программу отрицательные проводки. Но ведь неспроста в бухгалтерии существует понятие "красной проводки" или "сторно" - все-таки это нужная вещь. Не могу понять, почему авторы от нее отказываются - какая-то непонятная принципиальность во вред продукту. Согласиться с тем, что это усложнило бы отчетность, невозможно, поскольку какая программе разница, будут ли все слагаемые положительными или нет.
свернуть/развернуть ветвь о смысле жизни и обо всём [куверти3 11/01/2015 09:35] # написать ответ
 
Ответ, конечно же, не "42", а немного другой :-)
Сторно имеет несколько другую природу, чем для ваших операций.
Пусть аванс - это монета.
Дали аванс - положил монету в кошелек и рад.
Вернул аванс - физически отнял часть монеты и вернул (вынул из кошелька, перевел между счетами и т.п.)
Сторно имело бы смысл, когда монета осталась бы там же (нет физического движения), но высокие договаривающиеся стороны считали бы е номинал вместо 10 заплаченных королевских риалов, например, за 8 по соглашению сторон. (В реальности, например, это уменьшение стоимости уже полученных товаров.)
Поэтому расход или перевод для сущности возврата аванса - самое "то".
 
Пусть аванс - это монета.
Дали аванс - положил монету в кошелек и рад.
Вернул аванс - физически отнял часть монеты и вернул (вынул из кошелька, перевел между счетами и т.п.)

Вы говорите об операциях перевода (в терминах программы), а с переводами никакой потребности в операциях с обратным знаком нет, т.к. все вопросы решаются обратными переводами. Точно так же будет при использовании двойной записи. А вот при кассовом методе, для которого только и имеют смысл операции прихода и расхода, аналогом корреспондирующего счета выступает статья расхода/прихода. И необходимость обратных проводок по статье есть объективная реальность, хоть "сторно" вы это назовете, хоть "аванс".
 
Самое обидное, что объективных причин чтобы запрещать отрицательные проводки - нет.
Сам пользуюсь способом: сказать "иииээээхххх..... *****"  и в зависимости от ситуации пользуюсь тем или иным способом.
Возможно, автор переубедитсяTo wink