Transactions Lost Posting to GL

We've been using Great Plains (Dynamics V9) since 9/01/06, and are
having some serious problems when posting to GL. In one case, one
payment of two vouchers was lost going from A/P to GL. We only print
about 30 checks a week, so at the end of the month when we posted to GL
and noticed the discrepancy, it was relatively easy to track down the
payment that was lost. The Accounting firm that helped with the
installation was of no help. Their solution was to create a journal
entry, which of course brough GL up to date, but didn't solve the
problem. Now this month, we're about $8,000 off between A/R and GL.
With about 150 invoices a day, tracking down this problem for a month's
worth of invoices is nearly impossible. There were no errors messages
generated on the user's PC when the posting to GL was run. From both
the AP and AR sides, everything looks like it was posted.

Has anyone run into a similar problem? Are there log files generated
within Great Plains when we post to GL that I could search through to
track this down? Any tables within the database that I could compare to
see what might have not been posted to GL?

Any help and/or ideas would be greatly appreciated.

Joel

0
jziegler (4)
12/8/2006 6:18:19 PM
greatplains 29623 articles. 3 followers. Follow

7 Replies
650 Views

Similar Articles

[PageSpeed] 31

To add to Richards great suggestions....over the years I have seen this come 
up a few times.  Batches from the GL mysteriously disappear.  No errors, no 
problems, no one can tell what happened to them.  After you rule out 
anything like unposted transactions or batches stuck in Batch Recovery, 
etc., here is a scenario that can cause this:

- Payables batch is posted and creates a GL batch.
- Someone is looking at GL transactions in the Transaction Entry screen and 
looks at one of these transactions from the Payables batch....maybe they 
change something, maybe they just click around....
- When they go to exit the screen, they get a message that says, "Do you 
want to save changes or DELETE THIS TRANSACTION?"  Except that part is not 
bold or capitalized, so most people misread it and think it says something 
like, "Do you want to save or delete your changes?"  Choosing Delete here 
actually deletes the entire GL transaction.

If this happens, there is no way to get it back short of manually entering a 
GL transaction with the right numbers.  Usually you can figure out if this 
is what happened by checking for missing journal entry numbers around the 
time that this would have been posted.

To prevent this in later versions of GP you can disallow deleting GL 
transactions by going to Tools > Setup > Financial > General Ledger and 
unchecking Allow Deletion of Saved Transactions.  (I believe this is only 
available in GP 8.0 and 9.0.)

-- 
Victoria Yudin
Dynamics GP MVP


"Richard L. Whaley" <info@AccoladePublications.com> wrote in message 
news:A6DE0E02-6325-4647-A7F2-2AD2A7549ED2@microsoft.com...
> You stated in your message that there were NO ERROR MESSAGES GENERATED ON 
> THE
> USER'S PC.  Posting error messages are printed on the posting reports. 
> Too
> often, people dont print these as they can be reprinted (if you do 
> everything
> else correctly).
>
> First step:  Make sure all posting journals are printed and examined, at
> least until the problems are resolved.
>
> Second step: Have you looked at the batches to see if there are any 
> unposted
> transactions hanging around in the original batch.  Usually, if a 
> transaction
> does not post, it stays in the system in the original batch.  It wont post
> until the problem is resolved but you can try to post the batch, print the
> reports, and examine them for errors.
>
> Of course, if you are not getting the option to print the posting reports,
> go to Tools->Setup->Posting->Posting Setup and turn on the reports for AP 
> and
> GL
>
> The usual suspect is missing or incorrect account numbers.  GP will let 
> you
> complete a setup without entering all of the account numbers and many 
> people
> leave these blank KNOWING they NEVER use those accounts.  This will
> frequently create transactions that cannot post.  Also, if you use an 
> account
> number as a default in a setup screen, and then delete the account number 
> for
> some reason, it remains in the setup screen, but the transactions using it
> will not post.
>
> Check this out and let me know if you need more.
> -- 
> Richard L. Whaley
> Author / Consultant / MVP
> Documentation for Software Users
>
> For help learning and better using Dynamics GP,... check out our books at
> http://www.AccoladePublications.com
>
>
>
> "jziegler@wi.rr.com" wrote:
>
>> We've been using Great Plains (Dynamics V9) since 9/01/06, and are
>> having some serious problems when posting to GL. In one case, one
>> payment of two vouchers was lost going from A/P to GL. We only print
>> about 30 checks a week, so at the end of the month when we posted to GL
>> and noticed the discrepancy, it was relatively easy to track down the
>> payment that was lost. The Accounting firm that helped with the
>> installation was of no help. Their solution was to create a journal
>> entry, which of course brough GL up to date, but didn't solve the
>> problem. Now this month, we're about $8,000 off between A/R and GL.
>> With about 150 invoices a day, tracking down this problem for a month's
>> worth of invoices is nearly impossible. There were no errors messages
>> generated on the user's PC when the posting to GL was run. From both
>> the AP and AR sides, everything looks like it was posted.
>>
>> Has anyone run into a similar problem? Are there log files generated
>> within Great Plains when we post to GL that I could search through to
>> track this down? Any tables within the database that I could compare to
>> see what might have not been posted to GL?
>>
>> Any help and/or ideas would be greatly appreciated.
>>
>> Joel
>>
>> 


0
victoria (3339)
12/8/2006 9:58:09 PM
I have more detail on this problem now, and could use some additional
help, focusing on the AR side. The problem occurs at the end of the
month, and relates to posting dates. An invoice batch was in the AR
system in November, but when it posted to the GL, it was posted into
December.

We create invoices outside of Great Plains, and use the Integration
Manager to load the invoices into AR. We create invoices the day after
the orders ship. So, orders shipped on 11/30/06, have invoices created
on 12/01/06. The invoice date for these invoices is set to 11/30/06.
The AR Invoice integration runs on 12/01/06.

The flat file of the invoices has the invoice date of 11/30/06 in each
record. The destination mapping uses this date to load both the
Document Date and the Posting Date in the Receivables Transaction. The
integration then runs unattended at night on 12/01/06, to integrate the
invoices.

Looking at the data in the Great Plains table RM10301, the document
date, (RM10301.DOCDATE), for the invoices is set correctly to 11/30/06.
The Posting Date, (RM10301.GLPOSTDT), however, is set to 12/01/06.
(Although I haven't taken the time to prove this, I believe this is why
the transactions actually posted to GL in December.)

In doing some additional investigation, it appears that the GLPOSTDT
date is set based on the User Date of the Great Plains application that
is running when the integration occurs. Since the integration is run
unattended and starts up the Grat Plains application as part of the
unattended process, the User Date defaults to the system date on the
server running the integration, which is 12/01/06.

What table and field does the Posting Date in the Receivables
Transaction integration get loaded into?

Is there a way to control, via the flat file integration, what date is
loaded into the GLPOSTDT field in RM10301?

If you need more information, feel free to let me know.

Thanks for the help.

Joel



