Использование характеристик в 1С: 8 УТ, УПП

98 Comments

  1. Арчибальд

    «Делай что дОлжно, и пусть будет что будет…»

    Внятно расписано, как и что будет. Остается надеяться, что кто-то выберет «что должно» ДО того, как основательно забьет базу…

    Reply
  2. Шёпот теней

    … выводы … особенно понравились …

    … прямо как у классиков русской прозы … в Москву … в Москву … в Москву …

    … воОООот …

    п.с. ««Музыка играет так весело, бодро, и хочется жить! […] и, кажется, еще немного, и мы узнаем, зачем мы живем, зачем страдаем… Если бы знать! (Музыка играет все тише и тише.) Если бы знать, если бы знать!» (Занавес.)…»

    … вот …

    Reply
  3. Reaper_1C

    Дааа…. а тот факт, что характеристики нужны для отборов/группировки номенклатуры в отчетах по одному или нескольким свойствам характеристики — ни полслова.

    Reply
  4. Alraune

    (3) Есть об этом не только полслова, но даже больше )))

    Если интересно, посмотрите внимательнее текст, а то мне неудобно цитировать саму себя.

    Reply
  5. iov

    на вопрос почему не используете характеристики зачастую слышу

    1 — не удобно операторам

    2- не удобно в отчетах

    3 — дороже обработки и отчеты с использованием характеристик

    4 — При ведении учетов при многих фирмах/складах использование характеристик требует более высококвалифицированных сотрудников.

    (со слов людей заказывающих и делающих)

    хотя встречал и грамотное использование характеристик и не типовое использование (при изменяющихся характеристиках и свойствах).

    Но всегда встает вопрос а на хрена и сколько стоит…

    Reply
  6. iov

    p.s. статья — плюс. в мемориз следующий раз клиентам просто показывать буду пусть сами читают.

    Reply
  7. Abadonna

    1. По статье: изложено толково, последовательно, ясно. Плюс

    2. По существу (что использовать?): тут просто метод «нос вылез-хвост увяз».

    Уменьшаем справочник Номенклатура, увеличиваем подчиненный справочник «ХарактеристикиНоменклатуры». Соответственно, при запросах появляется лишняя связанная таблица и т.д.

    Мой личный вывод: подчиненные справочники я еще с 7.7 недолюбливаю, вариант с использованием характеристик мне менее симпатичен.

    Примечание:

    При постройке почти ERP-системы на Дивногорском заводе низковольтной аппаратуры на основе еще дремучей комплексной 7.7 мы использовали справочник ДоговорыГП, не подчиненный, одним из реквизитов которого был Контрагент (т.е. почти наоборот, как оно сделано в 1С). Нам это оказалось гораздо удобнее, особенно в части учета на сч. 20 и 43

    P.S. И еще один вопросик возникает… Имеем УТ и БП, как синхронизировать номенклатуру? Размножаться в БП?

    Reply
  8. Dimka74

    Тоже в последнее время задумался над тем, как уменьшить тендецию непомерного разрастания справочника. Думаю, а что если вести учет по хар-кам? Взял листочек и начал создавать товарный портфель организации с учетом существующего ассортимента и, конечно, его характеристик. Короче, через 5 мин. я плюнул на это дело, а вот почему, у нас много различных групп товара, а в них соответственно ещё чёртова куча под.., подпод…групп, т.е. вложений в корневую категорию может достигать до 8, плюс ко всему, порой не понять какие характеристики важны для нового учета (по харькам), а какие нет. По моим подсчетам оптимально использовать не более 2х характеристик иначе все опять становится непомерно сложно и нуторно.

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

    Любопытен вот какой вопрос, как быть тем, кто уже имеет не хилый справочник номенклатуры, как его перерабатывать, кто это должен делать, как заставить сотрудников «любить» такой учет и т.д и т.п.

    Reply
  9. YAN

    Статья хорошая для пользователей!

    (8) А вот что делать с не хилыми справочниками, мысль была написать на конференции 1С предложение добавить предопределенное свойство элементов справочника «Актуальный» (как запись в регистре, так же реализовано в ЗУПе с сотрудниками) и уже в настройках пользователя можно было бы задавать показывать только актуальные.

    Reply
  10. Alraune

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

    (7)

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

    Имеем УТ и БП, как синхронизировать номенклатуру? Размножаться в БП

    С бухучетом есть особенность и в случае, если учет ведется в единой базе (УПП). Учет по характеристикам никак не связан с планом счетов, т.е. проводка по соответствующим счетам делается только по Наименованию, характеристики там нет. Если в документе одна Номенклатура, но записана двумя строками, с разными характеристиками, и цена разная – проводка по БУ будет одна, в ней суммируется, соответственно, количество и стоимость. Ну, и списание будет идти по этой средней цене. Как синхронизировать – нужно смотреть по ситуации, наверно. Или составлять справочники так, чтобы в пределах одного элемента цена не менялась, или – увеличивать количество в БП. У нас УПП было, поэтому это все – в рамках предположения.

    (8)

    оптимально использовать не более 2х характеристик

    Да, возможно, Вы правы, у нас на практике больше не использовали.

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

    (9)

    Спасибо!

    По поводу актуальности, может, я не совсем поняла, что Вы имеете в виду, но в ЗУП с сотрудниками проще – уволился – значит, неактуальный. А с номенклатурой – ее, может, год не поступало с такой характеристикой, а потом снова появилась, и вот кто-то должен будет сразу лезть в этот элемент и выставлять актуальность? Кажется, не очень удобно.

    Reply
  11. Abadonna

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

    P.S. Например, 7.7, желаем у всех контриков завести один-разъединый договор с наименованием «Основной». Оно бы было замечательно, если бы в таблице договоров и появилась одна единственная запись. Однако — фигушки! Появится ровно столько записей, сколько есть контрагентов

    Reply
  12. YAN

    (10) Да насчет примера с регистрами в (9) неправильно написал в регистрах используется понятие «Активность» 🙂

    А насчет примера с номенклатурой, то заметил, что если пользователи продолжительное время не используют номенклатур (даже не обязательно год, а бывало и 3-4 месяца) то предпочитают заводить новую ! Тут естественно понятно, что нужно проводить работу с людьми, а если персонал регулярно меняется !?

    P.S.: Увы, но универсального решения ПОКА в таких ситуация нету, либо я их не знаю 🙂

    Reply
  13. Abadonna

    (12)

    о предпочитают заводить новую !

    Если бы только так! Они иногда просто предпочитают завести новую, даже не глядя, что такая уже была (и не три месяца назад, а всего пару дней) 😥

    Reply
  14. Alraune

    (11)

    А здесь ты прав! Поэтому и спорить не буду.

    (12)

    универсального решения ПОКА в таких ситуациях нет, либо я их не знаю

    Я тоже не знаю. Вообще, подозреваю, что универсального решения здесь на самом деле нет, а кто утверждает обратное, тот либо не в теме, либо нагло врет.

    Reply
  15. Alraune

    Вот, заодно вспомнилось: на форуме как-то обсуждали тему, в итоге как раз к свойствам и характеристикам пришли.

    http://www.infostart.ru/forum/forum14/topic33453/

    Reply
  16. Abadonna

    Посмотрел на форуме по ссылке: совершенно идиотская постановка задачи.

    Предположим, имеем три телевизора LG 19 LH2000 от поставщиков

    Рога и Копыта1, Рога и Копыта2, Рога и Копыта3. Пусть даже продавец четко знает, что продал именно телевизор от поставщика Рога и Копыта3, и ему первому деньги перечислены.

    Вполне резонный вопрос поставщика Рога и Копыта1:

    — А какого…непечатные слова… вы продали сначала телевизор этого…непечатные слова.., если мой был вам поставлен раньше?

    Reply
  17. Alraune

    (16)

    В принципе, да. С другой стороны, поставщикам вредно быть настолько в курсе того, что происходит в компании.

    А зачем абсолютно одинаковые телевизоры брать у разных поставщиков? Хотя это уже, наверно, вопрос к автору форума.

    Reply
  18. Abadonna

    (17)

    А зачем абсолютно одинаковые телевизоры брать у разных поставщиков?

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

    P.S. А если у них включен FIFO, то и сама проблема просто не может возникнуть

    Reply
  19. Abadonna

    Вдогонку к (11), сугубое IMHO:

    использование характеристик номенклатуры — лишние головняки и для проггеров, и для юзверей. Вряд ли цель тут оправдает средства

    Reply
  20. Alraune

    (18)

    Это я пыталась ему объяснить вначале. Но ключевая фраза у него была, наверно,

    Так мне сказал руководитель

    Интересно, а FIFO часто используется? Я практически нигде не встречала, все в основном ведут по среднему.

    Reply
  21. Abadonna

    (20)

    Интересно, а FIFO часто используется?

    На моей бывшей (она же — новая 😀 ) работе комплексуха 7.7 — FIFO.

    И задолго до меня уже было заведено.

    Reply
  22. mdzen

    (20) Учет по среднему в моей практике практически не встречается — все используют FIFO. Народ желает видеть реальную картину, а не усредненную — типа «средняя температура по больнице 36.7». 😀

    Reply
  23. Abadonna

    (22) Согласен. Для бухучета — по барабану, главное красиво отчитаться. А вот для упр. учета точную картину только через FIFO и можно получить. Особенно, если ЗП манагера напрямую связана с тем, что он продал.

    Reply
  24. Abadonna

    Кстати, Ирина, фирма как раз и торгует электротехникой, прям твой пример по проводам! 😀 Но у меня даже и в мыслях не возникало завести в конфе подчиненный справочник ХарактеристикиНоменклатуры ;). Хотя конфа настолько перекроенная, что никаким обновлениям уже не поддается и теоретически там можно мутить, что хочешь.

    Reply
  25. Alraune

    (24)

    Ну, что здесь ответить? Я не собираюсь в одиночку отдуваться за фирму 1С в плане целесообразности учета по характеристикам. Да и не говорила, что «используйте их все, и будет вам счастье», скорее, наоборот.

    Кто-то их использует — и доволен.

    Кто-то не использует — и тоже доволен.

    Кто-то использует — и недоволен.

    Четвертый вариант тоже возможен )))

    Reply
  26. CheBurator

    > Все равно какой-либо справочник/регистр будет увеличиваться – либо номенклатура, либо значения характеристик и свойств.

    ..

    мне кажется, что не это определяющее.. больше должна волновать скорость доступа к отчетым и актуалльным данным — а от размера может зависеть совсем слабо.. вот тут и интересно было бы посмотреть — насколько снижает «производительность» системы использование характеристик…???

    .

    почему серии сделали отдельно? а не тоже в характеристика?

    Reply
  27. Abadonna

    (25)

    Да и не говорила, что «используйте их все, и будет вам счастье», скорее, наоборот.

    А никто и не говорит, что ты говорила 😀 Это мы тут просто рассуждаем.

    (26)

    насколько снижает «производительность» системы использование характеристик…???

    А тут и смотреть не надо, и так ясно:

    1-й вариант: Провод МГШВ 2.0 красный в справочнике надо завести один раз, в любых документах выбрать — один раз

    2-й вариант: в каждом новом документе помимо «Провод» надо еще каждый раз выбрать, что он еще и «МГШВ 2.0 красный».

    А в ведомости по партиям так вообще надо выбрать, что он

    а) МГШВ

    б) 2.0

    в) красный

    Как я и сказал в (19):

    Вряд ли цель тут оправдает средства

    Reply
  28. anig99

    В общем и целом скажу, что практической оптимизации использования торговли — нет. Использование характеристик в штатном исполнении замедляет ввод документов…Вплоть до того, что в документах графа Характеристики имеет свойство «Пропускать при вводе», что увеличивает число нажатий клавиш и мышки…

    но по этому поводу у меня есть идейка…

    Reply
  29. Alraune

    (26)

    почему серии сделали отдельно? а не тоже в характеристиках?

    Снова вопрос не ко мне, а к 1С. Мне кажется, разработчики отдельных блоков программы работают изолированно друг от друга, и одни из них слабо представляют, что делают другие. Поэтому иногда то, что логично было бы видеть вместе, оказывается «разбросанным» по разным местам. Но это тольтко мое предположение, возможно, во всем этом есть какая-то стратегическая задумка.

    (27)

    Да, я об этом тоже думала. Возникла мысль: обычно справочники и документы заводят одни люди, а пользуются отчетами — другие. Настройки отчетов сохраняются, поэтому каждый раз их делать не надо. И этим «другим» более важно, чтобы было удобнее им, а сколько раз там в документах будет выбирать этим характеристики оператор, им все равно. Сколько времени формируется отчет — тоже все равно, не каждый же час он нужен.

    (28)

    но по этому поводу у меня есть идейка…

    Я надеюсь, в скором времени мы сможем об этом прочитать.

    Reply
  30. Abadonna
    Возникла мысль: обычно справочники и документы заводят одни люди, а пользуются отчетами — другие. Настройки отчетов сохраняются, поэтому каждый раз их делать не надо. И этим «другим» более важно, чтобы было удобнее им, а сколько раз там в документах будет выбирать этим характеристики оператор

    На НВО нет операторов, только менеджеры. Поэтому они и заводят элементы справочников, и документы набивают, и отчетами пользуются. Так что едины во всех лицах 😉

    P.S. И еще парочка именно электротехнических фирм (оптовых) — там тоже нет операторов, только бухи и менеджеры.

    P.P.S. Смысл иметь операторов лично я вижу только для рознично-мелкооптовых (накладных копеечных много), либо вам там, на Западе, деньги девать некуда 😀

    Reply
  31. Abadonna

    (26)

    почему серии сделали отдельно? а не тоже в характеристика?

    И тут все предельно ясно! Учет по сериям — печальная необходимость для бытовой техники, например. Хошь не хошь, а надо отразить какой именно телевизор этой модели продал. А вот Характеристики — дело вкуса

    Reply
  32. Alraune

    (30)

    А там были, и никто их не спрашивал, удобнее им с характеристиками или без них. Да, накладных было много, уже не помню, кажется, человека два занимались исключительно ими.

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

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

    Reply
  33. Alraune

    (31) А еще и серийные номера есть!

    Reply
  34. Ish_2

    (7) Смутил.

    2. По существу (что использовать?): тут просто метод «нос вылез-хвост увяз».

    Уменьшаем справочник Номенклатура, увеличиваем подчиненный справочник «ХарактеристикиНоменклатуры». Соответственно, при запросах появляется лишняя связанная таблица и т.д.

    Мой личный вывод: подчиненные справочники я еще с 7.7 недолюбливаю, вариант с использованием характеристик мне менее симпатичен.

    Никаких подчиненных справочников в 8-ке использование характеристик номенклатуры не требует. Они не нужны.

    Если сравнить два варианта ведения учета в одной и той же конфигурации , позволяющей использовать характеристики номенклатуры (ХН):

    1. ПРИ использовании ХН.

    2. БЕЗ использовании ХН и с «увеличенным» справочником номенклатуры.

    — то в п1. общий объем информации существенно меньше.

    Никакого выигрыша не дает п.2. и в скорости получения отчетов.

    Reply
  35. Abadonna

    (34)

    Никаких подчиненных справочников в 8-ке использование характеристик номенклатуры не требует. Они не нужны.

    О как! А на рисунке что? Галлюцинация?

    Reply
  36. Ish_2

    Ирина , я со «своим уставом» полезу к Вам в гости.

    Чем отличается песня от статьи ?

    Если в художественном произведении вывод :

    «думайте сами, решайте сами» — вполне оправдан — такой вывод хорошо поётся под гитару,

    То как ни крути , спеть «Выводы (не претендующие на истину)» значительно тяжелее.

    Это я к тому , что вывод в Вашей статье : «Дескать, как хотите…», на мой вкус, слишком размыт и портит предыдущее содержание.

    Оно, конечно, так безопаснее , но и менее интересно.

    Reply
  37. Ish_2

    (35) Извини , ошибся.

    Типовую УТ смотрел очень давно. Но, вообще говоря, организовать учет по харатеристикам номенклатуры можно и без подчиненного справочника «Характеристики номенклатуры».

    Reply
  38. Abadonna

    (37) +(35) Даже если бы его и не было, от этого ничего не меняется. Скулю (и любому другому типу данных) глубоко фиолетово, как и что ты сам себе называешь: хоть подчиненный справочник ХарактеристикиНоменклатуры, хоть регистр сведений ЗначенияСвойствОбъектов.

    Это всё — таблицы. И в них есть определенное количество полей и записей.

    Так что метод «нос вылез-хвост увяз» работает вовсю 😉

    Забавно: (38) писал, когда еще не видел твоих изменений в (37), тем не менее — в точку попал 😀

    Reply
  39. Abadonna

    Регистр сведений в 8-ке — голимый подчиненный справочник в терминологии 7.7, только еще и к тому же мульти-подчиненный.

    А вот и дополнительное соединение:

    Запрос.Текст = Запрос.Текст + »
    |ВНУТРЕННЕЕ СОЕДИНЕНИЕ
    | РегистрСведений.ЗначенияСвойствОбъектов             КАК ЗначенияСвойствОбъектов» + Индекс + »
    |
    |ПО
    | ЗначенияСвойствОбъектов» + Индекс + «.Объект = ХарактеристикиНоменклатуры.Характеристика
    | И
    | ЗначенияСвойствОбъектов» + Индекс + «.Свойство = &Свойство» + Индекс +»
    | И
    | ЗначенияСвойствОбъектов» + Индекс + «.Значение = &Значение» + Индекс +»
    |»;
    
    

    Показать

    Reply
  40. Ish_2

    (38) SQL-серверу действительно всё равно обращаться к какой таблице , если состав полей , индексы ,количество записей в них одинаковы. Я же толковал про то , что объем информации в случае использования харктеристик номенклатуры -меньше.

    Вместо записей в справочнике номенклатура:

    Провод зеленый медный

    Провод зеленый алюминевый

    Провод зеленый стальной

    Провод красный медный

    Провод красный алюминевый

    Провод красный стальной

    Экономнее , проще , гибче иметь

    одну запись в справчнике «номенклатура»

    и две характеристики

    «металл» со значениями : «сталь,алюминий, медь»

    и «цвет» со значениями : «красный , зеленый»

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

    Провод сечением 0.1

    Провод сечением 0.2

    Провод сечением 0.3

    Провод сечением 0.7

    и т.д.

    Reply
  41. Abadonna

    (40) Ой, не уверен, но мне кажется, что ты тут шибко ошибаешься (жаль не могу в скуле посмотреть).

    Мне кажется, что не будет всего два цвета в характеристиках, а будет

    Провод-владелец ЗЕЛЁНЫЙ

    Провод-владелец КРАСНЫЙ

    Равно как:

    Провод — владелец 0.1

    Провод — владелец 0.2

    …………………………………

    и т.д.

    Так что все «безобразия» из таблицы номенклатуры переползут в таблицу регистра.

    Reply
  42. Ish_2

    (41) Пусть даже и так . Т.е. при использовании подчиненного справочника.

    Запись, подчиненного справочника, содержащая два поля «Провод-владелец» и «зеленый» ,предполагаю, должна быть короче (меньше по объему), чем целая новая запись справочника Номенклатура :

    «Провод зеленый».

    Reply
  43. Abadonna

    (42) Пример из жизни:

    — Аркадий, займи 10 тысяч?

    — Вот ключи от квартиры, а там…

    Вариант1:

    — В гостиной, на пианино лежит 10 тыс. рублей, возьми

    Вариант2:

    — В гостиной, на пианино лежит 5 тыс. рублей, в спальне

    в трюмо, в третьем ящике сверху еще 2 тысячи, на кухне на холодильнике — еще 3…

    Тебе по какому варианту удобнее будет?

    Reply
  44. Ish_2

    (43) Мне удобнее по варианту 1.

    Но приходится иметь дело с тем , что есть : с квартирой Аркадия ( другие -то не дают !).

    А квартира Аркадия устроена не так , чтобы было удобно давать взаймы кому ни попадя,

    а так чтобы было удобно ему самому.

    Деваться некуда- пойду всё соберу : спасибо , добрый человек !

    Reply
  45. Abadonna

    (42)

    должна быть короче (меньше по объему),

    Меньше по объему (даже если и так) — кого оно сейчас волнует?

    А вот, что скорость доступа к информации при использовании характеристик упадет — тут даже и сомневаться не приходится!

    Reply
  46. Ish_2

    (43) Слушай , вопрос о том что оптимальнее с точки зрения быстродейтсвия и объема информации в общем случае вести всё-таки бессмысленно.

    Ты мне приведешь один конкретный пример — я тебе другой.

    И что будет быстрее еще тот вопросик.

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

    Конкретно же определить условия экспримента , а затем ответить на вопросы :

    ЧТО ?, НА СКОЛЬКО ? В КАКИХ СЛУЧАЯХ ? — будет тяжеловато.

    Главная же претензия к статье Ирины в том , что не обозначен главный смысл введения в 8-ке нового объекта ПланВидовХарактеристик и использования его в типовых конфигурациях :

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

    Reply
  47. Abadonna

    (46)

    В 7-ке не было такой возможности.

    Была 😉 Посмотри расчет зарплаты «Камин», где пользователь мог создать любой ему нужный справочник, не трогая конфу. Меня всегда умиляет, когда «чистые» восьмерочники

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

    Да! А для тех, кто гнет пальцы на 8.1, сообщаю, что сам уж давно на 8.2 работаю 😉

    Reply
  48. Ish_2

    (47) Ты о чем толкуешь ?

    Я сравниваю возможности платформ 7 и 8 . И говорю , что на уровне ПЛАТФОРМЫ появился новый механизм ПланВидовХарактеристик. И теперь появилось возможность у пользователя штатно без извращений добавлять новые аналитики.

    Ты же мне тыкаешь частным решением на уровне конфигурации :

    дескать , люди как — то там извратились.

    Конечно, мужчина ты авторитетный.. , но про Камин (прости, Господи!) давай лучше не будем. Несолидно , как-то.

    Reply
  49. Abadonna

    (48)

    Ты о чем толкуешь ?

    Я толкую о том, что, например, vip на «языке домохозяек» Basic пишет такие ВК, которые другим и на Си не снились. А про Камин: завтра увидит Арчибальд твой (48) — и поедом тебя съест 😀

    Reply
  50. Ish_2

    (49) Про vip’а — верю.

    Про Арчибальда — не верю. Он — хороший человек.

    Будет аккуратен в выражениях и конструктивен.

    Reply
  51. Abadonna

    За ЗУП не скажу, а 10 релизов ЗИК за год, со стандартной припиской «исправлены ошибки предыдущего релиза» — это уже наглый перебор.

    Reply
  52. Abadonna

    (48) Кстати, объясни мне, дремучему, что значит «на уровне ПЛАТФОРМЫ»?

    Если «люди как — то там извратились», значит ПЛАТФОРМА позволяет? Или не так?

    Reply
  53. anig99

    (31) а ещё даже без серий часто нужно указывать страну происхождения… Чтобы не плодить ГТД можно характеристиками обойтись….

    Характеристик всё-таки скорее болванка механизма, чем полноценный механизм… Нужно допиливать.

    (32) иногда бывает так, что может сделать конечно и один, но как-то давно уже возникла ситуация, когда один не справился, поэтому приняли решение увеличить штат… Налоговая — это вредная штука.

    Reply
  54. Ish_2

    (51) ЗУП — знаю как было дело. Но тебе не скажу. Вы с Арчибальдом начнете хихикать.

    (52) Одно дело платформа позволяет извратиться программисту , т.е. создать свой кодинг и дополнительные структуры,

    другое дело имеет штатный (встроенный механизм) .

    Ты вон в Delfi (никогда не использовал , кстати) наверняка имеешь готовые удобные структуры типа «Соответсвия» в 1с. Так ведь ? Или ты извращаешься и реализуешь такой функционал с помощью массивов , например ?

    Reply
  55. Alraune

    (46)

    Главная же претензия к статье Ирины в том , что не обозначен главный смысл введения в 8-ке нового объекта ПланВидовХарактеристик и использования его в типовых конфигурациях :

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

    С претензией согласна.

    Reply
  56. ПланВидовХарактеристик к Характеристикам номенклатуры не имеют отношения.

    Это подчиненный справочник, как уже говорили в обсуждении.

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

    А вот использование свойств раздувает базу довольно таки сильно.

    Reply
  57. gaglo

    (55) — зря согласна; претензия к статье не имеет отношения; см. 56;

    Про характеристики номенклатуры, в том виде, как они реализованы в УПП — удобство использования сомнительно. Лично я считаю, что на характеристики следует выносить лишь несущественные параметры номенклатуры, которые тем не менее охота (зачем-то?) учитывать. А это очень зависит от самой номенклатуры.

    Случай с проводом — сечение и цвет — так вот сечение провода всегда существенно, от него зависит допустимый ток, брать провод в 10 раз толще необходимого нормальный клиент не будет. А вот цвет… Для монтажного провода и он весьма важен: принято, что черный — земля, красный — плюс и т.д. Для силового кабеля толщиной в руку, который еще и в землю закопают — цвет ни фига не важен, но и зачем его учитывать — непонятно.

    У нас на фирме пытались на характеристики вывести учет производителя — практически отказались, и учет бухтовки провода — есть характеристика «бухты 200м», так будьте добры с нее отгружать только кратно 200 м — пока держится, но путаница частая.

    Reply
  58. Alraune

    (57) Имелось в виду, что хорошая формулировка

    любое количество новых разрезов аналитики для ведения учета.

    а не только количество элементов справочника.

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

    Reply
  59. Арчибальд

    (48) Камин 2.0 — совершенно несолидно. Он только одним отличается от одноэсных зарплат: он работает. Во всем остальном — отстой.

    Но я полностью с тобой солидарен: если ты предпочитаешь иметь солидную программу — ЗУП тебе в руки и барабан на шею.

    Хотя… Сами-то одноэсовцы, похоже, считают отстоем платформу 8.1…

    Reply
  60. Bux2

    Вопрос по УПП.

    При проведении регламентного закрытия месяца расчет себестоимости реализованной продукции происходит в разрезе только номенклатуры? Или с учетом аналитики по характеристикам?

    Иными словами, себестоимость одной номенклатуры, но с разными характеристиками

    1- будет одинаковой или

    2- будет отличаться?

    У меня нет возможности проверить. Склоняюсь к 1-му варианту.

    Reply
  61. Alraune

    (60) Для бухгалтерского учета вариант 1 правильный. У проводок нет аналитики по номенклатуре, поэтому себестоимость будет считаться по единице номенклатуры в целом, без учета характеристик.

    Reply
  62. anig99

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

    Reply
  63. (58)

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

    Не-не, все нормально с исходным материалом, он нужен , полезен и востребован.

    Reply
  64. molot

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

    Reply
  65. climepost

    В нашей конторе при переезде бухгалтеров с «Бухгалтерия:7.7» и менеджеров с «Торговля и склад:7.7» в общую базу УПП механизм характеристик был просто спасением. В номенклатуру загрузили справочник номенклатуры и материалов из бухгалтерии, а в характеристики — всё, что не вошло в этот справочник из названий номенклатуры менеджеров. В результате:

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

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

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

    В-четвертых, упрощается ввод по строке наименований при заведении документов. Если есть (к примеру) 85 позиций, название которых начинается с одинакового слова, то ввод по строке – спасение оператора – невозможен. При характеристиках 85 позиций номенклатуры можно превратить в 16.

    Ну и, в-пятых, очень удобен механизм характеристик при ежедневной работе с отчетами.

    В общем, все счастливы.

    Reply
  66. vladen

    Хороша статья, но ответ на вопрос темы не дано 🙁

    «о целесообразности и границах его применимости. Здесь – попытка найти ответ на него»

    Лично я этим механизмом пользуюсь более 5 лет на различних предприятиях, так и не получил для себя окончательного ответа 🙁

    С одной стороны идея очень хороша. Но далеко не совершенна. например характеристика «сечение», в приведенном автором примере… Хорошо если мы именем определенный список сечений, но если у нас может характеристика принимать не дискретное (практически любое)… что делать? Клепать бесконечно новые элементы характеристики? ладно их хранение в базе, но заставлять пользователя постоянно их видеть, даже если эта характеристика давно не актуальна.

    В общем, лично мне очень не хватает характеристики типа «число», и механизма автоматического управление элементами значений характеристик.

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

    А вот если мы используем сечение в самом элементе номенклатуры, то получаем возможность на каждую номенклатуру задать дополнительное свойство. Таким образом получаем раздутый справочник номенклатуры, НО!, всегда можем пользоваться различными отборами. Например — остатки номенклатуры с сечением меньше 6 мм…

    Reply
  67. Nefertary

    (66) А кто мешает создать свойство объекта с типом число? В типе значения можно для него можно задавать простые типы данных — такие как строка и число

    Reply
  68. itar59

    Спасибо! Прекрасный материал. Даже мои юзеры поняли!

    Reply
  69. tango

    (66)

    «Лично я этим механизмом пользуюсь более 5 лет»

    «лично мне очень не хватает характеристики типа «число»

    … однако

    Reply
  70. Alik Moskva

    Спасибо, хорошая статья. вот только почему 1С не привязал «характеристику» к Услугам, могло получится замечательное решение, я это сделал и теперь услуга «Доставка товара» может использовать километраж. (добавлена как в УПП, так и КА)

    Reply
  71. Alraune

    (70) Спасибо и Вам. Насчет

    почему 1С не привязал «характеристику» к Услугам

    — так 1С много чего «не». Впрочем, возможно, дело в том, что услуга не хранится на складе, поэтому учет в разрезе характеристик для нее считается неактуальным.

    Reply
  72. vladen

    (67)

    Свойство объекта — может быть число. набор значений характеристик — всегда ссылка на отдельный справочник и управлять этим справочником со стороны пользователя очень неудобно. 😐

    (70)

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

    Reply
  73. hdman

    «лично мне очень не хватает характеристики типа «число» —

    Почему нет? -Есть!!!

    По умолчанию создается тип «Список значений», но никто не запрещает вам заменить его на стоку или число.

    например уменя в характеристику таким образов добавлен «Артикул характеристики» и «Примечение к характеристике.» которые являются строками.

    Пример

    «A 0156, .04, 25мм, 080, Комплект для фронтальных зубов»

    «строка», «знч из списка»,»знч из списка»,»знч из списка»,»Строка»

    Reply
  74. Bux2

    Ещё вопрос по характеристикам. Но уже в БП 2.0 (хоть тема и про УПП и УТ).

    Новое в БП 2.0 — доп. харакеристики в справочниках. НО в БП невозможно организовать учет в разрезе харакеритик по аналогии с УПП.

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

    И ещё пример: в документе «ПоступлениеТиУ» в табличной части невозможно выбрать несколько строк одной номенклатуры с разными характеристиками.

    Правльно поняла?

    Reply
  75. Alraune

    (74) К сожалению, с БП 2.0 не работаю пока, но посмотрела и пришла к такому же выводу.

    Причем у меня даже отбор по характеристике в отчете НЕ работает.

    Хорошо бы, конечно, еще кто-нибудь свое мнение здесь добавил.

    Reply
  76. Lokon

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

    Reply
  77. fomix

    Статья действительно обстоятельная и полезная, но «суть» остается в подъезде — что же оптимально использовать… Мнения разошлись, а практики маловато!

    Reply
  78. Alraune

    (77) Спасибо. А по поводу разошедшихся мнений — так у нас до сих пор даже на тему, что лучше — 7.7 или 8 — у многих мнения расходятся))

    Reply
  79. fomix

    (76) Lokon, А откуда грузить хотите?

    Reply
  80. Поручик

    (77) (78)

    что лучше — молоток или кувалда, что лучше — камаз или газель — у многих мнения расходятся))

    Reply
  81. Medvedik

    Как уже заметили, ответа «использовать или нет» в плане влияния на скорость работы — нет. Это… грустно 🙂

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

    Reply
  82. fomix

    (81) Medvedik, Спасибо за дельный совет!

    Reply
  83. kitminsk

    Хорошая, но уже устаревшая информация. Может кто соберется с силами и обновит для последней 11 версии?

    Reply
  84. svcoopers

    Направление «Характеристики номенклатуры» интересное и полезное. В любом случае, всегда можно выбрать вести их или нет.

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

    К недостаткам следует отнести отсутствие картинок на характеристики номенклатуры. Наконец, обмены с сайтами плохо переносят обмен с 1С, где используются такие характеристики. Кроме того, на сайт такие фотографии не попадают, т.к. их некуда было вставить

    Reply
  85. bsa28000

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

    Reply
  86. AlexO

    (16) Abadonna,

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

    Reply
  87. AlexO

    (17)

    А зачем абсолютно одинаковые телевизоры брать у разных поставщиков? Хотя это уже, наверно, вопрос к автору форума.

    да если в компании больше одного менеджера — это будет само собой получаться.

    Reply
  88. AlexO

    (19) Abadonna,

    использование характеристик номенклатуры — лишние головняки и для проггеров, и для юзверей.

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

    Ну разделили по характеристикам «Провод медный» и «провод серый». А вот нужно использовать кроме этого еще и реквизиты номенклатуры (всякие там артикулы, штрихкоды и прочее и прочее). И что — вести еще параллельно с учетом «обычной» номенклатуры учет «номенклатуры с характеристиками» со всеми дополнительными «реквизитами характеристик» артикул, штрихкод…

    Reply
  89. AlexO

    (20)

    Интересно, а FIFO часто используется? Я практически нигде не встречала, все в основном ведут по среднему.

    Партионный учет, где он нужен (а не подмена-обманка типа «партии» РАУЗ) — это прежде всего FIFO (раз LIFO отменили). А вот учет по средней — это уже РАУЗ, так любимый 1с.

    Reply
  90. AlexO

    (23) Abadonna,

    Для бухучета — по барабану, главное красиво отчитаться

    как это «по барабану»? а остатки на складах? а незавершенка? как без FIFO определите, что оно реально ушло и куда? и кому деньги платить в этом месяце?

    Reply
  91. AlexO

    (24) Abadonna,

    Хотя конфа настолько перекроенная, что никаким обновлениям уже не поддается и теоретически там можно мутить, что хочешь.

    Характеристики затем и введены в таком «мягком» варианте, чтобы без перекраивания конфы как-то разделить номенклатуру дополнительно по другим признакам, отличным от указанных в реквизитах.

    Но реальный учет по таким «реквизитам» — полный хаос. Так что туда лучше вписывать только те характеритиски, которые не влиют на учет, а только — на принятие решений и сортировку/посик номенклатуры по базе. Вот тогда механизм характеристик отрабатывает себя на все сто процентов 🙂

    Reply
  92. AlexO

    (26) CheBurator,

    почему серии сделали отдельно? а не тоже в характеристика?

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

    Собственно, в (27) Abadonna более детально описал схему «учета по характеристикам» — если все эти дополнительные поля перемножить на варианты различных расчетов, разные схемы учета и списания, то кроме усложнения «внесения инфо» на этапе введения документов в разы получим усложненные в десятки раз механизмы учета и расчета.

    Reply
  93. AlexO

    (40) Ish_2,

    Вместо записей в справочнике номенклатура:



    Экономнее , проще , гибче иметь

    одну запись в справчнике «номенклатура»

    и две характеристики

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

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

    Другое дело, чтобы «скрыть» лишние «описания», не нужные на данный момент для принятия решения, из поля зрения при просмотре справочника Номенклатура.

    Reply
  94. AlexO

    (66) vladen,

    Хорошо если мы именем определенный список сечений, но если у нас может характеристика принимать не дискретное (практически любое)… что делать? Клепать бесконечно новые элементы характеристики? ладно их хранение в базе, но заставлять пользователя постоянно их видеть, даже если эта характеристика давно не актуальна.

    Этого не будет никогда.

    Механизм характеристик — как он сделан, — подразумевает, что вы подставляете конкретную и окончательную характеристику, а не тип данных.

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

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

    Reply
  95. AlexO

    (69) tango,

    «лично мне очень не хватает характеристики типа «число»

    … однако

    (73) hdman,

    Почему нет? -Есть!!!

    никто не запрещает вам заменить его на стоку или число.

    Речь идет о ПЛАВАЮЩЕЙ характеристике, а не просто «тип число» или «тип строка».

    Если один менеджер введет в эту характеристику «5» (или «фронтальный комплект»), то как другой найдет именно эту же характеристику, чтобы они были идентичны (вот возмет, и введет не «5», а «5,5», и не «фронтальный комплект», а «фронт.комп.»). И что вы в итоге найдете по таким характеристикам?

    Reply
  96. AlexO

    (81) Medvedik,

    Как уже заметили, ответа «использовать или нет» в плане влияния на скорость работы — нет. Это… грустно

    как это нет — вот же ответ (ранее прозвучавший немного в завуалированной форме от Абадонны):

    Чем больше аналитик — тем больше тормоза.

    Другое дело, когда есть какие-то преимущества от использования ХН, но есть и существенные недостатки наравне с преимуществами. И к чем пренебречь — вот это не понятно.

    А как изменится скорость обработки транзакций, если использовать дополнительное поле аналитики — это совсем не вопрос в рамках архитектуры 1с.

    Будет тормозить. И чем больше данных будут одновременно обрабатываться — тем больше будет тормозить.

    Reply
  97. Boudybuilder

    (20) Вот тут я с Вами не соглашусь!!!!

    Reply
  98. Boudybuilder

    (22) mdzen, достойный ответ. Какие могут быть середины? ДА и LIFO разве что при дефляции использовать! Только ФИФО!!! И не иначе!!!

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *