logo
logo

Форум Касательно п 3

создать новую тему раскрыть все
Касательно п 3 Explorer 04/02/2002 19:28 #написать ответ
А нельзя-ли и для операций реализовать двухуровневую систему вложений точно как для счетов?
Пра - оч актуально. Я использую программу для детального учета расходов сотрудников и записи по операции (сведения о товаре по чеку) для меня напр - оч важно, поскольку товар/покупка ставится на учет как единица.
со своей стоимостью, количеством и описанием.
 
Для операции еще можно ввести атрибут "налоги" (НДС, НСП, Акциз) и "скидки" (cо стоимости товаров (до налогов) или со стоимости покупки (после налогов).
 
С другой стороны - подобная детализация нужна в 70% случаев, и когда в ней нет необходимости - можно вводить операцию по счету по упрощенной схеме (как сейчас).
 
Например по счету "Покупки - мебель" у меня сейчас значится четыре оплаты спальных гарнитуров (гарнитур - одной записью) состоящих каждый из 5 предметов(что не отображено в базе).
 
Для второго уровня записей по операции (товар по чеку) необходимы только основные сведения - наименование, цена, количество. Сумма по чеку/операции может отличаться от суммы стоимостей товаров по чеку...
 
Каатся мне это могли бы быть совершенно идентичные по структуре категории учета БД (счета(группа) - со вложениями и, аналогично, операции(группа) - со вложениями)
 
Dervish: Я верно понял, Вы предлагаете ввести дополнительные поля, определяемые пользователем? Мммм, интересное предложение... Надо обдумать... Очень интересное...
 
Посмотрите на обсуждение с Константином вопроса по сптилированию операций (чуть ниже в форуме). Мы не об одном и том же говорим?
Касательно сплитирования - нет. Это полумера :)) Эксплорер 04/02/2002 21:11 #написать ответ
Я пытаюсь вести речь о "однотипности структуры объектов БД" сожалею, если мне не удается донести мысль, но речь вот о чем:
 
Мы видим что для реквизитов операции есть определенная однотипная структура - "родитель", "описание", "примечание". Равно одинаковая для "Агентов" "Проектов" и "Статей".
 
ИМХО для "счетов" и "операций" структура также может (должна?) быть одинаковой... Почему нет?
Простое двухуровневое вложение и там и там(примерно - как группировка по категории)
 
То, что для "счета" является "родителем" (верхний уровень - группа "наличные" напр.) для операций - будет собственно операция (с атрибутами агент/проект/статья). То, что для счета является собственно счетом (Наличные>Кредитная_Карточка_Жены -вложеная запись) - для операции (мебельный гарнитур) будет некоторая запись о товаре по счету (Мебельный_гарнитур>Тумбочка_прикроватная) - так-же вложеная запись. ИМХО для всех объектов БД мы имеем всего две структуры - простое двухуровневое вложение для "Счетов" и "Операций" и глубокое многоуровневое вложение для "Агентов", "Проектов" и "Статей"...
 
Ну и кроме того...
 
Теперь о том посте что я бросил в примечании к пункту первому. Да, я говорил о моделировании пользователем реквизитов операции для группы счетов.
 
Для начала...
 
Атрибутами операции я назову "агентов" "проекты" и пр.
Реквизитами - сумму операции, проценты (если есть) сумму налога (напр.) дату операции. Просто для того, чтобы обозначить разницу...
 
Насколько я понял (со второго раза) в п.1 плана работ речь идет об атрибутах операции, я в свою очередь хотел сказать о настройке реквизитов операций - поле, формат данных, наименование поля - для операции по группе счетов(собственно и все)
 
Dervish: На обдумывание, хорошо? )
RE: Касательно сплитирования - нет. Это полумера :)) Artem Fedorov 04/02/2002 22:20 #написать ответ
А что мещает сделать просто разбиение? ИМХО это решит проблему. Вот как: если у нас одна плоская операция, то все работает как обычно. Если комбинированная (с дочерними записями), то просто родительская операция сама по себе прекращает иметь какой-то смысл -- ее реквизиты вычисляются посредством суммирования (?) дочерних записей. Вот например запись "Гарнитур". Если добавлять туда записи "Полка", "Тумбочка" и т.д., то сумма операции будет суммой ее детей, а изменить сумму нелзья. Кстати, наоборот тогда будет с атрибутами -- такие поля как агент и проект будут общими для дочерних записей. Это то, что было надо?
С этим суммированием - я напарился выше крыши... Вот уж был у меня горький опыт 04/02/2002 22:37 #написать ответ
В "реале" по разному бывает...
 