Victoria [MVP] wrote:
> To add to Richards great suggestions....over the years I have seen this come
> up a few times.  Batches from the GL mysteriously disappear.  No errors, no
> problems, no one can tell what happened to them.  After you rule out
> anything like unposted transactions or batches stuck in Batch Recovery,
> etc., here is a scenario that can cause this:
>
> - Payables batch is posted and creates a GL batch.
> - Someone is looking at GL transactions in the Transaction Entry screen and
> looks at one of these transactions from the Payables batch....maybe they
> change something, maybe they just click around....
> - When they go to exit the screen, they get a message that says, "Do you
> want to save changes or DELETE THIS TRANSACTION?"  Except that part is not
> bold or capitalized, so most people misread it and think it says something
> like, "Do you want to save or delete your changes?"  Choosing Delete here
> actually deletes the entire GL transaction.
>
> If this happens, there is no way to get it back short of manually entering a
> GL transaction with the right numbers.  Usually you can figure out if this
> is what happened by checking for missing journal entry numbers around the
> time that this would have been posted.
>
> To prevent this in later versions of GP you can disallow deleting GL
> transactions by going to Tools > Setup > Financial > General Ledger and
> unchecking Allow Deletion of Saved Transactions.  (I believe this is only
> available in GP 8.0 and 9.0.)
>
> --
> Victoria Yudin
> Dynamics GP MVP
>
>
> "Richard L. Whaley" <info@AccoladePublications.com> wrote in message
> news:A6DE0E02-6325-4647-A7F2-2AD2A7549ED2@microsoft.com...
> > You stated in your message that there were NO ERROR MESSAGES GENERATED ON
> > THE
> > USER'S PC.  Posting error messages are printed on the posting reports.
> > Too
> > often, people dont print these as they can be reprinted (if you do
> > everything
> > else correctly).
> >
> > First step:  Make sure all posting journals are printed and examined, at
> > least until the problems are resolved.
> >
> > Second step: Have you looked at the batches to see if there are any
> > unposted
> > transactions hanging around in the original batch.  Usually, if a
> > transaction
> > does not post, it stays in the system in the original batch.  It wont post
> > until the problem is resolved but you can try to post the batch, print the
> > reports, and examine them for errors.
> >
> > Of course, if you are not getting the option to print the posting reports,
> > go to Tools->Setup->Posting->Posting Setup and turn on the reports for AP
> > and
> > GL
> >
> > The usual suspect is missing or incorrect account numbers.  GP will let
> > you
> > complete a setup without entering all of the account numbers and many
> > people
> > leave these blank KNOWING they NEVER use those accounts.  This will
> > frequently create transactions that cannot post.  Also, if you use an
> > account
> > number as a default in a setup screen, and then delete the account number
> > for
> > some reason, it remains in the setup screen, but the transactions using it
> > will not post.
> >
> > Check this out and let me know if you need more.
> > --
> > Richard L. Whaley
> > Author / Consultant / MVP
> > Documentation for Software Users
> >
> > For help learning and better using Dynamics GP,... check out our books at
> > http://www.AccoladePublications.com
> >
> >
> >
> > "jziegler@wi.rr.com" wrote:
> >
> >> We've been using Great Plains (Dynamics V9) since 9/01/06, and are
> >> having some serious problems when posting to GL. In one case, one
> >> payment of two vouchers was lost going from A/P to GL. We only print
> >> about 30 checks a week, so at the end of the month when we posted to GL
> >> and noticed the discrepancy, it was relatively easy to track down the
> >> payment that was lost. The Accounting firm that helped with the
> >> installation was of no help. Their solution was to create a journal
> >> entry, which of course brough GL up to date, but didn't solve the
> >> problem. Now this month, we're about $8,000 off between A/R and GL.
> >> With about 150 invoices a day, tracking down this problem for a month's
> >> worth of invoices is nearly impossible. There were no errors messages
> >> generated on the user's PC when the posting to GL was run. From both
> >> the AP and AR sides, everything looks like it was posted.
> >>
> >> Has anyone run into a similar problem? Are there log files generated
> >> within Great Plains when we post to GL that I could search through to
> >> track this down? Any tables within the database that I could compare to
> >> see what might have not been posted to GL?
> >>
> >> Any help and/or ideas would be greatly appreciated.
> >>
> >> Joel
> >>
> >>

0
jziegler (4)
12/13/2006 3:19:25 PM
Joel,

Glad you were able to find the source of the issue!

Yes, you should be able to specify the GL posting date in your integration - 
it is typically called Posting Date or GL Posting Date in the Integration 
Manager mapping.

-- 
Victoria Yudin
Dynamics GP MVP


<jziegler@wi.rr.com> wrote in message 
news:1166023165.462034.268520@l12g2000cwl.googlegroups.com...
>I have more detail on this problem now, and could use some additional
> help, focusing on the AR side. The problem occurs at the end of the
> month, and relates to posting dates. An invoice batch was in the AR
> system in November, but when it posted to the GL, it was posted into
> December.
>
> We create invoices outside of Great Plains, and use the Integration
> Manager to load the invoices into AR. We create invoices the day after
> the orders ship. So, orders shipped on 11/30/06, have invoices created
> on 12/01/06. The invoice date for these invoices is set to 11/30/06.
> The AR Invoice integration runs on 12/01/06.
>
> The flat file of the invoices has the invoice date of 11/30/06 in each
> record. The destination mapping uses this date to load both the
> Document Date and the Posting Date in the Receivables Transaction. The
> integration then runs unattended at night on 12/01/06, to integrate the
> invoices.
>
> Looking at the data in the Great Plains table RM10301, the document
> date, (RM10301.DOCDATE), for the invoices is set correctly to 11/30/06.
> The Posting Date, (RM10301.GLPOSTDT), however, is set to 12/01/06.
> (Although I haven't taken the time to prove this, I believe this is why
> the transactions actually posted to GL in December.)
>
> In doing some additional investigation, it appears that the GLPOSTDT
> date is set based on the User Date of the Great Plains application that
> is running when the integration occurs. Since the integration is run
> unattended and starts up the Grat Plains application as part of the
> unattended process, the User Date defaults to the system date on the
> server running the integration, which is 12/01/06.
>
> What table and field does the Posting Date in the Receivables
> Transaction integration get loaded into?
>
> Is there a way to control, via the flat file integration, what date is
> loaded into the GLPOSTDT field in RM10301?
>
> If you need more information, feel free to let me know.
>
> Thanks for the help.
>
> Joel
>
>
>
> Victoria [MVP] wrote:
>> To add to Richards great suggestions....over the years I have seen this 
>> come
>> up a few times.  Batches from the GL mysteriously disappear.  No errors, 
>> no
>> problems, no one can tell what happened to them.  After you rule out
>> anything like unposted transactions or batches stuck in Batch Recovery,
>> etc., here is a scenario that can cause this:
>>
>> - Payables batch is posted and creates a GL batch.
>> - Someone is looking at GL transactions in the Transaction Entry screen 
>> and
>> looks at one of these transactions from the Payables batch....maybe they
>> change something, maybe they just click around....
>> - When they go to exit the screen, they get a message that says, "Do you
>> want to save changes or DELETE THIS TRANSACTION?"  Except that part is 
>> not
>> bold or capitalized, so most people misread it and think it says 
>> something
>> like, "Do you want to save or delete your changes?"  Choosing Delete here
>> actually deletes the entire GL transaction.
>>
>> If this happens, there is no way to get it back short of manually 
>> entering a
>> GL transaction with the right numbers.  Usually you can figure out if 
>> this
>> is what happened by checking for missing journal entry numbers around the
>> time that this would have been posted.
>>
>> To prevent this in later versions of GP you can disallow deleting GL
>> transactions by going to Tools > Setup > Financial > General Ledger and
>> unchecking Allow Deletion of Saved Transactions.  (I believe this is only
>> available in GP 8.0 and 9.0.)
>>
>> --
>> Victoria Yudin
>> Dynamics GP MVP
>>
>>
>> "Richard L. Whaley" <info@AccoladePublications.com> wrote in message
>> news:A6DE0E02-6325-4647-A7F2-2AD2A7549ED2@microsoft.com...
>> > You stated in your message that there were NO ERROR MESSAGES GENERATED 
>> > ON
>> > THE
>> > USER'S PC.  Posting error messages are printed on the posting reports.
>> > Too
>> > often, people dont print these as they can be reprinted (if you do
>> > everything
>> > else correctly).
>> >
>> > First step:  Make sure all posting journals are printed and examined, 
>> > at
>> > least until the problems are resolved.
>> >
>> > Second step: Have you looked at the batches to see if there are any
>> > unposted
>> > transactions hanging around in the original batch.  Usually, if a
>> > transaction
>> > does not post, it stays in the system in the original batch.  It wont 
>> > post
>> > until the problem is resolved but you can try to post the batch, print 
>> > the
>> > reports, and examine them for errors.
>> >
>> > Of course, if you are not getting the option to print the posting 
>> > reports,
>> > go to Tools->Setup->Posting->Posting Setup and turn on the reports for 
>> > AP
>> > and
>> > GL
>> >
>> > The usual suspect is missing or incorrect account numbers.  GP will let
>> > you
>> > complete a setup without entering all of the account numbers and many
>> > people
>> > leave these blank KNOWING they NEVER use those accounts.  This will
>> > frequently create transactions that cannot post.  Also, if you use an
>> > account
>> > number as a default in a setup screen, and then delete the account 
>> > number
>> > for
>> > some reason, it remains in the setup screen, but the transactions using 
>> > it
>> > will not post.
>> >
>> > Check this out and let me know if you need more.
>> > --
>> > Richard L. Whaley
>> > Author / Consultant / MVP
>> > Documentation for Software Users
>> >
>> > For help learning and better using Dynamics GP,... check out our books 
>> > at
>> > http://www.AccoladePublications.com
>> >
>> >
>> >
>> > "jziegler@wi.rr.com" wrote:
>> >
>> >> We've been using Great Plains (Dynamics V9) since 9/01/06, and are
>> >> having some serious problems when posting to GL. In one case, one
>> >> payment of two vouchers was lost going from A/P to GL. We only print
>> >> about 30 checks a week, so at the end of the month when we posted to 
>> >> GL
>> >> and noticed the discrepancy, it was relatively easy to track down the
>> >> payment that was lost. The Accounting firm that helped with the
>> >> installation was of no help. Their solution was to create a journal
>> >> entry, which of course brough GL up to date, but didn't solve the
>> >> problem. Now this month, we're about $8,000 off between A/R and GL.
>> >> With about 150 invoices a day, tracking down this problem for a 
>> >> month's
>> >> worth of invoices is nearly impossible. There were no errors messages
>> >> generated on the user's PC when the posting to GL was run. From both
>> >> the AP and AR sides, everything looks like it was posted.
>> >>
>> >> Has anyone run into a similar problem? Are there log files generated
>> >> within Great Plains when we post to GL that I could search through to
>> >> track this down? Any tables within the database that I could compare 
>> >> to
>> >> see what might have not been posted to GL?
>> >>
>> >> Any help and/or ideas would be greatly appreciated.
>> >>
>> >> Joel
>> >>
>> >>
> 


