Укажите, пожалуйста, на ошибки в проектировании БД для небольшой

← →
miwa © (2004-11-17 00:01) [0]

бухгалтерской программы.
Таблицы:
Товары: - ID; - ID предка (для работы с категориями товаров); - название. Работники: - ID; - имя; - пароль (для контроля со стороны программы, но не СУБД); - еще что-то. Торговые точки: - ID; - имя; - еще что-то. Поставщики: - ID; - имя; - еще что-то. Приход товара: - ID; - ID товара; - ID поставщика; - цена; - дата; - № накладной; - примечание. Продажа: - ID; - ID товара; - ID работника; - ID торговой точки; - текущая цена; - дата. Наличие товара: - ID товара; - ID торговой точки; - количество. Наценки: - ID товара; - наценка.
В программе не планируется учет налогов и прочих заумностей ;о)).
Заранее благодарен.

← →
DrPass © (2004-11-17 00:04) [1]

Ничего, к третьей нормальной форме приведена. А смысловые ошибки тебе при эксплуатации выявят

← →
GanibalLector © (2004-11-17 01:47) [2]

Приход товара:
- ID;
- ID товара;
- ID поставщика;
- цена;
- дата;
а цена закупки?Более того,я считаю что необходимо добавить таблицу: ПАРТИИ ТОВАРОВ.

← →
kostan © (2004-11-17 03:09) [3]

если планируется SQL база (типа IB) то можно
разделить права по пользователям
(Пароли, Роли: Reader Writer и тп) (через ini)
чтоб все не лезли исправлять:)

← →
CHTR (2004-11-17 06:50) [4]

В приходе товара иногда делают отдельно накладные и отдельно товар.

Приход товара:
- ID;
- ID товара;
- ID накладной;
- Цена;
- Кол-во;
- номер партии;

Приходные накладные:
- ID
- ID поставщика;
- сумма;
- дата;
- примечание;
- (можно еще ID точки добавить)

← →
miwa © (2004-11-17 10:31) [5]

>[1] Тоесть общих, грубых ошибок нету? Вот и ладушки. Это хорошо - значит я не такой уж и невежда. :o)) Первая попытка, все-таки. >[2] "Цена" - это как раз и есть цена закупки. А отпускная цена определяется как сумма закупочной + надбавка (табица наценки). А зачем таблица "Партии товаров". Что она будет делать? >[3] Как раз Interbase и планируется. Можно поподробнее, пожалуйста? Если я правильно понял - вывести права пользователей в отдельный внешний файл? А смысл? Все равно будет таблица "Пользователи" доступ на запись в которую будет только у одного человека, который и будет решать, кому какие права позволить. Планирую сделать несколько ролей и начальник сможет назначать эти роли тем пользователям, которым посчитает нужным. >[4] Хм, а что - есть смысл... Правда, шеф ничегосеньки об этом не упоминал, я "Номер накладной" от себя добавил, но - да.

← →
msguns © (2004-11-17 10:37) [6]

1. Не видно таких объектов как "документ". Если учет по товару, а не по поставкам, то невозможен партионный учет и будут траблы со средневзвешенной ценой. Как при такой модели проводить/откатывать документы ?
2. Совершенно неясна алгоритмика цен: где определяется торговая наценка и по каким ценам ведется учет на складе и в рознице. Как делать переоценку ? Опта что, вообще нет ? Проигнорирован вопрос о возврате товара.
3. Характеристики товара вообще не прописаны: ед.измерения, весовой/штучный, код в ЭККА и т.д.
4. Где в документах движения прописано кол-во товара ? Не увидел.
5. В справочниках (поставщиков) что имеется под умным словом "еще что-то". Или за накладные и информацию в них о поставщиках ответит А.С.Пушкин ?
6. много еще чего..

В общем, совершенно сыро.

← →
msguns © (2004-11-17 10:43) [7]

>miwa © (17.11.04 10:31) [5]
>[1] Тоесть общих, грубых ошибок нету?
Есть. Очень грубая. Неверный подход к реализации учета товаров.
Например, вообще ни слова об оплате товара.

