Working in 3.6 Database, On Sales Order. We have the situation where the client wants to track specific stock by using the “Appl-to Item Entry” my question is does this work in any way shape or form with Order Tracking?? The results we are getting are quite confusing. If the end user decides to change their ming as to which Item Ledger entry they wish to apply the Sales line to, then the order tracking seems to ignore this, and therefore create confusion as to which stock will be applied against when sales order is shipped. In the end it is the entry in the “appl-to entry no.” field anyway, making me think then that the order tracking functionality is not quite right??? Can anyone shed any light on this? Cheers.[;)]
Hi Andrew I presume you are not using the true order tracking of serial and lot numbers as it over complicates matters for you, therefore I have two questions for you. 1) Why are you not using reservations? 2) Is there a specific reason you have posted in the manufacturing forum - do you require this tracking also at a the component level of a BOM? I only ask as I believe you are using the applies to entry field in an unusual way, it is on the form as it is used in other areas, but not particularly in the manner you are. I have not looked at using this field in this manner because I would approach the “tracking” differently depending upon the requirements (perhaps you could elaborate on these for us).
Another issue ? - make 2 purchase order receipts : LOT1, LOT2 - this results in 2 Item Ledger Entries : 1 and 2. - make a sales order, item tracking and select LOT1. - assign Item Ledger Entry 2 (which is LOT2) to the sales line : via the field Appl.-to Item Entry => you can post without any issue : you get a posted tracking of LOT1, and when you look at the ILE, the remaining quantity of Item Ledger Entry 2 is now one less … I would have guessed that we would get an error on post of the shipment saying we have provided conflicting information. Should I issue a service request or am i mistaken ?
Hi nav nav I suppose whether you issue a service request or not depends upon the actual functionality of the Appl.-to Item Entry field. I believe there are other - designed - methods to handle the functionality Andrew is after, and I am unsure if a) the Appl.-to Item Entry field will do what he wants or b) the Appl.-to Item Entry field is supposed to do what he wants! Andrew seems not to use item tracking, and in your example you are, not to mention you are telling the system to do something wrong, it is not doing it in processing. So if we can break it is it a bug to be reported or are we using the system in an incorrect manner [?] I suppose you could always log it and they will tell you [:D]
I agree that it is abusing the system. But I always try to follow the concept that if you allow the user to fill in fields, you have to make sure it works in all situations. I made a service request.
You must break it everywhere then [:D] Let us know how you get on.
Thanks for your imput, i think reservations entries are the way in which we are going to tackle this problem, as on straight forward orders they work great. The only issue is not being able to reserve from multiple locations. Guess that’s another issue all together though. Thanks again.
Hi Andrew I think you are correct that locations will cause you a problem - with reservations turned on and a location on the sales line the only applicable reservation would be at that location, so you cannot ship from Location A and reserve that stock at location B (which in most circumstances would be sensible [:D]). A work around to this is to use the availability by location on the line to show where you can load the order and then split the sales line over the available locations.
This has always been a bit of a issue with some of our clients using MFG, as when using locations, Navision presumes that the user will already know at the time of sales order input the location of where the Output will be placed. Am i correct in saying that Navision Locations are really for geographical areas as opposed to rows/shelves/bins. (in which case you would know the location upfront).
quote:
Originally posted by AndyP
This has always been a bit of a issue with some of our clients using MFG, as when using locations, Navision presumes that the user will already know at the time of sales order input the location of where the Output will be placed. Am i correct in saying that Navision Locations are really for geographical areas as opposed to rows/shelves/bins. (in which case you would know the location upfront).
I would say, you’re correct.
Hi Andrew Just as an addition to nav nav (Gunther of old?) the warehouse management system deals with the functionality of rows, bins and zones etc., although a bin literal does appear against the item, although this is not a processing location - so it assumes everything is here. The additional processing involved in warehousing is substantial but it is the price you pay for that level of control[:D]. In essence - yes locations denote geography, they can and are used for a variety of other functions but you need to be aware of the limitations, and this is one of them [;)]