0
victoria (3339)
12/13/2006 4:03:54 PM
In the Integration Manager setup, I have the Posting Date set to "Use
Source Field", and then map it to the same date field from the flat
file that is used to load the Document Date.

The Document Date is set correctly in RM10301, but the Posting Date
picks up the Use Date from the Great Plains application.

Do I need to do aomething else to get that Posting Date set correctly?

Joel



Victoria [MVP] wrote:
> Joel,
>
> Glad you were able to find the source of the issue!
>
> Yes, you should be able to specify the GL posting date in your integration -
> it is typically called Posting Date or GL Posting Date in the Integration
> Manager mapping.
>
> --
> Victoria Yudin
> Dynamics GP MVP
>
>
> <jziegler@wi.rr.com> wrote in message
> news:1166023165.462034.268520@l12g2000cwl.googlegroups.com...
> >I have more detail on this problem now, and could use some additional
> > help, focusing on the AR side. The problem occurs at the end of the
> > month, and relates to posting dates. An invoice batch was in the AR
> > system in November, but when it posted to the GL, it was posted into
> > December.
> >
> > We create invoices outside of Great Plains, and use the Integration
> > Manager to load the invoices into AR. We create invoices the day after
> > the orders ship. So, orders shipped on 11/30/06, have invoices created
> > on 12/01/06. The invoice date for these invoices is set to 11/30/06.
> > The AR Invoice integration runs on 12/01/06.
> >
> > The flat file of the invoices has the invoice date of 11/30/06 in each
> > record. The destination mapping uses this date to load both the
> > Document Date and the Posting Date in the Receivables Transaction. The
> > integration then runs unattended at night on 12/01/06, to integrate the
> > invoices.
> >
> > Looking at the data in the Great Plains table RM10301, the document
> > date, (RM10301.DOCDATE), for the invoices is set correctly to 11/30/06.
> > The Posting Date, (RM10301.GLPOSTDT), however, is set to 12/01/06.
> > (Although I haven't taken the time to prove this, I believe this is why
> > the transactions actually posted to GL in December.)
> >
> > In doing some additional investigation, it appears that the GLPOSTDT
> > date is set based on the User Date of the Great Plains application that
> > is running when the integration occurs. Since the integration is run
> > unattended and starts up the Grat Plains application as part of the
> > unattended process, the User Date defaults to the system date on the
> > server running the integration, which is 12/01/06.
> >
> > What table and field does the Posting Date in the Receivables
> > Transaction integration get loaded into?
> >
> > Is there a way to control, via the flat file integration, what date is
> > loaded into the GLPOSTDT field in RM10301?
> >
> > If you need more information, feel free to let me know.
> >
> > Thanks for the help.
> >
> > Joel
> >
> >
> >
> > Victoria [MVP] wrote:
> >> To add to Richards great suggestions....over the years I have seen this
> >> come
> >> up a few times.  Batches from the GL mysteriously disappear.  No errors,
> >> no
> >> problems, no one can tell what happened to them.  After you rule out
> >> anything like unposted transactions or batches stuck in Batch Recovery,
> >> etc., here is a scenario that can cause this:
> >>
> >> - Payables batch is posted and creates a GL batch.
> >> - Someone is looking at GL transactions in the Transaction Entry screen
> >> and
> >> looks at one of these transactions from the Payables batch....maybe they
> >> change something, maybe they just click around....
> >> - When they go to exit the screen, they get a message that says, "Do you
> >> want to save changes or DELETE THIS TRANSACTION?"  Except that part is
> >> not
> >> bold or capitalized, so most people misread it and think it says
> >> something
> >> like, "Do you want to save or delete your changes?"  Choosing Delete here
> >> actually deletes the entire GL transaction.
> >>
> >> If this happens, there is no way to get it back short of manually
> >> entering a
> >> GL transaction with the right numbers.  Usually you can figure out if
> >> this
> >> is what happened by checking for missing journal entry numbers around the
> >> time that this would have been posted.
> >>
> >> To prevent this in later versions of GP you can disallow deleting GL
> >> transactions by going to Tools > Setup > Financial > General Ledger and
> >> unchecking Allow Deletion of Saved Transactions.  (I believe this is only
> >> available in GP 8.0 and 9.0.)
> >>
> >> --
> >> Victoria Yudin
> >> Dynamics GP MVP
> >>
> >>
> >> "Richard L. Whaley" <info@AccoladePublications.com> wrote in message
> >> news:A6DE0E02-6325-4647-A7F2-2AD2A7549ED2@microsoft.com...
> >> > You stated in your message that there were NO ERROR MESSAGES GENERATED
> >> > ON
> >> > THE
> >> > USER'S PC.  Posting error messages are printed on the posting reports.
> >> > Too
> >> > often, people dont print these as they can be reprinted (if you do
> >> > everything
> >> > else correctly).
> >> >
> >> > First step:  Make sure all posting journals are printed and examined,
> >> > at
> >> > least until the problems are resolved.
> >> >
> >> > Second step: Have you looked at the batches to see if there are any
> >> > unposted
> >> > transactions hanging around in the original batch.  Usually, if a
> >> > transaction
> >> > does not post, it stays in the system in the original batch.  It wont
> >> > post
> >> > until the problem is resolved but you can try to post the batch, print
> >> > the
> >> > reports, and examine them for errors.
> >> >
> >> > Of course, if you are not getting the option to print the posting
> >> > reports,
> >> > go to Tools->Setup->Posting->Posting Setup and turn on the reports for
> >> > AP
> >> > and
> >> > GL
> >> >
> >> > The usual suspect is missing or incorrect account numbers.  GP will let
> >> > you
> >> > complete a setup without entering all of the account numbers and many
> >> > people
> >> > leave these blank KNOWING they NEVER use those accounts.  This will
> >> > frequently create transactions that cannot post.  Also, if you use an
> >> > account
> >> > number as a default in a setup screen, and then delete the account
> >> > number
> >> > for
> >> > some reason, it remains in the setup screen, but the transactions using
> >> > it
> >> > will not post.
> >> >
> >> > Check this out and let me know if you need more.
> >> > --
> >> > Richard L. Whaley
> >> > Author / Consultant / MVP
> >> > Documentation for Software Users
> >> >
> >> > For help learning and better using Dynamics GP,... check out our books
> >> > at
> >> > http://www.AccoladePublications.com
> >> >
> >> >
> >> >
> >> > "jziegler@wi.rr.com" wrote:
> >> >
> >> >> We've been using Great Plains (Dynamics V9) since 9/01/06, and are
> >> >> having some serious problems when posting to GL. In one case, one
> >> >> payment of two vouchers was lost going from A/P to GL. We only print
> >> >> about 30 checks a week, so at the end of the month when we posted to
> >> >> GL
> >> >> and noticed the discrepancy, it was relatively easy to track down the
> >> >> payment that was lost. The Accounting firm that helped with the
> >> >> installation was of no help. Their solution was to create a journal
> >> >> entry, which of course brough GL up to date, but didn't solve the
> >> >> problem. Now this month, we're about $8,000 off between A/R and GL.
> >> >> With about 150 invoices a day, tracking down this problem for a
> >> >> month's
> >> >> worth of invoices is nearly impossible. There were no errors messages
> >> >> generated on the user's PC when the posting to GL was run. From both
> >> >> the AP and AR sides, everything looks like it was posted.
> >> >>
> >> >> Has anyone run into a similar problem? Are there log files generated
> >> >> within Great Plains when we post to GL that I could search through to
> >> >> track this down? Any tables within the database that I could compare
> >> >> to
> >> >> see what might have not been posted to GL?
> >> >>
> >> >> Any help and/or ideas would be greatly appreciated.
> >> >>
> >> >> Joel
> >> >>
> >> >>
> >

0
jziegler (4)
12/13/2006 4:28:05 PM
Are you creating a new batch with the integration?

What are your posting settings for this type of transaction?  Are you using 
the posting date from the batch or the transaction?

