Думаю, ваши проблемы имеют несколько "синтетический" оттенок (хотя, возможно, я и ошибаюсь). Если у Вас товар приходит каждый раз по принципу "скока Дядя Вася нашуровал в коробку", то нет смысла учитывать товар в коробках. Все равно в одной коробке его одно количество, в другой - другое. Имеет смысл его учитывать в штуках, и точка.
Если у вас даются скидки за размер партии, то определить размер партии для определения таблицы скидок как раз удобнее в штуках, если в коробках количество товара бывает разное. Все равно вы не сможете указать в документах "5 коробок", если во всех 5 коробках разное количество. ТАК ТМЦ УЧИТЫВАТЬ ЗАПРЕЩЕНО!
Если это вопрос удобства погрузки-выгрузки, то такие вещи можно указать в примечании просто в виде текста, например, "1 кг шариковых ручек в ассортименте - примерно пол-коробки из-под обуви".
Еще в транспортных накладных зачастую указывается "число мест". Этот параметр проставляет кладовщик по-факту, но не в колонке "количество", а именно в колонке "число мест". Потому как может просто взять пустую коробку из-под одного товара и насыпать туда другого. Но это вопрос даже не погрузки-выгрузки - это касается безопасности, всяких пропускных режимов и т.п. К скидкам это точно никакого отношения иметь не может.

Эту задачу можно реализовать "проводочной моделью" в любой бухгалтерской системе, которая позволяет настраивать пользовательские аналитики счетов (например, в ИНФИНе). Для складского учета выделяется несколько забалансовых вспомогательных счетов, при настройке которых указывается, что по ним ведется количественный учет. Допустим, на счете 0001 ведется учет в основных единицах измерения, на счете 0002 - в дополнительных, на счете 0003 - в дополнительных к дополнительным, на счете 0004 - в дополнительных к дополнительным к дополнительным. Когда товар приходуется или расходуется, то ОБЯЗАТЕЛЬНО делается проводка по счету 0001. По остальным счетам она делается в том случае, если в момент ее выполнения пользователь указал, что та же самая операция одновременно "оцениваться" в нескольких количествах. Совсем не обязательно подсовывать юзеру интерфейс, в котором он видит такие жуткие слова, как "дебет" или "кредит". Можно настроиь ввод кастомизированного документа, а проводки сформируются автоматом. Можно настроить отчеты (в том числе, параметризированные), которые будут показывать информацию, агрегатируя ее с нескольких счетов, в удобном для узверя виде.

В регистрах 1С можно настроить учет одновременно нескольких "ресурсов". Там это делается еще проще. Настраивается ОДИН регистр с НЕСКОЛЬКИМИ ресурсами "количество". Только клепать конфигурацию придется самим (или заказывать), поскольку в стандартных такие штуки не реализованы (по карйней мере, я не видел).

monolitС учётом вопроса довольно странно читать про проводки. Речь-то идёт об аналитическом учёте, а не о финансовом, не так ли ?Совершенно верно. Но проводки могут идти с нулевыми суммами, и акцент делаться именно на количественный учет. В ИНФИНе вы можете запустить отчет по нескольким счетам одновременно, аналитические разрезы которых настроенны на одинаковые справочники, и получить картину по нескольким счетам одновременно. Например, движения того же линолеума. Выбрали нужную расцветку и видите одновременно и метры, и рулоны.

monolitРасскажу, как такие задачи решаются в "Монолите"....
Тоже вариант.

