создать новую тему раскрыть все
 
Коротко опишу то, с чем столкнулся.
 
Зарплата у меня сдельная, но оплачивают ее позже и по частям, а поэтому потребовался отдельный счет "Начисленная зарплата".
То есть я отдельно накапливаю на этом счете сколько денег заработал, но которые пока мне не выплачены, а потом эти денюжки (в момент выплаты) операцией "перевод" отправляются на счет "наличные". Таким образом я всегда знаю сколько мне работодатель должен (а иногда и выплатил вперед).
 
Есть у меня такая категория "Статьи" (расходов, доходов).
 
Поставил галочку в чекбокс "Разделять по виду операции"
 
В списке появилось 2 раздела: "Все статьи прихода" и "Все статьи расхода"
 
Ввожу статью прихода "Зарплата"
При вводе операции перевода из начисленной зарплаты в наличные (то есть фактического получения денег) не могу выбрать ни какой статьи.
 
Ставлю чекбокс "Использовать в переводах"
 
Появляется отдельный раздел "Все статьи перевода"
И в него нужно вводить отдельную статью "Зарплата".
 
Так вот, не удобно то, что для переводов нужно вбивать дублирующие статьи. То есть получается, что статья доходов "Зарплата" у меня отдельно "Зарплата приход" и "Зарплата перевод"
 
А мне нужно, чтобы это была одна статья.
 
> А мне нужно, чтобы это была одна статья.
 
Как я понимаю, это не самоцель, верно?
 
Итак, что вам нужно? Смею предположить, вам нужно всегда знать начисленную и выплаченную сумму. И соответственно, разницу между ними, чтобы понимать, сколько должен работодатель.
 
В этом случае я бы поступал так: в момент начисления заработной платы я вводил бы сумму начисленной зарплаты в виде невыполненной операции прихода. А в момент выплаты, я отмечал бы эту операцию как выполненную.
 
В графиках остатков по счетам можно посмотреть не только реальное изменение остатков по счетам, но и предполагаемое изменение остатков, если бы все операции были бы выполнены. Этот остаток рисуется красным пунктиром.
 
Кстати, возвращаясь к вашему вопросу, я себе не представляю, как это одна и та же статья может быть и статьёй прихода и статьёй перевода. Нелогично выходит.
 
Но если уж очень-очень нужно, то, думаю, следует создать классификатор и установить в нём признак "Не разделять по виду операции".
свернуть/развернуть ветвь Мысль понятна [Percent 15/08/2005 03:48] # написать ответ
 
>В этом случае я бы поступал так: в момент начисления заработной платы я вводил бы сумму начисленной зарплаты в виде невыполненной операции прихода. А в момент выплаты, я отмечал бы эту операцию как выполненную.
Начисленное и выплаченное совсем может не совпадать по сумме (накапливается одними частями, а выплачивается другими частями), и поэтому такой способ не особо подходит.
 
Поэтому был выбран более бухгалтерский способ в виде отдельного счета, и перевода со счета "начислено" на счет "наличные" (кстати, кое-что со счета "начисленные" переводится на погашение кредита напрямую, минуя наличные).
Подходов может быть много для организации учета.
свернуть/развернуть ветвь продолжение [Percent 15/08/2005 03:49] # написать ответ
 
>Кстати, возвращаясь к вашему вопросу, я себе не представляю, как это одна и та же статья может быть и статьёй прихода и статьёй перевода. Нелогично выходит.
 
Если рассматривать классическую бухгалтерию, то приход - это результат перевода, ибо ни что ни откуда само по себе не берется. В классическом учете денег принцип двойной записи не соблюдается (то есть налицо разрывы учета (учитывается не всё, а только то, что нужно)), и это понятно, потому, что иначе будет до такой степени всё сложно, что ни какого учета не захочется.
 
На самом деле очень часто требуются одни реквизиты в счете с которого перечисляются деньги и совсем другие реквизиты на счете, на который перечисляются деньги. Этого можно в данном случае достигнуть только отдельной операцией прихода и отдельной операцией расхода.
свернуть/развернуть ветвь продолжение [Percent 15/08/2005 03:50] # написать ответ
 
