Про количественный учет (ещё раз)

Про количественный учет (ещё раз) IF 14/10/2005 12:43 #

Почитав интересные темы на форуме
(например
http://www.dervish.ru/forum.php?theme_id=927&forum_id=1)
в голове засела назойливая мысль реализовать подобный учет!
1. вооружившись полученными рекомендациями сделал следущее:
1. В дереве счетов созданы:
+Материалы
++Склад
+++Балка
++++18
++++25
++++35Ш1
+++Газы
++++Кислород
++++Углекислота
+++Грунт
и т.д. по наименованиям
++Производство
аналогичные подсчета для списания материалов в производство

2. В валютах созданы:
кг-блк-18
кг-блк-35ш1
балл-кслрд
балл-углкслт
простые кг и балл не подходили, потому как хотелось потом пересчитывать штуки в рубли, а стоиость разных материалов различна.

3. При введении операций создаю текущий курс необходимой валюты к валюте RUR
(наприер на 01.09 1кг-блк-18 = 16RUR )

продолжение IF 14/10/2005 12:43 #

В процессе добавления операций возникли трудности/вопросы:
Например 01.09 операция прихода материалы/балки/18 +200 кг-блк-18 по курсу 16 ру/кг, а потом 05.09 ещё одно поступление, скажем +500 кг-блк-18 и уже по 20 ру/кг.
Когда попросил программу пересчитать остатки на 03.09 в RUR, выдаёт НЕ 3200ру (200*16) а нечто сренее между 3200ру и 14000ру. Причем! Каждый день остаток меняется! то есть на 04.09 он становиться больше чем на 03.09, хотя прихода по счету не было и курсы никто не менял. Интересно что остатки на 05.09 становяться 14000ру (200кг+500кг)*20кг/ру, а на 06.09 продолжают расти!
Насколько понял проблема связана с алгоритмами пересчета курсов?
Возможно ли делать "непересчет" курсов валют до их явного изменения?
А может удасться как-нибудь ещё и среднюю стоимость считать? %-))

2. Посокольку через балкокилограммы ничего не выходило поробовал сделать так:
1. Создал счет Материалы/Балка/18 с валютой RUR
2. При вводе операций использовал "цену за единицу" и "количество"
(например, 16ру за шт и 200шт в количество)
3. После ввода аналогичных операций на 01.09 и 05.09 на странице операций остаток по счету на 05.09 составил 14000ру, а вот где поглядеть общее колчество в шт?

Надеюсь я сумел объяснить чего хотел и чего не получилось...
Может сущетсвует способ попроще? Или же не получится у меня пока и штуки знать и их стоимость узнавать сразу же?

Заранее буду благодарен за любые разъяснения!

комментарий по первому варианту ... are 16/10/2005 16:03 #

причина неправильных остатков давно известна. Это аппроксимация курсов валют, заложенная в программе. С точки зрения бухгалтерского учета она является нонсенсом - т.к. курс (в вашем случае цена за изделие !!!), установленный раз, должен действовать до следующего своего изменения - никаких промежуточных плавных, среднеарифметических, среднеквадратических и других значений.
Если кому то и может понравиться аппроксимация, то это дилерам, аналитикам для оценки поведения активов в будущем в связи изменением курсов валют; для принятия решений, как сохранить и приумножить активы. Но в программе заложен один алгоритм аппроксимаци, а в природе их существуют десятки ... К тому же, в программе нет интерфейса для такого моделирования, впрочем, это и не требуется.

По зрелому размышлению... Dervish 17/10/2005 13:02 #

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

Согласен и про "фишку учета"#2 IF 17/10/2005 13:54 #

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

Касательно реализации учета количества.
В том случае, если я пользуюсь именно потоварнымивалютами (кг-блк-18, кг-блк-35ш1, балл-кслрд) то остаток считается соответствено в штуках, килограммах, баллонах. А каким образом лучше всего реализовать паралельный учет и имеющегося в наличии имущества и его стоимости. при чем стоимости не по последнему указанному курсу, а по по его реальной стоимости.
Это необходимо для учета отпускаемых материалов в производство. (в бухгалтерии с этой задачей справляются очень тяжело и как обычно с большой задержкой) И хотелось чтобы кладовщик ведя записи по штукам, тоннам и тд мог не только сказать Сколько было отгружено, но и на какую реальную(а не по последнему указанному курсу) стоимость.

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

Или быть может кто-то из завсегдатаев подскажет другую программку специально для учета материалов? А то сил больше нету в бумажках листаться и каждый раз всё ручками пересчитывать.

О товарном учёте. Dervish 17/10/2005 14:05 #

Я об этом уже как-то говорил в форуме, но это было довольно давно. Повторю: я никогда не занимался складским учётом и эта тема для меня совершенно незнакомая. Поэтому Cash (AbilityCash) никогда и не замахивался на ведение товарного учёта. Идея использовать валюты для поштучного учёта товаров возникла уже по ходу работы над программой. И, понятно, эта идея не может решить абсолютно все задачи складского учёта.

Тем не менее, мне хотелось бы уточнить одну вашу фразу: "не по последнему указанному курсу, а по по его реальной стоимости".

Скажите, пожалуйста, что именно вы имели в виду? Разве стоимость по текущему курсу не является реальной стоимостью товара?

Все зависит от метода ... IF 17/10/2005 15:47 #