>"Цена" - это как раз и есть цена закупки. А отпускная цена определяется как сумма закупочной + надбавка (табица наценки).

Путь в никуда. Цена отпуска (розничная) может изменяться как непосредственно при отпуске в розницу, так и в самой рознице. Причем возможна ситуация, когда один и тот же товар в разных точках стоит по разным ценам. Что делать тогда с твоей талицей "наценок" ? И что вообще это за таблица ? Что, менеджеру офиса вмнесто цен будут показываться цена закупки + наценка ? Где прайсы с несколькими колонками цен ?

← →
Sergey13 © (2004-11-17 10:57) [8]

2[5] miwa © (17.11.04 10:31)
>А отпускная цена определяется как сумма закупочной + надбавка (табица наценки).
ИМХО, это неудобно. Т.к. отпускные цены часто округляются "для удобства" например. Расчитываемость цен так же может плохо сказаться на точности и погрешностях при подбивании итогов. Мой вывод - назначать цену вручную, пользуясь справочником, но с возможностью корректировки. И соответственно хранить их.

>А зачем таблица "Партии товаров". Что она будет делать?
А про это у своего шефа/бухгалтера спроси поподробнее. Ибо это одна из основ учета. Смысл этого (грубо и приближенно) - считать ли сегодняшние гвозди и вчерашние просто гвоздями, или разными гвоздями.

Со справочником "Товары" тоже надо бы поподробнее и поконкретнее. Например на "предка" может быть наличие, или это просто "группа"? Может группы вообще отдельным справочником лучше сделать?

← →
miwa © (2004-11-17 11:10) [9]

<offtopic>
Вот блин. Опять links enter"ы хавает. Никто не подскажет, как его научить нормально пост постить?
</offtopic>

> msguns

Ну хоть хто-то выругал, а то я уже волноваться начал что все так хорошо :o))
Попытаюсь все же агрументированно ответить на критику.
6.1. Обьект "документ" - это вроде накладной? Тогда учту, доделаю. Насчет же партиооного учета и средневзвешенной цены - я даже таких слов не знаю, честно. И хотя "в программ не планируется ... заумностей" (0-й пост), все же буду благодарен, если подскажете, что это такое и зачем оно нужно.
6.2. Торговая наценка определяется исключительно желаниями заказчика, об этом оговаривалось отдельно. На нее не влияют (в логике программы) налоги, конкуренты и международное положение :o) Об опте не говорилось, но, думаю, что только из-за того, что ни я ни заказчик не имеем опыта в таких делах. А переоценка делается изменением коеффициента в таблице "наценка". За идею насчет многоколоночного прайса - спасибо.
6.3. Товар исключительно поштучный... Хотя, вы правы - одного только названия может оказатся маловато.
6.4. Моя жесточайшая промашка. Спасибо за подсказку.
6.5. Имел в виду, что информации о поставщике может быть много, но вся она будет в одной таблице (адреса, номера счетов и т.п.)
6.6. Буду очень благодарен, если вы продолжите.

7.1. Оплате товара кем? Заказчиком? Тогда таблица "приход товара", поля "цена" и "количество". А в таблице продаж - текущая цена и то же количество.
7.2. Цена будет формироватся "на лету" и менеджер будет у себя видеть результат "цена закупки + наценка". Так же как и любой из работников-пользователей. Изменение наценки повлечет за собой изменение цен, при этом предыдущие цены будут утрачены, конечно. Но сведения о том, что, кем, когда и за сколько продавалось останутся в таблице продеж. По-вашему это неверный подход? Тогда как было бы лучше?

← →
Sergey13 © (2004-11-17 11:34) [10]

2[9] miwa © (17.11.04 11:10)
>6.2. Торговая наценка определяется исключительно желаниями заказчика,
Он пожелает вообще без наценки. 8-)

>А переоценка делается изменением коеффициента в таблице "наценка".
Т.е. проданные вчера по цене1 сегодня будут смотреться как проданные по цене2?