-- 
Victoria Yudin
Dynamics GP MVP


<jziegler@wi.rr.com> wrote in message 
news:1166027285.163839.173030@16g2000cwy.googlegroups.com...
> In the Integration Manager setup, I have the Posting Date set to "Use
> Source Field", and then map it to the same date field from the flat
> file that is used to load the Document Date.
>
> The Document Date is set correctly in RM10301, but the Posting Date
> picks up the Use Date from the Great Plains application.
>
> Do I need to do aomething else to get that Posting Date set correctly?
>
> Joel
>
>
>
> Victoria [MVP] wrote:
>> Joel,
>>
>> Glad you were able to find the source of the issue!
>>
>> Yes, you should be able to specify the GL posting date in your 
>> integration -
>> it is typically called Posting Date or GL Posting Date in the Integration
>> Manager mapping.
>>
>> --
>> Victoria Yudin
>> Dynamics GP MVP
>>
>>
>> <jziegler@wi.rr.com> wrote in message
>> news:1166023165.462034.268520@l12g2000cwl.googlegroups.com...
>> >I have more detail on this problem now, and could use some additional
>> > help, focusing on the AR side. The problem occurs at the end of the
>> > month, and relates to posting dates. An invoice batch was in the AR
>> > system in November, but when it posted to the GL, it was posted into
>> > December.
>> >
>> > We create invoices outside of Great Plains, and use the Integration
>> > Manager to load the invoices into AR. We create invoices the day after
>> > the orders ship. So, orders shipped on 11/30/06, have invoices created
>> > on 12/01/06. The invoice date for these invoices is set to 11/30/06.
>> > The AR Invoice integration runs on 12/01/06.
>> >
>> > The flat file of the invoices has the invoice date of 11/30/06 in each
>> > record. The destination mapping uses this date to load both the
>> > Document Date and the Posting Date in the Receivables Transaction. The
>> > integration then runs unattended at night on 12/01/06, to integrate the
>> > invoices.
>> >
>> > Looking at the data in the Great Plains table RM10301, the document
>> > date, (RM10301.DOCDATE), for the invoices is set correctly to 11/30/06.
>> > The Posting Date, (RM10301.GLPOSTDT), however, is set to 12/01/06.
>> > (Although I haven't taken the time to prove this, I believe this is why
>> > the transactions actually posted to GL in December.)
>> >
>> > In doing some additional investigation, it appears that the GLPOSTDT
>> > date is set based on the User Date of the Great Plains application that
>> > is running when the integration occurs. Since the integration is run
>> > unattended and starts up the Grat Plains application as part of the
>> > unattended process, the User Date defaults to the system date on the
>> > server running the integration, which is 12/01/06.
>> >
>> > What table and field does the Posting Date in the Receivables
>> > Transaction integration get loaded into?
>> >
>> > Is there a way to control, via the flat file integration, what date is
>> > loaded into the GLPOSTDT field in RM10301?
>> >
>> > If you need more information, feel free to let me know.
>> >
>> > Thanks for the help.
>> >
>> > Joel
>> >
>> >
>> >
>> > Victoria [MVP] wrote:
>> >> To add to Richards great suggestions....over the years I have seen 
>> >> this
>> >> come
>> >> up a few times.  Batches from the GL mysteriously disappear.  No 
>> >> errors,
>> >> no
>> >> problems, no one can tell what happened to them.  After you rule out
>> >> anything like unposted transactions or batches stuck in Batch 
>> >> Recovery,
>> >> etc., here is a scenario that can cause this:
>> >>
>> >> - Payables batch is posted and creates a GL batch.
>> >> - Someone is looking at GL transactions in the Transaction Entry 
>> >> screen
>> >> and
>> >> looks at one of these transactions from the Payables batch....maybe 
>> >> they
>> >> change something, maybe they just click around....
>> >> - When they go to exit the screen, they get a message that says, "Do 
>> >> you
>> >> want to save changes or DELETE THIS TRANSACTION?"  Except that part is
>> >> not
>> >> bold or capitalized, so most people misread it and think it says
>> >> something
>> >> like, "Do you want to save or delete your changes?"  Choosing Delete 
>> >> here
>> >> actually deletes the entire GL transaction.
>> >>
>> >> If this happens, there is no way to get it back short of manually
>> >> entering a
>> >> GL transaction with the right numbers.  Usually you can figure out if
>> >> this
>> >> is what happened by checking for missing journal entry numbers around 
>> >> the
>> >> time that this would have been posted.
>> >>
>> >> To prevent this in later versions of GP you can disallow deleting GL
>> >> transactions by going to Tools > Setup > Financial > General Ledger 
>> >> and
>> >> unchecking Allow Deletion of Saved Transactions.  (I believe this is 
>> >> only
>> >> available in GP 8.0 and 9.0.)
>> >>
>> >> --
>> >> Victoria Yudin
>> >> Dynamics GP MVP
>> >>
>> >>
>> >> "Richard L. Whaley" <info@AccoladePublications.com> wrote in message
>> >> news:A6DE0E02-6325-4647-A7F2-2AD2A7549ED2@microsoft.com...
>> >> > You stated in your message that there were NO ERROR MESSAGES 
>> >> > GENERATED
>> >> > ON
>> >> > THE
>> >> > USER'S PC.  Posting error messages are printed on the posting 
>> >> > reports.
>> >> > Too
>> >> > often, people dont print these as they can be reprinted (if you do
>> >> > everything
>> >> > else correctly).
>> >> >
>> >> > First step:  Make sure all posting journals are printed and 
>> >> > examined,
>> >> > at
>> >> > least until the problems are resolved.
>> >> >
>> >> > Second step: Have you looked at the batches to see if there are any
>> >> > unposted
>> >> > transactions hanging around in the original batch.  Usually, if a
>> >> > transaction
>> >> > does not post, it stays in the system in the original batch.  It 
>> >> > wont
>> >> > post
>> >> > until the problem is resolved but you can try to post the batch, 
>> >> > print
>> >> > the
>> >> > reports, and examine them for errors.
>> >> >
>> >> > Of course, if you are not getting the option to print the posting
>> >> > reports,
>> >> > go to Tools->Setup->Posting->Posting Setup and turn on the reports 
>> >> > for
>> >> > AP
>> >> > and
>> >> > GL
>> >> >
>> >> > The usual suspect is missing or incorrect account numbers.  GP will 
>> >> > let
>> >> > you
>> >> > complete a setup without entering all of the account numbers and 
>> >> > many
>> >> > people
>> >> > leave these blank KNOWING they NEVER use those accounts.  This will
>> >> > frequently create transactions that cannot post.  Also, if you use 
>> >> > an
>> >> > account
>> >> > number as a default in a setup screen, and then delete the account
>> >> > number
>> >> > for
>> >> > some reason, it remains in the setup screen, but the transactions 
>> >> > using
>> >> > it
>> >> > will not post.
>> >> >
>> >> > Check this out and let me know if you need more.
>> >> > --
>> >> > Richard L. Whaley
>> >> > Author / Consultant / MVP
>> >> > Documentation for Software Users
>> >> >
>> >> > For help learning and better using Dynamics GP,... check out our 
>> >> > books
>> >> > at
>> >> > http://www.AccoladePublications.com
>> >> >
>> >> >
>> >> >
>> >> > "jziegler@wi.rr.com" wrote:
>> >> >
>> >> >> We've been using Great Plains (Dynamics V9) since 9/01/06, and are
>> >> >> having some serious problems when posting to GL. In one case, one
>> >> >> payment of two vouchers was lost going from A/P to GL. We only 
>> >> >> print
>> >> >> about 30 checks a week, so at the end of the month when we posted 
>> >> >> to
>> >> >> GL
>> >> >> and noticed the discrepancy, it was relatively easy to track down 
>> >> >> the
>> >> >> payment that was lost. The Accounting firm that helped with the
>> >> >> installation was of no help. Their solution was to create a journal
>> >> >> entry, which of course brough GL up to date, but didn't solve the
>> >> >> problem. Now this month, we're about $8,000 off between A/R and GL.
>> >> >> With about 150 invoices a day, tracking down this problem for a
>> >> >> month's
>> >> >> worth of invoices is nearly impossible. There were no errors 
>> >> >> messages
>> >> >> generated on the user's PC when the posting to GL was run. From 
>> >> >> both
>> >> >> the AP and AR sides, everything looks like it was posted.
>> >> >>
>> >> >> Has anyone run into a similar problem? Are there log files 
>> >> >> generated
>> >> >> within Great Plains when we post to GL that I could search through 
>> >> >> to
>> >> >> track this down? Any tables within the database that I could 
>> >> >> compare
>> >> >> to
>> >> >> see what might have not been posted to GL?
>> >> >>
>> >> >> Any help and/or ideas would be greatly appreciated.
>> >> >>
>> >> >> Joel
>> >> >>
>> >> >>
>> >
> 


