Skip to main content

Notifications

Announcements

No record found.

Finance | Project Operations, Human Resources, ...
Answered

Integration posted with a year of 2065

Posted on by 10

I'm struggling to make this make sense in my mind so, bare with me:

We've recently begun entering our American Express transaction by "only" using Great Plains! Previously this was done using an outside source/company that imported the transactions into GP. I've introduced the process of entering the transaction to the VENDOR and paying it out to the CREDIT CARD section, selecting our AMEX. As you may or may not know, you can typically input a date (within the open period) of the "AMEX CHARGE" in the same screen. NO BIG DEAL! Especially at my previous company, no issues here! 

My new company uses INTEGRATIONS, love them btw. There was an integration done and the date in the spreadsheet was entered as, 06/02/2065 and it actually allowed the transaction to be integrated as such. With that said as normal, in the VENDOR we had an INVOICE and a PAYMENT: invoice dated 06/04/2020 (the posting date and day this was done) and the payment date was 06/02/2065 which came from the data entry error in the integration spreadsheet. As a result, the open transaction under the AMEX cc vendor says, 06/02/2065. This method of entering cc rcpts is new to this company and integrations are new to me so, we're kind of at a disadvantage to each other when trying to figure out why this worked. It should not have allowed a transaction to post to the year, 2065.

My questions are: 1)WHY did it not flag or fail the integration? The fiscal year for 2065 is not yet open! (2)Is there a setting that will make it flag the transaction if this happens again? (which I hope it NEVER happens again)

I also feel the need to add, I tried to simulate the same error within our test company and it in fact, DID give me an error message pertaining to the "fiscal period" and the integration FAILED. Perfect, actually. That's what I would want to happen. Why did this not happen the same way before? This is also a new integrations we've set up as well. I'm mostly trying to avoid this from happening again. I'm aware that I can create a credit for the wrong year and apply the two, to net the transactions to 0 for the year 2065. I want to prevent this from accidentally going through again and I feel it's a setting that is not properly set.

PLEASE HELP!