Бывает, что сумма чека напр и сумма товаров по чеку не совпадает,
бывает что в сумму операции входит пункт, который отображать не обязательно (полиэтиленовый пакет/упаковка)
А бывает, что просто нельзя отображать этот пункт - взятка или "откат".
 
Кроме того, вычисляемые поля увеличат ЗНАЧИТЕЛЬНО время обработки запроса.
 
Не уж... Пусть хранятся в явном виде... Единственное, что можно добавить - "автосуммирование по умолчанию" например набив некое кол-во записей о расходах в "операцию", в поле сумма я получаю сумму раходов. сбросив галочку "с учетом НДС" (НДС прописывается в настройках счета/программы) - сумма стоимости товаров увеличивается в поле "сумма оперции" на 20%.
 
И тем не менее, я должен иметь возможность скорректировать ручками это значение. Ну и кр.того - ускоренный ввод - если мне нет необходимости расписывать операцию - мне достаточно просто ввести сумму/ы так, как это сделано сейчас... Либо калькуляцией в поле, либо просто числом.
RE: С этим суммированием - я напарился выше крыши... Artem Fedorov 04/02/2002 22:51 #написать ответ
Все возможно! Для того, что не надо учитывать, просто не ставим галочку выполено и все! Операция не прибавляется автоматом.
 
Если сумма больше, вводим дополнительную операцию (из-за чего-то она результат больше чем сумма?).
 
И ничего страшного, ИМХО в этих workarounds нет, зато логика программы становится четче. А если допускать такие колебания в сторону от классической математики, то это чтож за бухгалтерская программа такая.
 
А время обработки запроса не увеличится, если подходить с умом Ведь можно и при запросе каждый раз считать сумму, а можно при изменении сумм дочерних записей сразу править сумму родительской. Вот так, никаких тормозов.
 
И о скорости: кто-то из нас кого-то недопонимает. Вот:
А что мешает создавать операцию без дочерних записей? Такой же быстрый ввод данных, она ничем не будет отличаться от тех операций, какие есть сейчас. Дать возможность вводить простые операции, а если надо, кликаешь, напрмер правой кнопкой на операции, выбираешь "создать дочерние" и все. Операция автоматом становится псевдо-операцией (группой), и ты начинаешь вводить детей. Тут добавляется новая функциональность не ущемляя старой.
Логика еще и в том тынс-тынс и ворос Артему 04/02/2002 23:08 #написать ответ
чтобы сделать идентичные по сути объекты БД (группы_счетов/счета и операции/записи_о_расходе) идентичными отчасти и по форме.
Для конгруэнтности/строиности/удобства ))
 
Вычисляемые в запросе поля IMHO - перебор и не оправданы (если оправданы - то чем IYHO?). А если все равно хранить их в явном виде - почему-ж тогда не дать возможности "подправить" перед сохранением...
 
ЗЫ - насчет скорости выполнения вычисляемого запроса - поверь на слово -ну его в баню, (тем более для операций, которых мож быть оч много) никчему это совсем...
Так, покажите мне логику! ;) Artem Fedorov 04/02/2002 23:32 #написать ответ
Дак где тут логика? Если у меня логическая стройность всех записей в БД (о них ты говорил), то логично автовычислять сумму. А то ведь сумму по счету не дают править, ведь так? И правильно, что не дают! Так и сумму операций не надо давать! Это удобно для твоего случая, но в остальных пользователи офигеют. Что это такое? А если случайно исправить сумму, а потом ошибки оттуда расти начинают? К тому же, программа дом.бухгалтерии, которая не дружит с математикой -- это уже не программа для домашней бухглтаерии. Тем более, как я говорил, все это можно реализовать и так, обходные пути я уже назвал.
 
Про суммирование: дык я и имел ввиду, что с суммированием в запросе хуже! Надо сразу делать суммирование при изменении дочерних записей. И быстро, и комфортно.
ну... это слишком вольная интерпретация я 05/02/2002 09:12 #написать ответ
я говорю о минимализации/стандартизации методов/подходов... в этом и вижу логику оптимизации А "логическая стройность всех записей в БД" - это не мои слова...
 
