создать новую тему раскрыть все
 
Скажите пожалуйста, а как правильно проводить возвраты денег?
Т.е. например я купил 2 вещи, провел "расход - 200 руб". Через пару недель одну из них вернул, в магазине мне вернули 100 руб - как их правильно провести? Приход - имхо неправильно, отрицательный расход - программа не дает ввести...
 
Я немного удивлен тем, что операция "отрицательного" расхода не вызывает у вас большего неприятия чем операция прихода.
 
Если вам так уж не нравится операция прихода, тогда создайте отдельный счет "Взаиморасчеты", операцию расхода, которую вы сделали при покупке товара измените на операцию перевода. А полученное возмещение оформите обратным переводом со счета взаиморасчетов на счет наличных.
 
А я, в своей базе данных, если у меня возникает ситуация, аналогичная вашей, просто удаляю операцию расхода. Как будто бы я и не покупал этот товар. Я просто не вижу смысла засорять базу данных лишней информацией.
 
Уважаемый разработчик! Вашу базу никто засорять не собирается. Пусть человек свою "засоряет". Вы считаете, что одни и те же 100 рублей можно заработать дважды? Было предложено самое оптимальное решение. Что сложного в реализации?
 
Мало того, я считаю что подобная возможность будет крайне вредна.
 
Однако, если есть таки желание сваливать операции прихода и расхода в кучу, то Вы легко можете этого добиться. Создаете новый классификатор, убираете в нем галочку "Разделять по виду операции" и пожалуйста: нет больше статей доходов и расходов, есть просто статьи. Можете по ним делать и приходы и расходы.
 
У меня операции прихода и расхода традиционно разделены, однако тоже регулярно возникает желание убрать галочку и иметь возможность проводить операции с обратным знаком. Останавливает только Ваше мнение и нестандартность решения (как правило в др. программах так делать нельзя).
 
...приходы по статьям расходов, то тогда может быть разрушена вся система учета. Собственно, деление классификаторов на деревья доходов и расходов для того и нужны, чтобы отделить доходы от расходов. Доходы, выполненные по статье расходов (и наоборот) выбиваются из этой схемы напрочь.
 
Еще один вопрос, который сразу возникает после разрешения доходов по статье расходов состоит в том, что непонятно как готовить отчет по оборотам по статьям. По уму просится такие доходы вычесть из расходов по этой статье. Но это противоречит общей логике подготовки таких отчетов, в которой просто суммируются все операции по соответствующим статьям расходов/доходов.
 
И, наконец, последнее. Как это вообще должно выглядеть с точки зрения user interface? Просто разрешить в операциях расхода вводить статьи дохода? Ну это и сейчас можно сделать если снять соответствующую настройку классификатора. Вводить какие-нибудь дополнительные функции в программе наподобие "Возврат суммы"? Честно говоря, я против такого решения потому что user interface и так перегружен.
 
Поэтому, повторюсь, я делаю довольно просто: если возвращается сумма по операции, которая была сделана всего день-другой назад, я просто удаляю (или корректирую) оригинальную операцию. Если же возврата денег придется немного подождать, то я создаю отдельный счет "Расчеты с магазином", на который скидываю оригинальный платеж, а потом, после возврата суммы перевожу эти деньги на счет наличных. В этом случае становится видно в дереве счетов, что мне магазин должен денег.
 
но иногда действительно удобно было бы списывать средства по статье дохода и наоборот. С точки зрения user interface это можно сделать просто вводя операции со знаком минус, при этом отрицательные суммы никак не должны влиять на логику отчетов. Ну вот простой пример: купили мы продуктов на 1000р., со скидкой по дисконтной карте 5%, вбиваем эту скидку как "-50р." по той же статье "Продукты" и получаем в отчете сумму 950р. в полном соответствии с чеком. Аналогично и возвраты.
А сейчас мы вынуждены использовать либо мутную схему с переводами "Расчеты с магазином" (что приемлемо для возвратов, но совершенно не годится для скидок), либо раздувать фиктивные обороты по статьям "Возвраты", "Скидки" и проч.
 
Если магазин продал мне товар на 50 рублей дешевле и мне эти 50 рублей "кровь из носу" надо отразить в учете, то это в чистом виде мой доход, а никакой не "отрицательный расход".
свернуть/развернуть ветвь См. мой ответ Dervish'у (-) [Amundsen 03/08/2010 12:30] # написать ответ
 
 
Вы получите доход по статье "Продукты" в 50 рублей. Если Вы производитель продуктов питания, то это нормально, это Ваша выручка. А если Вы (как и я) типичный потребитель продуктов питания, то, согласитесь, доход по статье "Продукты" выглядит нелогично. Well
 
