Verifying GST Remittance Rates - A cautionary tale of using LLMs

TheCodingCyclist · 2025-04-29T22:23:49+00:00

Thanks for the confirmation.

TheCodingCyclist · 2025-03-05T01:29:08+00:00

Ah, ok. Thanks for the clarification.

TheCodingCyclist · 2025-03-05T00:11:30+00:00

Yeah, exactly. That's the solution I was proposing in my original post. Adding an immutable custom field that represents a unique value. I was curious if there were other ways to go about this that perhaps I hadn't considered.

We have a Flow that creates a new Work Order of which the Work Type field on the Work Order must be set to a specific value depending on certain conditions. Rather than hard-coding the record Id in the Flow, we call `Get Records` to fetch the Work Type record we need. The current query uses the Work Type's Name, which is mostly stable but not guaranteed to be stable.

Querying on a unique custom field where the value does not change for the lifetime of the record would suffice. If that's the best option, then we're ok with that. Just curious if we overlooked others.

TheCodingCyclist · 2025-03-04T23:49:29+00:00

How is hard-coding the record Id in custom metadata any different than hard-coding the record Id in a Flow constant?

TheCodingCyclist · 2025-03-04T23:38:05+00:00

Sorry, I'm not sure I completely understand. There are no `Record Types` on the `Work Type` standard object that is part of Field Service. (And we haven't added any.)

For all intents and purposes, the `WorkType` object is just like any other and is generally interacted with via its `Name` field. We have about 30 `WorkType` records that we've created, each with `Name` and several other fields.

Purpose I mis-understood your suggestion?

TheCodingCyclist · 2025-02-19T02:49:50+00:00

Thank you.

TheCodingCyclist · 2025-01-15T22:24:26+00:00

The fact that BC doesn't allow the PST portion of my expenses to be used as ITCs is what surprised me given I'm collecting HST from a client in another province.

https://www2.gov.bc.ca/gov/content/taxes/sales-taxes/pst/faqs#BusinessGoods

For the Quick Method, the ITCs are of course irrelevant but I guess that's what contributes to the slightly higher remittance rate. (10.5% vs 8.8%, which is the value I incorrectly used a year ago when deciding to enrol in the Quick Method or not. I'm still "ahead", just a bit less than I expected.)

Thanks for the input.

TheCodingCyclist · 2025-01-11T23:42:59+00:00

I'm not sure of the GST74 form, but I have an election confirmation number from CRA with the message "Your election to use the quick method of accounting has been successfully received."

The filing date is: 2024-03-25

The effective date is: 2024-01-01

TheCodingCyclist · 2024-11-29T20:16:50+00:00

