Длина номера фактуры, накладной больше 20 символов.

[Logger]

Добрый день.
Коллеги, недавно столкнулись с проблемой, что поставщики чаще стали присылать номера документов длиной больше 20 символов.
В аксапту не лезут.
С учетом того что в 1С , Oracle Aplications длина номера инвойса 50 символов (интересно сколько в сапе ?) то такая ситуация будет повторяться все чаще.
Как можно исправить ситуацию ?
Есть несколько вариантов.

1. «В лоб». Увеличить EDT NUM, FactureExternalId_RU до 50 символов.
+
А. просто и быстро модифицировать.
Б. Практически нулевая вероятность багов в кое после такого изменения.
-
А. Нереально долгая синхронизация базы. (у нас порядка 700 миллионов записей только в InventTrans, а работаем 24/7. Разрешенный простой- 2 часа в неделю). Вариант почти невозможный.
Б. Увеличить размер поля NUM– выпустить джина из бутылки – будут чаще заполнять длинные значения (причем не только для номеров документов. Наследники EDT NUM много где используются)- уменьшится скорость работы базы.
В. А если потребуется еще длиннее номер сделать ? (Интересно, кто встречал больше 50?) – Опять все переделывать и устраивать перепроверку и переколбас БД ?


2. «Компромиссный». Оторвать подветку EDT InvoiceId от NUM и увеличить до 50 символов. Также увеличить длину EDT FactureExternalId_RU до 50 символов.
+
А. Не такой большой рост базы и не такой долгий простой в работе как для варианта 1. (но все равно немало)
-
А. Все равно немаленькое время синхронизации БД.
Б. Все равно потери производительности при увеличении длины поля (хотя и не такие сильные как в варианте 1)
В. Дополнительные трудозатраты на перепроверку исходного кода – нет ли где то усечения номеров документов при работе (нередко EDT Num использовали как промежуточный тип для переменных в коде и.т.п.). Выше риск разных багов.


3. «Новое поле “Внешний номер”». Завести в табличках документов 2-й поле «Внешний номер». В который и писать значение от поставщика и использовать его при выгрузках во внешние системы при печати документов, при формировании книг покупок и продаж и.т.п.
+
А. Короткое время синхронизации базы.
Б. Нет рисков усечения номеров документов при работе
-
А. Все равно приличные трудозатраты на доработку кода, чтобы в нужных местах использовалось новое поле. (изменений наверно даже побольше чем в вариантах 1-2)
Б. Много неоднозначностей в каком случае какое поле использовать и как заполнить обычный InvoiceId (как усечь номер от поставщика, чтобы не получить кучу дублей)


4. «Я-шланг». Прикинуться шлангом. В аксапте ничего не менять, пусть пользователи сами что-нибудь придумают, усекут номер как хотят и потом разбираются с налоговой и с контрагентами.
+
…
-
…


Какие еще есть варианты и что лучше выбрать ? Кто как делал у себя на проектах ?

P.S.
Все больше начинаю любить суррогатные ключи.

P.P.S.
DAX 2009 Приложение RU5