Совсем другое дело, если эти 50 рублей провести по статье "Скидки". Это действительно полученная Вами скидка, такая операция будет отражать экономическую суть произошедшего. Кстати, впоследствии (при соответствующем учете) Вы сможете посчитать как полученные скидки по продуктам питания, так и скидки на заправке и т.д.
 
Ничуть не считаю обороты по статье "Скидки" фиктивными, думаю, что именно так и нужно делать. Ваш пример наглядно это подтверждает.
свернуть/развернуть ветвь И все же не согласный я ... [Amundsen 03/08/2010 12:29] # написать ответ
 
... считать скидку в 50р. доходом. Экономическую суть оно будет отражать на базаре, после упорных торгов по поводу цены продукта. Well
А в большинстве случаев скидка в супермаркете не является доходом, это просто составная ценообразования и если в чеке из магазина стоит общая сумма 950р., то это означает только то что я потратил на продукты 950р. И на базаре кстати тоже. А иначе так можно далеко зайти: если в яндекс.маркет средняя цена товара указана 15тр, а я приобрел тот же товар за 10, это же не означает занесение разницы 5тр по доходной статье?
 
Вопрос со скидками кстати бывает актуален: вот у меня рядом магазин одежды, где перманентно висит скидка 50%. Очевидно, что это не более чем маркетинговый прием и итоговая цена соответствует обычным ценам других магазинов, но в чеке скидка пробита отдельной строкой. Вот вам и раздутый в два раза оборот по статье "Одежда". А также явно фиктивный "доход".
 
Пример с яндекс маркетом, извините, дурацкий: никто не покупает за "среднюю цену", все покупают за цену, которую готовы платить.
 
Либо Вам нужно учитывать скидку, либо нет. Если нужно - то это именно та самая базарная сущность о которой вы упомянули. Магазин платит Вам, за принятие решения в его пользу.
 
Если же скидку учитывать не нужно, то непонятно о чем вообще разговор.
 
Мне не нужно учитывать скидку как статью дохода, все что мне нужно - это учитывать реальные суммы совершенных расходов. Если бы я мог прийти в магазин и объявив о своем решении в его пользу забрать бонус, тогда да, безусловный доход имел бы место быть. Но реально мне нужно просто соотнести общую сумму чека с покупками (при отстутствии чеков/сплитов в программе).
 
то это Вы и делаете:
Если бы я мог прийти в магазин и объявив о своем решении в его пользу забрать бонус, тогда да, безусловный доход имел бы место быть.

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

См. мой пример с яндекс.маркет: я делаю выбор в пользу магазина с более низкой ценой. Что не означает получение мною дохода, даже несмотря на время, потраченное на поиск низкой цены.
свернуть/развернуть ветвь Но в этом случае [Loki 03/08/2010 13:50] # написать ответ
 
у Вас нет никаких проблем с учетом - просто вписываете то, что написано в чеке.
Вы же хотите рассматривать тот случай, когда в чеке написана одна цена. а магазин Вам продал товар дешевле. Или Вы уже что-то другое хотите рассматривать?Well
 
я уже приводил пример магазина с постоянной скидкой 50%.
 
На самом деле проблема скидок имеет типовое решение, но в других программах, к сожалению: когда сумма чека не совпадает с суммой его позиций, разница либо сразу пропорционально раскидывается по позициям (программно), либо заносится в специальное поле ("Скидка") групповой операции (чека), значение которого опять же раскидывается по позициям в отчетах и бюджетах. Поэтому смысла спорить является ли скидка доходом я не вижу.
 
А при чём тут доход, если программа оперирует приходом?
 
я также могу спросить: причем тут приход, когда речь идет о расходе To wink
свернуть/развернуть ветвь Не совсем [Rodion 04/08/2010 16:09] # написать ответ
 
Да нет, не в терминологии. Доход - это средства, полученные в результате, какой-либо деятельности. А приход - поступление средств на счёт. Доход, это одна из составных прихода.
Скидка - это разница между предполагаемым расходом и фактическим. Лучше всего, её совсем не учитывать в программе. Если же, для отчётности, Вам это нужно, тогда - это скорее приход (Вы платите 100% и в тоже время продавец Вам возвращает 50%), ибо отрицательного расхода попросту в учёте не существует. Расход - это уже "-", а "-" на "-" равен "+", тоесть приходу
 