0
victoria (3339)
12/13/2006 6:51:38 PM
Thanks for the continued interest.

The problem turned out to be how we had our posting settings, as you
suspected. We had the Sales/Receivables Entry set to Post by Batch.
When we changed that to Post by Transaction, the date in our flat file
was loaded into the RM10301.GLPOSTDT field, and then was used for the
posting date into GL.

With it set to Batch, the User Date from the user's PC was being put
into RM10301.GLPOSTDT, and even if the user changed the posting date
when she posted the A/R batch, the RM10301.GLPOSTDT did not change.
Since the AR Integration ran in an unattended mode in the evening, the
User Date in Great Plains defaulted to the system date. So, when we ran
some invoices through on 12/1/06, even thought they were posted into AR
in November, since the RM10301.GLPOSTDT date was set to 12/1/06, they
went into the GL in December.

The downside of the Post by Transaction setting, is that we have a lot
more transactions going into the GL, but at least they're going into
the correct month.

Thanks again for the help, and pointing me into the direction that
ultimately allowed us to solve the problem.

Joel



Victoria [MVP] wrote:
> Are you creating a new batch with the integration?
>
> What are your posting settings for this type of transaction?  Are you using
> the posting date from the batch or the transaction?
>
> --
> Victoria Yudin
> Dynamics GP MVP
>
>
> <jziegler@wi.rr.com> wrote in message
> news:1166027285.163839.173030@16g2000cwy.googlegroups.com...
> > In the Integration Manager setup, I have the Posting Date set to "Use
> > Source Field", and then map it to the same date field from the flat
> > file that is used to load the Document Date.
> >
> > The Document Date is set correctly in RM10301, but the Posting Date
> > picks up the Use Date from the Great Plains application.
> >
> > Do I need to do aomething else to get that Posting Date set correctly?
> >
> > Joel
> >
> >
> >
> > Victoria [MVP] wrote:
> >> Joel,
> >>
> >> Glad you were able to find the source of the issue!
> >>
> >> Yes, you should be able to specify the GL posting date in your
> >> integration -
> >> it is typically called Posting Date or GL Posting Date in the Integration
> >> Manager mapping.
> >>
> >> --
> >> Victoria Yudin
> >> Dynamics GP MVP
> >>
> >>
> >> <jziegler@wi.rr.com> wrote in message
> >> news:1166023165.462034.268520@l12g2000cwl.googlegroups.com...
> >> >I have more detail on this problem now, and could use some additional
> >> > help, focusing on the AR side. The problem occurs at the end of the
> >> > month, and relates to posting dates. An invoice batch was in the AR
> >> > system in November, but when it posted to the GL, it was posted into
> >> > December.
> >> >
> >> > We create invoices outside of Great Plains, and use the Integration
> >> > Manager to load the invoices into AR. We create invoices the day after
> >> > the orders ship. So, orders shipped on 11/30/06, have invoices created
> >> > on 12/01/06. The invoice date for these invoices is set to 11/30/06.
> >> > The AR Invoice integration runs on 12/01/06.
> >> >
> >> > The flat file of the invoices has the invoice date of 11/30/06 in each
> >> > record. The destination mapping uses this date to load both the
> >> > Document Date and the Posting Date in the Receivables Transaction. The
> >> > integration then runs unattended at night on 12/01/06, to integrate the
> >> > invoices.
> >> >
> >> > Looking at the data in the Great Plains table RM10301, the document
> >> > date, (RM10301.DOCDATE), for the invoices is set correctly to 11/30/06.
> >> > The Posting Date, (RM10301.GLPOSTDT), however, is set to 12/01/06.
> >> > (Although I haven't taken the time to prove this, I believe this is why
> >> > the transactions actually posted to GL in December.)
> >> >
> >> > In doing some additional investigation, it appears that the GLPOSTDT
> >> > date is set based on the User Date of the Great Plains application that
> >> > is running when the integration occurs. Since the integration is run
> >> > unattended and starts up the Grat Plains application as part of the
> >> > unattended process, the User Date defaults to the system date on the
> >> > server running the integration, which is 12/01/06.
> >> >
> >> > What table and field does the Posting Date in the Receivables
> >> > Transaction integration get loaded into?
> >> >
> >> > Is there a way to control, via the flat file integration, what date is
> >> > loaded into the GLPOSTDT field in RM10301?
> >> >
> >> > If you need more information, feel free to let me know.
> >> >
> >> > Thanks for the help.
> >> >
> >> > Joel
> >> >
> >> >
> >> >
> >> > Victoria [MVP] wrote:
> >> >> To add to Richards great suggestions....over the years I have seen
> >> >> this
> >> >> come
> >> >> up a few times.  Batches from the GL mysteriously disappear.  No
> >> >> errors,
> >> >> no
> >> >> problems, no one can tell what happened to them.  After you rule out
> >> >> anything like unposted transactions or batches stuck in Batch
> >> >> Recovery,
> >> >> etc., here is a scenario that can cause this:
> >> >>
> >> >> - Payables batch is posted and creates a GL batch.
> >> >> - Someone is looking at GL transactions in the Transaction Entry
> >> >> screen
> >> >> and
> >> >> looks at one of these transactions from the Payables batch....maybe
> >> >> they
> >> >> change something, maybe they just click around....
> >> >> - When they go to exit the screen, they get a message that says, "Do
> >> >> you
> >> >> want to save changes or DELETE THIS TRANSACTION?"  Except that part is
> >> >> not
> >> >> bold or capitalized, so most people misread it and think it says
> >> >> something
> >> >> like, "Do you want to save or delete your changes?"  Choosing Delete
> >> >> here
> >> >> actually deletes the entire GL transaction.
> >> >>
> >> >> If this happens, there is no way to get it back short of manually
> >> >> entering a
> >> >> GL transaction with the right numbers.  Usually you can figure out if
> >> >> this
> >> >> is what happened by checking for missing journal entry numbers around
> >> >> the
> >> >> time that this would have been posted.
> >> >>
> >> >> To prevent this in later versions of GP you can disallow deleting GL
> >> >> transactions by going to Tools > Setup > Financial > General Ledger
> >> >> and
> >> >> unchecking Allow Deletion of Saved Transactions.  (I believe this is
> >> >> only
> >> >> available in GP 8.0 and 9.0.)
> >> >>
> >> >> --
> >> >> Victoria Yudin
> >> >> Dynamics GP MVP
> >> >>
> >> >>
> >> >> "Richard L. Whaley" <info@AccoladePublications.com> wrote in message
> >> >> news:A6DE0E02-6325-4647-A7F2-2AD2A7549ED2@microsoft.com...
> >> >> > You stated in your message that there were NO ERROR MESSAGES
> >> >> > GENERATED
> >> >> > ON
> >> >> > THE
> >> >> > USER'S PC.  Posting error messages are printed on the posting
> >> >> > reports.
> >> >> > Too
> >> >> > often, people dont print these as they can be reprinted (if you do
> >> >> > everything
> >> >> > else correctly).
> >> >> >
> >> >> > First step:  Make sure all posting journals are printed and
> >> >> > examined,
> >> >> > at
> >> >> > least until the problems are resolved.
> >> >> >
> >> >> > Second step: Have you looked at the batches to see if there are any
> >> >> > unposted
> >> >> > transactions hanging around in the original batch.  Usually, if a
> >> >> > transaction
> >> >> > does not post, it stays in the system in the original batch.  It
> >> >> > wont
> >> >> > post
> >> >> > until the problem is resolved but you can try to post the batch,
> >> >> > print
> >> >> > the
> >> >> > reports, and examine them for errors.
> >> >> >
> >> >> > Of course, if you are not getting the option to print the posting
> >> >> > reports,
> >> >> > go to Tools->Setup->Posting->Posting Setup and turn on the reports
> >> >> > for
> >> >> > AP
> >> >> > and
> >> >> > GL
> >> >> >
> >> >> > The usual suspect is missing or incorrect account numbers.  GP will
> >> >> > let
> >> >> > you
> >> >> > complete a setup without entering all of the account numbers and
> >> >> > many
> >> >> > people
> >> >> > leave these blank KNOWING they NEVER use those accounts.  This will
> >> >> > frequently create transactions that cannot post.  Also, if you use
> >> >> > an
> >> >> > account
> >> >> > number as a default in a setup screen, and then delete the account
> >> >> > number
> >> >> > for
> >> >> > some reason, it remains in the setup screen, but the transactions
> >> >> > using
> >> >> > it
> >> >> > will not post.
> >> >> >
> >> >> > Check this out and let me know if you need more.
> >> >> > --
> >> >> > Richard L. Whaley
> >> >> > Author / Consultant / MVP
> >> >> > Documentation for Software Users
> >> >> >
> >> >> > For help learning and better using Dynamics GP,... check out our
> >> >> > books
> >> >> > at
> >> >> > http://www.AccoladePublications.com
> >> >> >
> >> >> >
> >> >> >
> >> >> > "jziegler@wi.rr.com" wrote:
> >> >> >
> >> >> >> We've been using Great Plains (Dynamics V9) since 9/01/06, and are
> >> >> >> having some serious problems when posting to GL. In one case, one
> >> >> >> payment of two vouchers was lost going from A/P to GL. We only
> >> >> >> print
> >> >> >> about 30 checks a week, so at the end of the month when we posted
> >> >> >> to
> >> >> >> GL
> >> >> >> and noticed the discrepancy, it was relatively easy to track down
> >> >> >> the
> >> >> >> payment that was lost. The Accounting firm that helped with the
> >> >> >> installation was of no help. Their solution was to create a journal
> >> >> >> entry, which of course brough GL up to date, but didn't solve the
> >> >> >> problem. Now this month, we're about $8,000 off between A/R and GL.
> >> >> >> With about 150 invoices a day, tracking down this problem for a
> >> >> >> month's
> >> >> >> worth of invoices is nearly impossible. There were no errors
> >> >> >> messages
> >> >> >> generated on the user's PC when the posting to GL was run. From
> >> >> >> both
> >> >> >> the AP and AR sides, everything looks like it was posted.
> >> >> >>
> >> >> >> Has anyone run into a similar problem? Are there log files
> >> >> >> generated
> >> >> >> within Great Plains when we post to GL that I could search through
> >> >> >> to
> >> >> >> track this down? Any tables within the database that I could
> >> >> >> compare
> >> >> >> to
> >> >> >> see what might have not been posted to GL?
> >> >> >>
> >> >> >> Any help and/or ideas would be greatly appreciated.
> >> >> >>
> >> >> >> Joel
> >> >> >>
> >> >> >>
> >> >
> >

