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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.05.2008, 15:39   #41  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Защита от кодера-дурака должна быть, но это не проблема навижн, а проблема управления проектом.
Другое дело, что программных механизмов контроля таких действий среда разработки не предоставляет.
Структура кодюнитов построена так, что не залазить в них, при добавлении новой "фичи", просто нельзя. Даже новое поле не всегда достаточно просто завести в учтенной и неучтенной строке, потому что вызова TRANSFERFIELDS в учетном кодюните может быть не предусмотрено. Просто при построении системы этот пункт явно игнорировался.
Старый 07.05.2008, 15:40   #42  
HLS is offline
HLS
Участник
 
37 / 10 (1) +
Регистрация: 18.04.2008
To Дуд: если даже я и новичек, то это не значит что я несу чушь...

Если вы внимательно прочли мою тему, то должны были понять, что я допускаю ситуацию, когда "простое" проставление галочки "Open" относительно поля "Remaining Quantity" может вызвать несоответствие где-либо, для каких-либо (неизвестных мне) ситуаций... Просто когда имеете место дело с таблицей 32 в которой > 20 млн. записей, лишний раз стоит убедиться, не так ли?
Старый 07.05.2008, 15:47   #43  
Yoil is offline
Yoil
NavAx
NavAx Club
Лучший по профессии 2017
Лучший по профессии 2009
 
1,574 / 70 (6) ++++
Регистрация: 20.11.2002
Адрес: Msk
Цитата:
Сообщение от HLS Посмотреть сообщение
To Дуд: если даже я и новичек, то это не значит что я несу чушь...
Цитата:
Сообщение от HLS
А нужно чтобы дороботки надобились по максимуму не в "стремных" CU, дорабатывайте что хотите - только не в самом ядре
Цитата:
Сообщение от Kashin
Структура кодюнитов построена так, что не залазить в них, при добавлении новой "фичи", просто нельзя. Даже новое поле не всегда достаточно просто завести в учтенной и неучтенной строке, потому что вызова TRANSFERFIELDS в учетном кодюните может быть не предусмотрено.
Еще раз простите, но Вы таки несете чушь.
__________________
"Моей лошадке ядрышком полмордочки снесло..."
А.В.Суворов, письма к дочери
Старый 07.05.2008, 16:08   #44  
HLS is offline
HLS
Участник
 
37 / 10 (1) +
Регистрация: 18.04.2008
To Дуд:
Я имел в виду идеальный случай, то-что я написал по этой теме, можете считать как некое размышление, со множеством допущений, по поводу того - как можно было-бы сделать навик более стабильным и свободным от глюков. У вас есть другое?
Зачем объявлять мое рассуждение чушью, если не имеете своего?

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

Если вы внимательно прочли мою тему (про галку "Open"), то должны были понять, что я допускаю ситуацию, когда "простое" проставление галочки "Open" относительно поля "Remaining Quantity" может вызвать несоответствие где-либо, для каких-либо (неизвестных мне) ситуаций... Просто когда имеете место дело с таблицей 32 в которой > 20 млн. записей, лишний раз стоит убедиться, не так ли?
Старый 07.05.2008, 16:21   #45  
HLS is offline
HLS
Участник
 
37 / 10 (1) +
Регистрация: 18.04.2008
Цитата:
Сообщение от Kashin Посмотреть сообщение
Защита от кодера-дурака должна быть, но это не проблема навижн, а проблема управления проектом.
Согласен полностью. Только изменил бы слово "дурака" на "ивана-дурака", и добавил бы - "защита от внедренца-дурака". А в России таких не мало! Вспомним сколько у нас продается дипломов с квалификацией инженер-программист. И проблема, мне кажется, особенна именно для России, если даже крупные и уважаемые интеграторы допускают такие ошибки при внедрении, что хоть плачь хоть смейся (через некоторое время)... тут наше "на авось" - не катит.
Старый 07.05.2008, 16:22   #46  
GalaM is offline
GalaM
Moderator
Лучший по профессии 2009
 
