8.4.2. Учет российской специфики при внедрении западных систем

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

Разница в отчетных периодах. Общеизвестно, что согласно россий­скому законодательству финансовый год начинается в январе и разбива­ется на 12 периодов, соответствующих календарным месяцам. В боль­шинстве стран компании вправе определять отчетные периоды само­стоятельно, и они зачастую смещают начало финансового года относительно календарного или изменяют продолжительность отчетных периодов, что приводит к необходимости повторения их закрытия.

Многие западные системы (например, SAP R/3 или BAAN) по­зволяют поддерживать специальную Главную книгу с автоматиче­ским переносом в нее бухгалтерских документов и последующим получением отчетности по альтернативному набору отчетных перио­дов, но использование данной функциональности достаточно трудо­емко как в плане конфигурации, так и в аспекте дальнейшей под­держки системы.

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

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

Организация параллельного бухгалтерского учета. Трансформа­ция баланса, широко применяемая в России для получения финансо­вой отчетности по западным стандартам, не позволяет добиться нуж­ной точности и детализации данных, требующихся для решения управленческих задач. Поэтому обеспечение параллельного учета практически всегда является одним из требований при внедрении новой системы.

Реализация параллельного учета с одновременным вводом каж­дой операции раздельно по западным и российским стандартам воз­можна в западных системах путем создания двух независимых орга­низационных единиц для одного юридического лица. При этом про­водки должны вводиться вручную, так как реализовать и, самое главное, поддерживать механизм автоматической трансформации каждой отдельно взятой проводки практически невозможно. В силу трудоемкости как в плане внедрения системы, так и ежедневной ра­боты такое решение может рассматриваться только с теоретической точки зрения. *

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

План счетов. Основой для рассмотренного выше решения по ор­ганизации параллельного учета является специальным образом адап­тированный и расширенный план счетов, на базе которого можно проводить операции и получать отчетность согласно обоим стандар­там учета.

Общеизвестно, что в России действуют достаточно жесткие ин­струкции по нумерации и использованию плана счетов. Это делает невозможным использование корпоративного плана счетов и потен­циально может привести к разногласиям. Достаточно остро встает вопрос существенного расширения корпоративного плана счетов для его адаптации к целям параллельного учета. При принятии решения

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

Так, например, в системе SAP R/3 предусмотрена возможность использования альтернативной нумерации счетов. Данные номера счетов не могут быть использованы при проводке документов, одна­ко ряд отчетов позволяет выводить требуемые данные с заменой ос­новной нумерации на альтернативную. Учитывая вышесказанное, ре­комендуемым решением является создание в системе собственного плана счетов в соответствии с российскими стандартами и ведение альтернативных счетов для поддержки их соответствия с корпоратив­ным планом счетов.

Вопрос консолидации бухгалтерской отчетности при таком ре­шении практически не усложняется, поскольку в подмодуле консо­лидации системы SAP R/3 используется обобщенный независимый план счетов, соответствие с которым необходимо строить для каждо­го из планов счетов юридических лиц.

Автоматическое определение (контировка) счетов. Следствием не только введения нового плана счетов, но и законодательных осо­бенностей России является необходимость разработки соответствия для каждой из групп товаров между проводимой в модулях логисти­ки операцией (прием или отгрузка товара, излишек или недостача на складе при инвентаризации и т.д.) и корреспондирующими счетами в финансовом документе. Как правило, при этом возникает необходи­мость концептуально пересмотреть классификацию документов, ис­пользуемую в модели.

Широкое использование безвозмездной реализации товаров не только для продвижения продаж, но и для прочих целей является специфической особенностью российского бизнеса. При этом необ­ходимо обеспечить корректное деление операций для целей налого­вого учета.

Автоматизация таких налогов, как налог на добавленную стои­мость (НДС) и налог с продаж, никогда не была простой задачей. Это особенно актуально для компаний, работающих и на внутреннем, и на международном рынке. Например, для исходящих налогов требуется введение ряда признаков, проставленных как на учетных карточках покупателей, так и на учетных карточках товаров для автоматического расчета и проводки данных операций. Опыт разработки контировки

\

счетов на нескольких проектах позволяет выполнять данную работу быстро и эффективно. При этом существенным является своевремен­ное принятие бизнес-решений о том, какие операции (из числа теоре­тически существующих) применимы для компании-заказчика.

