powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
59 сообщений из 59, показаны все 3 страниц
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32267770
DrBeer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 all: Собственно что нужнО :
Задумали у нас на предприятии новое направление, под него решил начальник построить склад с кучей стилажей в каждом из которых туева хуча ячеек. И чтобы определенный товар приходовался/хранился/отпускался только на/в определенной ячейке. Всебы ничего, но, как всегда предчуствуя что он гаденыш чегото не додумал, задал вопрос : а может ли быть ситуация когда в 1 ячейке будет не 1 вид товарной позиции а 2,3, или Х, хотя решили что Х это много и ограничились Y :) При всем при этом он имеет желание чтобы вёлся учет движения в ячейках (т.е. на складской накладной было расписана позиция товара в виде ячейка а - 27 шт, ячейка с 63 шт и т.д. и т.п.) и потом можно было посмотреть кто и когда и сколько чего совал в указанную ячейку, ну и тому подобные фатальные идеи.
Еслиб все ограничилось жесткой связкой - 1 товар - фиксированный набор ячеек и 1 ячейка - 1 товар - я бы и не кряхтел про это, но ситуация немного всовсем стала плохая :) Нечто подобное есть у фирм торгующих автозапчастями (человеки из таких фирм - весьма интересен ваш опыт)
Кто с таким сталкивался ? Кто как решал ? Буду рад услышать любые идеи, советы, соболезнования :) Если это принципиально :
платформа - сейчас WinNT4+IB5.6 будет FreeBSD+Firebird 1 or 1.5 если к тому времени вылезет, среда разработки Delphi.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32267778
Фотография _ChaiNik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С первого взгляда, особых проблем реализации не видно. Просто дополнительная детализация, по аналогии со множеством складов фирмы.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32267789
DrBeer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 _ChaiNik:" С первого взгляда, особых проблем реализации не видно. Просто дополнительная детализация, по аналогии со множеством складов фирмы. "
Это да - сам понимаю что это не более чем склад в ячейке, но такая детализация угиммораивает учет, и усложняет мне жысть - а это не есть хорошо Может есть какието другие варианты ?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32267807
Фотография tygra
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну у нас работает, уж сколько времени - все нормально.
Товар приходуется на склад - как обычно.
Но при этом еще есть список ячеек, куда это нужно положить - ячейки привязаны к складу, товары привязываются к ячейкам - туды их и кладут люди. Нет проблем.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32267855
DrBeer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 tygra:"Товар приходуется на склад - как обычно.
Но при этом еще есть список ячеек, куда это нужно положить - ячейки привязаны к складу, товары привязываются к ячейкам - туды их и кладут люди. Нет проблем." Блин...обломали весь настрой - прийдется идти и работать над собой и своей задачей
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32272602
Фотография Varan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интресно было б сравнить варианты структуры под такой прикольный склад.
И еще: я тут в одной книжке прочел, что систему БД лучше проектировать, начиная не со схемы РБД, а с "концептуальной модели". Интересно было бы услышать мнение опытных людей, насколько оправдано использование этих "концептуальных моделей" при проектировании, и, если оправдано, привести вариант "концептуальной модели" под упомянутую задачу.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32298271
Фотография Varan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня "родилась" такая структура, не знаю, насколько это правильно:
1. Товары (Id товара, и.т.п)
2. Склады (ячейки)(Id склада, и.т.п)
3. Движения товара
(Id движения, FK товара, FK from (откуда), FK out (Куда), сколько, дата)
4. Текущее состояние (ID, FK товара, FK склада, количество)
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32298424
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я бы основал такую систему на иерархических структурах. Примерно так:

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. Есть вопросы - задавайте.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32298621
Фотография Владимир П.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Приход товара - положительное число, расход - отрицательное

Нехорошо. Лучше иметь два поля: откуда уходит и куда приходит товар.
Если приход, то "свою" ячейку ставим в поле "Куда"; если расход -- то "Откуда". Каждое из этих полей ссылается на, например, номер договора (отслеживаем отношения с поставщиками/заказчиками) или номер ячейки склада (отслеживаем перемещения внутри склада, между складами, цехами и проч.).
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32298667
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Владимир П.

> Приход товара - положительное число, расход - отрицательное

Нехорошо. Лучше иметь два поля: откуда уходит и куда приходит товар.
Если приход, то "свою" ячейку ставим в поле "Куда"; если расход -- то "Откуда". Каждое из этих полей ссылается на, например, номер договора (отслеживаем отношения с поставщиками/заказчиками) или номер ячейки склада (отслеживаем перемещения внутри склада, между складами, цехами и проч.).

Не люблю поля со значением NULL , это не есть хорошо. Каждое поле в любой ячейке должно содержать информацию. Это раз. Второе. Информация о приходе и расходе заносится одной процедурой (убираем лишний код). Номер договора и прочая лабуда об операции содержится в документе (Operation_ID), нас она мало интересует, в данном случае. Документооборот - отдельная тема.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32299302
VKomarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Все правильно, но не до конца продумано.
Знак значения в поле количество не отражает тип операции.
С минусом может быть любой расход (брак, списание, продажа и т.п.)
Лучше добавить еще поле, тип операции. А в справочнике типов операций
указывать тип влияния на остаток (-1,0,1 - уменьшает/не изменяет/увеличивает).
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32299341
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 VKomarov

Для учета без разницы причины движения. Важен вектор (приход или расход). Причины отражаются в документах (накладная, акт списания, приходный ордер etc.) А лишнии поля плодить не стоит, информацию нужно хранить компактно.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32299624
VKomarov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Jinn
Для учета и последующей аналитики как раз важны причины движения.
Если отражать причину движения в документах, то указывать знак операции (вектор)
нет необходимости вовсе. Всегда можно знать как влияет документ на остаток товара.
Использовать число со знаком в поле значения - есть плохой тон и типичная ошибка
программирования. На первый взгляд это облегчает проектирование, однако потом
затрудняет дальнейшую разработку. Особенно это становится заметно, когда проект
перерастает только складской учет и требует дополнительной аналитики.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32299726
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
VKomarov

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

Ну вот, мы и подошли к аналитике :) На самом деле, складской учет всего лишь часть бухучета. Эту часть я просто грубо выдрал из предложенной мною однажды системы документооборота (не только бухгалтерия, но и прозводство в целом) и адаптировал под поставленную задачу (учет движения на складе). В нормальных условиях направление движения задавалось именно типом документа . В данном случае я сознательно отказался от этого, поскольку вопрос стоял именно о движении на складе, и в данном случае трудозатраты на разработку будут несколько меньше, чем при разработке комплексной системы документооборота и бухучета.

А систему отвергли. Из за кажущейся сложности и отсутствия времени. Если интересно - можно обсудить.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32299885
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn

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

Если некий товар передается, скажем, с фирмы на другую фирму. Это у Вас с минусом будет или с плюсом?
А если фирма своя же?
А если товар при этом не покидает пределов склада? Тогда движения, как бы и нет?

IMHO, при таком подходе (плюс-минус), трудозатраты будут значительно больше при малейшем изменении ТЗ в сторону универсальности. Например, одновременно вести два склада, физически находящихся в одном помещении.

>На самом деле, складской учет всего лишь часть бухучета.

А вот тут, категорически солидарен. Более того, рискну заметить, что при нормальной постановке бухучета, от складского учета, как сущности, можно отказаться вовсе. ;-)
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32299981
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некто

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

Если некий товар передается, скажем, с фирмы на другую фирму. Это у Вас с минусом будет или с плюсом?
А если фирма своя же?
А если товар при этом не покидает пределов склада? Тогда движения, как бы и нет?

Для склада без разницы куда уходит товар (продукция) в цех, другому собственнику или на другой склад. Запись будет иметь знак минус. Этот товар со склада "ушел". А если принимать во внимание то, что у нас учет ведется вплоть до места хранения (ячейка) то мы можем перекладывать товар из одной ячейки в другую. Например - складывение однотипного товара из нескольких ячеек в одну. В этом случае мы отобразим расход по этим ячейкам (знак минус) и приход в ячейку хранения (знак плюс). Все это будет отображено в одном документе (Operation_ID). Надеюсь здесь стало понятней? :)

IMHO, при таком подходе (плюс-минус), трудозатраты будут значительно больше при малейшем изменении ТЗ в сторону универсальности. Например, одновременно вести два склада, физически находящихся в одном помещении.

Особых проблем не будет. Просто функции складского учета плавно перетекут в систему бухучета, в материальную группу.

>На самом деле, складской учет всего лишь часть бухучета.

А вот тут, категорически солидарен. Более того, рискну заметить, что при нормальной постановке бухучета, от складского учета, как сущности, можно отказаться вовсе. ;-)

Это будет не сущьность, но модуль (или задача, как в постановке). Так же как и "касса", "зарплата" etc.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300287
У нас огромный продовольственный склад, принадлежащий нескольким юр. лицам. Ассортимент: готовая продукция, производимая несколькими юр. лицами, сырье для произ-ва, товар. Продукция, сырье и товар могут быть как собственными, так и принимаемыми на хранение. Схема реализована согласно принципов бухгалтерского учета. Ячейка выступает аналитическим показателем проводки. Отслеживаются партии объектов хранения, сроки хранения, заполненность ячеек, доступность объектов для выгрузки, возможность загрузки определенного объекта в определенную ячейку. Существует несколько типов операций: приход, расход, возврат, перемещение, инвентаризация, трансформация (разборка и сборка объектов хранение, например разбока палеты на ящики).
Все это крутится на MS Sql Server, большая часть бизнес логики делается хранимыми процедурами, остальное на MS VBScript.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300335
Фотография Varan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тишкин Алексей, схема сильно отличается от того, что предлагает Jinn?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300352
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Varan

Не стоит забывать что я привел упрощенную схему (фактически только ядро). Если ее расширить то можно завернуть и под такую, которую описал Тишкин Алексей , без особых напрягов.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300466
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще-то все давно придумано - всегда есть лицевые счета - как объекты учета, документы и соответсвующие им проводки (это как раз и есть ДВИЖЕНИЕ по счетам). При этом атрибуты проводки - это
( id_документа, сумма, дата, дебет, кредит )

ВСЕ - до полной картины не хватает еще плана счетов для деления л/с на типы(активный, пасивный и т.д.)

Зачем изобретать велосипед?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300527
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
funikovyuri

Вообще-то все давно придумано - всегда есть лицевые счета - как объекты учета, документы и соответсвующие им проводки

Следуя твоей логике, то стоит ездить на фордах 1 модели, которые выпускались в начале прошлого века :) Зачем изобретать? Мне приходилось сталкиваться со многими бухгалтерскими пакетами, как с "коробочными" (яркий пример 1С), так и с самописьками. Практически везде одно и тоже: превалирование бухгалтерии над базой данных. При этом не нормальных бухгалтеров а, скорее, счетоводов, которые заучили операции, журналы etc. При этом практически любая бухсистема плохо стыкуется с производством. А ведь большинство данных в бухгалтерию поступает именно из производства. Вот я и попытался в свое время увязать (точнее объединить) производственный и бухгалтерский документооборот в единую систему. И от него плясать. Если мы имеем все документы (а в основе любого учета лежат именно документы) то мы легко привязывем к ним проводки и получаем, фактически, бухгалтерию. Это одна сторона документооборота. Этот же документооборот мы используем для производственного учета (он отличается от бухгалтерского). Это второй вектор использования документооборота. Сюда можно привязать логистику, маркетинг и прочие службы. За счет того, что документы вводятся единожды, в месте их формирования, бухгалтерия получает кучу операторов, что положительно сказывается на оперативности учета :)
Фактически, любой учетный документ состоит из двух частей: описательной и табличной. В описательной обязательными атрибутами являются: уникальный идентификатор документа, дата его создания, подразделение (сторонняя организация), тип документа (определяет движение). В табличной части обязательны параметры: уникальный идентификатор строки, предмет перемещения (товар, сырье, деньги и т.п.), цена единицы, количество. Под такую схему можно подогнать любой учетный документ . Если с "шапкой" документа (описательная часть) все ясно, то с табличной частью возникают некоторые сложности. Как учитывать такие разные вщи как: здание, станки, готовая продукция, наличные деньги и прочее? По этой причине родилась еще одна идея общего справочника наименований (я его описывал в одной из веток), откуда и берутся идентификаторы для табличной части. Это, собственно говоря, и может послужить ядром всей системы учета предприятия. При этом неважно чем занимается предприятие производством станков или торговлей презервативами :)
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300565
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Следуя твоей логике, то стоит ездить на фордах 1 модели, которые выпускались в начале прошлого века :)

Нет, следуя моей логике – лучше форд 1 модели – чем самодельный самокат...

Практически везде одно и тоже: превалирование бухгалтерии над базой данных.

В том что я предложил этой проблемы нет.

Я занимался проектированием/консалтнгом АБС так что мои знания – это банковская бухгалтерия. То что я предложил – это патерн бухгалтеского учета – и ничего больше. Т.е. склад, учет ОС, а тем более документооборот – это другие системы (хотя и тесно связанные) – все они решают разные задачи – и профессионализм здесь заключается в умении не смешивать их.
Например когда мы проектировали модуль учет основных средств внутри нашей АБС – мы не встретили никаких проблем интеграции этих подсистем – каждая выполняла свою задачу – и не мешала остальным. Если интересно я могу приводить конкретные примеры с анализом вариантов использования и диаграммами классов на UML. Весь фокус заключается в том что задачи бухгалтерии и учета ОС – это разные задачи, точнее ОС – это не только бухгалтерия – и незачем пытатся обеспечить в первой функциональность второй. Я не занимался складом и логистикой – но думаю их задачи –это тоже не только бух. Учет.

Далее по порядку:

Если мы имеем все документы (а в основе любого учета лежат именно документы) то мы легко привязывем к ним проводки и получаем, фактически, бухгалтерию.

Я уже написал – основа учета – это лицевой счет. Т.е. ТО ЧТО УЧИТЫВАЕТСЯ. Из чего складывается бухгалтерия я тоже привел – это система ( л/с, план счетов, документы, проводки )

Это одна сторона документооборота.

Вот она, проблема про которую я говорю – каша из понятий. Бухгалтерия – это не система документооборота. Что такое система документооборота может посмотреть у Blaha, Premerlani, Fowler, Hay, Silverston, Inmon, Graziano – это парни, занимавшиеся разработкой аналитических patterns для различных предметных областей.

Под такую схему можно подогнать любой учетный документ.

Бухгалтеский документ – это информация о перемещении между л/c. Для него характерны две основные операции провести/сторнировать – все. Не надо пытаться все что в жизни называется документом считать бухгалтеским! Например акт ввода в эксплоотацию – это совсем другой документ – ему могут соотвествовать бухгалтерские документы – но не проводки!

Как учитывать такие разные вщи как: здание, станки, готовая продукция, наличные деньги и прочее?

Так и учитывать – в штуках на л/с!
А справочник наименований – это не бухгалтерия – это уже что-то другое
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300684
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 funikovyuri

