Правильное сохранение при Мастер- Детаил

← →
MsGuns © (2009-03-26 15:48) [40]

>Xmen (26.03.09 13:59) [29]

С ума застрелиться !
Товарысч не только писать, но и читать не умеет.
[19] вообще, а абзац про 1с в частности для кого писан был ?

Опять-таки прежде чем садиться писать всякие "мастер-деталы" неплохо бы поиметь какое-никакое представление о ПРЕДМЕТНОЙ ОБЛАСТИ ибо судя по ветке у автор в торговле не ухом, не рылом. Неплохо также подчитать что-нибудь по проектированию БД вообще, например про нормализацию (это к вопросу про "наименования" и т.д.)

Короче, лучшее решение - это 1С. Иначе это будет что-то страшное, а не прогроамма.

Ну а если нужно "поскорее" или "для папы", то эксель в зубы и вперед с песней

← →
Виталий Панасенко (2009-03-26 15:57) [41]

Я так и не понял, почему тебе так мучительно первоначально записать мастер запись? Получишь ИД и используй его уже в детали...

← →
Sergey13 © (2009-03-26 15:58) [42]

> [40] MsGuns © (26.03.09 15:48)

Да ладно тебе. 8-)

Мы все учились понемногу
Чему-нибудь и как-нибудь.
(с) Пушкин

ЗЫ: только наверное надо в соответствующий раздел переносить топик

← →
Сергей М. © (2009-03-26 16:02) [43]

> MsGuns © (26.03.09 15:48) [40]

Что-то тебя не понять)

То на "топорность" одноэсины сетуешь, то агитируешь народ за одноэсину как "лучшее решение")

← →
Anatoly Podgoretsky © (2009-03-26 16:48) [44]

> Сергей М. (26.03.2009 16:02:43) [43]

Чего странного то, ведь по знаниям, кому то умные программы, кому то тупые.

← →
MsGuns © (2009-03-26 16:51) [45]

>Сергей М. © (26.03.09 16:02) [43]
>Что-то тебя не понять)
>То на "топорность" одноэсины сетуешь, то агитируешь народ за одноэсину как "лучшее решение")

Что поделаешь - 1с так заполонила наш мир, что приходится искать к ней подходы.
А заполонила потому еще, что над нею очень немало потрудились НЕпрограммисты (бухгалтеры, экономисты, товароведы и проч). Ей очень трудно отказать в том, что предметная область представлена очень даже полно и понятно, а схема документооборота максимально приближена к реальной. Поэтому бухгалтеры так ее полюбляют :)

← →
Сергей М. © (2009-03-26 17:43) [46]

> MsGuns © (26.03.09 16:51) [45]

А, ну вот теперь понятно, с какой стороны "топор" рассматривается)

В целом согласен.

Но уж больно дорог этот "топор" оказывается в приобретении, саппорте и эксплуатации.

← →
MsGuns © (2009-03-26 22:22) [47]

>Сергей М. © (26.03.09 17:43) [46]
>Но уж больно дорог этот "топор" оказывается в приобретении, саппорте и >эксплуатации.

Скупой платит дважды (с)

← →
Игорь Шевченко © (2009-03-27 02:31) [48]

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

← →
Xmen (2009-03-27 06:46) [49]

А что тепер и написать программу ненужно?

← →
Anatoly Podgoretsky © (2009-03-27 09:08) [50]

Не нужно, особенно с такими знаниями.

← →
Сергей М. © (2009-03-27 09:14) [51]

> Скупой платит дважды

А бездумно щедрый четырежды)

← →
Xmen (2009-03-27 12:34) [52]

почитав ваши ответы изменил структуру таблиц.
Таблица движение товаров.
CREATE TABLE TOVAR (
ID INTEGER NOT NULL,
ID_DOC INTEGER,
NAME VARCHAR(100),
ED_IZ INTEGER,
SENA NUMERIC(15,2),
KOL INTEGER,
ID_OPER INTEGER
);
ALTER TABLE TOVAR ADD CONSTRAINT PK_TOVAR PRIMARY KEY (ID);

Таблица документов(приход/расход)
CREATE TABLE DOCUMENT (
ID INTEGER NOT NULL,
N_DOC INTEGER,
N_DOG INTEGER,
DATE_DOC DATE,
SUMMMA_DOC NUMERIC(15,2),
PRINIAL VARCHAR(50),
SDAL VARCHAR(50),
ORG VARCHAR(100),
TYPE_DOC INTEGER
);
ALTER TABLE DOCUMENT ADD CONSTRAINT PK_DOCUMENT PRIMARY KEY (ID);

