How do you handle the situation when stock needs to be received but the Po was never created and after PO must be assigned to that receiving.
Ps: I dont want to make an inventory adjustment.
Thanks
Same question as Savatage's. Why don't you want to make the PO?
If you don't want to make the PO, you have no other option but to use the Item Journal. Either you can make a positive adjstmt, or you can make a Purchase.
If you want a PO later on, and if during receiving, the PO is still not made, why not make the PO at the moment of receiving and post it?
This is a problem we also face many times. Actually the problem is not not making a PO but unable to decide the PO upon receiving: vendors don't give the PO number upon shipping.
So what actually would be needed is a later match between a Receipt and a PO.
I am thinking on an add-on solution covering it, however, I still not yet measured all the consequences...
Do It Yourself is they key. Standard code might work - your code surely works.
If you make an adjustment instead of a purchase in the item journal the items will not appear in the vendor statistics, use Entry Type::Purchase.
You can use the purchase journals when the receipt arrives to post it , but you have to make sure that the posting date and document no. are identical, otherwise the navigate function won't work, and in addition to this there is no proper document to print.
I have an outline for implementing Purchase Order / Receipt Matching.
Basically Item Jnl - Purchase type is wrong idea because it is invoiced (creates cost amount (actual)).
Implementing Purchase Receipt (or, more likely, Whse Receipt) w/o an order seems close to impossible - Navision really heavily relies on the document workflow process. It is the same old "how to make an integrated system unintegrated for an unintegrated client" we face on almost all projects. (Does it sound strange? Well, take a journey then to here, to the Wild Wild East, and take a good look around )
So as Receipt w/o PO is out of question, the only way to solve it seems to be to create an on-the-spot PO when receiving.
Problems:
1) User Rights: warehouse guys should not be allowed to create PO-s
2) Matching it with the original PO
For problem 1), I suggest the following modification:
- create a boolean field "Temporary" to table Purchase Header
- create a new field to Purchase & Payables setup, "Temporary PO No. Series" with relation to No. Series
- create a Codeunit, that a) inserts a new Purchase Header, Document Type is Order, No. is NoSeriesManagement.GetNextNo to this "Temporary PO No. Series" field. It also checks the "temporary" field to yes.
- Create a menu item called "Create a blank temporary PO" that runs it.
Yes, it is against Navision standards. Why we do this unorthodox thing is User Rights. If you do it this way, you can give a role to the Whse Employees that they are allowed to insert a Purchase Header, but only allowed to modify (and delete) a Purchase Header with a security filter of Temporary= YES. The No. Series is for visibly separating real and temporary PO-s.
With all this, they will be able to create temporary=YES PO-s but not real ones. Any simpler solutions are welcome.
For problem 2), I suggest the following modifications:
- New field to Purchase Line: quantity to match.
- Code to Codeunit 90: when posting a Temporay=YES PO to Receive, quantity to match is set equal to quantity to receive.
- New form, PO Matching, with two subforms. One lists all PO lines, other lists only those with quantity to match > 0. Users can select a record on both of them (use GETSELECTIONFILTER) and press a menu item or button that matches them. T
This button:
- checks which has the less quantity
- modifies Qty. Received, Outstanding Qty. and all such relevant fields with this quantity
- maybe Document Nos. etc.
(this still needs a little bit more design)
Do you like it?
Do It Yourself is they key. Standard code might work - your code surely works.
Yeah - but even then you won't have f.e. Source No. in then Item Ledger Entry.
If you make the Source Type and Source No. Fields editable in the Item Journal you can select Source Type::Vendor and in the "Source No." the Vendor No.
Comments
do you not want to use Item Journal ->Entry type->Purchase?
http://www.BiloBeauty.com
http://www.autismspeaks.org
RIS Plus, LLC
I woulk like to do the receiving but not on sa PO as I didnt create anyone.
Maybe I will use savatage suggestion
Is there a reason you don't want to create one?
http://www.BiloBeauty.com
http://www.autismspeaks.org
Same question as Savatage's. Why don't you want to make the PO?
If you don't want to make the PO, you have no other option but to use the Item Journal. Either you can make a positive adjstmt, or you can make a Purchase.
If you want a PO later on, and if during receiving, the PO is still not made, why not make the PO at the moment of receiving and post it?
So what actually would be needed is a later match between a Receipt and a PO.
I am thinking on an add-on solution covering it, however, I still not yet measured all the consequences...
Do It Yourself is they key. Standard code might work - your code surely works.
You can use the purchase journals when the receipt arrives to post it , but you have to make sure that the posting date and document no. are identical, otherwise the navigate function won't work, and in addition to this there is no proper document to print.
Do It Yourself is they key. Standard code might work - your code surely works.
Basically Item Jnl - Purchase type is wrong idea because it is invoiced (creates cost amount (actual)).
Implementing Purchase Receipt (or, more likely, Whse Receipt) w/o an order seems close to impossible - Navision really heavily relies on the document workflow process. It is the same old "how to make an integrated system unintegrated for an unintegrated client" we face on almost all projects. (Does it sound strange? Well, take a journey then to here, to the Wild Wild East, and take a good look around
So as Receipt w/o PO is out of question, the only way to solve it seems to be to create an on-the-spot PO when receiving.
Problems:
1) User Rights: warehouse guys should not be allowed to create PO-s
2) Matching it with the original PO
For problem 1), I suggest the following modification:
- create a boolean field "Temporary" to table Purchase Header
- create a new field to Purchase & Payables setup, "Temporary PO No. Series" with relation to No. Series
- create a Codeunit, that a) inserts a new Purchase Header, Document Type is Order, No. is NoSeriesManagement.GetNextNo to this "Temporary PO No. Series" field. It also checks the "temporary" field to yes.
- Create a menu item called "Create a blank temporary PO" that runs it.
Yes, it is against Navision standards. Why we do this unorthodox thing is User Rights. If you do it this way, you can give a role to the Whse Employees that they are allowed to insert a Purchase Header, but only allowed to modify (and delete) a Purchase Header with a security filter of Temporary= YES. The No. Series is for visibly separating real and temporary PO-s.
With all this, they will be able to create temporary=YES PO-s but not real ones. Any simpler solutions are welcome.
For problem 2), I suggest the following modifications:
- New field to Purchase Line: quantity to match.
- Code to Codeunit 90: when posting a Temporay=YES PO to Receive, quantity to match is set equal to quantity to receive.
- New form, PO Matching, with two subforms. One lists all PO lines, other lists only those with quantity to match > 0. Users can select a record on both of them (use GETSELECTIONFILTER) and press a menu item or button that matches them. T
This button:
- checks which has the less quantity
- modifies Qty. Received, Outstanding Qty. and all such relevant fields with this quantity
- maybe Document Nos. etc.
(this still needs a little bit more design)
Do you like it?
Do It Yourself is they key. Standard code might work - your code surely works.
The document nos. in the item journal and the purchase journal need to be identical.
Yeah - but even then you won't have f.e. Source No. in then Item Ledger Entry.
Do It Yourself is they key. Standard code might work - your code surely works.
If you make the Source Type and Source No. Fields editable in the Item Journal you can select Source Type::Vendor and in the "Source No." the Vendor No.