В то время как компания SAP заявила об уходе с российского рынка, наша компания, назло немцам, решила внедрить программный продукт SAP HR, модуль, отвечающий за кадровый учет и расчет зарплаты. До этого кадровый учет велся в 1С: ЗУП 3.0. Данные из ЗУП с помощью типового механизма синхронизации попадали в 1С:Бухгалтерия 3.0 ПРОФ, которой и после перехода на SAP требуются сведения о начислениях по зарплате. Надо заметить, что внедрением и переводом кадрового учета из 1С в SAP занималась отдельная организация-разработчик. Сопровождение всего SAPа также осталось на ней, нам достался лишь весьма ограниченный доступ. Проблему загрузки в 1С зарплаты сотрудников, рассчитанной в SAP, предстояло решить самостоятельно. В нашем распоряжении со стороны SAP оказался только текстовый файл выгрузок с начислениями и удержаниями, и ещё IDOC.
Текстовый файл начислений представляет из себя простой csv. В файле есть заголовок с перечислением названий полей и далее строки данных. В каждой строке коды различных объектов из базы SAP и сумма начисления или удержания, перечисленные через точку с запятой.
IDOC – промежуточная база-концентратор, содержащая ограниченную выборку из SAP по самым ключевым данным: по сотрудникам и их документам, подразделениям, банковским счетам сотрудников и другой справочной информации. Но там и близко нет ничего о начислениях или удержаниях.
Задача - сделать так, чтобы из всего этого в 1С:Бухгалтерия формировались привычные и понятные для бухгалтера документы: «Отражение зарплаты в бухучете» и «Резерв отпусков».
Часть данных, конечно, поддавалась «прямому сопоставлению». То есть когда определенному коду SAP соответствует конкретный элемент конкретного справочника в 1С. Но часть данных представляла из себя клубок проблем. И самым проблемным из всех оказался «Способ учета зарплаты», который в «1С: Бухгалтерия» и задает проводки по счетам учета. Первая сложность в том, что SAP делает из начислений мешанину. Например, есть начисление X, есть начисление Y. А есть ещё начисление Z, которое является суммой начислений X и Y. И все три начисления отдельными строками присутствуют в файле выгрузки SAP. На настоящий момент у нас в программе насчитывается порядка трехсот видов начислений и удержаний, которые встречаются в файле SAP. А вот какие из них должны попадать в документы отражения зарплаты, принимает решение бухгалтер. В каком-то случае ему надо, чтобы попали начисления X и Y с разными способами учета зарплаты. В каком-то случае надо, чтобы в документ попало именно аккумулирующие начисление, а составляющие его начисления просто отбросились. Причем бухгалтер в какой-то момент может передумать. А ещё почти каждый месяц появляются новые виды начислений. А некоторые из уже имеющихся видов могут изменить свою интерпретацию в документе: например, был один счет, стал другой.
Вторая сложность интерпретации кодов SAP из строки выгрузки в том, что разное сочетание кодов по-разному задает значения показателей начислений в документе отражения зарплаты. И здесь могут быть самые разные вариации: один код SAP может указывать одновременно на несколько показателей в документе «Отражение зарплаты»; или сочетания кодов разных полей могут задавать один и тот же показатель в документе. И это всё тоже может быть не навсегда. Разбираться в программном коде с интерпретацией каждого конкретного вида начисления в данном случае бесполезно, их слишком много, и они слишком изменчивы.
Мне приходилось встречать интеграционные решения между 1С и другими системами, правда задачи интеграции не были такой сложности. И во всех организация, так называемого, маппинга всегда сводились к созданию «свалки» тематических справочников и регистров. В коде, как-правило, при обращении к этим объектам творится «каша»: данные просто теряют свою ссылочную природу 1С и представляют собой таблицы, связанные кодами. Стремление архитектурно упорядочить некий хаос на входе можно понять, и, наверняка, есть задачи, для которых это оправданно. Но та выгрузка начислений из SAP, которую нам предстояло обработать, где конечный результат интерпретации по сути не ясен, требовала других подходов. К тому же нужен был инструмент доступный пользователю, во всех смыслах этого слова: от интерфейса до понимания того, что происходит.
Некоторая часть справочников 1С действительно могла быть сопоставлена один-к-одному со справочниками SAP. Например, физически лица. В такие справочники в конфигураторе были добавлены реквизиты, которые хранят код SAP. Но для большинства данных было найдено своё программное решение, позволившее не менять объекты конфигурации совсем. От «раскладывания» данных выгрузки SAP по отдельным объектам метаданных сознательно отказались, и все прочитанные из файла значения полей вместе с их интерпретацией записываются в один регистр обработанных данных. То есть на момент загрузки нам важнее прочитать все данные из файла и подобрать для них соответствующие значение в базе. Вполне возможно, что для одного и того же загружаемого значения в регистр запишется несколько интерпретаций. Какая из них попадет в документ отражения зарплаты решится позже, на этапе формирования документа. А на этапе интерпретации работает всего один объект метаданных – план видов характеристик. Именно о нем хотелось бы рассказать подробней, потому что его одного хватает для перевода всего что приходит из SAP в значения базы 1С, и не только значений полей файла выгрузки, но и значений из IDOC.
План видов характеристик довольно редко используемый объект, но для решения наших задач подходит идеально. У плана есть типовой реквизит «Тип значения», который и задает тип искомого значения 1С. А созданные реквизиты и табличные части уже определяют, как искать конкретное значение. Хотя состав файлов выгрузок из SAP может меняться, все же набор возможных полей в файле конечен, а, следовательно, и количество типов значений нашего плана видов характеристик. В интерфейсе пользователя выбор типа значения определяет внешний вид формы плана вида характеристик, скрывая или, наоборот, отображая некоторые реквизиты, что упрощает пользователю работу с настройками.
Как видно из структуры данных плана, никаких конкретных значений, типа «Вид операции» или «Подразделение», все реквизиты и значения таблиц задаются или выбираются в режиме приложения. Создавая элементы плана видов характеристик, пользователь указывает программе как ей обработать встретившееся значение. За то какое поле из файла будет интерпретировать тот или иной элемент плана вида характеристик отвечает реквизит «ПредопределенноеСопоставление». В него записывается название поля. Хотя есть элементы, у которых данный реквизит остается пустым. Это в тех случаях, когда пользователь выбирает поиск интерпретации по значениям нескольких полей файла выгрузки SAP. В порядке применения элементов плана видов характеристик нет иерархии как таковой. Для интерпретации значения какого-либо поля будут применены все элементы настроек, которые имеются для данного поля. Но технологически в первую очередь отрабатывают настройки с заполненным реквизитом «ПредопределенноеСопоставление», то есть те, которые интерпретируют конкретное значение конкретного поля. А во вторую очередь отрабатывают настройки интерпретации набора полей.
Реквизит «Дополнительное», установленный в «Истина», позволяет «выключить» элемент плана из процедуры интерпретации. Два реквизита «СоздаватьЭлементыСправочника» (на форме «Создавать элементы справочника при их отсутствии») и «ОшибкаПриПустомЗначении» (на форме «Если соответствие не найдено - считать ошибкой загрузки данных») работают, когда для значения поля файла выгрузки SAP программе не удалось подобрать ни одного значения в базе 1С. Реквизит «СоздаватьЭлементыСправочника» становится доступен на форме только когда тип значения выбран «справочник». Это видно на скрине с настройкой справочника «Физические лица». Если в данном реквизите установлена галочка, то программа создаст новый элемент в заданном справочнике. Порядок создания и заполнения элемента описан в коде программы для каждого конкретного справочника отдельно.
В элементе настройки реализованы 4 вида интерпретации. Выбранный вид интерпретации заносится в реквизит «ВидСопоставления»:
- Прямая интерпретация. Возможно только для простых типов, таких как «число» или «строка». Значения переводятся непосредственно в значения 1С;
- Интерпретация по значению какого-либо реквизита справочника, если в качестве результирующего типа значения выбран справочник. Реквизит выбирается в «Поле поиска»;
- Интерпретация по таблице сопоставлений (таблица СопоставлениеДанных). В этой таблице значениям конкретного поля файла загрузки проставлены соответствующие значения из базы 1С. Это могут быть ссылки, значения перечислений, строки или числа.
В таблице сопоставления есть галочка «Технологическое», которой можно пометить те значения полей в файле выгрузки, которые должны быть отброшены при формировании зарплатных документов. Это к решению задачи про начисления «X + Y = Z», где бухгалтер решает какая часть равенства должна отразиться в бухгалтерском балансе. Очевидно, что «Значения SAP» здесь не могут повторяться, иначе результирующих значений будет много. Если такая ситуация неопределенности результата случается, результирующее значение остается пустым и в регистре обработанных данных ставится отметка об ошибке интерпретации.
- Интерпретация по таблице сопоставлений набору из нескольких полей (таблица «СопоставлениеПоНабору»). В наборе может быть произвольное количество произвольных полей. Пользователь сам выбирает, какие поля файла загрузки попадут в набор. А после и задает значения полей, которым будет соответствовать то или иное значение в базе 1С.
По структуре таблицы «СопоставлениеПоНабору» видно, что наборы заносятся в таблицу строками, что дает возможность хранить наборы из разного количества полей. И количество полей в наборе ограничено лишь количеством полей в файле выгрузки SAP. В интерфейсе пользователя таблица наборов из вертикального вида разворачивается в горизонтальный.
Среди полей файла выгрузки SAP есть поля, значения которых существенны для заполнения документов зарплаты, такие как «Подразделение» или «Вид начисления». А есть и те, которыми можно пренебречь. Например, «Подраздел персонала». Для первой группы полей, в случае ошибок интерпретации, попадание строки начисления в документ отражения зарплаты должно быть запрещено, так как начисление некорректно отразиться в проводке. А для второй группы - ошибки не играют большой роли. По логике программы строка начисления, в которой хотя бы для одного значения поля проставлена ошибка интерпретации, не может попасть в документ отражения зарплаты. Для того чтобы начисления с ошибками в интерпретации незначащих полей всё же попадали в зарплатные документы, существует галочка «ОшибкаПриПустомЗначении». При снятой галке, даже если для загружаемого значения не нашлось ни одного соответствующего значения в базе 1С, пустой результат не будет считаться ошибкой.
По мере интерпретации загружаемых значений заполняется регистр обработанных данных. Это регистр сведений следующего вида:
Как видно из его структуры, содержимое регистра ненамного более упорядочено, чем данные в файле на загрузку. Только ко всему добавились результаты интерпретации. Но на самом деле – это и есть то, к чему следует стремиться. Данные имеют конкретный адрес («НомерСтрокиВФайле» и «ИмяФайлаЗагрузки»), и теперь они типизированы (измерение «ПолеИзФайла» хранит значение элемента плана видов характеристик). В добавок есть готовое значение, которое можно заносить в документы 1С. И это на самом деле достаточная степень упорядочивания. Данные, хранимые в таком виде, легко собираются запросами, как угодно. И дальше их нетрудно распределить по табличным частям зарплатных документов. Кроме этого, например, у нас сейчас в коде описаны три варианта формирования документов. Точнее три варианта заполнения документов. Есть вариант загрузки по сотрудникам, когда в документ не попадают начисления для которых в базе 1С не было найдено физическое лицо. При этом все начисления в документах персонифицируются, то есть заносятся на конкретного сотрудника. Есть вариант формирования, при котором ошибки в подборе физических лиц не учитываются, начисления аккумулируются на подразделениях и заносятся в документы без заполнения графы «Сотрудник». Вариантов может быть масса. Разделение процесса интерпретации и формирования документов дало множество плюсов. Даже если требуется кардинально сменить интерпретацию каких-либо данных файла SAP, то просто создаются или меняются настройки – элементы плана видов характеристик, и, если требуется, дописывается новый вариант формирования документов.
Стоит сказать, что сам регистр интерпретированных данных доступен пользователям для просмотра и редактирования. За счет этого пользователь сам может отследить возникшие ошибки и поправить их.
Как было сказано выше, тот же план видов характеристик, который интерпретирует данные файла SAP о зарплате сотрудников, работает и для интерпретации данных IDOC. База IDOC используется для обогащения справочников 1С. Из неё грузятся сведения о физических лицах, подразделениях, банковских счетах и о многом другом. И здесь план видов характеристик помогает сопоставлять, например, документы физических лиц. Так как в IDOC от документов есть только коды. Настройка интерпретации сопоставляет каждому этому коду определенный тип документа, который в «1С:Бухгалтерия» задается перечислением. В некоторых случаях настройка интерпретации через план видов характеристик используются лишь для того, чтобы определить, какой реквизит справочника содержит код SAP. Обращение к реквизиту объекта вроде бы легко прописать в тексте программы, ведь их названия почти никогда не меняются. Но, если использовать настройку, то уже не приходится менять программный код, когда добавляется новый справочник для сопоставления, или удаляется какой-то старый. Причем с этой задачей может справиться сам пользователь.
Итого вся наша система загрузки данных из файла начислений SAP состоит из одного плана видов характеристик, одного регистра и одной обработки, в которой запускается загрузка данных из файла SAP и формирование документов. Плюс по одному новому реквизиту в нескольких справочниках. Хотя сопровождение интеграции SAP и 1С в дальнейшем безусловно потребует изменения программного кода, но в основе простая, логичная структура, легко поддающаяся доработкам и изменениям. С помощью данного инструмента в нашей организации грузятся данные уже примерно полгода. И с большинством вновь возникших задач обработки загружаемых данных удалось справиться изменяя или создавая новые элементы настроек загрузки, и дорабатывая планы формирования документов.
1С в целом показала себя как очень гибкая, многоуровневая среда, позволяющая воплотить самые разные подходы к обработке данных. Наша разработка – это пример того, каким образом можно реализовать систему объектов, хранящих правила сопоставления значений, не в конфигураторе, а непосредственно в приложении. Надеюсь, что этот пример станет ещё одной «кувалдой» для тех, кто строит интеграцию 1С с SAP.
