"POSTING NO." getting block in Purchase header table

lavanyaballurgi
Member Posts: 235
I am back with an ancient problem. Sometime due to some error popping up while posting an purchase order/invoice the POSTING NO. field will lock a posting No. i.e. the LAST NO. USED in that number series gets updated to next number even though this current No. is not posted.
Hope you are getting.
e.g. in invoice posting no series the last number used is "abc/0005" now if i try to post order/invoice "PO/0001" & encounter some error the number "abc/0006" get locked in this "PO/0001" and if I post next order/invoice e.g. "PO/0002" it get posted with "abc/0007". Now auditors ask where "abc/0006" went?
how to avoid this locking of number is PO?
Hope you are getting.
e.g. in invoice posting no series the last number used is "abc/0005" now if i try to post order/invoice "PO/0001" & encounter some error the number "abc/0006" get locked in this "PO/0001" and if I post next order/invoice e.g. "PO/0002" it get posted with "abc/0007". Now auditors ask where "abc/0006" went?
how to avoid this locking of number is PO?
0
Comments
-
Not sure why it's that important but you can go into last No used and change it if you need to.
So what you are saying is that during posting you get "some" error (which your should elaborate on) and due to this error it's skipping a posting no in the series?
Do you have Posting No. Field showing on the Purchase header.
After this error is this field being populated?0 -
yes the field "posting No." gets filled with the next number available in No. series.
No the "Posting no." field is displayed in header. Well its important because here they want the posted document to be in series.
One solution is what you said but for that I need to check this field everytime myself & update the No. series. I want to get this done automatically.0 -
Obviously everything works as desired as long as no error occurs or someone doesn't hit - cancel - in the middle of posting.
I just seems like alot to have each po you want to post search thru every already posted inv to make sure the next number used is actually the true next number and no gap exists.
Where we are, we treat a PO Posting number as just a system number that holds really no value as far as business practices. As long as the po posts to the correct vendor, with the correct dates & terms, with the correct Vendor Invoice No. then we are good to go.0 -
Savatage wrote:I just seems like alot to have each po you want to post search thru every already posted inv to make sure the next number used is actually the true next number and no gap exists.
Harry in a growing number of countries this is becoming a legal requirement. Even in the UK,m although not a legal requirement, many auditors are requesting this. Many APAC and South American countries have this as a legal requirement. Even some European countries already have this as law. And more governments are starting to make it a legal requirement.
So it really is quite important.David Singleton0 -
Then the next version or update should have some FINDLAST function on the vendor Ledger entries and have it compare to the number series next number to allow posting. (If "No Gaps In Posting No" is checked in the Setup table = additional change) Pehaps even POP up the No Series form on error so the user can update the number.
I've notice a skipping in the posting number can be cause by a number of unexpected things and hard to predict when it will happen. And if it's a number anyone can change/update it then seems like gov. overkill to control it.
What if there is a gap and I change the number series & post to fill that gap, then put the no series back to where it was. Is that legal? What does it actually prevent?0 -
It's not a new issue, some country versions of Navision have had this functionality since version 2.01. But it is very problematic, and most specifically in regards to performance.David Singleton0
-
David Singleton wrote:It's not a new issue, some country versions of Navision have had this functionality since version 2.01. But it is very problematic, and most specifically in regards to performance.0
-
Wow ... its an honour so see all experts replying to my query
Well I am not sure if this is a legal requirement in India but what my end users told me is that auditor will ask lots of questions about this missing number.
So as per you guys there is no such solution exist? Is there a possibility of designing any solution for this? or we need to ](*,) with this problem?0 -
You can develop a process only report and run it periodically (especially, before audits..
which will generate and replace the numbers in the order of posting date.
Chn0 -
That was [-X a good solution [-(
but even this solution can not change already posted invoices0 -
... but I can't figure out anything else at the moment..
0 -
Back to this post. I do notice that when I post an Item Journal - CU23 throw an error if my Document # is not the Next one or the one it's supposed to be..
// Post lines LineCount := 0; LastDocNo := ''; LastDocNo2 := ''; LastPostedDocNo := ''; FIND('-'); REPEAT IF NOT EmptyLine AND (ItemJnlBatch."No. Series" <> '') AND ("Document No." <> LastDocNo2) THEN TESTFIELD("Document No.",NoSeriesMgt.GetNextNo(ItemJnlBatch."No. Series","Posting Date",FALSE));
My guess is you would need to implement something like this to prevent gaps.
Another question is how many gaps are you experiencing a month on average. If it's under 5 I would ask, to whomever wants the gap details, if they would except a screenshot or a notification email when it happens. see if that will suffice before making system changes.0 -
Problem resolved, I did not have a COMMIT after my code.
Works fine now.
I have the opposite problem.
NAV2009 R2
I NEED the Header to be updated when posting the invoice so that if there is an error I can check which invoices failed to post but have been allocated the next number.
In the older versions of NAV, this was done for the Posting No. and caused some problems.
However, I cannot now see how to make it work in NAV2009.
Ideally I need a new Boolean field, Posting, to be set to TRUE when the user Posts the Invoice.
Then if the post fails for any reason, I know that the attempt was made.
I have tried inserting code in CU80 in the same place as the old code (Navision 4.1) that populated the Posting No. but it all rolls back on error and the Sales header is not modified.
Can someone tell me how to deliberately update the header?Experience is what you get when you hoped to get money0
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
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions