Особенности и проблемы, возникающие при внедрении SAP ERP Roll Out проектов в филиалах западных компаний в России

Roll Out проект в России подразумевает под собой задачу организации в системе возможности ведения учета по правилам РСБУ, не нарушая при этом основных процессов. Сложность проекта зависит не только от количества и видов разниц между корпоративным и локальным учетом, но и от гибкости методологов клиента и их готовности находить золотую середину между желанием следовать букве законодательства и оптимизировать затраты на автоматизацию этих требований в системе. В первую очередь, целесообразно определить все имеющиеся разницы, найти методологические подходы к их устранению и постараться, насколько возможно, сблизить учеты.

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

• Различия в моменте отражения хозяйственных операций;
• Различия в правилах отражения хозяйственных операций;
• Корпоративный и локальный планы счетов;
• Смещение финансового года;
• Различная валюта отчетности.

Для реализации параллельного учета могут использоваться следующие глобальные инструменты SAP ERP:

• Альтернативный план счетов (функциональность FI-GL);
• Специальные регистры (функциональность FI-SL);
• Дополнительные регистры ГГК (функциональность FI-GL, Новая (Гибкая) главная книга);
• Различные области оценки основных средств (функциональность FI-AA);
• Различные методы и способы оценки стоимости запасов (в т.ч. ML (Material Ledger)-Регистр материалов);
• Функциональность консолидации.

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

План счетов

План счетов РСБУ настраивается, как альтернативный план счетов к корпоративному. Необходимо тщательно проработать mapping между счетами оперативного плана счетов (GAAP) и альтернативного плана счетов РСБУ, чтобы в дальнейшем корректно выполнить необходимые настройки. При подготовке mapping-а, важно чтобы счет основного плана счетов использовался именно в тех и только в тех операциях, для которых в РСБУ используется присвоенный альтернативный счет. Кроме того, счет должен соответствовать по техническим характеристикам: контрольный счет, управление открытыми позициями, налоговая категория и т.п., требуемым для соответствующего альтернативного счета в функциональности Russian Add-on.

Оперативный план счетов разбивается на три части, каждая из которых обслуживает:

• только локальные проводки GAAP;
• общие проводки GAAP и РСБУ;
• только проводки РСБУ.

Для возможности совместного ведения параллельного учета создаются технические счета и в корпоративном и в альтернативном плане счетов, которые являются нерелевантными для соответствующей отчетности.Российский рынок облачных ИБ-сервисов только формируется 2.4 т

Необходимо иметь в виду следующие особенности ведения альтернативных счетов:

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

Несоблюдение данных правил ведет к некорректной работе стандартной отчетности Russian Add-on.

Сдвиг фискального года относительно календарного

Одной из важных проблем на Roll Out проектах, является использование в корпоративном учете данной компании финансового года, который, сдвинут относительно календарного. Сдвинутый финансовый год не только усложняет работу пользователей при формировании годовой отчетности для целей РСБУ, но и требует дополнительной адаптации стандартной функциональности Russian Add-On.

В процессе внедрения функциональности Russian Add-On на нескольких проектах, в компаниях, работающих со сдвинутым финансовым годом, удалось выявить и исправить ошибки программной логики. Главным образом это касается решений в области учета НДС:

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

В результате совместной работы с SAP AG было выпущено несколько свежих нот:

• 1800993 14.12.2012 (J_3rfum26: Shifted year for separate VAT accounting)
• 1793287 11.12.2012 (J_3rfum26: Document could not be posted due to splitting)
• 1809771 13.02.2013 (J_3rfum26: Wrong debit/credit sign posting from ALV)

Учет НДС

Учет НДС на Roll Out проектах реализуется в SAP ERP на базе стандартной функциональности поставляемой в рамках российской локализации. Важным фактором технической возможности ведения учета в системе, в соответствии с последними изменениями и требованиями РСБУ, является установка последнего пакета обновлений и нот. Вся отчетность строится на базе данных ведущего регистра с использованием инструментов Russian Add-on.

Налоговая схема и Коды НДС

