Навижен сильно недоделан (С) Gmc. Почему? - Страница 3 - NAV: Функционал

artkashin · 07.05.2008, 15:39

Защита от кодера-дурака должна быть, но это не проблема навижн, а проблема управления проектом.
Другое дело, что программных механизмов контроля таких действий среда разработки не предоставляет.
Структура кодюнитов построена так, что не залазить в них, при добавлении новой "фичи", просто нельзя. Даже новое поле не всегда достаточно просто завести в учтенной и неучтенной строке, потому что вызова TRANSFERFIELDS в учетном кодюните может быть не предусмотрено. Просто при построении системы этот пункт явно игнорировался.

HLS · 07.05.2008, 15:40

To Дуд: если даже я и новичек, то это не значит что я несу чушь...

Если вы внимательно прочли мою тему, то должны были понять, что я допускаю ситуацию, когда "простое" проставление галочки "Open" относительно поля "Remaining Quantity" может вызвать несоответствие где-либо, для каких-либо (неизвестных мне) ситуаций... Просто когда имеете место дело с таблицей 32 в которой > 20 млн. записей, лишний раз стоит убедиться, не так ли?

**Yoil** · 07.05.2008, 15:47

Цитата:

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

To Дуд: если даже я и новичек, то это не значит что я несу чушь...

Цитата:

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

А нужно чтобы дороботки надобились по максимуму не в "стремных" CU, дорабатывайте что хотите - только не в самом ядре

Цитата:

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

Структура кодюнитов построена так, что не залазить в них, при добавлении новой "фичи", просто нельзя. Даже новое поле не всегда достаточно просто завести в учтенной и неучтенной строке, потому что вызова TRANSFERFIELDS в учетном кодюните может быть не предусмотрено.

Еще раз простите, но Вы таки несете чушь.

HLS · 07.05.2008, 16:08

To Дуд:
Я имел в виду идеальный случай, то-что я написал по этой теме, можете считать как некое размышление, со множеством допущений, по поводу того - как можно было-бы сделать навик более стабильным и свободным от глюков. У вас есть другое?
Зачем объявлять мое рассуждение чушью, если не имеете своего?

И простите - еще раз..

Если вы внимательно прочли мою тему (про галку "Open"), то должны были понять, что я допускаю ситуацию, когда "простое" проставление галочки "Open" относительно поля "Remaining Quantity" может вызвать несоответствие где-либо, для каких-либо (неизвестных мне) ситуаций... Просто когда имеете место дело с таблицей 32 в которой > 20 млн. записей, лишний раз стоит убедиться, не так ли?

HLS · 07.05.2008, 16:21

Цитата:

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

Защита от кодера-дурака должна быть, но это не проблема навижн, а проблема управления проектом.

Согласен полностью. Только изменил бы слово "дурака" на "ивана-дурака", и добавил бы - "защита от внедренца-дурака". А в России таких не мало! Вспомним сколько у нас продается дипломов с квалификацией инженер-программист. И проблема, мне кажется, особенна именно для России, если даже крупные и уважаемые интеграторы допускают такие ошибки при внедрении, что хоть плачь хоть смейся (через некоторое время)... тут наше "на авось" - не катит.

**GalaM** · 07.05.2008, 16:22

Цитата:

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

И поймите я - не сторонник того чтобы запретить править объекты! Просто править нужно по принципу 7 раз отмерь 1 раз отреж. очнь часто это правило - особенно начинающими "чудо-программистами" - студентами, нанятым за 30000 тыщ - не соблюдается.... Они же себя считают мега-монстрами программирования!

Я совсем не согласна, что надо что-то закрывать в системе.
Если NAV поставляется с открытым кодом, так надо весь код открыть, а не частично. И пусть вся ответственность о том, кто и что делает лежит на авторе изменений. Если компания хочет экономить, нанимая на работу студентов, то это не проблема отдельных пользователей.

Ведь сейчас нельзя даже простую ошибку поправить(под клиентской лицензией, которая разрешат в править объекты, кроме тех, что относятся к учетным).
Например, в отчете кассира не выволится поле Name 2 организации, а пользователь ее исправить не может, так как этот отчет ставит номер напечатанной страницы в т. 272, которая относться к учетным.

список операций по договорам нельзя просмотреть, так как отсутсвуют косвенные права доступа......

Приходится образащаться к партнерам, которые удивляются (как будто я первая, кто образается с этой ошибкой), проверяют ее, исправляют, высылают объект..... Ну в общем в счет за такую работу можно выставить 0,5 - 1 ( в зависимости от квалификации заказчика и совести партнера)... И что же после этого клиент должен думать о всей этой чудо системе (и о самом НАВ и способе ее продажи ????). А ведь исправить ошибку подобного рода можно за несколько секунд.....