И еще вариант - чем их больше, тем больше шансов выбрать подходящее решение. Опять же отталкиваюсь от возможностей ИНФИН. Можно настроить всего один счет (либо кастомизированный "документ", это как больше нравится). Несколько нижних аналитических уровней предусмотреть в виде ссылок на несколько разных справочников (в принципе, можно и на один справочник на разных уровнях, но в этом случае придется немного извернуться), в которых ведется учет приходных партий (что-то вроде "нумератора партий"), но в разных единицах измерения. Если справочники завязаны в иерархическую структуру, то на верхних уровнях иерархии указывается более крупная единица измерения, на нижних - более мелкая. Короче, нижние уровни иерархии рассматриваются как детализация верхних. Этот подход позволяет как использовать очень подробную детализацию (при этом не забыв, что для получения более детализированной картины понадобятся дополнительные усилия по вводу дополнителдьной информации), либо в отдельных случаях уходить от детализации, довольствуясь более обобщенной информацией.
Приведу пример по этому варианту. Приходит в одной приходной партии 5 рулонов линолеума, в каждой - по 50 п.м. На верхнем уровне иерархии помечается более "крупная единица" - рулоны, и что пришло их 5. Все 5 рулонов вешаются на одну партию. На следующем уровне раскрывается детализация - все эти 5 рулонов в итоге ОДНОВРЕМЕННО составляют 250 п.метров (5 рулонов * 50 п.метров). Впоследствии можно отражать расходы, ссылаясь на аналитики приходной партии. Но если мы из одного рулона отпустили 30 п.м., а из другого 40 п.м., то эта информация в итоге должна быть введена двумя расходами, в обеих указывается 0 рулонов и указанное количество п.м. После этого мы заходим в оборотку, либо аналитическую карточку и видим - у нас по прежнему было 5 рулонов, сколько п.м. в каждом мы уже не помним, но в сумме было 250 п.м. Потом было 2 расхода. Мы видим, какое количество п.м. в каждом расходе и какое количество рулонов в каждом из них. То есть, видим в каждом расходе по 0 рулонов и по 30 и 40 п.м. И видим текущий остаток - 5 рулонов и в итоге 180 п.м. Но сколько осталось в каком рулоне погонных метров - не знаем , хотя можем догадаться, внимательно разглядывая картину приходов и расходов.
Если нам захочется более детально учитывать информацию, чтобы знать, сколько именно метров в каком рулоне, мы каждый рулон оформляем отдельной приходной партией , для каждой из нее указываем - 50 п.м. Потом, когда делаются расходы, мы должны явно указывать уже конкретный рулон. И по каждому конкретному рулону можем посмотреть остаток. А также можем посмотреть остаток по всем рулонам сразу в п.метрах. Однако, возникнут дополнительные проблему - как идентифицировать рулоны, как их отличать друг от друга. Видимо, на каждый рулон придется вешать какой-то номерок, который проставляется в виде признака партии для каждого рулона. А также и в документах. Примерно так.
Если рулоны в свою очередь разложены по палетам, то... нужно определиться, что же вам нужно конкретно знать - сколько рулонов на палете, сколько метров в рулоне или сколько метров на палете. Сразу всю информацию иметь хотеть не вредно, но сомневаюсь, что реально она действительно кому-то может быть нужна. А усилий для того, чтобы она МОГЛА быть получена уйдет много. Причем, не столько на этапе внедрения, сколько на этапе эксплуатации.

Валентин КЯ вообще в шоке, когда система учета не может работать с различными упаковками товара.Возможно, Вы не совсем поняли специфику данного конкретного случая. Подавляющее большинство учетных систем может переводить одни единицы измерения в другие. Но при условии, если между этими единицами измерения имеется достаточно стабильная и неизменная связь. Наиболее стабильные связи: 1000м = 1км, 1000г = 1кг = 0.001т и т.п., которые выполняются для любой номенклатуры и партии. Менее стабильные связи: 1 контейнер с номенклатурой1 = 20 ящикам с номенклатурой1 = 200 коробкам с номенклатурой1 = 20000 штукам номенклатуры1 , поскольку эти соотношения зависят от номенклатуры. Но и такие связи в достаточной степени стабильны и дегко отслеживаются. А вот когда взаимосвязь между единицами измерения ИЗМЕНЯЕТСЯ ВО ВРЕМЕНИ (то есть, зависит от приходных/расходных партий), тогда уже начинаются сложности, связанные с тем, что В КАЖДОЙ ПРИХОДНОЙ И РАСХОДНОЙ ПАРТИИ НЕОБХОДИМО ПО КАЖДОЙ ОПЕРАЦИИ ПРИХОДА И РАСХОДА УКАЗЫВАТЬ ОДНОВРЕМЕННО НЕСКОЛЬКО РАЗНЫХ КОЛИЧЕСТВ В РАЗНЫХ ЕДИНИЦАХ ИЗМЕРЕНИЯ, потому что между ними НЕТ ПОСТОЯННОЙ ЗАВИСИМОСТИ и возможности автоматически получать из одной единицы измерения другую. Фактически - это необходимость учета НЕСКОЛЬКИХ никак не связанных между собой количеств по одной и той же операции (а не просто единиц измерения). Прочитайте внимательно информацию там, где приведены примеры с рулонами/метрами линолеума. Вести учет одновременно нескольких количеств действительно не все системы могут. В некоторых системах выкрутиться можно, сделав нескольких извилистых движений. В некоторых вопрос в принципе не может быть решен. Но не это самое главное. Главное ответить на вопрос - а действительно ли это до такой степени необходимо? Ведь вводить информацию ПО КАЖДОМУ КОЛИЧЕСТВУ при обработке КАЖДОЙ ОПЕРАЦИИ придется РУКАМИ, хоть какая там разавтоматизированная система не стой. Если ответ положительный, тады, конечно... :)

Popov76Реализовано очень просто в AVASystems.Господин Popov76, прекращайте гнать рекламу под видом ответов в тему. Последнее предупреждение Вам. Если Вы его проигнорируете, Вы будете забанены. Прежде чем возражать по существу, внимательно и еще раз прочитайте, что тут написано. А потому уже рассказывайте сказки про то, как у вас автоматически килограммы преобразуются в клилометры.