Полемический задор давай лучше оставим для дискуссии о пиве...
Да какая полемика?! Artem Fedorov 05/02/2002 10:21 #написать ответ
Наверное, я просто не могу понять, что ты имеешь ввиду. Можно объяснить для меня, глупого? Еще раз. В двойном объеме. По шагам, разжевывая и кладя мне в рот.
 
ЗЫ Мне кажется, я начинаю понимать... Стандартизация... Ты имеешь ввиду, что как будет сделано с вложенными счетами, так надо и с операциями?.. Все-таки, поподробнее, если можно.
 
P.P.S. А что, о пиве можно начать отдельную ветку...
В общем и целом.... Иде я нахожусь 05/02/2002 13:17 #написать ответ
Если говорить о вложеных счетах и операциях - то да...
 
Т.Е. простое двухуровневое вложение и там и там...
 
Сгруппировать счета по "видам/группам" и присвоить реквизиты операций для каждого вида счетов - это одно направление. В каждой группе неограниченное количество счетов.
 
Разделить операцию на записи о расходе по операции ("сведения о товаре по чеку") и дать пользователю возможность детализации - второе. В каждой операции неограниченное количество товаров...
 
И то и другое решается в одном ключе. И то и другое значительно расширит функциональные возможности программы. Алгоритм работы с этими объектами БД однотипный и сов прозрачный/естественный. Представление данных - как в "реале" - классическая модель.
Легко и просто.
>Категория учета (группа счетов)
>Карточка учета (счет)
>Операция по карточке (операция)
>Детали операции по карточке (товар по чеку)
 
При этом ключевыми так и остаются
 
>Карточка учета
>Операция по карточке
 
>Категория учета - суммирующая информация по группе счетов
>Детали операции по карточке - детализирующая информация по операции
Все прояснилось, но... Artem Fedorov 05/02/2002 13:47 #написать ответ
Отлично. Ты объснил как раз для меня: просто и понятно. Я об этом же и говорил, только стоит одна проблема: сумма "Операции по карточке". Согласись, даже в реале, семма товаров в чеке и есть сумма целого чека -- ни больше, ни меньше. Если твой кассовый аппарат начнет пробивать товаров на общую сумма 10 р., а в чеке итог будет 20. Что ты сделаешь? Будешь чинить аппарат. То же самое тут.
 
Тем более, если проводить аналогии со счетами, то родительский счет будет иметь сумму всех дочерних. В копейку. Как в аптеке. Так почему сумма "карточки операции" должна быть отличной от сумм "деталей операции"?
 
Ксати, если строго следовать этому принципу ("ничего ни откуда не появляется"), то можно реализовывать целые деревья операций и счетов. В принципе, в случае с чеками, двух уровней вложенности достаточно, но в других случаях (кто знает, что придет в голову пользователю?) это может оказаться полезным. В конце концов, никто никого не заставляет иметь более двух уровней вложенности (карточка - детали) или даже одного. Но сама возможность создания неограниченного количества уровней добавляет гибкости. Тем более не слишком сложна в реализации.
но... я 05/02/2002 16:11 #написать ответ
принцип разумной достаточности во главу угла...
 
В реале организовывать "целые деревья операций и счетов" пожалуй не придется. В случае со счетами - это группировкапо признаку на одном уровне, группировки более обобщенные возможны на уровне разделения баз данных (например), пожалуй в пределах одной базы глубокие вложения счетов - излишество не оправданое...
В случае с операциями - это детализация операции на одном уровне вложения, в принципе на практике этого тоже достаточно.
 
На уровне БД мы оперируем записями об операциях - это основная таблица и, собственно основа учета. Мы меняем реквизиты и атрибуты именно для операций
Счета - по сути - один из атрибутов операции (атрибуты и реквизиты - см. посты выше)- основной группирующий признак и естественное представление суммирующих данных об операциях
 
Детали операции - описательные данные и носят вспомогательное  значение их жесткая структура только помешает работе...
 
Если говорить о программе для магазина, то безусловно сумма по чеку (операция) должна равняться сумме стоимости товаров по чеку (кстати здесь тоже могут быть отклонения... связаные с рассчетом НДС, скидками и округлениями)
 
