AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 09.02.2017, 14:37   #1  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
? Длина номера фактуры, накладной больше 20 символов.
Добрый день.
Коллеги, недавно столкнулись с проблемой, что поставщики чаще стали присылать номера документов длиной больше 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

Последний раз редактировалось Logger; 09.02.2017 в 14:40.
Старый 09.02.2017, 15:16   #2  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А разве время синхронизации базы разное если добавить поле / изменить текущее?
__________________
Ivanhoe as is..
Старый 09.02.2017, 15:21   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А разве время синхронизации базы разное если добавить поле / изменить текущее?
Угу - насколько я помню, в большинстве случаев, увеличение размера строкового поля отрабатывается БД немедленно. То есть - никакой перетасовки данных не происходит, просто где-то в системных структурах БД размер максимальной длинны для varchar-поля меняется. А старые структуры данных, в которых записи таблицы хранятся, при этом остаются валидными.

Вы бы там попробовали где-нить на полигоне в лоб задачу решить. Есть большие шансы что за пару часов управитесь. (Ну а если не управитесь - придется базу на полигоне из бэкапа поднимать. Не самое приятное задача, но за выходные явно поднимется...)
P.S. Размер базы тоже не должен сильно увеличиться, поскольку конечные пробелы все равно в БД не хранятся. Там все-таки VARCHAR, и аксапта их перед записью урезает как не необходимые...

Последний раз редактировалось fed; 09.02.2017 в 15:23.
За это сообщение автора поблагодарили: Logger (3).
Старый 09.02.2017, 15:29   #4  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
А разве время синхронизации базы разное если добавить поле / изменить текущее?
Да, и отличается очень сильно в случае когда меняется длина строкового поля.

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

Мы придумали обходной финт.
Если строковый EDT меняет длину, то собираем перечень табличек и полей на которые это повлияет, генерим для них SQL запросы вида ALTER TABLE ... MODIFY FIELD изменяя длину поля и обновляем также инфу в системной табличке SQL Dictionary
После этого аксапта при синхронизации ничего не трогает (мы ведь все сделали за нее).
Отрабатывает такая полуручная "синхронизация" мгновенно.

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

А поскольку номер документа это ключевое поле которой входит в первичный ключ и почти во все foreignKey то ...
Приходится кучу индексов пересоздавать и тратить на это много времени. 2 часов на всю базу не хватает.
Ну и плюс опять же размер индексов вырастать будет если реально будут 50 символов заполнять.

Последний раз редактировалось Logger; 09.02.2017 в 15:37.
Старый 09.02.2017, 15:35   #5  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
По законодательству длина номера документа у нас вроде не определена, но как подсказали мне друзья, для электронного документооборота внесена некоторая ясность.

http://www.garant.ru/products/ipo/prime/doc/71285094/
Цитата:
Наименование элемента Сокращенное наименование (код) элемента Признак типа элемента Формат элемента Признак обязательности элемента Дополнительная информация
Наименование товара (описание выполненных работ, оказанных услуг), имущественных прав (графа 1 счета-фактуры) НаимТов А Т(1-1000) О
ГАРАНТ.РУ: http://www.garant.ru/products/ipo/pr...#ixzz4YBso60L4

Цитата:
Сведения о платежно-расчетном документе (строка 5 счета-фактуры) (СвПРД)
Наименование элемента Сокращенное наименование (код) элемента Признак типа элемента Формат элемента Признак обязательности элемента Дополнительная информация
Номер платежно-расчетного документа НомерПРД А Т(1-30) О
ГАРАНТ.РУ: http://www.garant.ru/products/ipo/pr...#ixzz4YBtPoV5Y

Правда на скорую руку так и не разобрался в каком случае речь идет о номере СФ и сколько же он может быть длиной в электронном документообороте. 30 или 1000 символов.
И как с остальными документами дело обстоит.

P.S. Жаль форматирование таблички съехало в цитатах. - Смотреть лучше в документе по ссылке.
Старый 09.02.2017, 15:38   #6  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Если у вас реально уже проблемы с синхронизацией, пора делать обходную процедуру - запрет синхронизации через Акс, изменение структуры БД в SQL. На больших базах без этого никуда.
__________________
Ivanhoe as is..
Старый 09.02.2017, 15:41   #7  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Если у вас реально уже проблемы с синхронизацией, пора делать обходную процедуру - запрет синхронизации через Акс, изменение структуры БД в SQL. На больших базах без этого никуда.
Так так и сделали.
Но чую, что в данном случае даже упомянутая мной схема не уложится в 2 часа, потому что поля почти все индексированные.
Старый 09.02.2017, 15:48   #8  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Logger Посмотреть сообщение
Но если поле для которого хотим поменять длину индексировано, то БД посылает на попытке изменения длины, приходится грохать индекс, менять длину и заново строить индекс.
А как именно посылает ? Просто любопытно (поскольку в индексах при таком изменении тоже вроде бы не надо ничего менять).
И какая у вас версия SQL ?
Старый 09.02.2017, 17:05   #9  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от fed Посмотреть сообщение
А как именно посылает ? Просто любопытно (поскольку в индексах при таком изменении тоже вроде бы не надо ничего менять).
И какая у вас версия SQL ?
Вот так
Цитата:
ORA-30556: functional index is defined on the column to be modified
https://community.oracle.com/thread/2343555