^Получение пакета финансовой отчетности. Как правило, раз­вертываемая модель системы содержит все необходимое для получе­ния I корпоративной отчетности. Адаптация обычно заключается в привязке соответствующих счетов к строкам отчетов. Необходимость в серьезных доработках возникает в случае существенных отступле­ний от внедряемой модели, возможных как по причине расхождений в законодательстве, так и из-за особенностей бизнеса российского представительства компании. Данные вопросы носят индивидуаль­ный характер и практически не подлежат обобщению.

Ситуация с пакетом отчетности, требуемым российским законо­дательством, обстоит гораздо хуже. Не все эти отчеты поставляются вместе с системой, не все поставляемые стандартные отчеты работа­ют корректно и отражают нужды конкретного клиента. Достаточно сказать, что такой базовый отчет, как отчет о корреспонденции сче­тов, работает неправильно с некоторыми видами документов.

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

Оформление клиентами заказов на покупку товара. Безусловно, развертываемая модель содержит настроенные бизнес-процессы об­работки заказов покупателей. Вместе с тем российское законодатель­ство и условия ведения бизнеса диктуют свою специфику. Россий­ские покупатели, как правило, заказывают товары с использованием формы заказа и кодировки товаров, разработанных с учетом только локальных потребностей. При внедрении интернациональной модели становится оправданным использование единой кодировки товаров. Процесс перехода на новую кодировку может быть весьма болезнен­ным, если он не спланирован заранее. Минимизация неудобства для клиентов достигается с помощью как системных, так и организаци­онных мер. На первых порах во избежание путаницы в бланке заказа может использоваться и старая, и новая кодировка товаров, что по­зволяет с течением времени приучить клиентов пользоваться новой кодировкой. Возможности системы позволяют одновременно выво-

дить на печать несколько альтернативных кодировок одного и того же товара. I

Еще одним интересным аспектом работы с клиентскими заказами может явиться проверенная российской практикой система предостав­ления скидок,и надбавок. Безусловно, в разворачиваемой модели/су­ществует схема калькуляции, включающая многочисленные скидки и надбавки. Вместе с тем во многих случаях представляется целесооб­разным разработать самостоятельную схему калькуляции для России. Такая схема хотя и предполагает дополнительные затраты на разра­ботку и тестирование, тем не менее приносит ощутимую выпрду в процессе эксплуатации системы, поскольку отдел обработки заказов и клиенты работают со знакомыми понятиями и не происходит резкого изменения процесса предоставления клиентских скидок.

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

Обработка банковских платежей и контроль кредитных лими­тов покупателей. Достаточно вспомнить, какие принципиальные различия существуют между банковскими системами России и Ук­раины, чтобы понять, что банковская система каждой из стран во многом является уникальной. Можно ожидать, что в адаптируемой модели не будут представлены такие компоненты, как авансовые платежи, платежи в условных единицах и предварительная обработка платежей для целей проверки кредитоспособности. Рассмотрим каж­дый из перечисленных пунктов отдельно.

\ Например, в системе SAP R/3 имеется стандартная функциональ­ность для ведения авансовых платежей, и она известна всем российским специалистам в области внедрения системы, а следовательно, и не за-слуйсивает изложения. Гораздо менее распространенный вариант -предварительная регистрация счета (еще отсутствующего) и ввод в систему запроса на оплату вместо запроса на предоплату с последую­щей! автоматической генерацией платежа. Такой вариант позволяет избегать дополнительной конфигурации системы, однако имеет два существенных недостатка. Первый из них — отсутствие отдельного счета, на котором отражается задолженность по предоплатам, а второй - отрутствие достаточно точных данных на этапе предварительной регистрации счета. Конечно, система позволяет автоматически перене­сти остаток по авансовым платежам на отдельный счет в конце месяца и откорректировать счет при его проводке, однако пользователи будут испытывать определенные неудобства.

