Фантазии на тему 1С:зарплата и владение предметом
(36) А то Вы зачем-то фантазируете на тему 1С: Зарплаты, хотя предметом не владеете.
Еще как владею. Разбирали мы ваши журналы расчетов, и CJ447 (основной ваш) и прочие, которые делаете для ваших надобностей (напр. журнал расчета ЕСН (CJ1238) - эт в версии 7.70.021. Вот его примитивная структура (журнала расчетов) - мы ее в XML-е описываем
<table identifier="Журнал расчетов" connectionno="3">
<tablename>CJ447</tablename>
- <fields>
<field fieldno="1" name="Мастер" dbname="iddoc" type="CHAR" size="9" />
<field fieldno="2" name="Сотрудник" dbname="ids" type="CHAR" size="9" />
<field fieldno="3" name="ВОУ" dbname="idalg" type="CHAR" size="4" />
<field fieldno="5" name="Сумма" dbname="result" type="FLT" />
<field fieldno="6" name="НачальнаяДата" dbname="dateb" type="FLT" prjclass="2" />
<field fieldno="7" name="КонечнаяДата" dbname="datee" type="FLT" prjclass="2" />
<field fieldno="8" name="Период" dbname="period" type="CHAR" size="9" />
<field fieldno="15" name="Дни" dbname="sp448" type="FLT" />
<field fieldno="16" name="Часы" dbname="sp449" type="FLT" />
</fields>
</table>
По сути, только через idalg возможно определение, что за КБК, ОГС и прочие параметры проведения данной записи будут для нее актуальны. Если Вы, коллега, сведущи в организации бюджетного учета в какой-либо более-менее крупной организации, то наверняка в курсе, что один и тот же вид начислений начисляется по разным КБК, СубКЭСР, Мероприятиям, Типу средств, Направлению расхода, Типу финансирования и прочей бюджетной классификации, большинства из которой в типовой бюджетной конфигурации 1С отсутствует по умолчанию или вбивается как строка в аналитику КБК. И что ж получается, если у меня 10 подразделений финансируются из разных источников (эт образно - под источником я понимаю совокупность всей бюджетной классификации), то мне надо заводить 10 пользовательских видов начислений - каприз пользователя? - (извиняюсь, что спутал с конфигурационным объектом ВидыРасчетов, который выбирается для пользовательского) с разными схемами формирования проводок. Хотя схема формирования проводок в Смете зависит не только от настройки вида начислений, но может быть применена как к непосредственному начислению, исполнению должности (у нас в отличии от 1С сотрудника нормально можно назначить на несколько должностей - в журнале начислений у вас есть только поле Сотрудник, и к какой должности привязано начисление - не разберешься, в Парусе и то есть понятие "Исполнение должности"), собственно должности, подразделению.
А если вы, уважаемый коллега, знакомы хотя бы с основами SQL, то сами должны понимать, что никаких более менее сложных запросов (напр. общую сумму матпомощи по определенной КБК в разрезе учреждений) из таких данных не выбрать, а потому все скрипты ваших отчетов, которые формируют бухгалтерские проводки по зарплате - весьма условные. Куда Вы, к примеру отнесете запись начисления, если сотрудник у Вас одновременно назначен на 2 или более должности (если, конечно, такое вообще в 1С возможно)? Ведь в исходной таблице начислений у Вас хранится ссылка только на справочник сотрудников (таблица sc16).
К слову говоря, и проводки-то конечные в 1С:зарплата используют от силы 10% пользователей, ну или если структура организации слишком уж простая, не один ответственной главбух централизованный бухгалтерии по вашему Мемориальному ордеру 5 (хотя начисления по з/п в бюджетном учете уже 2 года отражаются в ж/о 6 - ну это может конфигурации мне попались такие - хотя у всего окружного центра такие стоят), так вот, НИ ОДИН ОТВЕТСТВЕННЫЙ БУХГАЛТЕР не возьмет данные этого журнала, чтобы по нему занести операции в 1С:Бухгалтерия.
Поскольку я не только выгружал данные из 1С, но и сверял их после выгрузки, я всю структуру 1С:зарплата и принципы формирования начислений изучил весьма серъезно, потому как работа такая.
Возможно, что-то где-то я не учел или понял не так, но общая схема работы мне абсолютно понятна. И схема эта никак не может быть использована в первоначальном виде для сколько-нибудь сложного ведения расчета зарплаты.