I have a client that would like to edit one field on a posted sales invoice. That field is a Customer PO field. As much of a no-no as that seems to be, it also seems pretty harmless being that it is just an informational change. The problem I am having is that the field is editable on the form and you can make the change - but as soon as you leave the record you get a permissions error (even as superuser). You do not get an error with a solution developers license loaded. Is that something that is restricted in the customer license file? Thanks
Doug, Well the technical answer is set the Permissions property of the Posted Sales Invoice form to ‘TableData Sales Invoice Header=rm’. This gives the form permissions to update the table. Of course the non-technicial answer is should you really be doing this? Once posted, documents should not be changed so they can be reporduced (re-printed) if necessary.
With custormer license you can’t edit/insert/delete posted entries (ledger entries, posted documents). This permission should be set on object which is changing the entry.
I think you could get away with a Codeunit similar to 315 Sales Inv.-Printed (check out the Permissions property). When the field is validated, pass the current record to the new Codeunit and let it modify the record. Most probably, and depending on how it’s done, you will need to either COMMIT the changes inside the Codeunit or UPDATE the Form after modifying the record.
Take a look at codeunit 391, “Shipment Header - Edit” and the way it’s called from form 130. If you want to enable modification of the Invoice Header it should be done, indirectly, in a similar fashion. A modification like this should definitely be applied with caution…
A-ha! Steffen’s Codeunit is an even better example.
Don’t forget to change the appropriate ledgers as well (Cust. Ledger, etc)
For the simple purpose this is to serve, Gary’s suggestion worked perfectly. They essential have one user with the rights to enter a PO number on the sales header so I figure no real harm done by allowing this. They often time dont get a PO issued to them till weeks afters the invoice has been created. Thanks for the help…
quote:
Originally posted by elimar
For the simple purpose this is to serve, Gary’s suggestion worked perfectly. They essential have one user with the rights to enter a PO number on the sales header so I figure no real harm done by allowing this. They often time dont get a PO issued to them till weeks afters the invoice has been created. Thanks for the help…
This is Navision and everything is done for a reason, this includes the Edit codeunits! Garys Suggestion may work fine and only “one user” can edit the PO but that could be changed in a moment, now if the client or another programmer has forms designer they can drop a field on and make any field editable. I would strongly suggest you have a look at the codeunit for Sales Shipment-Edit as the earlier post, within this codeunit only the fields that Navision want to let the user modify can be changed, this means that only someone like us with access to the codeunits can add fields that can be edited, if you add the permission to the form the system will allow editing of any field not just the one you want! Editing Codeunits: The permissions are set at codeunit level and as you can see in the code below, only the selected package tracking fields can be edited not the whole record as in Garys solution. SalesShptHeader := Rec; SalesShptHeader.LOCKTABLE; SalesShptHeader.FIND; SalesShptHeader.“Shipping Agent Code” := “Shipping Agent Code”; SalesShptHeader.“Package Tracking No.” := “Package Tracking No.”; SalesShptHeader.MODIFY; Rec := SalesShptHeader; With Navision the quick fix is not always the best option, so consider the “what if” senario’s!
Good point, David. I will look further into that before finializing.
quote:
Originally posted by achowtc
Don’t forget to change the appropriate ledgers as well (Cust. Ledger, etc)
I’m surprised that no one is emphasizing this. But the Cust. Ledger will need to be changed too, or else you’ll have a hard time matching the customer’s PO between the Posted Invoices and the reports.