0
jziegler (4)
12/14/2006 8:26:49 PM
Glad to help - thanks for the follow-up!

-- 
Victoria Yudin
Dynamics GP MVP


<jziegler@wi.rr.com> wrote in message 
news:1166128009.839350.109840@l12g2000cwl.googlegroups.com...
> Thanks for the continued interest.
>
> The problem turned out to be how we had our posting settings, as you
> suspected. We had the Sales/Receivables Entry set to Post by Batch.
> When we changed that to Post by Transaction, the date in our flat file
> was loaded into the RM10301.GLPOSTDT field, and then was used for the
> posting date into GL.
>
> With it set to Batch, the User Date from the user's PC was being put
> into RM10301.GLPOSTDT, and even if the user changed the posting date
> when she posted the A/R batch, the RM10301.GLPOSTDT did not change.
> Since the AR Integration ran in an unattended mode in the evening, the
> User Date in Great Plains defaulted to the system date. So, when we ran
> some invoices through on 12/1/06, even thought they were posted into AR
> in November, since the RM10301.GLPOSTDT date was set to 12/1/06, they
> went into the GL in December.
>
> The downside of the Post by Transaction setting, is that we have a lot
> more transactions going into the GL, but at least they're going into
> the correct month.
>
> Thanks again for the help, and pointing me into the direction that
> ultimately allowed us to solve the problem.
>
> Joel
>
>
>
> Victoria [MVP] wrote:
>> Are you creating a new batch with the integration?
>>
>> What are your posting settings for this type of transaction?  Are you 
>> using
>> the posting date from the batch or the transaction?
>>
>> --
>> Victoria Yudin
>> Dynamics GP MVP
>>
>>
>> <jziegler@wi.rr.com> wrote in message
>> news:1166027285.163839.173030@16g2000cwy.googlegroups.com...
>> > In the Integration Manager setup, I have the Posting Date set to "Use
>> > Source Field", and then map it to the same date field from the flat
>> > file that is used to load the Document Date.
>> >
>> > The Document Date is set correctly in RM10301, but the Posting Date
>> > picks up the Use Date from the Great Plains application.
>> >
>> > Do I need to do aomething else to get that Posting Date set correctly?
>> >
>> > Joel
>> >
>> >
>> >
>> > Victoria [MVP] wrote:
>> >> Joel,
>> >>
>> >> Glad you were able to find the source of the issue!
>> >>
>> >> Yes, you should be able to specify the GL posting date in your
>> >> integration -
>> >> it is typically called Posting Date or GL Posting Date in the 
>> >> Integration
>> >> Manager mapping.
>> >>
>> >> --
>> >> Victoria Yudin
>> >> Dynamics GP MVP
>> >>
>> >>
>> >> <jziegler@wi.rr.com> wrote in message
>> >> news:1166023165.462034.268520@l12g2000cwl.googlegroups.com...
>> >> >I have more detail on this problem now, and could use some additional
>> >> > help, focusing on the AR side. The problem occurs at the end of the
>> >> > month, and relates to posting dates. An invoice batch was in the AR
>> >> > system in November, but when it posted to the GL, it was posted into
>> >> > December.
>> >> >
>> >> > We create invoices outside of Great Plains, and use the Integration
>> >> > Manager to load the invoices into AR. We create invoices the day 
>> >> > after
>> >> > the orders ship. So, orders shipped on 11/30/06, have invoices 
>> >> > created
>> >> > on 12/01/06. The invoice date for these invoices is set to 11/30/06.
>> >> > The AR Invoice integration runs on 12/01/06.
>> >> >
>> >> > The flat file of the invoices has the invoice date of 11/30/06 in 
>> >> > each
>> >> > record. The destination mapping uses this date to load both the
>> >> > Document Date and the Posting Date in the Receivables Transaction. 
>> >> > The
>> >> > integration then runs unattended at night on 12/01/06, to integrate 
>> >> > the
>> >> > invoices.
>> >> >
>> >> > Looking at the data in the Great Plains table RM10301, the document
>> >> > date, (RM10301.DOCDATE), for the invoices is set correctly to 
>> >> > 11/30/06.
>> >> > The Posting Date, (RM10301.GLPOSTDT), however, is set to 12/01/06.
>> >> > (Although I haven't taken the time to prove this, I believe this is 
>> >> > why
>> >> > the transactions actually posted to GL in December.)
>> >> >
>> >> > In doing some additional investigation, it appears that the GLPOSTDT
>> >> > date is set based on the User Date of the Great Plains application 
>> >> > that
>> >> > is running when the integration occurs. Since the integration is run
>> >> > unattended and starts up the Grat Plains application as part of the
>> >> > unattended process, the User Date defaults to the system date on the
>> >> > server running the integration, which is 12/01/06.
>> >> >
>> >> > What table and field does the Posting Date in the Receivables
>> >> > Transaction integration get loaded into?
>> >> >
>> >> > Is there a way to control, via the flat file integration, what date 
>> >> > is
>> >> > loaded into the GLPOSTDT field in RM10301?
>> >> >
>> >> > If you need more information, feel free to let me know.
>> >> >
>> >> > Thanks for the help.
>> >> >
>> >> > Joel
>> >> >
>> >> >
>> >> >
>> >> > Victoria [MVP] wrote:
>> >> >> To add to Richards great suggestions....over the years I have seen
>> >> >> this
>> >> >> come
>> >> >> up a few times.  Batches from the GL mysteriously disappear.  No
>> >> >> errors,
>> >> >> no
>> >> >> problems, no one can tell what happened to them.  After you rule 
>> >> >> out
>> >> >> anything like unposted transactions or batches stuck in Batch
>> >> >> Recovery,
>> >> >> etc., here is a scenario that can cause this:
>> >> >>
>> >> >> - Payables batch is posted and creates a GL batch.
>> >> >> - Someone is looking at GL transactions in the Transaction Entry
>> >> >> screen
>> >> >> and
>> >> >> looks at one of these transactions from the Payables batch....maybe
>> >> >> they
>> >> >> change something, maybe they just click around....
>> >> >> - When they go to exit the screen, they get a message that says, 
>> >> >> "Do
>> >> >> you
>> >> >> want to save changes or DELETE THIS TRANSACTION?"  Except that part 
>> >> >> is
>> >> >> not
>> >> >> bold or capitalized, so most people misread it and think it says
>> >> >> something
>> >> >> like, "Do you want to save or delete your changes?"  Choosing 
>> >> >> Delete
>> >> >> here
>> >> >> actually deletes the entire GL transaction.
>> >> >>
>> >> >> If this happens, there is no way to get it back short of manually
>> >> >> entering a
>> >> >> GL transaction with the right numbers.  Usually you can figure out 
>> >> >> if
>> >> >> this
>> >> >> is what happened by checking for missing journal entry numbers 
>> >> >> around
>> >> >> the
>> >> >> time that this would have been posted.
>> >> >>
>> >> >> To prevent this in later versions of GP you can disallow deleting 
>> >> >> GL
>> >> >> transactions by going to Tools > Setup > Financial > General Ledger
>> >> >> and
>> >> >> unchecking Allow Deletion of Saved Transactions.  (I believe this 
>> >> >> is
>> >> >> only
>> >> >> available in GP 8.0 and 9.0.)
>> >> >>
>> >> >> --
>> >> >> Victoria Yudin
>> >> >> Dynamics GP MVP
>> >> >>
>> >> >>
>> >> >> "Richard L. Whaley" <info@AccoladePublications.com> wrote in 
>> >> >> message
>> >> >> news:A6DE0E02-6325-4647-A7F2-2AD2A7549ED2@microsoft.com...
>> >> >> > You stated in your message that there were NO ERROR MESSAGES
>> >> >> > GENERATED
>> >> >> > ON
>> >> >> > THE
>> >> >> > USER'S PC.  Posting error messages are printed on the posting
>> >> >> > reports.
>> >> >> > Too
>> >> >> > often, people dont print these as they can be reprinted (if you 
>> >> >> > do
>> >> >> > everything
>> >> >> > else correctly).
>> >> >> >
>> >> >> > First step:  Make sure all posting journals are printed and
>> >> >> > examined,
>> >> >> > at
>> >> >> > least until the problems are resolved.
>> >> >> >
>> >> >> > Second step: Have you looked at the batches to see if there are 
>> >> >> > any
>> >> >> > unposted
>> >> >> > transactions hanging around in the original batch.  Usually, if a
>> >> >> > transaction
>> >> >> > does not post, it stays in the system in the original batch.  It
>> >> >> > wont
>> >> >> > post
>> >> >> > until the problem is resolved but you can try to post the batch,
>> >> >> > print
>> >> >> > the
>> >> >> > reports, and examine them for errors.
>> >> >> >
>> >> >> > Of course, if you are not getting the option to print the posting
>> >> >> > reports,
>> >> >> > go to Tools->Setup->Posting->Posting Setup and turn on the 
>> >> >> > reports
>> >> >> > for
>> >> >> > AP
>> >> >> > and
>> >> >> > GL
>> >> >> >
>> >> >> > The usual suspect is missing or incorrect account numbers.  GP 
>> >> >> > will
>> >> >> > let
>> >> >> > you
>> >> >> > complete a setup without entering all of the account numbers and
>> >> >> > many
>> >> >> > people
>> >> >> > leave these blank KNOWING they NEVER use those accounts.  This 
>> >> >> > will
>> >> >> > frequently create transactions that cannot post.  Also, if you 
>> >> >> > use
>> >> >> > an
>> >> >> > account
>> >> >> > number as a default in a setup screen, and then delete the 
>> >> >> > account
>> >> >> > number
>> >> >> > for
>> >> >> > some reason, it remains in the setup screen, but the transactions
>> >> >> > using
>> >> >> > it
>> >> >> > will not post.
>> >> >> >
>> >> >> > Check this out and let me know if you need more.
>> >> >> > --
>> >> >> > Richard L. Whaley
>> >> >> > Author / Consultant / MVP
>> >> >> > Documentation for Software Users
>> >> >> >
>> >> >> > For help learning and better using Dynamics GP,... check out our
>> >> >> > books
>> >> >> > at
>> >> >> > http://www.AccoladePublications.com
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > "jziegler@wi.rr.com" wrote:
>> >> >> >
>> >> >> >> We've been using Great Plains (Dynamics V9) since 9/01/06, and 
>> >> >> >> are
>> >> >> >> having some serious problems when posting to GL. In one case, 
>> >> >> >> one
>> >> >> >> payment of two vouchers was lost going from A/P to GL. We only
>> >> >> >> print
>> >> >> >> about 30 checks a week, so at the end of the month when we 
>> >> >> >> posted
>> >> >> >> to
>> >> >> >> GL
>> >> >> >> and noticed the discrepancy, it was relatively easy to track 
>> >> >> >> down
>> >> >> >> the
>> >> >> >> payment that was lost. The Accounting firm that helped with the
>> >> >> >> installation was of no help. Their solution was to create a 
>> >> >> >> journal
>> >> >> >> entry, which of course brough GL up to date, but didn't solve 
>> >> >> >> the
>> >> >> >> problem. Now this month, we're about $8,000 off between A/R and 
>> >> >> >> GL.
>> >> >> >> With about 150 invoices a day, tracking down this problem for a
>> >> >> >> month's
>> >> >> >> worth of invoices is nearly impossible. There were no errors
>> >> >> >> messages
>> >> >> >> generated on the user's PC when the posting to GL was run. From
>> >> >> >> both
>> >> >> >> the AP and AR sides, everything looks like it was posted.
>> >> >> >>
>> >> >> >> Has anyone run into a similar problem? Are there log files
>> >> >> >> generated
>> >> >> >> within Great Plains when we post to GL that I could search 
>> >> >> >> through
>> >> >> >> to
>> >> >> >> track this down? Any tables within the database that I could
>> >> >> >> compare
>> >> >> >> to
>> >> >> >> see what might have not been posted to GL?
>> >> >> >>
>> >> >> >> Any help and/or ideas would be greatly appreciated.
>> >> >> >>
>> >> >> >> Joel
>> >> >> >>
>> >> >> >>
>> >> >
>> >
> 


