|
07.05.2008, 16:37 | #1 |
Участник
|
Цитата:
Сообщение от 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"; В целом как аргументирование того, чтобы править стандартные "серьезные" юниты - прокатит. Но лучше было бы привести пример протаскивания какого-либо нового поля в какую-либо из книг. Тут хоть ничего сложного и нет, но юнит тронуть придется. |
|
07.05.2008, 16:46 | #2 |
Участник
|
Цитата:
Сообщение от romeo
Не очень удачный пример. TRANSFERFIELDS переносит по айдишникам полей. Наверное головоломкой было бы поддерживать соответствие айди в одной книге и десятках документальных таблиц, которые в нее что-то пишут. Пришлось бы резервировать поля ... Я понимаю учет транзитов ... Но с книгой пример не оч. удачный.
В целом как аргументирование того, чтобы править стандартные "серьезные" юниты - прокатит. Но лучше было бы привести пример протаскивания какого-либо нового поля в какую-либо из книг. Тут хоть ничего сложного и нет, но юнит тронуть придется. |
|
07.05.2008, 16:50 | #3 |
Участник
|
|
|
07.05.2008, 17:07 | #4 |
Участник
|
Согласитесь, что задача вполне решаема? То, что сложно - это точно, но то что учетный кодюнит - это одна большая свалка всего, что можно представить при учете - однозначно. Наверное, нет разделения кода на слои, на отдельные элементы, нет ЯДРА, как выразился HLS. Просто это данность.
|
|