свернуть/развернуть ветвь Сорри, что-то глюкануло, [Amundsen 04/08/2010 16:58] # написать ответ
 
и сначала я не увидел весь текст вашего сообщения.
Скидка - это разница между предполагаемым расходом и фактическим. Лучше всего, её совсем не учитывать в программе.

В большинстве случаев эта разница есть лишь в рекламе и чеке магазина, а на практике нужно учитывать лишь итоговый расход. Но вот здесь и возникают сложности: мы не можем просто "не учитывать" (отбросить) сумму скидки без нарастающей погрешности. Само собой, речь идет о ничтожных суммах, но при сверке данных программы с выпиской по кредитной карте, эта погрешность будет раздражать. Но и приходом (а тем более доходом) эту скидку считать затруднительно, ведь речь всегда идет о расходе. А главное, что иногда суммы скидок бывают не сказать чтобы малозначимые и тогда, если следовать принципу единобразия и заносить их приходом, они приведут нарушению отчетности (см. выше пример скидки 50% на одежду).
Отрицательный расход это тоже костыли, но по крайней мере он позволит отражать реальные расходы по категориям в отчетах и бюджетах.
 
... а дисконтированный на 50р. расход Well
 
Как это вообще должно выглядеть с точки зрения user interface? Просто разрешить в операциях расхода вводить статьи дохода? Ну это и сейчас можно сделать если снять соответствующую настройку классификатора.

 
Попробовал снять соотв. настройку классификатора и получил следующую картину:
1. Как ожидалось, появилась возможность совершить приход по расходной статье (и наооборот)
2. В бюджетах оборот по расходной статье вычисляется с учетом совершенных приходов по этой же статье и это правильно, аналогично в отчете "Динамика оборотов"
3. В отчете "Обороты" с группировкой по статьям расходы и приходы считаются и показываются отдельно: т.е. расходы по расходной статье показываются в "Списаниях", а приходы по той же статье показаны в "Поступлениях". Т.е. одна и та же статья показана в разных секторах.
 
Мне кажется имеет смысл выводить в отчете "Обороты" результирующее значение по статье: таким образом, в случае когда расходы по стате превышают приходы за период, статья и ее итоговый результат показывается в секторе "Списания", в противном случае соотв. наоборот.
 
ЗЫ Речь идет о классификаторе со снятой галкой "Разделять по виду операции"
 
Почитал тут мануал на этот локомотив индустрии и обнаружил, что возмещаемые служебные расходы они рекомендуют делать через приходную категорию "Business Reimbursements":
Every time you spend money on reimbursable
expenses (like parking), assign the transactions to
Business Reimbursements. Then, when you run an
Itemized Categories report (page 310), the value for
Business Reimbursements shows up as a negative
number—your cue that you’re still waiting for your
reimbursement.
 
When you receive your check for reimbursed
expenses, assign the deposit to the Business Reimbursements
category as well.

Так что, по крайней мере "отрицательный приход" наверное таки имеет право на жизнь. Well
свернуть/развернуть ветвь Мне показалось [Loki 23/08/2010 17:57] # написать ответ
 
что описанная в цитате методика в точности совпадает с отдельным нулевым счетом "Business Reimbursements".
 
а счет используется в соответствии реально проведенной транзакцией. Вот рекомендация в полном варианте:
 
Tracking Reimbursements
 
If your company or volunteer association reimburses you
for expenses, a category for tracking your reimbursements
can help you make sure you receive all the money you’re
due. Here’s how:
 
1. Create an income category called, say, Business
Reimbursements. (You could just as easily use an
expense category, but income categories are usually
fewer in number and thus easier to spot.)
 
2. Every time you spend money on reimbursable
expenses (like parking), assign the transactions to
Business Reimbursements. Then, when you run an
Itemized Categories report (page 310), the value for
Business Reimbursements shows up as a negative
number—your cue that you’re still waiting for your
reimbursement. In fact, you can use that Itemized
Categories report to prepare your expense report.
(Creating a customized report [page 447] that shows
only the Business Reimbursements category makes
it easy to see what you should claim.)
 
