|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
Как будет если поле хранящее одновременно и количество и вес сделать тип Currency? Или какой тип использовать правильно? Формат веса будет всего 2 цифры после запятой. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2017, 13:48 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
Адеке, стесняюсь спросить - а что это за извращение - "поле хранящее одновременно и количество и вес"? По логике - удобнее и у универсальнее иметь два отдельных поля: в одном указывается "Единица измерения" - штуки, КГ, упаковка, и так далее. А в другом - хранится, собственно, количество чего то там в единицах измерения, указанных в соответствующем поле. Я лично, после некоторых извращений, для "количества" использую числовое поле, размер "действительное", формат "основной", точность 11, шкала 3, число дес. знаков 3. Мне нужно, что бы можно было хранить значения до трёх знаков после запятой (например, вес в граммах) для развесного товара. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2017, 14:31 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
Tarasios, да, так и есть. Раньше только штучные товары продавали, поэтому тип поля было INTEGER. А сейчас подключаются и весовые товары, поэтому и возник вопрос, на какой изменить тип поля таблицы: денежный или действительный? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2017, 16:12 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
АдекеКак будет если поле хранящее одновременно и количество и вес сделать тип Currency? Или какой тип использовать правильно? Формат веса будет всего 2 цифры после запятой. - Собственно в вашем ракурсе (как в прочем и в моем) количество и вес это одно и тоже, только у меня это поле двойной точности (Double) ибо к типу поля Currency акцес где нужно и где не нужно норовит прикрутить рубли. а так в принципе и Currency покатило бы, если везде тыкать принудительный формат... - вот только точность три знака после запятой, а не два ибо бывает и 325 грамм, да и просто две - это не наглядно... - если у вас розница - советую выбросить единицы измерения вообще на помойку, и коню понятно, что пачка сигарет, бутылка, и т.д. это штука, а в классификаторе уже написано что Вино 0,75 Л... - соответственно мука, сахар, печеньки на развес и т.д. это очевидно килограммы, а разливное пиво, молоко и т.д. это очевидно литры... - розница настолько благодарна, что я избавил ее от единиц измерения, что даже приходуют батарейки в комлекте по 4 шт. например как одна штука (один комплект), а если нужно (иногда) раздербанить упаковку и продать только одну батарейку - бибикают упаковку и продают количество 0,25 - ну и на весовой товар нужно писать свою функцию округления до трех заков (типа как для копеек), чтоб в отчетах и интерфейсе не было несуразной дробной части... Люблю всё делать не стандартно, не как все... ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2017, 18:35 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
vmag, 0,25 упаковки батареек - это круто, это точно, "не как все" )) Я в рознице немного по другому пути пошёл. Если один и тот же товар хозяин продаёт и упаковкой, и поштучно - то в справочнике товара делается две позиции: для учёта в штуках и в упаковках. Если надо "раздербанить упаковку" - списывается на "роскомплектацию" упаковка (с одной позиции) и зачисляется уже в штуках (штук в упаковке * на кол-во упаковок) . После чего продавать можно и поштучно, и в упаковках. На будущее прикручу автоматический "раздерибан" упаковок по требованию. Любой способ имеет свои плюсы и минусы, понятное дело. По типу полей. Currency не нравится определённо по причине хитрого округления и хранения цифр. Ставлю, например, в таблице 2 знака после запятой, в форме - 2 знака. Отображается всё красиво и правильно. Например - 9,26. Ставлю курсор в поле - опаньки, а там, на самом деле, 9,253. И в процентных подсчётах скидки, сдачи - порой эти тысячные складываются в значимые копейки, кассиры и клиенты напрягаются. Делал "насильное" округление до двух знаков - задалбывают лишние движения по каждому такому полю - в формах, отчётах, да и долго. В итоге, как написал выше, подобрал тип поля - доволен, да и претензий пока не получаю. Знаки после указанных - просто "отрезаются". Такой тип поля теперь использую и для хранения количества товара и для "денеХ". ... |
|||
:
Нравится:
Не нравится:
|
|||
15.10.2017, 20:50 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
TarasiosПо типу полей. Currency не нравится определённо по причине хитрого округления и хранения цифр. Ставлю, например, в таблице 2 знака после запятой, в форме - 2 знака. Отображается всё красиво и правильно. Например - 9,26. Ставлю курсор в поле - опаньки, а там, на самом деле, 9,253. И в процентных подсчётах скидки, сдачи - порой эти тысячные складываются в значимые копейки, кассиры и клиенты напрягаются. Ясно. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2017, 14:36 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
Использовать Double для хранения счётных по своей сути данных вместо Currency или Decimal - это экстремально вредный совет. Кто из программистов не смог в валидацию ввода и форматирование вывода - его проблемы. А вот проблемы с неправильным хранением огребут все, причём не сразу, а когда масштаб проблемы уже может стать мало контролируемым. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2017, 17:23 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
Не вынесла душа поэта... (c) :) ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2017, 18:15 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
13-й кварталИспользовать Double для хранения счётных по своей сути данных вместо Currency или Decimal - это экстремально вредный совет. А вот проблемы с неправильным хранением огребут все, причём не сразу, а когда масштаб проблемы уже может стать мало контролируемым. А можно с этого места поподробнее? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2017, 18:40 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
Tarasios, можете объяснить, почему в приложенном примере при выполнении запроса Q_SumEqualTo100K в столбце SumEqualTo100K видим 0 (сумма не равна 100000)? И если в запросе Q_Sum заменить CDbl на CCur, то будет равна? Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2017, 21:10 |
|
Поле хранящее одновременно и количество и вес - тип Currency?
|
|||
---|---|---|---|
#18+
13-й кварталИспользовать Double для хранения счётных по своей сути данных вместо Currency или Decimal - это экстремально вредный совет. Кто из программистов не смог в валидацию ввода и форматирование вывода - его проблемы. А вот проблемы с неправильным хранением огребут все, причём не сразу, а когда масштаб проблемы уже может стать мало контролируемым. C 2008 года нет проблем, причем использование очень интенсивное - основная величина в складской программе розницы... Я сразу сказал что нужно: vmag- ну и на весовой товар нужно писать свою функцию округления до трех заков (типа как для копеек), чтоб в отчетах и интерфейсе не было несуразной дробной части... Это как блюдо из фуги... не умеешь готовить - умер, экзотика... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.10.2017, 21:49 |
|
|
start [/forum/topic.php?fid=45&msg=39537670&tid=1611999]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
others: | 263ms |
total: | 383ms |
0 / 0 |