огарничение длины поля 30 сиволов таблица товары

[dik_imported]

У нас этап внедрения MBS Navision 3.70. Пока внедренцы срочно доканчивают программу сдаточных испытаний я переношу данные из старых учетных систем в таблицы Navisoin. Особенно тяжко с куцыми полями таблицы Item поле Описание и Описание поиска. Классифицировать практически невозможно, приходится писать на птичьем языке, внедренцы говорят поле немоги трогать, когда прошу делать дополнительное поле длиной 200 символов чтобы хоть что то можно было впихнуть кривят лицо, я не могу аргументированно их заставить или убедить себя, тяжело уложить материалы (1000 позиций) в линейный список без каких либо попыток классификации и с именами по 30 символов. Хотел узнать как этот вопрос решен. может я неправильно использую функционал? или просто не привык к интерфейсу, подскажите п-та

[rootadmin]

Вообще, не должно быть проблем с дополнительным полем. А так, можно посоветовать использовать расширенные тексты и/или комментарии.

[Dzemon]

1. В ТЗ эта необходимость прописана?
2. Поле Описание поиска - индексное, он служит заменой поля Название для поиска. В принципе, в коде оно особо не используется, так что можно и расширить. А вообще лучше перейти на товарный классификатор. Но если вам необходимо хранить просто дополнительную информацию по товарам, то см. сообщение выше.

[rootadmin]

Цитата:

Сообщение от Dzemon

А вообще лучше перейти на товарный классификатор.

Простите, а это как? Просветите неграмотного

[dik_imported]

Б спасибо всем что откликнулись. В ТЗ стоит что у товаров могут быть 2 доп поля для классификации товарная категория, и товарная группа. ТОварная категория содержит товарные группы а товарные группы уже содержат сами товары. Если я даже классифицирую в этих полях товары ну допустим категория - "пленки" группа - "горячее ламинирование" а сами пленки имею названия AVERY GT 220x110 UI (это то что попадает в поле название). ТО когда проект менеджер формирует заказ он при отборе еще видит по группам и категориям что онтуда складывает, но в самом то заказа уже потом, он в позициях видит только вот эту белиберду AVERY GT 220x110 UI. Расширенные тексты там (в форме заказа) тоже не видны. Пользователи у меня после 1С и самописной БД на Access будут шокированы такими наименованиями. Проблема (если это проблема конечно) лежит на поверхности и у меня зародилось сомнение неужели ее никто не решал или я что то не так делаю что в 30 символов впихнуться не могу?

[dik_imported]

АГа, подскажите п-та поподробнее про товарный классификатор

[anatoliy]

решал эту проблему следующим образом

расширил в таблице Item поле Description до 200 символов.

и расширил этоже поле во всех связанных таблицах, т.е 32,5802, 37,39, 5741 и т.д. заняло часа 3 и в течении месяца ловля сообщений типа "переполнение при преобразовании из текст в текст", таких сообщений было от силы 5.

[rootadmin]

Цитата:

Сообщение от dik

Расширенные тексты там (в форме заказа) тоже не видны.

На самом деле видны, если выставить соответствующую галочку в карточке товара. Что-то типа "Автовставка расширенных текстов."

[rootadmin]

Цитата:

Сообщение от anatoliy

расширил в таблице Item поле Description до 200 символов.

я бы тоже так сделал (и сделал, правда для других справочников). Но внедренцы dikа это делать не хотят почему-то...

[Dzemon]

Цитата:

Сообщение от rutadmeen

Цитата:

Сообщение от Dzemon

А вообще лучше перейти на товарный классификатор.

Простите, а это как? Просветите неграмотного

Судя по постам, классификаторы уже используется.

to dik:
А увеличение поля Description чревато тем, что в документах оно не будет полностью печататься, т.е. придется те же счета-фактуры перекраивать под многострочное отображение наименований.

Название AVERY GT 220x110 UI больше подходит для Но. Товара, а Описание должно содержать что-то другое. В одной фирме я видел самодельный визард для "правильного" формирования длинного Описания товара и короткого Описания.
Думаю, вам стоит изменить принцип формирования Описания товаров.

[Тимур_imported]

На мой взгляд проблему нужно разделить на несколько частей:
1) поиск номенклатурной позиции;
2) отображение номенклатурных позиций в формах и в списках транзакций;
3) печать номенклатурных позиций в документах.

И решения рекомендую следующие:
(1) - поиск по многим полям. Без всякого иерархичного номенклатора это делается в стандартном Navision. Надо только четко отрубить пользователям всякое желание сохранить свои прежние привычки. Аргумент простой: повторение номенклатурных позиций в разных ветках. Можно и важно хранить признаки поиска из старой системы (код, например)
(2) - расширенные тексты. Отображается в формах вполне нормально и удобно для восприятия (особенно на мониторах с низким разрешением). Надо только в свойствах грида отрубить возможность плодить строчки простым перемещением по строчкам вверх-вниз.
(3) - дополнительное поле. Будет все печататься как укажите, только одна эстетичекая проблема: если длина наименования товара помещается в одной строке, то система все равно будет оставлять пустые строки на всю длину поля в отчетах.

[dik_imported]

Огромное спасибо за дельные советы. Давно не встречал такого отношения к болеющим проблемаими на форумах Я понял свою ошибку. Часть - это техническое решение. (нужно немного перемнить свое сознание под систему обозначений в Navision и применить ваши рекомендации), и досконально разобраться что где и как выводится и надо ли цепляться застарую форму представления справрочников ("сделай нам как было" 1С или MS Access), вторая - административная, написание четкой системы именования и классификации и требование ее от исполнителей. Одну битву уже удалось выиграть - это перевод сознания бухов и менелдеров отдела продаж от дерева к системе фильтров и плоских справочников (хотя в Access у них дерева не было ) Еще раз огромное спасибо за дельные советы,
PS внедренцев мы еще поддавим немного в нужную сторону

[apanko]

Тема не совсем новая, возражений не будет если я в ней спрошу?

Уважаемый Тимур

Цитата:

(2) - расширенные тексты. Отображается в формах вполне нормально и удобно для восприятия (особенно на мониторах с низким разрешением). Надо только в свойствах грида отрубить возможность плодить строчки простым перемещением по строчкам вверх-вниз.

Можете уточнить про функциональность расширенных текстов:
1. Можно ли расширенные тексты отображать в списке товаров?
2. Сложно ли вставить расширенные тексты в спецификацию, не повлечет ли это за собой каких-либо негативных последствий?

Про заявки покупки наверно можно и не заикаться, не стоит результат усилий.
Пусть справочник открывают и в нем смотрят (особенно если ответ на первый вопрос положительный). Хотя сомневаюсь...

АП