Before a receiver, buyer, or processor of seafood products can use the eLandings system to submit reports they must establish an operation, and user accounts for the individuals who will use the eLandings system.
Operations
For the purposes of the eLandings system, an operation is defined as an entity that will receive seafood product and will complete landing and production reports, as well as IFQ reports.
- A landing report is defined as the initial or first exchange of seafood product from the harvester to a second party. The second party may be a buyer, receiver, processor or expediter. The landing report will document one or more ADF&G fish ticket(s), and may also generate one or more IFQ report(s).
The range of seafood you receive and process will determine your Operation type and there are a number of different licenses and permits that may be required. The State of Alaska requires that all buyers of seafood product obtain an annual Intent to Operate license, commonly referred to as the ADF&G Processor License Code.
Processors or receivers of federally managed groundfish species must obtain a Federal Processors Permit (FPP). Buyers or receivers of IFQ halibut or sablefish must obtain a federal Registered Buyers Permit (RB); and each receiver of rationalized crab must obtain a Registered Crab Receiver (RCR) permit. The Crab Rationalization Program is exclusive to the Bering Sea and Aleutian Island (BSAI) king and tanner crab fisheries.
As stated above, an entity that is licensed to receive seafood product with the State of Alaska can register an operation. Most buyers, receivers or processors of seafood product have only one operation. In some cases, a business may establish a separately licensed or permitted enterprise. A unique operation is defined as having a distinct combination of any of the following: ADF&G processor code, Federal Processing Permit number, federal Registered Buyer number (Halibut/Sablefish IFQ), a federal Registered Crab Receiver number (Rationalized BSAI crab), and port code.
If the combination of any of these permits differs, then the operation is unique.
The eLandings system defines several types of operations that have different characteristics. Each operation registered must be one of these types. If you want to register an operation that does not seem to fit one of these descriptions, contact eLandings support (email elandings@alaska.gov) for help with your registration.
Plant/Receiver
A plant/receiver is a shorebased processing plant or seafood receiver. Plant/Receiver operations are the most common type, and are able to do custom processing or receiving on behalf of another operation.
At-Sea
An At-Sea operation is a Catcher/Processor, Mothership, or floating processor that is receiving or processing fish in State waters and/or in waters of the EEZ off the coast of Alaska away from an established port. At-Sea operations can also do custom processing or receiving for another operation.
Buyer/Exporter
A Buyer/Exporter operation receives catch from fishers, but exports the catch without processing the catch into other products. They can export within or out of country. Since Buyer/Exporter operations do no processing they cannot do custom processing. However, they can have custom processing done for them by another operation.
Catcher Seller
A Catcher Seller operation is a vessel that catches and sells unprocessed or limited processed catch to individuals (e.g. via dockside sales) for personal consumption, or to other fishers for bait, but not for resale. Catcher Seller operations cannot do custom processing for others, nor can they have custom processing done for them.
Custom Processing Owner
Groundfish
The purchaser/owner of the seafood product may have another processor or operation receive, expedite, or process seafood on their behalf. The operation that is in possession of the seafood product, but not the owner or a direct agent for the owner is a Custom Processor. NMFS defines a Custom Processing relationship as between a mothership or catcher/processor issued an FFP or a shoreside processor or SFP issued an FPP, with a contractual relationship with a custom processor to process groundfish on its behalf.
The owner of the catch must establish a custom processing operation for each physical plant that does the actual processing. This allows the owner of the catch to maintain visibility and control of the landing reports. The landing reports should be created and submitted on the owners behalf by users at the plant that are doing the custom processing. The owner of the seafood product must have a valid ADF&G Processor Code license and the processing facility will need to have their own receiving permits from Fish and Game as well as NMFS. These permits are used to establish the custom processing owner operation. Once the operation is established, the users at the custom processing facility will be authorized to make landing reports for the custom processing owner operation. This is akin to providing the custom processor with the metal process code plate to create paper fish ticket records.
The advantage of establishing the custom processing owner operation is that it gives the owner the ability to review and access landing reports electronically as soon as they have been successfully submitted to the Interagency Server. They can also remove the authorization to access those reports should the business relationship be terminated.
Crab
In this type of custom processing relationship, the owner of the crab must have their own established eLandings operation type that allows for custom processing relationships (see ADFG allowable activities matrix). Within that operation, they must have their own ADFG processor code in addition to an RCR permit. When the crab owner determines that they want to have a shoreside plant custom process for them, they must obtain an additional RCR permit that identifies the physical processing facility where the processing will occur.
The owner then creates the custom processing relationship in eLandiings, under Administer Operation. The process will generate a unique operation that identifies the relationship between the owner and processor and provide the user with an opportunity to add the new RCR before saving. eLandings administrators must approve these before users can access the new operation.
Child Operation Types
Two types of operations act as agents for another operation, but do not have any affect on the ownership of the seafood product. They pass the product along to their parent operation for processing.
Buying Station
A Buying Station is a land-based entity that receives unprocessed groundfish from a vessel for delivery to a shoreside processor and that does not process the fish (NMFS 679.2 Definitions). A buying station can be considered an annex of the plant or mothership (this is not done in Federal fisheries) for which it is acting as an agent. Buying Stations are usually completely shore based, such as a truck being loaded for transport to a distant plant, or may be a scow (a barge-like vessel). Tenders are specifically added to shoreside operations so that tLandings and PTI can be configured and used to document tender vessel landings.
Tender
A tender vessel is a vessel that is used to transport unprocessed fish or shellfish received from another vessel to an associated processor (NMFS 679.2 Definitions).
User Accounts
Before an operation can use the eLandings system to submit reports, they must establish a user account for each individual who will actually use the system. A user is an individual that has been designated to use the eLandings System to record seafood landings and production. Each individual that will use eLandings must be identified by name. The user management subsystem of eLandings controls which individuals are able to view and enter data on reports for specific operations. User accounts also allow the system to pre-populate some data fields on landing and production reports, such as processor codes, processor permit numbers, and port code.
User IDs
Each user of eLandings needs a user ID. The user ID identifies the individual and gives them authorization to view and submit reports for specific operations. User IDs should not be shared, each person should have their own user ID. This facilitates the management of users and privileges, and provides for data security. When created, a user ID must be authorized to access reports for at least one operation. Before a user ID can be utilized both the User account must be registered by submitting a signed user agreement form to the eLandings overseeing agencies.
Passwords
Each user account has a password. The password protects the user account and its operations. It allows the system to authenticate the user, and to prevent unscrupulous individuals from impersonating users and accessing confidential data. Passwords should be secret and hard to guess. A user should never share their userid and password with another user. If a password is accidentally compromised it should be changed immediately.
User Profile
Each user account has a profile for the user. The profile contains contact information such as telephone numbers and an email address. The contact information should be kept up to date since it will be used in the event that eLandings support staff need to contact the user about issues with a submitted report. The email address will also be used by the eLandings system to notify users of important information such as planned outages and changes to the system.
The user profile also has configuration settings for the user. These control the number of lines of data entry fields that will be displayed by default. Setting these parameters appropriately will reduce the number of times a user has to request more data entry fields when they are entering reports. The configuration settings also allow users to set the number of decimal places they will see for weights and prices. This is particularly important for users and operations that use prices that include fractions of cents.
The user profile allows the user to specify a default operation. When creating a new landing or production report this will save the user the step of specifying which operation to create the report for.
User Authorizations
The same user ID may be used for multiple operations. UserIDs can be given access to an operation when appropriate, and have their access privileges for that operation revoked, without affecting the user ID, the data about the individual, or its access to other operations.
Operation Administration
Each operation required at least one user designated as an administrator. Administrators can manage the operation and users for the operation. Administrators can create new user accounts, add existing users to their operations, remove user privileges, and setup new operations.