#Salesforce Field Service65 utenti parlano di questo argomento

I would check:

1. all service objectives and weights in the scheduling policy
2. whether Resource Priority or Preferred Resource is active
3. actual travel time used by the scheduler, not only map distance
4. geocoding on the Service Appointment and resource locations
5. whether last known location is actually used for scheduling
6. whether the visible 100/100 score is rounded
7. whether the result changes with a simplified test policy using only availability, skills, territory and minimize travel.

@Michael McCarthy

This is a data job, not a coding job. No Apex needed.  

You're updating PricebookEntry records. Each one is just a Product plus a Price Book plus a price. Lots of records, but still just records. Data Loader handles this.

Three steps:

Export first. Pull every PricebookEntry with Id, Pricebook2Id, Product2Id, UnitPrice. The Id is the key column. It lets you update in place instead of making duplicates.

SELECT Id, Pricebook2Id, Product2Id, UnitPrice FROM PricebookEntry

Edit in spreadsheet. Open the export, change UnitPrice to your new rates. Sort by product family and price book, apply the right rate to each group. Your 15 families and 10 charges get sorted out here in a few minutes.

Load back in. Run Data Loader Update (not Insert), match on Id. One job. Thousands of records updated in one pass. 

Few things to watch:

Test in the sandbox first. Price changes ripple into quotes, work orders, and estimates. See it work safely once, then repeat in production.

Standard price book matters. Custom price book entries need the standard entry to exist. You're updating existing entries, so this shouldn't cause issues, but Data Loader's error file will flag any that do.

If this repeats yearly, save your Data Loader mappings. Next year is push-button. That's the only automation you need. Still not Apex.

Where the Apex advice came from: code only makes sense if rates must recalculate automatically based on business logic. Even then, one Flow or one trigger does it, not 750 files. For a bulk rate refresh, Data Loader is the tool. An afternoon of work, not a dev cycle. 

-SP

@Eva Murphy Please find resources on the new Scheduling Console below:

Product documentation:

https://help.salesforce.com/s/articleView?id=service.fs_scheduling_console_parent.htm&type=5

Trailhead: 

https://trailhead.salesforce.com/content/learn/modules/scheduling-console-quick-look

So if you chose to uncheck the box in Field Service Mobile Settings for full Edit Access on records the only place the Technician could potentially go to actually attempt to update the Quantity on Hand would be through the Inventory Tab > Edit Inventory Action.

To your point, making the quantity on hand field read only isn't possible as far as I know, just based on past experience and what I see in the org.  You would have to go the route of making the entire Product Item Object Read Only, which could get complicated in my opinion.

You'd most likely have to make it Private in OWD Settings, then open it up from there using Sharing Rules, which depending on how many Items you have, could get difficult to manage.  You'd have to determine who is going to get Edit Access, who would remain read only, etc... and then confirm that there are no implications into your current processes based on the Items being just read only for certain folks.  To be honest, that does not sound like a fun path to go down.

You could investigate using a Validation Rule on the Product Item, using something like an ISCHANGED() on the Quantity on Hand Field as well validate the profile.  So in essence if the quantity on hand is changed and the user doing it is a technician profile, then show the validation error.

Again, if you went that route you would want to test throughly to confirm that doesn't have an impact in the product consumption process, which you might be ok on as long as the running user to create the product item transactions is the system and not the technician.

Also keep in mind that if you go this route, the user would still be able to attempt the editing of their inventory through the inventory tab, but when that change tried to sync to the database, it would throw an error.  That error would be visible in the profile tab.

You would need to be mindful to of when the stock transactions you mentioned occur in the other app, do those come through into SF tagged to an integration user or directly to the technician salesforce user, as that could trigger the validation as well.

Hope this helps!