[abilitycash] |dervish.acash| Найдены 2 ошибки в 203 05511.05520
По классификатору
← Октябрь 2005 → | ||||||
1
|
||||||
---|---|---|---|---|---|---|
5
|
||||||
21
|
23
|
|||||
29
|
||||||
За последние 60 дней ни разу не выходила
Сайт листа:
http://www.dervish.ru/
Открыт:
30-01-2004
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.others.abilitycash-list@subscribe.ru
Адрес
модератора: comp.soft.others.abilitycash-owner@subscribe.ru
По классификатору
Все зависит от метода ...
Чтобы было аккуратнее приведу небольшой пример:
Приобретение товара (операции прихода на счет склад)
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 ру
Если не ошибаюсь были и другие методы, но сейчас вот так не вспомню %-)
Таким образом от выбранного метода меняются остаки по счетам и соответсвенно,
когда, конце месяца, делается анализ деятельности, показатели во многом будут
зависеть от выбранного метода.
Не могу судить насколько сложно реализовать механизмы подобного учета в программе.
И не знаю стоит ли реализовывать все возможные. Но вот было приятно.
Надеюсь смысл фразы стал яснее. =)
Согласен с Вами
такое поле, конечно, будет показывать любой имеющийся в базе классификатор. Какой
нужен - такой и кажет. Но не более одного. Это же упрощение обычного (несложного)
ввода, который составляет большинство записей в базе. А если нужно указывать
несколько классификаторов, то и здесь ведь экономия налицо - начало то уже положено.
Но если мы говорим о том, что пользователь постоянно вводит несколько классификаторов
- то это уже Вы решаете с помощью Ваших шаблонов, на которые я очень надеюсь.
У меня в одной базе 2 классификатора, в другой - 3.
Кстати, еще идея:
А что если у полей фильтра операций в журнале поставить галочку <<использовать
при вводе>>? Я говорю про: <<Показывать операции:>>. Когда в поле классификатора
на вкладке операций есть выбор, (напр. Клиент: Пупкин В.В.) и журнал фильтруется
по этому классификатору - то при вводе этот клиент будет подставляться по умолчанию.
Это как со счетами - какой выбран, того и вводимые операции.
О товарном учёте.
Я об этом уже как-то говорил в форуме, но это было довольно давно. Повторю: я
никогда не занимался складским учётом и эта тема для меня совершенно незнакомая.
Поэтому Cash (AbilityCash) никогда и не замахивался на ведение товарного учёта.
Идея использовать валюты для поштучного учёта товаров возникла уже по ходу работы
над программой. И, понятно, эта идея не может решить абсолютно все задачи складского
учёта.
Тем не менее, мне хотелось бы уточнить одну вашу фразу: \"<i>не по последнему
указанному курсу, а по по его реальной стоимости</i>\".
Скажите, пожалуйста, что именно вы имели в виду? Разве стоимость по текущему
курсу не является реальной стоимостью товара?
Согласен и про "фишку учета"#2
Просто эта функция малозаметна (вернее совсем незаметна) если ежедневно следить
за курсами валют и вбивать их. Но валют всего ничего, а вот стоимостей товаров
море и перезабивать все это море ежедневно просто невозможно. Поэтому, конечно,
отключение этой фишки насовсем - приятная необходимость, ну или, в том случае
если это необходимо, сделать дополнительный чекбокс в настройках (вкл/выкл апроксимацию
курсов)
Касательно реализации учета количества.
В том случае, если я пользуюсь именно потоварными валютами (кг-блк-18, кг-блк-35ш1,
балл-кслрд) то остаток считается соответствено в штуках, килограммах, баллонах.
А каким образом лучше всего реализовать паралельный учет и имеющегося в наличии
имущества и его стоимости. при чем стоимости не по последнему указанному курсу,
а по по его реальной стоимости.
Это необходимо для учета отпускаемых материалов в производство. (в бухгалтерии
с этой задачей справляются очень тяжело и как обычно с большой задержкой) И хотелось
чтобы кладовщик ведя записи по штукам, тоннам и тд мог не только сказать Сколько
было отгружено, но и на какую реальную(а не по последнему указанному курсу) стоимость.
Скорее всего эта нетривиальная задача, которая перед данной программой не ставилась.
Понимаю, что попытка применить нечто подобное может привести к введению методик
учета материалов в производстве - то есть приблизит к дебрям бухгалтерии.
Но было бы здорово, потому как универсальность программы развивается.
Или быть может кто-то из завсегдатаев подскажет другую программку специально
для учета материалов? А то сил больше нету в бумажках листаться и каждый раз
всё ручками пересчитывать.
А зачем нажимать...
..на Enter? Вот как раз это нажатие и вызывает операцию на редактирование. Вы
хотите, чтобы поле обновилось? Для этого можно просто нажать на клавишу \"стрелка
вправо\". Она сместит поле ввода вправо, но при этом обновится поле месяца.
Ответы. (+)
1. Согласен.
2. Ох, я уже и забыл про 199-ю сборку... И, если не ошибаюсь, этот ляп, о котором
вы говорите, он уже исправлен.
Да, перепроверил - у меня всё работает корректно.
Спасибо, буду исправлять. (+)
1. Признаю, это мой ляп. Будет исправлено.
2. Какой именно фильтр вы имеете в виду? Фильтр по классификатору? По датам?
По счетам?
Опять же,...
..о каком именно классификаторе мы говорим? О статьях? Об агентах? О проектах?
Сколько классификаторов в вашей базе данных? В моей - три.
Сколько окон с классификаторами делать на странице операций? Сколько кликов нужно
для того, чтобы добавить одну операцию если на закладке операций три окошка с
классификаторами?
Взглянул. (+)
Думаю, что делать два поля для ввода статей не нужно, что это будет неправильно.
Обратите внимание, сколько пришлось потратить усилий для того чтобы объяснить
людям что именно вы хотите и для чего это нужно. Мне хотелось бы сделать программу
интуитивно понятной. А ваше предложение, судя по необходимости <i>такого</i>
объяснения не отличается интуитивной простотой.
Кроме того, как я понимаю, речь идёт не только о статьях, чтобы всё было логичным,
аналогичную возможность нужно дать для любого классификатора. И как программа
должна определять количество полей для каждого классификатора? Понимаю, что единственная
возможность, это через дополнительные настройки. Поймал себя на мысли, что не
могу себе даже представить как именно это лучше делать.
В общем, считаю реализацию такой возможности неправильной. А тему считаю закрытой.
понятно
Я на само деле догадывался "где собака порылась".
Присоединяюсь к...
...просьбе Андрея: можно привести пример?
Ответы. (+)
По первому вопросу могу сказать \"вряд ли это будет сделано\". То что вы просите
вызывает слишком много технических проблем. Например, а что делать если вторая,
внешняя база данных недоступна? Или, что делать при реализации вот такого сценария:
1. Внешняя база недоступна, открываем основную.
2. В основной базе удаляем операцию перевода со \"своего\" счета на счёт внешней
базы. Сохраняем, закрываем.
3. Делаем внешнюю базу доступной и заново открываем базы.
В общем, там масса вариантов.
По второму вопросу могу сказать что это возможно.
ок
Спасибо.
Будем ждать