Я не буду приводить цитаты и выдержки из ьвоего поста, желающие могут прочитать сами. Но поверь мне (с банковской бухгалтерией я сталкивался), в тебе примат бухгалтера над базистом. Банковская бухгалтерия и производственная - две большие разницы. Начиная с плана счетов и кончая отчетностью. Как по форме так и по содержанию. Производственного учета в банке нет вообще . Банк считает деньги, и только деньги. В производстве считают детали, штуки, тонны etc.
По поводу документооборота. Может, конечно, я применил неправильный термин, но не в этом суть. Назовем это системой учета производственно-хозяйственной документации :) Как ты примешь что либо (на твой любимый л/с :) без составления документа? Как без документа ты спишешь что либо с л/с? По желанию левой ноги? Вопросы, конечно, риторические, но они отражают суть моей идеи - первичен документ. Затем мы с этим документом делаем что хотим: бухгалтерия привязывает к строкам проводку(и) по счетам (пожалуйста - вот тебе учет по счетам), склад списывает материалы (товары) с карточки (в производстве косные люди работают, к картотеке привыкли :) и т.п. Основа любого учета документ. Учет без документов - уголовно наказуемое деяние :)
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300770
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но поверь мне (с банковской бухгалтерией я сталкивался), в тебе примат бухгалтера над базистом.

Круто, никогда не замечал Интересно из чего такой вывод? Из того что слышал про дебит и кредит???

Банковская бухгалтерия и производственная - две большие разницы.

Никто и не спорит что они отличаются. К тому же я "производственной" не занимался.

Банк считает деньги, и только деньги. В производстве считают детали, штуки, тонны etc.

Это неправда. Банк чситает все

Как ты примешь что либо (на твой любимый л/с :) без составления документа?
Интересно, а как составить документ без л/c? Я привел схему бух. учета - там есть документы - так в чем ты меня упрекаешь? Да я поставил л/с на первое место - так как именно л/c является объектом учета - но это не принципиально. Во всяком случае я никаких выводов из твоей посылки не сделал - т.е. это просто слова

Смотри - есть мемориальный ордер - это бухгалтерский/платежный документа - в соответсвии с ним формируются проводки отражающие движение между л/c. А вот складская карточка - это что-то другое (я по крайней мере так думаю). Да и вообще движение по складу - это не только движение между л/c
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32300959
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 - наименование

Все сущности (счета, кор-ты, объекты учета, аналитика и т.д.) имеют древовидную структуру (если интересно - кину).

Все основано на первичном документе, он является основой.
Данная схема позволяет паралельно вести бухгалтерский и оперативный учет. В данной реализации у нас сделано следующим образом: в первой проводке отражается информация, необходимая для бух. учета (партии, счета, кор-ты), во второй проводке - оперативная информация (партии, ячейки хранения).
Это сделано по причине того, что в бухгалтерии движение по ячейкам хранения не нужно. Возможно, что и по партиям тоже (к сожалению, на Украине для налоговой инспекции вести партионный учет обязательно). В бухгалтерии партии, по большому счету, виртуальные и не имеют ничего общего с реальными партиями на складе. Реальные партии склада учитываются в оперативном учете.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301114
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
funikovyuri

Но поверь мне (с банковской бухгалтерией я сталкивался), в тебе примат бухгалтера над базистом.
Круто, никогда не замечал Интересно из чего такой вывод? Из того что слышал про дебит и кредит???

Нет. Это всего лишь терминология (знание которой очень даже хорошо для работы). Мне и самому, в свое время, пришлось закончить курсы бухгалтеров, чтобы разговаривать с ними на одном языке :) Просто ты представляешь базу данных в терминах банковской системы а не наоборот.

Банк считает деньги, и только деньги. В производстве считают детали, штуки, тонны etc.
Это неправда. Банк чситает все

Нет. Банк не выпускает трактора и не поьребляет глину. В банк входят деньги и выходят деньги. Деньги - сырье и продукция банка. Это я в терминах производства :) По этой причине и учет там своеобразный, отличный от производственного.

Как ты примешь что либо (на твой любимый л/с :) без составления документа?
Интересно, а как составить документ без л/c? Я привел схему бух. учета - там есть документы - так в чем ты меня упрекаешь? Да я поставил л/с на первое место - так как именно л/c является объектом учета - но это не принципиально. Во всяком случае я никаких выводов из твоей посылки не сделал - т.е. это просто слова

Я тебя ни в чем не упрекаю :) Но лицевой счет - не есть объект учета. Объект учета - деньги, а лицевой счет всего лишь отражает их положение (чем не ячейка склада? :), проводки отображают движение. В первую очередь всегда создается документ, а затем он уже разносится по счетам. Хороший пример - платежное поручение. Для банка - документ, объект учета. Для производственной бухгалтерии нет. Там проводки делают в соответствии с выпиской банка (итоговый документ). Обрати внимание - оба документа создаются без привязки к лицевым счетам бухгалтерий.

Смотри - есть мемориальный ордер - это бухгалтерский/платежный документа - в соответсвии с ним формируются проводки отражающие движение между л/c.

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

Фактически, то что я нарисовал, есть ни что иное, как отображение хозяйственных операций в базе данных. При этом я постарался минимизировать количество оперативной информации, используемой для учета (производственного, бухгалтерского etc.) Остальная информация привязывется к этому учету и хранится в специфичных таблицах, используемых соответствующими модулями (частями системы).
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301388
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Просто ты представляешь базу данных в терминах банковской системы а не наоборот.

С чего ты это взял? Как это вообще определяется (вот сижу теперь и думаю - с какой точки зрения я себе это все представляю)?

Нет. Банк не выпускает трактора и не поьребляет глину.
НО в банке есть учет ОС и МБП (и даже "виртуальный" склад для ОС) так вот его мы проектировали уже имея спроектированную бухгалтерию - и каждая система выполняла свою задачу.

Мы с тобой видно друг друга не поняли. Само сабой объект учета деньги - а л/c - это место хранения. Далее проводки конечно же формируются по бухгалтерским документам. Которые(документы) в свою очередь определяют вовлеченные л/с!
Платежное поручение - это как раз бухгалтерский документ - привязанный к л/с

В производственной бухгалтерии одна хозяйственная операция может быть отображена бухгалтерией в нескольких проводках.
И не только в производственной - это правильно.

Что ты называешь оперативной информацией?

P.S. главное это взаимопонимание мы говорим об очень похожих вещах и доказываем по сути одно и тоже
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301439
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn
>А вот тут, категорически солидарен. Более того, рискну заметить, что при нормальной постановке бухучета, от складского учета, как сущности, можно отказаться вовсе. ;-)

Это будет не сущьность, но модуль (или задача, как в постановке). Так же как и "касса", "зарплата" etc.


Это вопрос терминологии. Пусть будет модуль. :-)

>первичен документ.

1000% согласен. Непонятно только, какая концептуальная разница тогда между документооборотом в банке и на производстве. Как по мне, так никакой.

>Затем мы с этим документом делаем что хотим: бухгалтерия привязывает к строкам проводку(и) по счетам (пожалуйста - вот тебе учет по счетам), склад списывает материалы (товары) с карточки (в производстве косные люди работают, к картотеке привыкли :) и т.п.

А вот здесь вопросик, а на хрена это списание с карточки, если при правильном построении бухучета любую карточку, в том числе ту к которой они так привыкли мы спокойно получим из данных бухучета? Правильно ли я понял, что Вы параллельно предлагаете вести учет на складе и в бухгалтерии (вопросы реального - официального учета предлагаю пока опустить)?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301493
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Тишкин Алексей