3. When you receive your check for reimbursed
expenses, assign the deposit to the Business Reimbursements
category as well. You’ll know you’ve
been reimbursed for all your expenses when the
total for this category is zero or equal to the amount
of unreimbursed expenses.

 
Bonnie Biafore. Quicken 2009: The Missing Manual
 
 
В рекомендациях лучших пингвиноводов от GnuCash усмотрел следующее:
Общей ошибкой является ввод возвращенных денег как доходы. Это не доходы, а скорее "отрицательные расходы". Именно по этой причине вы должны перевести деньги с расходного счета на счет кредитной карты при получении возврата средств.

A common mistake is to enter a refund as income. It is not income, but rather a “negative expense”. That is why you must transfer money from the expense account to your credit card when you receive a refund.

 
В оригинале этот "отрицательный расход" обзывается "Refund" (п. 6.5.3)
свернуть/развернуть ветвь Читай внимательней: [Karu 05/01/2015 12:17] # написать ответ
 
Общей ошибкой является ввод возвращенных денег как доходы. Это не доходы, а скорее "отрицательные расходы". Именно по этой причине вы должны перевести деньги с расходного счета на счет кредитной карты при получении возврата средств.

 
Чистейшей воды приход!
 
И, вообще, там ведут учёт при помощи двойной записи, которая уже более 500 лет назад решила данную проблему. Так что, я не понимаю о чём вы тут ещё спорите!
 
Речь идет как раз о двойной записи, где "расходный счет" соответствует статье расхода в Ability.
 
А спорим мы как раз из-за невозможности в Ability списать с расходной статьи как в примере выше.
 
В бухгалтерии по сути две операции "приход" и "расход". Назовите их "сложение" и "вычитание", если Вас смущает термин "приход".
 
Вводить суммы с минусом - зло.
 
если мы решим быть столь педантичными в их применении, то для тех же скидок у нас будет только один выход: пропорционально разносить дисконт по позициям чека вручную. Но лично мне решительно лень это делать и посему отрицательный расход выглядит несколько меньшим злом Well
свернуть/развернуть ветвь не все так просто, [пацак],[ 08/08/2010 12:59] # написать ответ
 
при покупке лекарств скидка не "пропорциональная", - на отечественные есть и большая, на импортные ее может не быть вообще.
Если нет времени - не парься с учетом скидок.
А есть время - возможны варианты учета :
1. в расход вбивается сумма по чеку + скидка. Скидка оформляется приходом по статье бонус по данному агенту (магазину, аптеке) той же датой.  Таким образом, итог всегда правильный и существует возможность оценить "лояльность" к покупателю того или иного магазина по сумме скидок.
2. многие супермаркеты предоставляют "накопительную" скидку, которую можно в какой-то момент реализовать при очередной покупке в этом супермаркете. Обычно такая скидка на следующий год не переходит. Так вот, такие скидки лучше оформлять невыполненным приходом по статье бонус по данному агенту. В очередной раз направляясь за покупкой, профильтровал по данному агенту накопленные бонусы и имеешь предствалнеие, на сколько можно уменьшить затраты на очередную покупку.
Что касается возвратов. Их все-же лучше выполнять положительным приходом по отдельной статье. Знакомый купил диван за несколько сот у.е. После более полугода экплуатации через общество потребителей вернул диван в магазин по причине хронического скрипа подушек дивана. От покупки нового дивана в этом магазине отказался. Если операцию покупки отменить, как предлагалось, либо вернуть деньги днем покупки, то не будет видно, что "оборотные средства" моего знакомого в течение полугода были на несколько сот у.е. меньше ...
Про учет скидок в магазинах, где купальник стоит 2500 у.е. а скидка составляет -70% круглый год, говорить нечего. Такие магазины существуют вне правил какого-либо учета.
 
по поводу лекарств: из любого правила всегда есть исключения. Однако по моему опыту, подавляющее большинство скидок преоставляется на всю сумму покупок.
 
не париться с учетом скидок не получается: заметная часть моих расходов идет по карте и хотелось бы совпадения банковской выписки и остатков по счету КК в программе.
 
По варианту #1 скажу, что именно так я сейчас и веду учет, поэтому и вижу его недостатки.
Оценивать лояльность магазина наверное нет смысла: разброс цен во времени на один и тот же товар в рамках одного и того же магазина часто превышает суммы скидок.
 
Накопительные скидки я учитываю аналогично варианта #1, с начислением рублевой стоимости "баллов" на счет бонусной карты ("Пререкресток"). Мелкие покупки (хлеб) я в реале оплачиваю "баллами" с карты и при таком подходе учет этих операций в программе не вызывает вопросов.
 