Операции по товарам
CREATE TABLE OPERATION (
ID INTEGER NOT NULL,
ID_TOVAR INTEGER,
TYPE_OPER INTEGER,
DATE_OPER DATE
);
ALTER TABLE OPERATION ADD CONSTRAINT PK_OPERATION PRIMARY KEY (ID);

Правильно ли я создал?

← →
Игорь Шевченко © (2009-03-27 13:11) [53]

> Правильно ли я создал?

Нет

← →
Sergey13 © (2009-03-27 13:11) [54]

> [52] Xmen (27.03.09 12:34)
> Правильно ли я создал?

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

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

> N_DOG INTEGER,

> SUMMMA_DOC NUMERIC(15,2),
> PRINIAL VARCHAR(50),
> SDAL VARCHAR(50),
> ORG VARCHAR(100),
> TYPE_DOC INTEGER

Это что и зачем?

> ID_OPER INTEGER

Это относится к документу, а не к товару.

> DATE_OPER DATE

Это вообще зачем? Это маленький справочник, никаких дат там не нужно.

Ну и про то что я писал тебе в письме. Что и как учитывать будешь, определился? Без этого проектировать структуру бесполезно.

← →
Сергей М. © (2009-03-27 13:22) [55]

> Xmen (27.03.09 12:34) [52]

Смысл каждой записи в "книге движения" - тогда-то там-то на основании такого-то документа осуществлена такая-то операция над такой-то номенклатурно-учетной единицей в таком-то количестве для такой-то единицы измерения по такой-то учетной стоимости на такую-то сумму.

← →
Xmen (2009-03-27 14:18) [56]

TABLE TOVAR
ID - ид
ID_DOC - вк таблицы Document
NAME - наименование товара
ED_IZ - единица из.
SENA - цена товара
KOL - количество
ID_OPER - вк операции по товару

DOCUMENT
ID - ид
N_DOC - номер документа (приход/расход)
N_DOG - номер договора
DATE_DOC - дата документа
SUMMMA_DOC - сумма документа
PRINIAL - принял (ФИО)
SDAL - сдал (ФИО)
ORG - организация (приход/расход)
TYPE_DOC - тип (приход/расход)

TABLE OPERATION
ID - ид
ID_TOVAR - вк товар
TYPE_OPER - тип операции (приход/расход/списание)
DATE_OPER - дата операции

← →
Sergey13 © (2009-03-27 14:41) [57]

> [56] Xmen (27.03.09 14:18)
тогда уж так

TABLE TOVAR
ID - ид
ID_DOC - вк таблицы Document
NAME - наименование товара
ED_IZ - единица из.
SENA - цена товара
KOL - количество

DOCUMENT
ID - ид
N_DOC - номер документа (приход/расход)
ID_OPER - вк операции по товару
N_DOG - номер договора
DATE_DOC - дата документа
SUMMMA_DOC - сумма документа
PRINIAL - принял (ФИО)
SDAL - сдал (ФИО)
ORG - организация (приход/расход)

TABLE OPERATION
ID - ид
NAME_OPER - тип операции (приход/расход/списание)
OPER - +1/-1

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

Что за склад у тебя, что хранишь/учитываешь, для чего?

← →
Сергей М. © (2009-03-27 14:42) [58]

И где тут таблица, отражающая движение ?

← →
Xmen (2009-03-27 14:55) [59]

У меня по идей все таблицы, справочников еще не указал.
Таблица Tovar у меня является таблицей движения. а таблица Document то является таблицей данных о документах прихода и расхода (номер договора, кто принял товар, от куда ....). Operation - таблица операции по товару, расхода/списания.

← →
Xmen (2009-03-27 15:02) [60]

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

← →
MsGuns © (2009-03-27 15:14) [61]

Автор, ну поймите же наконец что пока не будет в голове ясности о ПРЕДМЕТНОЙ ОБЛАСТИ, не появится четкое представление об таких объектах как МАТЕРИАЛЬНЫЙ ДОКУМЕНТ, КАРТОЧКА ТОВАРА, КОНТРАГЕНТ и т.д., все что делается будет торжеством ламеризма.

Блин, ну это все равно что проектировать автомобиль с формы колеса и вида панели приборов

← →
Sergey13 © (2009-03-27 15:18) [62]

> [59] Xmen (27.03.09 14:55)
> Таблица Tovar у меня является таблицей движения
Чума просто. 8-)

> [60] Xmen (27.03.09 15:02)
> сначала это был склад маленькой продуктовой базы, ну я хотел
> это использовать и в других случаях.

Типа по легкому бабла срубить?

Вобщем тебе надо разобраться с предметной областью. И с основными принципами проектирования БД, всякие там ключи, нормальные формы и т.п.
Без этого пока дальше двигаться смысла нет, ИМХО.