Не затруднит ли Вас, продемонстрировать такую, например операцию ( точнее 3 :-) ) в Вашем JOURNAL.
Приход на склад: Пиво "Славутич" 10 * 1,5 грн.
Приход на склад: Пиво "Славутич" 10 * 2,0 грн.
Расход со склада: Пиво "Славутич" 15 * 2,5 грн. (лучше реализация, но можно и просто списание )

Мне очень интересно, как это будет выглядеть в Вашей структуре:
Код: 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.
declare @journal table ( j_id int primary key , 
	doc_id int ,  -- id док--та 
 
	j_tr_no int ,  -- номер проводки 
 
	j_ln_no int  ,  -- номер строки в проводке 
 
	acc_db varchar ,  -- дебет счета 
 
	acc_cr varchar ,  -- кредит счета 
 
	j_ag1 int ,  -- корреспондент, проходящий по дебету 
 
	j_ag2 int ,  -- корреспондент, проходящий по кредиту 
 
	j_sum decimal (  19  ,  2  ) ,  -- сумма по строке проводки 
 
	j_qty decimal (  19  ,  2  ) ,  -- кол--во по строке проводки 
 
	jf_qty decimal (  19  ,  2  ) ,  -- производное кол--во по строке проводки 
 
	j_ent int ,  -- объект учета (в данном случае объект хранения) 
 
	j_un int ,  -- единица измерения 
 
	jf_un int ,  -- производная единица измерения 
 
	ser_id int  -- id партии объекта учета 
 
	) 


Вам только insert добавить :-). И если можно, какие заполняет оператор, а какие расчитываются?

Если совсем будет не лень, хотелось бы видеть отражение в этом журнале простой операции покупки Тишкиным валюты в ближайшем обменнике :-). Типа мы учет личных финансов ведем :-).

Я безо всякой иронии. Правда интересно.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301578
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
funikovyuri

... вот сижу теперь и думаю - с какой точки зрения я себе это все представляю ...

Хорошее занятие :) Я тоже в свое время озадачился этим вопросом. После его решения все стало решаться легко и просто. Хранить нужно данные, а не "лицевые счета" или "станки" ;)

Мы с тобой видно друг друга не поняли. Само сабой объект учета деньги - а л/c - это место хранения. Далее проводки конечно же формируются по бухгалтерским документам. Которые(документы) в свою очередь определяют вовлеченные л/с!
Платежное поручение - это как раз бухгалтерский документ - привязанный к л/с

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

Что ты называешь оперативной информацией?

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

Но это вопросы терминологии.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301602
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некто

>Затем мы с этим документом делаем что хотим: бухгалтерия привязывает к строкам проводку(и) по счетам (пожалуйста - вот тебе учет по счетам), склад списывает материалы (товары) с карточки (в производстве косные люди работают, к картотеке привыкли :) и т.п.

А вот здесь вопросик, а на хрена это списание с карточки, если при правильном построении бухучета любую карточку, в том числе ту к которой они так привыкли мы спокойно получим из данных бухучета? Правильно ли я понял, что Вы параллельно предлагаете вести учет на складе и в бухгалтерии (вопросы реального - официального учета предлагаю пока опустить)?

Правильно понял. Именно так и должно быть. В момент формирования документа (отпуск со складе) к строке табличной части документа привязывается номер карточки (документ формирует склад). Все.
Именно эта идея и заложена: данные вводятся один раз, используются многими, не плодятся дубли :)
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301645
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Именно эта идея и заложена: данные вводятся один раз, используются многими, не плодятся дубли :)

Это очень радостно и целиком поддерживаю.
Но вопрос повторю и даже расширю. Предполагаете ли Вы для этих "карточных" расчетов отдельный набор процедур ( view, функций и т.п.)? Т.е этот "карточный" учет ведется параллельно бухгалтерскому или нет? Если да, то какой из них является первичным?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301822
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некто

>Именно эта идея и заложена: данные вводятся один раз, используются многими, не плодятся дубли :)

Это очень радостно и целиком поддерживаю.
Но вопрос повторю и даже расширю. Предполагаете ли Вы для этих "карточных" расчетов отдельный набор процедур ( view, функций и т.п.)? Т.е этот "карточный" учет ведется параллельно бухгалтерскому или нет? Если да, то какой из них является первичным?

Никакого паралельного учета нет. Мы имеем хозяйственную операцию. Все данные в эти таблицы записываются одной процедурой, хотя вызываться она может из разных мест. Складской учет - отдельная подсистема. Но все данные по хозяйственным операциям учитываются в общей системе.
Бухгалтерия - это отдельная песня :) Там учет идет по другому принципу. Как я уже раньше говорил, одна хозяйственная операция может быть описана несколькими проводками, поэтому придется создать детализацию для хозяйственных операций в разрезе бухгалтерии, поскольку бухгалтерия рааботает только с суммами . Если Вы обратили внимание, то в табличной части документа понятие сумма отсутствует. Все бухгалтерские проводки будут привязаны к хозяйственным операциям по идентификатору строки табличной части. Естественно в других модулях (подсистемах) потребуются свои, специфичные процедуры и представления, отчеты и прочее, но основные функции управления едины для всех модулей.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301904
Фотография Varan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jinn, "Не стоит забывать что я привел упрощенную схему (фактически только ядро). "
Конечно, я это понимаю и уважаю людей, которые, щадя собеседников, приводят только ту часть информации, которая связана с предметом разговора.
Тишкин Алексей, Спасибо, будет о чем поразмыслить на досуге, сравнить подходы.
funikovyuri "Если интересно я могу приводить конкретные примеры с анализом вариантов использования и диаграммами классов на UML"
К сожалению, для меня использование этого UML остается лишь несбыточной мечтой. Поэтому было бы очень интересно увидеть, как применяется этот инструмент к реальным задачам. В книгах все примеры, как мне кажется, весьма далеки от реальности.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301926
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn
>Никакого паралельного учета нет... Складской учет - отдельная подсистема...
Бухгалтерия - это отдельная песня :) Там учет идет по другому принципу.


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

У Вас для бухгалтерии движение генерирует проводки (отдельные sp, наверное). А для склада - записи в карточках (другие sp ). В бухгалтерии - остаток по складу по какому-то конкретному товару или группе товаров, расчитанный из аналитик бухгалтерских проводок. На складе - тот же самый остаток, расчитанный с помощью карточек. Так? Если да, то зачем две подсистемы, если достаточно одной? Если будут расхождения в этих остатках, где искать концы?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32301972
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn

>поскольку бухгалтерия рааботает только с суммами

Для меня это новость. Правда. Я наверное очень давно учил бухучет. Все наверное изменилось с тех пор.

"На предприятиях учет товарно-материальных ценностей ведется одновременно и в натуральных, и в денежных показателях. Для этого служит количественно-суммовая форма....
Рассмотренные формы могут быть использованы и для построения других учетных регистров, например книг аналитического учета или вспомогательных учетных ведомостей"
(С) В.Г. Макаров. "Теория бухгалтерского учета", Москва, издательство "Финансы и статистика" 1990 г.

Да, действительно очень давно это было. Но тем не менее очень толковый учебник. Там и формы аналитических ведомостей с количественно-суммовыми показателями по объекту учета имеются и страшно сказать в них кроме количества, цены и суммы еще и специальные графы - дебет и кредит.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32302106
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некто

2 Jinn
>поскольку бухгалтерия рааботает только с суммами
Для меня это новость. Правда. Я наверное очень давно учил бухучет. Все наверное изменилось с тех пор.