Возвраты можно учитывать по-разному. У меня собсно возвратов пока не было, но имела место реализация ранее купленных товаров на "вторичном рынке". Пока я обходился приходной статьей "Реализация", но есть мысли завести в счетах группу "Имущество" и такого рода операции проводить переводами по соотв. счетам.
 
Магазины, которые "существуют вне правил какого-либо учета" все равно приходится как-то учитывать и помимо "скидка круглый год" есть еще интересный в плане учета вариант "купи три по цене двух". Well
 
Изначально речь шла о возврате товара.
Лично я проводил бы как это положено в виде прихода. Ведь по сути проводка это отражение движения материальных ценностей в реальной жизни.
 
Теперь о скидках. Мне кажется, что Вас не интересует дисконт в разрезе товаров. Ведь по сути дисконт имеет значение только в разрезе поставщиков.
Пожалуй я бы завёл отдельный счёт "Дисконт поставщика №1" на который начислял бы бонусы.
 
но на примере возврата товара. Я лишь дополнил тему примером со скидками, поскольку ИМХО именно здесь "отрицательный расход" имеет отраженный в реальности смысл.
Мне кажется, что Вас не интересует дисконт в разрезе товаров. Ведь по сути дисконт имеет значение только в разрезе поставщиков.

Вот как раз в разрезе поставщиков мне дисконт не интересен. Да и в разрезе товаров строго говоря тоже: мне вообще не интересен дисконт как таковой, меня интересует точное занесение расходов по категориям.
 
Возврат товара как правило спорадическая операция, которая на учет сильно влиять не будет. Возвраты дорогостоящих товаров можно проводить через спецсчет "Имущество".
свернуть/развернуть ветвь Скидки [Rodion 13/08/2010 17:18] # написать ответ
 
Когда-то, видел похожую на нашу програмку, где была возможность в окне внесения расходов вносить скидки на товар. Но, программа, была специально создана для учёта домашних покупок. Для нашей прграммы, это, по моему, ненужное усложнение
 
и эта возможность есть как минимум в четырех известных мне финансовых программах. И еще в одной она "временно отключена" из-за общих недоработок системы.
Хотя я веду речь уже не об "отрицательном расходе" (это не более чем костыли), а о группировке операций в чек, которая решает эту проблему.
 
просто удаляю операцию расхода. Как будто бы я и не покупал этот товар. Я просто не вижу смысла засорять базу данных лишней информацией.

Аналогично Well ...
 
операцию по карте уже не вернешь иначе сверить остатки будет тяжело. В итоге в отчетах имеем раздутые обороты по доходам и расходам. Ну и ладно...
 
В этом месяце прошло несколько совместных мероприятий, по которым я расплачивался кредиткой, а другие участники возмещали мне свою долю участия наличными. В программе вводил операции по факту: т.е. полные суммы расходов по соотв. статье, а возмещения по приходной статье "Возвраты долгов". В результате имею правильный баланс по всем счетам, но совершенно искаженную картину оборотов по статьям дохода-расхода.
Видимо отрицательные суммы в операциях таки могут быть полезны.
 
Как вам такой вариант?
 
При оплате делаем:
- "за себя" расход со счёта кредитки по нужной статье
- "за других" - переводы со счёта кредитки на соотв. счета долгов ("Иванов", "Петров", "Сидоров" ...) - всё равно ведь надо считать, кто сколько должен - почему этого не сделать сразу?
 
При возврате долгов наличными делаем
- обратный перевод со счёта долгов ("Иванов") на счёт "кошелёк"
 
Итого:
- баланс по всем счетам правильный
- доходы-расходы адекватные (расходы только "за себя", доходов "ниоткуда" нет)
- а деньги, по итогу, просто перешли с кредитки в кошелёк (через соответствующий счёт долгов)
- и ... никаких отрицательных сумм Well
 
Единственное, что здесь и правда было бы полезно - это т.н. "сплит-транзакции" - чтобы одной (составной) транзакцией описать исходную трату по кредитке. Но, на мой взгляд, это не так и критично.
 
а когда статей несколько, то расход по каждой из них придется дробить по числу участников.
 
Если же, например, "для себя" вы считаете еду в ресторане отдельно от напитков (например), то совсем не обязательно их отдельно учитывать и для должников:
- расход: 800р - еда
- расход: 600р - напитки
- перевод: 1500р - долги > Иванов
- перевод: 1200р - долги > Петров
 