640 / 42 (3) +++
Регистрация: 13.03.2008
Адрес: Москва
Цитата:
Сообщение от HLS Посмотреть сообщение
И поймите я - не сторонник того чтобы запретить править объекты! Просто править нужно по принципу 7 раз отмерь 1 раз отреж. очнь часто это правило - особенно начинающими "чудо-программистами" - студентами, нанятым за 30000 тыщ - не соблюдается.... Они же себя считают мега-монстрами программирования!
Я совсем не согласна, что надо что-то закрывать в системе.
Если NAV поставляется с открытым кодом, так надо весь код открыть, а не частично. И пусть вся ответственность о том, кто и что делает лежит на авторе изменений. Если компания хочет экономить, нанимая на работу студентов, то это не проблема отдельных пользователей.

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

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

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

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

Ну а простым пользователям данные конечно нельзя править и студентам то же.....
Все, что я говорила выше должно касаться только к доступу через программные объекты
Старый 07.05.2008, 16:24   #47  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от Дуд Посмотреть сообщение
Еще раз простите, но Вы таки несете чушь.
Где чушь? Вы никогда не добавляли записи типа 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";
Старый 07.05.2008, 16:37   #48  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
Цитата:
Сообщение от 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 переносит по айдишникам полей. Наверное головоломкой было бы поддерживать соответствие айди в одной книге и десятках документальных таблиц, которые в нее что-то пишут. Пришлось бы резервировать поля ... Я понимаю учет транзитов ... Но с книгой пример не оч. удачный.
В целом как аргументирование того, чтобы править стандартные "серьезные" юниты - прокатит. Но лучше было бы привести пример протаскивания какого-либо нового поля в какую-либо из книг. Тут хоть ничего сложного и нет, но юнит тронуть придется.
Старый 07.05.2008, 16:46   #49  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от romeo Посмотреть сообщение
Не очень удачный пример. TRANSFERFIELDS переносит по айдишникам полей. Наверное головоломкой было бы поддерживать соответствие айди в одной книге и десятках документальных таблиц, которые в нее что-то пишут. Пришлось бы резервировать поля ... Я понимаю учет транзитов ... Но с книгой пример не оч. удачный.
В целом как аргументирование того, чтобы править стандартные "серьезные" юниты - прокатит. Но лучше было бы привести пример протаскивания какого-либо нового поля в какую-либо из книг. Тут хоть ничего сложного и нет, но юнит тронуть придется.
Очень удачный пример, как раз. Сейчас уже сделать ничего нельзя, ибо как вы правильно выразились изначально не было цели поддерживать соответствие id в книге и в документальных таблицах. Именно поэтому в 22 кодюните не используется TRANSFERFIELDS. потому что он сейчас просто не сработает, а выскочит с ошибкой. Результат - при добавлении нового поля - НЕОБХОДИМО править учетный кодюнит. Громадный кодъюнит становится Modified только потому, что добавилось одно поле.
Старый 07.05.2008, 16:50   #50  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
Цитата:
Сообщение от Kashin Посмотреть сообщение
Громадный кодъюнит становится Modified только потому, что добавилось одно поле.
И что? Головоломкой еще более сложной было бы разработать кодеюнит таким образом, чтобы при реализации самых различных задач его по возможности не нужно было трогать..
Старый 07.05.2008, 17:07   #51  
artkashin is offline
artkashin
Участник
MCBMSS
 
519 / 18 (2) ++
Регистрация: 06.12.2006
Цитата:
Сообщение от romeo Посмотреть сообщение
И что? Головоломкой еще более сложной было бы разработать кодеюнит таким образом, чтобы при реализации самых различных задач его по возможности не нужно было трогать..
Согласитесь, что задача вполне решаема? То, что сложно - это точно, но то что учетный кодюнит - это одна большая свалка всего, что можно представить при учете - однозначно. Наверное, нет разделения кода на слои, на отдельные элементы, нет ЯДРА, как выразился HLS. Просто это данность.
Старый 07.05.2008, 17:18   #52  
SVG is offline
SVG
Участник
 