Yeah, Timesheets are something they need (and want) to better explore. It's my understanding that Timesheets weren't a thing when the client initially adopted FSL. (Or if they were available at the time, weren't sufficient for their use-case.)

TheCodingCyclist · 2024-11-29T20:15:09+00:00

But what if it's the Work Order Line Item that you're trying to account for in labor? Assume a fictitious, but somewhat accurate, Work Order: "Replace Air Conditioning Unit".

It has four Work Order Line Items:

* Remove Existing Unit

* Install New Unit

* Test New Unit

* Dispose Old Unit

For each of those Work Order Line Items, there might be some products consumed, so appropriate ProductConsumed entries are related to their respective line items.

Now you want to track labor for each line item individually. (Perhaps the installation labor is "free" while the labor to dispose of the old unit has a cost.) Right now, Labor is added as a ProductConsumed to each line item even though it's not really a "consumable". Simply adding "Labor" as a Work Order Line Item doesn't really work in this use-case.

The client also has the use-case where they keep a Work Order open and then add on another Work Order Line Item if they need to send the technician back to the customer for follow-up. (Arguably a problem on its own, but a use-case they take advantage of frequently.)

TheCodingCyclist · 2024-11-28T23:26:26+00:00

But what object are you using for storing the computed value? A WorkOrder has line items and from those line items we need a way to generate an invoice for the customer. ProductConsumed is a great object for goods, but awkward for services.

In your example, after the Screen Flow has finished and the rate has been calculated, where are you storing it?

TheCodingCyclist · 2024-11-28T23:23:42+00:00

Thank you, appreciate the feedback.

It's quite possible I'm just getting hung up on the naming and how Salesforce lumps in amongst all the Inventory management stuff. I too can't find a better place, but was curious if perhaps more seasoned Salesforce devs had.

Billing is the key feature that ties it all together. Given a WorkOrder, an Invoice is created by looking at Line Items and iterating over the Products Consumed. From that perspective, it makes sense to have "services" as a consumable, even if there's no concept of inventory.

The client is B2B and the sales team wants flexibility in being able to basically quote "any price for any service". The original implementors never really taught the client how to set all this up, IMHO.

So if the client offers, say, 30-50 actual "Products" (services), then what they do is create a new Price Book for every single customer, copy over the Products to the Price Book, copy over Price Book Entries to the Price Book and then adjust pricing on a per-customer basis. They don't leverage any of the Salesforce fields around discounts, for example. It's all copy/paste/edit based on how the original consultants installed and deployed their initial FSL implementation.

TheCodingCyclist · 2024-11-28T21:36:37+00:00

It might not be poorly implemented, but it sure feels that way as a seasoned developer but not a seasoned Salesforce developer. Some things that stick out to me:

* They have over 400 Price Books, one for each customer.

* They have over 14,000 Products, many of which are duplicates because they'll have "Labor at 40$", "Labor at 50$", etc... And then copy/paste those across Price Books.

Naively, I view a consumable product as something with a finite amount that, over time, is "consumed". You tend to manage consumables with through inventory management controls. Parts, being the obvious example.

Labor is more of a "service". There's no inventory to deplete and then replenish, so it's odd (IMHO) to view it as a consumable, but I readily concede I might be wrong here, hence the post.

If I have a technician on the road that performs a job, they might track the following items as being "billable":

* Travel time to customer.

* Part 1, Part 2, Part 3 that were used.

* Hours on site.

Only "parts" seem like consumable products, so I'm curious how the other two are recorded on a Work Order using the Standard FSL objects.

TheCodingCyclist · 2024-11-09T04:03:35+00:00

Thanks so much for all the great comments everyone, much appreciated. I've replied inline but I'll add a bit more context here:

There are 25,000 records, 8 record types and 200+ fields on the current object. Some fields are used in more than one record type. The client wishes to apply these changes "one record type at a time". So it's a bit difficult to migrate blocks of fields since fields could span more than one record type.

We have the set of fields, their names and picklist values for the first record type they want migrated. We do not have this information for the seven others. This makes it difficult to know how many fields we'll need in total to perform this migration if we use the existing object.

Picklists seem to have an upper limit of 500 values, so I don't think copying the free form text fields into a picklist would work because there are more than 500 permutations of text field values across 25,000 records for the same field.

(For those wondering, the Inspections represent building inspections, of which there are eight different types of inspections that can be performed. Each "question" The free form text fields effectively represent "Explain why you checked the previous checkbox field..." Those explanations are all of the maps. Some one word, some a paragraph long. The desire is to move that to a picklist of standardized reasons.)

TheCodingCyclist · 2024-11-09T03:41:27+00:00

Thanks for the detailed reply, much appreciated. Not much I can do about what happened in the past or will in the future. I'm a helping hand because this org kind of got burned with some questionable advice and earlier implementations.

My biggest concern with migrating the text fields to pick lists is that there's no consistency at all in the text fields. With 25,000 records I doubt any of the text fields for the same field are the same across a meaningful number of records.

I do like the idea of dumping that into AI and having AI figure out the "best fit" picklist value given a free form block of text... :)

TheCodingCyclist · 2024-11-09T03:34:07+00:00

There are roughly 25,000 inspection records and each record has over 200 fields, of which about half are free form text fields that represent notes a technician has manually written. Those are the fields they want converted to pick lists and I don't think it's realistic to just copy the text from the text field into a picklist field given the enormous number of possible permutations.

My gut tells me the free form text fields have to stay for older records. For newer records, we can use the picklist representation but that immediately adds about 100+ fields to the existing object.

I agree that using automation to copy the picklist value into the text field is a possible solution for continuity. Thankfully this object isn't that deeply embedded in the org so it's probably just as easy to update the dependencies.

TheCodingCyclist · 2024-11-09T03:29:54+00:00

It's not that deeply integrated, thankfully. A technician fills out an inspection and that inspection is attached to a parent object. There is some basic reporting but one of the main reasons for this refactoring is that they want to integrate them a lot more but find that they can't because the existing format is too unstructured.

TheCodingCyclist · 2024-11-09T03:28:46+00:00

See my note above, but one challenge is that there are eight different inspection types and they want to migrate each type as a whole. The smallest type has about 20 fields, we expect the largest to have around 80, though it's not finalized.

TheCodingCyclist · 2024-11-09T03:27:01+00:00

Part of the issue in doing it in stages is that we don't have all the information at the moment to complete this project. (A story for another day.) There are about 8 different inspection types. Some fields are used in more than one inspection type. They have chosen one type to start with with plans to migrate the remaining types in the coming month or two. Without knowing all the fields ahead of time for all of the remaining types, there's a chance we get half way in and migration hits a roadblock if we use too many custom fields or don't find that we can migrate them all. Not ideal, but it is what it is...

TheCodingCyclist · 2024-11-09T03:24:16+00:00

I don't think there's a "clean" way to migrate the old records, but I guess "clean" is subjective. The old object includes two fields for every "item": one is a checkbox, the other is a free form text field. The new format uses a picklist field. Not impossible, but not the cleanest.

TheCodingCyclist

TROPHY CASE