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

можно в модуле менеджера сделать метод. Или в общем модуле

В модуле документа видна ТЧ с именем Зарплата, а не общий модуль.

не заниматься копрокодом, назвать модуль и ТЧ разными именами

(3) а если так исторически сложилось?..

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

Неужели нет стандартных методов разжешения конфликта имен?

(6) Убить всех, кто помнит, что "так исторически сложилось" и сделать правильно.

ТС не читатель? (1), (5) чем не подходят? Или в модуле объекта.

(8) Вы что, читать не умеете? Исторически сложилось.. автор питает глубокое уважение к истории родной нетленки! Как можно от наследия предков отказываться?!
ЗЫ А вообще, конечно, жаль что в платформе вместо общих объектов с наследованием ввели понятие "общие модули"..

(9) >>общих объектов с наследованием

расшифруй

(10) Ну вот предположим, что вместо модулей будет иерархия объектов. На каждом уровне определяются свои процедуры и функции, при этом те процедуры, которые не определены на текущем уровне - наследуются из вышестоящих уровнея. Если процедура с таким же именем уже есть в вышестоящих объектах - то в текущем она переопределяется, с возможностью обращения через "Родитель.". Это бы здорово упростило внесение доработок в типовые, в частности, и значительно повысило бы сопровождаемость кода. Да и в типовых не было бы того спагетти вызовов между модулями, как сейчас.

(11) Поздравляю, вы сейчас пришли к концепции ООП, наследования и перегрузки функций :))

Не нужно это на самом деле. Оно упрощает работу программиста, но существенно усложняет читабельность чужого кода и простоту его изменения.

(11) Переходи на ООП :)

+(12) ... не нужно это, само собой, только применительно к описательному процедурно-ориентированному языку 1С. А в полноценном высокоуровневом ЯП без этого не обойтись.

(12) Читабельность чужого кода в типовых ниже плинтуса, я уже упоминал спагетти с модулями типа "ОбщийМодульРасчетаЗарплатыСтандартный", "ОбщийМодульРасчетаЗарплатыПереопределяемый", "ОбщийМодульРасчетаЗарплатыРегламентированный" и тому-подобный кошмар, который бы элегантно реализовывался через ООП.

(9) исторически сложилось - это писалось до меня

для демонстрации решил набросать по минимуму, для демонстрации проблемы и обнаружил что
http://savepic.net/3757316.png, но http://savepic.org/3597751.png
Есть ли в общем доступе описание стандартов язика 1С с описанием подобных ситуаций?