В ERP предусмотрена налоговая схема для каждой страны, для России - TAXRU. Независимо от того, какая налоговая схема будет использоваться для России (бывают проекты, на которых регламентируется использование единой налоговой схемы и использовать TAXRU невозможно), она должна быть донастроена – добавлены условий ZUD и ZUK.

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

Еще одной спецификой, используемой в России, являются целевые коды НДС, редко используемые в западных компаниях. Поэтому, кроме того, что данная особенность требует настройки дополнительной системы кодов, приходится дополнительно объяснять западным коллегам методику их применения. Целевые коды НДС используются для следующих процессов:

• Перенос входящего НДС к зачету (перенос с 19* на 68* счет);
• Перенос входящего НДС к зачету с учетом вторичных событий: налоговый агент, капитальное строительство и т.д.;
• НДС по товарам в пути (целевой код используется только для целей правильного функционирования стандартной разработки по учету НДС для товаров в пути, являющейся частью Russian Add-on);
• Необходимы технические целевые коды НДС для стандартной российской функциональности по учету экспортного НДС.
• Счета ГК для учета НДС
• Необходимо иметь в виду следующие особенности настройки счетов Главной Книги для учета НДС по российскому учету.
• Для удобства анализа входящего НДС обычно создается несколько 19-х отдельных счетов для целей РСБУ.
• Для обеспечения корректной работы российской локализации Russian Add-On cчета отложенного входящего НДС (19, 76) должны быть обязательно с «управлением открытыми позициями»;
• 68* счет, используемый для уплаты НДС, должен быть контрольным.

Эти технические особенности необходимо учесть при формировании mapping-а счетов НДС особое внимание следует уделить их техническим характеристикам.

НДС по авансам выданным

Часто данный процесс необходимо настраивать полностью, так как иностранные компании обычно не используют процесс Down payments payable. Требуется выполнить ряд дополнительных настроек, не предусмотренных обычно конфигурацией глобальных процессов.

Настройки преследуют следующие цели:

• Вывод суммы НДС в Назначении платежа в платежном поручении, для выгрузки в Клиент-Банк и для печатной формы;
• Возмещение НДС, если есть такие требования от клиента.