Categories:
  • ACH HELP Profile Picture
    ACH HELP 10 on at
    RE: Integration posted with a year of 2065

    Isaac, I forgot to add... I couldn't void historical or open! I kept getting an error that my voiding date couldn't be "before the document date" which was in the year 2065, sort of impossible! I even tried manipulating the date, that's didn't work! The error then was, "The fiscal period hadn't been set up yet". Also tried to update the transaction information through the Financial Smartlist. I won't even elaborate on how I broke this even further lol... I wish I would have just stuck with the eye sore. However, my AC has much less GP experience and was nervous about the posting date. I had a strong feeling it was ok and posted in the current period.

  • ACH HELP Profile Picture
    ACH HELP 10 on at
    RE: Integration posted with a year of 2065

    That definitely helps also, thanks for adding that! That's exactly what I was thinking but I didn't want to call that out to my Assistant Controller, didn't want to be rude. I figured the main focus when opening and closing different fiscal periods would be the month, please correct me if I'm wrong on that thinking. I love to learn new things and I'm self taught so this is awesome … I'm really nerding out :) (no offense) thanks a lot Brandon! I'm definitely going to review the resource you sent.

  • ACH HELP Profile Picture
    ACH HELP 10 on at
    RE: Integration posted with a year of 2065

    Isaac, 

    I was only pointing out the Payables vs. Receivables for clarity if you were able to help with my other issue. I looked at the posting settings briefly to try to help with another issue. 

    I would definitely like to bounce ideas back and forth with you maybe via teams or email. Is that something you would be ok with?

  • Verified answer
    Hokuminaria Profile Picture
    Hokuminaria 2,950 on at
    RE: Integration posted with a year of 2065

    Hello,

    I would like to add on to what Isaac said.

    In Payables, we are not checking the Fiscal Periods to see if that period is setup. It will allow you to post to any year even if it is not setup.

    Now, we do have a PSTL tool that will verify the date exists within a Fiscal Period. This is called the Doc Date Verify tool. Please review Chapter 8 in the article below that goes over the Doc Date Verify Tool.

    docs.microsoft.com/.../profservicestoolslibrary

    I hope this helps!

    Thank you!

    Brandon Jarrett | Microsoft Support Engineer.

  • Suggested answer
    Isaac Olson Profile Picture
    Isaac Olson on at
    RE: Integration posted with a year of 2065

    No problem, and yes sorry for the confusion between Receivables and Payables.  At one point you had mentioned credit card receipts and we can enter Cash Receipts as Credit Card Payments in the Receivables module, so my mind was over there, but the screenshot would be the same idea, just in Purchasing rather than Sales.  To If you can live with the date, you can just leave it or if you wan tto clean up that date, you could void this payment (Purchasing >> Transactions >> Void Historical Transactions) and re-enter it with the correct dates.  Its going to be more of a visual eye sore than anything else, not a huge deal.  

    I hope this helps!

    Isaac Olson

    Microsoft Support

  • ACH HELP Profile Picture
    ACH HELP 10 on at
    RE: Integration posted with a year of 2065

    Isaac, 

    Thank you so much for your feedback, very helpful and easy to understand! So, to answer your initials questions:

    1) Yes, I'm referring to "Integration Manager" 

    2) After hammering and hammering away at it, I did realize the date of 6/2/2065 was only the document date! Specifically the document date for the American Express transaction that was created from the original vendor invoice/entry, that was paid out to AMEX.

    To piggy back off of question 2; with only the document being 2065 and not the posting date - was it really that big of an issue? Obviously we want our documents, records, dates, transactions etc all entered and processed correctly, make no mistake about that! The posting date was 6/4/2020 which came from the batch. So my thought now after the fact is, the year 2065 looks completely ridiculous but my transaction was posted in the correct month and year! (Correct, Isaac?) I've included two images, the Vendor Trans & the Amex transaction! I believe our settings are set to use the "posting date" of the "batch". When Integration Manager imported the batch into GP, it was given a batch date of 6/4/2020 which would be automatic due to our posting setting(s), if I'm understanding correctly. 

    MSHelps-2.pngMSHelps.png

    Now I have a clear understanding of why the Integration Manager did not flag the transaction! Furthermore, the posting settings are likely not the same in the Test Company at the moment which could also explain why it didn't yield the exact same result. I'm interested in how the posting settings can affect different things, in different ways. Again, thank you so much! 

    Also, would you mind taking a look at my ACH question I posted prior to this? I noticed your screenshot of the post settings was from the sales side, I would be working with the PURCHASING side (I'm in payables, not sure if that matters. 

    Thanks a lot Issac!

  • Verified answer
    Isaac Olson Profile Picture
    Isaac Olson on at
    RE: Integration posted with a year of 2065

    Hello, 

    In order to narrow this down a bit, I have a couple of questions that I just wanted to verify based on your summary, which has awesome detail, so thank you!

    1. When you say INTEGRATIONS, do you mean that you are using 'Integration Manager' or is INTEGRATIONS a Third Party or Customization that you have in place? 

    2. Which Date specifically is the 06/02/2065 on the transaction? For example we have the Document Date, Posting Date, Apply Date?  

    The reason that I ask, is you could have a document date that is outside of the fiscal periods, but a posting date that is within the fiscal periods, and post that without issue. 

    The other thing to consider is your posting setup.  (Tools>>Setup>>Posting>>Posting)  You can choose here, whether or not are you going to use the posting date from the batch or the transaction as the Posting date.  

    2210.Capture.PNG

    If you are using Integration Manager, it is not going to let you do anything that you are not allowed to do through front end GP, because for Cash Receipts it is just running a macro to populate the data into the windows.  My guess would be that either the integration is not 1 to 1 between your test and live company, or the setups are not 1 to 1 if you get a warning in one and not the other.  

    My recommendation would be to try running the exact same 2065 integration in live again just with a different document number, then click on the blue arrow next to the date on the Cash Receipt Entry window and see if it truly is 2065 for both posting and document date, or just one or the other.  

    For this transaction you can go to (Sales >> Transactions >> Posted Transactions) and void it, so you can bring it back in at the correct date.  

    I hope this helps!

    Isaac Olson

    Microsoft Support

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

December Spotlight Star - Muhammad Affan

Congratulations to a top community star!

Top 10 leaders for November!

Congratulations to our November super stars!

Tips for Writing Effective Suggested Answers

Best practices for providing successful forum answers ✍️

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 291,253 Super User 2024 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 230,188 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Product updates

Dynamics 365 release plans