|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
и да продавать "товары" очень не рационально , ибо тогда нельзя будет по закону "продать" "телефон+ пленку в подарок", ибо нельзя продать товар по цене 0. для этого делают отдельную сущность. и таки не вижу "услуг" или даже возможность "впихнуть" услуги в данную структуру, а если таки предполагается торговля электроникой, то таки услуги наверняка должны быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2018, 16:48 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
ПАРТИОННЫЙ УЧЕТ. Ребят, такое ощущение, что это какая-то проторенная дорожка. Чисто с бухгалтерской точки зрения это значит учет себестоимости по методу FIFO? Есть у кого-нибудь пример структуры, в которой реализован партионный учет? Очень интересно посмотреть. Sergueimake.believeИзображение структуры в PNG. ProductStatuses_Product подозрительно живет своей жизнью независимо от поставок и продаж. Какие статусы там предполагаются? Статус товара: 1. В наличии (готов к реализации) 2. В пути 3. На ремонте 4. Неликвид (описать состояние товара: царапины, наличие упаковки и т.д.) SergueiSergueiProductStatuses_Product подозрительно живет своей жизнью независимо от поставок и продаж. Какие статусы там предполагаются? Я так понимаю Warehoses_products -попытка сделать движения товаров между складами? Если да то - то подумайте получше что там не так. Ммм... да, я создавал эту таблицу чтобы иметь возможность отслеживать именно размещение по складам. Т.е. например всего поступило 10 штук какого-то товара, из них 3 в магазин, 7 на склад. Далее "+1" в магазин, например, "-1" на складе. Дальше пока не думается, помощь окажите? Гигабайт Мегабайтович Килобайтови да продавать "товары" очень не рационально , ибо тогда нельзя будет по закону "продать" "телефон+ пленку в подарок", ибо нельзя продать товар по цене 0. для этого делают отдельную сущность. и таки не вижу "услуг" или даже возможность "впихнуть" услуги в данную структуру, а если таки предполагается торговля электроникой, то таки услуги наверняка должны быть. Закону РФ? Привет из КР, тут можно. Услуги есть, вы правы. Планировал делать отдельной схемой, чтобы не мешать с товарами. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.02.2018, 18:46 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
тогда нельзя будет по закону "продать" "телефон+ пленку в подарок", ибо нельзя продать товар по цене 0. По 1коп/1рупь можно. Обычно так и делают. При этом это полноценное товарное движение. Иногда делают такую цену, чтоб НДС был 1коп. Тогда и на POS нет проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 10:46 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
make.believeПАРТИОННЫЙ УЧЕТ. Ребят, такое ощущение, что это какая-то проторенная дорожка. Чисто с бухгалтерской точки зрения это значит учет себестоимости по методу FIFO? Нет, FIFO это другое. Партионный учет, если говорить про оценку запасов, скорее соответствует тому, что законодатель называет "по себестоимости каждой единицы". make.believeСтатус товара: 1. В наличии (готов к реализации) 2. В пути 3. На ремонте 4. Неликвид (описать состояние товара: царапины, наличие упаковки и т.д.) Беда в том, что эти статусы никак не связаны ни с поставками, ни с остатками, ни с продажами. То есть, поступили 100 ручек, из них 5 поцарапанных. Хорошо, внесли в статусы - поцарапанных, 5 штук. Хотя уже потеряна информация, от какого поставщика они пришли. А затем продали 10, осталось 90. Как узнать, остались у нас поцарапанные ручки, или может как раз их и продали? Вручную при каждой продаже пересматривать и править все статусы? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 10:55 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
Есть у кого-нибудь пример структуры, в которой реализован партионный учет? Очень интересно посмотреть. Вариантов решений много. Ньансов еще больше. Тема довольно ёмкая и дискуссионная. Как делал я(основные положения) : Контрагенты/склады/POS - в одной таблице. Это адреса движения откуда/куда (см. ниже) Все товарные док-ты в одной паре таблиц. Шапка/строки. Некот. из них "фиктивные" т.к. генерятся из первички с других таблиц. Н-р инвентаризация. Лежит отдельно. При проведении создает пару документов - списание и оприходование. Это физически выравнивает остатки. Идентификатор партии - ИД строчной части. Журнал движения : Партия/ТипДокумента/дата/товар/откуда/куда/сколько(+,-)/цена. Журнал привязок между партиями: ПартияПрихода/ПартияРасхода/кол-во Партия может быть неизрасходована. В т.ч. расходная партия. Взаимопривязки происходят на лету при проведении док-тов. Это позволяет отпускать "в минус". Проведение закрывает(исчерпывает) и приходную и расходную партии. Для вн.перемещений есть запрет на "отпуск в минус". Журнал незакрытых партий : служ. таблица для быстроты расчетов. Она же хранит текущие остатки в разрезе склада. Достаточно просуммировать по нужному складу. Новые партии добавляются, исчерпанные партии удаляются. Услуги можно проводить только по журналу движения. Схема предельно простая и может быть усилена к-л ньюансами/признаками/доп.таблицами. Складская отчетность строится по журналу движения. Остатки на произвольную дату: "незакрытые партии" - "обороты от сегодня до нужной даты". зы: схема показана упрощенно. Ньюансов много. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 11:38 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
То есть, поступили 100 ручек, из них 5 поцарапанных. Хорошо, внесли в статусы - поцарапанных, 5 штук. Хотя уже потеряна информация, от какого поставщика они пришлиИ чо ? Это вполне можно учесть, если к коду склада добавлять код типа запаса: своб.запас/резерв/брак/неликвид/отложено и т.д. Видна не только вся картина запасов, но и партия, по кот. поступил брак/неликвид. И отпуск также можно полностью регулировать: из своб. запаса продали 20шт и из брака 5шт. В люб. момент можно перенести из своб. запаса в брак/и пр. или наоборот (вн. перемещением). Этот же код позволяет вести адресное хранение, если таковое нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 11:46 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
LSVТо есть, поступили 100 ручек, из них 5 поцарапанных. Хорошо, внесли в статусы - поцарапанных, 5 штук. Хотя уже потеряна информация, от какого поставщика они пришлиИ чо ? Это вполне можно учесть, если к коду склада добавлять код типа запаса: своб.запас/резерв/брак/неликвид/отложено и т.д. Видна не только вся картина запасов, но и партия, по кот. поступил брак/неликвид. И отпуск также можно полностью регулировать: из своб. запаса продали 20шт и из брака 5шт. В люб. момент можно перенести из своб. запаса в брак/и пр. или наоборот (вн. перемещением). Этот же код позволяет вести адресное хранение, если таковое нужно. Я именно это и имел в виду, что статусы лучше если уже не к партиям, то остаткам на складах привязывать. А у ТС статусы к справочнику товаров привязаны, непонятно даже, на каком складе царапанные ручки лежат. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 12:25 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
make.believeМмм... да, я создавал эту таблицу чтобы иметь возможность отслеживать именно размещение по складам. Т.е. например всего поступило 10 штук какого-то товара, из них 3 в магазин, 7 на склад. Далее "+1" в магазин, например, "-1" на складе. Неизвестны полные требования к функционалу, как можно что то советовать... Я бы сделал общую "таблицу операций" с товарами с указанием типа операции, времени и места выполнения и от нее бы расходился "звездой" в разные стороны со специфическими атрибутами. Cane Cat Fisher Как узнать, остались у нас поцарапанные ручки, или может как раз их и продали? Вручную при каждой продаже пересматривать и править все статусы? Вообще на мой взгляд поцарапанные ручки это отдельная товарная позиция. Ведь они даже по своей цене (пониженной) будут продаваться. Так что тут все понятно должно быть. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 14:50 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
SergueiВообще на мой взгляд поцарапанные ручки это отдельная товарная позиция. Ведь они даже по своей цене (пониженной) будут продаваться. Так что тут все понятно должно быть.Плохое решение. Разве что для примитивных систем, как выход из положения. Это задвоит все карточки товара в перспективе. Что однозначно увеличит хаос. Достаточно складского статуса "брак" и спец. цены "Брак". Вариантов решения много. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 15:00 |
|
Структура БД учета товаров (приход/продажа/возвраты/инвентаризация)
|
|||
---|---|---|---|
#18+
[quote LSV]SergueiПлохое решение. Разве что для примитивных систем, как выход из положения. Это задвоит все карточки товара в перспективе. Что однозначно увеличит хаос. Достаточно складского статуса "брак" и спец. цены "Брак". Не вижу проблем такие товарные позиции делать "динамическими" (не создавая в базе товарную позицию, а сделать цену для товара в зависимости от состояния, но при этом все это должно быть в разделе "брак" или "уценка". Это вопрос реализации. На сколько я понял, что нечто подобное вы и предлагаете. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2018, 15:14 |
|
|
start [/forum/topic.php?fid=32&gotonew=1&tid=1540084]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
12ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 178ms |
0 / 0 |