Поэтому я против всяких ограничений подобного рода, раз код открытый и можно вносить модификации, то и пусть заказчик сам играет с системой как хочет. Хуже от этого никому не будет.

. Ведь проверить как что изменил заказчик и к чему это привело (ну если заказчик захочет-таки предявиь претензии кому-либо) элементарно даже студенту....

Ну а простым пользователям данные конечно нельзя править и студентам то же.....
Все, что я говорила выше должно касаться только к доступу через программные объекты

artkashin · 07.05.2008, 16:24

Цитата:

Сообщение от Дуд

Еще раз простите, но Вы таки несете чушь.

Где чушь? Вы никогда не добавляли записи типа ValueEntry.NewField := ItemJnlLine.NewField? Там, где достаточно было ValueEntry.TRANSFERFIELDS(ItemJnlLine) портянки кода вида:

Код:

  ValueEntry."Drop Shipment" := "Drop Shipment";
  ValueEntry."Reason Code" := "Reason Code";
  ValueEntry."Return Reason Code" := "Return Reason Code";
  ValueEntry."External Document No." := "External Document No.";
  ValueEntry."Document Date" := "Document Date";
  ValueEntry."Gen. Bus. Posting Group" := "Gen. Bus. Posting Group";
  ValueEntry."Gen. Prod. Posting Group" := "Gen. Prod. Posting Group";

romeo · 07.05.2008, 16:37

Цитата:

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

Где чушь? Вы никогда не добавляли записи типа ValueEntry.NewField := ItemJnlLine.NewField? Там, где достаточно было ValueEntry.TRANSFERFIELDS(ItemJnlLine) портянки кода вида:

Код:

  ValueEntry."Drop Shipment" := "Drop Shipment";
  ValueEntry."Reason Code" := "Reason Code";
  ValueEntry."Return Reason Code" := "Return Reason Code";
  ValueEntry."External Document No." := "External Document No.";
  ValueEntry."Document Date" := "Document Date";
  ValueEntry."Gen. Bus. Posting Group" := "Gen. Bus. Posting Group";
  ValueEntry."Gen. Prod. Posting Group" := "Gen. Prod. Posting Group";

Не очень удачный пример. TRANSFERFIELDS переносит по айдишникам полей. Наверное головоломкой было бы поддерживать соответствие айди в одной книге и десятках документальных таблиц, которые в нее что-то пишут. Пришлось бы резервировать поля ... Я понимаю учет транзитов ... Но с книгой пример не оч. удачный.
В целом как аргументирование того, чтобы править стандартные "серьезные" юниты - прокатит. Но лучше было бы привести пример протаскивания какого-либо нового поля в какую-либо из книг. Тут хоть ничего сложного и нет, но юнит тронуть придется.

artkashin · 07.05.2008, 16:46

Цитата:

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

Не очень удачный пример. TRANSFERFIELDS переносит по айдишникам полей. Наверное головоломкой было бы поддерживать соответствие айди в одной книге и десятках документальных таблиц, которые в нее что-то пишут. Пришлось бы резервировать поля ... Я понимаю учет транзитов ... Но с книгой пример не оч. удачный.
В целом как аргументирование того, чтобы править стандартные "серьезные" юниты - прокатит. Но лучше было бы привести пример протаскивания какого-либо нового поля в какую-либо из книг. Тут хоть ничего сложного и нет, но юнит тронуть придется.

Очень удачный пример, как раз. Сейчас уже сделать ничего нельзя, ибо как вы правильно выразились изначально не было цели поддерживать соответствие id в книге и в документальных таблицах. Именно поэтому в 22 кодюните не используется TRANSFERFIELDS. потому что он сейчас просто не сработает, а выскочит с ошибкой. Результат - при добавлении нового поля - НЕОБХОДИМО править учетный кодюнит. Громадный кодъюнит становится Modified только потому, что добавилось одно поле.

romeo · 07.05.2008, 16:50

Цитата:

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

Громадный кодъюнит становится Modified только потому, что добавилось одно поле.

И что? Головоломкой еще более сложной было бы разработать кодеюнит таким образом, чтобы при реализации самых различных задач его по возможности не нужно было трогать..

artkashin · 07.05.2008, 17:07

Цитата:

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

И что? Головоломкой еще более сложной было бы разработать кодеюнит таким образом, чтобы при реализации самых различных задач его по возможности не нужно было трогать..

