Сведения о различиях при согласовании общего реестра с управлением выплатами или с управлением задолженности

В этой статье описывается, почему баланс счета кредиторской задолженности или баланс счета дебиторской задолженности в общем реестре отличается от общей суммы, которая должна быть оплачена в отчете об истекшей задолженности в Microsoft Dynamics GP. Часто задаваемые вопросы приведены в конце этой статьи.

Область применения: Microsoft Dynamics GP
Исходный номер базы знаний: 866570

Подпрограмма "Согласование с GL" была новой для Microsoft Dynamics GP 10.0 (SP2). Эта подпрограмма создает электронную таблицу Microsoft Office Excel. Эту электронную таблицу можно использовать для сопоставления транзакций в разделе "Управление выплатами" или "Управление задолженностями", которые были размещены в общем реестре. Этот процесс не создает корректирующие транзакции. Однако этот процесс поможет определить различия транзакций, перечисленные в этом разделе. Чтобы открыть окно Согласование с GL, наведите указатель на Инструменты в меню Microsoft Dynamics GP, наведите указатель на Подпрограммы, наведите указатель на Финансовые средства и выберите Согласование с GL.

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

• Не все пакеты GL размещаются. (Электронная таблица "Сверка с GL" сообщает только об опубликованных записях.)

• Отчет о устаревшем балансе пробных версий печатается с ограничениями. Снова распечатайте Исторический отчет о стареющей дебиторской задолженности только с ограничением даты.

• Не все счета кредиторской задолженности или все счета дебиторской задолженности отображаются в Главной книге. Убедитесь, что вы просматриваете все счета с кредиторской задолженностью или все счета с задолженностью в общем реестре.

• Пакеты в управлении выплатами или в управлении задолженностями были размещены в общем реестре. Пакет в общем реестре был изменен или изменен до его публикации.

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

• Диапазон дат в отчете "Подробный пробный баланс" в общем реестре не соответствует диапазону дат в отчете о устаревшем балансе пробных платежей в разделе "Управление выплатами" или "Управление задолженностями". При печати отчета по древней дебиторской задолженности установите флажок "Дата проводки GL" в области "Выбор транзакций для отчета с использованием".

• Транзакции были размещены в разделе "Управление выплатами" или "Управление задолженностями". Однако эти транзакции не были размещены в главной книге, если они были для начальных балансов. Если флажок "Публикация в общий реестр" не установлен в окне "Установка публикации" для серии покупок или для серии продаж, транзакции будут размещены в разделе "Управление выплатами" или "Управление задолженностью". Однако эти транзакции не будут размещены в General Ledger.

• Флажок "Отслеживание доступных скидок в GL" установлен в окне настройки управления кредиторской задолженностью или в окне настройки управления дебиторской задолженностью. Затем чистая сумма счета будет размещена в общем реестре. Кроме того, оставшаяся сумма будет размещена на счете доступных скидок. Только чистая сумма будет отображаться в отчете "Подробный баланс пробной версии" в общем реестре. Однако в счете отображается общий общий объем валового счета на балансе по старым судебным разбирательствам в управлении выплатами или в управлении задолженностями.

• Документы были аннулированы в другой период, чем период их первоначального размещения. Подробный отчет о балансе пробной версии в общем реестре может не совпадать с отчетом о балансе в прошлом периоде пробной версии. Например, предположим, что этот счет был введен 01.01.2007. Этот счет был отменен 2.1.2007. Печатать отчет о подробном пробном балансе общего реестра за период с 01.02.2007 по 28.02.2007. В отчете появится недействимая транзакция. Если исторический отчет о дебиторской задолженности печатается в том же диапазоне дат, то аннулированный документ не будет напечатан в отчете, так как он был отменен.

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

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

• Если произошло прерывание, пакеты, возможно, не были правильно размещены в Общем реестре, в управление выплатами или в управление задолженностями.

• При печати отчета о устаревших пробных версиях вы не выбрали следующие флажки в области исключения.