← →
miwa © (2004-11-17 11:39) [11]

> [8]Sergey13

Отпускная цена при расчете, будет, конечно, корректироваться в "удобную" сторону. Тоесть, формула будет чуть посложнее, чем "закупочная цена + надбавка". И все же рекомендуете хранить текущую цену?

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

Что касается справочника "товары", то такой подход довольно убедительно пропагандируют Востриков с Ковязиным в своем "Мир Интербейз". Ну, тоесть, они не утверждают, что это идеальный подход для бухучета, а просто иллюстриют им удобную классификацию товаров с произвольным количеством уровней вложености. "Предок", скорее всего, будет "просто группой". "Скорее всего" потому, что вы видите перед собой только результат моего осмысления первой, предварительной так сказать, встречи с заказчиком. Потому и советуюсь, чтобы в конце все не переделывать и волосы на себе не рвать из-за излишней самоуверенности.

← →
miwa © (2004-11-17 11:47) [12]

> Sergey13[10]

Нет, конечно, цена продажы товара записывается в поле "текущая цена" таблицы "продажа" и не изменяется до второго пришестия :o))

А "заказчик" в этом контексте - это тот, для кого я пишу программу. Тоесть, он не захочет без наценки ;o))

← →
msguns © (2004-11-17 11:52) [13]

Прежде чем приступать к проектированию топологии (общей схемы) БД, необходимо
1. Сделать постановку.
На этом этапе
- Четко отобразить существующий документооборот: от приходных накладных (поступление товара от постащиков) до актов списания, переоценки и инвентаризации. Здесь надо изучить всю первичку (плотно поработать с бухгалтерами, кладовщиками, менеджерами, операторами и завмагазинами).
- Определить базовые сущности проблемы, например такие, как "Товар", "Группа товаров", "Партнеры", "Розничные точки", "Накладная", "Оплата" и др.
2. Разработать техническое задание (ТЗ), где изложить
- решаемые задачи,
- характеристики входной (вводимой) информации
- алгоритмы преобразования и хранения информации
- характеристики планируемых рабочих мест (клиентов)
- выходные формы
- выбор СУБД и "железа", в т.ч. сетевого "харда" и методов доступа (администрирования)

Только после этого, собственно, приступать к проектированию БД и бизнес-логики.

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

Советую еще посмотреть внимательно 1С или подобные брэнды. Причем там, где они нормально работают. Очень может помочь

← →
Sergey13 © (2004-11-17 12:02) [14]

2[11] miwa © (17.11.04 11:39)
> "Предок", скорее всего, будет "просто группой".
Т.е. товара по этой ссылке не будет? А вдруг кто товар сделает группой после начала эксплуатации. При "произвольном количестве уровней вложености" это может стать проблемой. Хотя может и не стать. Но скорее всего станет. Например кто то посчитает что должно быть распределение товара по цветам. Заведет несколько цветовых подгрупп. А товар пришел без указания цвета. И что? Тут надо продумывать очень тщательно, ибо изменение начальных условий влечет к полному переписыванию всего проекта.

← →
msguns © (2004-11-17 12:14) [15]

>Sergey13 © (17.11.04 10:57) [8]
>>А зачем таблица "Партии товаров". Что она будет делать?
>А про это у своего шефа/бухгалтера спроси поподробнее. Ибо это одна из основ учета. Смысл этого (грубо и приближенно) - считать ли сегодняшние гвозди и вчерашние просто гвоздями, или разными гвоздями.