:) Утрирую. Хотя я не встречал проводки: "Д11К70. Баран. 10 шт." :) В балансе тоже штуки не фигурируют. Все что есть на предприятии выражается в стоимостном выражении. Разве не так? Поэтому и упрощаю по поводу сумм.

(С) В.Г. Макаров. "Теория бухгалтерского учета", Москва, издательство "Финансы и статистика" 1990 г.

Правильные книжки читаем :)

Да, действительно очень давно это было. Но тем не менее очень толковый учебник. Там и формы аналитических ведомостей с количественно-суммовыми показателями по объекту учета имеются и страшно сказать в них кроме количества, цены и суммы еще и специальные графы - дебет и кредит.

Это необходимо, в основном, для "бумажной" работы, при создании интерфейса рабочего места бухгалтера, разработки отчетов. При разработке базы данных это необходимо учитывать, но зацикливаться на этом на первоначальном этапе не стоит. В моем предложении это учтено.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32302159
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn
>Утрирую. Хотя я не встречал проводки: "Д11К70. Баран. 10 шт.

>Это необходимо, в основном, для "бумажной" работы, при создании интерфейса рабочего места бухгалтера, разработки отчетов. При разработке базы данных это необходимо учитывать, но зацикливаться на этом на первоначальном этапе не стоит. В моем предложении это учтено.

Я кроме себя знаю еще минимум 9 баранов, которые встречали :-)
Пожалуй, что зря я ввязался в этот спор. Потому что, как почти все обсуждения по этим и похожим вопросам, сводятся к отстаиванию какого-то подхода (как правило гениального и своего) вместо попытки найти в этом подходе нелогичности и несоответствия.
Я ни сколько не пытался дезавуировать Ваш подход. А только позволил себе контруктивную, IMHO, критику.
Боюсь прийдет Тишкин Алексей и тоже на меня обидится. :-(

P.S. Как только Вы попытаетесь "зациклится" на необходимости "аналитических проводок" (объект, партия, количество по цене), Вы тут же задумаетесь над необходимостью вообще, того модуля, который называется "складской учет". IMHO разумеется.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32302222
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некто

2 Jinn
>Утрирую. Хотя я не встречал проводки: "Д11К70. Баран. 10 шт.
Я кроме себя знаю еще минимум 9 баранов, которые встречали :-)

Лихо. Ни разу не видел, не слышал, и не читал про проводки в кирпичах и баранах. Ссылочку дай :)

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

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

Я ни сколько не пытался дезавуировать Ваш подход. А только позволил себе контруктивную, IMHO, критику.

К сожалению критики пока не увидел. Был уход в сторону конкретизации. У кого что болит ...

P.S. Как только Вы попытаетесь "зациклится" на необходимости "аналитических проводок" (объект, партия, количество по цене), Вы тут же задумаетесь над необходимостью вообще, того модуля, который называется "складской учет". IMHO разумеется.

Я и говорю - конкретизация. Давайте подключим, тогда уж, экономистов (им себестоимость считать), логистиков (планировать запасы), технологов (менять технологию в зависимости от наличия материалов) да и многих других. Все "аналитические проводки" есть только отображение хозяйственных операций в бухгалтерских терминах. И не более. При этом они совершаются только после документального подтверждения хозоперации. Это уже обсуждалось (см. трейд с funikovyuri ).
А по поводу задуматься над ... Это и сподвигло к анализу движения информации на предприятии, способам ее обработки и т.п. Поставщиком информации на предприятии является производство (склады тоже производство). Остальные подразделения, в лучшем случае, только контролируют справочную информацию. Привяжи сценарий проводок к документу и генери их после ввода (подтверждения) документа и половину бухгалтерии можно выгонять :)
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32302280
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Jinn:
учет в штуках – это стандарт. На внебалансовых счетах может лежать что угодно – от 10 баранов – до 5 бланков векселей. Это основы

2Varan:Хорошо, пришлю – скажи куда
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32302595
2 Некто:

Во первых по поводу структуры: ACC_DB, ACC_CR имеют тип int, это ссылка на ID счетов из справочника (плана счетов); J_SUM, J_QTY, JF_QTY имеют тип money.

По поводу операций (упрощенно):

insert into DOCUMENTS (DOC_NO, DOC_DATE, DOC_NAME)
values ('1', '2003/10/23', 'Приход на склад')

insert into JOURNAL (DOC_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)
values ([ID док-та], 0, 0, [ID счета складского], [ID счета поставщиков], [ID склада], [ID поставщика], 15, 10, 0, [ID объекта Пиво "Славутич"], [ID ед. изм.], 0, [ID партии])

insert into JOURNAL (DOC_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)
values ([ID док-та], 0, 1, [ID счета складского], [ID счета поставщиков], [ID склада], [ID поставщика], 20, 10, 0, [ID объекта Пиво "Славутич"], [ID ед. изм.], 0, [ID партии])

insert into DOCUMENTS (DOC_NO, DOC_DATE, DOC_NAME)
values ('1', '2003/10/23', 'Расход со склада')

insert into JOURNAL (DOC_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)
values ([ID док-та], 0, 0, [ID счета покупателей], [ID 702], [ID покупателя], [ID склада], 37.5, 15, 0, [ID объекта Пиво "Славутич"], [ID ед. изм.], 0, [ID партии])

insert into JOURNAL (DOC_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)
values ([ID док-та], 1, 0, [ID 902], [ID счета складского], [ID покупателя], [ID склада], 15, 10, 0, [ID объекта Пиво "Славутич"], [ID ед. изм.], 0, [ID партии])

insert into JOURNAL (DOC_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)
values ([ID док-та], 1, 1, [ID 902], [ID счета складского], [ID покупателя], [ID склада], 10, 5, 0, [ID объекта Пиво "Славутич"], [ID ед. изм.], 0, [ID партии])

Это элементарные проводки, в системе к ним прибавляется еще несколько (НДС, фин результат, ТЗР и т.п.)

Оператор выбирает шаблон операции (шаблон определяет форму документа (приходная накл., расходная накл. и т.п.), кол-во проводок, счета в проводках, зависимость сумм проводок и т.п.), выбирает поставщика\покупателя, набирает перечень объектов учета, проставляет количество и цену (либо сумму). Цена может попадать автомачески из прайс-листа (справочника цен). Производная единица измерения проставляется при условии указания в свойствах объекта учета (соответственно рассчитывается количество в производной единице измерения). Партии проставляются автоматически (в случае прихода создаются, в случае расхода списываются). Речь о ячейках хранения не ведется.

По поводу валюты:
В системе имеется таблица JRN_CRC:
JC_KEY - PK,
J_ID - ссылка на ID проводки,
CRC_ID - ID валюты,
RT_ID - ID курса валюты,
JC_NO - номер валюты,
JC_SUM - сумма в валюте,
JC_PRICE - цена в валюте,
JC_RATE - значение курса.

INSERT по поводу валюты приводить нужно ?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32302622
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
funikovyuri

2Jinn:
учет в штуках – это стандарт.

Учет какой ? Складской или производственный - легко.

На внебалансовых счетах может лежать что угодно – от 10 баранов – до 5 бланков векселей. Это основы