Согласитесь, что задача вполне решаема? То, что сложно - это точно, но то что учетный кодюнит - это одна большая свалка всего, что можно представить при учете - однозначно. Наверное, нет разделения кода на слои, на отдельные элементы, нет ЯДРА, как выразился HLS. Просто это данность.

SVG · 07.05.2008, 17:18

Цитата:

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

Я бы на месте Микрософта сделал вот что: Все основные кодюниты "стремные" отладил по человечески и запретил их править абсолютно всем! Нашел ошибку - напиши в Микрософт....

Простите что вмешиваюсь )
Я так понял что весь сыр-бор из-за этой фразы )
Фраза типа "надо запретить всем женщинам водить машину потому что они плохо водят"
или "надо запретить всем рожать, потому что вырастает хрен пойми что"

Проблема в категоричности ваших высказываний, HLS )
Правильнее просто не экономить на ИТ - на консультантах, тестерах, программистах.
Не доверяться внедренцу "за подешевле", не экономить на собственных специалистах.
Вот решение проблемы.

Запрещать редактирование части логики программы - потеря одного из конкурентных преимуществ нави.

HLS · 07.05.2008, 17:23

Представим ситуацию

На этапе внедрения - заказчик попросил сделать много дополнительных отчетов.
И программист Вася (только-что научившийся лобать отчеты), напихал фигову тонну новых ключей в таблицу 32 и 27. Для подсчета суммы тех или иных полей. Разбираться в уже существующих - ему было лень или просто не догадался.... Пока база маленькая (компания только начал работу) никаких проблем не будет. но...

Через несколько лет, при большом числе транзакций - эти таблицы раздуются до неприлично большого размера за счет этих новых ключей, а как следствие тормозить работу всей системы в целом, вплоть до критической отметки.

Вопрос.
Какого хрена дале Васе корячить таблицы? (ключи)
И кто будет искать причину "засора", и кто вообще поймет что такое имеет место быть?

P.S.

Это то что пришло сразу в голову, разбираться в коде и искать и вспоминать ситуации когда при якобы "безобидном" изменение логики лезет кучу кривостей - я не буду, поверьте мне на слово - их очень много!

SVG · 07.05.2008, 17:25

Да, и еще если позвоните - 5 копеек про корявость учетного 22го юнита
Я тоже если честно не совсем понимаю, зачем сделали
ValueEntry."Return Reason Code" := "Return Reason Code";
ValueEntry."External Document No." := "External Document No.";
ValueEntry."Document Date" := "Document Date";
Простите Рома и Яша ))) Я не на стороне оппонентов (см. сообщ. выше), просто хочу внести ясность ))))

Весь юнит работает через таблице 83 - она является донором и для 32й и для 5802
Можно в общем-то было соблюсти ID полей в книгах и в таблице 83
Тем более что 80й и 90й юнит заполняют таблицу 83 при помощи перечисления полей...
В общем непонятно почему так.... Видимо исторически сложилось )
Но вы поймите главное! нельзя запрещать редактирование логики системы!
Это является большим преимуществом нави - полная открытость кода!
Я например недавно сделал так, что можно вводить фильтр даты в виде 1,,31 (запятые)
потому что надоедает вечно регистр переключать.... Клева же!
Просто лазить в юниты надо не студентам, вот и все. О чем базар.

romeo · 07.05.2008, 17:30

Попытаюсь защитить программиста Васю.. Когда он пихал свои десятки ключей в таблицы, он выставлял галочку SQL Index у ключиков?

HLS · 07.05.2008, 17:34

Цитата:

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

Попытаюсь защитить программиста Васю.. Когда он пихал свои десятки ключей в таблицы, он выставлял галочку SQL Index у ключиков?

Вероятность 50/50

HLS · 07.05.2008, 17:39

Цитата:

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

Просто лазить в юниты надо не студентам, вот и все. О чем базар.

Как это воплотить в жизнь?

На мой взгляд тут нужны жесткие меры.... Либо внести в закон поправку об уголовной ответственности (шутка)

romeo · 07.05.2008, 17:40

Цитата:

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

Вероятность 50/50

Тогда снимайте 50 процентов вины с Васи. Потому что ключ в нави без галки Скуль на скуле не строится.

romeo · 07.05.2008, 17:42

Цитата:

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

Как это воплотить в жизнь?

SVG ответил )
"Правильнее просто не экономить на ИТ - на консультантах, тестерах, программистах"

HLS · 07.05.2008, 17:45

Цитата:

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

Тогда снимайте 50 процентов вины с Васи. Потому что ключ в нави без галки Скуль на скуле не строится.

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