Я бы внес поправку. Не "основ", а "способов". Существуют 2 основных метода учета товаров (и не только):
1. По товару.
На товар заводится карточка. Все приходы данного товара независимо от постащика и вх.цены (цены закупки) "ложаться" на эту карточку. С нее же идет и списание при отпуске, отгрузке, и т.д.
Преимущества: легкость списания, нет жесткой привязки к первичке (документам), что позволяет избежать откатов при правке "задним числом", удобство и постояноство кодов ЭККА (например, при переоценке товара в магазине не надо переклеивать коды на товаре).
Недостатки: погрешности с ценой и суммами в фактурах, приводящие к "зависанию" остатков (сумма не 0, а к-во 0 или наоборот), невозможность учитывать срок реализации или партии поставок.
2. По поставкам.
Товар изначально привязывается к идентификатору фактуры прихода и в дальнейшем все его движение пляшет от этого идентификатора (кода поставки).
Преимущества.
Нет проблем с входными ценами, т.к. для товара, поступившего несколько раз, имеется несколько идентификаторов, указывающих на "свою" вх.цену. Как результат, 100% гарантия точности учета из-за отсутствия потери при расчете средневзвешенных цен (как при товаронм учете). Возможность учета по партиям, что особенно важно при торговле, к примеру, скоропортящимися продуктами или лекарственными прпаратами, т.к. каждый идентификатор фактически и есть партия.
Недостатки.
Большее кол-во операций в БД и, возможно, на клиенте, что приводит к замедлению работы приложения. Достаточно сложный в реализации и трудоемкий для пользователя механизм "отката" документов, особенно поступлений от поставщиков. Откат "задним" числом (напрмер, для внесения исправлений) прихода ведет к автоматическому откату всех последующих по времени документов, где "двигалась" любая позиция откатываемого документа.
Списание (при оформлении любого расходного документа) выполняется не с карточки, как в учете по товару, а с поставок, что может приводить к тому, что один товар (в смысле позиция прайса) будет списан с нескольких поставок (чаще всего алгоритмом FIFO: first input - first output) и, соответственно, печататься будет несколькими строками, если не предусмотрен алгоритм агрегирования.

Какой способ выбирать зависит от специфики товара и методов учета в конкретной фирме. Ясно, что в автомагазине или доме мебели партии ни к чему, а вот в фармацевтии или сети гастрономов без них не обойтись.

← →
miwa © (2004-11-17 12:17) [16]

> msguns [13]
Хех, вы, безусловно, правы, но:
фирма-заказчик - это 10 человек если считать шефа и уборщиц;
документооборот вы переоцениваете. Приход товара, наверное, еще отмечается в какой-то накладной, но уж продажа идет чуть ли не "из-под полы". Нет, планируется, конечно, открытие магазина с соответствующим документооборотом, но только планируется. И какие там будут документы ходить, а также как и в какую сторону - это пока неясно. По карйней мере мне :o) Но, во всяком случае спасибо за конструктивные советы - буду долбить.

> Sergey13 [14]

Возможно, я туплю; а может просто не вижу очевидных вещей из-за отсутствия опыта, но все же.
Почему могут возникнуть проблемы из-за того, что группа станет товаром или наоборот? Ведь всюду фигурирует только ID товара (группы) и какая фиг разница, продались ли "ведра - оцинкованные" или "ведра - оцинкованные - желтые"? В первом случае по запросам пройдет, например, ID=5, во втором ID=10. В отчетах по ID выберутся в первом случае одни ведра (которе по совместительству еще и группа), а во втором - другие (просто ведра).
Или я чего-то недопонимаю?

← →
Sergey13 © (2004-11-17 12:25) [17]

2[16] miwa © (17.11.04 12:17)
Ну если ты не видишь проблемы, то может ее и нет для тебя. 8-)

← →
msguns © (2004-11-17 12:26) [18]

>miwa © (17.11.04 12:17) [16]
фирма-заказчик - это 10 человек если считать шефа и уборщиц;
документооборот вы переоцениваете. Приход товара, наверное, еще отмечается в какой-то накладной, но уж продажа идет чуть ли не "из-под полы".

Если персонал еще не научился правильно работать (по Вашим словам), то это еще не значит, что никогда не научится. Делать же программу под "отсутствие" нормального учета, ИМХО, вообще не стоит - напишите на екселе или аксесе что-нить немудреное и курите бамбук !

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

А это уже основание для "взрослого" подхода к решению задачи.

> И какие там будут документы ходить, а также как и в какую сторону - это пока неясно.