0
victoria (3339)
12/14/2006 8:42:10 PM
Reply:

Similar Artilces:

Transaction to read when no actual transaction
I have an account called 'Honda accord'. It is an asset account that has a loan associated with it. The loan account is 'Honda loan.' I imported a transaction into Honda accord and says i have 1 transaction to read. I have view all dates/transactions selected and nothing comes up. The box to the left says i still have a transaction to read and I cant find the darn thing. Any Ideas???? -- Stephen and Erica Chenelle In microsoft.public.money, Stephen & Erica Chenelle wrote: >I have an account called 'Honda accord'. It is an asset account that has a >...

Will somebodu response to this post
Hi No need to apologise since you were drunk and unaware of what was going on. Regards Roberts ...

Batch Not Posting
Hello all, we have an issue where when we attempt to post from several different modules it gets so far then kills great plains. we have to go into the batch recovery run the batch recovery at which time it will print the reports them GP dies again. then we have to go back into batch recovery and hit cancel on all the reports and it will them post the batch. TIA ...

Paid Transaction Removal not removing some transactions
When running Paid Transaction Removal two transactions for an account were not removed to history while seemingly identical transactions in another account were. As I understand the rules of paid transaction removal, a transaction will be removed if it meets the following criteria. 1. If it's an invoice it must be fully paid. 2. If it's a payment, the document amount must be fully applied to one or more invoices. 3. The removal date must be after the document date. The documents are debit notes, are fully paid off (CURTRXAM = .00000) and the document dates precede the cut-off d...

PM Transaction Work vs Open
What is the difference between PM_Transaction_WORK and PM_Transaction_OPEN? Thanks, Steven work = saved open - posted "Steven" wrote: > What is the difference between PM_Transaction_WORK and PM_Transaction_OPEN? > > Thanks, > Steven As an add on, the work also includes recurring transactions. "Doug" wrote: > work = saved > open - posted > > "Steven" wrote: > > > What is the difference between PM_Transaction_WORK and PM_Transaction_OPEN? > > > > Thanks, > > Steven Thanks, Guys! Steven "klewis&quo...

How are transactions automatically assigned to categories?
When I download my credit card statements into Money, I notice that some of them are automatically assigned to categories. How does Money do this? Is the information included in the info I download from my bank, or are there rules within money? More importantly, how can I add my own rules to auto- categorize things? Thanks! -Aaron ...

V10 - Transaction by debtor enquiry report
Hi, Anyone any ideas why when printing the transaction by debtor enquiry report, the last digit of the amount is dropped off? This is when printed as A4 - payables is okay going to same printer. Okay when displayed to screen - only lost when actually printed. Thanks Jean -- JB Is the last digit perhaps trying to print outside the 'printable' area of the printer? If you do not use A4 paper does it work? Do you have the A4 module installed? "JB" wrote: > Hi, > > Anyone any ideas why when printing the transaction by debtor enquiry report, ...

