| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Нумерация документов [D7, Paradox]
Leon1 © (2005-01-28 08:28:00)Народ, ни кто не сталкивался с данной штукой? как лучше реализовать? естественно Номер документа как первичный ключ не подойдет! У меня есть идеи например:
1)реализация с помощью отдельной таблицы с автоинкрементным полем в которую производится вставка перед открытием документа тем самым можно получить значение следующего номера, минус этого способа если документ будет открыт и не записан получится что номер пропал
2)То же что и первое но вставка производится после запсиси документа, а значение автоинкрементного поля получается в момент открытия документа и увеличивается на 1.. минус пользователь может держать фиг знает сколько этот документ открытым и могут родиться документы с содинаковыми номерами
3) SQL запрос на MAX(NumDoc) минус точно такой же как и у 2 способа
4) SQL запрос на COUNT(*) минус номера должны быть изменяемыми и если после первого пошел 10 то следующий получим не 11 а 3...
Мож кто то подскажет еще какие нибудь решения?????
Leon1 (2005-01-28 14:22:00) [21]По поводу таблиц посню явно, главная таблица реквизитов, есть таблица со строками документов грубо говоря по механизму
Master->Detail в основной есть Id в другой есть Pid поле, Id является сурогатным ключем следовательно для вставки данных в Detail таблицу нужно
а) чтобы запись с Pid = Id находилась в БД
б) нужно знать этот самый Id чтобы присвоить его Pid
Для любой субд (и это факт) до физического попадания Записи в Master таблицу предугадать какой Id пудет не возможно, если это конечно не однопользоватльская программа
т.е. получается пока шапка документа не записана то речи о вставке стро быть не может, т.е. сначала сохрани шапку а потом вбивай строчки
В случае если в дело вступает 3 таблица то получим следующее:
1) Таблица содержит(ID,NumDoc,DateDoc,TimeDoc);
2) Таблица содержит(IDDOC,KONTR,DOGOVOR, и т.п.);
3) Таблица содержит(PID,TOVAR,RASHOD);
При создании документа вставляем запись в 1 получаем что вставка для 2 и что самое важное для 3 производится до записи документа... пользователем в случае отмены все просто банально удаляется... вот суть идеи
Соловьев (2005-01-28 14:07:00) [22]> по написанию сложных ERP систем....
о Парадоксе я тут промолчу ... :)
Соловьев (2005-01-28 14:05:00) [23]у каждой халявы есть ограничения 8) у MSDE - 5 коннектов.
msguns (2005-01-28 14:04:00) [24]Крик души ?
Leon1 (2005-01-28 14:00:00) [25]2 Соловьев MSSQL за баксы MSDE халява! :-) Поясню, поскольку в Delphi я человек не такой уж и опытный, то избрал для начала Paradox просто посмотреть что да как и вообще что кчему как работает и т.п. я конечно понимаю что есть масса компонент типа FibPLUS которые значительно способствуют у программиста развитие желания и интереса работать над самим программным продуктом а не ловить грабли на тему типа а почему IBTable такой плохой или а почему IBQuery не то.. то.. то.. Именно основное дело заключается в том, что отсутсвует нужная информация или за частую ее просто тяжело выловить в просторах сети или на книжных прилавках, подумайте, чему учат в институтах и в мудреных толстых томах, я лично имею немалый набор книг по Delphi но насколько помню в институте нас учили использовать BDE и Paradox а о сложных фомах мы и знать не знали... показывали общие примеры типа TDataBase TTable TQuery TDbGrid TDBNavigator все... за сим откланились взяли курсовые и бай бай... ни в одной книге я не видел описаний методик реализации механизма рассчета остатков... или механизма подбора по товарной номенклатуре все как то приведено в общем для небольшого количества и естественно литература не дает исчерпывающие ответы на вопросы, после чего возникают мучительные думки... блин а как этот механизм покажет себя на пактике... я сам в основном около 3 лет занимался конфигурированем 1С и как бы и подзабыл уже некоторые аспекты разработки ПО в таких системах как Delphi.... исключительно мое мнение... о данному вопросу... на рынке отсутсвуют просто методические пособия по написанию сложных ERP систем....
Соловьев (2005-01-28 13:10:00) [26]msguns ©
Вам надо за посты памятник ставить, так много писать(и главное по делу) это надо уметь! 8)
msguns (2005-01-28 13:09:00) [27]Ни в коем случае не инкремент для номера !!! Ни в коем случае ! Буквально через неделю эксплуатации проги операторы будут плеваться на такой автономер. Я уж молчу о сбросе нумерации с 1-го января и раздельной номурации для каждого типа документов при том, что заголовки их могут лежать в одной таблице.
Соловьев (2005-01-28 13:08:00) [28]Да политику формирования номера надо конечно решать на организационном уровне, но взявшись за дело, ты сразу почему-то уперся в кокретные проблемы Парадокса. а не организационные, в первом посте ты их описал.
Предпочитаю MS SQL и я, но на него деньги нужны и не малые. А FireBird бесплатен.
msguns (2005-01-28 13:06:00) [29]>Leon1 (28.01.05 12:40) [18]
>и тута новая проблема..... ох...
Проблема не "тута", а в отсутствии опыта. Но это дело временное ;))
Не надо путать две вещи: заголовок документа (Гл.таблица) и фактура, отнесенные платежи и т.д., т.е. подчиненные таблицы. При добавлении в таблицу нового заголовка (создание нового документа) запись постится сразу. И только потом узер вводит фактуру. При этом новый № уже есть в БД и другой узер на другом компе получит свой автономер уже с учетом первого. Вероятность одновременного ввода новой заголовкаотгрузки двумя узерами достаточно мала, но если такое даже случится, оба это увидят еще ДО печати документа и смогут исправить его (№). Проблема дубликатов, ИМХО, высосана из пальца и решается морями способов, в т.ч. с помощью упомянутой литерной части.
Советую обратить особое внимание на другие вещи: актуальность остатков и транзакционность (т.е.целостность пакета изменений в БД и т.д.). Здесь ожидаются куда более сурьезные траблы, особенно с учетом кривизны локалок, где парадокс чуть ли не лидирует по глюкавости.
Leon1 (2005-01-28 12:59:00) [30]2 Соловьев да сейчас помоему дело не в самой СУБД а в практике реализации нумерации документов, факт есть факт что инкреметное поле не подойдет, а Paradox это или Interbase именно в данной задаче роли нет ни какой, причем мне известно дофига примеров НОРМАЛЬНОЙ работы с БД Paradox, и помоему Interbase или Paradox дело каждого я лично предпочитаю MSSQL но склонять и пропогандировать к переходу на него не буду и не хочу:-) так лирическое отступление ни кого не хотел обидеть если что
msguns (2005-01-28 12:56:00) [31]>Leon1 (28.01.05 12:26) [13]
Предусмотри текстовую часть. Дело в том, что возвраты часто "нумеруют" как <№ прихода>"Возврат" или подобное. Избавишь себя от траблов будущем. Послушайся совет стараго израненого ветерана ;)
>Sergey13 © (28.01.05 12:31) [15]
Дело говорит
>Соловьев © (28.01.05 12:31) [16]
Это я против "птички" !? Саня, ты не прав. Если разрабатывается новый проект или коренным образом перерабатывется старый, я - первый, кто за то, чтоб забыть про локалки (любые)
По поводу нарушения порядка. Никто, нигде и никогда не требует, чтобы нумерация первички была непрервывной. Главное, чтобы одним номером не обзывались два однотипныхдокумента (например, два прихода или две отгрузки). И это вполне ясно зачем - во избежание путаниц при встречных проверках налоговиками.
Вот именно для этих целей и "придумана" литерная часть. Очень часто бывает, что покупатель, забирая товар (накладная может быть выписана неделю назад, а товар отложен или даже перемещен со склада в другое место (фура), обнаруживает, что он что-то забыл и просит "добавить". В этом случае удобно оформить добавку новым документом (накладной отгрузки) с номером, таким же как основная с прибавочкой "доп".
При отображении списка документов на клиенте очень рекомендую предусмотреть панельку для ввода узером доп.условий выборки, куда обязательно включить контрагента и период. И по умолчанию сортировать по дате-времени создания документа (часто они должны совпадать с временем фактического перемещения товара). Такая схема удовлетворяет 99% пользователей проги. А то, что №№ документов будут не подряд - не страшно абсолютно. Хотя бы потому, что если можно, оператор (бухгалтер) может его перенумеровать (например, для внутренних или приходов) или поменять дату.
Leon1 (2005-01-28 12:40:00) [32]Если два пользователя одновременно открыли документ тут и возникает колизия, но если чуть раньше или чуть позже то все буде акейно! в крйнем случае тут можно установить блокировку на таблицу и получим что то вроде пока новый номер добаляется то другой пользователь не может создать новый документ или что то в этом духе, но тут создается другой вопрос! а что если пользователь повис в момент открытия документа.. ведь блок то ни кто не снимет %-) и тута новая проблема..... ох...
ЮЮ (2005-01-28 12:33:00) [33]>случае отказа от создания документа можно просто удалить эту запись из таблицы...
Последний был № 4
Первый пользователь взял № 5
Второй взял № 6
Второй сохранил
Первый отказался
№ 5 - пропушен
См.[4]
Первый пользователь взял № 5
Второй взял № 5
Второй сохранил
Первый отказался
Если и первый попытается сохранить, то получит предупреждение, что №5 уже существует и будет предложен №6.
Соловьев (2005-01-28 12:31:00) [34]2 Leon1 (28.01.05 12:26) [13]
Нарываюсь на msguns 8). Но!
Пока не поздно уйдите Вы от этой СУБД, перейдите на нормальную клиент/серверную - FireBird например( http://firebird.sourceforge.net, http://ibase.ru)
Избавите себя от кучи головной боли.
Sergey13 (2005-01-28 12:31:00) [35]А какова первопричина твоей озабоченности? Дырки в нумерации? Неупорядоченность номеров при упорядочивании по дате? Так это вроде не регламентируется нигде и никем. Только "красивость" страдает.
Я бы забил на это.
Leon1 (2005-01-28 12:28:00) [36]P.S. Кстати при такой схеме работы можно наполнять и табличную часть документа записями не запоминая при этом данные шапки!
Leon1 (2005-01-28 12:26:00) [37]Вожможен еще вариант такой,
заводится отдельная таблица которая содержит
Уникальный идентификатор(Id),
номер документа(NumDoc),
дата документа(DateDoc),
время документа(TimeDoc),
далее таблица с шапкой документа там контрагенты договора прочая мерзлость, заводится еще одно поле грубо говоря Pid (Parent Id) этот самый Id связывается с Pid т.е. получаем что запись в шапочной таблице документа является дочерней для Таблицы с дребеденбью о номерах и т.п. в таблице с шапками документов на событие OnNewRecord вешаем что то вроде этого
With TQuery.Create(Self) do begin
DataBaseName:='CarsDataBase';
SQL.Add('SELECT MAX(Number)+1 AS MaxDocNumber FROM SRASPOR');
Open;
SRasporTable.Append;
SRasporTable.FieldByName('Number').AsInteger:=FieldByName('MaxDocNumber').AsInteger;
SRasporTable.FieldByName('DocTime').AsDateTime:=SysUtils.Time();
SRasporTable.FieldByName('DocDate').AsDateTime:=Date();
SRasporTable.Post;
Close;
Free;
End;
Тем самым гарантировано не произойдет колизии в момен записи документа номер будет занят на протяжении всего времени работы пользователя с документом а в случае отказа от создания документа можно просто удалить эту запись из таблицы... но это мое ИМХО....
Leon1 (2005-01-28 12:17:00) [38]Я как раз к этому и склоняюсь, тут как раз назревает вопрос о введении задним числом... это просто мрак получим
1
2
3
4
5
99
6
7
8
9
Как то явно не красиво получается а что делать... ничего...
Sergey13 (2005-01-28 11:43:00) [39]2[10] msguns © (28.01.05 11:17)
>от тебя требуется лишь предусмотреть такую возможность
В том то и дело, что пока не требовалось. 8-)
>и "счет" становится "накладной".
Интересные превращения. Рубли там долларами не становятся? Нет? Жаль. 8-)
Можно конечно придумать ситуации, но смысл этого мне все равно не понятен. Я не против твоей концепции, просто мне она кажется слегка излишней на практике в подавляющем количестве случаев. Может я и ошибаюсь.
msguns (2005-01-28 11:17:00) [40]>Sergey13 © (28.01.05 11:08) [8]
>Я не вижу особых причин вообще редактировать номер. Просто смысла не вижу, а гемороя добавляет.
Так от тебя не требуется видеть смысл, от тебя требуется лишь предусмотреть такую возможность ;)
Ладно, так и быть, один из вариантов смысла:
Есть системы, в которых нет счетов. Вернее, они вообще-то могут печататься, по ним резервируется товар и т.д. Фактически же "счет" есть не что иное, как непроведенная накладная отгрузки. Когда покупатель забирает товар, то накладная проводится (снимаются остатки со склада) и "счет" становится "накладной". Естественно, нумерация счетов и накладных разная. Вот оператор перед проведением документа и меняет № с "Номера счета" на "Номер накладной отгрузки"
| |
Страницы: 