Ну, по поводу основ. На счетах ничего не лежит . Счета применяются для учета . Учитывается в неких унииверсальных единицах. Таковой является вылюта учета (в России это рубль).
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32302874
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn\r
\r
>Лихо. Ни разу не видел, не слышал, и не читал про проводки в кирпичах и баранах. Ссылочку дай :) \r
\r
Я вроде бы цитату из учебника приводил. 8-).\r
Ну вот Вам ссылочка (не учебник, конечно, но тем не менее): /topic/1640\r
Там кстати и "подход к созданию модели данных учета" приведен. И по поводу способов хранения аналитических данных в бухгалтерском учете интересная дискуссия.\r
\r
>И цель - показать свой подход к созданию модели данных учета. Не бухгалтерского или производственного, а учета вообще. В производственном учете понятия "сумма" нет, там штуки (кг, т, м etc), в номенклатуре. Два этих типа учета антогонистичны по своей сути и в то же время у них есть общее - количество. \r
\r
Кажется я понял. У нас с Вами просто существенная разница в определениях. \r
Вы оперируете понятиями "производственного", "складского" и антогонистичного им бухгалтерского учета. Которые обрабатывают ( каждый по своему, предполагаю ) одни и те же первичные данные. И если по поводу хранения первичных данных я с Вами полностью согласен, всего остального, боюсь, я не в состоянии понять. \r
Дело в том, что само существование понятий "производственный учет" или даже "складской учет" для меня представляется сомнительным, при наличии нормально поставленного ( с подробными аналитиками ) бухгалтерского учета.\r
\r
2 Тишкин Алексей.\r
\r
Лень было нормальный скрипт на вставку данных написать? Так бы и сказали:"Лень мол мне".\r
Про покупку валюты нужно, только в нормальном виде, если не лень опять же.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32303031
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Тишкин Алексей
Код: 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.
declare @journal table ( j_id int identity ( 1 , 1 ) primary key  , 
	doc_id int ,  -- id док--та 
 
	j_tr_no int ,  -- номер проводки 
 
	j_ln_no int  ,  -- номер строки в проводке 
 
	acc_db varchar (  100  )  ,  -- дебет счета 
 
	acc_cr varchar (  100  ) ,  -- кредит счета 
 
	j_ag1 varchar (  100  )  ,  -- корреспондент, проходящий по дебету 
 
	j_ag2 varchar (  100  )  ,  -- корреспондент, проходящий по кредиту 
 
	j_sum decimal (  19  ,  2  ) ,  -- сумма по строке проводки 
 
	j_qty decimal (  19  ,  2  ) ,  -- кол--во по строке проводки 
 
	jf_qty decimal (  19  ,  2  ) ,  -- производное кол--во по строке проводки 
 
	j_ent varchar (  100  ) ,  -- объект учета (в данном случае объект хранения) 
 
	j_un varchar (  10  ) ,  -- единица измерения 
 
	jf_un int ,  -- производная единица измерения 
 
	ser_id varchar (  10  )   -- id партии объекта учета 
 
) 

insert into @journal (doc_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) 
	values (  1 ,  0 ,  0 , 'Товары на складе', 'Расчеты с поставщиками', 'Склад1', 'Пивзавод Славутич',  15 ,  10 ,  0 , 'Пиво Славутич', 'шт',  0 ,  1  ) 

insert into @journal (doc_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) 
	values (  1 ,  0 ,  1 , 'Товары на складе', 'Расчеты с поставщиками', 'Склад1', 'Пивзавод Славутич',  20 ,  10 ,  0 , 'Пиво Славутич', 'шт',  0 ,  2  ) 
insert into @journal (doc_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) 
	values (  2 ,  0 ,  0 , 'Расчеты с покупателями' , 'Доходы от реализации', 'Тишкин', 'Склад1',  37 . 5 ,  15 ,  0 , 'Пиво Славутич', 'шт',  0 , '???' ) 
insert into @journal (doc_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) 
	values (  2 ,  1 ,  0 , 'Себестоимость реализованных товаров' , 'Товары на складе', 'Тишкин', 'Склад1',  15 ,  10 ,  0 , 'Пиво Славутич', 'шт',  0 ,  1  ) 
insert into @journal (doc_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) 
	values (  2 ,  1 ,  0 , 'Себестоимость реализованных товаров' , 'Товары на складе', 'Тишкин', 'Склад1',  10 ,  5 ,  0 , 'Пиво Славутич', 'шт',  0 ,  2  ) 

select * from @journal


Если так, то очень и очень неплохо.
Типы данных я изменил для удобства.
Вопрос по существу. Партия в проводке 0 по документу 2 устанавливается или нет? Если нет, то как увидеть финансовый результат по конкретной партии?
Есть ли такая возможность?
Вопрос не по существу. Не Accent ли часом?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32303260
2 Некто:
Лень конечно, суть ведь понятна.
Партия в первой проводке второго документа не присваивается. Фин. результат в разрезе партий - вопрос неоднозначный. При необходимости можно сделать так, чтобы и в первой проводке была партия, в таком случае в первой проводке будет две строки.

> Вопрос не по существу. Не Accent ли часом?
Да, Акцент 6.0.

После ответа на вопрос не по существу есть смысл описывать операцию с валютой ? Могу дать ссылку где можно взять триальную версию (правда под DAO, но структуры у них практически одинаковые).
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32303371
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Тишкин Алексей

>После ответа на вопрос не по существу есть смысл описывать операцию с валютой ?

Поскольку Accent - нету смысла.

>Могу дать ссылку где можно взять триальную версию (правда под DAO, но структуры у них практически одинаковые).

Спасибо. И так знаком достаточно. :-)
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32303931
2 Некто:
Если ты знаком с Акцентом, какое твое мнение о нем ?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304332
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Некто

Кажется мне удалось пояснить свою идею :)

По поводу книги я уже говорил: правильная. Без ёрничанья и прочих усмешек.

Поповоду чета "в юаранах". Попробуйте представить акционерам или налоговикам баланс (годовой, квартальный etc) где основные средства указаны в штуках а остатки по кассе в тугриках :)

Производственный и бухгалтерский учет. Строить производственный учет на аналитике крайне нецелесообразно, поскольку у производственного учета несколько иные задачи. Да и оперативность бухучета ниже чем у производственного. Тем более следовать учитывать то, что часть данных вообще не войдет в бухучет, но необходим для полноценного производственного учета.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304398
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Тишкин Алексей

Среднего.
В Акценте первоначально заложена одна очень хорошая идея - хранение правил проведения отдельно от данных.

Все остальное много хуже.
Первичные данные, как таковые, не хранятся вообще. Т.е хранятся проводки на основе этих данных, но не непосредственно введенные данные. (Jinn бы плакал и я бы учавствовал ). Это, конечно, один из способов хранения, но чревато:
Потерей данных. Введена накладная. Одна строка табличной части не проведена (причин - масса). Мы ее навсегда потеряли.

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

Вы сами сказали, что в приведенном примере нельзя будет увидеть финансовый результат по каждой партии. Если я захочу это все-таки сделать, в оперативном учете, к примеру, боюсь, что просто добавить аналитику по партиям в плане счетов и произвести перепроведение документов будет не достаточно. Необходимо будет произвести какое то количество ритуальных действий, связанных с написанием кода ( насколько мне известно опять же ).

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

Не ясна необходимость использования для описания бизнес логики Accent Basic , особенно в версии SQL Server.

Я, наверное, могу продолжать (критиковать вообще проще, чем делать), а Вы можете опровергать. Но первый недостаток (хранение проводок, вместо первичных данных ) - наиглавнейший и неустранимый. Правда я не видел, последней версии, кажется 8 ( вроде на .NET написана).
Тем не менее - это внедряется и работает, насколько мне известно. И в любом случае - это много симпатичнее 1С.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304516
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn
>Поповоду чета "в юаранах". Попробуйте представить акционерам или налоговикам баланс (годовой, квартальный etc) где основные средства указаны в штуках а остатки по кассе в тугриках :)

