Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Supplier invoice date and GRN date
abanerji
Member Posts: 3
I have been auditing systems of one of our entities. They have recently implemented NAV 2009 R2 version 6.
One of their foreign supplier's commercial term for delivery of goods is Ex-Works. The risk in the goods, and liability to pay the supplier, both start from the date of invoice of the supplier.
In Navision's scheme of entry, GRN precedes supplier invoice capture. However, in this case, for true representation of transactions, it is necessary that the invoice be entered first (based on the electronic copy which is received say on Day 1).
The imported goods are received, and GRN made, say on Day 10. Hence, from Day 1 to Day 9, the yet-to-be received goods are to be considered as goods-in-transit.
The foreign supplier's payment term is "net 30 days". So, the due date of settling this invoice is Day 30. If Day 1 is 1st January, Day 30 is 30th January. In the AP ledger for this supplier's account, due date should appear as 30th January. However, in NAV, if "posting date" can only be Day 10 (i.e., 10th January), i.e., the date of GRN, the due date will not appear as 30th January, but as the incorrect 9th February. Any payment plan made (based on such incorrect date) would require manual scrutiny and modification.
To summarise, the queries are two :-
a) Is it possible to enter supplier invoice, before GRN? If not, what is the way to solve this?
b) How to get the supplier's invoice date as "posting date", so that due date becomes correct?
By the way, my search in the forum came up with this link ( viewtopic.php?f=23&t=45470 ), where on a similar query, the post says "This topic has been discussed many many times on both forums. if you search you will find a lot of answers". However, I could not find any other relevant answer. If anybody can provide specific links, it would be appreciated.
One of their foreign supplier's commercial term for delivery of goods is Ex-Works. The risk in the goods, and liability to pay the supplier, both start from the date of invoice of the supplier.
In Navision's scheme of entry, GRN precedes supplier invoice capture. However, in this case, for true representation of transactions, it is necessary that the invoice be entered first (based on the electronic copy which is received say on Day 1).
The imported goods are received, and GRN made, say on Day 10. Hence, from Day 1 to Day 9, the yet-to-be received goods are to be considered as goods-in-transit.
The foreign supplier's payment term is "net 30 days". So, the due date of settling this invoice is Day 30. If Day 1 is 1st January, Day 30 is 30th January. In the AP ledger for this supplier's account, due date should appear as 30th January. However, in NAV, if "posting date" can only be Day 10 (i.e., 10th January), i.e., the date of GRN, the due date will not appear as 30th January, but as the incorrect 9th February. Any payment plan made (based on such incorrect date) would require manual scrutiny and modification.
To summarise, the queries are two :-
a) Is it possible to enter supplier invoice, before GRN? If not, what is the way to solve this?
b) How to get the supplier's invoice date as "posting date", so that due date becomes correct?
By the way, my search in the forum came up with this link ( viewtopic.php?f=23&t=45470 ), where on a similar query, the post says "This topic has been discussed many many times on both forums. if you search you will find a lot of answers". However, I could not find any other relevant answer. If anybody can provide specific links, it would be appreciated.
0
Comments
b. Set the Posting Date to 01, or change the Due Date manually into 30.
Andwian
1. If a "final" supplier invoice is considered as a "prepayment" (proforma?) invoice, in NAV, how would the final invoice be accounted again? Like I mentioned in my OP, I am an auditor, and do not know how NAV works fully. I am sure that the NAV team in the local business here are technically trained to deal with all aspects of NAV, and during my discussions with them, their initial response has been that the NAV supplier / goods process is standardised (manifested by GRN preceding invoice entry), and there is no possibility of a workaround. I shall definitely mention this "prepayment" suggestion to them again, and see their reaction.
Meanwhile, a 2011 post in this forum ( viewtopic.php?t=47005 ) says : "There are many bugs related to Prepayment Invoices that are KB articles on Partnersource ...". So, are the so-called "bugs" still there, or resolved by the NAV developers?
2. You suggestion to change the due date manually is one more step in freedom to the data entry person, which may cause errors. Once the supplier payment terms are in the "master" database (or, whatever it is called in NAV), the program should populate the due date field automatically.
Once the GRN is made, you must keep post the receipt as invoice. But, this time, the invoice should be 0, since you must reverse the Prepayment.
This one is made automatically using Prepayment feature. This is a local feature. Don't know if this is exist in India (?) version.
And yes, you are true about the fact that there are many bugs
When I receive a fix for one thing, the other part arise a bug. Sometimes, it damage the standard part.
I don't know, maybe because it is a local feature, and there is a crash with the base feature.
Lastly, I have received the private fix (not official) by the MS, but my user become frustrated, and they do not want to use the prepayment feature anymore. Hence, I use the workaround to use the prepayment. A bit complicated, actually.
Andwian