I want to know how 3 way matching is possible in Navision and i dont have any idea abut that…
can you help me in it in any way possible …
thanx in advance
I want to know how 3 way matching is possible in Navision and i dont have any idea abut that…
can you help me in it in any way possible …
thanx in advance
What do you mean by 3-way matching?
Actually what i understood from the perspective of other ERP is that In Purchase Order the qunatitiy you orderd ,the goods you received and the invoice must match so that there should be not any error in payable in general ledger …
Other ERP like SAP support that feature when there is diffrence between these.
But in Navision you can receive and invoice less than or equal to what you ordered but if there is a diffrence suppose e.g.
you ordered for 100 CAN you receive 105 and you want the invoice for 100 and like other cases where these three figures will not match
so it is possible in Navision or any other alternative i think its possible in GP so idea how to get that in Navision wil be very helpful and appreciated
Thanks in advance
So maybe the client should be using GP instead.
Ya i have heard its possible in GP but client wants in Navision so I have tried but didnt get it .So pls tell or give some idea hows its possible in Navision or not possible by any how
When you sold the system to the client, how did you explain this to them? It sounds like a key business requirement for them did you analyze the need during the sales process, and explain how Navision works?
This is a very common requirement, ankit. It requires a modification, but it’s very small.
Under receiving is handled as follows:
Generally, we create a new field on the report called - “original quantity ordered”. When a quantity is received, it changes the quanitty on the PO line, and saves the original quantity orderered in the new field. The new quantity is then fully received and invoiced (hence the “3-way matching”).
Over receving is handled by creating a new line.
There is usually some work to distinguish between backorders and purchase orders that just aren’t going to be fufilled.
Hmmm
vs
as I read it the client DOES NOT WANT TO ALLOW over and under.
This is exactly the issue, we are giving a code solution without having any clue what the client really needs.
[:@]
Hi girish ,
Thanx for this REply but if you dont mind can you tell me in little deep how to do that as I am little new in Navision…
Thanx in advance
That’s why ALL new Navision developers start by working the first years under a senior developer and consultant who will mentor them in how to become a Navision developer. You can’t expect to memorize the answers to a few tests and then become a top notch Navision consultant in a year.
Have you spoken with your mentor about this?
Correction:
What gets lost sometimes is that many of these noobs don’t know any better, and it’s their employers that are at fault here. We see an increasing number of general questions, expecting complete tutorials as answers, because the employers do not provide proper mentoring or career paths that should include actual training instead of a brandump and a link to an online forum. It’s the leadership that sets the tone, and by not providing proper mentoring and by not showing the new people the right way to go about skill levels, they jeopardize the entire industry.
I agree - having this growing group of untrained developers and consultants jeopardizes how NAV is perceived as a product. And it does appear that their employers think they will just magically figure it out (i.e. ask us [:)]) That seems irresponsible on the part of the employers and unfair to us.
On the other hand…
This free community greatly accelerates the maturation of developers and, personally, had more to do with my growth than any mentoring I had at work. In my opinion, the openess of this forum and the way it gets other up to speed quickly is a big plus to selling NAV.
Just my two cents…
The thing is that historically the developers and consultants we were helping were working in a proper environment and learning in a direction that built careers. This current generation is all about getting the hourly rate as low as possible with no concern what so ever of number of hours.
Customers are looking for cheaper hourly rates, and that is opening a market for developers with 3 months experience out of school, and a few “questionable” certifications to charge out programing at $25 per hour. That developer hasn’t a hope in hell of solving the problem, so just posts the “spec” here or on MiBuSo so that one of us can solve it for them. But the customer then ends out paying for about 8 times more hours to get the code working, and then finds out that the solution is not really what is needed and end out paying a qualified consultant and or developer to fix things to do what they really wanted.
Oh and when the OP doesn;t know what the spec means, and has to go to google to find out, we need to really consider if in fact we are helping the situation here or just making it worse. In my opinion the only correct answere is “Get back to the senior consultant”.
Hi Girish,
actually i didnt understand from your reply as below
"we create a new field on the report called - “original quantity ordered”. " and
"Over receving is handled by creating a new line.
There is usually some work to distinguish between backorders and purchase orders that just aren’t going to be fufilled."
Thats is didnt understand it so i am requesting you to give some idea of that In little brief
Thanks in advance
Hi Girish ,
Here i am mentioning one case which Client wants
pls suggest
I misspoke. I shoud have said create a new field on the purchase order line called “original quantity ordered”. When you release the order, if you have 100 in the quantity field you store 100 in the “original quantity ordered” field as well.
If you have orderded 100, and receive 90, you change the quantity field to be 90. The “original quantity ordered” field is still 100. Then you receive 90 and invoice for 90.
If you have already sent a payment to the vendor for 100, then you apply the 100 payment to the 90 invoice. Then create a refund from the vendor and apply the refund to the payment as well.
Is that clear? This is the standard way that most companies handle under receiving.
There can be another problem, however. What happens if you have a vendor that sends multiple shipments for an order and therefore you have to receive multple times? How do you distinguish between those partial receipt orders and an order that is not going to be completely fufilled (the above example)?
I just read this a bit more fully. One way to handle this would be the following:
Purchase order for quantity = 100 is created. When the goods arrive you find that they sent 105. Create a new line on the original PO for 105. Receive all 105 and Invoice for 105.
Create a purchase credit memo and return for remaining 15 items. Apply the credit memo to the 105 invoice - now you only have 90 left outstanding to pay for.
Create a payment for 90 and apply to the original invoice.
Success! And no code was written.
There are some costing issues you need to be careful of here. If you would like me to go “deeper” (and if you don’t know what I’m talking about, you should ask me to go deeper) then please demonstrate that you have some knowledge of how NAV handles costing.
Ahmed, I always thought of your mentoring as coming more from the community instead of the office. But hey - you taught me everything I know! So, everyone, if you don’t like my solutions, you know who to blame
Hi,
We have developed this functionality for purchasing and subcontracting companies… In addition our 3 way matching tool can work with commodity pricing - when price of goods changes every day and 3 way matching is really important…
If you do not need anything elaborate like this you can use standard NAV. You will need 3 roles for 3 way matching
Purchaser - user who creates purchase orders
Receiver - user who receives orders
AP User - user who processes Purchase Invoices
Add field Original Order quantity on the purchase line and populate it when PO get released. Create Field on Item Card - allowed Over Receine % - and allow receiving user only receive more by this %. Receiver must be allowed only receive PO’s.
AP User will create new invoice and “get uninvoiced receipts”. Put test field on release that Direct Unit Cost on PO equal Direct Unit Cost on Invoice…
That is basically it… Now you have system that does not allow receive more than ordered and does not allow process invoice with different price than was ordered and Purchaser will have to change PO price for Accounting to be able process Invoice…