Если возмещение НДС не требуется, то достаточно для каждой ставки настроить по одному техническому коду НДС со ссылкой на технический счет, который проставляется в ТАП и наследуется при вводе авансового платежа. Это позволяет вычислить сумму НДС при формировании документа авансового платежа, которая используется при формировании поля «Назначение платежа» в платежном поручении. (Дополнительно требуется настройка операции VVA - Автоматические проводки.

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

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

НДС по авансам полученным

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

Для реализации процесса Down payments receivable требуется выполнить ряд дополнительных настроек, не предусмотренных обычно конфигурацией глобальных процессов:

• Создаются исходящие коды налога (10%, 18%), настроенные на отдельный 68* счет, для которого активировано управление открытыми позициями, налоговая категория «>».
• Проводка формируется в корреспонденции с 76-м счетом, который, должен быть без управления ОП, налоговая категория
• Настраивается операция MVA - Автоматические проводки со ссылкой на 76-й счет.
• Настраиваются коды ОГК.

Учет НДС по товарам в пути

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

Для автоматизации данного процесса успешно используется стандартная функциональность Russian Add-On (транзакция J3RFVATSD).

Данная разработка позволяет:

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

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

Раздельный учет НДС и экспорт

Раздельный учет НДС реализован в SAP ERP в пакете обновлений EhP5. Стандартное решение по раздельному учету НДС предоставляет следующие возможности:

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

При внедрении данного решения на практике возникают следующие проблемы:

• В момент закупки материала/товара/услуги у поставщиков обычно неизвестно, куда он пойдет: на экспорт, для реализации на внутреннем рынке или на необлагаемую налогом операцию. Поэтому невозможно на этапе ввода фактуры по закупке проставить корректный код НДС, определяющий отнесение данных товаров к раздельному учету.
• Кроме того, возникает вопрос методики расчета коэффициентов распределения, в случае, когда реализация товара на экспорт растягивается на несколько периодов и часть закупки «зависает» на складе на неопределенное время.
• Стандартное решение предполагает использование в системе цепочки реализации Контракт -> Заказ -> Поставка -> ГТД ->Сбытовой Счет-фактура -> Финансовый Документ Счета-фактуры -> Оплата. В случае отсутствия одного из объектов цепочки необходимо дорабатывать стандартную функциональность ввода подтверждений по экспортной реализации.
• Усложняется процедура переноса налога и выравнивания позиций счетов входящего НДС, поскольку, в результате разбиения к одной фактуре возникает несколько документов переноса, к тому же перенос облагаемой и необлагаемой части налога для одного счета-фактуры может быть выполнен в разные периоды, в результате чего возникает частичное выравнивание. Поэтому программа переноса налога J_3RFUM26 не выравнивает перенесенные позиции.Поэтому при внедрении раздельного учета НДС обязательно должна быть проработана процедура автоматического выравнивания позиций входящего НДС.
• Отсутствие функционала по расчету коэффициентов для раздельного учета. В настоящий момент данный вопрос прорабатывается SAP,в результате, предлагается решение на FI-SL.
• Невозможность ручной корректировки результатов выполнения процессов разделения входящих счетов-фактур и связывания их с фактурами по реализации;
• Всегда возникает вопрос о способе и возможностях распределения суммы входящего НДС, относящейся на необлагаемую реализацию, на соответствующие счета и объекты учета для отнесения на себестоимость или прочие операции. Либо в системе разрабатывается программа распределения, либо распределение производится вне системы и результаты загружаются в виде проводок.
• Увеличивается сложность процесса корректировки и сторнирования документов, особенно предыдущих периодов.

При использовании сдвинутого финансового года для учета НДС по экспорту необходимо применить следующие ноты:

• 1800993 14.12.2012 (J_3rfum26: Shifted year for separate VAT accounting)
• 1793287 11.12.2012 (J_3rfum26: Document could not be posted due to splitting)
• 1809771 13.02.2013 (J_3rfum26: Wrong debit/credit sign posting from ALV)

Расчеты в валюте

Настройка валют

По умолчанию для основной валюты БЕ задается тип курса М и данную настройку нельзя изменить. Но проблема в том, что иностранные компании используют свою валюту (USD, EUR) как базовую валюту для типа курса М, в то время как для РСБУ это должны быть рубли.

Существуют следующие настройки, помогающие решить данную проблему.

• Создается альтернативный тип курса, например, ZRU с базовой валютой – RUB. Соответственно, курс ЦБ ведется не для типа курса М, а для ZRU.
• В транзакции «Определения коэффициентов пересчета для валют» (Валюты) для каждой пары пересчета из иностранной валюты в рубли указывается Альтернативный тип курса ZRU.

В результате при любой операции пересчета в рубли будет использоваться тип курса ZRU, позволяющий производить пересчет по курсу ЦБ, в то время как другие БЕ компании сохранят пересчет по своим правилам.

Отражение суммы переоценки открытых позиций в Актах сверки

Стандартные отчеты, предназначенные для отражения переоцененных сумм по расчетам с Дебиторами и Кредиторами, входящие в Russian Addon, построены на базе таблиц Гибкой Главной Книги. Если в ее активация в системе не предусмотрена, то данные таблицы не заполняются, соответственно отчеты формируются без результатов переоценки.

Программы:

• J_3RF_ASK – Vendors reconciliation statement
• J_3RF_ASD – Customers reconciliation statement
• J_3RFPCR - Payments of vendors (RU)
• J_3RFPDE - Payments of customers (RU)
• J_3RFREVHISTFC - The history of valuation

Так как SAP в настоящее время поддерживает в новых разработках только решения, основанные ГГК, то при желании решить данную проблему необходимо дорабатывать данные программы самостоятельно.

Курсовые разницы

По правилам РСБУ необходимо отдельно вести расход и доход по курсовым разницам на отдельных счетах. Так как в западном учете подобного разделения не требуется, то, чаще всего, для отражения результатов расчета курсовых разниц настроен один счет без разделения на доходы и расходы.

Настройка счетов курсовых разниц глобальная и не зависит от Балансовой единицы. Если корпоративная политика компании позволит расширить глобальный план счетов, добавив отдельные счета для отражения доходарасхода от курсовых разниц, то проблема решается лишь путем выполнения необходимых настроек. В этом случае при настройке корпоративной отчетности счета доходов и расходов указываются вместе в одной строке, а в целях РСБУ – в разных строках.

Но проблема в том, что чаще всего корпоративная политика компании разделить счета не позволяет. В этом случае создаются технические счета, на которые, по итогам закрытия периода, вручную выполняются корректировочные проводки с учетом разделения на доход и расход. В дальнейшем эти счета используются при настройке отчетности по РСБУ.

Учет результатов расчетов курсовых разниц также специфичен с точки зрения формирования Налога на прибыль. Используя стандартное решение ТПР по Налогу на прибыль, реализованное на функциональности FI-SL или FI-GL, можно разделить доход и расход в момент трансляции данных из FI в налоговый регистр.

Расчеты в УЕ

Ведение расчетов в УЕ является спецификой российского учета. Один из методов реализации данного процесса – создание отдельных видов валют, например RUU (для USD), RUE (EUR). Курс для данных видов валют может рассчитываться автоматически в момент загрузки курсов основных валют, как некоторая производная от реальных валют (например, USD+EUR)2).