• Установите эти флажки, а затем распечатайте отчет о устаревшем балансе пробной версии.

  Примечание.

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

  • Неотложные примененные кредитные документы
  • Нулевой баланс
  • Деятельность

• Если при пересчете используется управление мультивалютными операциями, вы выбрали опубликовать в счет компенсации покупок/продаж.

• Суммы кредитной карты, введенные в окне "Запись транзакций с выплатами" для счета. Это может привести к дисбалансу при согласовании для управления выплатами по общему реестру, так как только чистое изменение будет размещаться в модуле Общего реестра. (То есть это выглядит так, как будто транзакции GL отсутствуют, но суммы на стороне GL сведены в одну запись GL, тогда как сторона PM может показать три транзакции. Однако они по-прежнему должны соответствовать в более поздних версиях и корректно переходить в раздел "Сопоставленные транзакции".)

• Если прерывания или проблемы возникли при размещении пакета "Платежи" или "Задолженности", и транзакции одновременно оказались в таблицах "Работа" и "Открытые", удаление пакета RM или PM в Microsoft Dynamics GP приведет к проблемам. В данном случае пользователь обычно видит записи в обеих таблицах и решает, что пакет задач им не нужен, поэтому просто удаляют его в Microsoft Dynamics GP. Так как таблицы Work и Open совместно используют таблицу распространения, удаление пакета данных в Microsoft Dynamics GP также приведет к удалению записей распространения. Конечный результат заключается в том, что запись заголовка транзакции существует, но на стороне RM или PM отсутствуют соответствующие распределения, но GL была обновлена правильно. Эта проблема будет рассматриваться в следующей версии Microsoft Dynamics GP.

• Распределения могут отображаться в разделе "Потенциально сопоставленные" с различными суммами, если были применены скидки. Для сопоставления учетные записи скидок GL должны быть включены с учетной записью PM/RM перед запуском процесса "Примирить с GL". Закройте электронную таблицу и повторно запустите ее с помощью учетных записей GL со скидкой, перечисленных также.

• Распределения могут отсутствовать на стороне PM/RM, если тип (CASH, PAY, PURCH) был изменён. В электронной таблице согласования учетная запись используется только для стороны GL. Учетная запись не используется на стороне PM/RM. Сторона PM/RM извлекает данные с помощью типа PAY или REC независимо от используемой учетной записи, поэтому вы должны обязательно перечислить все учетные записи AP или AR в окне согласования. И простое переключение типа распространения в таблице SQL не делает распределение автоматически отображаться при повторном создании электронной таблицы. (Это была проблема в предыдущих версиях для кредитных карт типа CASH на счет AP, но эти записи отображаются в GP 2016, поэтому это больше не является проблемой.)

• Проверьте дату применения и дату публикации GL в таблице применения для многокурсных транзакций по сравнению с фактической датой, размещенной в GL. Например, 22 января к счету, датированному 31 декабря, была применена кредитная записка, датированная 5 декабря, и дата применения и дата публикации GL были оставлены как 22 января. Однако при публикации пакета GL пользователь изменил дату на 31 декабря. В этом случае в электронной таблице "Сверка с ГЛ" за декабрь перечислены суммы реализованной прибыли/убытка со обеих сторон, и они совпадают. Однако отчет HATB пока не распознает реализованную прибыль или убыток и будет отличаться по сравнению с GL, так как она не была применена или зафиксирована до января в соответствии с записью об применении.  

Часто задаваемые вопросы

Является ли электронная таблица "Reconcile to GL" настоящей сверкой счетов к оплате/получению на счетах GL?

A1. Функция примирения с GL — это средство устранения неполадок, помогающее пользователям выявлять несовпаденные распределения между RM/PM и GL. Это не обязательно должно было связываться с HATB, и это не было первоначальной целью, хотя мы знаем, что клиенты делают это. Балансы в электронной таблице "Согласование с GL" являются наиболее точными оценками, полученными с помощью простого сложения и вычитания распределений в таблице. В то время как балансы на HATB учитывают почти каждую таблицу и существенно более сложны и точны, из-за чего два баланса часто не совпадают.

