Создание нового журнала

[Eldar9x]

Здравствуйте. Необходимо создать новый журнал в аксапте. Так же, как и обычные с Названием, с Шапкой, Строками, проверкой/разноской итд. Причем он не завязан ни к модулю номенклатур, ни к модулю ГК. Проводок там создаваться не будет. Tutorial-ы в 2009 аксапте сделаны по одному из этих модулей. Подскажите, пожалуйста, с чего начать, куда смотреть в этом вопросе?

[lev]

Цитата:

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

Здравствуйте. Необходимо создать новый журнал в аксапте. Так же, как и обычные с Названием, с Шапкой, Строками, проверкой/разноской итд. Причем он не завязан ни к модулю номенклатур, ни к модулю ГК. Проводок там создаваться не будет. Tutorial-ы в 2009 аксапте сделаны по одному из этих модулей. Подскажите, пожалуйста, с чего начать, куда смотреть в этом вопросе?

Ну куда смотреть, зависит от бизнес задачи.
Вообще все журналы сделаны примерно по одному виду. Я бы сделал по аналогии с InventJournalTable (хотя конечно, повторюсь, все зависит от бизнес назначения журнала).

[Eldar9x]

Цитата:

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

Ну куда смотреть, зависит от бизнес задачи.
Вообще все журналы сделаны примерно по одному виду. Я бы сделал по аналогии с InventJournalTable (хотя конечно, повторюсь, все зависит от бизнес назначения журнала).

Это для отдельно живущего самодельного транспортного модуля. Там есть свои таблицы, в которых при разноске и будут происходить изменения. Вот в том то и дело, я сейчас ума не приложу, с чего хотя бы начать сейчас...

[S.Kuskov]

Цитата:

— А у вас нет такой же, но с пелра… перламутровыми пуговицами?
— К сожалению, нет.
— Нет? Будем искать.

Цитата:

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

Подскажите, пожалуйста, с чего начать, куда смотреть в этом вопросе?

Конечно странная постановка задачи, ну да ладно. Первое что приходит в голову. Это следовать Tutorial-ам, но только наследовать свои классы не от модульных классов, а от базовых.

//class TutorialJournalCheckPost extends JournalCheckPostLedger
class myTutorialJournalCheckPost extends JournalCheckPost
{
}

[lev]

Цитата:

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

Это для отдельно живущего самодельного транспортного модуля. Там есть свои таблицы, в которых при разноске и будут происходить изменения. Вот в том то и дело, я сейчас ума не приложу, с чего хотя бы начать сейчас...

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

З.Ы. ну и как уже сказал S.Kuskov наследоваться Вам нужно будет от базовых классов.

[Eldar9x]

Спасибо. Я еще где-то видел статью по созданию новых журналов. Как раз по ней очень давно создавал какой-то новый журнал УЗ. Но вот сейчас что-то не могу найти. Помню только, что там по порядку очень хорошо были разжеваны все моменты этого вопроса...

[S.Kuskov]

Новый тип складского журнала

[Eldar9x]

Цитата:

Сообщение от S.Kuskov

Новый тип складского журнала

Эх, там ссылка битая

[egorych]

Цитата:

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

Здравствуйте. Необходимо создать новый журнал ... Причем он не завязан ни к модулю номенклатур, ни к модулю ГК. Проводок там создаваться не будет.

Цитата:

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

З.Ы. ну и как уже сказал S.Kuskov наследоваться Вам нужно будет от базовых классов.

Можно спросить - а задлянафига? Потренироваться в наследовании? Или охота поковыряться в базовых классах?
Если журнал ни с чем не связан - сделайте 2 таблички и 2 кнопки - проверить/разнести. Пропишите действия хоть на форме хоть в своем-же классе и радуйтесь стабильной и ПОНЯТНОЙ работе!
зы Вообще не понимаю наличия ООП в управленческих системах! Ну, например, семейство классов SalesPurch - нафига они нужны вместе? Зачем их объединили, чтоб потом в поте лица определять что это - салес или же пурч, ёперный балет!

[lev]

Цитата:

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

Можно спросить - а задлянафига? Потренироваться в наследовании? Или охота поковыряться в базовых классах?
Если журнал ни с чем не связан - сделайте 2 таблички и 2 кнопки - проверить/разнести. Пропишите действия хоть на форме хоть в своем-же классе и радуйтесь стабильной и ПОНЯТНОЙ работе!
зы Вообще не понимаю наличия ООП в управленческих системах! Ну, например, семейство классов SalesPurch - нафига они нужны вместе? Зачем их объединили, чтоб потом в поте лица определять что это - салес или же пурч, ёперный балет!

как я уже говорил:

Цитата:

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

и если уже после этого человек поймет, что ему нужно что то, что уже есть в базовых классах и можно использовать уже существующее, тогда:

Цитата:

З.Ы. ну и как уже сказал S.Kuskov наследоваться Вам нужно будет от базовых классов.

в другом случае, напишет свое.

[Starling]

Цитата:

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

Можно спросить - а задлянафига?

Согласен.
Из личного опыта - на проекте тоже была необходимость создать новый журнал – для принципиально новых сущностей. Разработчик оценил эту задачу в довольно большое количество часов – уж не помню какое, но мне оно не понравилось.
Тогда было предложено не использовать стандартный подход, а сделать просто отдельные формочки. Все это было «слизано» со стандартных журналов коммерческих соглашений. Оценки уменьшилась в разы. Результатом все довольны.
Но это частный случай, функциональность таки получилось урезанной. Такие фичи, как блокировка журнала открытого другим пользователем, настройки журналов для групп не реализовывались. Для нас это было не критично.
Тут уже вам решать.

[S.Kuskov]

Цитата:

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

Можно спросить - а задлянафига?

Дьявол, как всегда, в деталях. Сделать что-то своё сбоку - оно конечно много проще.
Работать оно будет, Но вам прийдётся придумать объяснение для пользователей и консультантов, почему те функции к которым они привыкли при работе с стандартными журналами не реализованы у вас.

О чём я говорю. На вскидку:

1. Журнализация ошибок при проверке/Отображение строк с ошибками
2. Система прав доступа журналам (Типы журналов) и к отдельным журналам (атрибуты: Частный, группа пользователей)
3. Разграничение нескольких пользователей при работе с одним журналом (болкировка журнала)
4. Отображение числа строк в шапке журнала
5. ... и т.д. и т.п.

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

[Eldar9x]

Цитата:

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

Можно спросить - а задлянафига? Потренироваться в наследовании? Или охота поковыряться в базовых классах?
Если журнал ни с чем не связан - сделайте 2 таблички и 2 кнопки - проверить/разнести. Пропишите действия хоть на форме хоть в своем-же классе и радуйтесь стабильной и ПОНЯТНОЙ работе!

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

[mazzy]

Цитата:

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

Хотя изначально в тз это вообще была одна простенькая форма с вполне понятной логикой.

не-не-не, Девид Блейн.
простенькая она пока полностью не осознаешь что от нее требуется

делайте по туториалу.

[_scorp_]

Цитата:

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

Подскажите, пожалуйста, с чего начать, куда смотреть в этом вопросе?

Нужно будет прописать свои таблицы в Map:
JournalNameMap
JournalTableMap
JournalTransMap
Не претендую на 100% правильность, но я при создании журналов создал наследников от перечисленных классов и перекрыл следующие методы:
JournalFormTable
- dataSourceCreatePost
- dataSourceCreatePre
- datasourceExecuteQueryPre
- datasourceValidateDeletePost
- enableButtonsActive
- initAllOpenPostedFromCaller
- initDatasourceAllow
- queryAddRange
- valueAllOpenPosted
JournalFormTrans
- dataSourceInitValuePost
- dataSourceInitValuePre
- dataSourceWritePre
- initButtons
- initDataSourceAllow
JournalStatic
- journalName
- journalTable
- journalTrans
- journalTypeIdToEnum
- menuItemStrLines //эта реализация мне не нравиться. В зависимости от типа журнала подменятся MenuItem для кнопки строк. Из-за этого неудобно настраивать права.
- nameFieldIdJournalNameId
- newJournalTransData
- newJournalVoucherNum
- numRefJournalId
- standardJournalNameId
JournalTableData
- canBeAutoUnlocked
- checkOpen
- initFromJournalName
- updateTable
JournalTransData
- findVoucher
- isVoucherObjectKeyValid
- voucherObjectKey
Реализовать формы по примеру:
InventJournalTable
InventJournalMovement

[Raven Melancholic]

Цитата:

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

Такое требование тз: использовать стандартный функционал журналов

В принципе, там особых сложностей нет:

• Создаем таблицы для заголовков, для строк и для наименований журналов.
• Включаем их в Map JournalNameMap, JournalTableMap, JournalTransMap.
• В настройках подходящего модуля добавляем поля, в которых будут указываться стандартные наименования журналов.
• Создаем формы для заголовков, строк, наименований журналов.
• Реализуем наследников от JournalFormTable, JournalFormTrans, JournalStatic, JournalTableData, JournalTransData. Если нужно, то еще и JournalCheckPost.
• В классе JournalStatic модифицируем методы construct, findJournalTableFromTrans, findJournalTableId
• В классе JournalTableData модифицируем construct

Вроде бы все. Ну а какие методы реализовывать и как все это использовать, смотрим по туториалу, по другим существующим журналам ну и по логике, указанной в задании.