Добрый вечер коллеги. Второй раз за 3 года встает следующий вопрос на который я не могу найти внятного ответа: почему во всех документах можно вводить дробное количество, если номенклатура - "штуки". Можете рассказать каким образом эту проблему можно все-таки правильно решить, если реквизит количество - Число(13,3)? Проверять при выборе номенклатуры в табличной части её единицу измерения и прописывать ФорматРедактирования через условное оформление?
---
Я тоже пошел этим же путем, так как выяснилось, что через условное оформление "ФорматРедактирования" не поставить. В событии ПриРедактировании проверяю тип упаковки измерения и прописываю КвалификаторЧисла, с нужной разрядностью, через Новый ОписаниеТипа(), который добавляю в ОграничениеТипа. Если редактируется строка без "штук", то записываю в ОграничениеТипа - ДоступныеТипы. ПриИзменении - через Цел() отсекаю лишние разряды, если штуки. Плюс обработка проверки заполнения, если "проскочит" через кнопку типа "Подобрать" или копирование через буфер обмена.
---
почему во всех документах можно вводить дробное количество - ??? в чем вопрос?
---
Вопрос в том, что некоторые пользователи вводят вместо "1.000" - "1.032" на номенклатуру типа "телефон", "розетка", "лом", "лампа", "тумба", "гвоздь".
---
а если у вас есть 1шт, "коробка гвоздей" и вы израсходовали половину?
---
Это называется упаковка, там отдельная ед.изм. Кроме того гвозди, если память мне не изменяет, меряются в килограммах.
---
где то в кг. Зависит от фасовка. Бывает ящиками по 20 кг. А бывает маленькими коробочками в строительном магазине. По накладной они в штуках приходят.
---
Не будут же вам в магазине отгружать 1.5 коробочки и писать потом в накладной "1.5 штуки". Вам две коробочки продадут.
---
нам да две продадут. А потом в производство заберут целую. А вернут 0.5.
---
Предположим. Тогда может статься так, что 0.5 коробки окажется не ровно половина гвоздей, а с недостачей и следующее изделие попадет к клиенту без недобитых гвоздиков в местах где они быть должны (как и бывало с Икеей)
---
списали на хоз нужды. На ремонт. Никто их до грамма пересчитывать не будет. Но для порядка надо учитывать остаток.
---
Вопросов нет. Можно и в килограммах их все-же учитывать. Но блин, как с ломом то быть.
---
а с хлебом? 1 буханка это штука. Ты просишь продать половину.
---
В советском союзе так продавали, опять же во многих исторических сведениях нормы хлеба фигурируют в граммах. Значит и хлеб можно учитывать в килограммах, при желании. А вот как быть за закупоренными бутылками шампанского например?
---
если пользователь вводит 0.25 кувалды то что ему помешает ввести 5 кувалд при фактическом наличии двух штук.
---
Контроль остатков помешать может. Но, если уж и инвентаризация не помогает выявить кражу, то "рисовать" в программе можно что угодно.
---
Указывается новая единица Короб, для гвоздей базовая Ед Килограмм или Шт
Для короба указывается Коэффициент.
Например если в Короб помещается 20 килограмм, коэффициент 20, при базовой ед Килограмм для номенклатуры
Или 100 шт то Коэффициент 100 при базовой ед Шт. для номенклатуры
---
допишите в ПриИзмененииКоличества проверку на единицу измерения и округляйте как считаете нужным
---
Это не проблема. Меня волнует идеологическая сторона вопроса. Возможно есть типовые механизмы и я просто о них ничего не знаю. Хочу разобраться прежде чем лепить свои костыли.
---
в КА 1.1(УПП или УТ в т.ч.), в ед. измерения, для штук стоит Округлять до 0 по умолчанию.
UPD: Только что проверил, оно не помогает))
---
А в ERP где такое? Вот скрин.
---
это не в классификаторе, а в списке доступных Единиц для номенклатуры. То есть когда вы добавляете возможную ед для номенклатуры. К сожалению нет ЕРП или других баз под рукой
---
Ну вот у меня так выглядит подбор единиц измерения в номенклатуру
---
Думаю, просто решили не заморачивались в типовых с таким контролем. Потому что во-первых это дополнительная функциональность, а во-вторых потому что всегда найдутся те, которым "надо именно так".
---
В это с трудом верится глядя на документ ERP типа ЭкземплярБюджета, где заморочились так, что оставили после себя косяков разгребать с фоновым заданием на пол.года вперед.
---
Мы в самописке где есть штучные позиции (с точным весом) и есть весовые, просто добавили автоматический пересчет на штуки с предупреждением, исходя из предположения что в этом случае по ошибке указали вес вместо количества штук.
---
Доработать под себя можно многое. Довольно тяжело объяснить руководству такие вещи как дробное количество или ошибку округления при работе с данными из регистра себестоимости, когда они просят найти цену изделия через деления общей суммы остатка на общее количество остатка на выбранную дату. Потом умножают цену на количество в печатной форме и не получают ту стоимость изделия которая им нужна.
---
Значит и хлеб можно учитывать в килограмма
Так не учитывают же.
---
Ок, пофантазируем, что кризис добил РФ и теперь все ходят по талонам затариваться хлебом. 1С еще живет и ведет учет. Бухгалтер, который ведет учет в продуктовом магазине отвлекся на звонок из школы и набивает напротив проданной бутылки водки - 0.5 вместо 1.000 (бут). Че делать?
---
Кажется, в данном случае имеет смысл уточнить у ответственных/руководства, чтобы они сформулировали задачу, как должно быть в каждом конкретном случае.
---
(30)