Что ж тут неясного-то ? Те же, что ходят сейчас, будут ходить и тогда. Ну, добавится тройка новых: "Внутренний отпуск", "Товарный отчет" и, возможно, "Возврат из розницы". Ах да ! Еще возможна переоценка в магазине. Но она мало чем отличаеться от переоценки на складе. Загрузка кодов в кассу за документ считаться не может. Кстати, а как планируется загружать ЭККи ? Ручками ?

← →
miwa © (2004-11-17 12:27) [19]

> msguns [15]

Вот за это - большое спасибо. Просветил.
Поскольку учет планируется в фирме, которая занимается торговлей компютерами, комплектующими etc, то партии сдесь не нужны. А зная о погрешностях метода, будем думать, как с ними боротся.
Вы можете что-то посоветовать? Или я уже слишком многого хочу? :o))

← →
CHTR (2004-11-17 12:45) [20]

Я бы посоветовал книгу где нибудь достать по 1С Торговля и склад и вечер потратить. Все бы в голове улеглось и оформилось.

← →
msguns © (2004-11-17 12:52) [21]

>miwa © (17.11.04 12:27) [19]
>Вы можете что-то посоветовать?

[13],[20]

← →
KSergey © (2004-11-17 14:09) [22]

Интересно, в свете отгремевшей ветки про 1С, ее упомянутости уважаемым msguns и не только, а так же ввиду присутствия здесь практиков - не ответит ли кто на простой с виду вопрос: а не проще ли будет в данном конкретном случае взять готовую.. ну ту же 1С, например? О ценен пока не говорим, ведь и не знаем с чем сравнивать. Но вот с точки зрения функционала.
Просто из любопытства вопрос.

← →
msguns © (2004-11-17 14:37) [23]

>KSergey © (17.11.04 14:09) [22]

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

Лично я придерживаюсь мнения (если тебе интересно мое) мнение, что быстрее и дешевле разработать собственную модель учета, причем вполне шуструю, надежную и многопользовательскую, чем связываться с 1С (v 7.7). Говорю с позиции паскалишника и сиквэльщика, естесственно. Если же чел - спец в 1С, то, наверное, проще будет ориентироваться на нее. Хотя.. Больно много глючных реализаций даже там, где проект "вылизывают" спецы.

← →
miwa © (2004-11-17 14:37) [24]

> [22]

Ну, этот вопросс, конечно, не совсем ко мне, но все же. Во-первых оно будет весьма похоже на "из пушки по воробьям", ну а во-вторых - сейчас используется linux-сервер с firebird на борту. Это тоже, ИМХО, накладывает некоторые ограничения, нет?

← →
msguns © (2004-11-17 14:50) [25]

1С работает с MS SQL

← →
Sergey13 © (2004-11-17 14:54) [26]

2[24] miwa © (17.11.04 14:37)
И чего у них на этом летающем огненном пингвине крутится? Просто интересно. Если
>фирма-заказчик - это 10 человек если считать шефа и уборщиц;

← →
miwa © (2004-11-17 16:12) [27]

>[26] Sergey13

А кроме всего прочего эта фирма - это еще и два компютерные клубы. Соответственно на огненном пингвине - раздача и учет интернета. Еще там выделенные сервера для каких-то игрушек крутятся, насколько мне известно. Возможно, еще что-то.

← →
miwa © (2004-11-17 23:27) [28]

Простите, как то выпустил из внимания два поста.

> [18] msguns © (17.11.04 12:26)
> считаться не может. Кстати, а как планируется загружать
> ЭККи ? Ручками ?

Знаете, я бы с большим удовольствием вам ответил, но должен признаться, что не знаю, кто такие ЭККи. Ручками будут вносится названия, категории товаров, цены, поставщики. Или это не то?

> [17] Sergey13 © (17.11.04 12:25)
> 2[16] miwa © (17.11.04 12:17)
> Ну если ты не видишь проблемы, то может ее и нет для тебя.
> 8-)

