Grulin
commented
5 months ago Hi @kevin-hashimoto. The piece that I was missing from this card is the explanation of how fuel codes are numbered. The original number (for example, 100) can be assigned to any fuel pathway (a fuel pathway is the unique assignments of a company, CI, fuel, feedstock, location, transport mode etc.) that the specific code will be applied to. The versions of these codes (so the same pathway, but some slight changes to CI or or nameplate capacity and/or simply new effective dates) are given a new decimal place values.
There is no sequential restriction on entering the initial fuel code number (100) unless it has been used already. In that case, when the fuel supplier goes to input 100, they will be forced to pick the next version (maybe 100.4 or whatever the next version is).
Also, the fuel codes should begin at 100.0 and the new code fields should not be auto-populated unless the user is entering a new version of a previously used fuel code. Fields can prepopulate once the new version (100.1 for example) is chosen. Please see TFRS for how this works.
Please see examples from TFRS:
Fuel code versions in view table: Image
Also for consideration: How can we design the fuel code input so that users can easily enter multiple codes with similar inputs all at once. For example, 10 codes from the same company. Right now, we would have to add the company name over and over again for each line.
Please let me know if you want me to create a new card for this if it's going to be a lot more work. Thank you
Description: When an IDIR user is adding a new fuel code and inputs the fuel code number into the 'Fuel code' field, the system suggests the next version of the code. This is achieved by scanning the database of existing codes to determine what the next version will be. See the "fuel code versioning" section below for more information on versioning.
The user must select this next version, they are not able to indicate their own version of the code. We achieve this in TFRS by preventing decimals being used in the input field.
Once the user selects the next version of the fuel code, the system should prepopulate some of the input fields with data from the previous version. See the "prepopulate" section below for more information.
NOTE: This functionality exists in TFRS; we want to replicate it in the LCFS portal.
Fuel code versioning: Fuel codes are assigned a prefix "BCLCF" and then given a unique 3+ digit number that follows sequential order. The first ever fuel code was BCLCF101.0. The '.0' end portion of the fuel code indicates its version. Fuel codes have effective periods when they are active, usually 1-3 years; after this period, the fuel code expires. The fuel producer is the one who is responsible for applying for fuel codes for their fuel production facilities; when a code is nearing expiry, the producer can apply for renewal of the fuel code. Once the application is processed, the renewed code will be given a new version number. For example, when BCLCF101.0 expires, the next version will be BCLCF101.1.
Prepopulate data when selecting the next version:
The following fields should be prepopulated when the user selects the next version:
Wireframe:
https://preview.uxpin.com/59145260c7d8cc48969ac79401cc03d84843c3d9#/pages/165712417/simulate/sitemap
Purpose and benefit to user:
This auto-suggestion ensures data quality by mitigating the risk that IDIR users enter a version already in use or skips a version. Some expired codes are still used for late or supplemental reporting, so it is vital that each fuel code is distinct and doesn't repeat any previous versions.
Acceptance Criteria:
Development Checklist:
Notes: TFRS already has this feature. reference TFRS to see how it was done there