Руководство поставило задачу. Я ищу способ её решения, начиная с понимания почему это работает так, а не иначе. Есть ли типовые механизмы ограничения. Понятно, что на каждую дырку затычку поставить сложно иначе зачем нужен будет вообще оператор, которого можно заменить ИИ. Наверняка я не первый, кто подобный вопрос задает. Что мешает сделать какую-нибудь настройку в номенклатуре или единицах измерения, которая подскажет в каком формате и с какими ограничениями можно вводить данные в поле, если оно содержит универсальный формат числа.
---
так может задать вопрос разработчикам? Или допилить самому. Решение универсальное. И дробное количество не такой уж и редкий случай.
---
Я не могу задавать вопросы разработчикам, так как формат подписки на ИТС оплаченный работодателем этого не позволяет сделать. Партнерский форум закрыт. Пилить я буду так и так похоже.
---
Потому что поле для ввода количества одно для всех единиц измерения. Доработать можно как угодно: разные поля и механизмы ввода для разных единиц измерения, или сложный механизм проверки/корректировки количества в зависимости от указанной единицы измерения. Но то, что нужно Вам, не обязательно нужно для всех остальных.
P.S Пофантазировать можно о чем-угодно. А если этот бухгалтер вместо единицы двойку поставит? Как система может знать, ошибся он или специально ввел? Или вместо водки хлеб продал? Или вообще ничего не ввел, и хочет, чтобы система поняла автоматически, что для кого и когда нужно ввести...
---
Думается, что вопрос о делимости или неделимости шт. следует решать для каждой номенклатуры отдельно. Например путем установки флага для номенклатуры или для самих единиц, если они подчинены номенклатуре.
---
Жаль только, что в типовых решениях нет готовых механизмов для этого.
---
Я бы по поводу дробных штук голову себе не морочил, это вопрос качества работы бухгалтера.
бухгалтер когда заводит документ обязан сверить итоговую сумму с документом.
---
Есть еще экономисты и производственники. Стоит у них норма - 102 этикетки на 100 готовых изделий. Они берут и списывают по норме - на 25 изделий 25,5 этикеток. Начинаешь выпытывать - а чего не по факту - выясняешь - считать испорченные некому/некогда/лень, а то клеят и данные вводят разные люди. А часто остатки такой мелочи такого порядка, что и задолбаешься считать с абсолютной точностью эти "штуки", проще на вес прикидывать (мелкие гайки) или рулонами (этикетки) считать.
---
Дела такую штуку )), путем ограничения типа для элемента управления при изменении данных текущей строки и все...
---
Я тоже пошел этим же путем, так как выяснилось, что через условное оформление "ФорматРедактирования" не поставить. В событии ПриРедактировании проверяю тип упаковки измерения и прописываю КвалификаторЧисла, с нужной разрядностью, через Новый ОписаниеТипа(), который добавляю в ОграничениеТипа. Если редактируется строка без "штук", то записываю в ОграничениеТипа - ДоступныеТипы. ПриИзменении - через Цел() отсекаю лишние разряды, если штуки. Плюс обработка проверки заполнения, если "проскочит" через кнопку типа "Подобрать" или копирование через буфер обмена.
---
Доработка не пригодилась. Причина дробного количества в моей ситуации оказалась в документе на основании которого создают другой документ. Т.е. ручной ввод отсутствует. На основании документа "Заказ переработчика" создавался "Отчет переработчика". Если в ТЧ заказа переработчика дублировались строки, то ERP применяя свой алгоритм вычисления каких-то норм умножала количество на эту норму. И ей все равно, штуки там или что.