Настоящее согласование должно осуществляться между отчетом RM или PM Исторического пробного баланса (HATB) и отчетами пробного баланса GL. Если они совпадают, возможно, вам не понадобится запускать инструмент "Reconcile to GL" для этого месяца. Таблицы GL состоят из дебетов и кредитов, а таблицы, из которых HATB получает данные, – это таблицы заголовков транзакций и таблицы записи применения. Таким образом, клиенты попросили способ примирить распределения в GL с таблицами распространения в RM или PM, чтобы помочь найти различия на этом уровне. Таким образом, именно поэтому была создана подпрограмма "Согласование с GL". Это средство устранения неполадок для сравнения дистрибутивов с распределениями между модулями для выявления отсутствующих дистрибутивов, что может привести к отсутствующим транзакциям из HATB. Поэтому используйте средство "Примирить с GL" в качестве помощи только для того, чтобы помочь вам примирить HATB с GL Trial Balance. Если баланс HATB и GL TB совпадает, то в этом месяце действительно нет необходимости запускать инструмент согласования с GL.

Вопрос 2. Должны ли итоговые данные в таблице "Согласование с GL" совпадать с итоговыми данными в HATB?

A2: Нет. Итоги в электронной таблице "Согласование с GL" представляют собой простую операцию сложения и вычитания записей распределения в этой таблице и не принимают во внимание другие таблицы. В то же время HATB рассматривает совершенно разные таблицы для вычисления баланса, используя таблицы транзакций и применения записей, что является гораздо более сложным расчетом. Из-за различных методов расчета или таблиц, используемых для получения балансов, не ожидается, что электронная таблица "Сверка с GL" будет напрямую соответствовать возрастающим балансам в отчетах HATB, что затруднит их согласование. Не обязательно сопоставлять балансы по согласованию с электронной таблицей GL с отчетом HATB.

Мы рекомендуем игнорировать итоговые суммы в электронной таблице согласования с GL и просто использовать разделы Несовпаденные и Потенциально совпаденные, чтобы помочь вам найти различия для анализа, чтобы выяснить, может ли это объяснить разницу между GL TB и HATB. Сверка с таблицей GL не является настоящей сверкой и предназначалась только для того, чтобы помочь вам определить различия в распределении для выяснения, существует ли эта разница также на уровне транзакций. На самом деле, если HATB соответствует GL ТБ, действительно не потребуется выполнить согласование с служебной программой GL на этот месяц вообще, так как нет различий для идентификации.

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

Вопрос 3. Что делать, если дистрибутивы отсутствуют на стороне GL?

A3: Если вы найдете распределения на стороне RM или PM, которые не находятся на стороне GL, изучите сторону GL для различий времени. Убедитесь, что все пакеты GL размещены. Если они действительно отсутствуют на стороне GL, вам потребуется ключ отрегулировать запись журнала непосредственно в GL для записи, чтобы создать дистрибутивы GL.

Вопрос 4. Что делать, если дистрибутивы отсутствуют на стороне RM или PM?

A4: Если распределение GL указано, но отсутствует на стороне RM или PM, сначала изучите различия времени. Также исследование, чтобы узнать, указана ли сама транзакция в отчете HATB и уже учитывается. Возможно, транзакция существует, но дистрибутивы просто отсутствуют. Таким образом, вопрос становится тем, как получить дистрибутивы в RM или PM, если транзакция существует? Во-первых, помните, что таблицы распространения в RM или PM не используются для других целей или отчетов в групповой политики, кроме этой таблицы согласования. Так действительно нужно вернуть их обратно в RM или PM? Оцените, стоит ли вам время заполнять таблицу, которая не используется в другом месте.

Но если вы выберите исправить таблицу распределения PM, вам придется аннулировать документ, чтобы примененные записи вернулись в открытый статус. Затем используйте служебную программу "Удалить журнал транзакций", чтобы удалить пустотый документ. Не забудьте установить запись для публикации в GL и не отправлять их в GL. Удалите пакет GL, созданный пустотой. Затем введите документ заново в модуль кредиторской задолженности, чтобы транзакции и распределения были воссозданы. Не забудьте аннулировать пакет GL для этого. Затем повторно примените новый документ к открытым документам, и они должны снова перейти к журналу.

