Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Как я «проектировал» систему оперативного учета Прочитав рассказ Циничного Кота о его удачном и неудачном проекте я тоже решил поделиться с людьми, и рассказать о своем опыте «проектирования». Не знаю, правда, будет ли мой рассказ точно соответствовать теме «принципы проектирования БД для учетных целей», но надеюсь, что все-таки будет. Начало В моем маленьком городке работу найти нелегко, но все ж таки удалось мне устроиться на завод оператором-наладчиком токарных станков с ЧПУ. Освоив за пару дней программирование станка, я стал думать о том, чем бы занять свои мозги, которые после написания программы типа F10 M3 X164 Y236 …(установить размер подачи, «запустить» шпиндель, «подъехать» на такую-то координату…) были совершенно свободны. Как-то раз я зашел в диспетчерскую за своим производственным заданием и стал свидетелем такой сцены. В комнате взволнованный представитель заказчика продукции нашего заводика беседовал с работниками диспетчерской: «У нас план горит, вы нам недогрузили изделий N365 в количестве 100 штук». «Да нет, мы вам отгрузили изделий N365 такого-то числа целых 150 штук!», - был ответ. «Так 100 штук из этих 150 было из заявок NN238 и 239, которые вы нам уже давно были закрыть, а про остальные 50 штук я вашему директору лично звонил». «Ничего подобного, вот нахал, я лично помню, что позицию N365 ваш начальник в заявках N238 и N239 просил аннулировать, я с ним по телефону разговаривала.Так что эти сто штук были отгружены совсем по другим заявкам!Не надо лохматить бабушку! Утверждайте новую заявку, будут вам через месяц 365-е». «Но у меня план горит! Меня же уволят!» - восклицает снабженец - «Я был на складе, такие изделия там есть, отгрузите их мне, будьте так добры». «То, что лежит на складе, предназначено для других, к тому же еще по другим заказам по этой позиции дефицит 500 штук, почему это мы именно вам их должны отвалить?» Тут в диспетчерскую входит мастер цеха полуфабрикатов и радостно риторически сообщает: «Ну вот, только что снял форму под изделие N365, теперь весь дефицит тютелька-в-тютельку будет закрыт. И чтоб в течение месяца мне о нем больше не напоминали!». Но, услышав разговор с заказчиком, тут же меняется в лице: «Да мне, чтобы сделать заготовки под те изделия №365, что вы потом брать не стали, пришлось за час до окончания работы формы переставлять в прошлом месяце. Я только что весь дефицит по ним закрыл, если они вам нужны, идите, сами форму заново ставьте!». Почувствовав, что тут и до мордобоя недалеко, я взял свое задание, и удалился, подумав про себя, что что-то в этой диспетчерской происходит не так. К тому же, я давно заметил, что те изделия и количества, что распределитель работ приносит нам на клочке бумажки, даются по какому-то непонятному принципу. Бывает, делаешь, делаешь какую-нибудь деталь полдня, переналаживаешь станок, начинаешь делать другое, а на следующий день к тебе приходят и говорят: «Делай снова то, что вчера утром делал, срочно надо». И приходится, не закончив партию, доделывать то, что можно было изготовить еще вчера без переналадки. Купив по дороге домой книжку «Access в подлиннике», я сел после ужина за компьютер и стал думать, как ситуацию поправить, какую надо сделать базу и какие в ней должны быть таблички...(если кому-нибудь будет интересно, в следующий раз продолжу свой рассказ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2003, 17:40 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Реальный опыт всегда интересен. Я бы с удовольствием почитал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2003, 09:06 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Интересно было бы увидеть комментарий специалиста по бизнес-процессам - что же там за бизнес-процессы описаны в 3 абзаце рассказа Вовчика и в чем причина конфликта - в организации учета или в неправильной организации работы служб предприятия (и как бы можно было бы эти процессы перестроить?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2003, 10:49 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Как я «проектировал» систему оперативного учета (часть 2) Поскольку имеются заинтересовавшиеся, продолжу свой рассказ. Сначала я было собрался рассказать, какую структуру я придумывал и как, но, боюсь, что если поподробнее не рассказать о том, что творится на предприятии, уважаемые знатоки не смогут определить, что в моей структуре правильно, а что нет, поэтому расскажу кратко о других аспектах работы предприятия, не отраженных в 1 части. Производство практически позаказное (это видно из 1 части), многономенклатурное, дискретное. На 8% номенклатуры (90%) в количественном выражении - достаточно устойчивый спрос. На остальное - крайне неопределенный. Готовые изделия представляют из себя несложные сборки без промежуточных узлов. 4 основных цеха - полуфабрикаты, комплектующие 1, комплектующие 2, комплектующие 3. Задачу я себе (первоначально, далее появлялись новые) поставил следующую: Организовать учет заявок и оформление отгрузочных документов таким образом, чтобы в любой момент иметь полную информацию о состоянии каждого заказа. Кстати, учет в штуках а не в рублях - это, вроде бы тоже учет, так что, я, наверное, не отклоняюсь от темы. (продолжение следует...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 18:28 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Ждем. Только рассказ такими порциями будет длиннее санты-барбары ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 18:32 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Вдогонку. Может начать заново в новом топике ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 18:33 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
x, А мне без критики учаcтников форума писать неинтересно. Хоть кто-нибудь сказал бы какую-нибудь гадость по теме... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 18:35 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Тут хоть топик приличный, а то как это можно назвать? Разве что "Как чайник писал дурацкую программу." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 18:38 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Как начнешь описывать проектные решения, так и начнут критиковать. А сейчас можно сказать какую-нибудь гадость только о порядках на твоем заводе, но это не интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 18:40 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Как я «проектировал» систему оперативного учета Часть 3 Ну, короче, дальше даже думать почти не пришлось. У одного дилера (да, у нас там еще дилеры есть) я увидел листок, на котором он ведет учет своих заявок. Этот листок выглядел следующим образом : 1)Атрибуты, касающиеся заявки (дата, вх №, уникальный номер по реестру дилера, заводской регистрационный номер, дата заявки и.т.п) 2) в строках - изделия заявки, их количества, количества в отгрузках 3) в заголовках столбцов - даты отгрузок. При перемещении изделий со склада завода на склад дилера по накладной (в которой могут входить изделия из 20 заявок дилера) девушка "разносит" эту накладную по вышеописанной бумажке (проставляет в заявке напротив соответствующей позиции дату и количество полученных изделий). Когда заявка по какой-то позиции полностью укомплектована, девушка берет желтый маркер, и закрашивает соответствующую строчку. Когда весь листок становится полностью желтым - заявка полностью скомплектована. "Вот она где собака зарыта", - подумал я, - "Нужно установить соответствие между заявками и отгрузками. Для каждой позиции заявки (номенклатуры) надо хранить следующцю информацию: даты отгрузок, количества, номер отгрузочного документа. Причем процесс "разнесения" надо как-то автоматизировать. Тут я бы сделал отступление на счет того, что вышеописанный подход я считаю неправильным. Надо было не процесс "разнесения" накладной по заявкам, а поменять всю систему работы с заявками и методику учета. А эта система была такова. 1.Поступление заявки и счет на оплату 1. Заказчик присылает заявку 2. Заявка регистрируется (вх №) 3. Заказчику выписывается счет на оплату (изделия, количества, деньги) 4. Копия счета поступает на склад 5. Копия счета поступает начальнику производства 6. Оригинал счета поступет в бухгалтерию. 7. Заявка записывалается в специальный журнал (аналог вышеописанного документа дилера) 2. "Некто" принимает решение о том, что заявка "активна" 3.Склад узнает о том, что такая-то заявка "активна" и начинает комплектовать заявку из того, что есть на складе (а если этот заказчик еще и блатной, то из изделий, предназначенных(или даже скомплектованных) для других заказчиков. 4. Начальник производства получает информацию о том, что такую-то заявку из его пухлой папки надо изготавливать. 5. С определенной дискретностью, на основании своей личной "статистики" потребления изделий и информации (неполной, естественно, поскольку складского учета тогда не было) склада о том, что "по такой-то заявке таких-то не хватает" начальник производства принимает решение изготавливать какие-то комплектующие. 6. Изготовленные комплектующие поступают на склад, где ими либо сразу комплектуют заявки по совершенно нечеткому алгоритму (об этом надо говорить отдельно), либо идут в "задел". Но обо всем этом я узнал потом, а вначале принялся "автоматизировать хаос" следующим образом … (продолжение следует) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 19:51 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Жалко, что Вовчик пропал. Всегда полезно узнать о чужих методах работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2003, 20:07 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Я думаю, еще вернется. А вот автоматизировать хаос никому бы не пожелал. Во-первых, намаетесь, во-вторых, маловероятно, что что-то путевое получится. В той системе, что он описал, очевидно следующее - процессы не синхронизированы, раз, ответственные лица не прописаны, два. Есть несколько информационных "потоков" живущих сами по себе - поток входящих заявок, поток объектов с производства и поток объектов со склада. Впрочем, не буду перебивать, хочу дослушать до конца. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 14:42 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Как я «проектировал» систему оперативного учета Часть 4. Ну а дальше, под неправильно поставленную задачу я стал придумывать структуру 1. Справочник номенклатуры (ГП) 2. Справочник всех деталей из которых собирается ГП 3. Таблица связок между 1 и 2. 4. Справочник контрагентов 5. Справочник "своих" фирм (так и не вспомнил, для чего их 2 сделал, можно было 1 обойтись) 6. Справочник "типы всего" (иерархический), там лежат типы деталей, документов, контрагентов и.т.п, короче всякая классификация. 7. Таблица заголовков заявок 8. Таблица строк заявок 9. Таблица заголовков документов (счета-фактуры, накладные, счета на предоплату, еще чего-то там...) 10. Многострочная часть документов 11. Заголовки накладных дилерам 12.Многострочная часть накладных дилеров (тоже не помню, для чего отдельно, можно было пп 8-9 обойтись через некоторое время к этому добавилось 13. Таблица движений по комплектующих 14. Таблица движений по ГП. 15.Спр.полуфабрикатов (поскольку он сильно отличается по аттрибутам от п2) 16-20 Еще всякие справочники:материалы, цеха, люди и т.п. (в принципе их тоже можно было в один свалить, ничем люди от материальов, в принципе, в данном случае не отличаются) Ну, в общем , все таблицы нет смысла перечислять, к тому же чем их больше, тем глупее разработчик.(вернее наоборот, чем глупее разработчик, тем их больше) Расскажу лучше, в чем заключался первый геморрой...(продолжение следует) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2003, 20:34 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Почему-то отсутствуют критические замечания. Все со всем согласны или моя "Санта-Барбара" никого не заинтересовала? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2003, 17:00 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Да вобщем то всё гуманно. :) Только чё то не видно журнала операций и прочей бух. хрени. типа счета, баллансы, справочник типовых проводок, корреспонденция счетов. Похоже, что оперативно учитывать деньги в задачу не входило. И ещё, пожалуй самый большой пробел, отсутствует упоминание о workflow, т.е. кто кому, когда, зачем, почему, на каком основании, опись, протокол, взял-принял, отпечатки пальцеу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2003, 09:59 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Извините что перебиваю историю, но вопрос в тему (про бух учет): В какой момент наиболее правильно было бы пересчитывать остатки с точки зрения целостности и оперативности получения данных: 1.Прописать триггер на проводки, т.е. при любых изменениях в таблице проводок пересчитывается таблица остатков начиная с даты измененной (удаленной, обновленной) проводки (остатки собираюсь хранить на каждый день по всем счетам - может это неправильно?). 2.При создании отчетов которые требуют расчета остатков. Посоветуйте плиз! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2003, 11:43 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
akuz, Да, вы правы, главная задача, которую я перед собой поставил -организовать учет заявок и расчет дефицита комплектующих под определенное подмножество заявок (план производства). Это мне предсавлялось гораздо полезнее, чем вести какие-то там счета для налоговой инспекции (или вообще для непонятно кого или чего) Если у Вас будет время, может расскаажете нам про workflow (что это такое и как его можно использовать?)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2003, 11:47 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Ну, если кому-то это действительно интересно, приведу скрипт простенькой БД, которую я разрабатывал для этих целей. К сожалению она не доделана и не пошла, ввиду решения руководства об использовании Lotus Workflow, но как начальная идея вполне работоспособна. Возможно здесь не видны некоторые другие БД, необходимые для её работы, например БД в которой хранится секурити и разнесение усеров по ролям, но уж не обессудьте. Смысл в том, что все документы, которые необходимо проводить по пути утверждения, хранятся в других БД и имеют поле [doc] [uniqueidentifier] NOT NULL, которое является неявным внешним ключом к таблице docs в этой БД, а всё что связано с прохождением документа по различным путям утверждения хранится в одном месте. Можете использовать и развить эту идею, но без меня. :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2003, 10:52 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
akuz, Спасибо за пример, но я то думал, что Вы словами расскажете, что это за workflow такое. А так - непонятно (мне, по крайней мере), что это за база и для чего она? Ну а я, раз обещал, продолжу свой рассказ. Как я «проектировал» систему оперативного учета Часть 5.("Рыба") Про геморрой, я, пожалуй, расскажу в другой раз, а сейчас я поведаю, как я вообще получил «добро» от руководства на разработку программы. Пришел я, в общем, после наблюдения сцены в диспетчерской, описанной в ч1, и в голове моей возникла структура базы почти в том виде, что я описал выше. Ключевой вопрос, как я уже говорил, заключался в том, как организовать учет заявок. Но как это сделать? Как я уже говорил, в «заявочный» журнал отгрузки вносились крайне нерегулярно и поэтому там было много ошибок. Как же автоматизировать этот процесс? Чтобы не создавать электронный аналог этого журнала, а как-то упростить весь процесс… Для этого придется рассказать более подробно про то, как происходил процесс отгрузки (о том, как происходила работа с заявкой, рассказано в ч.3). 1. Заказчик появляется перед «внешним диспетчером» и сообщает, что он хочет что-то получить по своим заявкам 2. Диспетчер идет на склад и сообщает работникам склада, что приехал такой-то заказчик и хочет что-то получить 3. Работники склада ищут копии документов (их может быть 5-8, и по каждому есть какие-нибудь «долги»), описанного в п.3 (заявки с количествами и датами отгрузок), выясняют, что «недогрузили», и что из этого скомплектовано. Если что-то не скомплектовано - комплектуют. 4. После того, как они что-то скомплектовали, они пишут на листке, что они скомплектовали и относят этот листок обратно «внешнему диспетчеру». На основании этого листка «внешний диспетчер» выписывает счет-фактуру, идет с клиентом на склад и происходит торжественная передача товара. 5. Некий человек в определенное время берет выписанные счет-фактуры и «разносит их по заявкам»(напротив позиций номенклатуры пишет количества и даты отгрузок, закрашивая «закрытые» позиции желтым маркером и вычеркивая полностью погашенные заявки. Вообще говоря, налицо как-то неправильно организованный процесс обмена информацией и распределение ролей. Вот список замеченных нестыковок: 1. «Внешний» диспетчер, общающийся с заказчиком, не имеет информации о состоянии склада и ходе комплектования заказа. При возникновении к-л спорных моментов он сразу «переключает» звонок клиента на склад. 2. Решение, что и кому отгружать принимает, по сути дела, склад на основании своего, «параллельного» учета. 3. Человек, который «разносит» заявки (на основании этой информации затем планируется производство), никак не заинтересован в качестве своей работы. 4. Зачастую начальник производства принимает решение что-либо изготавливать на основании информации склада о том, что «по такой-то заявке того-то не хватает». Если бы я был бизнес-аналитиком, я бы, пожалуй предложил варианты, как надо перестроить процессы учета заявок и отгрузки ГП, но тогда я принялся автоматизировать то, что есть. В таблице многострочной части заявок сделал несколько полей «отгружено1», «отгружено2»… «отгружено5» (то же самое с датами) – чувствую, что сейчас мне достанется за такую кривую структуру - и написал процедуру, которая «разносит» накладную по следующему алгоритму: 1. берет позицию из накладной клиенту 2. Ищет самую раннюю заявку данного клиента. 3. Если отгруженное количество> долг, прописать в поле «отгружено N» число=Долг, запомнить Котг=Котг.-Долг (Если Котг<Долг, прописать это и закончить процесс) 4. Найти такую же позицию в более поздних заявках. 5. Повторить п 3. 6. Взять след. позицию накладной 7.Повторить все с п 2. По сути дела этот алгоритм реализует логику «справедливого разнесения заявок», когда отгружаемое количество погашает сначала более раннюю заявку, затем более позднюю и.т.п. То есть делал то, что как я потом догадался, должен был вносить в систему тот, кто и принимал решение о том, что и по какой заявке он отдает – склад. Но тогда на складе компьютера не было, учета тоже, и я сделал то, что сделал Ну а далее я сделал быстренько формы ввода заявок, выписки счетов и кнопку «провести накладную и разнести по заявкам», ввел несколько тестовых заявок, и показал лицу, принимающему решение (жене директора), как можно усовершенствовать работу с заявками. «Вот смотрите, как упростится работа», - пел я как соловей, - «вот сюда вносятся заявки, вот здесь выписываются счета. Далее оператор нажимает на кнопочку – и все, далее – любая информация доступна: все дефициты, нехватки и состояние каждого заказа и в деньгах и в штуках». «Да, в этом что-то есть», сказало ЛПР. Через неделю я сидел в диспетчерской и в рабочее время писал свою прогу. Но все оказалось намного сложнее, чем представлялось первоначально. (Возможно, будет продолжение) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2003, 20:45 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
1. Вот объясните мне, зачем выдумывать велосипед. Ведь на текущий момент существуйте море продуктов решающих проблемы бухгалтерского учета. Ваша задача закодировать процесс отличный от бухгалтерского. Нужно создать конвертер который будет выплевывать результаты в программу бухгалтерского учета. Обязанность бухгалтера настроить проводки по документам и прочую сопутствующую информацию. Учетчику не нужны проводки, бухгатеру не нужны вся лабуда со складом. Все довольны и друг другу не мешают. Сложнее когда бухгалтер он же учетчик. Он начинает применять свои дебиты/кредиты к вашей программе, в итоге получается страшный монстр. 2. Для реализации успешного проекта необходимо: - Четкая постановка задачи. Причем любое дальнейшее дополнение ТЗ ведет к увеличению срока разработки, сдачи проекта и финансовых вливаний. Во многом случае это заставляет заказчика лишний раз задуматься над своим бизнес процессом и более плодотворно поработать с постановщиком. К тому же на этапе проектирования возможен вариант изменения бизнес процесса заказчика с уже некоторыми функциями системы (многие фирмы пытаются внедрить у себя известные программы, но пока результаты слишком незначительны, т.к. начальство не может понять, что легче пересторить свой бизнес процесс, чем переработать под свои нужды программу). - Выбор средств проектирования, программирования следует выбирать на основе того, чем владеет группа разработки, а не определять среду разработки, а уж потом набирать или переучивать людей. 2 Вовчик Суды по вашему описанию постановкой вы занимались так сказать на ходу выясняя все новые и новые подробности ? Если ДА, то в таком случае Ваш проект склоненн к постепенному загибанию (конечно если он уже не реализован или не загнулся :-) ). При таком подходе несколько полей «отгружено1», «отгружено2»… «отгружено5» (то же самое с датами) Вы будете обречены на изменение как самой базы, так и программы в случае если этих отгрузок потредуется больше чем заложенно. Ну да ладно. Моя цель здесь не чувствую, что сейчас мне достанется за такую кривую структуру все же интересно почитать мысли в проектировании других людей. 2 wara. Вы сейчас задали вопрос не из области программирования, а из области "Управление знаниями". В ней описаны не структуры, не конкретные реализации на конкретных языках программирования, а общие методы и подходы к описанию процесса учета чего-либо. Уже многие пытаются систематизировать такие знания, но пока к сожалению информации и результатов практически нет. А чтобы получить такой результат, необходимо участие большого количества разработчиков и не меньшее количество технических писателей. Благо когда качество разработчика и писателя совмещены в одном лице, в большенстве же случаев (и я в том числе) программисту сложно описать все что у него в башке на нормальном языке. Сам себе удивляюсь сколько написал. НАдеюсь все понятно или ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2003, 00:36 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Andrew Campball По пп 1-2 полностью согласен По п.3. Не надо на Вовчика нападать. Он ведь свой первый опыт описывает. Ну ясно дело, с первого захода хорошую базу не напишешь. Своего опыта не хватает и веришь задачедателям. «отгружено1», «отгружено2»… «отгружено5» - это наверняка кто-то из кладовщиков напел: "Мол больше пяти отгрузок у нас не бывает". Это уже потом приходит понимание, что если задачедатель говорит "Так делается всегда", то это значит, что через месяц все поменяется. А если он говорит "Этого не может быть никогда", то, значит, в следующем году это обязательно случится. И умение на автопилоте писать нормализованую базу тоже не сразу приходит. По п.4. Именно это и хотелось видеть главным предметом разбирательства в форуме "Проектирование БД". Как селект написать или как отчет напечатаь - это в других. Сомневаюсь я, что если взять пару сотен разработчиков и технических писателей, то они быстро все систематизируют, опишут и дадут стройную теорию. Вот канаву они быстро выкопают, намного быстрее чем выкопал бы один Кодд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2003, 01:49 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Ну что же, попытаюсь описать моё понимание workflow. Сознательно не перевожу это понятие на родной язык, потому что все известные переводы не отражают суть. В моём понимании workflow, это динамическая система разграничения полномочий. Для каждого объекта в системе на любой момент времени, в зависимости от состояния объекта, существует определённый набор действий, разрешённый определённым ролям, в отличие от общепринятых систем разграничения полномочий, реализованных, например, в MSSQL Server и имеющих предопределённый, не зависящий от состояния объекта, набор действий и маску разрешений. Возьмём для примера заявку на какой либо ресурс. Допустим она имеет следующие атрибуты: Этап: 1. Инициация (заявки нет в системе) 2. Выпуск, 3. Утверждение, 4. Исполнение, 5. Архив; Состояние: 1. Создана, 2. Выпущена, 3. Утверждена, 4. Отклонена, 5. Исполняется, 6. Помещена в архив; Возможные действия: 1. Создать, 2. Выпустить, 3. Просмотреть, 4. Редактировать, 5. Утвердить, 6. Отклонить, 7. Закрыть, 8. Удалить. Список ролей: 1. Сотрудник, 2. ЛПР, 3. Исполнитель Для каждого этапа мы имеем маску полномочий: Действие | Кому разрешено | Новый этап | Новое состояние 1. Начальное состояние (заявки нет в системе) Создать | Сотрудник | Выпуск | Создана 2. Выпуск Просмотреть | Сотрудник | Выпуск | Не меняется Редактировать | Сотрудник | Выпуск | Не меняется Выпустить | Сотрудник | Утверждение | Выпущена Удалить | Сотрудник | Удаляется из системы и т.д. Такие же маски мы имеем для любого другого типа документов. Тут есть ещё масса наворотов с персонофикацией прав, т.е. с динамическим переназначением состава ролей для каждого экземпляра документа, навешиванием специфических обработчиков на каждое действие, ведением журнала действий и т.д. Вобщем не всё так просто, как кажется на первый взгляд, но если у вас имеется достаточно разнообразный и продвинутый workflow, то такая система оправдывается с лихвой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2003, 13:44 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Cat2 Сомневаюсь я, что если взять пару сотен разработчиков и технических писателей, то они быстро все систематизируют, опишут и дадут стройную теорию. А не кто и не говорит, что все должно быть быстро. Просто это нужно делать систематизированно. Организовать виртуальный клуб в котором можно обсудить все тонкости учета. Соответсвенно, после обсуждения вносит исправления или дополнения в уже готовый документ описания сущности задачи. И т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 12:18 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
2akuz Ты забыл добавить: гарантированная доставка сообщений - типа, звонят в бухгалтерию а им отвечают что никто заявку на покупку стульев не получал ну и как следствие прозрачность или контроль - т.е. однозначно можно определить получала бухгалтерия заявку или нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 12:29 |
|
||
|
Принципы проектирования БД для учетных целей
|
|||
|---|---|---|---|
|
#18+
Всем спасибо за интересные комментарии. Прямо так и хочется воскликнуть как герой фильма "Короткое замыкание": "О-о-о, information" Andrew Campball 1."Суды по вашему описанию постановкой вы занимались так сказать на ходу выясняя все новые и новые подробности ? Если ДА, то в таком случае Ваш проект склоненн к постепенному загибанию (конечно если он уже не реализован или не загнулся :-) ). " A:Да, заниматься постановкой задачи приходилось по ходу пьесы в довольно экстремальных условиях. Однако, несмотря на это, "проект не загнулся"(Вам, может быть от этого и было бы весело, а мне - нет), а принес, несмотря на шероховатости, значительную пользу решив следующие задачи: 1.)Автоматизирована работа с заявками 2) Автоматизирована работа склада 3) Склад, внешний диспетчер, внутренний диспетчер, начальник производства и сотрудники ПДО и т.п. работают в единой информационной среде, получая ценную оперативную (и "аналитическую" информацию) 4)Автоматизировано составление плана многономенклатурного производства ( 2500 позиций номенклатуры) в условиях практически непредсказуемого спроса (количества заказываемых изделий одной номенклатуры колеблется от 0 до 10 000 шт.) В результате использования программы предприятию удалось справится с большим объемом заказов в период пика без найма доп. раб. силы (только за счет "полуручного" планирования запасов и удобного плана производства) и создать запасы дефицитных изделий пропорционально пронозируемому спросу в период практически полного отсутсвия заказов без увольнения сотрудников. Была собранна ценная статистика по динамике спроса и производительности труда рабочих, выяснилось, к примеру .... 2 Andrew Campball, ("При таком подходе несколько полей «отгружено1», «отгружено2»… «отгружено5» (то же самое с датами) Вы будете обречены на изменение как самой базы, так и программы в случае если этих отгрузок потредуется больше чем заложенно.") A: Несмотря на неправильность такой структуры, это ни разу ни привело ни к каким проблемам (хотя я согласен, что сделано некрасиво) - я ни разу не видел, чтобы одна и та же номенклатурная позиция отгружалась по одной конкретной заявке в 5 приемов - максимум в 3 3.Andrew Campball, надеюсь, что Вас не затруднит дать совет начинающему на следующий вопрос: Постановка задачи: Необходимо как можно быстрее создать связанную с данными форму (при изменении данных в форме должны меняться данные в источнике данных) следующего вида (OLAP - компоненты и перекрестные запросы не использовать, как и "ручную" загрузку данных в сетку и выгрузку в таблицы, temp-таблиц - не более одной, а желательно вообще без них): заголовки столбцов - количество1, дата1, количество2, Дата2 ...количество N, Дата N Строки - позиция номенклатуры, количество в заказе, количество в 1 отгрузке, дата 1 отгрузке, количество во 2 отгрузке, дата 2 отгрузки, ...количество в N отгрузке, дата N отгрузки. Данные заявок хранятся в таблице следующего вида : id строки заявки, FK заявки,FK номенклатуры, количество. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2003, 20:29 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32139679&tid=1546098]: |
0ms |
get settings: |
6ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
57ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 239ms |
| total: | 372ms |

| 0 / 0 |
