|
05.03.2008, 18:38 | #1 |
Участник
|
Расширил поле название в таблице поставщики (соответственно поставщики и налоговые органы) до 150.
Столкнулся с проблемами в денежные средства - журнал платежей, журнал платежей, Журнал банковских платежей Фактически таблицу приемник исправил, прямо в таблице можно вносить записи с нужной длиной. При работе из формы позникает переполнение при приообразовании типов.... Прошу помочь советом и местом гре править |
|
06.03.2008, 09:44 | #2 |
Moderator
|
Ну далее Вы будете сталкиваться с проблемой почти во всех формах . В системе есть много мест где обрабатывается значение поля Name и часто приходится расширять и значения переменных во многих метах.
Так что изменять значение поля Name, мне кажется, не очень хорошие идеей, ну или трудоемкой..... Обычно я расширяла поле Name 2. Это приносить меньше хлопот. Вариант добавить еще одно поле в т. Поставщик и использовать значение этого поля в тех отчетных формах, где это необходимо. Мне кажется с длиной названия мучаются многие, только почему Microsoft не сделает ничего централизовано? |
|
06.03.2008, 09:44 | #3 |
Участник
|
Править придется во многих местах. Включите Debuger и просмотрите на какую переменную ругается.
Лучше бы сделали дополнительное поле для длинного названия поставщика. |
|
06.03.2008, 10:56 | #4 |
Участник
|
Автор. Меняйте обратно длину поля, корректируйте данные, ищите другие пути решения. Сделать дополнительное поле, как советовал Andreblack, будет нормально.
Не надо искать, где еще придется менять длины, руки устанут. Добавляйте новое поле. |
|
06.03.2008, 11:37 | #5 |
Участник
|
Всем спасибо! Вразумили меня конкретно...
|
|
06.03.2008, 11:48 | #6 |
Участник
|
Я все же советую расширить до 150 длину родного поля и всех связанных полей/переменных.
Таблица Field (форма 7702) и Developers Toolkit помогут Вам найти все места где используется Vendor.Name. В противном случае от Вас могут потребовать заменить код в тех местах где используется Vendor.Name на новое поле - что по трудозатратам несопоставимо с простым увеличением длмны поля. |
|
06.03.2008, 12:15 | #7 |
Участник
|
Хм... мне кажется или в карточку поставщика не выведено поле Name 2
|
|
06.03.2008, 13:34 | #8 |
Moderator
|
не кажется
не выведено так же как и Address 2. Кстати, с адресом может быть такая же проблема и придется его увеличивать..... С названиями товара тоже. |
|
06.03.2008, 16:18 | #9 |
Участник
|
Мне кажется запаритесь менять по всему коду размерности полей, коды, суммы названий которые превысят длину переменной, учетные процедуры, отчеты, триггеры журналов...
Разве что по ходу. Бамц- выскочила ошибка. Поправил, дальше ждешь.... Так долго можно править.... Много косвенных вещей - например наименование поставщика при учете может попадать в запись финкниги... |
|
06.03.2008, 16:26 | #10 |
Moderator
|
Цитата:
Я всегда увеличиваю поля Name 2 и Address 2 большинстве отчетов в качестве названия и адреса используется сочетание полей Name + Name 2 и Address и Address 2, но не везде.... В отчетах таких косяков многова-то.... + еще кодюнит который формирует книгу покупок-продаж.. там переменные живут Больше больших проблем не припомню... возможно прихолось править еще где-то когда высткакивало... Но это не сильно напрягало.... А какие еще есть идеи как хранить такие длинные названия поставщиков и их адресов.... |
|
06.03.2008, 16:28 | #11 |
Участник
|
Цитата:
Но я лично не решился бы. Представьте что Вы уволились и на каком-то коде выскочила ошибка переполнения. Оно надо чтобы потом дергали? Или чтобы коллега ругался пришедший вместо Вас |
|
06.03.2008, 17:34 | #12 |
Moderator
|
Цитата:
А Вы то как делаете? Или у Вас бухгалтерия не хочет видеть полное название поставщиков? |
|
06.03.2008, 17:53 | #13 |
Участник
|
Первый раз будете мучиться.
Потом будет протягивать на автомате за два часа . Заодно и методологию Навижн глубже поймете Упрощенный алгоритм. 1. Увеличиваем поле Description в фин. журнале 2. Увеличиваеи поле Description в книгах (17 и 23). 3. Увеличиваем Бла-Бла Vendor Name в документах и учтенных документах. 4. На разработческой базе прибиваем (для тех кто умеет /меняем тип на boolean поля Vendor.Name, комплилим все объекты, находим ошибки - при необходимости увеличиваем длину, возвращаем Vendor'у правильный Name, компилим снова. Дальше останутся проблемы с длиной полей/переменных в которые пишутся увеличенные на шагах 1-4 поля. Но как показывает практика их достаточно немного и из критичных - только в учетных кодеюнитах. PS. Если на проекте спокойствие программиста приоритетнее задач бухгалтерии - тогда конечно увеличивать длину не стоит |
|
06.03.2008, 18:14 | #14 |
Участник
|
Зачем увеличивать поле Описание в журналах и учтенных операциях? Для того, чтобы хранить полное наименование поставщика в операции, где и так есть его номер? При этом занимая лишнее место в базе? С точки зрения строения баз данных - ересь какая-то. Поле Описание в журналах нужно для того, чтобы снабдить операции какими-то комментариями. То, что туда по умолчанию в некоторых случаях копируется наименование поставщика - ну, просто раз есть поле, почему бы ему не быть заполненным чем-то содержательным. Так что - однозначно расширять Название 2!
|
|
06.03.2008, 19:18 | #15 |
Участник
|
2Milk.
Дело в том, что после учета надо видеть данные, с которыми документ учитывался, актуальные на ТОТ момент. Это навижен, Милк. И это правильно, Милк -) 2Автор. Только не говорите нам, что пользователи заказали новый отчет (адна штук), в котором нужно отображать полное наименование поставщика -) |
|
07.03.2008, 10:59 | #16 |
Участник
|
romeo, а вам не кажется, что актуальные на тот момент данные достаточно хранить в учтенных документах? А расширять поля, чтобы хранить их еще и в операциях - немного странная роскошь? Давайте в них хранить еще актуальные на тот момент адреса, телефоны и т.д. Это будет Navision, Ромео?
|
|
07.03.2008, 11:35 | #17 |
Участник
|
2Милк. Насчет книг согласен. Невнимательно читал.
|
|
07.03.2008, 15:00 | #18 |
Участник
|
Цитата:
Сообщение от Vladimir-2008
Расширил поле название в таблице поставщики (соответственно поставщики и налоговые органы) до 150.
Столкнулся с проблемами в денежные средства - журнал платежей, журнал платежей, Журнал банковских платежей Фактически таблицу приемник исправил, прямо в таблице можно вносить записи с нужной длиной. При работе из формы позникает переполнение при приообразовании типов.... Прошу помочь советом и местом гре править |
|
08.03.2008, 11:44 | #19 |
Участник
|
Интересная дискуссия. Напишу свою точку зрения
Расширять поля неправильно в принципе. Используйте новые поля, комментарии, расширенные тексты (для товаров) - но не нужно залезать в Систему и все подряд там менять. Люди не просто так сделали именно 30 символов, а не 250. Гораздо проще объявить название из 30 символов внутренним в Системе, добавить новое поле на сколько хотите и его выводить в какие-то внешние отчеты. Для внутренних отчетов организации больше 30 символов не для товара, не для поставщика, не для клиента НЕ нужно. Мест где нужно большое название на порядок меньше, чем тех где надо будет вносить исправления. Уверен, что и времени по такому пути у вас уйдет меньше и ошибок допустите меньше и не поламаете ничего. Очень интересно, как потом придется переходить на новые сервис-паки, например, опять все переписывать? |
|
11.03.2008, 09:52 | #20 |
Moderator
|
Цитата:
Сообщение от Borr
Расширять поля неправильно в принципе. Используйте новые поля, комментарии, расширенные тексты (для товаров) - но не нужно залезать в Систему и все подряд там менять. Люди не просто так сделали именно 30 символов, а не 250.
Гораздо проще объявить название из 30 символов внутренним в Системе, добавить новое поле на сколько хотите и его выводить в какие-то внешние отчеты. Для внутренних отчетов организации больше 30 символов не для товара, не для поставщика, не для клиента НЕ нужно. Мест где нужно большое название на порядок меньше, чем тех где надо будет вносить исправления. Уверен, что и времени по такому пути у вас уйдет меньше и ошибок допустите меньше и не поламаете ничего. Очень интересно, как потом придется переходить на новые сервис-паки, например, опять все переписывать? Так как если я добавляю новое поле мне придется переписывать ВСЕ отчетные формы + механизмы вывода информации в них. Ведь в большинстве форм уже прописано формирование название или адреса как Name + Name 2. + новое поле надо еще вытащить на экрнанные формы и пр. и пр. Так что при переходе на новый сервиспак еще не известно, что легче и проще выйдет. И что делать с кучей коротких полей? |
|