Задача поставленна как-то бредово. А зачем?

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

1. Если мне не изменяет память, можно задать пересчет единиц измерения вплоть до конкретной позиции номенклатуры. Т.ч., на мой взгляд, любая _осмысленная_ задача покрывается стандартным функционалом. Если, конечно, исключить тот дебильный момент, что в OeBS под код ед. измерения только 3 символа выделено, что создает проблемы если реально нужно очень много единиц измерения (например склад и коробки различного размера).
2. В ситуации исходной постановки задачи, я бы курочил форму и добавил туда поле кол-во в собственных условных единицах. Стандартное поле кол-во скрыл. При заполнении своего поля, менял бы поле кол-во. Все транзакции делать в одной, стандартной единице измерения.

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

Но в той ситуации и кастомизация ед. измерения ничего не давала. Все реализовывали через механизм партий (LOT) в OeBS с допиливанием системы (экранные формы движения. Пилили, что бы можно было выбирать сначала партию/трубу, а кол-во само подставлялось) + ядро модуля Shiping Execution (что бы отгрузка шла только целиком партиями и система не пыталась одну партию/трубу на разные вагоны погрузить).

В общем, IMHO, проблема чисто архитектурная. Без знания деталей предметной области, бизнес процессов у заказчика и принятых архитектурных решений на Вашем проекте, что то советовать по Subj невозможно!

Кроме "своего" пересчета из одних единиц измерения в другие, Вам нужно будет еще и в MTL_TRANSACTIONS как-то хранить исходные данные на основании которых был выбран такой пересчет и как-то протаскивать эти данные по всей системе. А для "протаскивания" через склад, что бы данные не потерялись, кроме партий (LOT) в стандартном Inventory и контейнеров/палет (LPN) в WMS что либо придумать сложно. А просто ОГП на транзакции не сильно помогут. Т.к. на складе все упадет в одну кучу и получится бардак. IMHO. Но это надо знать Ваш проект и бизнес процесс которые пытаетесь автоматизировать.