Производственный и бухгалтерский учет. Строить производственный учет на аналитике крайне нецелесообразно, поскольку у производственного учета несколько иные задачи. Да и оперативность бухучета ниже чем у производственного. Тем более следовать учитывать то, что часть данных вообще не войдет в бухучет, но необходим для полноценного производственного учета.


Мне представляется, что наш с Вами спор - типичный пример использования неопределенных (или неоднозначно определенных терминов). Я не знаю, что такое "производственный" или "складской" учет. Определения не видел. Знаю учет финансовый (для акционеров и внешних инвесторов), оперативный (для внутреннего использования менеджментом), налоговый и их вариации ( тут простор для фантазии). Финансовый реальный ( черный ) и официальный, например. Оперативный по центрам ответственности или направлениям деятельности (можно даже с "внутренними" ценами и пр.). Все эти виды учета - бухгалтерские ( основанные на принципах двойной записи и баланса)

Учет в баранах, действительно не нужен акционерам, их аналитики не интересуют. Для них есть финансовый учет.
Для налоговой - есть налоговый учет, но он тоже бухгалтерский. Есть кстати примеры ( в учебниках западных авторов, в основном), когда одна и таже операция в налоговом учете отражается одним способом, а в финансовом (для акционеров и внешних инвесторов) совершенно иначе ( и это нормально).
Не бухгалтерский учет менее оперативен, нежели производственный. Иначе. Финансовый бухгалтерский учет менее оперативен, нежели оперативный бухгалтерский учет. И это, кстати, их еще одно главное отличие (кроме потребителей).
То что Вы называете "производственным" или "складским" учетом - я называю оперативным. Ключевое отличие в подходах - он тоже бухгалтерский по своей сути. Можно, наверное вести его не на бухгалтерских принципах. И ведут, и успешно (я и сам три различных склада написал). Только зачем? Нет такого вопроса на который нельзя было бы получить ответ из данных правильно поставленного оперативного бухгалтерского учета. Знаете - назовите. Готов признать свою неправоту.

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

P.S. Вполне допускаю, что вы напишите свой производственный учет и он будет вполне работоспособен и будет охватывать все необходимые аспекты. Т.е. будет лучше, гибче и проще, чем оперативный бухгалтерский с аналогичной функциональностью, построенный по учебнику. Тогда Ваше имя войдет в список теоретиков учета и покойный итальянский монах Лука Паччоли будет любоваться Вами с небес. Но может пару учебников с описанием принципов построения бухгалтерского учета ( в том числе оперативного, в том числе на производстве) все-таки прочтете? Они не такие нудные, особенно если подходить к ним с точки зрения, например директора (одновременно владельца) предприятия. Просто курсов IMHO, недостаточно.
P.P.S. Ну нагородил. Чувствую себя Репликантом. :)).
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304630
ban@accent6.com.ua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Некто
Я так понимаю, Вы из Киева. А можно телефончик. Уж больно хочется поговорить.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304644
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ban@accent6.com.ua

У меня аська в профиле, кажется. Там и договоримся, можно даже пива попить.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304772
olk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Некто:
нет это вы что то зациклились на бухучете :) хотите-те определений их у меня есть :)


РОССИЙСКАЯ ФЕДЕРАЦИЯ

ФЕДЕРАЛЬНЫЙ ЗАКОН

О БУХГАЛТЕРСКОМ УЧЕТЕ


Принят
Государственной Думой
23 февраля 1996 года

Одобрен
Советом Федерации
20 марта 1996 года

(в ред. Федеральных законов от 23.07.1998 N 123-ФЗ,
от 28.03.2002 N 32-ФЗ, от 31.12.2002 N 187-ФЗ,
от 31.12.2002 N 191-ФЗ, от 10.01.2003 N 8-ФЗ,
от 30.06.2003 N 86-ФЗ)
Глава I. ОБЩИЕ ПОЛОЖЕНИЯ


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

1. Бухгалтерский учет представляет собой упорядоченную систему сбора, регистрации и обобщения информации в денежном выражении об имуществе, обязательствах организаций и их движении путем сплошного, непрерывного и документального учета всех хозяйственных операций.
2. Объектами бухгалтерского учета являются имущество организаций, их обязательства и хозяйственные операции, осуществляемые организациями в процессе их деятельности.
3. Основными задачами бухгалтерского учета являются:
формирование полной и достоверной информации о деятельности организации и ее имущественном положении, необходимой внутренним пользователям бухгалтерской отчетности - руководителям, учредителям, участникам и собственникам имущества организации, а также внешним - инвесторам, кредиторам и другим пользователям бухгалтерской отчетности;
обеспечение информацией, необходимой внутренним и внешним пользователям бухгалтерской отчетности для контроля за соблюдением законодательства Российской Федерации при осуществлении организацией хозяйственных операций и их целесообразностью, наличием и движением имущества и обязательств, использованием материальных, трудовых и финансовых ресурсов в соответствии с утвержденными нормами, нормативами и сметами;
предотвращение отрицательных результатов хозяйственной деятельности организации и выявление внутрихозяйственных резервов обеспечения ее финансовой устойчивости.

из пункта 1. Т.е. исходя из определения учет в штуках не обязателен, или упрощая еще [руководителям, учредителям, участникам и собственникам имущества организации, а также внешним - инвесторам, кредиторам и другим пользователям бухгалтерской отчетности] оперативный учет как таковой не нужен ...
здесь под оперативным учетом я понимаю как раз учет хоз. деятельности предприятия - т.е. конкретно что дядя Ваня взял со склада 10 заготовок, и выточил из них восемб деталей, при этом две списал в утиль (а на самом деле как видно из акта службы безапасности стырил) ... :)

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

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

Кроме того имея всю первичку я могу получить бух.учет и в Российской нотации, и в GAAP и если надо по собственному плану счетов .... и в любой валюте ....

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

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

3. Основными задачами бухгалтерского учета являются:
формирование полной и достоверной информации о деятельности организации и ее имущественном положении
, необходимой внутренним пользователям бухгалтерской отчетности - руководителям, учредителям, участникам и собственникам имущества организации, а также внешним - инвесторам, кредиторам и другим пользователям бухгалтерской отчетности;
обеспечение информацией, необходимой внутренним и внешним пользователям бухгалтерской отчетности для контроля за соблюдением законодательства Российской Федерации при осуществлении организацией хозяйственных операций и их целесообразностью, наличием и движением имущества и обязательств,использованием материальных, трудовых и финансовых ресурсов в соответствии с утвержденными нормами, нормативами и сметами;
предотвращение отрицательных результатов хозяйственной деятельности организации и выявление внутрихозяйственных резервов обеспечения ее финансовой устойчивости.

Не вижу запрещения количественно-суммового учета. Вижу наоборот. Внутренним пользователям - с подробными аналитиками (оперативный учет).
Внешним - финансовый учет. Менее подробно (кстати, есть отчеты с количественными характеристиками и для внешних пользователей). Завтра приведу очередную цитату.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304862
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>из пункта 1. Т.е. исходя из определения учет в штуках не обязателен, или упрощая еще [руководителям, учредителям, участникам и собственникам имущества организации, а также внешним - инвесторам, кредиторам и другим пользователям бухгалтерской отчетности] оперативный учет как таковой не нужен ...

Боюсь, что есть "руководителям, учредителям, участникам и собственникам имущества организации", которые с Вами сильно не согласятся.