Документ задолженности формируется в УЕ, при этом валюта платежа в документе указывается RUB. Программа платежей при формировании платежа берет курс в рублях на дату платежа. Если курс УЕ формируется по особым правилам на основании договора, то платеж вводится рублях, непосредственно с указанием суммы по нужному курсу.

Выравнивание платежа и задолженности производится в УЕ в транзакции FB05, позволяющей задать курс.

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

Чтобы выделить отдельно результаты по курсовым разницам, возникающие от переоценки открытых позиций в УЕ (в целях учета по РСБУ и Налогу на прибыль), в настройке счетов переоценки для УЕ проставляются отдельные счета дохода и расхода.

Формы бухгалтерской отчетности

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

• Для вывода альтернативных счетов в отчетности необходимо активировать на селекционном экране опцию «Альтернативный счет»;
• Если в компании используется сдвинутый финансовый год, то для формирования отчетности за календарный год используется опция «Альтернативный период».

Эти опции доступны во всех стандартных транзакциях для формирования балансовой отчетности: F.01, J_3RFBS_ALL, J_3RFFV4.

Примечание: Для отчета J_3RFFV4 (Форма-4) существует специфическая логика заполнения экрана выбора в случае использования сдвинутого финансового года. При необходимости получить данные за календарный года, он указывается качестве финансового года, а индикатор Альтернативный период не проставляется.

Учет основных средств

Для тиражированных западных систем учет основных средств и амортизации, ведущийся по 01 основной области оценки, – это учет по корпоративным правилам.

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

В случае использования сдвинутого финансового года возникают следующие проблемы:

• Израсходованный срок в карточках формируются не по правилам РСБУ (в соответствии с календарным годом), а по сдвинутому финансовому году, так как переключение года производится в момент смены года;
• Отчеты по Запасам ОС функционируют в пределах года. Просмотреть сальдо на конец месяца внутри года можно только в случае, если год не закрыт. В случае сдвинутого года можно оказаться в ситуации, когда часть календарного года относится к уже закрытому периоду.

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

Расчет себестоимости

Требованием РСБУ является получение фактической себестоимости производимой и реализуемой продукции. Для налогового учета также необходим расчет налоговой себестоимости продукции или товара, правила расчета которой могут отличаться от бухгалтерских.

Большинство западных проектов используют регистр материалов ML (Material Ledger) для определения себестоимости товара и продукции. Проблема в том, что практически во всех случаях правила ее формирования отличаются от правил, определяемых нашим законодательством.

В зависимости от видов настройки регистра могут возникнуть следующие проблемы. Чаще всего учет товара ведется по стандартной цене и переоценка (изменение данной цены на фактическую) производится только раз в год. Отклонения между стандартной и фактической ценой накапливаются на отдельных счетах. Таким образом, фактическая себестоимость в разрезе материалов в системе не ведется. Кроме того, правила формирования отклонений по корпоративным стандартам могут отличаться от требований РСБУ и налогового учета.