Поговорил с DBA. Проблема в функциональных индексах. Без них все ок. Попробовал сам, действительно без функциональных индексов все ок.
Запрос такой
X++:
ALTER TABLE TESTTABLE MODIFY TEXTFIELD NVARCHAR2(50)
Версия 12.1.0.2.0
За это сообщение автора поблагодарили: fed (1).
Старый 10.02.2017, 09:17   #10  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Цитата:
Сообщение от Logger Посмотреть сообщение
Правда на скорую руку так и не разобрался в каком случае речь идет о номере СФ и сколько же он может быть длиной в электронном документообороте. 30 или 1000 символов.
И как с остальными документами дело обстоит.

P.S. Жаль форматирование таблички съехало в цитатах. - Смотреть лучше в документе по ссылке.
Судя по этому (из приложения в ссылке):
Цитата:
Порядковый номер счета- фактуры (строка 1 счета- фактуры), документа об отгрузке товаров (выполнении работ), передаче имущественных прав (документа об оказании услуг) НомерСчФ А Т(1-1000)
- номер до 1000. (где они такую траву берут?)
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании.
Старый 10.02.2017, 09:29   #11  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
362 / 542 (19) +++++++
Регистрация: 08.08.2007
Записей в блоге: 1
А сколько сейчас времени у вас тратится при варианте пересоздания индексов, хотя бы порядок, если конечно пробовали? Просто при временных затратах в десятки часов, вариантов вроде не так много остается. В стандарте вроде как FactureExternaId_RU имеет длину 30 символов, у вас также ?

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

Цитата:
Б. Много неоднозначностей в каком случае какое поле использовать и как заполнить обычный InvoiceId (как усечь номер от поставщика, чтобы не получить кучу дублей)
А в случае если усекать номер, номерную серию внутри AX не вариант использовать, или номер должен быть максимально похож на реальный ?
__________________
Sergey Nefedov
За это сообщение автора поблагодарили: Logger (3).
Старый 10.02.2017, 10:11   #12  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от SRF Посмотреть сообщение
А сколько сейчас времени у вас тратится при варианте пересоздания индексов, хотя бы порядок, если конечно пробовали?
Если в табличке порядка полмиллиарда записей то порядка 10-20 минут на один индекс. А индексов может быть несколько и табличек тоже. В общем по ощущениям - это не на 2 часа остановки, а часов на 6. Но это грубая прикидка.

Цитата:
Сообщение от SRF Посмотреть сообщение
В стандарте вроде как FactureExternaId_RU имеет длину 30 символов, у вас также ?
Да также. У нас длины сейчас все по стандарту.

Цитата:
Сообщение от SRF Посмотреть сообщение
А в случае если усекать номер, номерную серию внутри AX не вариант использовать, или номер должен быть максимально похож на реальный ?
Я думаю, что желательно чтобы он был похож на реальный.

Поговорили еще с DBA. Мне все больше нравится вариант 1.
Возможно что нить придумаем как сделать.
Как вариант - пропатчить ядро чтобы аксапта научилась работать с БД в регистронезависимом режиме без всяких функциональных индексов. Тогда и проблемы не будет никакой. Длины полей увеличатся легко.
Старый 10.02.2017, 16:51   #13  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Logger Посмотреть сообщение
Если в табличке порядка полмиллиарда записей то порядка 10-20 минут на один индекс. А индексов может быть несколько и табличек тоже. В общем по ощущениям - это не на 2 часа остановки, а часов на 6. Но это грубая прикидка.
Не знаю, как в Oracle, а в MS SQL можно параллельно индексировать разные таблицы. Нельзя разные индексы в одной таблице, но в разных таблицах - вполне. В разных соединениях, разумеется...

Т.е. условно вместо 20 минут на одну таблицу + 20 минут на другую итого 40. Получите 20 минут на обе.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: Logger (1).
Теги
factureexternalid, invoice, invoiceid, num, электронная отчетность, электронный сф

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
System.Net.Mail.MailMessage и Subject длиной больше 100 символов Damn DAX: Программирование 0 09.02.2011 19:59
Длина строки range - 250, 1000 или больше Logger DAX: Программирование 13 19.09.2010 14:36
"Испортились" номера в таблице договоров Shirmin Oleg DAX: Администрирование 3 21.11.2005 12:27
Печать накладной и счёта-фактуры через AxaptaCOMConnector mpogorelov DAX: Программирование 0 25.02.2005 18:28
при построении перекрёстных ссылок выдаётся сообщение об ошибках mmmax DAX: Программирование 10 21.01.2005 12:42
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 23:30.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.