Но, в общем случае, да, придётся делить все совместные расходы по количеству участников. И этого вам не избежать ни при какой схеме учёта - те же самые "отрицательные суммы" этого никак не изменят.
Вы ведь хотите знать, кто, сколько и за что вам должен? А иначе будет:
- Эй, Вася, с тебя 400р!
- За что это?
- Не помню. У меня вот тут записано.
(сравните с: "Вася, с тебя 200р за билет в кино и ещё 200 за попкорн с колой")
 
если упростить ситуацию и не заморачиваться с учетом долгов (в моем случае возмещение имело место сразу с допустимой погрешностью), то ваш вариант можно представить как:
Картсчет - расход: 800р - еда
Картсчет - расход: 600р - напитки
Картсчет - перевод: 2700р - Наличность
 
аналогичный вариант с отрицательной суммой будет выглядеть примерно так:
Картсчет - расход: 2300р - еда (вся еда по чеку)
Картсчет - расход: 1800р - напитки (все напитки по чеку)
Наличность + расход: 1500р - еда (возмещаемая еда)
Наличность + расход: 1200р - напитки (возмещаемые напитки)
 
это позволяет вводить чек "как есть", просто дополняя его сторнирующими операциями.
 
просто удалить - сбиваются остатки, как минимум.
Плюс заплатить я мог с кредитки, например, а вернули мне наличными
 
Бухгалтерский и налоговый учет скидок
 
3.2. Скидки, предоставляемые после покупки
3.2.2 Учет  у покупателя

 
В журнале регистрации счетов-фактур зарегистрирован «отрицательный» счет-фактура, полученный от продавца при предоставлении скидки.
 
отменить операцию или ее часть, признав ее недействительной? Это отличается от простого удаления тем, что сохраняется информация об операции, которая может потребоваться позднее, например при разборе полетов.
 
... начатой здесь: http://www.dervish.ru/forum-theme.2665/#p15502
поскольку тему считаю важной.
 
Какое бы не было отношение к отрицательным суммам, они являются неотъемлемой частью бухгалтерской практики известной под именем "сторно". Не вижу смысла избегать этого, тем более что многие типовые задачи получат очевидное решение.
 
в составных операциях будут автоматически заполняться некоторые графы, а значит сторно будет необходимо.
иначе придется разблокировать заблокированные графы.
пример - возврат тухлятины как одной позиции по чеку с большим количеством наименований.
либо сторно, либо менять местами дебет и кредит, которые будут заблокированы.
 
зы
надо еще разрешить использовать программу для журналирования - разрешить ввод с нулевой суммой.
свернуть/развернуть ветвь Таки приход))))) [Rodion 31/07/2010 16:33] # написать ответ
 
Я просто не вижу смысла засорять базу данных лишней информацией.

 
Ув. Дервиш, это корректно, если между покупкой и возвратом небольшой промежуток времени. Но, если это несколько дней, теряется реальная картина остатка в промежутке этого времени.
Хотя, я тоже не понимаю автора темы. Возврат денег за возвращённый товар - это и есть самый настоящий приход. Рекомендую ввести статью прихода: "Возвращение денег за невостребованный товар" (или что-то в этом роде), а в примечании к операции указывать по какой статье была произведена первоначальная операция (покупка)
 
.
свернуть/развернуть ветвь . [starcat 18/08/2010 21:03] # написать ответ
 
Возможно терминологическая путаница, меня интересует не "расход", а потраченное.
Например :
1) купил что-то за 100
2) попробовал, не оно, через пару недель вернул в магазин, магазин вернул мне 90 (10 удержал за услугипочты).
3) купил другое за 150
 
по вашей схеме (сделать 90 приходом), получится что за этот период расход 250, приход 90.
Мне бы хотелось видеть "расход 160, приход 0".
 
Чтобы получить в отчете цифру 160, сейчас в момент (2) надо:
- найти исходную транзакцию
- удалить ее
- посчитать, сколько магазин удержал с меня, добавить той датой расход на эту сумму (10)
- сделать перевод на счет "долги" на 90
в текущую дату добавить перевод со счета "долги" на 90
 
Хотелось бы упростить это (особенно когда приходится делать это относительно часто).
 
А путаница, пожалуй, из-за терминологии. По сути в программе дебетовый и кредитовый оборот, который правильно проводить проводками. Ведь оборот то был. А так как в этой программе это называется приходом/расходом, то и возникает желание это поправить.
 
Как поступить в Вашем случае я не знаю. Но мне по крайней мере понятно Ваше предложение.