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

В этой статье описывается, почему остаток на счете кредиторской задолженности или баланс счета дебиторской задолженности в общем реестре отличается от общей суммы, причитающейся в отчете об историческом пробном балансе в 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 проверка в области Выбор транзакций для использования отчета.

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

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

• Документы были аннулированы в другой период, чем они были первоначально размещены. Отчет "Подробный баланс пробной версии" в общем реестре может не соответствовать отчету "Исторический устаревший пробный баланс". Например, предположим, что счет был введен 1/1/2007. Этот счет был аннулирован 01.02.2007. Подробный отчет о пробном балансе общего реестра печатается за 1.02.2007 - 28.02.2007. Отмененная транзакция появится в отчете. Если журнал "Исторический пробный баланс" печатается в том же диапазоне дат, то недействительный документ не будет печататься в отчете, так как он был аннулирован.

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

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

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

• При печати отчета "Исторический пробный баланс" вы не выбрали следующие поля проверка в области Исключить.

• Выберите эти проверка поля, а затем напечатайте отчет "Исторический возраст пробного баланса".

  Примечание.

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

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

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

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

• Если имели место прерывания или проблемы с пакетом "Кредиторская задолженность" или "Дебиторская задолженность", и транзакции были найдены в таблицах Work и Open одновременно, удаление пакета 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 января к счету от 5 декабря была применена кредитная записка от 31 декабря, а дата применения и дата отправки GL были оставлены как 22 января. Однако при публикации пакета GL пользователь изменил дату на 31 декабря. В этом случае в электронной таблице Согласование с GL за декабрь месяца перечислены реализованные суммы прибыли и потерь с обеих сторон, и они, как представляется, выверяются. Тем не менее, в отчете HATB еще не признается реализованная сумма прибыли/убытка и будет отключено на эту сумму по сравнению с GL, так как она не была применена или размещена до января в соответствии с записью о применении.  

Вопросы и ответы

В1. Является ли электронная таблица Сверки с GL истинной выверкой для кредиторской задолженности/дебиторской задолженности в GL?

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

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

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

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

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

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

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

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

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

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

Но если вы решите исправить таблицу распределения PM, вам придется удалить документ, чтобы примененные записи вернулись к открытию. Затем используйте служебную программу удаления журнала транзакций, чтобы удалить документ с недействительным. Убедитесь, что публикация будет отправляться в GL, а не отправлять в GL. Удалите пакет GL, созданный void. Затем снова включите документ в раздел "Кредиторская задолженность", чтобы транзакции и распределения были воссозданы. Обязательно отмените пакет 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.