Навижен сильно недоделан (С) Gmc. Почему?

[romeo]

Цитата:

Сообщение от 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]

Цитата:

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

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

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

[romeo]

Цитата:

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

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

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

[artkashin]

Цитата:

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

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

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