Receivables transactions not aging individual transactions
Looking at smartlist, the Receivables transactions have a search/favourite added, including the aging periods. When you look at the search, it doesn't age the individual transactions, but instead ages the entire customers balance. I would expect it to show the aged balance per transation. Assessment: With how Smartlist is currently designed, the default smartlist object pulls from the Summary table for those aging period amounts. This is the reason why it does not show the aging for individual transactions. I know that the ability to see the aging of the individual accounts would b...

TRANSACTION and SELECT *
Hi all I have a question about SQL Transactions: For example, I have a table with 3 rows (ID 1, 2 and 3). Now I insert a new row within BEGIN TRANSACTION, and I do not commit yet. In another SQL Session, I try to select data. When I do SELECT * FROM Table, it is blocked. When I do SELECT * FROM Table WHERE ID = 2 I get a result. How can I make SELECT * FROM Table possible even when there is a open Transaction ? Of corse I only expect to get the ID's 1, 2 and 3 back and not the new row. I have looked about IsolationLevel, but this does not help. Thanks for any comments ...

Rounding on Investment transactions
I've seen this problem for quite a while in Monday (at least 01, 02, 03, and 04). But when I'm entering my transactions, often times the final amount (shares*cost+comm) don't equal out, it's always the matter of 1 penny, but I'm a bit anal that way. For instance. 0.78800 shares at 27.8900 per share. Fully worked out it comes to 21.97732. So when Money does the transaction it rounds it to 21.98 (makes perfect sense). My brokerage relays the cost as 21.97. What options do I have to make these transactions actually work out? Since I can't do a negative commis...

Debugging SQL Server 2005 Transact SQL
I have an urgent requirement to debug Transact-SQL in SQL Server 2005 and I have a couple of questions. 1. Are there any *free* programs that will allow me to debug (step through line-by-line, look at cursor results, variables, etc). 2. If the answer is 'no' and Visual Studio is the least expensive alternative, which versions are compatible and have debugging capability? Thank you very much in advance. allanc (allan.for.g.groups@gmail.com) writes: > I have an urgent requirement to debug Transact-SQL in SQL Server 2005 > and I have a couple of questions. > 1. Are th...

Receivables Transaction Entry #2
Anyone have any idea why the Address ID does not get saved on the Receivables Transaction Entry when posted? -- Japheth Nolt Microsoft SBF Specialist Landis Computer www.landiscomputer.com 5/4/2007 3:27:40 PM There is no field available in the Receivables Open table to store it! I have put in this suggestion since version 5.5, and it still hasnt happened. You will have to develop a customisation to track it in a parrellel table. (Or use VBA & DUOS table) ------ Robert "Japheth Nolt" <japheth.remove@landiscomputer.com> wrote in message news:xn0f5t47t3uqcr000@msnews....

Error Accessing File. Network connection may have been lost.
I recently upgraded to Office 2k3 SP3, and applied the hotfix. Now I am getting the message above almost every time I try to bring an Access 2003 database home from work. The Microsoft KB indicates this has to do with having Access 2000 and Version 6.3.91.8 of the Vbe6.dll file installed and that you have either imported or copied/pasted forms or reports that contain code module or standalone modules into an Access2000 database. Did this particular version of the Vbe6.dll file come out with SP3? The resolution (if you have a machine without this annoying vbe6.dll file) is to export ...

PM/RM Batch--Transaction Threshold?
1) Does anyone have insight as to the practical limits on the number of transactions which either a PM or RM batch can hold/process prior to presenting a problem. 2) We have had problems in past scenarios where high-transaction volume batches (200+) have caused system problems with posting to the G/L and the Sub-ledgers of either RM or PM. Any way to avoid this w/o reducing the number of transactions contained in the batch? ...

Unable to Post Payables (Computer Check) Batch
We have a Payables (Computer Check) Batch that we are unable to post. Originally the post was stuck with the status of "posting". We followed the steps to unlock this batch (Link to Instructions appear below): https://mbs.microsoft.com/customersource/productsservices/products/articles/111005_tntgp.htm?printpage=false This has worked for us in the past. After unlocking the Payables Batch the status changed to "Available". Unfortunately the batch still shows a "Last Date Posted" of 01-14-08 which was the date we first tried to post this batch. Since this...

Batch is Receiving Transactions
After going to Transaction>>Financial>>General, clicking on the find and trying to double-click on on a Batch, I receive the message "This batch is receiving transactions." This transaction and another one posted at the same time have been showing this message for over 24 hours. Is there a way to clear/fix this message so the entries can be viewed and posted to the GL? There are 2 things you can check. First check the Dynamics table SY00800 for records related to the batches and clear these records after checking to see that no one is logged into Great Plains. ...

Paid Sales Transaction Removal error message
Hola Familia When I try to do run a "Paid Sales Transaction Removal" against a specify customer (Microsoft Dynamics GP menu >> Tools >> Routines >> Sales >> Paid Transaction Removal) in Dynamics GP 10 with SQL 2005, I get the following error: [Microsoft] [SQL Native Client] [SQL Server] Violation of PRIMARY KEY constraint ‘PKRM30101’. Cannot insert duplicate key in object 'dbo.RM30101'. I searched for the error message in Customer Source Knowledge base and found Article ID : 861084, which I followed and it showed the duplicate document (invoice...

System Message 6654: Subaccount is invalid for posting.
Please help! I got the message in the view log when posting a batch thru Post Transaction screen in Solomon 5.5. We have verified all the subaccounts and can't see anything wrong. Thanks, Claudia, Sorry, you're in the wrong newsgroup - this is for Dynamics GP (formerly Great Plains). The one you're looking for is microsoft.public.solomon. -- Victoria Yudin Dynamics GP MVP "Claudia" <calejos@mpiphp.org> wrote in message news:1165272923.748961.178760@f1g2000cwa.googlegroups.com... > Please help! > I got the message in the view log when posting a batch ...

Analytical Accounting Dimension ID for Bank Transaction
Hi. can any one help me out in finding TABLES of AA from which i can link dimensions assigned in the Bank Transaction. I need create a crystal report for it. Thanks in advance!! ...

Reconcile old bank transaction
We switched from bank A to bank B and when I go to Checkbook Balance Inquiry screen, the old bank A still show current checkbook balance with a negative value. The transition from bank A to B are all correct in paper works, but not in the GP. When I look at the data for 2 transactions in tables, I noticed 1 of the transaction is reconciled and the other is not; otherwise, every values are identical. How would I fix this negative balance on old bank? Thanks! ...

Transaction Remains as Transaction to Read
I am using MSMNY03 deluxe on XPpro. One checking account registered transaction remains in the list of Transactions to Read and I have not been able to "Accept Transaction". The account register has a note attached saying: "This downloadable transaction is a probabale match to a manually entered transaction. " After clicking on Accept in the account register, the note remains and the Transaction to Read list remains with that one remaining transaction to be read. How can this be corrected ? de ~Vince~ Have you tried clicking "change" instead? Susan "...

GP10: Payables Transaction Inquiry-Vendor window
Hello All I'm having a problem seeing the vendor records in the payables tranaction inquiry-vendor window for some users only (including sa). I've checked the user security settings & assigned the same security role ID to the problematic users as the security role ID that is working properly. I've marked (and unmarked) the task ID but nothing seems to solve the problem. Any ideas how to fix please? ...

Eaton Vance Direct Online Services
I'm finally adding direct downloads from a number of my accounts. When I set up Eaton Vance online services and connect, all that downloads is my account share balance - no transactions and no account dollar value. The register show the # of shares. The account list shows a dollar value of $0.00. When I look at account settings, for some investment accounts" track cash transactions" is an option; for Eaton Vance it is not. Is this a limitation placed by Eaton Vance, or else what do I need to change to download transactions and account values? TIA In microsoft.public.money, k...

Import RMS GL distributions
During our GP implementation, our VAR set up one of our GP client computers for importing RMS batches into our GL. She created a shortcut which brings up a small dialog window with just the following on it: Window title: Import GL Distributions File to Import: [text box to browse to RMS-exported XML file] [check box] Print Import Journal [check box] Print the General Ledger Transaction Edit List [OK] [Cancel] The shortcut properties show: Window: 3rd party - Import GL Distributions I need to do this on a computer different than the one she set it up on, but I cannot find the window ...

Investment Transactions not appearing in Cash Transactions
The Cash Transactions register is missing items that are present in the Investment Transactions register, causing the month-end money balance to not reconcile with the monthly statement from my brokerage. I'd like to try deleting all my transactions back through the most recently reconciled month, and downloading them all again. Is there any way to do that? Version: Money2001 Deluxe & Business thank you, /Jim What kind of items are missing? Buys and Sells? -- Michael Gordon MVP "Jim F" <hedgefund2020@comcast.net> wrote in message news:694601c3e668$b32bb8...