НО для магазина основой учета является именно товар, для нас же - платеж (операция). Поэтому пример с магазином и кассовым аппаратом не совсем адекватен там другие цели и задачи.
Сдается мне, что рассчет в запросе суммы операции на основе суммы записей по операции просто не нужен. Это излишнее усложнение. Пусть будет автосуммирование по операции на событие AfterUpdate записи о расходе, но возможность редактировать сумму по операции ручками должна остаться в люб. случ.
придется дожидаться пока Сергей из отпуска вернется в любом случае 05/02/2002 16:15 #написать ответ
после 13 февраля
RE: RE: Касательно сплитирования - нет. Это полумера :)) Konstantin 06/02/2002 01:10 #написать ответ
Ну да, в общем то то что Иван предлагает похоже на сплиты, но не срвсем то, или скорее не совсем затем для чего классические сплиты были сделаны в домашней персональной бухгалтерии. Еще к тому же он предлагает делать их вложенными... Честно говоря для дома для семьи я плохо представляю зачем бы это могло пригодится а гемороя в реализации будет немало мне кажется.
 
Константин
По касательной... ГексЛопер 06/02/2002 03:39 #написать ответ
Поскольку уже намечена реализация двухуровнего вложения счетов - двухуровневое вложение операций может быть реализовано по тому-же алгоритму, гемороя не так и много.
 
Это дополнение значительно увеличит функциональность программы, позволяя делать больший акцент на слове "бухгалтерия" чем на "домашняя".
 
Но, на всякий случай - поясняю на практике - зачем это может понадобится в дом.бух. :
 
Отправляя мебель в Санкт Петербург при переезде я её страховал (обязательная процедура) мебель была разномастная но дорогая (кожанная софа, итальянская витрина и т.п.)
В принципе каждый дорогостоящий айтем страхуется отдельно и стоимость покупки каждого из наименований мне нужна для оценки страховщиком.
Можно, конечно, поднять товарные чеки и уточнить стоимость, но удобнее это посмотреть в программе.
 
Другой вариант... Космос ТВ мне выставляет счета за пакет Альфа ($ 40.00/мес.) и доп эротический канал
"Private Blue" ($ 12.00/мес.) За Альфу платит моя компания (возвращает деньги), за эротику плачу я сам.
Т.Е. операция одна (оплата счета Космос ТВ) расходов по ней два, причем учитывать их нужно отдельно, операция "с повторением".
 
Оплата счета автомастерской, за ремон машины - тоже отдельная песня, тут тебе и услуга -помыли машину  ($ 60.00 - во гады) и товар с услугой - замена масла, и запчасти - дворники поменял и коврики новые купил.
Операция одна - записей в ней несколько.
 
Сходил в магазин за продуктами - заодно накупил видеокассет и бутылку вискаря за 1500 - тоже надо выделить...
 
А покупки в интернет... Книга стоит $20.00 доставка - $19.00
 
Ну в общем, если что не понятно - спрашивай
Неограниченные уровни Artem Fedorov 06/02/2002 08:29 #написать ответ
Я в целом поддерживаю Ивана, только хотелось бы выделить такой момент, как поддержка нескольких уровней вложенности: если брать твой пример со страхованием, то что делать, если я страхую мебель в двух фирмах? И мне хочется выделить каждую? Если давать возможность создавать два уровня, почему бы не дать возможность создавать и три? Повторюсь, никто не заставляет использовать все возможности, но если в какой-то момент понадобилось такое сделать, будет приятно знать, что программа это поддерживает. Причем сложность реализации отличается не сильно.
RE: Неограниченные уровни ХуксМалдер 06/02/2002 09:21 #написать ответ
я уже говорил о разумной достаточности...
 
Если страховать имущество в двух фирмах, то это будет две разные операции...
 
Что касается операций и записей по операции - двухуровнего вложения достаточно. Это естественная форма представления данных. Так она существует на практике...
 
RE: Неограниченные уровни Artem Fedorov 06/02/2002 10:59 #написать ответ
Э-э-э-х-х-х...
поскольку дискуссия наша превращается в диалог Быть может вот что еще я хотел бы добавить 06/02/2002 14:13 #написать ответ
сдается мне что некоторые вопросы мы могли бы обсудить почтой.
Боюсь что Сергей, не смотря на его в высшей степени лояльное отшение к пользователям, начнет тереть наши посты с форума как спам...
 
ЗЫ )
Действительно Artem Fedorov 06/02/2002 16:13 #написать ответ
Воистину так! Я уже упоминал, что форум не преднозначен, для таких "жарких" дискуссий
 
P.S. На мыло написал...