← →
Игорь Шевченко © (2009-03-27 15:39) [63]

Sergey13 © (27.03.09 15:18) [62]

готовое купить гораздо дешевле

← →
MsGuns © (2009-03-27 15:41) [64]

>Xmen (27.03.09 14:18) [56]

Просто критика:

>TABLE TOVAR

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

а) цене в справочнике делать нечего, ибо она должна быть в КАРТОЧКЕ
б) отсутствует несколько важных характеристик товара, например принадлежность к группе (категории) товара, ссылка на прайс-листы и т.д.

>DOCUMENT
> N_DOC - номер документа (приход/расход)

В одном поле и номер и тип документа ? Это как ? У документа может быть более одного номера, например для приходов есть внеший (входящий) и внутренний (учетный). Иначе 1-го января все приходы будут нумерованы 1 или оригинальный номера будут утеряны, что чревато.

> N_DOG - номер договора
Аналогично. Если требуется аналитика по договорам (заявкам) следует определить в БД объект "Договор" ("Заявка" или "Заказ"), спроектировать его таблицы, а в документах использовать ссылки на них

> DATE_DOC - дата документа
Одной даты мало например для приходов. Накладная может быть выписана 1-м числом, а товар прибыл 2-го.

>SUMMMA_DOC - сумма документа
Одной суммы мало. Требуется еще как минимум одна - НДС. Кроме того неясно как поступать со скидками (надбавками) ?

>PRINIAL - принял (ФИО)
>SDAL - сдал (ФИО)
Опять фигня. Если приход, то одного ФИО мало и требуется еще номер и дата доверенности
Зачем два ФИО, если вполне достаточно одного - ведь двух ФИО на одном док-те быть не может

>ORG - организация (приход/расход)
Опять "рюшечки" :) Должон быть справочник контрагентов с полной инфой включая банковские реквизиты, дира, главбуха и т.д., а здесь опять-таки ссылочка

>TYPE_DOC - тип (приход/расход)

Мало ибо есть еще как минимум один тип - списание

>TABLE OPERATION
Даже не обсуждаю - полная профанация фестивалит :)
Если требуется вести журнал операций, то хотя бы нужно понять что это такое и с чем его едят - опять-таки марш к 1с

В целом "картина маслом" (с)
Выкрасить и выбросить :)

> Таблица Tovar у меня является таблицей движения

А таблица OPERATION тогда у тебя что ?

И с какого перепугу они, эти две таблицы, друг на друга ссылаются ?

Рука руку моет ?)

Ешкин хвост, таблица "Операции" типа хранит данные о фактуре накладной ? Бо ее-то (фактуры) здесь и не хватает. А если так, то опять все с ног на голове.
Возьмите хоть одну "живую" накладную и просто внимательно разглядите ее - может тогда прояснится на доске ?

> [63] Игорь Шевченко © (27.03.09 15:39)
Не всегда. Да и дешевле не значит лучше. Тоже конечно не всегда.
Но учиться то на чем то надо.
ИМХО склад и калькулятор каждый должен написать сам хотя бы раз. 8-)

Sergey13 © (27.03.09 16:00) [67]

Практически всегда. А дешевле - это объективная сторона, готовый продукт всегда по совокупности дешевле, чем собственная мучительная разработка.

> ИМХО склад и калькулятор каждый должен написать сам хотя
> бы раз. 8-)

Ни разу не писал. Пойду удавлюсь с горя :)

склад не писал. А вот калькулятор - да.
Поэтому убиваться об стену не буду, только напьюсь с горя -)

А я калькулятор не писал - мне убиться или упиться ? :)

по вкусу :) я бы упился :)

Утопиться, одним ударом по двум зайцам.

Ну а я не только не писал ни того, ни другого. Но и не разу не "фетчил". И уж тем более не "политурил"!
Так что мне всё по-фигу. :)

Дом "скорби"
Пациент с манией великого математика подходит к одному из своих соседей по палате:
- Я тебя сейчас продифференцирую !
Сосед падает в обморок. Подходит к другому:
- Я тебя сейчас продифференцирую !
Никакой реакции.
- Я тебя сейчас проинтегрирую !
Чувак забился в припадке.

"Математик" гордо озирается и, увидя в углу еще одного соседа, подходит к нему:
- Я тебя сейчас продифференцирую !
Никакой реакции.
- Я тебя сейчас проинтегрирую !
Никакой реакции.

- Ты чего не боишься !?
- А я е в степени х

← →
Xmen (2009-03-30 08:43) [75]

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

Правильное сохранение при Мастер- Детаил Найти похожие ветки