Хотя если в денежную программу ввести серию стандартных шаблонных операций, чтобы по сто раз не вводить одно и то-же (с определенными по умолчанию реквизитами), если операция стандартная. И тоже выстроить их в виде дерева.
 
Например, покупаю я строительный материал для дачи, выбираю из древовидного шаблона пункт стройматериалы для дачи. А у меня автоматически заполняются все необходимые для этой операции поля: Расход, со счета "наличные", проект "строительство дачи", объект "дача", статья расхода: "материалы/стройматериалы", допустим делаю небольшую поправку "материалы/стройматериалы/кирпич", для уточнения назначения платежа.
 
И всё. Да, конечно, потребуются дополнительные предварительные настройки, но это окупается потом скоростью ввода.
 
Желательно, чтобы такой шаблон мог сделать несколько связанных операций по разным счетам.
 
Именно поэтому в классической бухгалтерии есть отдельно журнал проводок и журнал операций.
 
(Ладно, это я уже в дебри полез)
 
Но если уж очень-очень нужно, то, думаю, следует создать классификатор и установить в нём признак "Не разделять по виду операции".
 
Так я и сделал, искуственно введя приход и расход как элемент дерева (отрицательно, что показывается все дерево при заполнении операции)
 
Вроде как Dervish грозился сделать шаблоны операций, если не в ближайшей сборке, то во всяком случае в одной из ближайших версий.
 
"Счета" - то что есть сейчас
"Журнал операций" - то что нынче называется "Операции".
"Операции" - дерево стандартных операций, страница для для настроек стандартных операций
и так далее что есть... Конечно еще хотелось бы журнал проводок, но это уж совсем бухгалтерия....
свернуть/развернуть ветвь А я уже сомневаюсь, нужны ли... [В.Червонных 16/08/2005 23:36] # написать ответ
 
статьи вообще.
Неограниченное количество ветвящихся счетов, на мой взгляд, вполне их заменяет.
Работать можно на нескольких работах, поэтому у счета "Расчеты с работодателями" могут иметься субсчета по конкретным работодателям, например.  
Кстати, я не понял, используете ли Вы метод двойной записи (переводы) в большинстве случаях, или это редкое исключение?
Здесь уже собралось несколько адептов практически сплошной двойной записи, в том числе и не ортодоксальной - не просто с переводами  между счетами в одной и той же валюте, но  с переводами между счетами разной природы: один денежный, другой натуральный. Это позволяет поддерживать основный элементы складского учета.
Нам очень не хватает возможности строить отчеты по динамике оборотов для наших операций, но мы не устаем надеяться, что Дервиш все ещё помнит про эту дедоделку ;-)
свернуть/развернуть ветвь Re: "ДедоДелку" это 5 :))) [Explorer 18/08/2005 20:26] # написать ответ
 
ЖNeutral
 
Неограниченное количество ветвящихся счетов, на мой взгляд, вполне их заменяет.
Есть определенные пределы разумного.
 
Кстати, я не понял, используете ли Вы метод двойной записи (переводы) в большинстве случаях, или это редкое исключение?
Прога заточена под расходы/доходы.
В ряде случаев переводы (там где требуется дальнейший учет и движение, например материальных активов), а в ряде - просто списание средств со счета (продукты и прочие личные расходы).
 
Я отношусь к этому, как к журналу операций, а не как к журналу проводок. И в скором времени, вероятно, я оптом переоформлю ряд расходов в переводы.
 
Пример: Еду я куда-нибудь по делу, у меня транспортные расходы.
Если я еду по 1 делу, то понятно, всё списывается на это. А если дела 2 или 3 и нужно их разнести в определенной пропорции по статьям расхода или по агентам... Часто бывает нужно, и в ряде программ есть.
 
 
разбить его на простые счета затраты1\дела,
затраты2\дела и т.д., а потом операциям перевода разнести в определенной пропорции?