… прямо как у классиков русской прозы … в Москву … в Москву … в Москву …
… воОООот …
п.с. ««Музыка играет так весело, бодро, и хочется жить! […] и, кажется, еще немного, и мы узнаем, зачем мы живем, зачем страдаем… Если бы знать! (Музыка играет все тише и тише.) Если бы знать, если бы знать!» (Занавес.)…»
Дааа…. а тот факт, что характеристики нужны для отборов/группировки номенклатуры в отчетах по одному или нескольким свойствам характеристики — ни полслова.
1. По статье: изложено толково, последовательно, ясно. Плюс
2. По существу (что использовать?): тут просто метод «нос вылез-хвост увяз».
Уменьшаем справочник Номенклатура, увеличиваем подчиненный справочник «ХарактеристикиНоменклатуры». Соответственно, при запросах появляется лишняя связанная таблица и т.д.
Мой личный вывод: подчиненные справочники я еще с 7.7 недолюбливаю, вариант с использованием характеристик мне менее симпатичен.
Примечание:
При постройке почти ERP-системы на Дивногорском заводе низковольтной аппаратуры на основе еще дремучей комплексной 7.7 мы использовали справочник ДоговорыГП, не подчиненный, одним из реквизитов которого был Контрагент (т.е. почти наоборот, как оно сделано в 1С). Нам это оказалось гораздо удобнее, особенно в части учета на сч. 20 и 43
P.S. И еще один вопросик возникает… Имеем УТ и БП, как синхронизировать номенклатуру? Размножаться в БП?
Тоже в последнее время задумался над тем, как уменьшить тендецию непомерного разрастания справочника. Думаю, а что если вести учет по хар-кам? Взял листочек и начал создавать товарный портфель организации с учетом существующего ассортимента и, конечно, его характеристик. Короче, через 5 мин. я плюнул на это дело, а вот почему, у нас много различных групп товара, а в них соответственно ещё чёртова куча под.., подпод…групп, т.е. вложений в корневую категорию может достигать до 8, плюс ко всему, порой не понять какие характеристики важны для нового учета (по харькам), а какие нет. По моим подсчетам оптимально использовать не более 2х характеристик иначе все опять становится непомерно сложно и нуторно.
Короче, как правильно говорит Арчибальд, нужно на берегу договариваться нужен такой учет или нет, а нужен он будет если есть хотя бы тактический план по развитию торговли, иначе проще по старинке, товар->новый код.
Любопытен вот какой вопрос, как быть тем, кто уже имеет не хилый справочник номенклатуры, как его перерабатывать, кто это должен делать, как заставить сотрудников «любить» такой учет и т.д и т.п.
(8) А вот что делать с не хилыми справочниками, мысль была написать на конференции 1С предложение добавить предопределенное свойство элементов справочника «Актуальный» (как запись в регистре, так же реализовано в ЗУПе с сотрудниками) и уже в настройках пользователя можно было бы задавать показывать только актуальные.
(5) Согласна с Вами, хотя сотрудники в этом случае, возможно, должны быть не столько высококвалифицированными, сколько хотя бы внимательными и ответственными. Впрочем, таких тоже найти не всегда просто.
Иногда использовать характеристики, наверно, удобно. В данном случае были как раз провода, список номенклатуры небольшой, но большое количество цветов/диаметров, и учет по ним вести хотели. В общем, в этом случае характеристики подошли, было удобно. Но, конечно, как панацею этот способ нельзя рекомендовать.
Имеем УТ и БП, как синхронизировать номенклатуру? Размножаться в БП
С бухучетом есть особенность и в случае, если учет ведется в единой базе (УПП). Учет по характеристикам никак не связан с планом счетов, т.е. проводка по соответствующим счетам делается только по Наименованию, характеристики там нет. Если в документе одна Номенклатура, но записана двумя строками, с разными характеристиками, и цена разная – проводка по БУ будет одна, в ней суммируется, соответственно, количество и стоимость. Ну, и списание будет идти по этой средней цене. Как синхронизировать – нужно смотреть по ситуации, наверно. Или составлять справочники так, чтобы в пределах одного элемента цена не менялась, или – увеличивать количество в БП. У нас УПП было, поэтому это все – в рамках предположения.
По поводу актуальности, может, я не совсем поняла, что Вы имеете в виду, но в ЗУП с сотрудниками проще – уволился – значит, неактуальный. А с номенклатурой – ее, может, год не поступало с такой характеристикой, а потом снова появилась, и вот кто-то должен будет сразу лезть в этот элемент и выставлять актуальность? Кажется, не очень удобно.
(10) Ир, я просто рассматриваю ситуацию с точки зрения хранения информации в таблицах. Не будет одной характеристики «красный» в связанной таблице, а будет столько записей «красный» с синхронизирующим полем по владельцу (внутр. ID номенклатуры), сколько номенклатур ссылается на «красный». Физически не выигрываем ничего, а проигрываем (хотя бы в том же прямом запросе) лишним соединением.
P.S. Например, 7.7, желаем у всех контриков завести один-разъединый договор с наименованием «Основной». Оно бы было замечательно, если бы в таблице договоров и появилась одна единственная запись. Однако — фигушки! Появится ровно столько записей, сколько есть контрагентов
(10) Да насчет примера с регистрами в (9) неправильно написал в регистрах используется понятие «Активность» 🙂
А насчет примера с номенклатурой, то заметил, что если пользователи продолжительное время не используют номенклатур (даже не обязательно год, а бывало и 3-4 месяца) то предпочитают заводить новую ! Тут естественно понятно, что нужно проводить работу с людьми, а если персонал регулярно меняется !?
P.S.: Увы, но универсального решения ПОКА в таких ситуация нету, либо я их не знаю 🙂
универсального решения ПОКА в таких ситуациях нет, либо я их не знаю
Я тоже не знаю. Вообще, подозреваю, что универсального решения здесь на самом деле нет, а кто утверждает обратное, тот либо не в теме, либо нагло врет.
Посмотрел на форуме по ссылке: совершенно идиотская постановка задачи.
Предположим, имеем три телевизора LG 19 LH2000 от поставщиков
Рога и Копыта1, Рога и Копыта2, Рога и Копыта3. Пусть даже продавец четко знает, что продал именно телевизор от поставщика Рога и Копыта3, и ему первому деньги перечислены.
Вполне резонный вопрос поставщика Рога и Копыта1:
— А какого…непечатные слова… вы продали сначала телевизор этого…непечатные слова.., если мой был вам поставлен раньше?
А зачем абсолютно одинаковые телевизоры брать у разных поставщиков?
Насколько я понял из форума, там вопрос как раз в том, что совершенно одинаковый товар взят у разных поставщиков. А иначе постановка задачи (как она там обозначена) вообще теряет смысл.
P.S. А если у них включен FIFO, то и сама проблема просто не может возникнуть
(20) Учет по среднему в моей практике практически не встречается — все используют FIFO. Народ желает видеть реальную картину, а не усредненную — типа «средняя температура по больнице 36.7». 😀
(22) Согласен. Для бухучета — по барабану, главное красиво отчитаться. А вот для упр. учета точную картину только через FIFO и можно получить. Особенно, если ЗП манагера напрямую связана с тем, что он продал.
Кстати, Ирина, фирма как раз и торгует электротехникой, прям твой пример по проводам! 😀 Но у меня даже и в мыслях не возникало завести в конфе подчиненный справочник ХарактеристикиНоменклатуры ;). Хотя конфа настолько перекроенная, что никаким обновлениям уже не поддается и теоретически там можно мутить, что хочешь.
Ну, что здесь ответить? Я не собираюсь в одиночку отдуваться за фирму 1С в плане целесообразности учета по характеристикам. Да и не говорила, что «используйте их все, и будет вам счастье», скорее, наоборот.
> Все равно какой-либо справочник/регистр будет увеличиваться – либо номенклатура, либо значения характеристик и свойств.
..
мне кажется, что не это определяющее.. больше должна волновать скорость доступа к отчетым и актуалльным данным — а от размера может зависеть совсем слабо.. вот тут и интересно было бы посмотреть — насколько снижает «производительность» системы использование характеристик…???
.
почему серии сделали отдельно? а не тоже в характеристика?
В общем и целом скажу, что практической оптимизации использования торговли — нет. Использование характеристик в штатном исполнении замедляет ввод документов…Вплоть до того, что в документах графа Характеристики имеет свойство «Пропускать при вводе», что увеличивает число нажатий клавиш и мышки…
почему серии сделали отдельно? а не тоже в характеристиках?
Снова вопрос не ко мне, а к 1С. Мне кажется, разработчики отдельных блоков программы работают изолированно друг от друга, и одни из них слабо представляют, что делают другие. Поэтому иногда то, что логично было бы видеть вместе, оказывается «разбросанным» по разным местам. Но это тольтко мое предположение, возможно, во всем этом есть какая-то стратегическая задумка.
Да, я об этом тоже думала. Возникла мысль: обычно справочники и документы заводят одни люди, а пользуются отчетами — другие. Настройки отчетов сохраняются, поэтому каждый раз их делать не надо. И этим «другим» более важно, чтобы было удобнее им, а сколько раз там в документах будет выбирать этим характеристики оператор, им все равно. Сколько времени формируется отчет — тоже все равно, не каждый же час он нужен.
Возникла мысль: обычно справочники и документы заводят одни люди, а пользуются отчетами — другие. Настройки отчетов сохраняются, поэтому каждый раз их делать не надо. И этим «другим» более важно, чтобы было удобнее им, а сколько раз там в документах будет выбирать этим характеристики оператор
На НВО нет операторов, только менеджеры. Поэтому они и заводят элементы справочников, и документы набивают, и отчетами пользуются. Так что едины во всех лицах 😉
P.S. И еще парочка именно электротехнических фирм (оптовых) — там тоже нет операторов, только бухи и менеджеры.
P.P.S. Смысл иметь операторов лично я вижу только для рознично-мелкооптовых (накладных копеечных много), либо вам там, на Западе, деньги девать некуда 😀
почему серии сделали отдельно? а не тоже в характеристика?
И тут все предельно ясно! Учет по сериям — печальная необходимость для бытовой техники, например. Хошь не хошь, а надо отразить какой именно телевизор этой модели продал. А вот Характеристики — дело вкуса
А там были, и никто их не спрашивал, удобнее им с характеристиками или без них. Да, накладных было много, уже не помню, кажется, человека два занимались исключительно ими.
Смысл иметь операторов лично я вижу только для рознично-мелкооптовых (накладных копеечных много), либо вам там, на Западе, деньги девать некуда
Мне кажется, что на многих предприятиях хватает сотрудников, которые заняты непонятно чем. Или два-три человека делают то, что вполне сделал бы и один. Вроде и все заняты, но, как известно, если человек занят, это еще не значит, что он занят делом. Впрочем, вопросов кадровой политики я никогда не решала, и моего мнения об этом не спрашивали )))
2. По существу (что использовать?): тут просто метод «нос вылез-хвост увяз».
Уменьшаем справочник Номенклатура, увеличиваем подчиненный справочник «ХарактеристикиНоменклатуры». Соответственно, при запросах появляется лишняя связанная таблица и т.д.
Мой личный вывод: подчиненные справочники я еще с 7.7 недолюбливаю, вариант с использованием характеристик мне менее симпатичен.
Никаких подчиненных справочников в 8-ке использование характеристик номенклатуры не требует. Они не нужны.
Если сравнить два варианта ведения учета в одной и той же конфигурации , позволяющей использовать характеристики номенклатуры (ХН):
1. ПРИ использовании ХН.
2. БЕЗ использовании ХН и с «увеличенным» справочником номенклатуры.
— то в п1. общий объем информации существенно меньше.
Никакого выигрыша не дает п.2. и в скорости получения отчетов.
Типовую УТ смотрел очень давно. Но, вообще говоря, организовать учет по харатеристикам номенклатуры можно и без подчиненного справочника «Характеристики номенклатуры».
(37) +(35) Даже если бы его и не было, от этого ничего не меняется. Скулю (и любому другому типу данных) глубоко фиолетово, как и что ты сам себе называешь: хоть подчиненный справочник ХарактеристикиНоменклатуры, хоть регистр сведений ЗначенияСвойствОбъектов.
Это всё — таблицы. И в них есть определенное количество полей и записей.
Так что метод «нос вылез-хвост увяз» работает вовсю 😉
Забавно: (38) писал, когда еще не видел твоих изменений в (37), тем не менее — в точку попал 😀
(38) SQL-серверу действительно всё равно обращаться к какой таблице , если состав полей , индексы ,количество записей в них одинаковы. Я же толковал про то , что объем информации в случае использования харктеристик номенклатуры -меньше.
Вместо записей в справочнике номенклатура:
Провод зеленый медный
Провод зеленый алюминевый
Провод зеленый стальной
Провод красный медный
Провод красный алюминевый
Провод красный стальной
Экономнее , проще , гибче иметь
одну запись в справчнике «номенклатура»
и две характеристики
«металл» со значениями : «сталь,алюминий, медь»
и «цвет» со значениями : «красный , зеленый»
Если же речь идет о сечении (число) , то использование характеристики номенклатуры становится необходимым . Не хотелось бы видеть ужасную картину в справчонике Номенклатура:
(41) Пусть даже и так . Т.е. при использовании подчиненного справочника.
Запись, подчиненного справочника, содержащая два поля «Провод-владелец» и «зеленый» ,предполагаю, должна быть короче (меньше по объему), чем целая новая запись справочника Номенклатура :
(43) Слушай , вопрос о том что оптимальнее с точки зрения быстродейтсвия и объема информации в общем случае вести всё-таки бессмысленно.
Ты мне приведешь один конкретный пример — я тебе другой.
И что будет быстрее еще тот вопросик.
Вообще , как я понимаю, ты исходишь из того, что необходимость левого соединения к характеристикам -есть дополнительные затраты. Это общее соображение .
Конкретно же определить условия экспримента , а затем ответить на вопросы :
ЧТО ?, НА СКОЛЬКО ? В КАКИХ СЛУЧАЯХ ? — будет тяжеловато.
Главная же претензия к статье Ирины в том , что не обозначен главный смысл введения в 8-ке нового объекта ПланВидовХарактеристик и использования его в типовых конфигурациях :
дать возможность пользователю интерактивно (без изменения конфигурации) добавлять любое количество новых разрезов аналитики для ведения учета. В 7-ке не было такой возможности.
Была 😉 Посмотри расчет зарплаты «Камин», где пользователь мог создать любой ему нужный справочник, не трогая конфу. Меня всегда умиляет, когда «чистые» восьмерочники
нахваливают то, что в 7.7 (пусть и необязательно через горло ;)), но уже было давным-давно сделано.
Да! А для тех, кто гнет пальцы на 8.1, сообщаю, что сам уж давно на 8.2 работаю 😉
Я сравниваю возможности платформ 7 и 8 . И говорю , что на уровне ПЛАТФОРМЫ появился новый механизм ПланВидовХарактеристик. И теперь появилось возможность у пользователя штатно без извращений добавлять новые аналитики.
Ты же мне тыкаешь частным решением на уровне конфигурации :
дескать , люди как — то там извратились.
Конечно, мужчина ты авторитетный.. , но про Камин (прости, Господи!) давай лучше не будем. Несолидно , как-то.
Я толкую о том, что, например, vip на «языке домохозяек» Basic пишет такие ВК, которые другим и на Си не снились. А про Камин: завтра увидит Арчибальд твой (48) — и поедом тебя съест 😀
(31) а ещё даже без серий часто нужно указывать страну происхождения… Чтобы не плодить ГТД можно характеристиками обойтись….
Характеристик всё-таки скорее болванка механизма, чем полноценный механизм… Нужно допиливать.
(32) иногда бывает так, что может сделать конечно и один, но как-то давно уже возникла ситуация, когда один не справился, поэтому приняли решение увеличить штат… Налоговая — это вредная штука.
(51) ЗУП — знаю как было дело. Но тебе не скажу. Вы с Арчибальдом начнете хихикать.
(52) Одно дело платформа позволяет извратиться программисту , т.е. создать свой кодинг и дополнительные структуры,
другое дело имеет штатный (встроенный механизм) .
Ты вон в Delfi (никогда не использовал , кстати) наверняка имеешь готовые удобные структуры типа «Соответсвия» в 1с. Так ведь ? Или ты извращаешься и реализуешь такой функционал с помощью массивов , например ?
Главная же претензия к статье Ирины в том , что не обозначен главный смысл введения в 8-ке нового объекта ПланВидовХарактеристик и использования его в типовых конфигурациях :
дать возможность пользователю интерактивно (без изменения конфигурации) добавлять любое количество новых разрезов аналитики для ведения учета.
ПланВидовХарактеристик к Характеристикам номенклатуры не имеют отношения.
Это подчиненный справочник, как уже говорили в обсуждении.
Вести характеристики можно без всякого ущерба, количество записей от этого не увеличится, вопрос только в персонале. В типовом функционале характеристики, как и серии являются измерениями всех регистров накопления по товарам, будете вы их заполнять или нет, поля все равно присутствуют в записях. Системе при обработке запросов все равно — пустая ссылка или с уникальным идентификатором — на скорость не влияет.
А вот использование свойств раздувает базу довольно таки сильно.
(55) — зря согласна; претензия к статье не имеет отношения; см. 56;
Про характеристики номенклатуры, в том виде, как они реализованы в УПП — удобство использования сомнительно. Лично я считаю, что на характеристики следует выносить лишь несущественные параметры номенклатуры, которые тем не менее охота (зачем-то?) учитывать. А это очень зависит от самой номенклатуры.
Случай с проводом — сечение и цвет — так вот сечение провода всегда существенно, от него зависит допустимый ток, брать провод в 10 раз толще необходимого нормальный клиент не будет. А вот цвет… Для монтажного провода и он весьма важен: принято, что черный — земля, красный — плюс и т.д. Для силового кабеля толщиной в руку, который еще и в землю закопают — цвет ни фига не важен, но и зачем его учитывать — непонятно.
У нас на фирме пытались на характеристики вывести учет производителя — практически отказались, и учет бухтовки провода — есть характеристика «бухты 200м», так будьте добры с нее отгружать только кратно 200 м — пока держится, но путаница частая.
любое количество новых разрезов аналитики для ведения учета.
а не только количество элементов справочника.
Да, и спасибо всем за комментарии. У меня уже не в первый раз получается так, что комментарии интереснее, глубже и логичнее исходного материала (статьи) )))))
При проведении регламентного закрытия месяца расчет себестоимости реализованной продукции происходит в разрезе только номенклатуры? Или с учетом аналитики по характеристикам?
Иными словами, себестоимость одной номенклатуры, но с разными характеристиками
1- будет одинаковой или
2- будет отличаться?
У меня нет возможности проверить. Склоняюсь к 1-му варианту.
(60) Для бухгалтерского учета вариант 1 правильный. У проводок нет аналитики по номенклатуре, поэтому себестоимость будет считаться по единице номенклатуры в целом, без учета характеристик.
(61)(60) у проводок нет, но в регистрах партий, продаж, выпуск и т.д. характеристики есть. Поэтому расчет себестоимости будет идти в разрезе характеристик. Другое дело, что только по проводкам этого не отследить.
Главное в характеристиках — не уменьшение количества элементов, а параметризация позиций (что хорошо иллюстрируется примером с выводом значения свойства в отчет). Хотя, параметры можно задавать и для номенклатуры (используя свойства). Просто для спарвочника характеристик есть хоть какая-то интерфейсная обвязка параметров…
В нашей конторе при переезде бухгалтеров с «Бухгалтерия:7.7» и менеджеров с «Торговля и склад:7.7» в общую базу УПП механизм характеристик был просто спасением. В номенклатуру загрузили справочник номенклатуры и материалов из бухгалтерии, а в характеристики — всё, что не вошло в этот справочник из названий номенклатуры менеджеров. В результате:
Во-первых, бухгалтерия не видит в своих отчетах совершенно не нужные ей тонкости, которые жизненно необходимы менеджерам.
Во-вторых, есть возможность распечатывать документы покупателям без этих тонкостей.
В-третьих, у бухгалтеров отпала необходимость заводить липовые позиции в номенклатуре для списания по конкретной стоимости. Например, гвозди приходят по разным ценам и уходят по средней себестоимости. А некоторому покупателю надо продать гвозди именно по той стоимости, по которой они закуплены. В бух. базе заводилась отдельная позиция гвоздей, и так почти по всем наименованиям. Теперь же бухгалтерия приходует и списывает одну всеобщую позицию гвоздей, но с некоторой характеристикой, которая уходит с 43 счета (а сначала с регистра) по цене прихода.
В-четвертых, упрощается ввод по строке наименований при заведении документов. Если есть (к примеру) 85 позиций, название которых начинается с одинакового слова, то ввод по строке – спасение оператора – невозможен. При характеристиках 85 позиций номенклатуры можно превратить в 16.
Ну и, в-пятых, очень удобен механизм характеристик при ежедневной работе с отчетами.
«о целесообразности и границах его применимости. Здесь – попытка найти ответ на него»
Лично я этим механизмом пользуюсь более 5 лет на различних предприятиях, так и не получил для себя окончательного ответа 🙁
С одной стороны идея очень хороша. Но далеко не совершенна. например характеристика «сечение», в приведенном автором примере… Хорошо если мы именем определенный список сечений, но если у нас может характеристика принимать не дискретное (практически любое)… что делать? Клепать бесконечно новые элементы характеристики? ладно их хранение в базе, но заставлять пользователя постоянно их видеть, даже если эта характеристика давно не актуальна.
В общем, лично мне очень не хватает характеристики типа «число», и механизма автоматического управление элементами значений характеристик.
Даже в приведенном автором примере, было б очень удобно, не выбирать из списка сечений, а вбивать его явно числом.
А вот если мы используем сечение в самом элементе номенклатуры, то получаем возможность на каждую номенклатуру задать дополнительное свойство. Таким образом получаем раздутый справочник номенклатуры, НО!, всегда можем пользоваться различными отборами. Например — остатки номенклатуры с сечением меньше 6 мм…
Спасибо, хорошая статья. вот только почему 1С не привязал «характеристику» к Услугам, могло получится замечательное решение, я это сделал и теперь услуга «Доставка товара» может использовать километраж. (добавлена как в УПП, так и КА)
— так 1С много чего «не». Впрочем, возможно, дело в том, что услуга не хранится на складе, поэтому учет в разрезе характеристик для нее считается неактуальным.
Свойство объекта — может быть число. набор значений характеристик — всегда ссылка на отдельный справочник и управлять этим справочником со стороны пользователя очень неудобно. 😐
А вот простенькую обработку для загрузки характеристик никто так и не сделал… ЛИбо набор характеристик ограничен, либо они должны быть изначально прописаны, либо они прописываются только по одной на каждое наименование номенклатуры… либо я плохо искал. хотя честно искал усердно и настойчиво.. Может кто кинет ссылку на нужную обработку?
Как уже заметили, ответа «использовать или нет» в плане влияния на скорость работы — нет. Это… грустно 🙂
Ну а при заведении характеристик для номенклатуры нужно вдумчивао подходить к вопросу, что можно в эти характеристики отнести, а какие параметры критичны и необходимо оставить в справочнике (из-за которых номенклатуру стоит плодить).
Направление «Характеристики номенклатуры» интересное и полезное. В любом случае, всегда можно выбрать вести их или нет.
К достоинствам можно отнести фильтрацию по разным характеристикам товара, что сложно сделать по обычной схеме учета.
К недостаткам следует отнести отсутствие картинок на характеристики номенклатуры. Наконец, обмены с сайтами плохо переносят обмен с 1С, где используются такие характеристики. Кроме того, на сайт такие фотографии не попадают, т.к. их некуда было вставить
На самом деле гораздо интересней было бы услышать про работу с характеристиками в УПП — каким образом они переносятся при рождении товара, и все, что связано с работой по ним с материалами и готовой продукцией.
верно, а также — если, все-таки, товар при получении идентичный, а в процессе хранения каждая «коробка» приобрела несколько отличные свойства друг от друга, а в первую очередь продался товар с более «товарным видом». А деньги широкой рукой перечислены первому поставщику — просто так, у него при закрытии сошлись номенклатура, количество и сумма.
использование характеристик номенклатуры — лишние головняки и для проггеров, и для юзверей.
абсолютно согласен. Использование характеристик не влечен за собой того, что товар с разной характеристикой автоматически становится другой номенклатурой со всеми вытанцовыванием.
Ну разделили по характеристикам «Провод медный» и «провод серый». А вот нужно использовать кроме этого еще и реквизиты номенклатуры (всякие там артикулы, штрихкоды и прочее и прочее). И что — вести еще параллельно с учетом «обычной» номенклатуры учет «номенклатуры с характеристиками» со всеми дополнительными «реквизитами характеристик» артикул, штрихкод…
Интересно, а FIFO часто используется? Я практически нигде не встречала, все в основном ведут по среднему.
Партионный учет, где он нужен (а не подмена-обманка типа «партии» РАУЗ) — это прежде всего FIFO (раз LIFO отменили). А вот учет по средней — это уже РАУЗ, так любимый 1с.
Для бухучета — по барабану, главное красиво отчитаться
как это «по барабану»? а остатки на складах? а незавершенка? как без FIFO определите, что оно реально ушло и куда? и кому деньги платить в этом месяце?
Хотя конфа настолько перекроенная, что никаким обновлениям уже не поддается и теоретически там можно мутить, что хочешь.
Характеристики затем и введены в таком «мягком» варианте, чтобы без перекраивания конфы как-то разделить номенклатуру дополнительно по другим признакам, отличным от указанных в реквизитах.
Но реальный учет по таким «реквизитам» — полный хаос. Так что туда лучше вписывать только те характеритиски, которые не влиют на учет, а только — на принятие решений и сортировку/посик номенклатуры по базе. Вот тогда механизм характеристик отрабатывает себя на все сто процентов 🙂
почему серии сделали отдельно? а не тоже в характеристика?
потому что учет по сериям нужен железно, а по характеристикам сделать подобное — это перекраивать всю конфу (ведь характеристики, по определению, могут быть какие угодно, а не только «как серии», иначе только регистр серий и получится), и не факт, что еще все будет работать без многолетних исправлений ошибок.
Собственно, в (27) Abadonna более детально описал схему «учета по характеристикам» — если все эти дополнительные поля перемножить на варианты различных расчетов, разные схемы учета и списания, то кроме усложнения «внесения инфо» на этапе введения документов в разы получим усложненные в десятки раз механизмы учета и расчета.
Ничего не проще. Нужно тогда будет постоянно делать соединения между этими таблицами, а не как раньше — запросил номенклатуру, и получил все с ней связанное.
В этом и самая главная проблема — при постановке учета по таким «характеристикам» все время надо делать соединения, чтобы верно получить именно «Провод красный», а не «Провод красный медный», и все документы-движения-расчеты-аналитику привязывать в первому, а не к обоим.
Другое дело, чтобы «скрыть» лишние «описания», не нужные на данный момент для принятия решения, из поля зрения при просмотре справочника Номенклатура.
Хорошо если мы именем определенный список сечений, но если у нас может характеристика принимать не дискретное (практически любое)… что делать? Клепать бесконечно новые элементы характеристики? ладно их хранение в базе, но заставлять пользователя постоянно их видеть, даже если эта характеристика давно не актуальна.
Этого не будет никогда.
Механизм характеристик — как он сделан, — подразумевает, что вы подставляете конкретную и окончательную характеристику, а не тип данных.
И даже если сделают просто подстановку типа данных (как в Свойствах документов) — то как другой увидит уже введенное значение свойства, чтобы его повторно использовать, не вводя нового?
Это должен быть совершенно, принципиально другой механизм характеристик — чего 1с, естественно, делать не будет даже в отдаленном будущем.
никто не запрещает вам заменить его на стоку или число.
Речь идет о ПЛАВАЮЩЕЙ характеристике, а не просто «тип число» или «тип строка».
Если один менеджер введет в эту характеристику «5» (или «фронтальный комплект»), то как другой найдет именно эту же характеристику, чтобы они были идентичны (вот возмет, и введет не «5», а «5,5», и не «фронтальный комплект», а «фронт.комп.»). И что вы в итоге найдете по таким характеристикам?
Как уже заметили, ответа «использовать или нет» в плане влияния на скорость работы — нет. Это… грустно
как это нет — вот же ответ (ранее прозвучавший немного в завуалированной форме от Абадонны):
Чем больше аналитик — тем больше тормоза.
Другое дело, когда есть какие-то преимущества от использования ХН, но есть и существенные недостатки наравне с преимуществами. И к чем пренебречь — вот это не понятно.
А как изменится скорость обработки транзакций, если использовать дополнительное поле аналитики — это совсем не вопрос в рамках архитектуры 1с.
Будет тормозить. И чем больше данных будут одновременно обрабатываться — тем больше будет тормозить.
«Делай что дОлжно, и пусть будет что будет…»
Внятно расписано, как и что будет. Остается надеяться, что кто-то выберет «что должно» ДО того, как основательно забьет базу…
… выводы … особенно понравились …
… прямо как у классиков русской прозы … в Москву … в Москву … в Москву …
… воОООот …
п.с. ««Музыка играет так весело, бодро, и хочется жить! […] и, кажется, еще немного, и мы узнаем, зачем мы живем, зачем страдаем… Если бы знать! (Музыка играет все тише и тише.) Если бы знать, если бы знать!» (Занавес.)…»
… вот …
…
Дааа…. а тот факт, что характеристики нужны для отборов/группировки номенклатуры в отчетах по одному или нескольким свойствам характеристики — ни полслова.
(3) Есть об этом не только полслова, но даже больше )))
Если интересно, посмотрите внимательнее текст, а то мне неудобно цитировать саму себя.
на вопрос почему не используете характеристики зачастую слышу
1 — не удобно операторам
2- не удобно в отчетах
3 — дороже обработки и отчеты с использованием характеристик
4 — При ведении учетов при многих фирмах/складах использование характеристик требует более высококвалифицированных сотрудников.
(со слов людей заказывающих и делающих)
хотя встречал и грамотное использование характеристик и не типовое использование (при изменяющихся характеристиках и свойствах).
Но всегда встает вопрос а на хрена и сколько стоит…
p.s. статья — плюс. в мемориз следующий раз клиентам просто показывать буду пусть сами читают.
1. По статье: изложено толково, последовательно, ясно. Плюс
2. По существу (что использовать?): тут просто метод «нос вылез-хвост увяз».
Уменьшаем справочник Номенклатура, увеличиваем подчиненный справочник «ХарактеристикиНоменклатуры». Соответственно, при запросах появляется лишняя связанная таблица и т.д.
Мой личный вывод: подчиненные справочники я еще с 7.7 недолюбливаю, вариант с использованием характеристик мне менее симпатичен.
Примечание:
При постройке почти ERP-системы на Дивногорском заводе низковольтной аппаратуры на основе еще дремучей комплексной 7.7 мы использовали справочник ДоговорыГП, не подчиненный, одним из реквизитов которого был Контрагент (т.е. почти наоборот, как оно сделано в 1С). Нам это оказалось гораздо удобнее, особенно в части учета на сч. 20 и 43
P.S. И еще один вопросик возникает… Имеем УТ и БП, как синхронизировать номенклатуру? Размножаться в БП?
Тоже в последнее время задумался над тем, как уменьшить тендецию непомерного разрастания справочника. Думаю, а что если вести учет по хар-кам? Взял листочек и начал создавать товарный портфель организации с учетом существующего ассортимента и, конечно, его характеристик. Короче, через 5 мин. я плюнул на это дело, а вот почему, у нас много различных групп товара, а в них соответственно ещё чёртова куча под.., подпод…групп, т.е. вложений в корневую категорию может достигать до 8, плюс ко всему, порой не понять какие характеристики важны для нового учета (по харькам), а какие нет. По моим подсчетам оптимально использовать не более 2х характеристик иначе все опять становится непомерно сложно и нуторно.
Короче, как правильно говорит Арчибальд, нужно на берегу договариваться нужен такой учет или нет, а нужен он будет если есть хотя бы тактический план по развитию торговли, иначе проще по старинке, товар->новый код.
Любопытен вот какой вопрос, как быть тем, кто уже имеет не хилый справочник номенклатуры, как его перерабатывать, кто это должен делать, как заставить сотрудников «любить» такой учет и т.д и т.п.
Статья хорошая для пользователей!
(8) А вот что делать с не хилыми справочниками, мысль была написать на конференции 1С предложение добавить предопределенное свойство элементов справочника «Актуальный» (как запись в регистре, так же реализовано в ЗУПе с сотрудниками) и уже в настройках пользователя можно было бы задавать показывать только актуальные.
(5) Согласна с Вами, хотя сотрудники в этом случае, возможно, должны быть не столько высококвалифицированными, сколько хотя бы внимательными и ответственными. Впрочем, таких тоже найти не всегда просто.
(7)
Иногда использовать характеристики, наверно, удобно. В данном случае были как раз провода, список номенклатуры небольшой, но большое количество цветов/диаметров, и учет по ним вести хотели. В общем, в этом случае характеристики подошли, было удобно. Но, конечно, как панацею этот способ нельзя рекомендовать.
С бухучетом есть особенность и в случае, если учет ведется в единой базе (УПП). Учет по характеристикам никак не связан с планом счетов, т.е. проводка по соответствующим счетам делается только по Наименованию, характеристики там нет. Если в документе одна Номенклатура, но записана двумя строками, с разными характеристиками, и цена разная – проводка по БУ будет одна, в ней суммируется, соответственно, количество и стоимость. Ну, и списание будет идти по этой средней цене. Как синхронизировать – нужно смотреть по ситуации, наверно. Или составлять справочники так, чтобы в пределах одного элемента цена не менялась, или – увеличивать количество в БП. У нас УПП было, поэтому это все – в рамках предположения.
(8)
Да, возможно, Вы правы, у нас на практике больше не использовали.
Еще, кстати, есть «Свойства», к примеру, у договоров контрагентов. Тоже удобный способ разделять их в отчетах по какому-либо признаку.
(9)
Спасибо!
По поводу актуальности, может, я не совсем поняла, что Вы имеете в виду, но в ЗУП с сотрудниками проще – уволился – значит, неактуальный. А с номенклатурой – ее, может, год не поступало с такой характеристикой, а потом снова появилась, и вот кто-то должен будет сразу лезть в этот элемент и выставлять актуальность? Кажется, не очень удобно.
(10) Ир, я просто рассматриваю ситуацию с точки зрения хранения информации в таблицах. Не будет одной характеристики «красный» в связанной таблице, а будет столько записей «красный» с синхронизирующим полем по владельцу (внутр. ID номенклатуры), сколько номенклатур ссылается на «красный». Физически не выигрываем ничего, а проигрываем (хотя бы в том же прямом запросе) лишним соединением.
P.S. Например, 7.7, желаем у всех контриков завести один-разъединый договор с наименованием «Основной». Оно бы было замечательно, если бы в таблице договоров и появилась одна единственная запись. Однако — фигушки! Появится ровно столько записей, сколько есть контрагентов
(10) Да насчет примера с регистрами в (9) неправильно написал в регистрах используется понятие «Активность» 🙂
А насчет примера с номенклатурой, то заметил, что если пользователи продолжительное время не используют номенклатур (даже не обязательно год, а бывало и 3-4 месяца) то предпочитают заводить новую ! Тут естественно понятно, что нужно проводить работу с людьми, а если персонал регулярно меняется !?
P.S.: Увы, но универсального решения ПОКА в таких ситуация нету, либо я их не знаю 🙂
(12)
Если бы только так! Они иногда просто предпочитают завести новую, даже не глядя, что такая уже была (и не три месяца назад, а всего пару дней) 😥
(11)
А здесь ты прав! Поэтому и спорить не буду.
(12)
Я тоже не знаю. Вообще, подозреваю, что универсального решения здесь на самом деле нет, а кто утверждает обратное, тот либо не в теме, либо нагло врет.
Вот, заодно вспомнилось: на форуме как-то обсуждали тему, в итоге как раз к свойствам и характеристикам пришли.
Посмотрел на форуме по ссылке: совершенно идиотская постановка задачи.
Предположим, имеем три телевизора LG 19 LH2000 от поставщиков
Рога и Копыта1, Рога и Копыта2, Рога и Копыта3. Пусть даже продавец четко знает, что продал именно телевизор от поставщика Рога и Копыта3, и ему первому деньги перечислены.
Вполне резонный вопрос поставщика Рога и Копыта1:
— А какого…непечатные слова… вы продали сначала телевизор этого…непечатные слова.., если мой был вам поставлен раньше?
(16)
В принципе, да. С другой стороны, поставщикам вредно быть настолько в курсе того, что происходит в компании.
А зачем абсолютно одинаковые телевизоры брать у разных поставщиков? Хотя это уже, наверно, вопрос к автору форума.
(17)
Насколько я понял из форума, там вопрос как раз в том, что совершенно одинаковый товар взят у разных поставщиков. А иначе постановка задачи (как она там обозначена) вообще теряет смысл.
P.S. А если у них включен FIFO, то и сама проблема просто не может возникнуть
Вдогонку к (11), сугубое IMHO:
использование характеристик номенклатуры — лишние головняки и для проггеров, и для юзверей. Вряд ли цель тут оправдает средства
(18)
Это я пыталась ему объяснить вначале. Но ключевая фраза у него была, наверно,
Интересно, а FIFO часто используется? Я практически нигде не встречала, все в основном ведут по среднему.
(20)
На моей бывшей (она же — новая 😀 ) работе комплексуха 7.7 — FIFO.
И задолго до меня уже было заведено.
(20) Учет по среднему в моей практике практически не встречается — все используют FIFO. Народ желает видеть реальную картину, а не усредненную — типа «средняя температура по больнице 36.7». 😀
(22) Согласен. Для бухучета — по барабану, главное красиво отчитаться. А вот для упр. учета точную картину только через FIFO и можно получить. Особенно, если ЗП манагера напрямую связана с тем, что он продал.
Кстати, Ирина, фирма как раз и торгует электротехникой, прям твой пример по проводам! 😀 Но у меня даже и в мыслях не возникало завести в конфе подчиненный справочник ХарактеристикиНоменклатуры ;). Хотя конфа настолько перекроенная, что никаким обновлениям уже не поддается и теоретически там можно мутить, что хочешь.
(24)
Ну, что здесь ответить? Я не собираюсь в одиночку отдуваться за фирму 1С в плане целесообразности учета по характеристикам. Да и не говорила, что «используйте их все, и будет вам счастье», скорее, наоборот.
Кто-то их использует — и доволен.
Кто-то не использует — и тоже доволен.
Кто-то использует — и недоволен.
Четвертый вариант тоже возможен )))
> Все равно какой-либо справочник/регистр будет увеличиваться – либо номенклатура, либо значения характеристик и свойств.
..
мне кажется, что не это определяющее.. больше должна волновать скорость доступа к отчетым и актуалльным данным — а от размера может зависеть совсем слабо.. вот тут и интересно было бы посмотреть — насколько снижает «производительность» системы использование характеристик…???
.
почему серии сделали отдельно? а не тоже в характеристика?
(25)
А никто и не говорит, что ты говорила 😀 Это мы тут просто рассуждаем.
(26)
А тут и смотреть не надо, и так ясно:
1-й вариант: Провод МГШВ 2.0 красный в справочнике надо завести один раз, в любых документах выбрать — один раз
2-й вариант: в каждом новом документе помимо «Провод» надо еще каждый раз выбрать, что он еще и «МГШВ 2.0 красный».
А в ведомости по партиям так вообще надо выбрать, что он
а) МГШВ
б) 2.0
в) красный
Как я и сказал в (19):
В общем и целом скажу, что практической оптимизации использования торговли — нет. Использование характеристик в штатном исполнении замедляет ввод документов…Вплоть до того, что в документах графа Характеристики имеет свойство «Пропускать при вводе», что увеличивает число нажатий клавиш и мышки…
но по этому поводу у меня есть идейка…
(26)
Снова вопрос не ко мне, а к 1С. Мне кажется, разработчики отдельных блоков программы работают изолированно друг от друга, и одни из них слабо представляют, что делают другие. Поэтому иногда то, что логично было бы видеть вместе, оказывается «разбросанным» по разным местам. Но это тольтко мое предположение, возможно, во всем этом есть какая-то стратегическая задумка.
(27)
Да, я об этом тоже думала. Возникла мысль: обычно справочники и документы заводят одни люди, а пользуются отчетами — другие. Настройки отчетов сохраняются, поэтому каждый раз их делать не надо. И этим «другим» более важно, чтобы было удобнее им, а сколько раз там в документах будет выбирать этим характеристики оператор, им все равно. Сколько времени формируется отчет — тоже все равно, не каждый же час он нужен.
(28)
Я надеюсь, в скором времени мы сможем об этом прочитать.
На НВО нет операторов, только менеджеры. Поэтому они и заводят элементы справочников, и документы набивают, и отчетами пользуются. Так что едины во всех лицах 😉
P.S. И еще парочка именно электротехнических фирм (оптовых) — там тоже нет операторов, только бухи и менеджеры.
P.P.S. Смысл иметь операторов лично я вижу только для рознично-мелкооптовых (накладных копеечных много), либо вам там, на Западе, деньги девать некуда 😀
(26)
И тут все предельно ясно! Учет по сериям — печальная необходимость для бытовой техники, например. Хошь не хошь, а надо отразить какой именно телевизор этой модели продал. А вот Характеристики — дело вкуса
(30)
А там были, и никто их не спрашивал, удобнее им с характеристиками или без них. Да, накладных было много, уже не помню, кажется, человека два занимались исключительно ими.
Мне кажется, что на многих предприятиях хватает сотрудников, которые заняты непонятно чем. Или два-три человека делают то, что вполне сделал бы и один. Вроде и все заняты, но, как известно, если человек занят, это еще не значит, что он занят делом. Впрочем, вопросов кадровой политики я никогда не решала, и моего мнения об этом не спрашивали )))
(31) А еще и серийные номера есть!
(7) Смутил.
Уменьшаем справочник Номенклатура, увеличиваем подчиненный справочник «ХарактеристикиНоменклатуры». Соответственно, при запросах появляется лишняя связанная таблица и т.д.
Мой личный вывод: подчиненные справочники я еще с 7.7 недолюбливаю, вариант с использованием характеристик мне менее симпатичен.
Никаких подчиненных справочников в 8-ке использование характеристик номенклатуры не требует. Они не нужны.
Если сравнить два варианта ведения учета в одной и той же конфигурации , позволяющей использовать характеристики номенклатуры (ХН):
1. ПРИ использовании ХН.
2. БЕЗ использовании ХН и с «увеличенным» справочником номенклатуры.
— то в п1. общий объем информации существенно меньше.
Никакого выигрыша не дает п.2. и в скорости получения отчетов.
(34)
О как! А на рисунке что? Галлюцинация?
Ирина , я со «своим уставом» полезу к Вам в гости.
Чем отличается песня от статьи ?
Если в художественном произведении вывод :
«думайте сами, решайте сами» — вполне оправдан — такой вывод хорошо поётся под гитару,
То как ни крути , спеть «Выводы (не претендующие на истину)» значительно тяжелее.
Это я к тому , что вывод в Вашей статье : «Дескать, как хотите…», на мой вкус, слишком размыт и портит предыдущее содержание.
Оно, конечно, так безопаснее , но и менее интересно.
(35) Извини , ошибся.
Типовую УТ смотрел очень давно. Но, вообще говоря, организовать учет по харатеристикам номенклатуры можно и без подчиненного справочника «Характеристики номенклатуры».
(37) +(35) Даже если бы его и не было, от этого ничего не меняется. Скулю (и любому другому типу данных) глубоко фиолетово, как и что ты сам себе называешь: хоть подчиненный справочник ХарактеристикиНоменклатуры, хоть регистр сведений ЗначенияСвойствОбъектов.
Это всё — таблицы. И в них есть определенное количество полей и записей.
Так что метод «нос вылез-хвост увяз» работает вовсю 😉
Забавно: (38) писал, когда еще не видел твоих изменений в (37), тем не менее — в точку попал 😀
Регистр сведений в 8-ке — голимый подчиненный справочник в терминологии 7.7, только еще и к тому же мульти-подчиненный.
А вот и дополнительное соединение:
Показать
(38) SQL-серверу действительно всё равно обращаться к какой таблице , если состав полей , индексы ,количество записей в них одинаковы. Я же толковал про то , что объем информации в случае использования харктеристик номенклатуры -меньше.
Вместо записей в справочнике номенклатура:
Провод зеленый медный
Провод зеленый алюминевый
Провод зеленый стальной
Провод красный медный
Провод красный алюминевый
Провод красный стальной
Экономнее , проще , гибче иметь
одну запись в справчнике «номенклатура»
и две характеристики
«металл» со значениями : «сталь,алюминий, медь»
и «цвет» со значениями : «красный , зеленый»
Если же речь идет о сечении (число) , то использование характеристики номенклатуры становится необходимым . Не хотелось бы видеть ужасную картину в справчонике Номенклатура:
Провод сечением 0.1
Провод сечением 0.2
Провод сечением 0.3
Провод сечением 0.7
и т.д.
(40) Ой, не уверен, но мне кажется, что ты тут шибко ошибаешься (жаль не могу в скуле посмотреть).
Мне кажется, что не будет всего два цвета в характеристиках, а будет
Провод-владелец ЗЕЛЁНЫЙ
Провод-владелец КРАСНЫЙ
Равно как:
Провод — владелец 0.1
Провод — владелец 0.2
…………………………………
и т.д.
Так что все «безобразия» из таблицы номенклатуры переползут в таблицу регистра.
(41) Пусть даже и так . Т.е. при использовании подчиненного справочника.
Запись, подчиненного справочника, содержащая два поля «Провод-владелец» и «зеленый» ,предполагаю, должна быть короче (меньше по объему), чем целая новая запись справочника Номенклатура :
«Провод зеленый».
(42) Пример из жизни:
— Аркадий, займи 10 тысяч?
— Вот ключи от квартиры, а там…
Вариант1:
— В гостиной, на пианино лежит 10 тыс. рублей, возьми
Вариант2:
— В гостиной, на пианино лежит 5 тыс. рублей, в спальне
в трюмо, в третьем ящике сверху еще 2 тысячи, на кухне на холодильнике — еще 3…
Тебе по какому варианту удобнее будет?
(43) Мне удобнее по варианту 1.
Но приходится иметь дело с тем , что есть : с квартирой Аркадия ( другие -то не дают !).
А квартира Аркадия устроена не так , чтобы было удобно давать взаймы кому ни попадя,
а так чтобы было удобно ему самому.
Деваться некуда- пойду всё соберу : спасибо , добрый человек !
(42)
Меньше по объему (даже если и так) — кого оно сейчас волнует?
А вот, что скорость доступа к информации при использовании характеристик упадет — тут даже и сомневаться не приходится!
(43) Слушай , вопрос о том что оптимальнее с точки зрения быстродейтсвия и объема информации в общем случае вести всё-таки бессмысленно.
Ты мне приведешь один конкретный пример — я тебе другой.
И что будет быстрее еще тот вопросик.
Вообще , как я понимаю, ты исходишь из того, что необходимость левого соединения к характеристикам -есть дополнительные затраты. Это общее соображение .
Конкретно же определить условия экспримента , а затем ответить на вопросы :
ЧТО ?, НА СКОЛЬКО ? В КАКИХ СЛУЧАЯХ ? — будет тяжеловато.
Главная же претензия к статье Ирины в том , что не обозначен главный смысл введения в 8-ке нового объекта ПланВидовХарактеристик и использования его в типовых конфигурациях :
дать возможность пользователю интерактивно (без изменения конфигурации) добавлять любое количество новых разрезов аналитики для ведения учета. В 7-ке не было такой возможности.
(46)
Была 😉 Посмотри расчет зарплаты «Камин», где пользователь мог создать любой ему нужный справочник, не трогая конфу. Меня всегда умиляет, когда «чистые» восьмерочники
нахваливают то, что в 7.7 (пусть и необязательно через горло ;)), но уже было давным-давно сделано.
Да! А для тех, кто гнет пальцы на 8.1, сообщаю, что сам уж давно на 8.2 работаю 😉
(47) Ты о чем толкуешь ?
Я сравниваю возможности платформ 7 и 8 . И говорю , что на уровне ПЛАТФОРМЫ появился новый механизм ПланВидовХарактеристик. И теперь появилось возможность у пользователя штатно без извращений добавлять новые аналитики.
Ты же мне тыкаешь частным решением на уровне конфигурации :
дескать , люди как — то там извратились.
Конечно, мужчина ты авторитетный.. , но про Камин (прости, Господи!) давай лучше не будем. Несолидно , как-то.
(48)
Я толкую о том, что, например, vip на «языке домохозяек» Basic пишет такие ВК, которые другим и на Си не снились. А про Камин: завтра увидит Арчибальд твой (48) — и поедом тебя съест 😀
(49) Про vip’а — верю.
Про Арчибальда — не верю. Он — хороший человек.
Будет аккуратен в выражениях и конструктивен.
За ЗУП не скажу, а 10 релизов ЗИК за год, со стандартной припиской «исправлены ошибки предыдущего релиза» — это уже наглый перебор.
(48) Кстати, объясни мне, дремучему, что значит «на уровне ПЛАТФОРМЫ»?
Если «люди как — то там извратились», значит ПЛАТФОРМА позволяет? Или не так?
(31) а ещё даже без серий часто нужно указывать страну происхождения… Чтобы не плодить ГТД можно характеристиками обойтись….
Характеристик всё-таки скорее болванка механизма, чем полноценный механизм… Нужно допиливать.
(32) иногда бывает так, что может сделать конечно и один, но как-то давно уже возникла ситуация, когда один не справился, поэтому приняли решение увеличить штат… Налоговая — это вредная штука.
(51) ЗУП — знаю как было дело. Но тебе не скажу. Вы с Арчибальдом начнете хихикать.
(52) Одно дело платформа позволяет извратиться программисту , т.е. создать свой кодинг и дополнительные структуры,
другое дело имеет штатный (встроенный механизм) .
Ты вон в Delfi (никогда не использовал , кстати) наверняка имеешь готовые удобные структуры типа «Соответсвия» в 1с. Так ведь ? Или ты извращаешься и реализуешь такой функционал с помощью массивов , например ?
(46)
дать возможность пользователю интерактивно (без изменения конфигурации) добавлять любое количество новых разрезов аналитики для ведения учета.
С претензией согласна.
ПланВидовХарактеристик к Характеристикам номенклатуры не имеют отношения.
Это подчиненный справочник, как уже говорили в обсуждении.
Вести характеристики можно без всякого ущерба, количество записей от этого не увеличится, вопрос только в персонале. В типовом функционале характеристики, как и серии являются измерениями всех регистров накопления по товарам, будете вы их заполнять или нет, поля все равно присутствуют в записях. Системе при обработке запросов все равно — пустая ссылка или с уникальным идентификатором — на скорость не влияет.
А вот использование свойств раздувает базу довольно таки сильно.
(55) — зря согласна; претензия к статье не имеет отношения; см. 56;
Про характеристики номенклатуры, в том виде, как они реализованы в УПП — удобство использования сомнительно. Лично я считаю, что на характеристики следует выносить лишь несущественные параметры номенклатуры, которые тем не менее охота (зачем-то?) учитывать. А это очень зависит от самой номенклатуры.
Случай с проводом — сечение и цвет — так вот сечение провода всегда существенно, от него зависит допустимый ток, брать провод в 10 раз толще необходимого нормальный клиент не будет. А вот цвет… Для монтажного провода и он весьма важен: принято, что черный — земля, красный — плюс и т.д. Для силового кабеля толщиной в руку, который еще и в землю закопают — цвет ни фига не важен, но и зачем его учитывать — непонятно.
У нас на фирме пытались на характеристики вывести учет производителя — практически отказались, и учет бухтовки провода — есть характеристика «бухты 200м», так будьте добры с нее отгружать только кратно 200 м — пока держится, но путаница частая.
(57) Имелось в виду, что хорошая формулировка
а не только количество элементов справочника.
Да, и спасибо всем за комментарии. У меня уже не в первый раз получается так, что комментарии интереснее, глубже и логичнее исходного материала (статьи) )))))
(48) Камин 2.0 — совершенно несолидно. Он только одним отличается от одноэсных зарплат: он работает. Во всем остальном — отстой.
Но я полностью с тобой солидарен: если ты предпочитаешь иметь солидную программу — ЗУП тебе в руки и барабан на шею.
Хотя… Сами-то одноэсовцы, похоже, считают отстоем платформу 8.1…
Вопрос по УПП.
При проведении регламентного закрытия месяца расчет себестоимости реализованной продукции происходит в разрезе только номенклатуры? Или с учетом аналитики по характеристикам?
Иными словами, себестоимость одной номенклатуры, но с разными характеристиками
1- будет одинаковой или
2- будет отличаться?
У меня нет возможности проверить. Склоняюсь к 1-му варианту.
(60) Для бухгалтерского учета вариант 1 правильный. У проводок нет аналитики по номенклатуре, поэтому себестоимость будет считаться по единице номенклатуры в целом, без учета характеристик.
(61)(60) у проводок нет, но в регистрах партий, продаж, выпуск и т.д. характеристики есть. Поэтому расчет себестоимости будет идти в разрезе характеристик. Другое дело, что только по проводкам этого не отследить.
(58)
Не-не, все нормально с исходным материалом, он нужен , полезен и востребован.
Главное в характеристиках — не уменьшение количества элементов, а параметризация позиций (что хорошо иллюстрируется примером с выводом значения свойства в отчет). Хотя, параметры можно задавать и для номенклатуры (используя свойства). Просто для спарвочника характеристик есть хоть какая-то интерфейсная обвязка параметров…
В нашей конторе при переезде бухгалтеров с «Бухгалтерия:7.7» и менеджеров с «Торговля и склад:7.7» в общую базу УПП механизм характеристик был просто спасением. В номенклатуру загрузили справочник номенклатуры и материалов из бухгалтерии, а в характеристики — всё, что не вошло в этот справочник из названий номенклатуры менеджеров. В результате:
Во-первых, бухгалтерия не видит в своих отчетах совершенно не нужные ей тонкости, которые жизненно необходимы менеджерам.
Во-вторых, есть возможность распечатывать документы покупателям без этих тонкостей.
В-третьих, у бухгалтеров отпала необходимость заводить липовые позиции в номенклатуре для списания по конкретной стоимости. Например, гвозди приходят по разным ценам и уходят по средней себестоимости. А некоторому покупателю надо продать гвозди именно по той стоимости, по которой они закуплены. В бух. базе заводилась отдельная позиция гвоздей, и так почти по всем наименованиям. Теперь же бухгалтерия приходует и списывает одну всеобщую позицию гвоздей, но с некоторой характеристикой, которая уходит с 43 счета (а сначала с регистра) по цене прихода.
В-четвертых, упрощается ввод по строке наименований при заведении документов. Если есть (к примеру) 85 позиций, название которых начинается с одинакового слова, то ввод по строке – спасение оператора – невозможен. При характеристиках 85 позиций номенклатуры можно превратить в 16.
Ну и, в-пятых, очень удобен механизм характеристик при ежедневной работе с отчетами.
В общем, все счастливы.
Хороша статья, но ответ на вопрос темы не дано 🙁
«о целесообразности и границах его применимости. Здесь – попытка найти ответ на него»
Лично я этим механизмом пользуюсь более 5 лет на различних предприятиях, так и не получил для себя окончательного ответа 🙁
С одной стороны идея очень хороша. Но далеко не совершенна. например характеристика «сечение», в приведенном автором примере… Хорошо если мы именем определенный список сечений, но если у нас может характеристика принимать не дискретное (практически любое)… что делать? Клепать бесконечно новые элементы характеристики? ладно их хранение в базе, но заставлять пользователя постоянно их видеть, даже если эта характеристика давно не актуальна.
В общем, лично мне очень не хватает характеристики типа «число», и механизма автоматического управление элементами значений характеристик.
Даже в приведенном автором примере, было б очень удобно, не выбирать из списка сечений, а вбивать его явно числом.
А вот если мы используем сечение в самом элементе номенклатуры, то получаем возможность на каждую номенклатуру задать дополнительное свойство. Таким образом получаем раздутый справочник номенклатуры, НО!, всегда можем пользоваться различными отборами. Например — остатки номенклатуры с сечением меньше 6 мм…
(66) А кто мешает создать свойство объекта с типом число? В типе значения можно для него можно задавать простые типы данных — такие как строка и число
Спасибо! Прекрасный материал. Даже мои юзеры поняли!
(66)
«Лично я этим механизмом пользуюсь более 5 лет»
«лично мне очень не хватает характеристики типа «число»
… однако
Спасибо, хорошая статья. вот только почему 1С не привязал «характеристику» к Услугам, могло получится замечательное решение, я это сделал и теперь услуга «Доставка товара» может использовать километраж. (добавлена как в УПП, так и КА)
(70) Спасибо и Вам. Насчет
— так 1С много чего «не». Впрочем, возможно, дело в том, что услуга не хранится на складе, поэтому учет в разрезе характеристик для нее считается неактуальным.
(67)
Свойство объекта — может быть число. набор значений характеристик — всегда ссылка на отдельный справочник и управлять этим справочником со стороны пользователя очень неудобно. 😐
(70)
Многим спецам приходилось добавлять характеристики к услугам, в том числе мне.
«лично мне очень не хватает характеристики типа «число» —
Почему нет? -Есть!!!
По умолчанию создается тип «Список значений», но никто не запрещает вам заменить его на стоку или число.
например уменя в характеристику таким образов добавлен «Артикул характеристики» и «Примечение к характеристике.» которые являются строками.
Пример
«A 0156, .04, 25мм, 080, Комплект для фронтальных зубов»
«строка», «знч из списка»,»знч из списка»,»знч из списка»,»Строка»
Ещё вопрос по характеристикам. Но уже в БП 2.0 (хоть тема и про УПП и УТ).
Новое в БП 2.0 — доп. харакеристики в справочниках. НО в БП невозможно организовать учет в разрезе харакеритик по аналогии с УПП.
Доп. характеристикииспользуются только для отборов, вывода дополнительной информации в отчеты. Но отчеты с аналитикой по характеристикам невозможны.
И ещё пример: в документе «ПоступлениеТиУ» в табличной части невозможно выбрать несколько строк одной номенклатуры с разными характеристиками.
Правльно поняла?
(74) К сожалению, с БП 2.0 не работаю пока, но посмотрела и пришла к такому же выводу.
Причем у меня даже отбор по характеристике в отчете НЕ работает.
Хорошо бы, конечно, еще кто-нибудь свое мнение здесь добавил.
А вот простенькую обработку для загрузки характеристик никто так и не сделал… ЛИбо набор характеристик ограничен, либо они должны быть изначально прописаны, либо они прописываются только по одной на каждое наименование номенклатуры… либо я плохо искал. хотя честно искал усердно и настойчиво.. Может кто кинет ссылку на нужную обработку?
Статья действительно обстоятельная и полезная, но «суть» остается в подъезде — что же оптимально использовать… Мнения разошлись, а практики маловато!
(77) Спасибо. А по поводу разошедшихся мнений — так у нас до сих пор даже на тему, что лучше — 7.7 или 8 — у многих мнения расходятся))
(76) Lokon, А откуда грузить хотите?
(77) (78)
что лучше — молоток или кувалда, что лучше — камаз или газель — у многих мнения расходятся))
Как уже заметили, ответа «использовать или нет» в плане влияния на скорость работы — нет. Это… грустно 🙂
Ну а при заведении характеристик для номенклатуры нужно вдумчивао подходить к вопросу, что можно в эти характеристики отнести, а какие параметры критичны и необходимо оставить в справочнике (из-за которых номенклатуру стоит плодить).
(81) Medvedik, Спасибо за дельный совет!
Хорошая, но уже устаревшая информация. Может кто соберется с силами и обновит для последней 11 версии?
Направление «Характеристики номенклатуры» интересное и полезное. В любом случае, всегда можно выбрать вести их или нет.
К достоинствам можно отнести фильтрацию по разным характеристикам товара, что сложно сделать по обычной схеме учета.
К недостаткам следует отнести отсутствие картинок на характеристики номенклатуры. Наконец, обмены с сайтами плохо переносят обмен с 1С, где используются такие характеристики. Кроме того, на сайт такие фотографии не попадают, т.к. их некуда было вставить
На самом деле гораздо интересней было бы услышать про работу с характеристиками в УПП — каким образом они переносятся при рождении товара, и все, что связано с работой по ним с материалами и готовой продукцией.
(16) Abadonna,
верно, а также — если, все-таки, товар при получении идентичный, а в процессе хранения каждая «коробка» приобрела несколько отличные свойства друг от друга, а в первую очередь продался товар с более «товарным видом». А деньги широкой рукой перечислены первому поставщику — просто так, у него при закрытии сошлись номенклатура, количество и сумма.
(17)
да если в компании больше одного менеджера — это будет само собой получаться.
(19) Abadonna,
абсолютно согласен. Использование характеристик не влечен за собой того, что товар с разной характеристикой автоматически становится другой номенклатурой со всеми вытанцовыванием.
Ну разделили по характеристикам «Провод медный» и «провод серый». А вот нужно использовать кроме этого еще и реквизиты номенклатуры (всякие там артикулы, штрихкоды и прочее и прочее). И что — вести еще параллельно с учетом «обычной» номенклатуры учет «номенклатуры с характеристиками» со всеми дополнительными «реквизитами характеристик» артикул, штрихкод…
(20)
Партионный учет, где он нужен (а не подмена-обманка типа «партии» РАУЗ) — это прежде всего FIFO (раз LIFO отменили). А вот учет по средней — это уже РАУЗ, так любимый 1с.
(23) Abadonna,
как это «по барабану»? а остатки на складах? а незавершенка? как без FIFO определите, что оно реально ушло и куда? и кому деньги платить в этом месяце?
(24) Abadonna,
Характеристики затем и введены в таком «мягком» варианте, чтобы без перекраивания конфы как-то разделить номенклатуру дополнительно по другим признакам, отличным от указанных в реквизитах.
Но реальный учет по таким «реквизитам» — полный хаос. Так что туда лучше вписывать только те характеритиски, которые не влиют на учет, а только — на принятие решений и сортировку/посик номенклатуры по базе. Вот тогда механизм характеристик отрабатывает себя на все сто процентов 🙂
(26) CheBurator,
потому что учет по сериям нужен железно, а по характеристикам сделать подобное — это перекраивать всю конфу (ведь характеристики, по определению, могут быть какие угодно, а не только «как серии», иначе только регистр серий и получится), и не факт, что еще все будет работать без многолетних исправлений ошибок.
Собственно, в (27) Abadonna более детально описал схему «учета по характеристикам» — если все эти дополнительные поля перемножить на варианты различных расчетов, разные схемы учета и списания, то кроме усложнения «внесения инфо» на этапе введения документов в разы получим усложненные в десятки раз механизмы учета и расчета.
(40) Ish_2,
…
Экономнее , проще , гибче иметь
одну запись в справчнике «номенклатура»
и две характеристики
Ничего не проще. Нужно тогда будет постоянно делать соединения между этими таблицами, а не как раньше — запросил номенклатуру, и получил все с ней связанное.
В этом и самая главная проблема — при постановке учета по таким «характеристикам» все время надо делать соединения, чтобы верно получить именно «Провод красный», а не «Провод красный медный», и все документы-движения-расчеты-аналитику привязывать в первому, а не к обоим.
Другое дело, чтобы «скрыть» лишние «описания», не нужные на данный момент для принятия решения, из поля зрения при просмотре справочника Номенклатура.
(66) vladen,
Этого не будет никогда.
Механизм характеристик — как он сделан, — подразумевает, что вы подставляете конкретную и окончательную характеристику, а не тип данных.
И даже если сделают просто подстановку типа данных (как в Свойствах документов) — то как другой увидит уже введенное значение свойства, чтобы его повторно использовать, не вводя нового?
Это должен быть совершенно, принципиально другой механизм характеристик — чего 1с, естественно, делать не будет даже в отдаленном будущем.
(69) tango,
… однако
(73) hdman,
никто не запрещает вам заменить его на стоку или число.
Речь идет о ПЛАВАЮЩЕЙ характеристике, а не просто «тип число» или «тип строка».
Если один менеджер введет в эту характеристику «5» (или «фронтальный комплект»), то как другой найдет именно эту же характеристику, чтобы они были идентичны (вот возмет, и введет не «5», а «5,5», и не «фронтальный комплект», а «фронт.комп.»). И что вы в итоге найдете по таким характеристикам?
(81) Medvedik,
как это нет — вот же ответ (ранее прозвучавший немного в завуалированной форме от Абадонны):
Чем больше аналитик — тем больше тормоза.
Другое дело, когда есть какие-то преимущества от использования ХН, но есть и существенные недостатки наравне с преимуществами. И к чем пренебречь — вот это не понятно.
А как изменится скорость обработки транзакций, если использовать дополнительное поле аналитики — это совсем не вопрос в рамках архитектуры 1с.
Будет тормозить. И чем больше данных будут одновременно обрабатываться — тем больше будет тормозить.
(20) Вот тут я с Вами не соглашусь!!!!
(22) mdzen, достойный ответ. Какие могут быть середины? ДА и LIFO разве что при дефляции использовать! Только ФИФО!!! И не иначе!!!