201 / 10 (1) +
Регистрация: 15.11.2004
Цитата:
Сообщение от HLS Посмотреть сообщение
Я бы на месте Микрософта сделал вот что: Все основные кодюниты "стремные" отладил по человечески и запретил их править абсолютно всем! Нашел ошибку - напиши в Микрософт....
Простите что вмешиваюсь )
Я так понял что весь сыр-бор из-за этой фразы )
Фраза типа "надо запретить всем женщинам водить машину потому что они плохо водят"
или "надо запретить всем рожать, потому что вырастает хрен пойми что"


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

Запрещать редактирование части логики программы - потеря одного из конкурентных преимуществ нави.
Старый 07.05.2008, 17:23   #53  
HLS is offline
HLS
Участник
 
37 / 10 (1) +
Регистрация: 18.04.2008
Представим ситуацию

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

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

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

P.S.

Это то что пришло сразу в голову, разбираться в коде и искать и вспоминать ситуации когда при якобы "безобидном" изменение логики лезет кучу кривостей - я не буду, поверьте мне на слово - их очень много!
Старый 07.05.2008, 17:25   #54  
SVG is offline
SVG
Участник
 
201 / 10 (1) +
Регистрация: 15.11.2004
Да, и еще если позвоните - 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 (запятые)
потому что надоедает вечно регистр переключать.... Клева же!
Просто лазить в юниты надо не студентам, вот и все. О чем базар.
Старый 07.05.2008, 17:30   #55  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
Попытаюсь защитить программиста Васю.. Когда он пихал свои десятки ключей в таблицы, он выставлял галочку SQL Index у ключиков?
Старый 07.05.2008, 17:34   #56  
HLS is offline
HLS
Участник
 
37 / 10 (1) +
Регистрация: 18.04.2008
Цитата:
Сообщение от romeo Посмотреть сообщение
Попытаюсь защитить программиста Васю.. Когда он пихал свои десятки ключей в таблицы, он выставлял галочку SQL Index у ключиков?
Вероятность 50/50
Старый 07.05.2008, 17:39   #57  
HLS is offline
HLS
Участник
 
37 / 10 (1) +
Регистрация: 18.04.2008
Цитата:
Сообщение от SVG Посмотреть сообщение
Просто лазить в юниты надо не студентам, вот и все. О чем базар.
Как это воплотить в жизнь?

На мой взгляд тут нужны жесткие меры.... Либо внести в закон поправку об уголовной ответственности (шутка)
Старый 07.05.2008, 17:40   #58  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
Цитата:
Сообщение от HLS Посмотреть сообщение
Вероятность 50/50
Тогда снимайте 50 процентов вины с Васи. Потому что ключ в нави без галки Скуль на скуле не строится.
Старый 07.05.2008, 17:42   #59  
romeo is offline
romeo
Участник
Аватар для romeo
 
564 / 10 (2) +
Регистрация: 31.03.2004
Цитата:
Сообщение от HLS Посмотреть сообщение
Как это воплотить в жизнь?
SVG ответил )
"Правильнее просто не экономить на ИТ - на консультантах, тестерах, программистах"
Старый 07.05.2008, 17:45   #60  
HLS is offline
HLS
Участник
 
37 / 10 (1) +
Регистрация: 18.04.2008
Цитата:
Сообщение от romeo Посмотреть сообщение
Тогда снимайте 50 процентов вины с Васи. Потому что ключ в нави без галки Скуль на скуле не строится.
В лучшем случае, придется переделывать отчеты. И не исключено, что Васины ключи программист Петя (более менее опытный) в дальнейшем не будет их использовать (не только для отчетов)....
 


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

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

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