Ну, как вариант - я могу не видеть проблемы из-за неопытности, но это не значит, что ее у меня нет. ;о))

Прочитал не все, но вроде этого не было.
1) Сделать единый журнал операции (покупки, продажи и т.д.)

2) Таблицы покупок и продаж товара следует также объединить в 1 журнал количество и себестоимость вычислять динамически (по возможности), строки прикреплять к операциям.

3) Покупателей, поставщиков, поставщиков услуг (вода, свет и т.д.) - тоже в 1 таблицу контрагентов.

4) Для вычисления например остатков товара по журналу товаров сделать примерно такую структуру:

Типы товаров операции
TOV_STATE_ID - ID; TOV_STATE_NAME - название TOV_STATE_TYPE - тип (-1 расходная, 0 - нейтральная(перемещение), 1 приходная);
Журнал товаров операции
OPER_TOV_ID - ID; TOV_STATE_NO - FK по TOV_STATE_ID; TOV_NO - FK по ID товара; OPER_TOV_Kolvo - количество; OPER_TOV_Cena - цена единицы;

Остаток товара получаем как
Select Sum(OPER_TOV_Kolvo * TOV_STATE_NO) From Table1, Table2 Where TOV_STATE_NO = TOV_STATE_NO

Пока все.

Правильная версия последнего запроса:

Select Sum(OPER_TOV_Kolvo * TOV_STATE_TYPE) From Table1, Table2 Where TOV_STATE_NO = TOV_STATE_NO

> Или это не то?
Не то!Имеется в виду кассовый аппарат.
Кстати,иногда необходимо работать со скидкой.А они бывают разные...на моей памяти 5 разных.

2 msguns
Понравилось мне Ваше [15].Хотел поинтересоваться...это Ваше мнение или это статья какая-то???Если статья,то не могли бы Вы сообщить адрес.И еще,БОЛЬШАЯ ПРОСЬБА...а можно ли взглянуть на Вашу структуру БД?

2[28] miwa © (17.11.04 23:27)
> Ну, как вариант - я могу не видеть проблемы из-за неопытности, но это не значит, что ее у меня нет. ;о))
Например самая первая возможная проблема. Выбрать товары определенной группы. В твоем случае придется рекурсивно проверять, а нет ли товара на родителе, потому что возможно когда-то товар сделали группой. Сам понимаешь во что это может вылиться.
Вообще динамическая структура (а при таком подходе фактически получается именно динамическая структура данных) та еще песня. Если пока нет опыта работы даже со статической, я бы не советовал такой подход.

>Vemer © (18.11.04 00:10) [29]
>Прочитал не все, но вроде этого не было.
>1) Сделать единый журнал операции (покупки, продажи и т.д.)

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

>2) Таблицы покупок и продаж товара следует также объединить в 1 журнал количество и себестоимость вычислять динамически (по возможности), строки прикреплять к операциям.

Глупости. Первичны всегда документы, а не операции. По крайней мере в складских задачах. Не каждому документу может соответствовать операция (счет, например) и не каждой операции - документ (оплата за товар наличными, к примеру). Это во-первых.
К тому же при учете по поставкам таблицу приходов надо выносить отдельно, т.к. ссылки на ее строки (коды поставок) будут присутствовать в фактурах других документов. Это во-вторых.
По каждой документо-строке делать операцию означает то, что получаем "неоткатные" операции, которые непонятно кому и зачем нужны. ИМХО, к операциям следует подходить по принципу "Одна операция - одна проводка". Это в-третьих.
По поводу "вычислять себестоимость динамически" (опустим безграмотность этой фразы с т.зр. бухучета) см. [15]

>3) Покупателей, поставщиков, поставщиков услуг (вода, свет и т.д.) - тоже в 1 таблицу контрагентов.

Совершенно справедливо. Ввести признак "дебитор(покупатель)-кредитор(продавец)-дебитор+кредитор". Без единой системы регистрации всех партнеров весьма вероятны случаи дублирования одного и того же лица в двух таблицах под разными наименованиями (или отличающимися в мелочах, что для "железки" одно и то же), а также нельзя получить сводный баланс по комбинированному партнеру (типа он и поставщик и покупатель)