Чтобы было аккуратнее приведу небольшой пример:
Приобретение товара (операции прихода на счет склад)
01-10-05 10 кг-уголок по курсу 15 ру/кг
05-10-05 15 кг-уголок по курсу 14 ру/кг
10-10-05 20 кг-уголок по курсу 10 ру/кг

Таким образом всего на складе (остаток по счету)должно быть 45 кг-уголок, а вот по пересчету в рубли должно по замыслу получиться 15*10 + 14*15 + 20*10 == 560 ру

и все было бы здорово, но материалы приходися отдавать в производство  не в те дни, когда они приходовались на склад, то есть продолжение примера:
передача материалов на склад (лидо расход по счету склад, либо перевод на счет "в производстве")
15-10-05 12 кг-уголок по... По какой цене? И на какую сумму?
либо сначала списывать 10кг по 15ру/кг + 2кг по 14 - метод FIFO,
либо все 12кг по 10 ру/кг из последнего прихода - метод LIFO.
Либо же пересчитать среднюю цену одного кг-уголок и списывать по ней, т.е. те самые 560ру / 45 кг = 12,444 ру/кг. И, таким образом,  отдаем в производство 12 кг-угоок (по средней цене) 12,444ру/кг = 149,28 ру
Если не ошибаюсь были и другие методы, но сейчас вот так не вспомню %-)

Таким образом от выбранного метода меняются остаки по счетам и соответсвенно, когда, конце месяца, делается анализ деятельности, показатели во многом будут зависеть от выбранного метода.

Не могу судить насколько сложно реализовать механизмы подобного учета в программе. И не знаю стоит ли реализовывать все возможные. Но вот было приятно.

Надеюсь смысл фразы стал яснее. =)

понятно IF 17/10/2005 13:31 #

Я на само деле догадывался "где собака порылась".

аппроксимация на колличество и цену Дмитрий 08/02/2010 07:37 #

В вашей программе как раз не хватает "Планирования". То есть анализа цены на кг(шт.). В отчётах хорошо будет видна тенденция или "Больше стали кушать", или "Дорого стали кушать". Так же легко можно оценить наценки на конкретные товары за требуемый промежуток. Аппроксимация необходима, т.к. нужны субъективные прогнозы изменения расходов на ближайшее время и это как раз основывается на количестве + цене за кг(шт).

В к сожалению в табличках работать пока гораздо удобнее.

Поскольку в упомянутой ветке я... В.Червонных 18/10/2005 22:40 #

участвовал, сообщаю, что накопленный с тех пор опыт позволяет утверждать, что на штучные материалы оптимально иметь единую валюту - штуки, без уточнений штук "чего именно". (Счетов штучных, действительно, должно быть много и штук "чего именно" всегда можно увидеть, рассматривая дерево счетов)Часто те же материалы имеют дополнительную характеристику, например, вес. Тогда для этого материала появляется подгруппа весовых счетов, с одной и той же валютой кГ.
В чистом товарном (кГ<-->шт) учете создавать конкретные курсы вообще не следует, достаточно прогнать по родственным счетам, превратив например, в момент покупки или выставления счета штуки для конкретной номенклатуры партии уголка в вес данной партии. Да я и вообще обхожусь без ввода курсов, указывая соотношения валют в каждой операции.
Должен сказать, что мои связи с поставщиками товаров отличаются стабильностью и проблемы учета одного и того же товара, купленного по разной цене, у меня не возникало. Если бы возникла, пришлось бы, наверное, дерево счетов для таких товаров строить с введением дополнительной промежуточной родительской подгруппы, конкретные счета в которой отражали бы покупку того же товара по новой цене (если бы приспичело учитывать такие детали). Жаль, что новые родительские подгруппы счетов, кажется, невозможно вводить в процессе работы, а надо заводить заранее.

неа... хочется гибкости! IF 03/11/2005 13:59 #

"накопленный с тех пор опыт позволяет утверждать, что на штучные материалы оптимально иметь единую валюту - штуки, без уточнений штук "чего именно"."

Штуки-то оно конечно штуки. Но хотелось бы знать также и их цену. Причём именно в этом и возникает вопрос. Надо не только знать сколько там (на складе) кг этого уголка и сколько со склада передается, например, в произвоство(благо это дейтсвительно ACash делает легко и непренуждённо), но и представлять сколько ЭТО всё стОит. Чуть выше/раньше я пытался разъяснить где возникают косяки и что должно бы получаться на самом деле.

накопленный к 2010 опыт? Smart 06/01/2010 15:16 #

Ребята, приблизились к решению?

Хотелось бы узнать, как обстоят дела сейчас?

Я тут затеял небольшой торговый бизнес ( http://magicrabbit.ru ) - и первый месяц показывает, что действительно важно знать, почем обошлась каждая конкретная штука товара.

Бывает, из поставщика получается выбить дополнительную скидку. Бывает, доставка до моей родной Самары выходит дороже запланированного и т.д.

P.S. Может быть нашлись какие-то другие варианты решения или другие программы?

позвольте Андрей 14/02/2010 11:11 #

А если просто в алгоритмы подсчета стоимости валют, внести хотябы одну валюту (я видел маленькую прогу которая подсчитывает несколько параметров (льготы, плату за эл.энергию))

Форум Про количественный учет (ещё раз)