Расчет налоговой себестоимости является частью ТПР по налогу на прибыль, входящего в Russian Add-on и реализованного на базе FI-SL или новой ГК. Но даже при использовании ТПР процесс расчета себестоимости требует донастройки «сведений» и «распределений» сумм отклонений, по причине различий в их составе для целей корпоративного и налогового учета.

Для получения фактической бухгалтерской себестоимости можно использовать несколько подходов, и все они основаны на заведении дополнительных технических счетов, которые не релевантны для корпоративного учета, а используются только для РСБУ.

Сумма отклонений в течение периода накапливается на определенных счетах в разрезе материалов. В конце периода необходимо провести расчет и распределение данных отклонений на соответствующие потоки – товар или продукция на складе, реализация, брак и т.д.

В случае, если правила расчета фактической себестоимости с помощью регистра материалов не обеспечивают выполнение правил РСБУ, то в зависимости от требований и возможностей проекта используются следующие подходы:

• разрабатывается отдельная программа, которая анализирует движения товара, собирает все затраты периода, производит расчет и формирует проводки на технических счетах;
• расчет и распределение производится вне системы, для чего в конце периода производится выгрузка из системы данных по формированию отклонений и проводок по движениям материалов. В Excel производится расчет фактической стоимости каждого материала на основании остатков на начало месяца, движений по поступлению (закупке или производству) и реализации. Затем производится загрузка через функциональность пакетного ввода из Excel-файла в систему корректировочных проводок по списанию себестоимости реализации на технические счета. Необходимо хранить стоимость остатков на складе в разрезе товаров вне системы (в Excel), чтобы использовать для расчетов следующего месяца.

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

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

Различия во времени отражения операций (Accruals)

На Roll Out проектах возникают сложности также в связи с разницей в периоде признания расходов между корпоративным учетом и РСБУ. Признание расхода по корпоративному учету происходит в периоде возникновения расхода, а по РСБУ – на дату поступления первичных документов. Так как в большинстве западных конфигураций регламентируется жесткое закрытие периода в первых числах следующего месяца, то отражение данных расхождений предполагает проведение дополнительных корректировочных проводок по техническим счетам, релевантным только для целей учета по РСБУ.

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

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

Для обеспечения жестких требований по отражению в Книге покупок всех документов текущего периода, поступивших до 20 числа следующего месяца, необходима доработка Книги Покупок.

Логистика

Выходные логистические формы

Проблемы, возникающие при формировании выходных печатных форм Счета-фактуры, Торг-12 и т.д.:

• каждый клиент имеет специфические требования заполнения полей документов;
• зачастую возникает потребность формировать выходные документы в нескольких валютах и на нескольких языках;
• отличие правил заполнения полей мастер данных в существующей конфигурации от принятых для формирования структуры данных и заложенных в функциональности Russian Add-on;
• иногда построение бизнес-процесса компании требует производить печать выходного документа не на той операции, к которой данная печать предусматривается в стандарте.

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

Учет по ГТД

Стандартное решение по учету ГТД предполагает списание товара в разрезе ГТД по FIFO в рамках Завода, но без привязки к партиям. В результате может возникнуть ситуация, когда при отпуске партии будет проставлен не тот ГТД, по которому данная партия поступила. Для решения проблемы необходима доработка стандартного решения.

Для введения ГТД в систему, с помощью транзакции J3RFGTDUSAGE есть три опции для заведения ГТД:

• на Заказ;
• на документ материала;
• на инвойс.

Необходимо иметь в виду, что в Книгу покупок ГТД попадает только в случае заведения на Заказ.

Закрытие периода

Закрытие периода осложняется не только тем, что в западном учете не используют закрывающих проводок по итогам месяца, например: Дт90 Кт20(44), Дт84 Кт90 и т.д. но и тем, что возможен сдвиг финансового года относительно календарного. Для формирования отчетных форм и формирования закрывающих проводок по правилам РСБУ создаются технические счета, которые не используются в корпоративном учете, но, в совокупности с используемыми счетами, создают правильную картину закрытия для Российского бухгалтерского учета.

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

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