>4) Для вычисления например остатков товара по журналу товаров сделать примерно такую структуру:

Есть опять-таки 2 подхода к остаткам (и не только по товару, а по сальдо с партнерами, сальдо на р/с в банках и т.д.):
1. Наличие таблицы сальдовых помесячных остатков. Ускоряет расчеты, но приводит к несколько бОльшим затратам памяти (доп.таблицы в общем-то немаленьких размеров)+усложняет логику
расчетов. Предполагает наличие расчетного периода, вне которого блокируются корректировки (т.е. для правок "прошлого" необходим сторнирующий документ)
2. Расчет производится по необходимости по всему движению за весь период хранения информации. Во избежание "тормозов", начинающихся после N-го месяца эксплуатации приложения и БД, рекомендуется делать чистку БД с удалением всего движения (создается один рез.документ, вносимый в БД как нач.приход "ниоткуда" или же как акт инвентаризации) до какой-то пограничной даты.

>GanibalLector © (18.11.04 00:30) [31]
>Кстати,иногда необходимо работать со скидкой.А они бывают разные...на моей памяти 5 разных.

Не все ЭКА поддерживают.

>GanibalLector © (18.11.04 00:31) [32] Если статья,то не могли бы Вы сообщить адрес.И еще,БОЛЬШАЯ ПРОСЬБА...а можно ли взглянуть на Вашу структуру БД?

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

>Sergey13 © (18.11.04 09:58) [33]
>потому что возможно когда-то товар сделали группой

Как это ? Что ж это за логика, которая позволяет так делать ?

2[34] msguns © (18.11.04 10:45)
>Как это ? Что ж это за логика, которая позволяет так делать ?
Это началось с [11] miwa © (17.11.04 11:39)

> [29]

1, 2. Простите, а смысл? Что это дает?
3. Опаньки, а это идея. Надо будет подумать. Спасибо.
4. Тоесть смысл 1 и 2 только в этом? Вы простите, если я что-то не то спрашиваю. Как я уже писал - это моя первая серьезная работа с бухгалтерией, да и с базами - максимум третий проект, да и то первые два были несерьезные. Учусь я пока.

> [31]

А-а-а, тоесть ЭКК - Электронные Кассовые Коды? Хм. Опять же - не думал на эту тему, так как это даже не упоминалось.
А какие возможны решения кроме ручного ввода? Соединятся по какому-нибудь com-порту с кассой и вытягивать-записывать?
За скидки спасибо. В смысле, за напоминание о них - тоже выпустил из внимания.

> [33]

А в уже упоминаемом мною "Мире Интербейз" неплохо описана разработка ХП для работы с такими структурами - вот их я и использую за основу. Надеюсь, я все же не настолько тупой, чтобы хорошие рабочие примеры угробить ;o))

2[36] miwa © (18.11.04 10:53)
>А в уже упоминаемом мною "Мире Интербейз" неплохо описана ...
Там описана программная реализация. А проблемы могут возникнуть (я не утверждаю, что обязательно возникнут 8-) из-за усложнения бизнес-логики.

> Sergey13 [37]

Спасибо, буду иметь в виду и в случае осложнений вспоминать... ну, например "Ах, Sergey13, $@#%^$#%^#$^@# накаркал ;o))"
А если серьезно - спасибо, постараюсь учесть.

To MS_Guns:

У моего заказчика первичны операции, а при необходимости генериться документ (пример - 1 счет на 10-15 продаж). Это в бухгалтерии первичен документ :). Задачи разные.

Под "операцией" подразумеваеться какое-то действие.

С уважением.

> Sergey13 [35]
Вообще-то, я этого не предлагал; я просто сказал, что такого скорее всего не будет, но гарантировать не могу, так как... ну и далее по тексту.
Типа оправдываюсь. :o))

Укажите, пожалуйста, на ошибки в проектировании БД для небольшой Найти похожие ветки