Платежи в рублях с пересчетом некой суммы в твердой валюте по курсу на день оплаты получили в России широкое распространение. Осуществлять пересчет сумм к оплате вручную возможно, но трудо­емко, к тому же при этом невозможно заранее подготовить пакет до­кументов, подлежащих оплате. Достаточно распространенным реше­нием является создание дополнительных кодов валют для каждого типа условных единиц (например, оплата суммы в евро, пересчитан­ных в рубли по курсу Банка России, плюс 1 %) и ежедневное ведение соответствующим образом рассчитанных курсов для каждой из них. В этом случае система сгенерирует платеж на основе предварительно введенного запроса в выбранной технической валюте, рассчитав при­веденную сумму во внутренней валюте, т.е. рублях. Данная сумма и должна быть взята для печати платежного поручения вместо суммы в валюте транзакции. Однако возникает необходимость связать данный документ со счетом-фактурой, проводимым в рублях, что может ге­нерировать вопрос о корректности формируемой отчетности по НДС. Потенциально данная проблема решается легко, если проведена до­работка программы платежей, позволяющая проводить платеж в ва­люте, отличной от валюты запроса на платеж.

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

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

Учет операций на таможенном складе и оформление таможен­ных процедур. Практика показывает, что данный тип операций мржет по разным причинам быть не реализован в модели или реализован не так, как этого требует бизнес.

Существует стандартное решение по учету операций на /тамо­женном складе, при котором прием товара на таможенный склад не отражается, а проводятся только счета и таможенные декларации. В процессе закрытия месяца запускается специальная программа, про­водящая перегруппировку, т.е. перенос остатков, сформированных неотфактурованными поставками и счетами, проведенными без соот­ветствующего документа по приему товара, на указанные при конфи­гурации системы счета. Данный подход, имея такое неоспоримое достоинство, как простота, не позволяет обеспечить количественный учет товара на таможенном складе.

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

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

Учет основных средств. Не являясь крупномасштабным в рамках всего объема работ по внедрению, вопрос учета основных средств вы­деляется ввиду существенных расхождений в их учете согласно рос­сийскому и международному стандартам учета. Особенно сильно рас-

хождения проявляются при ведении гиперинфляционного учета, одна­ко и они могут быть успешно учтены при конфигурации системы.

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

Ввод в эксплуатацию основных средств по западным стандартам учета сопряжен с меньшим количеством формальностей и зачастую должен быть проведен сразу после покупки основного средства. При этом нет необходимости проводить операцию через счет вложений во внеоборотные активы. Существует целый ряд решений для внедре­ния такого рода схем, однако практика показала, что оптимальным является вариант конфигурации, когда покупка основных средств осуществляется через модуль управления материальными потоками с проводкой поступления материала к заказу на поставку в дебет тех­нического счета Главной книги. Кроме того, наличие соответствую­щей конфигурации позволяет автоматически провести одновремен­ный с поступлением ввод основного средства в эксплуатацию по за­падным стандартам учета. При получении необходимого пакета документов проводится ручная операция ввода в эксплуатацию по российскому учету. Это позволяет получать информацию о вводи­мых в эксплуатацию основных средствах без дублирования их учет­ных карточек.

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

Поддержка русского языка. С первого взгляда может показаться странным, что поддержка русского языка также иногда вызывает ос­ложнения. На настоящий момент в ряде западных систем невозмож­но совмещение русского языка с рядом европейских языков. Однако западные разработчики, например компания SAP AG, работают над данной проблемой, и ее решение ожидается в обозримом будущем.

Наиболее важным вопросом, связанным с языковой поддержкой, являются правила заполнения учетных карточек, в частности учет­ных карточек клиентов и поставщиков. Дело в том, что корректная языковая поддержка, при которой поля наименования и адресных данных выводятся на языке, на котором пользователь зашел в систе­му, здесь не предусмотрена, несмотря на наличие группы полей для заполнения на каждом из языков. Справедливости ради необходимо заметить, что компания SAP AG работает над данным вопросом, но на настоящий момент существуют основной и вспомогательные на­боры полей. Противоречие заключается в том, что, с одной стороны, русские названия необходимо выводить в отчетах и удобнее исполь­зовать при поиске. С другой стороны, русские буквы могут затруд­нять работу иностранных пользователей или даже быть нечитабель­ными при доступе из других стран. Можно переработать отчеты и создать дополнительные атрибуты поиска, однако в большинстве случаев использование русских названий в качестве основных явля­ется предпочтительным, поскольку необходимость использования данных о российских контрагентах иностранными пользователями возникает крайне редко.

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