>здесь под оперативным учетом я понимаю как раз учет хоз. деятельности предприятия - т.е. конкретно что дядя Ваня взял со склада 10 заготовок, и выточил из них восемб деталей, при этом две списал в утиль (а на самом деле как видно из акта службы безапасности стырил) ... :)

А вот это вопрос относительной значимости информации (кстати, одна из центральных концепций бухгалтерского учета )
Для финансового учета эти факты могут быть признанными несущественными, а в оперативном ( кстати его еще часто называют управленческим, не знаю что правильнее ) очень даже могут отражаться. Особенно если заготовки из платины. :-)

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

т.е. можно вносить в базу все документы (вплоть до объяснительной почему тот-же дядя Ваня пришел на работу выпимшы (интересно как это отразить в бухучете :)), можно вносить информацию действительно необходимую для какого либо учета(ов).

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

>И я готов поспорить, что не любой оперативный учет (в моем понимании), можно и нужно отражать как бухгалтерский (т.е. требующий двойной записи),

Вопрос вкуса. Хотите, поспорим о вкусах.

>Кроме того имея всю первичку я могу получить бух.учет и в Российской нотации, и в GAAP и если надо по собственному плану счетов .... и в любой валюте ....

Если это удастся Вам. Вы станете очень богатым человеком, IMHO.
И это будет почти "идеальная" бухгалтерская программа, которую я так хочу видеть. И если Вы займетесь этим, вместо придумывания концепций "производственного" учета, это будет много полезнее. У меня пока не получается.

>Согласен что вы можете это расписать в "бухучет" но нафига мне нужен
дебет и кредит каких-либо счетов если мне надо знать сроки поставки,
сколько и каких палето-мест, сроки хранения и т.д


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

P.S. Это мое понимание предметной области и оно, само собой не претендует на истину в последней инстанции.
P.P.P.S. Репликантом быть охренительно тяжело :-(
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304897
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некто

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

На это есть хороший ответ. В бухгалтерии имеются только вторичные данные. Бухгалтерия занимается учетом . А все первичные данные бухгалтерия получает из производства. Представь себе аналитику по сотне тысяче деталей, причем важен этап производства, время поступления в обработку, местонахождение (цех, участок, бригада etc.) Производственники напрочь отвергают бухучет, он для них пустой звук. Да и для бухучета такая подробная аналитика ни к чему. А вот использовать производственную информацию, вместо ввода ее же в бухгалтерии, очень даже хорошо. Сокращает время обработки документов.

По твоему примеру. Бухгалтерия не разделяет партии одного и того же материала, сырья, полуфабрикатов (если они учитываются по одной карточке) , не имеет данных о качестве или иных характеристиках материалов.
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32304901
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Некто

Рекомендую на досуге ознакомиться с MRP/ERP/CRM Бухучетом там только слегка попахивает. Эти системы занимаются исключительно производством. Интересно - почему они построены не на системе бухучета?
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32305155
Некто
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Jinn

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

М-да. Я думал методы определения себестоимости по FIFO , LIFO, средневзвешенной, идентифицированной стоимости - это способы именно партионного учета. Я ошибался, видимо. 8-(

>Рекомендую на досуге ознакомиться с MRP/ERP/CRM Бухучетом там только слегка попахивает. Эти системы занимаются исключительно производством. Интересно - почему они построены не на системе бухучета?

MRP/ERP/CRM Бухучета нет и быть не может.
Любая система класса ERP включает в себя модуль финансового и управленческого учета. По определению. Если есть хоть одна без этого модуля - подскажите какая?

На счет CRM - Вы меня поймали, признаю. Проводки по каждому звонку клиента - наверное не нужны.
Хотя большую часть данных о взаимоотношении с клиентом можно ( и нужно ) получать из данных бухгалтерского учета ( финасового и управленческого ).

Как пойманный за руку, выскажу несколько более общую мысль по поводу необходимости и достаточности тех или иных модулей в системе управления (управления, а не учета) предприятием.
ERP система без модуля CMR - плохо, но не смертельно. Этого требования и в стандартах соответствия систем уровню ERP нет, кажется.
ERP система без модуля бухгалтерского учета - нахрен никому не нужная хрень. Обанкротиться можно, и очень быстро.

Возможно, Вы и правы, что модуль производства целиком в рамки бухучета засовывать смысла нет. Технологические вопросы к примеру. Но большую часть, в том числе и предложенный Вами пример с дядей Ваней, я бы без проблем засунул. Это проще, нежели отдельную логику для этих целей выдумывать. А то силов на технологические процессы не останется.

P.S. Меня больше именно автоматизация бухучета интересует. И финансового, и управленческого (оперативного). В том числе в системе из нескольких фирм, в том числе в нескольких планах счетов, в том числе с возможностью консолидации, межплановых проводок и т.п. Мне SAP R3 писать никак не возможно. Пупок развяжется. Мне бы от мыслей об 1С отдельно взятое предприятие освободить.
P.P.S. По моему мы развели тут обалденный флейм, к тому же мало кому интересный. Автор топика все равно уже склад дописывает. Скоро наверное и внедрить успеет. :-))
...
Рейтинг: 0 / 0
Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
    #32306704
Jinn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некто
>По твоему примеру. Бухгалтерия не разделяет партии одного и того же материала, сырья, полуфабрикатов (если они учитываются по одной карточке) , не имеет данных о качестве или иных характеристиках материалов.

М-да. Я думал методы определения себестоимости по FIFO , LIFO, средневзвешенной, идентифицированной стоимости - это способы именно партионного учета. Я ошибался, видимо. 8-(

И в этом Вы правы. НО! Это партионный учет в бухгалтерии . В производстве несколько иначе. Там партия начинается со склада. При этом партия может разделиться в каком либо цеху или объединиться с партией подобных деталей.

MRP/ERP/CRM Бухучета нет и быть не может.
Любая система класса ERP включает в себя модуль финансового и управленческого учета. По определению. Если есть хоть одна без этого модуля - подскажите какая?

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

На счет CRM - Вы меня поймали, признаю. Проводки по каждому звонку клиента - наверное не нужны.
Хотя большую часть данных о взаимоотношении с клиентом можно ( и нужно ) получать из данных бухгалтерского учета ( финасового и управленческого ).

Так какого учета? Финансового, управленческого или бухгалтерского? Зачем в бухгалтерии управленческий учет? Не лучше ли все это разделить, но пользоваться единой базой первичных документов ? При такой постановке вопроса мы получим одинаковые результаты в разной интерпретации. Да и засорять бухгалтерский модуль несвойственными бухгалтериями функциями не есть хорошо.

ERP система без модуля CMR - плохо, но не смертельно. Этого требования и в стандартах соответствия систем уровню ERP нет, кажется.
ERP система без модуля бухгалтерского учета - нахрен никому не нужная хрень. Обанкротиться можно, и очень быстро.

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

P.S. Меня больше именно автоматизация бухучета интересует. И финансового, и управленческого (оперативного). В том числе в системе из нескольких фирм, в том числе в нескольких планах счетов, в том числе с возможностью консолидации, межплановых проводок и т.п. Мне SAP R3 писать никак не возможно. Пупок развяжется. Мне бы от мыслей об 1С отдельно взятое предприятие освободить.

Правильной дорогой идем :) 1С еще та штучка. С моей точки зрения моя система для тебя может пригодиться. Для начала - сбор информации (первичные документы) в одном месте. Имея первичную информацию ты можешь ее представить в любом разрезе.
...
Рейтинг: 0 / 0
59 сообщений из 59, показаны все 3 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Нужен совет бывалых:построение складской учетной ситемы с ячеечным хранением
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]