on
RE:
A suggested creative solution; create a TBD Resource (you could add this/create one for each Resource Group). On Job Planning Lines, assign the TBD Resource. The type could equal = Budget only. when the resource is scheduled, create a new planning line for the portion for the new resource. Or replace with the TBD.The TBD resource hours assigned can be included in reporting to gage how many hours are still not assigned.
RE:
Sales Orders linked to jobs would also allow Drop Ship AND warehouse shipments . I imagine the restrictions are because of the multiple places that the data can change when working through standard BC functions (change qty, pricing, amount received, etc) validating changes will compromise the integrity of the data flow back to the job. however, something needs to be done. Far too many organizations and their consultants dive into using BC Jobs/Projects without realizing the restrictions. I would rather have the entire BC Jobs removed then allow it to exist where an organization decides to implement it without understanding the limitations**** recently i have observed "Limitations" listed within Microsoft Learn and demonstrations published by Microsoft. I encourage more of this
RE:
To elaborate on my recent comment posted; a drop ship is only created from a Sales Order. Since Sales Orders cannot be created and linked to a Project, a Project cannot have a Drop Ship. Sales Invoices can only be generated from Project Planning Lines whereas Purchase Invoices CANNOT be generated from project planning lines. We need the ability to generate both Sales and Purchase documents using the data in the project plannings lines. ]I understand that the bi-direction flow of data between sales and purchasing and the project can result in data validation errors/issues if the sales document changes during the workflow, but at least have a function to write data back to a project upon user command or similar
RE:
I would love to have this solution. Is this something that get's follow up?
RE:
I believe this is what the pbip format was created for. I think pbits can't be published because the standard office template format means you can only ever save a template; you can't ever open a template as such, it just creates a new file with all the content from the template populated.If it helps, we put the .pbix extension in the gitignore file so we can guarantee pbixs are never committed
RE:
I agree with the proposed solutions.
RE:
I agree with the proposed solutions. Another option is to determine through a global setup if the 'get receipt lines' function to work with the 'Buy from-vendor' or the 'pay-to vendor" of the receipt
RE:
Implementing this request, which prompts users to acknowledge that the "Request Receipt date" is being recalculated/ and or not updated and gives an option to choose the desired action will be very advantageous.Thus, I would request Microsoft to take this into account for the product upgrade.
RE:
I have spoken to our partner about this very thing, they looked into it and the code is marked as internal, looks like we cannot extend it ourselves and have to wait for microsoft.
RE:
Hi Laura,Thanks for raising this issue on IDEAS portal. Implementing this request, which prompts users to acknowledge that the "Request Receipt date" has been modified as a result of a change to the PO lines, will be very advantageous.Thus, I'm asking Microsoft to take this into account for a product upgrade.Regards,Deepak Sharma