|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 all: Собственно что нужнО : Задумали у нас на предприятии новое направление, под него решил начальник построить склад с кучей стилажей в каждом из которых туева хуча ячеек. И чтобы определенный товар приходовался/хранился/отпускался только на/в определенной ячейке. Всебы ничего, но, как всегда предчуствуя что он гаденыш чегото не додумал, задал вопрос : а может ли быть ситуация когда в 1 ячейке будет не 1 вид товарной позиции а 2,3, или Х, хотя решили что Х это много и ограничились Y :) При всем при этом он имеет желание чтобы вёлся учет движения в ячейках (т.е. на складской накладной было расписана позиция товара в виде ячейка а - 27 шт, ячейка с 63 шт и т.д. и т.п.) и потом можно было посмотреть кто и когда и сколько чего совал в указанную ячейку, ну и тому подобные фатальные идеи. Еслиб все ограничилось жесткой связкой - 1 товар - фиксированный набор ячеек и 1 ячейка - 1 товар - я бы и не кряхтел про это, но ситуация немного всовсем стала плохая :) Нечто подобное есть у фирм торгующих автозапчастями (человеки из таких фирм - весьма интересен ваш опыт) Кто с таким сталкивался ? Кто как решал ? Буду рад услышать любые идеи, советы, соболезнования :) Если это принципиально : платформа - сейчас WinNT4+IB5.6 будет FreeBSD+Firebird 1 or 1.5 если к тому времени вылезет, среда разработки Delphi. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2003, 14:01 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
С первого взгляда, особых проблем реализации не видно. Просто дополнительная детализация, по аналогии со множеством складов фирмы. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2003, 14:05 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 _ChaiNik:" С первого взгляда, особых проблем реализации не видно. Просто дополнительная детализация, по аналогии со множеством складов фирмы. " Это да - сам понимаю что это не более чем склад в ячейке, но такая детализация угиммораивает учет, и усложняет мне жысть - а это не есть хорошо Может есть какието другие варианты ? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2003, 14:11 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Ну у нас работает, уж сколько времени - все нормально. Товар приходуется на склад - как обычно. Но при этом еще есть список ячеек, куда это нужно положить - ячейки привязаны к складу, товары привязываются к ячейкам - туды их и кладут люди. Нет проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2003, 14:17 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 tygra:"Товар приходуется на склад - как обычно. Но при этом еще есть список ячеек, куда это нужно положить - ячейки привязаны к складу, товары привязываются к ячейкам - туды их и кладут люди. Нет проблем." Блин...обломали весь настрой - прийдется идти и работать над собой и своей задачей ... |
|||
:
Нравится:
Не нравится:
|
|||
17.09.2003, 14:45 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Интресно было б сравнить варианты структуры под такой прикольный склад. И еще: я тут в одной книжке прочел, что систему БД лучше проектировать, начиная не со схемы РБД, а с "концептуальной модели". Интересно было бы услышать мнение опытных людей, насколько оправдано использование этих "концептуальных моделей" при проектировании, и, если оправдано, привести вариант "концептуальной модели" под упомянутую задачу. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.09.2003, 11:00 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
У меня "родилась" такая структура, не знаю, насколько это правильно: 1. Товары (Id товара, и.т.п) 2. Склады (ячейки)(Id склада, и.т.п) 3. Движения товара (Id движения, FK товара, FK from (откуда), FK out (Куда), сколько, дата) 4. Текущее состояние (ID, FK товара, FK склада, количество) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2003, 12:54 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Я бы основал такую систему на иерархических структурах. Примерно так: table Storage Storage_ID number -- Идентификатор места хранения Owner_ID number -- Идентификатор верхнего уровня Storage_Name string -- Наименование Таким образом мы получим дерево хранения: Подразделени->Склад->Комната->и т.д. до ячейки включительно. В дополнительной таблице(ах) можно хранить некоторые характеристики мест хранения, например емкость низовых мест хранения (ячеек) table Product Product_ID number -- Идентификатор товара Owner_ID number -- Идентификатор верхнего уровня Product_Name string -- Наименование Та же самая структура. Верхний уровень - классификация товаров (изделий), последнее звено - конкретный товар (изделие). В дополнительной таблице хранятся характеристики товаров. Рекомедую сделать такую таблицу table Detail Product_ID number -- Идентификатор товара Detail_ID number -- Идентификатор параметра Value# string -- Значение параметра Таким образом мы сможем хранить самые разнообразные характеристики товара не заморачиваясь по поводу столбцов в таблице параметров. Отдельно можно сделать таблицу с ценами, которые можно изменять во времени: Product_Price Product_ID number -- Идентификатор продукта Price_Date date -- Дата актуальности цены товара Price_$ number -- Собственно цена Теперь элементарно можно сляпать таблицу приход/расход: table Product_Balance Operation_ID number -- Идентификатор операции Product_ID number -- Идентификатор продукта Storage_ID number -- Идентификатор продукта Balance_Date date -- Дата операции Count# number -- Количество Приход товара - положительное число, расход - отрицательное. Таким образом мы имеем актуальное значение количества единиц хранения и заполненность ячеек в РРВ. Для того, чтобы запросы выполнялись шустро (представьте как разрастется таблица за три года!!!) да и старые записи лучше иногда удалять, необходимо сделать таблицу остатков, той же структуры, но без поля Operation_ID. Подводить итоги лучше всего после сдачи бухгалтерского баланса или после проведения инвентаризации, то есть задним числом (на первое января когда на дворе апрель). В качестве Operation_ID можно использовать номер документа (накладные и т.п.), при условии что все документы имеют сквозной идентификатор и легко достаются. И еще немного. Это расчитано на работу в Oracle. Есть вопросы - задавайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2003, 14:22 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
> Приход товара - положительное число, расход - отрицательное Нехорошо. Лучше иметь два поля: откуда уходит и куда приходит товар. Если приход, то "свою" ячейку ставим в поле "Куда"; если расход -- то "Откуда". Каждое из этих полей ссылается на, например, номер договора (отслеживаем отношения с поставщиками/заказчиками) или номер ячейки склада (отслеживаем перемещения внутри склада, между складами, цехами и проч.). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2003, 15:45 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Владимир П. > Приход товара - положительное число, расход - отрицательное Нехорошо. Лучше иметь два поля: откуда уходит и куда приходит товар. Если приход, то "свою" ячейку ставим в поле "Куда"; если расход -- то "Откуда". Каждое из этих полей ссылается на, например, номер договора (отслеживаем отношения с поставщиками/заказчиками) или номер ячейки склада (отслеживаем перемещения внутри склада, между складами, цехами и проч.). Не люблю поля со значением NULL , это не есть хорошо. Каждое поле в любой ячейке должно содержать информацию. Это раз. Второе. Информация о приходе и расходе заносится одной процедурой (убираем лишний код). Номер договора и прочая лабуда об операции содержится в документе (Operation_ID), нас она мало интересует, в данном случае. Документооборот - отдельная тема. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2003, 16:08 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Все правильно, но не до конца продумано. Знак значения в поле количество не отражает тип операции. С минусом может быть любой расход (брак, списание, продажа и т.п.) Лучше добавить еще поле, тип операции. А в справочнике типов операций указывать тип влияния на остаток (-1,0,1 - уменьшает/не изменяет/увеличивает). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 09:11 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 VKomarov Для учета без разницы причины движения. Важен вектор (приход или расход). Причины отражаются в документах (накладная, акт списания, приходный ордер etc.) А лишнии поля плодить не стоит, информацию нужно хранить компактно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 09:53 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 Jinn Для учета и последующей аналитики как раз важны причины движения. Если отражать причину движения в документах, то указывать знак операции (вектор) нет необходимости вовсе. Всегда можно знать как влияет документ на остаток товара. Использовать число со знаком в поле значения - есть плохой тон и типичная ошибка программирования. На первый взгляд это облегчает проектирование, однако потом затрудняет дальнейшую разработку. Особенно это становится заметно, когда проект перерастает только складской учет и требует дополнительной аналитики. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 12:30 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
VKomarov Особенно это становится заметно, когда проект перерастает только складской учет и требует дополнительной аналитики. Ну вот, мы и подошли к аналитике :) На самом деле, складской учет всего лишь часть бухучета. Эту часть я просто грубо выдрал из предложенной мною однажды системы документооборота (не только бухгалтерия, но и прозводство в целом) и адаптировал под поставленную задачу (учет движения на складе). В нормальных условиях направление движения задавалось именно типом документа . В данном случае я сознательно отказался от этого, поскольку вопрос стоял именно о движении на складе, и в данном случае трудозатраты на разработку будут несколько меньше, чем при разработке комплексной системы документооборота и бухучета. А систему отвергли. Из за кажущейся сложности и отсутствия времени. Если интересно - можно обсудить. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 13:09 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 Jinn >В данном случае я сознательно отказался от этого, поскольку вопрос стоял именно о движении на складе, и в данном случае трудозатраты на разработку будут несколько меньше, чем при разработке комплексной системы документооборота и бухучета. Если некий товар передается, скажем, с фирмы на другую фирму. Это у Вас с минусом будет или с плюсом? А если фирма своя же? А если товар при этом не покидает пределов склада? Тогда движения, как бы и нет? IMHO, при таком подходе (плюс-минус), трудозатраты будут значительно больше при малейшем изменении ТЗ в сторону универсальности. Например, одновременно вести два склада, физически находящихся в одном помещении. >На самом деле, складской учет всего лишь часть бухучета. А вот тут, категорически солидарен. Более того, рискну заметить, что при нормальной постановке бухучета, от складского учета, как сущности, можно отказаться вовсе. ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 14:10 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Некто >В данном случае я сознательно отказался от этого, поскольку вопрос стоял именно о движении на складе, и в данном случае трудозатраты на разработку будут несколько меньше, чем при разработке комплексной системы документооборота и бухучета. Если некий товар передается, скажем, с фирмы на другую фирму. Это у Вас с минусом будет или с плюсом? А если фирма своя же? А если товар при этом не покидает пределов склада? Тогда движения, как бы и нет? Для склада без разницы куда уходит товар (продукция) в цех, другому собственнику или на другой склад. Запись будет иметь знак минус. Этот товар со склада "ушел". А если принимать во внимание то, что у нас учет ведется вплоть до места хранения (ячейка) то мы можем перекладывать товар из одной ячейки в другую. Например - складывение однотипного товара из нескольких ячеек в одну. В этом случае мы отобразим расход по этим ячейкам (знак минус) и приход в ячейку хранения (знак плюс). Все это будет отображено в одном документе (Operation_ID). Надеюсь здесь стало понятней? :) IMHO, при таком подходе (плюс-минус), трудозатраты будут значительно больше при малейшем изменении ТЗ в сторону универсальности. Например, одновременно вести два склада, физически находящихся в одном помещении. Особых проблем не будет. Просто функции складского учета плавно перетекут в систему бухучета, в материальную группу. >На самом деле, складской учет всего лишь часть бухучета. А вот тут, категорически солидарен. Более того, рискну заметить, что при нормальной постановке бухучета, от складского учета, как сущности, можно отказаться вовсе. ;-) Это будет не сущьность, но модуль (или задача, как в постановке). Так же как и "касса", "зарплата" etc. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 14:58 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
У нас огромный продовольственный склад, принадлежащий нескольким юр. лицам. Ассортимент: готовая продукция, производимая несколькими юр. лицами, сырье для произ-ва, товар. Продукция, сырье и товар могут быть как собственными, так и принимаемыми на хранение. Схема реализована согласно принципов бухгалтерского учета. Ячейка выступает аналитическим показателем проводки. Отслеживаются партии объектов хранения, сроки хранения, заполненность ячеек, доступность объектов для выгрузки, возможность загрузки определенного объекта в определенную ячейку. Существует несколько типов операций: приход, расход, возврат, перемещение, инвентаризация, трансформация (разборка и сборка объектов хранение, например разбока палеты на ящики). Все это крутится на MS Sql Server, большая часть бизнес логики делается хранимыми процедурами, остальное на MS VBScript. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 17:32 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Тишкин Алексей, схема сильно отличается от того, что предлагает Jinn? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 17:59 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 Varan Не стоит забывать что я привел упрощенную схему (фактически только ядро). Если ее расширить то можно завернуть и под такую, которую описал Тишкин Алексей , без особых напрягов. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 18:06 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Вообще-то все давно придумано - всегда есть лицевые счета - как объекты учета, документы и соответсвующие им проводки (это как раз и есть ДВИЖЕНИЕ по счетам). При этом атрибуты проводки - это ( id_документа, сумма, дата, дебет, кредит ) ВСЕ - до полной картины не хватает еще плана счетов для деления л/с на типы(активный, пасивный и т.д.) Зачем изобретать велосипед? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 19:16 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
funikovyuri Вообще-то все давно придумано - всегда есть лицевые счета - как объекты учета, документы и соответсвующие им проводки Следуя твоей логике, то стоит ездить на фордах 1 модели, которые выпускались в начале прошлого века :) Зачем изобретать? Мне приходилось сталкиваться со многими бухгалтерскими пакетами, как с "коробочными" (яркий пример 1С), так и с самописьками. Практически везде одно и тоже: превалирование бухгалтерии над базой данных. При этом не нормальных бухгалтеров а, скорее, счетоводов, которые заучили операции, журналы etc. При этом практически любая бухсистема плохо стыкуется с производством. А ведь большинство данных в бухгалтерию поступает именно из производства. Вот я и попытался в свое время увязать (точнее объединить) производственный и бухгалтерский документооборот в единую систему. И от него плясать. Если мы имеем все документы (а в основе любого учета лежат именно документы) то мы легко привязывем к ним проводки и получаем, фактически, бухгалтерию. Это одна сторона документооборота. Этот же документооборот мы используем для производственного учета (он отличается от бухгалтерского). Это второй вектор использования документооборота. Сюда можно привязать логистику, маркетинг и прочие службы. За счет того, что документы вводятся единожды, в месте их формирования, бухгалтерия получает кучу операторов, что положительно сказывается на оперативности учета :) Фактически, любой учетный документ состоит из двух частей: описательной и табличной. В описательной обязательными атрибутами являются: уникальный идентификатор документа, дата его создания, подразделение (сторонняя организация), тип документа (определяет движение). В табличной части обязательны параметры: уникальный идентификатор строки, предмет перемещения (товар, сырье, деньги и т.п.), цена единицы, количество. Под такую схему можно подогнать любой учетный документ . Если с "шапкой" документа (описательная часть) все ясно, то с табличной частью возникают некоторые сложности. Как учитывать такие разные вщи как: здание, станки, готовая продукция, наличные деньги и прочее? По этой причине родилась еще одна идея общего справочника наименований (я его описывал в одной из веток), откуда и берутся идентификаторы для табличной части. Это, собственно говоря, и может послужить ядром всей системы учета предприятия. При этом неважно чем занимается предприятие производством станков или торговлей презервативами :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 20:23 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Следуя твоей логике, то стоит ездить на фордах 1 модели, которые выпускались в начале прошлого века :) Нет, следуя моей логике – лучше форд 1 модели – чем самодельный самокат... Практически везде одно и тоже: превалирование бухгалтерии над базой данных. В том что я предложил этой проблемы нет. Я занимался проектированием/консалтнгом АБС так что мои знания – это банковская бухгалтерия. То что я предложил – это патерн бухгалтеского учета – и ничего больше. Т.е. склад, учет ОС, а тем более документооборот – это другие системы (хотя и тесно связанные) – все они решают разные задачи – и профессионализм здесь заключается в умении не смешивать их. Например когда мы проектировали модуль учет основных средств внутри нашей АБС – мы не встретили никаких проблем интеграции этих подсистем – каждая выполняла свою задачу – и не мешала остальным. Если интересно я могу приводить конкретные примеры с анализом вариантов использования и диаграммами классов на UML. Весь фокус заключается в том что задачи бухгалтерии и учета ОС – это разные задачи, точнее ОС – это не только бухгалтерия – и незачем пытатся обеспечить в первой функциональность второй. Я не занимался складом и логистикой – но думаю их задачи –это тоже не только бух. Учет. Далее по порядку: Если мы имеем все документы (а в основе любого учета лежат именно документы) то мы легко привязывем к ним проводки и получаем, фактически, бухгалтерию. Я уже написал – основа учета – это лицевой счет. Т.е. ТО ЧТО УЧИТЫВАЕТСЯ. Из чего складывается бухгалтерия я тоже привел – это система ( л/с, план счетов, документы, проводки ) Это одна сторона документооборота. Вот она, проблема про которую я говорю – каша из понятий. Бухгалтерия – это не система документооборота. Что такое система документооборота может посмотреть у Blaha, Premerlani, Fowler, Hay, Silverston, Inmon, Graziano – это парни, занимавшиеся разработкой аналитических patterns для различных предметных областей. Под такую схему можно подогнать любой учетный документ. Бухгалтеский документ – это информация о перемещении между л/c. Для него характерны две основные операции провести/сторнировать – все. Не надо пытаться все что в жизни называется документом считать бухгалтеским! Например акт ввода в эксплоотацию – это совсем другой документ – ему могут соотвествовать бухгалтерские документы – но не проводки! Как учитывать такие разные вщи как: здание, станки, готовая продукция, наличные деньги и прочее? Так и учитывать – в штуках на л/с! А справочник наименований – это не бухгалтерия – это уже что-то другое ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2003, 22:17 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2 funikovyuri Я не буду приводить цитаты и выдержки из ьвоего поста, желающие могут прочитать сами. Но поверь мне (с банковской бухгалтерией я сталкивался), в тебе примат бухгалтера над базистом. Банковская бухгалтерия и производственная - две большие разницы. Начиная с плана счетов и кончая отчетностью. Как по форме так и по содержанию. Производственного учета в банке нет вообще . Банк считает деньги, и только деньги. В производстве считают детали, штуки, тонны etc. По поводу документооборота. Может, конечно, я применил неправильный термин, но не в этом суть. Назовем это системой учета производственно-хозяйственной документации :) Как ты примешь что либо (на твой любимый л/с :) без составления документа? Как без документа ты спишешь что либо с л/с? По желанию левой ноги? Вопросы, конечно, риторические, но они отражают суть моей идеи - первичен документ. Затем мы с этим документом делаем что хотим: бухгалтерия привязывает к строкам проводку(и) по счетам (пожалуйста - вот тебе учет по счетам), склад списывает материалы (товары) с карточки (в производстве косные люди работают, к картотеке привыкли :) и т.п. Основа любого учета документ. Учет без документов - уголовно наказуемое деяние :) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2003, 08:52 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
Но поверь мне (с банковской бухгалтерией я сталкивался), в тебе примат бухгалтера над базистом. Круто, никогда не замечал Интересно из чего такой вывод? Из того что слышал про дебит и кредит??? Банковская бухгалтерия и производственная - две большие разницы. Никто и не спорит что они отличаются. К тому же я "производственной" не занимался. Банк считает деньги, и только деньги. В производстве считают детали, штуки, тонны etc. Это неправда. Банк чситает все Как ты примешь что либо (на твой любимый л/с :) без составления документа? Интересно, а как составить документ без л/c? Я привел схему бух. учета - там есть документы - так в чем ты меня упрекаешь? Да я поставил л/с на первое место - так как именно л/c является объектом учета - но это не принципиально. Во всяком случае я никаких выводов из твоей посылки не сделал - т.е. это просто слова Смотри - есть мемориальный ордер - это бухгалтерский/платежный документа - в соответсвии с ним формируются проводки отражающие движение между л/c. А вот складская карточка - это что-то другое (я по крайней мере так думаю). Да и вообще движение по складу - это не только движение между л/c ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2003, 09:53 |
|
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
|
|||
---|---|---|---|
#18+
2Varan: Структура следующая (кратко): Таблица, где хранятся заголовки документов DOCUMENTS: DOC_ID - PK DOC_GUID - GUID DOC_NO - номер док-та DOC_DATE - дата док-та DOC_NAME - наимнование док-та DOC_SUM - сумма док-та FRM_ID - ID формы первичного документа и т.д. Таблица, где хранится содержимое документа (фактически все движение) JOURNAL: J_ID - PK DOC_ID - ID док-та J_TR_NO - номер проводки J_LN_NO - номер строки в проводке ACC_DB - дебет счета ACC_CR - кредит счета J_AG1 - корреспондент, проходящий по дебету J_AG2 - корреспондент, проходящий по кредиту J_SUM - сумма по строке проводки J_QTY - кол-во по строке проводки JF_QTY - производное кол-во по строке проводки J_ENT - объект учета (в данном случае объект хранения) J_UN - единица измерения JF_UN - производная единица измерения SER_ID - ID партии объекта учета и т.д. Таблица с дополнительной аналитикой к проводке JRN_MISC: J_ID - ID проводки MSC_ID - ID аналитики и т.д. Справочник объектов учета ENTITIES: ENT_ID - PK ENT_GUID - GUID ENT_NAME - наименование UN_ID - единица измерения и т.д. Произвольные параметры объектов учета ENT_PARAMS: ENT_ID - ID объекта учета PRM_ID - ID параметра PRM_CY - значение параметра (денежные тип) и т.д. Справочник дополнительной аналитики MISC: MSC_ID - PK MSC_GUID - GUID MSC_NO - номер аналитики MSC_NAME - наименование Все сущности (счета, кор-ты, объекты учета, аналитика и т.д.) имеют древовидную структуру (если интересно - кину). Все основано на первичном документе, он является основой. Данная схема позволяет паралельно вести бухгалтерский и оперативный учет. В данной реализации у нас сделано следующим образом: в первой проводке отражается информация, необходимая для бух. учета (партии, счета, кор-ты), во второй проводке - оперативная информация (партии, ячейки хранения). Это сделано по причине того, что в бухгалтерии движение по ячейкам хранения не нужно. Возможно, что и по партиям тоже (к сожалению, на Украине для налоговой инспекции вести партионный учет обязательно). В бухгалтерии партии, по большому счету, виртуальные и не имеют ничего общего с реальными партиями на складе. Реальные партии склада учитываются в оперативном учете. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2003, 10:53 |
|
|
start [/forum/topic.php?fid=32&fpage=176&tid=1546788]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
74ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 240ms |
total: | 432ms |
0 / 0 |