Чтобы исправить ее в таблице распространения RM, необходимо удалить обе стороны счета и оплаты и повторно включить их как обратно, так и удалить пакет в GL.

Вопрос 5. Транзакции в разделе "Потенциально сопоставленные" выглядят так, как они соответствуют. Почему они не отображаются в разделе "Совпадение"?

A5. Существует несколько полей, соответствующих каждой записи о распределении. Все поля должны соответствовать, чтобы переместить его в соответствующий раздел. Если некоторые, но не все поля совпадают, он поместит его в раздел потенциально сопоставленных полей. Например, ниже приведены поля, которые сопоставляются для PM с GL:

Управление выплатами - GL
Номер ваучера — исходный контрольный номер
Источник TRX — исходный источник TRX
Дата публикации - Дата транзакции
По сумме счета — дебетовая сумма или кредитная сумма

Вопрос 6. Если я введу отсутствующие данные распределения в GL или RM/PM и повторно запущу таблицу сверки с GL, будут ли несопоставленные или потенциально сопоставленные элементы перемещаться в раздел сопоставленных?

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

Вопрос 7. Почему конечный баланс на ежемесячной или ежеквартальной электронной таблице не соответствует начальному балансу на следующей ежемесячной или квартальной электронной таблице?

A7: Если конечный баланс одного периода не соответствует начальному балансу следующего периода, это часто связано с осиротевшими записями распределения, у которых нет связанной записи заголовка в таблице субжурнала. Конечный баланс вычисляется excel прямо в электронной таблице. Он просто берет начальный баланс на этот период из верхней части электронной таблицы и добавляет или вычитает записи распределения, которые отображаются в электронной таблице, чтобы получить конечный баланс. С другой стороны, в следующем периоде начальный баланс вычисляется путем простого дебетово-кредитного расчета записей распределения в таблице SQL, и хранимая процедура присоединяется к таблице заголовков, поэтому она не будет включать распределения, для которых отсутствует запись заголовка. Конечным результатом может быть то, что некоторые распределения были рассчитаны на конечный баланс на предыдущей электронной таблице и пропущены из начального баланса в следующем периоде.

Вопрос 8. Распределения на стороне RM/PM существуют, но не загружаются в электронную таблицу.

A8. Ознакомьтесь со следующими советами по устранению неполадок:

• Проверьте диапазон дат, используемый в таблице "Согласование".
• Убедитесь, что дистрибутивы существуют в таблицах PM10100 или PM30600 для PM. (или для RM: выполните поиск RM10101 или RM30301) Проверьте даты этих распределений данных, чтобы убедиться, что они входят в диапазон, указанный для электронной таблицы. Важно найти их в таблицах распространения RM или PM, а не полагаться исключительно на повторно опубликованные журналы, например.
• Если вы найдете распределения в таблицах RM или PM, просмотрите эти распределения в документе на интерфейсе. Есть ли у них тип распределения PAY или REC или AVAIL? Это единственные типы, которые будут включены в электронную таблицу при сверке на стороне RM или PM в более ранних версиях. (Обновление: платежи по кредитным картам могут образовывать распределение на учетной записи AP с типом CASH, которое отображается в таблице, но при сверке с электронной таблицей GL это распределение не показывалось слева. Это просто проблема отображения электронной таблицы, а не проблема с данными. Однако эта проблема в Microsoft Dynamics GP 2016 не наблюдается, поскольку тип CASH теперь корректно отображается в электронной таблице, и была исправлена в процессе обновления.)

Вопрос 9. Можно ли отобразить окно "Согласование с GL" в других валютах?

A9: окно "Согласование с GL" предназначено для отображения только функциональных валют. Дополнительные сведения см. в разделе "Сведения о балансах" в окне "Согласование с GL" в Microsoft Dynamics GP.